1. Kvantitaive mål, tid/krefter som brukes vs faktisk oppgave
2. Konseptuell modell
2.1. Metaforer
2.1.1. Direkte knyttet til hvordan vi oppfatter verden
2.1.1.1. Tid: Spares, brukes Vann: renner ut, fyser, fordufter
2.1.2. Funksjonen er å overføre likheter mellom kjente og nye situasjoner
2.1.3. Initialiserer dannelsen av en mental modell
2.1.4. Passer sjeldent perfekt til den konseptuelle modellen
2.1.5. Brukere bruker ofte romlige metaforer for å beskrive informasjon, derfor burde det også brukes i menyer
2.1.6. Downsides
2.1.6.1. Kan gå ut på dato, f.eks. diskettsymbol for lagring
2.1.6.2. Kan skjule/vise feil sider av metafor
2.1.6.2.1. "må jeg tørke skrivebord for støv"
2.1.6.3. Begrensninger kan føles
2.1.6.4. Lett å dra for langt
2.1.6.4.1. Postrom->Skuff->nytt brev>penn......
2.1.6.5. Noen metaforer skalerer dårlig, f.eks. skrivebordsmetafor for skrivebord
2.2. Konsepter
2.2.1. Hva brukeren ser, generelt klasser
2.2.2. Hvert "konsept" har attributter og operasjoner
2.2.3. Hvis modellen består av mange konsepter kan det være forvirrende, men ofte kan de grupperes sammen eller være spesialiseringer av hverandre
2.2.4. En bruker kan tenke seg at alle konseptene kan interagere med hverandre, så kompleksiteten øker eksponensielt i forhold til antall konsepter man prøver å introdusere til brukeren
2.2.5. Noen konsepter er viktigere enn andre
2.3. Relasjon
2.3.1. Sammenheng i objekter i konsepten
2.3.2. Feks. Billett <=> Mobillett konto <=> Profil. It's all connected
2.4. Overførbarhet
2.4.1. Hvordan det virtuelle relaterer til noe i virkeligheten
2.4.2. Feks: Virtuelle bankkort = ekte bankkkort
2.5. Div
2.5.1. Ikke begynn m. layout, lag heller konseptuell modell
2.5.2. Design UI til slutt
2.5.3. Er ikke: usecase, programmering objekter
2.5.4. En konseptuell modell bør være så simpel og nær det faktiske systemet som mulig, så det blir enkelt for brukeren å forstå den
2.5.4.1. Hvis et system ikke er basert på en simpel modell kan det være at systemet blir for komplisert for brukeren
2.5.4.2. Hvis en modell ikke er nær virkeligheten kan den få brukeren til å misforstå hvordan systemet skal brukes
2.6. Designerens visjon om brukerens interaksjon
2.7. Oppgavebasert vs ikke-oppgavebasert
2.7.1. oppgave: "log hours"
2.7.2. ikke: "create record"
2.8. Lexicon
2.8.1. Man kan gi navn til atributter, konsepter, osv. Det kalles et leksikon, og gjør det lettere å passe på at navnebruken er konsistent i systemet.
2.8.2. Hjelper også så man ikke legger til flere begreper når man kunne brukt et begrep man allerede har introdusert til brukeren
3. Brukbarhetstesting
3.1. Brukbarhet er relativt og kontekstavhengig
3.1.1. Kontekst uavhengig: Vekt/størrelse/farge/GHz
3.2. Tre punkter man vil måle i en test
3.2.1. Effectiveness (anvendbarhet)
3.2.1.1. Hvilken grad oppgavene lar seg gjøre?
3.2.1.2. Dekker systemet funksjonene? Klarer brukern å bruke disse?
3.2.2. Efficiency (effektivitet)
3.2.3. Satisfaction (tilfredstillelse)
3.2.3.1. "opplevde" brukskvalitet
3.2.3.2. Krever tester for å fastslå opplevelser. Viktig for aksept.
3.3. Forskjellige måter å måle på
3.3.1. Brukbarhetstesting i lab
3.3.2. Fokusgrupper for feedback
3.3.3. Felt-tester
3.4. Arbeidssteg
3.4.1. Utvikle målsetninger og hypotese, lag en testplan
3.4.1.1. Finn ut hvem, hva, og når
3.4.2. Skaff brukere
3.4.2.1. De burde ha riktig bakgrunn (jobb, erfaring, utdanning, kjønn, alder, holdninger etc)
3.4.2.2. Ofte holder det med 5-8 forskjellige brukere. Mer enn det blir bare de samme problemene rapportert om igjen
3.4.3. Forbered materiale
3.4.3.1. Detaljer, hvor, type av test (papir eller working)
3.4.3.2. Scenarier
3.4.3.2.1. best mulig scenarie rekkefølge oppgaver = real world riktig skillnivå
3.4.4. Pilottest
3.4.4.1. Gjøres for å teste opplegget
3.4.4.2. God mulighet for å oppdage svakheter og øve seg på scenarioene. Et scenario er en situasjon og oppgaver.
3.4.5. Velg forsøksleder
3.4.5.1. Kan også ansette eksterne konsulenter
3.4.6. Utfør testen
3.4.6.1. Ti punkter for å utføre en test
3.4.6.1.1. Introduser seg selv
3.4.6.1.2. Beskriv hensikten ved testen
3.4.6.1.3. Fortell deltakerene at de kan avbryte når de vil
3.4.6.1.4. Beskriv utstyret i rommet og begrensningene til prototypen
3.4.6.1.5. Lær bort hvordan man tenker høyt
3.4.6.1.6. Forklar at man ikke kan tilby hjelp under testen
3.4.6.1.7. Beskriv oppgaven og introduser produktet
3.4.6.1.8. Spør om det er noe de lurer på, kjør testen
3.4.6.1.9. Avslutt testen og la brukeren uttale seg før man samler løse tråder
3.4.6.1.10. Bruk resultatene
3.4.6.2. Gi lette oppgaver først så brukeren får en suksessfølelse
3.4.6.3. Gi en oppgave om gangen
3.4.6.4. Ha en avslappet atmosfære, gjerne server enten kaffe eller vann
3.4.6.5. Unngå forstyrrelser, f.eks. lukk dør og skru av mobil
3.4.6.6. Ikke hint om at han jobber sakte
3.4.6.7. Ha få observatører i rommet
3.4.6.8. Ikke ha sjefen til brukeren i rommet mens han utfører testen
3.4.6.9. Kan avslutte forsøket hvis det virker belastende for brukeren
3.4.6.10. Ikke la brukeren få inntrykk av testerens personlige preferanse
3.4.6.11. Identifiserer problemer ved å loggføre breakdowns
3.4.6.12. Vær oppmerksom på måten brukeren sier ting og kroppspråket til brukeren
3.4.6.13. Behandle alle brukere som individ
3.4.6.14. Ikke gå videre før man er sikker på at brukeren er ferdig
3.4.6.15. Ikke se overrasket ut
3.4.6.16. Fokuser på hva brukeren forventer
3.4.6.17. Hold deg så mye som mulig i bakgrunnen
3.4.6.18. Tillat brukeren å komme med innspill
3.4.6.19. Forklar hvordan resultatene kan bli brukt
3.4.7. Omform data
3.4.7.1. Prioriter funnene, utvikler løsningsforslag, og lager rapport
3.5. Fordel/ulempe av å isolere context of use (COU) ved brukbarhetstesting
3.6. Formativ / summativ
3.6.1. Formativ
3.6.1.1. TIdlig faser
3.6.1.2. Innsikt for forbedrelser
3.6.1.3. Identifisere feil
3.6.2. Summativ
3.6.2.1. Senere faser
3.6.2.2. Godkjenne/måle brukskvalitet (akseptansetest)
3.6.2.3. Målbare kriterier Feilrate, tidsbruk, subjektiv tilfredsstillelse
3.7. Horisontal / Vertikal
3.7.1. Horisontal
3.7.1.1. Går i bredden, men ikke dybde
3.7.2. Vertikal
3.7.2.1. Smalt, men går i dybden
4. Brukersentrert design
4.1. Det kalles codesign når man slår sammen de to siste stegene i den iterative prosessen Workshop: hver gruppe lager sin løsning. Lavnivå. Design-in-action. Felles presentasjon
4.2. Brukskvalitet tar hensyn til bestemte brukere i bestemte omgivelser med bestemte mål. Personas definerer brukere, mens scenarioer definerer mål og omgivelser
4.3. Den iterative designprosessen
4.3.1. Plan the human centered design process
4.3.2. Understand and specify context of use
4.3.2.1. Brukssammenheng (COU)
4.3.2.1.1. Involver brukerne
4.3.2.1.2. Iterativ prosess
4.3.2.1.3. Krever forståelse av brukere, oppgaver og omgivelser
4.3.2.1.4. Tverrfaglig
4.3.2.1.5. Forståelse
4.3.2.1.6. Formidle
4.3.3. Specify user req.
4.3.3.1. Spesifisere krav
4.3.3.1.1. Intervju, fokusgruppe, rollespill
4.3.3.1.2. Formidles med: Kravlister (user req spec) Ikke-funksjonelle krav Scenarier/personas som viser bruken
4.3.4. Produce design solutions that meets user req.
4.3.4.1. Utvikling
4.3.4.1.1. Prototyping (papir vs working) Scenarier m personas for løsning i bruk retningslinjer (norman, nielsen)
4.3.5. Evaluate design vs req.
4.3.5.1. Brukbarhetstesting (se under)
4.3.5.1.1. Lab, fokusgruppe, felt test, SUS skjema
4.3.5.1.2. Testrapport, oppsumering, analyser av data
4.3.5.2. Iterate
4.3.6. Finished
4.3.7. divergens og konvergens skape valg / ta valg ide - produkt
4.4. Teknikker
4.4.1. Prototyping
4.4.1.1. Forenklet representasjon av designløsning
4.4.1.2. Brukes for testing
4.4.1.3. Prosjekters liv er gjerne en prosess hvor man skaper valg i starten, og må ta valg mot slutten
4.4.1.4. "Just enough prototyping"
4.4.1.5. Hvem er brukeren? Hva brukes det til? Hvor/hvilken sammenheng skal det brukes?
4.4.1.6. Prototyper vurederes ut ifra tre kriterier
4.4.1.6.1. Implementasjon
4.4.1.6.2. Funksjon/rolle
4.4.1.6.3. Look and feel
4.4.1.7. Lo-fi; low fidelity
4.4.1.7.1. Enkle prototyper uten detaljer
4.4.1.7.2. Gjerne i papir
4.4.1.7.3. Brukes tidlig i prosjektet
4.4.1.7.4. Enkle og billige å lage, trenger ikke å kunne progge
4.4.1.7.5. Ulemper: kan ikke simulere bevegelser, animasjoner etc. Må ha rollespill / innlevelse Ufullstendig
4.4.1.7.6. "tilbakemelding på egnetheten/brukervennligheten av konkrete løsninger
4.4.1.8. Hi-fi; high fidelity
4.4.1.8.1. Komplekse prototyper med detaljer
4.4.1.8.2. Ligner mer på det ferdige produktet, trenger ikke fullstendig program
4.4.1.9. Wizard-of-oz prototype
4.4.1.9.1. Det er et menneske som endrer tilstanden til systemet og reagerer på input fra brukeren
4.4.1.9.2. Kan være realistisk, men mest egnet til å simulere et begrenset sett med funksjonalitet
4.4.1.10. Papirprototype
4.4.1.10.1. Lager skisser av skjermbilder
4.4.1.10.2. Må simuleres av et menneske, wizard-of-oz style
4.4.1.10.3. Tilstandsdiagram brukes for å vise sammenhengen mellom skjermbilder
4.4.1.11. Skiller mellom bruk-og-kast og evolusjonær utvikling
4.4.1.11.1. Med evolusjonær kan man bygge seg videre mot et ferdig produkt
4.4.2. Personas
4.4.2.1. Er ikke en virkelig person, men en representant for en brukergruppe
4.4.2.2. Kan evaluere en funksjon med utgangspunkt i en persona
4.4.3. Scenarioer
4.4.3.1. Beskriver oppgaver eller situasjoner
4.4.4. Storyboards: ofte løsningen på et scenario Ideskisse, forslag
4.4.5. Intervju
4.4.5.1. +Dybdekunnskap - få brukere
4.4.5.2. Må plukke representative brukere
4.4.5.3. "Hva de gjør i dag", "hvilke omg.". Anvendbarhet: identifisere sentrale funksjoner
4.4.6. Fokusgruppe
4.4.6.1. Tilbakemelding på konkrete forslag Mange stemmer, lett å overse detaljer
4.4.6.2. Scenarier? Omg? Er funksjonaliteten riktig? Hva må gå fort? Hva skal brukeropplevelsen være?
5. Deltakende design
5.1. Kvalitetskriterier
5.1.1. Utilitas; Skal fylle et behov
5.1.2. Firmitas; Skal være teknisk godt
5.1.3. Venustas; Skal være vakkert
5.2. - Tar ikke hensyn til at forskjellige personer har forskjellige meninger
5.3. - Teknologi kan ha innebygde politiske, sosiale, og etiske konsekvenser
5.3.1. Ikke god eller ond, men heller ikke verdinøytral
5.4. Tar utgansgpunkt i brukerens "tause" kunnskap; The tool perspective
5.4.1. Erfaringsbasert kunnskap
5.4.2. Kan være vanskelig å formalisere, og dermed vanskelig for datamaskiner å erstatte
5.5. Startet i skandinavia pga frykt for at industrialisering og automatisering skulle ta arbeidsplassene til folk
5.6. Ideen er at deltakende design skal forbedre praksisen istedenfor å erstatte den
5.7. Arbeiderne er med på å bygge verktøyene
5.8. Brukersentrert design startet i USA. Da involverte de brukere i brukbarhetstester
5.9. Utfordringer
5.9.1. Må ha demokrati
5.9.2. mikset roller
5.9.3. Hvem vektes mest?
5.9.4. Ikke representativt
5.9.5. Vanskelig å lage radikale løsninger
6. Ubiquitous computing
6.1. Den tredje interaksjonsparadigmen
6.1.1. Den første var mainframes i 1960-1985. En datamaskin, mange brukere
6.1.2. Den andre var PCer i 1985-2000. En bruker, en datamaskin
6.1.3. Er nå i den tredje, hvor vi har en bruker, mange datamaskiner
6.2. Forkortet til UbiComp
6.3. Visjonen ble beskrevet av Mark Weiser fra Xerox PARC i 1991
6.3.1. Skulle kunne interagere med maskinen hvor som helst, når som helst
6.3.2. Skulle være en forlengelse av kroppen
6.4. Kan gjøre det vanskelig å gjenskape brukskonteksten; ting blir brukt mer "on-the-move" enn bare foran en pc
7. Konseptuelle- og mentale modeller
7.1. Mental
7.1.1. Er en persons ide om virkemåten og strukturen til et system
7.1.2. Styrer hvordan brukeren bruker systemet
7.1.3. Formes av erfaring fra lignende systemer, samtaler med brukere, prøving og feiling, og brukermanualer
7.1.4. subjektiv, ufullstendig, inkonsitent, dynamisk
7.1.5. Kan få tilgang til den ved brukbarhetstesting, oppgaveanalyse, og intervjuer
7.1.6. To typer
7.1.6.1. Funksjonell
7.1.6.1.1. Vite hvordan "Hva må jeg gjøre for å få til dette?"
7.1.6.2. Strukturell
7.1.6.2.1. Hva som fører til hva Strukturen til produktet
7.1.7. Kartlegg brukerens mentale modell
7.1.8. Dårlig modell fører til
7.1.8.1. Redusert brukeropplevelse
7.1.8.2. Systematisk feilbruk av system fordi deres mentale modell er crap
7.1.9. Dårlig modell løses med
7.1.9.1. Forbedre brukerens mentale modell Eller tilpasse systemet til mental modell
7.1.9.2. Tydeliggjør design
7.1.9.3. Kursing, tooltips, kort tutorial
7.2. System image
7.2.1. Kommuniserer den konseptuelle modellen
7.2.2. UI + manualer
8. Context of use
8.1. Hvem
8.1.1. Krever tilgang: teens, oldies, studenta etc
8.1.2. Flere akser: datakunnskaper, kjennskap til bruksområde, motivasjon, motorikk
8.2. Hva
8.2.1. Detaljert kartlegging av arbeidspraksis og infoflyt
8.3. Hvor
8.3.1. Kunnskap om fysiske omg., observere, teste, ekte eller simulert
9. Brukersentrert vs Deltagende
9.1. Brukersentrert
9.1.1. 1. Deigneren tar valg, "diktator"
9.1.2. 2. Brukerene er testsubjekter (konsulenter)
9.1.3. 3. Løsningen designes for brukerne
9.1.4. 4. Fokus på brukskvalitet
9.2. Deltagende
9.2.1. 1. Brukerne er med på designvalgene (designern er fasilitator)
9.2.2. 2. Brukerne er partnere gjennom hele prosessen
9.2.3. 3. Løsningen designes for, med og av brukerne
9.2.4. 4. Fokus på "user empowerment"
10. Designretningslinjer
10.1. Universell utforming
10.1.1. Syv prinsipper for universell utforming
10.1.1.1. Like muligheter for bruk
10.1.1.1.1. Skal være like anvendbar og tilgjengelig for forskjellige personer
10.1.1.1.2. Kan løses ved å gjøre utformingen tiltalende for alle brukere.
10.1.1.2. Fleksibel i bruk
10.1.1.2.1. Gjøre det mulig å gjøre ulike valg i bruken
10.1.1.3. Enkel og intuitiv i bruk
10.1.1.3.1. Eliminere unødvendig kompleksitet
10.1.1.3.2. Forventningene til tingen stemmer med det den gjør.
10.1.1.4. Forståelig informasjon
10.1.1.4.1. Få så mye informasjon til brukeren på en så enkel måte som mulig
10.1.1.5. Toleranse for feil
10.1.1.5.1. Lage advarsler
10.1.1.5.2. Utformingen skal minske faren for feil.
10.1.1.6. Lav fysisk anstrengelse
10.1.1.6.1. Skal brukes effektivt på en enkel måte
10.1.1.7. Størrelse i plass for tilgang og bruk
10.1.1.7.1. Mulig å bruke for brukere med ulike forutsetninger
10.1.1.7.2. Feks: Tomler
10.1.2. Bygger på en relasjonell forståelse av funksjonshemning
10.1.2.1. Funksjonshemning oppstår når det ikke er samsvar mellom en persons funksjonsevner og kravene omgivelsene og oppgavene stiller.
10.1.3. Kan brukes av folk uavhengig av bakgrunn, (fysisk, kognitive, kulturelt) uten at det ser ut som om man tar hensyn.
10.1.4. Ved å designe for mangfold blir det lettere for alle å bruke
10.2. Jacob Nielsens heuristikker
10.2.1. Visibility of system status
10.2.1.1. DN visibility + feedback
10.2.1.2. Systemet burde vise status, f.eks. gjennom en progress bar
10.2.2. Match between system and the real world
10.2.2.1. Ord, begreper, ikoner: Må snakke brukerens spåk
10.2.2.2. Feks: Ikoner i Photoshop
10.2.2.3. Må beskrive ting på en måte brukeren forstår
10.2.3. User control and freedom
10.2.3.1. La brukeren være i kontroll
10.2.3.2. Med en angre-knapp føler brukeren at han har kontroll, selv om man har satt systemet i en uønsket tilstand.
10.2.4. Consistency and standards
10.2.4.1. Følg platform standarder
10.2.5. Error prevention
10.2.5.1. Fleksibilitet. "Låse" ugyldige valg. Tidsfelt: kan ikke skrive bokstav i alder
10.2.5.2. Gjøre systemet "idiotsikkert". Hvis det er vanskeligere for brukeren å gjøre feil, er det lettere å gjøre riktig.
10.2.6. Recognition rather than recall
10.2.6.1. Instruksjoner/flyt må være naturlig
10.2.6.2. Skal ikke pugge bruk
10.2.6.3. Gjør ting synlig
10.2.6.4. F.eks. hurtigtaster er recall, men hvis man er i office og trykker på "alt" (i windows hvertfall), får man opp hurtigtastene for knapper. Da har man recognition.
10.2.6.5. Forhåndsvisning av font
10.2.7. Flexibility and efficiency of use
10.2.7.1. Ha måter som en erfaren bruker kan bruke systemet mer effektivt, f.eks. shortcuts eller lignende
10.2.8. Aesthetic and minimalistic design
10.2.8.1. Det er vanskelig for en bruker å finne viktig informasjon hvis det er veldig mye informasjon på skjermen.
10.2.8.2. Hvis informasjon er irrelevant eller sjeldent nødvendig burde den skjules.
10.2.9. Error recovery
10.2.9.1. Hjelper brukeren med å unngå feil.
10.2.9.2. Hjelper brukeren med å håndtere feil.
10.2.9.3. Tilbakemeldinger burde hjelpe brukeren, ikke gi en feilkode eller dårlig beskrivende feilmelding.
10.2.10. Help and dokumentasjon
10.2.10.1. Det er best å ikke bruke dokumentasjon, men hvis man må ha så skal den være bra.
10.3. Don Norman
10.3.1. Mapping
10.3.1.1. Sammenheng mellom interaksjon og effekt
10.3.1.2. Kalles poor mapping eller natural mapping
10.3.1.3. f.eks., hvis volumet skal opp trykker man på den øverste knappen
10.3.2. Visibility
10.3.2.1. Funksjoner som er ute av syne kan være vanskelig å forstå
10.3.2.2. Kan jeg se det? Worst case: Usynlige funksjoner (vannkran, forvirring)
10.3.2.3. Hjelper brukeren med å skjønne hva han skal gjøre
10.3.2.3.1. Hvordan kan jeg bruke det? Inviterer til bruk på bestemt måte
10.3.3. Consistensy
10.3.3.1. Elementer som ser like ut bør gjøre det samme
10.3.3.2. Brukeren burde slippe å huske på unntak
10.3.4. Constraints
10.3.4.1. Det motsatte av affordance
10.3.4.2. Hvorfor kan jeg ikke gjøre slik?
10.3.4.3. Signaliserer begrensninger "Greyed out"
10.3.4.4. PLACEHOLDER for datofelt
10.3.4.5. Betinges av:
10.3.4.5.1. Fysisk
10.3.4.5.2. Kulturelt
10.3.4.5.3. Omgivelser (polvott + smartphone)
10.3.5. Affordance + constraints
10.3.5.1. Viser hvordan noe skal brukes
10.3.5.2. Felt som skal fylles ut + knapp (next)
10.3.6. Affordance
10.3.6.1. Dårlig affordance = false affordance, luremus
10.3.6.2. En gjenstand kan signalisere ulike handlinger
10.3.6.2.1. Fysisk form
10.3.6.2.2. Kulturell. Konvensjoner som læres. Grønn: GO RØD: STOP
10.3.6.3. Hvis produktet kan utføre en handling det ser ut som om den ikke kan, kalles det hidden affordance
10.3.6.4. Beskriver en handlingsrelasjon mellom tingen og brukeren
10.3.6.5. Avhengig av bruksområde/plassering
10.3.7. Feedback
10.3.7.1. Visuell, auditiv, taktil, eller en kombinasjon
10.3.7.2. Info om hva som har skjedd
10.3.7.3. Affordance sier hva som kan gjøres og feedback sier at det har skjedd
10.3.7.4. Alle handlinger skal gi feedback
10.3.7.4.1. Mangel = kjipt. No progressbar..
11. Gestalt
11.1. Teorier for hvordan sanser fungerer
11.2. Baserer seg på at vi organiserer sanseinntrykk inn i helheter
11.3. Fem prinsipper
11.3.1. Likhet
11.3.1.1. Like former og farger sees sammen
11.3.2. Nærhet
11.3.2.1. Elementer som står nærme hverandre, oppfattes som tilhørende
11.3.3. Mental komplettering
11.3.3.1. Vi oppfatter helst lukkede former
11.3.4. Kontinuitet
11.3.4.1. En linje som har en retning oppfattes som om den skal fortsette i den retningen
11.3.5. Forgrunn/bakgrunn
11.3.5.1. Finnes aspekter som påvirker hva vi oppfatter som forgrunn og bakgrunn, f.eks. farge, kontrast, rammer, størrelse på objekter, perspektiver.
12. Brukergrensesnitt
12.1. Kontrollelementer
12.2. Input
12.2.1. Buttons
12.2.1.1. Fyrer aksjon
12.2.1.2. Tydelig symbol, tekst. Åpenbart. DONT FUCK IT UP
12.2.2. Toggles
12.2.2.1. Tilstandsendring
12.2.2.2. Umiddelbar
12.2.2.3. Liten skade ved feilklikk
12.2.2.4. Gjenkjennbar, intuitiv
12.2.3. Dropdowns
12.2.3.1. Ett av mange valg
12.2.3.2. Kan scrolle
12.2.3.3. Autocomplete ++
12.2.3.4. Kan nøstes (drawback: lett å feile)
12.2.4. Radiobutton
12.2.4.1. Ett valg (av flere alternativer)
12.2.4.2. Vertikal
12.2.4.3. Dekk mulighetsrom
12.2.4.4. Led noobs med default valg (Men ikke ved presidentvalg o.l.)
12.2.5. Checkbox
12.2.5.1. ETT eller MANGE valg
12.2.5.2. Helst vertikal (horisontal = space aids)
12.2.5.3. OK med kolonner
12.2.5.4. Lable: SKAL være enkel og positivt ladd! "Disabled" IKKE LOV
12.3. Navigasjon
12.3.1. Sliders
12.3.1.1. Verdi innenfor numerisk intervall.
12.3.1.2. ca ca, touch er ikke presist
12.3.2. Pagination, scroll bars
12.4. Informasjon
12.4.1. Label: Statisk
12.4.2. Textfields: Dynamisk (Liten grå rute rundt text, som disabled txtinput)
12.4.3. Popups
12.4.3.1. Tilbakemeldinger
12.4.4. Tool tips, icons, progress bars, notifications, message boxes, modal windows
12.5. Containers
12.5.1. Tab controls
12.5.1.1. Faner. Lett å bytte view
12.5.1.2. Innhold må være logisk / gi mening å dele inn
12.5.1.3. PC: på toppen, mobil: på siden
12.5.2. Panels, accordion