AMS-case. Eksemplifisering av modellbasert. tilnærming til design av brukergrensesnitt

Størrelse: px

Begynne med side:

Download "AMS-case. Eksemplifisering av modellbasert. tilnærming til design av brukergrensesnitt"

Stine Madsen
7 år siden
Visninger:

1 AMS-case Eksemplifisering av modellbasert tilnærming til design av brukergrensesnitt

2 Domenemodell Sentrale begreper og relasjoner Utgangspunkt for både oppgave- og dialogmodeller Mange muligheter kan undersøkes basert på modellen og kunnskap om generelle handlinger

3 Person-begrep Innfører Person som generalisering av Owner Staff Generelle og spesifikke egenskaper navn, adresse, etc. rollespesifikke egenskaper Naturlig sammenkobling til eksisterende adm.systemer, i toppen av generaliseringshierarkiet Hva slags type og struktur har de ulike attributtene? name/navn = fornavn [mellomnavn] etternavn? postal address!= address!= billing address? personnavn!= dyrs navn mange detaljer må avklares i designprosessen

Person-komponent Form/property sheet for visning og innfylling av verdier Typespesifikke felt for hvert attributt Felles attributter samles og håndteres likt Tekst og ikoner brukes

4 Person-komponent Form/property sheet for visning og innfylling av verdier Typespesifikke felt for hvert attributt Felles attributter samles og håndteres likt Tekst og ikoner brukes for markerer sub-typer vindustitler, gruppebokser, osv. ikoner i lister og hierarkier Spesifikke attributter (owner, staff) skilles fra felles vha. åpenrom streker gruppebokser, other...

5 Person-interaktor I en applikasjon finnes det som regel mange varianter av funksjonelt like komponenter Person-elementer kan presenteres på mange måter: kun navn eller alle attributter tabbed visning med kategoriserte detaljer viktigste attributter og Detaljer... -knapp Trenger notasjon for en komponents funksjon

6 Person-interaktor Notasjon for å beskrive abstrakt komponent-struktur Generell struktur for visning av verdier visning og editering Person-element mappes til attributter vha. funksjoner Nye verdier settes også vha. funksjoner

7 Integer-interaktor Input av heltall Basert på strenginput Parsing og unparsing Alternativer

8 Interaktorer og datatyper Mange datatyper har sin standardkomponent boolean: checkbox integer: slider string: tekstfelt Color: fargesirkel Date: kalender Mange varianter finnes imidlertid Alternativ å konstruere en selv, fra de andre

9 Spesialisert Integer-interaktor Input av heltall i begrenset intervall generell innfylling knapper for å øke eller minke verdi minimum eller maksimum

10 Tre bilder av system og UI 1. Tynt lag mellom bruker og system 2. Komponent som formidler data mellom system og bruker 3. Brukerens representant mot systemet

11 Strukturer Generelle strukturelle mønstre har sine konvensjoner Relasjoner, mapping fra ett objekt til 0-1, hvert objekt har 0 eller 1 relatert objekt 0-n, 0 eller flere relaterte objekter 1-n, 1 eller flere relaterte objekter Vær varsom med strenge begrensninger i GUI, dvs. slakk på domenekrav

12 Strukturer forts. Eksempel på domenebegrensning: en eier må ha minst ett dyr/animal et dyr må være eid av noen en avtale må være knyttet til et dyr Rimelig begrensning i domenemodell ellers er ikke en eier en eier kan ikke ringe til et dyr, atså må ha eier for å legge inn kontaktinfo Brukergrensesnitt stiller andre krav ufullstendige modeller må ofte tillates unngå feil bruk, f.eks. legge inn dyr som eier, for å kunne legge inn kontaktinformasjon

13 Eksempel-scenario Telefonen ringer Hei! Hva kan jeg hjelpe deg med? Jeg tror kjeledeggen min har vondt i halsen, kan jeg stikke ned til dere om en halv time? OK, men hva slags dyr gjelder det?...<klikk>... Eier kan ikke legges inn, siden navn mangler Dyr kan ikke legges inn, siden eier og navn mangler Avtale/appointment kan ikke legges inn, siden dyr mangler Slakke på krav om navn, nødvendig eier og kobling mellom avtale og dyr

14 Domenemodell!= UI-modell!

15 UI-orientert domenemodell Færre begrensninger Mer egnet for design av fri dialog Ingen tvangstrøye for brukeren

16 Relasjoner forts. Kardinalitet og oppgave avgjør interaksjonsobjekt kardinalitet avgjør ofte hvor praktiske ulike interaksjonsobjekter er i bruk enkle oppgave kan være input og output, hvor input kan inkludere valg blant alternativer 0-1, hvert objekt relateres til 0 eller 1 andre output/visning: som enkeltfelt input/redigering: valg av ett objekt fra sett av alternativer vha. listbox eller dropdown listbox mulighet for kategorisering, hierarkier og søk

17 Objekt-interaktor med valg Relatert objekt velges ofte blant mange kandidater Output av kandidat-sett Input av objekt fra settet Inkluderer ofte spesiell visning av valgt objekt

18 Oppgave Hvordan uttrykk flervalgsfunksjon? Output: Sett av kandidater Input: Subsett av kandidat-sett

Like dokumenter

AMS-case forts. Eksemplifisering av modellbasert. tilnærming til design av brukergrensesnitt

AMS-case forts. Eksemplifisering av modellbasert tilnærming til design av brukergrensesnitt Domenemodell Sentrale begreper og relasjoner Utgangspunkt for både oppgave- og dialogmodeller Mange muligheter