T-121.300 KÄYTTÖLIITTYMÄSUUNNITTELU Luento 3. Käyttöliittymäsuunnittelun mallinnus- ja kuvaustavat Teknillinen korkeakoulu Käyttöliittymät ja käytettävyys Marko.Nieminen@hut.fi http://www.soberit.hut.fi/t-121/t-121.300
Käyttöliittymäsuunnittelun mallinnus- ja kuvaustavat Luennon sisältö: Käyttöliittymäsuunnittelun mallinnuksen taustaa Käyttöliittymäsuunnittelun perinteiset mallinnustavat Oliopohjaiseen suunnitteluun soveltuvat mallit
Mallien ja mallinnuksen perusteita Relevanttien/oikeiden asioiden esiin nostaminen Asioiden järjestäminen tarkoituksenmukaisella tavalla Kommunikointi Tehokas kommunikointi Semiformaali tai formaali kuvaus käyttöliittymän toiminnasta Formaali mallintaminen HCI-alueella alkanut 1970-luvun loppupuolella (Phyllis Reisner 1977, 1981 (BNF); Embley 1978; Ledgard & Singer 1978)
Mallinnusohjeistoa (Pressman 1987) Kuvauksessa/mallinnuksessa käytettävän esitysmuodon ja sisällön on oltava relevanttia suhteessa tarkasteltavaan ongelmaan Kuvauksessa esitettävän aineiston on oltava kerroksittaista: yleisestä yksityiskohtaiseen tietoon Kerrallaan käytettäviä kuvaustapoja ei saa olla liikaa ja niiden on oltava yhdenmukaisia Kuvausten on oltava helposti muokattavissa (ajatuksena (Reisner 1981): yksinkertaisempi kuvaus johtaa yksinkertaisempaan käyttöliittymään ja helpompaan käyttöön)
Käyttöliittymäsuunnittelun taustamallit
GOMS Goals, Operators, Methods, Selection rules (Card, Moran & Newell 1980) Goal (edit document insert word) a symbolic structure that defines a state of affairs to be achieved, and determines a set of possible methods by which it may be accomplished Operators (press up arrow key, move hand to mouse) elementary motor or information-processing acts whose execution is necessary to change any aspect of the user s memory or to affect the environment Methods (indent with tab, delete with backspace) describes a procedure for accomplishing a goal. The description of the procedure is cast as a continual sequence of goals and operators, with conditional tests on the contents of the user s immediate memory and on the state of the task environment Selection Rules ( indent with spaces vs tab ) When a goal is attempted, there may be more than one method available to the user to accomplish the goal. The choice of method is governed by selection rules which depend upon the features of the task environment
GOMS - Huomioita Käyttötapoja tehtäviin kuluvan ajan ennustaminen tehtävien suoritustapojen/-reittien ennustaminen Huolehdittava sopivasta tarkkuustasosta, granulariteetistä! Tyypillinen tekstinkäsittelytehtävä: tavoitteita 1-20; operaattoreita 1-13; metodeja 4-6; valintasääntöjä 1-4 Käyttöalue varsin rajoitettu, sopii lähinnä vain asiantuntijakäyttäjien toiminnan tarkasteluun Olettaa varsin virheettömän käytön
Seven Stages of Action (Norman 1986) System Model - functionality Evaluation Interpretation Perception Physical system, state and environment Mental Models - Background knowledge - Experience Evaluation Goals Execution of actions Intentions Action specification Execution
Foley & van Dam (1990) Conceptual level user s mental model of the interactive system Semantic level meanings conveyed by the user s command input and by the computer s output Syntactic level defines how the units (words) that convey semantics are assembled into a complete sentence that instructs the computer to perform a certain task Lexical level deals with device dependencies and with the precise mechanisms by which a user specifies the syntax
Käyttöliittymäsuunnittelun perinteiset kuvauskielet
BNF Bachus Naur form Monien kuvauskielien taustalla <Puhelinluettelomerkintä> ::= <Nimi> <Puhelinnumero> <Nimi> ::= <Sukunimi>, <Etunimi> <Sukunimi> ::= <string> <Etunimi> ::= <string> <string> ::= <char> <char><string> <char> ::= a b c d e f g h i j k l m n o p q r s t u v w x y z å ä ö <Puhelinnumero> ::= (<suuntanumero>) <liittymänumero> <suuntanumero> ::= <digit><digit> <liittymänumero> ::= <digit><digit><digit><digit><digit><digit><digit> <digit> ::= 0 1 2 3 4 5 6 7 8 9
TAG Task Action Grammar (Reisner 1981 action ; Payne & Green 1986 task ) liikuta kursoria a) merkin verran b) sanan verran c) kappaleen verran eteenpäin task[direction, unit] -> command[unit], symbol[direction], command[unit=char]-> command[unit=word]-> CTRL command[unit=paragraph]-> ALT symbol[direction=forward]-> Nuolinäppäin_oikealle symbol[direction=backward]-> Nuolinäppäin_vasemmalle tuottaa a) + Nuolinäppäin_oikealle b) CTRL + Nuolinäppäin_oikealle c) ALT + Nuolinäppäin_oikealle
UAN User Action Notation Ongelmia suorakäyttöliittymien mallintamisessa Hiiren liikuttaminen: ~; objekti: [obj] (esim [icon]) Hiiren painallus: Mv; hiiren nosto: M^ Korostus/valinta:! (esim icon!) ~[file] Mv file! ~[x,y]* outline(file) > ~ ~[trash] outline(file) > ~, trash! M^ erase(file), trash!
Oliopohjainen mallinnus: Skenaario Skenaariossa kuvataan, mitä käyttötilanteessa tapahtuu Skenaario voi kuvata nykyhetkeä tai tulevaisuutta, painotetusti sitä ehkä kuitenkin käytetään tulevaisuutta kuvattaessa Skenaario esitetään vapaamuotoisena tekstinä Skenaariosta voidaan johtaa tarvittavia asioita: tietorakenteet, tietovirta, vaadittavat objektit Skenaarion pohjalta voidaan tuottaa rakenteeltaan formaalimpia kuvauksia
Nykyisiä kuvaustapoja
Oliopohjainen analyysi Tuotetaan vapaamuotoinen kuvaus ratkaistavasta asiasta Alleviivataan kaikki substantiivit (=objektit). Alleviivataan kaikki adjektiivit (=ominaisuudet) Alleviivataan kaikki verbit (=operaatiot)
Skenaario: kokoonpanolinja Kokoonpanolinjan työntekijä saa eteensä paletilla olevat tuotteen peruskomponentit. Hänen tehtävänään on kokoonpanna tuote lisäämällä siihen tuotetilauksessa olevat osat. Työntekijä tunnistaa tilauksen paletilla olevasta viivakoodista, jonka hän lukee viivakoodinlukijalla.
Use Case > UML Unified Modeling Language 1990 luvulle tultaessa Jakobson kehitti use case - kuvaukset use case ja UML kuvausten pohjaksi tarvitaan usein skenaariot UML:n käyttöliittymää sivuavat mallit: use case, sequence, collaboration, class, operations, attributes, relationships taustalla mm. ER-mallit, workflow-kuvat, tietovirtakaaviot
Use Case modelling WHAT our system will do at a high-level and with a user focus for the purpose of scoping the project and giving the application some structure Use Cases are an informal and imprecise modelling technique Use Cases are used primarily to capture the high level user-functional requirements of a system Use Cases are used to define the fundamental structure of our application
Use Cases are/do not Use Cases cannot usefully be used to capture nonfunctional requirements Nor can they usefully be used to capture "internal" functional requirements Use Cases are not a functional decomposition model not intended to capture all of the system requirements do not capture HOW the system will do anything
Use Case -mallinnus http://pigseye.kennesaw.edu/~dbraun/csis4650/a&d/uml_tutorial/use_ case.htm http://www.zoo.co.uk/~z0001039/pracguides/pg_use_cases.htm
Käyttöliittymän rakentamisen mallit (Constantine & Lockwood 2000)