MMI-forelesninger Overordnet bilde av mennesker (aktører), oppgaver, informasjon og systemer (verktøy) Oppgave- og Dialogmodellering Mål vise sammenheng mellom IS og UI-design oversikt over UI-modellering synliggjøre nytten av modeller
Tentativ tidsplan Uke 12 Mandag: Introduksjon Oppgave- og Dialogmodellering Artikkel Torsdag: Artikkel forts. Uke 13 Mandag: Modellering av AMS-case Torsdag: Case forts. IFIP-case Uke 14 Mandag: IFIP-case forts.
People use information and tools to perform actions Information People Actions Tools
The world is complex People Information Actions Tools
Differentiation and fragmentation Sociology, Psychology People Information Semantic data modelling Functional analysis BPR Actions Tools Workflow CSCW Systems engineering Task-based UI design
Boundaries are difficult and interesting People Information concepts, vocabulary Actions oordination, cooperation usability Tools constructiv composition integration, tailoring requirements vs. design
Klassifisering av (design)representasjoner Perspektiver (problem vs. solution) Granularitet (relativ) Formalisering formalisering perspektiv? granularitet
Bruk av (design)representasjoner Prosess innebærer ulike bevegelser i representasjonsrommet Representasjonsform tilpasses bruksbehov og deltagere formalisering perspektiv granularitet
UI-modellering: historie Høynivå-programmering programmeringsverktøy, GUI-toolkits og rammeverk User Interface Management Systems (UIMS) egne konsepter, programmeringsverktøy/-omgivelse, kjøretidssystem UI-modellering deklarative modeller generering av ferdig grensesnitt Oppgave(modell)basert brukergrensesnittdesign modellering av oppgaver trinnvis forfining av modeller til kjørbart system editering og analyse vs. generering
UI modelling - perspectives Task models How are tasks actually performed? What is the user supposed to be able to do? Dialog model What functional (abstract) UI elements do we need? How are they composed? Look & feel model How are objects and actions visualized and laid out? What are the interaction details
SE and UI model relations Process/ dataflow/ workflow STM/ Petri Nets Concepts/ objects/ data What is done? How is it performed? How is information represented? Task Dialog Presentation
Dataflow vs. tasks order deliver shelves book/loan DB put back receive book pile
Workflow vs. task modeling A1 Write travel report Actors Tools eturned from travel A1.1 Write report DETAILS REPORT A1.2 Provide details Simple Composite Role Roles Person Group Software Software suite Software product Suite product User App FINAL Secretary Abstract Concrete Abstract Concrete RE PORT OBJECTIONS dataflows A1.3 Sign report FINAL RE PORT Adm. A1.1 Write report User App Manager Make initial report Add details Handle objections U SER S UPP A PP Request details Receive details Fill in details Submit report Receive objections React Secretary Secretary Manager Manager
Oppgaveanalyse Kjært navn har mange betydninger trekke ut og representere brukeroppgaver forutsi problemer og evaluere mot brukbarhet og funksjonelle krav forutsi ytelse og måle kompleksitet måle læring og overføring av erfaringer Utgangspunkt i ergonomi, psykologi og SU Oppgave: målrettet handling på mange nivåer prosess, aktivitet oppgave aksjon, operasjon
Oppgaveanalyse forts. Begrepsavklaring: Goal/mål = tilstand som brukeren ønsker å oppnå Task/oppgave = set av handling som oppfattes som nødvendig for å nå et mål, gitt et sett av hjelpemidler Action/aksjon = atomisk handling uten problemløsning eller kontrollstruktur GOMS - Goals, Operations, Methods, Selection Oppgavestruktur hierarkisk dekomposisjon sekvensiering og valg
HTA plan 0: 1-2, deretter 2, 3, 4; 6 iht.krav; 5 hvert 15 min, etter større endringer, før utskrift og avslutning; 7 når ferdig 0brukeWP 1starte 2tekst 3 formattere 4 redigere 5lagre 6printe 7 avslutte plan 3: iht. krav plan 3: iht. krav aste hente paste tegn avsnitt dokument dekomponeres Overordnet dekomponering Detaljeringsnivå og granularitet Lovlig utførelser Kognitive prosesser
ruk av telefon... alternativer Bruke telefon sekvens overlappende Ringe ut Ta imot Samtale veksling nr? betinget Lagre nr. Summetone nr? Finne nr. nr flyt Taste nr. Notere Huske
Task modelling Often combines functions and concepts Two major formalisms: processes, dataflow and function networks hierarchical decomposition with sequence constraints Used both for understanding current work modes and practice specifying how work should be done Taskmodellingis work design! Easier to do in parallel with dialog and look & feel design
TaskMODL example 1 Read email Mailbox {} In conceptual model User Email client Mailboxes Out 1.1 Get new email In task structure messages 1.2 Manage email messages message Manage message Message A mailbox contains messages User performs Read email using Email client The current set of mailboxes provides the task context Get new email uses In mailbox and provides Manage email with set of messages Read message Transfer message Manage email implies acting on each individual message in the input set
TaskMODL features Hierarchical task structure of super- and subtasks Resources are preconditions for performing tasks: actor hierarchy model users, both abstract and concrete information modelled in CML from IDI references to dialog elements provide design support Explicit sequence constraints Flows: Control flow = sequence constraint Data flow = control flow + resource binding
Actors Abstract Types Actor Concrete composite/ simple Typical structure Group Person 2 Role A Role B Role C Composite Role Person 1 Role D
Sequence relations constraints for the super-/subtask part-of relation Aggregation Order Sequence Choice cardinality provides additional constrains a b c d a b c d a, b, c a, b, d c, a, b d, a, b c or d can in addition occur in between a and b
The choice relation: conditional tasks, i.e. an explicit deterministic condition method selection, i.e. the subtasks goals are equivalent and the choice will depend on e.g. resource constraints choice of goal, i.e. the subtasks goals differ and the choice will depending on context generalisation/specialization, i.e. abstract and possibly incomplete tasks are defined
Task hierarchy 1 Use Eudora 1.1 Make new Message 1.2 Reply to Message 1.3 Forward Message Author Message Provide Headers Author Body Recipient Subject
Oppgavemodellering og design... Oppgavemodellen hjelper utvikleren å: få oversikt over alt brukeren ønsker å gjøre beskrive oppgavestrukturen identifisere sammenheng mellom oppgaver og informasjon Design omfatter bl.a.: identifisere egnede metaforer og interaksjonsstiler knytte oppgaver til interaksjonsform å konstruere et helt brukergrensesnitt fra tilgjengelige deler å evaluere design opp mot brukere og oppgaver
...oppgavemodellering og design Oppgavemodellen beskriver: hvordan aktiviteter henger sammen hierarkisk begrensninger på sekvens informasjonsflyt generelle og spesifikke egenskaper ved oppgaver Design omfatter bl.a.: å identifisere nødvendige dialogelementer å aktivere disse på passende tidspunkt å velge egnede dialogelementer Merk at metaforer og interaksjonsstilen også legger sterke føringer på hvilke oppgaver som er meningsfylt!
..bruk av telefon Bruke telefon Hva betyr dette for design? Ringe ut Ta imot Samtale nr? Lagre nr. Summetone nr? Finne nr. nr Taste nr. Notere Huske finne og taste inn nr. utføres alltid når en ringer ut summetone avbryter inntasting lagring av nr. er aktuelt under hele samtalen, ikke bare initielt designvalg muliggjør vurdering av ergonomi
ppgave og dialog: konseptuell design shop look around fill caddie decide caddie content Recipe Look around Recipe Fill caddie Decide caddie content Goods Caddie Sent order
Window allocation: Physical design hierarchy message list single message
Presentation model Mapping from abstract to concrete interactors Look and feel of interaction elements Layout of interactors in windows Life cycle, visibility and activation Usually informal Name: Address: OK
Analytisk metode Gjennomgå oppgavemodell fokusere tenkt system mot relevant og realistiske oppgaver identifisere rollen brukergrensesnitt/system har ift. oppgaveutførelse Konstruere dialogmodell bryte ned oppgaveutførelsen i dialogtrinn spesifisere nødvendig informasjon for bruker og system, mao. output til brukeren og input til system identifisere system -funksjoner og operasjoner detaljere dialogspesifikasjon Look & feel oversette dialogelementer til native grensesnittelementer