Affordance

En gjenstands affordance er den kvaliteten som gjør at vi kan utføre en handling på den. En knapp signaliserer f.eks at vi kan trykke på den, og en colaflaske signaliserer at vi kan drikke den. Vi har tre former for affordance:

• Fysisk: Utformingen til et objekt signaliserer ofte hva man kan gjøre med objektet. En colaflaske er formet slik at hånden kan gripe rundt den.
• Kulturelt: Konvensjoner som læres.
• Gitt av konteksten eller omgivelsene. ("Nei, på Mac gjør vi det sånn her ..")

Jacob Nielsen - "10 Heuristics"

1. Visibility of system status
   • Systemet skal alltid vise brukeren hva som foregår i maskinen
2. Match between system and the real world
   • Snakk brukerens språk. Begreper, ord og fremstillingsmåte som brukeren forstår
3. User control and freedom
   • La brukeren ha kontroll, implementer "angre" på alle nivåer
4. Consistency and standards
   • Konsistens i grensesnittet, følg retningslinjer for plattformen du bruker
5. Error prevention
   • Lag systemet slik at minst mulig feil forekommer (fleksibilitet)
6. Recognition rather than recall
   • Brukeren skal ikke behøve å huske informasjon mellom dialoger. Instruksjoner skal være synlige når de trengs
7. Flexibility and efficiency of use
   • Gi avanserte brukere snarveier ol.
8. Aesthetic and minimalist design
   • Fjern alt som ikke har en hensikt
9. Help users recognize, diagnose, and recover from errors
   • Hjelp brukeren dersom det oppstår feil
10. Help and documentation
    • Lag et godt hjelpesystem

Don Norman - "The Design of Everyday Things"

Don Normans designprinsipper fungerer som tommelfingerregler eller en sjekklistefor å bidra til økt brukskvalitet i et produkt som utvikles. Fordelen ved å bruke designprinsippene ligger i at de kan bidra til å avdekke utfordringer med hensyn til et produkts brukskvalitet på en enkel, effektiv og billig måte. Ved å benytte seg av prinsippene kan man potensielt redusere antall iterasjoner i en brukersentrert design prosess, og dermed redusere kostnader, siden utfordringer kan avdekkes før en brukbarhetstest. Det er likevel begrensninger tilknyttet bruk av designprinsippene. De vil f.eks. være for generelle til å avdekke alle slags brukbarhetsutfordringer tilknyttet et produkt. Selv om en benytter seg av prinsippene må en derfor likevel gjennomføre en brukbarhetstest.

High level goals for data display

Smith and Mosier (1986):

Shneiderman's Eight Golden Rules of interface design

1. Streb etter konsistente sekvenser og design
2. Jobb for universal brukbarhet
3. Det bør være feedback fra systemet uansett hva brukeren gjør
4. Sekvenser eller grupper med handlinger bør ha en tydelig slutt. Eks. handling på nettet har en tydelig slutt med "bekreftelsessiden."
5. Forhindre feil. Brukeren burde ikke kunne gjøre feil, rett og slett.
6. Gjør det enkelt å rulle tilbake (angre) handlinger
7. Støtt et variert utvalg kontroller. Brukere med lite kunnskap skal kunne bruke applikasjonen, men erfarne brukere bør få hurtigtaster og andre verktøy som gjør at de kan jobbe fortere.
8. Unngå at brukeren må huske informasjon selv.

Fase 1: Forstå brukskontekst

Identifiser hvem som hovedsaklig kommer til å bruke produktet, hvorfor de vil bruke produktet, hva de krever av produktet og i hvilke sammenhenger de vil benytte seg av produktet.

Teknikker for å forstå brukskontekst

• Feltstudier
• Intervjuer
• Gruppeintervju/fokusgrupper
• Automatisk logging av bruksmønstre
• Rollespill
• Literaturstudie

Teknikker for å formidle brukskontekst

• Personas basert på observasjon og intervju
• Scenarier av dagens situasjon basert på observasjon
• Loggdata-analyser

Fase 2: Spesifisere brukerkrav

Når vi vet hva og under hvilken kontekst produktet skal brukes så kan vi spesifisere krav til produktet.

Teknikker for å spesifisere krav

• Intervju med brukere og andre interessenter.
• Fokusgrupper.
• Rollespill.

Teknikker for å formidle krav

• Kravlister (user requirements specification)
• Overordnede ikke-funksjonelle krav (bl.a. brukervennlighet)
• Scenarier og personas som viser tenkt
  system i bruk (use cases)

Fase 3: Design av løsninger

Når vi vet akkurat hva vi skal lage kan vi avhengig av hvor langt vi er kommet i designprosessen begynne å produsere et produkt.

Teknikker for å utvikle designløsninger:

• Prototyping:
• Ikke-funksjonelle (papirprototyper)
• Funksjonelle (kjørende prototyper)
• Scenarier m/personas for løsning i bruk.
• Designretningslinjer (Norman, Nielsen, etc)

Teknikker for å formidle designløsninger:

• Utprøving/Demo av selve prototypene
• Vise scenarier m/personas for tenkt system i bruk

Fase 4: Evaluere design opp mot brukerkrav

Etter å ha utviklet en designløsning må man få brukerenes tilbakemelding av produktet.

Teknikker for å evaluere designløsninger:

• Brukbarhetstesting i lab
• Fokusgrupper for feedback på løsning
• Felt-tester og logging av bruk
• Skjema (SUS)

Teknikker for å formidle resultat fra evaluering:

• Testrapport fra brukbarhetstest (summativ eller formativ)
• Oppsummering av feedback fra fokusgruppe
• Analyser av felt-tester og loggdata

Det som er viktig å legge merke til er at denne prosessen er iterativ og kan (og bør) utføres mange ganger i løpet av en designprosess. Det er ikke nødvendig å starte på fase 1 etter man har evaluert designet opp i mot brukerkravene, men man tar en vurdering på hvilket steg i prosessen man burde hoppe til for å kunne forbedre produktet.

Ulike prototyper

10 punkter for gjennomføring av brukbarhetstest

Dette er punkter testleder går gjennom med bruker.

1. Introduser deg selv
   • Hvem du er, hvem folka i teamet er. Håndhils. Oppnå trygghet.
2. Beskriv hensikten med testen
   • "Vi trenger hjelp med å teste et produkt -tester produktet, ikke deg. Vil finne ut hvor brukbart produktet er."
   • Hensikten er en forståelse for våre forventinger og behov.
3. Fortell deltakerne at de kan avbryte når de vil
   • Hensikt: Trygghet tillit og følelse av kontroll
4. Beskriv utstyret i rommet og begrensingene til prototypen
   • Fokus på hva testen skal handle om.
5. Lær bort hvordan man tenker høyt
   • Vis selv. Hensikt - få innsikt i brukerens strategier og mentale modeller
6. Forklar at du ikke kan tilby hjelp under testen
   • Blir anledning til å spørre og diskutere etter testen. Hvis de lurer på noe kan de gjerne si det høyt, da blir det lettere å huske i etterkant.
   • Forklar hvordan prototypen avviker fra virkeligheten.
7. Beskriv oppgaven og produktet
   • Beskriv oppgavene brukerene skal utføre. Legg frem summarisk oppgaveliste.
   • Beskriv produktet og systemet. Ikke avslør funksjonalitet eller operative begrep som du ønsker feedback på.
8. Spør om det er noe de lurer på og kjør testen
   • Lar brukeren komme til ordet før testens start.
   • Reflekter brukerens spørsmål tilbake til dem.
   • Ikke grip inn når ting går galt.
   • Ta detaljerte notater. Mer om testens gjennomføring under.
9. Avslutt testen med å la brukeren uttale seg før du samler eventuelle løse tråder
   • Avslutt testen når alle oppgaver er gjort eller tiden er oppbrukt. Besvar brukerens spørsmål.
   • Diskuter ting dere fant interessant underveis.
   • Be om en subjektiv vurdering og eventuelle forslag til redesign.
10. Bruk resultatene
    • Analyser sammenbrudd.
    • List opp og prioriter problemer.
    • Finn årsaker til de viktigste problemene og let etter alternative designløsninger.
    • Husk at hensikten med testen er input til redesign.
    • Hensikten med prototypen er å ha materiale å teste.
    • Tester der resultatene ikke brukes er bortkastet tid, og protottyper som aldri testes er bortkastet tid

Ting å huske på under testen:

• Ikke korriger problemer der og da.
• Aldri hjelp brukeren, med mindre det er siste utvei, eks. hvis vedkommende er veldig lost, svært forvirret, oppgaven gjør brukeren ukomfortabel, brukeren er så frustrert at det er like før han/hun gir opp, missing link i produktet, bugs eller krasj i systemet.
• Når du hjelper brukeren skal du ikke skylde på vedkommende. Hjelp vedkommende gradvis. Hjelpen kan påvirke det som skjer senere, så vær forsikig.
• Gi brukeren en tidlig følelse av suksess (lette oppgaver)
• Presenter en oppgave av gangen (reduserer mental belastning)
• Hold en avslappet atmosfære i testrommet (server kaffe og ta pauser)
• Unngå forstyrrelser; lukk døren og sett opp lapp. Slå av telefoner
• Aldri hint til brukeren om at hun gjør feil eller jobber sakte
• Minimer antall observatører i rommet (sett opp monitor i rommet ved siden av)
• Ikke la overordnede observere brukerne
• Hvis forsøkslederen får en følelse av at testsituasjonen er belastende for brukeren: Avslutt forsøket
• Observer testen upartisk, ikke la brukeren få en følelse av dine preferanser.
• Vær oppmerksom på hvordan du sier ting og ditt eget kroppsspråk. Det skal svært lite til før brukerne aner hva du mener
• Behandle hver enkelt bruker som et individ (ta pauser mellom brukerne)
• Ikke redd brukerne når de sliter med et problem
• Vær sikker på at brukerene er ferdig med oppgaven før du går videre (brukeren er ofte veldig usikker, selv om hun har utført den riktige responsen)
• Interager med brukeren underveis for å sikre verbalisering

Generelt sett: Hold deg i bakgrunnen, ha en passiv holdning, hjelp brukeren til å formidle det han eller hun tenker på.

Debriefing

• La først brukeren uttrykke seg
• Start diskusjonen på et høyt nivå, og jobb dere nedover.
• Trekk frem punkter du har notert
• Fokuser på å forstå problemene, ikke å løse de
• Etter alle aspekter er diskutert, åpne for innspill fra de andre i forsøket
• Åpne for at brukeren kan komme med ekstra innspill eller informasjon
• Forhold deg upartisk. Bruker skal ikke behøve å forsvare sine handlinger.

System Usability Scale (SUS)

Kan la brukeren fylle ut spørreskjema. Flere standardiserte, bla. SUS (System Usability Scale) som gir et tall mellom 0 og 100 på opplevd brukervennlighet. Se figur.

Brukbarhetstest som tegneserie

CC BY-NC-SA 4.0 Eirik Vågeskar

Funksjonshemming

Funksjonshemming oppstår når det ikke er samsvar mellom en persons funksjonsevner og kravene omgivelsene stiller.

7 prinsipper

1. Like muligheter for bruk
2. Fleksibel i bruk
3. Enkel og intuitiv bruk
4. Forståelig informasjon
5. Toleranse for feil
6. Lav fysisk anstrengelse
7. Størrelse og plass for tilgang og bruk

Hendelsesdreven programmering

Ifm. implementasjon av brukergrensesnitt bruker man gjerne det som kalles "hendelsdreven programmering." Man lar metoder kalles ut fra hendelser som inntreffer. Applikasjonen sover inntil hendelser inntreffer. Man har to typer hendelser:

• Leksikalse hendelser er de minste enhetene i en brukerinteraksjon, og er direkte knyttet til de fysiske input-enhetene til datamaskinen. Dette er det laveste nivået av hendelser vi har.
• Syntaktiske hendelser er en sekvens av leksikalske hendelser i en bestemt kontekst.

Når man implementerer et hendelsdrevent design bruker man gjerne en observator-observert-teknikken. En callback er en metode som kalles når en hendelse inntreffer.

Så hvordan funker MVC?

MVC er en programvarearkitektur/teknikk for å skille data fra grensesnittelementer. Det kan sees på som en realisering av de to øverste lagene i en 3-lags-arkitektur bestående av grensesnitt, business logic og persistens. MVC stammer fra Smalltalkprosjektet, der man skilte mellom modellen, viewet og kontrolleren.

Fordeler med MVC er at man enkelt kan bytte ut en del (eks. bytte ut et view, men beholde data), man kan ha flere view mot samme data og de koordineres automatisk. Ulempen er at det blir mer komplekst.

Model, View og Controller-objekter kobles under kjøring sammen slik at en modell kan ha flere View-Controller-par koblet til seg. Ved å automatisere oppdatering av alle views når modellen endres, innfører man en abstraksjon som gjør det lettere å legge til nye views. Oppdatering av views gjøres ved at modellen holder en liste med de View-Controllere som er koblet til den, og varsler disse ved endring.

Java Swing (deprecated)

JavaBeans-baserte modeller

• En JavaBean har visse egenskaper og følger visse navngivingskonvensjoner:
• Alle JavaBeans har et sett properties av ulike kategorier.
• Alle JavaBeans er kodet iht. visse konvensjoner:
• Navngiving av metoder for å lese og skrive properties.
  • read-metode: public String getName()
  • write-metode: public void setName(String name)
• generering av hendelser ved endringer av properties:
  • hendelsesklasse: PropertyChangeEvent
  • metoder for å registrere PropertyChangeListener-lystener:
  • add/removePropertyChangeListener