MMI-sammendrag fra eksamener

Transkript

1 MMI-sammendrag fra eksamener Hva er MVC MVC er en software arkitektur som muliggjør å skille datalaget fra presentasjonslaget i en applikasjon. I Swing er View og Controller ofte sydd sammen til GUI komponenter (slik som JButton, JList ). Dataen til applikasjonen legges i modellobjekter. Disse kobles til View-Controller. Når en verdi endres i et View, er det View-ets ansvar å oppdatere modellen sin. Endringer i modellen propageres så til alle andre Views som benytter den samme modellen. På denne måten vil tilstanden til alle Views til enhver tid være oppdatert, fordi de deler den samme datamodellen. Det generelle kravet er observerbarhet, dvs. at alle relevante data kan hentes ut og evt. endres og at en kan registrerer lyttere og få beskjed når dataene endres. I praksis betyr dette at en må ha et komplett sett metoder for å hente ut data, relevante metoder for å endre dem og metoder for å registrere lyttere. ISO 13407:210 Forstå og spesifisere brukssammenheng --> karakteriser brukerne beskrive brukernes oppgaver beskriv brukerens miljø Spesifisere bruker og organisasjonens krav --> Identifisere relevante brukere sette tydelige menneske-sentrerte mål og målbare kriterier godkjennes av brukere/representanter utvikle designløsninger --> utvikle konkrete(e) prototype(r) presentere designløsninger for brukerne benytte input for å lage forslag til løsninger evaluere design mot krav [restart] ha en evalueringsplan bruke evaluering som input i designprosessen undersøk om målene er nådd Standarden sier at man først skal planlegge. Deretter forstå brukeren og brukskonteksten. Videre skal man spesifisere krav og til slutt lage prototyper og evaluere. Hele prosessen itereres til vi har et ferdig produkt. ISO Definerer brukervennlighet (usability) som: Anvendbarhet, effektivitet og subjektiv tilfredsstillelse for spesifikke brukere, ed spesifikke mål, i spesifikke omgivelser. Anvendbarhet: Sier noe om i hvilken grad brukeren er i stand til å få utført de oppgavene som produktet skal tilby. F.eks: antallet oppgaver brukeren får til i en brukbarhetstest. Vi registrerer også opplevde problemer, ettersom det kan gi en pekepinne på problemer ved grensesnittet som kan føre til nedsatt anvendbarhet. Kan måles med antall oppgaver gjennomført uten hjelp Effektivitet: Sier noe om hvor mye det krever av brukeren for å få gjennomført oppgavene. Dette måles i medgått tid til oppgavene. Kan måles kvantitativt som tid brukt pr oppgave.

2 Subjektiv tilfredsstillelse: Sier noe om brukerens subjektive tilfredsstillelse og oppfatning av produktet. Kan måles med f.eks SUS-skjema. Det kan ofte være nødvendig med et intervju i tillegg, ettersom dette kan avdekke verdifull informasjon om brukerens subjektive mening. Kan måles med et SUS-skjema (kvantitativt) Kan måles ved et intervju av testperson (kvalitativt) Standarden sier av brukervennlighet skal måles for spesifikke brukere, med spesifikke mål, i bestemte omgivelser. Dermed er brukervennlighet kontekstavhengig. Viktig å gjøre testene realistiske! Visibility of status Brukeren skal aldri være i tvil om statusen til systemet Gjelder oppgaver og tilstand i prosess Eneste muligheten for brukeren å skjønne hvilken tilstand maskinen er i (ulikt fysiske prosesser) F.eks: progress bar, handlekurv Recognition rather that recall Mennesker er bedre på gjenkjenning enn korttidshukommelse Bruk ikoner og menysystemer istedet for kommandoer! F.eks: "bold tekst knappen" er skrevet med en tykk bokstav FEIL: unix kommandoer må pugges Gestaltprinsippene psykologisk forskning i 20de århundre synsinntrykket blir tolket før bevissheten helhet istedet for enkelhet ting som ligger i nærheten av hverandre blir "i grupper", "samme farge betyr samme gruppe" stor betydning for layoututvikling tre knapper i nærheten av hverandre bør bety det samme. ikke sett [bold] og [delete] inntilhverandre F.eks: i Word ligger "italic","underline" og "bold"-knappene samlet; alle er tekstmanipulerende. På fasttelefoner ligger tallknappene i en gruppe, imens [ringe] og [legge på] knappene ligger adskilt Universelt design Systemet skal fungere for de fleste typer mennesker uavhengig av fysiske, kognitive og kulturelle egenskaper. Det er med andre ord designet for å kunne brukes universelt av brukergruppene GUI-interaksjon Direktemanipulasjon (Drag & drop) krever ingen ekstra elementer på skjermen. dermed sparer vi skjermplass. Kan være effektivt enkelt å benytte og lære ikke farlig å prøve/feile

3 ofte dårlig afforance! Man må lære brukeren hvordan man kan manipulere krevende å programmere erfarne brukere vil helst benytte andre metoder (dette går for sakte) ikoner Lett å forstå "knowlegde in world" - se det du vil vite (på skjermen) tar mye plass menyer er en standard for brukeren -> consistency "alle programmer" bruker det "knowlegde in world" krever plass krever ofte flere brukerinteraksjoner (museklikk) - kan veies opp med shortcuts context meny (høyreklikk) frigjør mye plass - trenger verken menyer eller ikoner krever mer av brukeren tar mye tid dialogboksen kan skjule bakgrunnen kan vær dårlig affordance Schneiderman Lag konsistente brukergrensesnitt Vi må sørge for at funksjoner som utfører den samme oppgaven, ser lik ut i alle deler av grensesnittet! Slett bilde og slett dokument bør ha samme type knapp Gi shortcuts til brukeren erfarne brukere krever av at software skal kunne brukes effektivt, og har ikke tid til å rote rundt i menyer. Det er et pluss for den erfarne og ubetydelig for den novise Gi informative tilbakemeldinger Dette er spesielt viktig for novise og eldre brukere! Prøv å forhindre feilsituasjoner i programmet, men hvis noe går galt så må det returneres en informativ tilbakemelding FEIL: "ERROR 1600" (hentet fra iphone) RIKTG: "itunes were not able to establish a USB connection to your iphone. Please retry your operation" Tydelige arbeidssteg i dialoger Vis brukere hvilken status maskinen er i, til enhver tid! Det er den eneste måten brukeren har til å tilegne seg denne informasjonen. Unngå feil og gi enkle tilbakemeldinger Se over. La det være mulig å angre! I software hvor brukerene er noviser/eldre, er det spesielt viktig at

4 brukeren skal kunne angre på handlinger! For eksempel: slett aldri data direkte fra databasen med en gang La brukeren ha kontroll Ikke gjør som Windows! Office Word sin binders var en flopp! Eldre brukere kan falle helt av lasset Ikke tving brukeren til å huske kommandoer og operasjoner la viktige valg alltid være synlig på skjermen og ikke bortgjemt ("knowledge in world") Designprosess innhente spesifikasjoner dybdeintervju få vite "context of use" dybdekunnskap om brukerne rekker kun ut til et fåtall brukere papirprototyper med enkle scenarier se hvordan brukeren vil interagere/bruke med systemet få subjektive tilbakemeldinger tilbakemeldingene kan summere til generelle krav Man får tilbakemelding på konkrete forslag. Ofte lettere å kritisere/gi tilbakemelding på "uferdige" utkast Det er mange stemmer og meninger som kan komme frem, dermed blir det lett å overse noen For få brukere wizard of Oz gjennomføre wizard of Oz uformelt, logget/filmet intervju Billigere enn en kjørende prototype/alfa Gir tilbakemelding på brukervennlighet og på konkrete løsninger Det blir en kunstig situasjon fordi prototypen er så ufullstendig Prototyper: Low fidelity Enkle prototyper uten detaljer og interaksjonsmuligheter. Ofte laget av papir på en skisseaktig måte. FORDEL: Siden den ser så "uferdig ut" er det lett for brukeren å gi tilbakemeldinger Det tar kort tid å produsere og er billig. Man trenger ikke å sette en programmerer på oppgaven. Mangler detaljrikdom. Kan ikke simulere funksjoner ved programmet

5 Krever mye innlevelse fra brukeren/testpersonen High fidelity Kompleks prototype med mer detaljer. Laget på PC og ser ut som et ferdig utkast FORDEL: Gjør det mulig å teste brukergrensesnittet uten å programmere det fullstendig ULEMPE Siden produktet ser så ferdig ut, kan testpersoner kvie seg for å kommentere på grensesnittet koster mye å lage