Mats B. Pettersen Jøran B. Sandberg 25.09.2002 SIF80AP From Abstraction to Realization in UI Designs: Abstract Prototypes Based on Canonical Abstract Components Mats B. Pettersen Jøran B. Sandberg 25.09.2002 SIF80AP

Abstrakt - Konkret Abstrakt Konkret Konstruksjonsspek. Oppgavemodell Innholdsmodeller Oppgaveorientert design GUI design Innholdsnavigering Anvendelsesmodell Papirprototyp Idé Når følge en metodikk: Overgang fra halv-formelle ting til andre halv-formelle ting er ofte greit. MEN i hci er det ofte litt mer magic – kan ende opp i mange løsninger når en går fra abstrakt til konkret.. Ingen enkel rettet vei.

Abstrakte Prototyper GUI-tools: kjapt og gæli Holder fokus på innhold, organisering og funksjonalitet uavhengig av layout, utforming og oppførsel. GUI-tools: kjapt og gæli Abstrakte prototyper: mer gjennomtenkt produkt Abstrakt prototyping brukes som teknikk for å unngå å lage fancy prototyper (konkrete) som ser bra ut, men som ikke avdekker svakheter i det underliggende designet. Ved å holde tankegangen på det abstrakte nivået ser man bedre strukturelle svakheter i systemet.

Abstrakte Prototyper Oppgavemodell - generelt hva som skal gjøres Sammenknytter konseptuelt gap mellom Oppgavemodell - generelt hva som skal gjøres - ingen designdetaljer - typisk use-case, kravspek -> Realistisk prototype - detaljert beskrivelse av systemet - typisk skisse over skjermbilde, papirprototyp o.l.

Abstrakte Prototyper Innholdsmodell Navigasjonskart Består ofte av to deler: Innholdsmodell Representerer innholdet til brukergrensesnittet. En innholdsmodell er en samling ”views” bestående av de nødvendige (abstrakte) komponentene som trengs for å utføre ulike oppgaver innenfor hvert view. Navigasjonskart - Utfyller innholdsmodellen og kobler de ulike views’ene sammen. I prasksis har man et ark per view, og postitlapper for hver komponent.

Abstrakte Prototyper Wire-frame mockups variant av abstrakt prototyping som viser relativ størrelse og posisjon til elementene. fargekoding brukes for å vise prioritet eller type element. Populær for web-app byggere

Abstrakte Prototyper Abstrakt layout diagram annen variant av abstrakt prototyping. viser også relativ størrelse og posisjon til elementene. Lo-fi prototyp Vis ikke nøyaktig usende – bare størrelse og plassering

Ulike prototyper Abstrakt Konkret Hi-fi papirprototype (realistisk og detaljert) Low-fi papirprototype (grov skisse) Innholdsmodell (helt abstrakt) Abstrakt layoutdiagram Wireframe mockup Innh.mod: Ark og postit Wireframe/Abstr. : nettopp tatt Low-fi: grov skisse Hi-fi: realistisk og detaljert prototyp

Abstrakte problemer Vanlige novice-problemer ved disse modelleringsteknikkene Vanskelig med navngiving i abstrakte termer Vanskelig å skille tools fra materials Vanskelig å mappe abstrakte komponenter til fysiske komponenter Vanskelig å lage skjermlayouts og andre UI-kontekster fra abstrakte ”views” Navngiving ska vær abstrakt før ikke å lægg føringe. Tools/mat: designere uten særli erfaring veit ikke om en komponent ska vær modellert som en aktiv eller passiv elemnt. (editable display field: aktivt tool eller passivt material) Uten konsistens i navngivingen -> kan få modell uten kobling til verken fysisk design eller andre modeller.

Semantisk brobygging Broen mellom oppgavemodell og abstrakt modell er rimelig grei skuring. Ofte en-til-en mapping. Bare å jobbe seg gjennom task-case step by step -> se figuren Grunn til ikke grei skuring: en del aspekter ved både utseende og oppførsel gjenstår å fastsett Mellom abstrakt modell og et godt endelig design kan det derimot være vanskelig å finne en slik enkel semantisk mapping. Mange avgjørelser og tradeoffs å gjøre.

Semantisk brobygging (2) En abstrakt innholdsmodell er gjerne for nært oppgavemodellen og for langt unna det endelige designet. Abstrakt Konkret Abstrakt innholdsmodell Endelig design Oppgavemodell Trenger bedre bro!

Bedre brobygging Selv om abstrakt prototyping har en del ulemper, har studier vist at det finnes et klart behov for modellering mellom oppgavemodellen og det endelige designet. Det man trenger er en modelleringsvariant av abstrakt prototyping som ligger litt nærmere det endelige designet. Denne må være: enklere og mer naturlige å utvikle. lettere å oversette til et faktisk visuelt interaksjonsdesign. enklere å koble opp mot andre modeller gjennom domenemodellen.

Kanonisk abstrakt prototyping Bruk av standardiserte, abstrakte komponenter kan være med på å løse problemene med brobyggingen mellom abstrakt og konkret. -> Kanonisk abstrakt prototyping Kanonisk prototyping er en metodikk utviklet for dette, der man bruker et ”toolkit” for å prototype layout, størrelse og posisjon til kanoniske komponenter på en måte brukere kan forstå. Ikke ønskelig med kokebok – men en standard måte å beskrive problemet på

Kanoniske abstrakte komponenter Gir et standard ”toolkit” av abstrakte komponenter. Kjernesett av grunnleggende, generelle abstrakte komponenter Utvidelse av 1 med litt mer spesialiserte komponenter Special-purpose komponenter som kan være nyttige materialer e en spesialisering av en generell container (holder/innholds”boks”) tools e en spesialisering av en generell operation/action

Materialer Der er tre basismaterialer: Og to til (ekstra): Container Element (Ett element) Collection (Samling av elementer) Og to til (ekstra): Melding/varsel Akseptor (aktiv container) materialer e en spesialisering av en generell container (holder/innholds”boks”) Konvensjonell navngiving er å bare bruke navnet til innholdet – dvs. det som skal representeres i materialet.

Tools Operasjoner og handlinger er to typer abstrakte tools. Initiate/start Terminate/quit Operasjoner: Select Create Delete Modify Move Duplicate Aux.tools: Go/link/drill Perform (w/return) Toggle tools e en spesialisering av en generell operation/action Operasjoner: Gjør noe med materialer Handlinger: Trigger en handling. Setter i gang ting. Navngiving for tools er konvensjonelt å navngi handlingen som skal gjøres, e.g. ”(Do) Symbol checking”.

Tools (2) Slik det ser ut i praksis Vanligvis er diagram til venstre mest brukbare Til høyre : for store (eller web-baserte) prosjekter Legg merke til nøsting Tekstlig: Anbefales for web-baserte eller store prosjekter Ved bruk av tools i modelleringen kan det være greit at det kommer klart fram, enten grafisk eller vha. tekst, hvilke materialer verktøyet jobber mot.

Å designe fra kanoniske prototyper To parallelle aktiviteter: Visuelt design Utvelging av riktige komponenter for å realisere modellen med de kanoniske komponentene Layouten av de visuelle komponentene Interaksjonsdesign Utvelgelse eller konstruksjon av interaksjonsmetodene Beskrive den påkrevde oppførselen til grensesnittet Organisering av interaksjonssekvenser mellom ulike views eller kontekster Bruken av kanoniske prototyper - Bra for både uerfarne og erfarne designere Visuelt: - konversjonelt vil hver komponent realiseres vha widgets (tilgjengelig i toolkit) - bør kartelegge hvilke widgets som passer til de forskjellige komponentene Interaksjonsdesign - når laget det visuelle er stort sett int.design klart - interface.komponentan bestem ganske mye a interaksjonsdesigne - layout bestæm workflow - må værifiseres mot oppgavecasean (iterativt) Gjenbruk Når du har de kanoniske komponentene kan en bare prøve og feile med de forskjellig gui-som tilvarer dem..

Eksempel på bruk Flere mulige designløsninger fra en abstrakt prototype: 2. Arne Sølvberg 1. Hallvard Trætteberg 3. Dag Svanæs Editerbare sekvensnummer Arne Sølvberg Hallvard Trætteberg Dag Svanæs Flytting av elementer opp/ned vha piler Samme som han gikk gjennom på tavla forrige gang Dingsen til venstre ER den kanoniske prototypen Item: collection materiale Reorder: modifyer tool Legge til eller fjerne elementer fra en hovedliste Arne Sølvberg Hallvard Trætteberg Dag Svanæs Add -> <- Remove Hallvard Trætteberg Arne Sølvberg

Eksempel på bruk (forts.) Interaksjonsdesign. For forrige eksempel kan man tenke seg flere ulike interaksjonsmåter: Klikk for å velge kilde-punkt og mål Drag-and-drop Editere sekvensnumre Klikk på ”flytt opp” / ”flytt ned” Det kan være gunstig å kombinere flere av disse interaksjonsmåtene – for å passe både novisebrukere og mer avanserte brukere.

Konklusjoner Bruk av abstrakte layoutdiagrammer vha. kanoniske abstrakte komponenter funker for å strømlinjeforme og effektivisere usage centered design. Kanoniske prototyper ligger nærmere det ferdige produktet enn hva abstrakte modeller gjør – men uten å legge for sterke føringer for det visuelle designet og implementasjonen av brukergrensesnittet. Usage centered design = bruksorientert design