Salget av mobiler for første kvartal var 294 millioner enheter, mot 71 millioner PC’er. Flere titals millioner søk blir gjort via mobil (Tidwell jobber nå for Google), 80% av de er utenfor USA. Noen land søker mer via mobil enn fra PC.

Hva er konsensus for best practice? Det finnes noen guidelines allerede som forteller hvordan en mobil virker og hva som kreves. Hun tipser om sidene littlespringsdesign.com og Alltop.com og forteller at hun jakter etter patterns.

Hun er ingen mobilekspert, så hvor starter man? Mobil interaksjon kjennetegnes ved sterk oppgavefokus. Hun tar utgangspunkt i ‘general purpose’ og ‘always connected‘. Hun fokuserer på touchscreen telefoner som iPhone, enheter med tastatur, som Blackberry og telefoner med keypad (98% verdens mobiltelefoner), samt internet tablets. I jakten etter patterns bar hun med seg iPhone, en kindle, et kamera og en mp3-spiller hele tiden.

iPhone changed the game

Hun fulgte litt av den samme tilnærmingen som med den forrige boka:

• konsensus på best practice
• …men ikke for åpenbart
• spesifikke og utvidbare
• prøvde ikke å dekke alt

Nedenfor gjengir jeg de tentative best practice hun gikk igjennom, i den formen hun presenterte de:

One-column layout

Legg ut innholdet i en skrollende vertikal stack med de mest viktige tingene øverst. La bredden være flytende så den passer innenfor skjermen. Du vet ikkke hvor folden er på disse sidene, fordi enhetene er så forskjelige og kan holdes forskjellig.

Hvorfor

• Unngå horisontal skrolling
• Unngå zooming
• Enheter har ulik skjermbredde (og høyde), så design for fleksibilitet
• Tilpass det viktigste innholdet over folden når siden er lang

Når

• De fleste nettsider og programmer, særlig tekstbasert innhold og skjemaer

Persistent toolbar

Plasser de mest viktige verktøyene i en kort verktøylinje forankret til en av sidene på skjermen. Hun forteller at de har funnet ut at folk liker den øverst, men at de ikke kan generalisere dette.

Hvorfor

• Tykke eller sammensatte verktøylinjer tar for mye plass og brukerne protesterer mot “layer cake effect”
• Ikke tving brukeren til å skrolle siden for å komme til verktøylinjen - minimer skrollingen

Når

• Done, cancel, andre “dialog-ish” kommandoer
• Navigering: tabs, tilbake, etc
• Verktøy bør alltid være tilgjengelig
• Verktøy er små.

Jevnfør Tool overlay (neste pattern…)

Touch tools

Vis bare verktøy i respons til et tastetrykk eller trykk, i et lite, dynamisk overlegg.

Hvorfor

• Brukeren bestemmer når verktøyene er synlige
• Tillater ellers innholdet til å dominere oppmerksomheten

Når

• Verktøyene krever mye plass…
• …men trengs bare av og til
• Ofte brukt til video, bilder, spill, kart

Jevnfør med Persistent toolbar (forrige pattern)

Item markers

Bruk uthevede farger, ikoner og andre visuelle differensieringer i menyer og lister

Hvorfor

• Leseforholdene er sjeldent ideelle - bruk perseptuelle ledetråder for å hjelpe identifisere elementer
• Ingen roll-over hint!
• Ikoner kan forstørre treffområder
• Mobile skjermer er så små at du kan bruke mer intense farger enn normalt

Når

• Menyer (til programmer eller handlinger)
• Lister av objekter med vurderinger (ratings), status, lest/ulest notifikasjoner og annen metadata

Infinite list

I enden av en liste, plasser en knapp som laster inn eller føyer til flere oppføringer til listen

Hvorfor

• Den initielle innlastingen av M oppføringer er rask
• Påfølgende innlasting av N oppføringer, i biter, er også rask (og under brukerens kontroll)
• Brukeren trenger aldri å skifte kontekst ved å gå til en ny side

Når

• Beskjeder, artikler, søkeresultater, hva som helst som er “bunnløst”.
• Brukerne finner mest sannsynlig ønskede oppføringer øverst, men kan trenge å søke videre.

Thumbnail grid

Bruk et lite, mangfoldig rutenett av thumbnailbilder til å representere oppføringer.

Hvorfor

• Kompakt, attraktiv presentasjon av mengder med oppføringer (16+ på større skjermer)
• Firkantede thumbnails gjør de enkelt å treffe for fingre eller styli.

Når

• Objekter er for det meste uniforme i størrelse og type, etc.
• Lite metadata trengs å vises

Carousel

Vis større thumbnails i en linje eller sirkelbue, med den midtre i fokus. Brukeren beveger linjen til venstre eller høyre. Nyttig å se flere ting om gangen. Veldig bra å bruke på touchskjermer.

Hvorfor

• Fokus + innhold = lett identifisering
• Fungerer fint på scroll-and-select hardware

Når

• Metadata bør vises ved hvert element
• Elementene er forskjellige i form, størrelse eller type, men har en åpenbar visuell gjengivelse

Jevnfør en ordinær tekstliste eller med Thumbnail grid.

All-in-one button

Et enkelt treffpunkt i et skjema kan vise en merkelapp, en verdi eller en “rediger” indikator. Android gjør ikke dette, det er veldig synd, fordi de forteller ingen state. Er jeg tilkoblet wifi nå?

Hvorfor

• Store treffpunkter er bedre enn små
• Plasseffektivt og lett-å-bruke erstatninger for rullgardinlister, radioknapper, etc

Når

• Et skjemaelement spør brukeren om å velge fra en liste eller sett med verdier
• Et nytt skjermbilde eller overlegg trengs for å redigere verdien

Two-part button

En enkel knapp eller listeoppføring inneholder et større og et mindre treffpunkt, hver med forskjellig handling.

Hvorfor

• Samlokaliserer relevante handlinger med det aktuelle elementet
• Fjerner behovet for tilleggsbevegelser (for eksempel Androids ‘long click’)

Når

• Et element har en åpenbar primærfunksjon, men også en “rediger” eller “mer informasjon” funksjon
• Brukeren trenger å kjenne til begge

Aggressive autocompletion

Bruk autofullfør hver gang brukeren skriver tekst som i nærheten av forutsigbar. Typing sucks. Autocompletions på fritekst kan være irriterende.

Hvorfor

• Tekstoppføringer går sakte og er utsatt for feil
• Små tastaturer; suboptimalt fysisk miljø som bevegelse, varmt/kaldt, dårlig lys; delt oppmerksomhet; ofte ingen klipp/kopier/lim inn

Når

• Navn, epostadresser, URL’er, søkebegreper, datoer, etc
• Ordinær fritekst etter brukerens skjønn

Textfield clear button

Slett et tekstfelt med ett trykk.

Hvorfor

• Å slette lange strenger med tekst bokstav-for-bokstav er tregt og gir ofte feil
• Noen plattformer har ingen kopier/klipp/lim inn
• Brukerne forventer dette

Når

• Etthvert tekstfelt hvor to millimenter-bredder kan brukes

Share button

Når en bruker finner interessant innhold, la de enkelt sende det til venner via en “share” knapp. Mobil er sosialt. Det sosiale aspektet er viktig, folk vil kommunisere. Google har funnet at folk ikke vil kringaste sin posisjon. La de velge hvem de vil kringkaste til, sine venner og kontaktlister. Offentlig deling eller kringkasting er ofte ikke velkomment i en mobil kontekst.

Hvorfor

• Deling støtter nære sosiale bånd, som er høyt verdsatt blant brukere
• Direktelenker til e-post, meldinger eller sosiale nettverk gjør sidene veldig enkle å dele

Når

• URL’er, medieinnhold, kartlokasjoner, søkeresultater - bruk fantasien!

Micro loading indicators

Når en side eller blokk laster inn, vis en liten progresjonsindikator på stedet hvor brukeren trykket.

Hvorfor

• Tilkoblinger kan være trege eller uregelmessige
• Progresjonsindikatorer fremskynder den tilsynelatende lastetiden
• Forsikrer brukeren om at noe skjer som respons til en handling

Når

• Hver gang brukeren må vente for at noe må laste inn

Rich interconnections

Plassér direktelinker til andre programmer i ditt program eller nettside, og forhåndsutfyll dem med data fra brukerens kontekst. Hun forteller om google maps og hvordan du kan gå fra et sted til directions eller en website eller til en epost eller ta en telefon direkte fra det. Det er vanskelig å skifte mellom apps på en mobil, derfor er dette viktig.

Hvorfor

• En bruker ser bare ett program om gangen og det er en plage å bytte mellom dem
• Mobile enheter har ofte nok kontekst til å tilby intelligente stier mellom applikasjoner
• Du har ingen filsystemer eller utklippstavler (den vanlige måten å flytte rundt på data)

Når

• Telefonnummer i hvilken som helst applikasjon -> Oppringing
• Bilder i kameraet -> last opp eller send som e-post
• Etc.

…og til slutt:

Data in the cloud

Trekk brukerdata som e-post og kontakter fra gjemmesteder i nettverket, og også deres favoritter, historie, profiler og individuelle tilpasninger. Synkroniser automatisk. Veldig uferdig pattern. Folk vil ha dette på mobilen også.

Hvorfor

• Data i skyen er mer tilgjengelig enn personlige datamaskiner
• Gi brukerne det samme arbeidsmiljøet de har på en desktop klient, bare det eksakte brukergrensesnittet er annerledes

Når

• Når som helst?

Dette er tentative patterns

Hvor mye bevis er nødvendig for å si at en pattern er god? Tidwell tror at dette etterhvert kommer til å slutte å være en spesiell kategori innen design, vi kommer alle til å designe for mobil en dag. Hun er redd for at dette skulle forbli segregert fra alt annet. Hun kommenterer også til et spørsmål fra salen at patterns endrer seg over tid i takt med utviklingen, mange dør ut og er ikke relevante lenger heller. De er levende dokumenter. Hun kommer nok til å pensjonere noen patterns i neste versjon av sin bok. Eksemplene vil endre seg, fordi mange er utdatert. Hun understreker at dette er tentative patterns.

Ett annet spørsmål går på hvordan brukeren opplever en totalt annerledes versjon av samme tjeneste. Hvor ‘disruptive’ er det for brukeren? Som forskjellen mellom vanlig facebook og den mobile versjonen? En kommentar til det er hold grensesnittet til systemet ikke til enheten. Hold det til plattformen ikke til ‘desktopen’. Det har også mye med branding å gjøre, at brukeren kjenner seg igjen med grafisk design som er gjenkjennelig. Get the details right and make it look like yours.

Personlig er jeg spent på å se hva boken hennes gir av tillegg til det Apple allerede har nedtegnet i sine guidelines for utvikling av applikasjoner og nettsider til iPhone. Jeg forstod det var en del forventninger til denne presentasjonen på konferansen, men inntrykket mitt er at mange nyvinninger i design av mobil UX allerede er gjort av iPhone. Denne boken kan fort bli et oppslagsverk som i stor grad baserer seg på iPhone sine guidelines, men med et mål om være en mer generell guide til design av grensesnitt for mobile enheter. Hun påpekte underveis i presentasjonen at grunnen til hun brukte så mange skjermklipp fra iPhone var at det var så lett å ta skjermdumper på den…

Sitter med analysen til masteroppgaven min og føler en blanding av dyp innsikt og mangel på oversikt på samme tid, jeg veksler mellom panikk-angst for å ikke rekke over det hele til en følelse av å ville drive med forskning resten av livet.

13 iphonebrukere er dybdeintervjuet, halvparten har møtt hverandre i fokusgruppe, resten har reflektert i dagbøker og tatt bilder av hverdagen sin med iphone. Nesten 150 000 ord og 34 bilder med rådata. Ville delt mer av arbeidet her på bloggen, men jeg prøver å nøste tråder og det tar tid.

Jeg beundrer Agnete og Hege som gjør blogg til prosess og prosess til blogg, følg det spennende diplomarbeidet deres på ready, set, go back.

Theo Jansen vil skape liv og vil gjøre det fra scratch. Trondheim Matchmaking hadde invitert ham til Trondheim høsten 2007 hvor han fortalte om arbeidet sitt med å skape liv på strendene i Nederland ved hjelp av plastikkrør og vannflasker.

På Kreator 09 møtte jeg på en variant av skapningene hans i form av en Legorobot. Roboten hadde fått ben designet etter den ideelle formelen til Jansen. Den beveger seg stabilt og raskt, akkurat som de store plastbeistene på strendene i Nederland.

Hver del av hvert ben er nøye beregnet til å gi den beste bevegelsen ut i fra energioverføringen. Jansen kaller bestanddelene av plastdyrene sine for gener, og hevder at om han lever i 15 år til vil han få de til å reprodusere seg.

Se presentasjonen hans på TED talks for å oppleve mer av hva denne fascinerende mannen har viet de siste 20 årene av livet sitt til.

For å gi noen eksempler på hva jeg mener, vil jeg vise et gammelt bilde og et fra i vinter, og gi et tips til NRK.

For snart tre år siden mistet Agnete powerbooken sin fra surfebenken og ned i gulvet. Skjermen knuste og det ble en dyr reparasjon.

Bildet fikk fort kommentarer fra venner, med både spørsmål og sympatierklæringer.

Ikke bare kan venner dele denne smertefulle opplevelsen (ja, noen av oss får et veldig nært forhold til verktøyene våre) gjennom bildet, andre med tilsvarende opplevelser kan også fortelle sin erfaring. Vi møtes rundt bildet med en opplevelse vi kan dele. En flickr-bruker jeg ikke kjente fra før deltar med lenke til en bloggpost hvor han beskriver samme problem og hvordan han fikset det.

Jeg vet ikke motivasjonen hans for å delta med tips og hjelp, men tror det har med samme mellommenneskelighet man finner hos for eksempel en turist som får tips fra en tilfeldig lokal om en attraksjon som er verdt å se.

På flickr virker det helt tilfeldig hva som fanger brukernes interesse. Jeg ville ikke forventet at et bilde av en hæl med gnagesår ble en tråd med tips om hvordan man kan unngå det, men jeg er veldig glad for det skjedde.

Både den ødelagte laptopen og hælen med gnagesår er ting jeg kan snakke med venner og familie om, men her blir det hendelser og situasjoner som jeg deler helt uventet med nye og andre bekjente. Noen ganger ville jeg kanskje aldri delt det med noen i det hele tatt, fordi det i noen situasjoner kan oppleves for dagligdags eller uinteressant.

Gather, share vs. share, gather

Clay Shirky, som har skrevet boka Here comes everybody, snakker om hvordan vår tids nye teknologier uvikler seg og får oss til å utfolde oss i nye grupper som gjør nye ting på nye måter. Tidligere måtte vi samles for å dele. Uansett hvilke interesser det gjaldt, måtte en møteplass fasiliteres, som ofte også satte tid og sted som premisser. Internett og sosiale nettjenester fasiliterer og tilrettelegger for det motsatte: vi kan dele og så møtes.

Every URL is a potential community

På mp3-spilleren min har jeg to favorittpodkaster: NRK P2s Verdt å vite og BBC’s Digital Planet. Supre programmer som tar opp aktualiteter innen teknologi og vitenskap. Jeg kan høre om spennende tema som jeg vil lese mer om, eller jeg kommer på noe jeg hørte på en podkast fra i høst, men jeg klarer ikke finne igjen programmet eller detaljene i det som ble fortalt uten å måtte høre igjennom alle de siste podkastene på ny. Programoversikten til Verdt å vite ser slik ut:

Jeg kan verken lete opp eller lenke til det programmene tar opp. Hva om hvert program av P2s Verdt å vite hadde vært en møteplass hvor emnene kunne samles, lenkes til og diskuteres?

Ryktene sier at Digital Planet vil lage et tekstarkiv med innhold på programepisodene for framtiden, men jeg klarer ikke finne annet enn informasjon om siste episode. Og jeg kan ikke lenke til den eller delta i noen samtale der.

Bildene på flickr er et nettsamfunn, likeså bloggpostene med kommentarer her i bloggen. Artikler i nettavisene prøver å bli det og radioprogrammene til NRK og BBC burde være det.

Om du ikke har hørt det Clay Shirky snakker om tidligere, anbefaler jeg disse to presentasjonene. De er både en vekker og en god a-ha opplevelse:

• Here comes everybody fra PICNIC08, og
• It’s not information overload. It’s filter failure fra Web 2.0 Expo NY

Utdrag fra kommentarene til bloggposten:

What happens to learning that has no identifiable immediate objective? Or getting something from information that is completely different from what the author intended? Or absorbing information that has no other purpose than the joy of finding out something new? [...] Information is anything that communicates facts to increase understanding of the world. Methods of doing this might be more or less appropriate for a given objective or audience [...]

Information is anything that diminishes uncertainty

[...] information is a temporary result of a relational process. It’s actually the work to give a form. To put In a Form. And this form has to be recognized. It’s only when I’m satisfied with one of your answers, and when you’ve checked someway that I’m not missing something that information exist. In a way the problem is not What is information?, but When is information?

Information is news of difference. When it’s a difference that makes a difference it has meaning.

The point that is being made here is related to the definition of information [...] The distinction between information, data, and knowledge. The cups, an orange, a green and a red cup… are all data until they are given context and made relevant in the way that the film is talking about. It’s at that point the orange cup becomes “information”.

Se også

• Informasjonsbærer
• Mentale modeller
• Informasjonsskygger

Innholdet er grensesnittet.

Alle som jobber med GUI har kunnskapen til å jobbe med NUI. Men for å gjøre en god jobb må du ‘undo’ en del kunnskap om hvordan brukeren skal manipulere data.

Hvordan jobber de?

Prosess: Konseptuell design; Iterasjon på papir, storytelling boards.

Resultater: Interaksjonsdesign; De lager et visuelt språk for å illustrere, hvordan dobbelklikker du, hvordan slette et objekt, osv. Dette lager de også wireframes på.

Resultater: Previz; previsualiseringer som viser hvordan ting skal fungere gjennom eksempler. Designere og utviklere referere bare til “the movie” hvis det er diskusjon om hvordan en interaksjon skal være.

Prototyping: Work at scale! Dette er kritisk, du må få en følelse av hvordan designet henger sammen. De monterer spesialtilpassede test-oppsett for å teste, samtidig som de tester når designet i riktig miljø.

Han viser flere produkter de har gjort, det meste bakprojektert multitouch.

Utfordringer:

• Håndtere brukerforventninger
• Fasilitere natural and gestural input
• Designe storformat interaksjoner
• Designe for 360 interaksjoner

Han skryter av vanntingen til Microsoft Surface som er utrolig appelerende på folk, de vil prøve den og leke med den.

De har gjort ting som ikke funker hvor stakeholderne har vært negative til det “lekne” og vil heller ha cheezy reklamespots. De arbeider mye med å endre mind set, særlig på klientene.

Virtuelle keyboards er forferdelige, høy error-rate. Prøv å unngå det.

Hvordan endre GUI-vanene?

Du må balansere forventninger fra brukerene. Hvordan lærer du bort at du ikke har en scrollbar på iPhone?

Never control by proxy when you can control directly

Andre forventninger bør du innfri, som for eksempel å beholde lukk-knappen oppe til høyre. Brukerne er vant med det og slike funksjoner er vanskelig å designe annerledes.

Bruk metaforer. Med multitouch går man fra metaforisk til virtuell fremstilling av virkeligheten. Der tradisjonelle datamaskiner er bundet til metaforer kan man med multitouch gjøre den virkelige verden virtuell.

Design for forgivness. Pass på at brukerne ikke føler at de feiler når de utforsker interaksjonsmulighetene. Hver input må høres eller bli gjenkjent, og denne fremmede enheten må gi en slags tilbakemelding slik at brukerne forstår at den er interaktiv.

Ufordringer med input
Det kan være vanskelig å bestemme hvilken finger som tar på skjermen. Surface har fancy matte som regner ut vinkel på skyggen til fingrene. Viktig å huske at dette ikke er to mus som er plugget i maskinen. Sesjonshåndtering og sporing av bruk er viktig. Han kaller tilgjengelighets-aspekter for en akilleshæl ved denne interaksjonsmåten. Og “virtual keyboards suck.”

Mange av løsningene bakgrunnsbelyst. Det gjør at ting ikke ser så skarpt ut når du står nærme. Tenk på menneskets synsevne: Mennesket har ca 220 px i sitt synsfelt, viktig å huske på at brukerne står nærme skjermen og at tekst og grafikk må tilpasses.

Utfordringer ved flerbrukere
Kontekst og egnethet; når gir dette mening? Moody hevdet NUI ikke nødvendigvis egner seg i samarbeidende miljøer, men kan være en bra ting i kompetitive. Gir det noen fordeler?

Hvem har kontrol? Og over hva? Lokal vs global kontroll er viktig på systemnivå, men også for brukerne. En person må kunne gjøre noe uten å stenge for andre brukeres kontroll.

Typiske utfordringer ved table computing er orienteringen, hvilken vei skal grensesnittet vende seg. Disse systemene er ofte mer komfortable å bruke enn vertikale systemer.

Forskjellen mellom hjemmelagde multitouchsystemer og Surface:

• Optisk visuelt system, du kan orientere ting etter skyggen på dette
• Objektgjenkjenning
• Robust SDK - det betyr utrolig mye når det gjelder skalering
• Det har en god stivhet
• Det er produktifisert og godt produsert

Noen tanker til slutt

Be natural. Bruk metaforer og getstures som er naturlige.
Be social. Design for interaksjone ovenfor eller utenfor bordet
Be aware. Være imidiate og tilgi uventet input

Idag er ikke ‘natural’ = ‘kjent’. Det må være forutsigbart og mulig å lære uten instruksjoner. Årsak og virkning av en bruker kan bli observert av en annen bruker. Stol på nysgjerrighet. Know your hardware.

Virkelig mimikk har betydning, bruk tid på å forske på hva folk gjør for å lære om dette. Se hvordan folk snakker med hverandre, får råd, hvordan de sykler og utfører aktiviteter.

Lær av andre industrier: spilldesign, industridesign, spesialeffekter, og lignende.

Test som en besatt feiging. Test tidlig og ofte - og på riktig hardware.

Og ja: de får mange henvendelser fra klienter som ønsker å bestille “sånn som Tom Cruise har i Minority Report”. Jeg likte foredraget spesielt godt fordi det ga mange a-ha opplevelser, særlig fokuset på content = interface og viktigheten av å teste i riktig skala og oppsett.

På konferansen fikk jeg teste Surface, det er virkelig et kraftig og sosialt system. Har testet et hjemmelaget multitouch-oppsett tidligere, men det er en helt annen opplevelse å manipulere dataen direkte. NUI is the new loud. Det føles veldig riktig å “ta på data.”

Hva tror du om NUI? Har du spørsmål eller kommentarer, bruk kommentarfeltet…

Motivasjonen for å finne et rammeverk til holistiske designløsninger har vært et ønske om å minimere subjektive meninger i designarbeidet. Skulle de tatt hensyn til subjektive meninger i arbeidet med yahoo.com ville de fort kommet opp i 10 000+ interessenter.

Både arkitekter og IxD-folk begynner designarbeid med skissing, han trekker flere sammenlikninger mellom de to yrkene. Boken “101 things I learned in architecture shool” beskriver sentrale idéer bak arkitekters arbeid. I boken fant han flere teorier som ha gjenkjente fra sitt eget designarbeid.

En parti er en sentral idé eller konsept bak et bygg. Parti er en designprosess som hever seg over arkitekturen. Du må ha en forståelse av mer enn arkitektur og kontekst. Parti oppstår av de teknologiske mulighetene, markedsfaktorer, innsikt i kunder, gruppering av ressurser, bedriftsstrategi og lignende.

Bruk parti som en veiviser i design av de mange aspektene ved en bygning.

Hvordan brukte Yahoo disse tankene?

De kom opp med idéen om at Yahoo skulle være “the dashboard for what you love on the web”. Luke demonstrerer hvordan de har designet en meny-skuff på venstre side av nettsiden, som kan tilpasses av brukerne. Som en startmeny for web?

Men det trengs mer enn parti for å designe et nettsted. Luke er glad i design principles, han kaller det “key characterstics to evaluate descisions”. Designprinsipper og parti utgjør tilsammen det han kaller en Design Sandwich.

Hvordan setter de sandwichen ut i praksis?

• De vurderer alle relevante faktorer; teknologi, kontekst, publikum, etc.
• Bruker patterns, best practices og testing til å hjelpe arbeidet mot en løsning.
• Evaluerer løsning ved å sende de gjennom et filter av designprinsipper.

Diagrammet av sandwichen (over) er i skisseform med hensikt: den vil endre seg. Etterhvert som designprosessen går fremover, oppstår det uungåelige komplikasjoner. Krav fra klienter endrer seg, man får ny forståelse av gammel informasjon, testing gir ny informasjon, og så videre.

Det er imidlertid viktig å ikke skrinlegge idéen om parti når ting endrer seg, men bare en dårlig designer vil forsøke å holde på en mislykket parti…

Luke hadde spennende poenger i sine referanser til arkitektur, jeg rakk ikke notere alle. Men når han forsøker å gjøre et rammeverk ut av dette, sitter jeg heller igjen med en følelse av at de har erfart hvordan de har arbeidet i ettertid og funnet en modell som beskriver det, heller enn at han tilfører noe nytt med en sandwich-modell som andre kan gjøre samme tilnærming med.

Idéen bak parti kan like gjerne kalles arbeid med konseptuelle modeller. Det er helt grunnleggende i både interaksjonsdesign, det interessante er at Luke finner parareller til andre praktikere og at vi kan lære av hverandre.

Redesign av Yahoo er et enormt arbeid, med mange designere og interessenter som ønsker å være synlig med sitt arbeid. Da er det ryddig for alle å ha definerte patterns og best practice å forholde seg til. Jeg sitter igjen med en følelse av at i den grad sandwich-modellen har verdi for andre er det for prosjekter som har stort omfang og mange deltakere.

Apropos Yahoo og pageviews: Å være den mest besøkte nettsiden er ikke nødvendigvis positivt, denne illustrasjonen viser forsiden til Yahoo og Google fra 1996 til 2005. Google og Yahoo har to vidt forskjellige designstrategier: Google sender deg videre, Yahoo vil holde deg innenfor en portal. Clicks vs pageviews.

Har du kommentarer eller spørsmål til oppsummeringen, bruk kommentarfeltet :-)

Interaction design is not about computing technology

Technology is not our medium - behaviour is

Datamaskiner brukes for mye som eksempler på hva teknologien kan gjøre, vi låser oss selv til teknologiens begrensninger.

Interaksjonsdesigner har en universell tiltrekning til datavisualisering. Han viser eksempler fra sitt eget liv og hvordan han forsøker å illustrere sitt eget familietre med penn og papir. Det er akkurat som om interaksjonsdesignere har et gen som handler om å overføre informasjon til visuelle fremstillingersom skal gjøre informasjonen lettere å forstå. Dette preger også arbeidet vårt.

Han viser flere eksempler på teknologi som skal gjøre hverdagen bedre og hvordan denne preges av grafer, tabeller og tall. Noen forsøker å lage nye metaforer, han viser “grønn teknologi” og bruken av trær, planter og blader til å visualisere friskt, sunt, miljøvennlig, osv.

Frog Design har jobbet med en dings som skal hjelpe brukeren å stresse ned. Dingsen monitorerer fysiologiske data som hjerteslag over tid og skal gi feedback til brukeren om stressnivå.

I dette arbeidet møtte de problemer med å motivere brukerne. Uansett hvor mye arbeid de la i den visuelle presentasjon av stressnivået til brukeren, klarte de ikke å motivere til bruken av den. Metaforene de hadde brukt - fra grafer og diagrammer til fugler, skyer og trær - fungerte ikke. Brukerne likte det de så, men de fikk ikke brukerne til å ville bruke den.

Hvorfor ikke?

Arbeidet ble gjort etter en tradisjonell modell basert på sporing av data, måling og analyse: Hvordan presentere informasjon og data på en forståelig måte? Dette fungerer ikke for slike tjenester/produkter.

Vi trenger en ny modell, fortsetter han og viser bilder av:

• neglelakk som smaker vondt
• en sykkelsti hvor lys i bakken viser hvor veien går
• stikkontakter som ser ut som gullrøtter med det grønne som vokser ut ettersom den blir stående i stikkontakten

I arbeid med design er det viktig å bruke effekter som folk kan oppfatte.

Han viser et speedometer hvor nålen bøyer seg når du kjører lite effektivt - det er et ekstremt tydelig design, fordi nålen oppfører seg unormalt.

Hvorfor ikke bruke et bilde av ansiktet til Dick Cheney på en strømkontakt som forteller om strømforbruket ditt - “han har gjort så mye skadelig for oss.” For å demonstrere hvordan slike plugger er designet i dag viser han et stikkontakt med et display hvor en bitteliten stjerne skal fortelle brukeren at han er flink.

Designere må lage bedre belønningssystemer enn det… Ikke skrem brukerne, men gi de belønninger. I hverdagen får vi belønning i enkle ting som kaffe, alkohol og nikotin. Designere må arbeide for å redusere kompleksiteten i budskapet sitt, vi er faretruende nær å overvelde brukere med informasjon.

Så snakker han om Consumer Driven Health Care og patientslikeme.com. Slipp styrken til forbrukerne løs ved å inkludere de. Vi er sosiale vesener, la folk sammenlikne seg med hverandre.

Hva med å gi en oversikt over strømforbruket ditt sammenliknet med resten av nabolaget? Ikke hvordan du står i forhold til resten av nabolaget, men hvordan du forbruker strøm i forhold til de som er flinke i nabolaget ditt. Det er motiverende.

I sosialomsorgen er det mye snakk om hvor viktig ringen av mennesker rundt pasienten er. Disse må også inkluderes i helsearbeidet fordi de blir påvirket av pasientens situasjon. Det er viktig både for pasienten og for menneskene rundt.

Gammel modell: sporing, måling og analyse (tracking, measurement & analysis)

Ny modell: aktualitet, innflytelse og omfang (immediacy, influence & impact)

I jakten etter en modell som beskriver disse tankene bedre kom han over Jess McMulling sitt rammeverk.

Hvordan kan vi måle omfanget av det vi gjør?

Han forteller om Prosjekt Masiluleke. Designarbeidet hadde som hensikt å gjøre det enklere for Sør-Afrikanere å teste seg for hiv, både sosialt og praktisk, slik at helsemyndighetene kan gjøre opplysningsarbeidet enklere og følge opp smittede bedre. De har tidligere hatt problemer med å nå ut til særlig menn, noe prosjektet har gjort enklere. Historien er sterk, han gir mye plass til den i foredraget.

Budskapet er at design kan og bør påvirke, og at det er menneskers adferd og oppførsel som er vårt medium.

Sustainability: our problem

Fabricant tok videre det John Tackara fokuserte på i sitt foredrag: bransjen må fokusere mer på nye designemner med bærekraftighet som hovedmål. Prosjekt M var et godt case i så måte. Fabricant var praktisk og inkluderte flere tanker og problemer de hadde hatt underveis i foredraget sitt. Selv om ikke alle prosjekter vil ha likt omfang som Prosjekt M eller de prosjektene Tackara mener designere bør konsentrere seg om, har Fabricant gode innspill på hvordan involvere brukere i design av engasjerende tjenester og produkter, og hva som skal til for at de motiveres for å ta disse i bruk.

Foredraget var først og fremst inspirerende, i takt med de linjene hovedforedragene hadde. Med det var også en idévekker i forhold til hvordan alt fra lokale tjenester som vektklubber og klimaklubber, til helseinformatikk, kommunal resirkulering og enøk-tiltak kan utformes. Og hva som skal til.

Har du kommentarer eller spørsmål til oppsummeringene, legg gjerne igjen en kommentar…

• Bli introdusert til designskissing
• Utforske hva designskissing er og hvordan det er forskjellig fra kunsttegning
• Lære quick and dirty teknikker for å vise mennesker, ting, steder og idéer
• Bli kjent med scenarioskissing
• Ta del i et prosjekt med gruppetegning

Jeg har aldri vært god med pen og papir (bokser og piler, ok pluss; mennesker og steder, under ok minus) så dette var etterlengtet. For noen kunne denne workshoppen virke noe banal, men det var både teknisk datautdannede, designere og tradisjonelt kunstutdannede tilstede. Kanskje noen hadde godt av en oppfriskning?

Jeg tok ikke mange notater, men rakk å gjøre mange streker. Å skisse var tross alt hovedbudskapet.

Dette lærte jeg:

• Varm opp før du skal tegne
• Hold blyanten/pennen løst i hånden
• Tegn ved å trekke blyanten inn mot kroppen, pull - ikke push
• Øv deg på å tegne rette streker, rektangler, kuber, sirkler, elipser, sylindre og elipser
• Samme om du tegner sirkler mot eller med klokken, la pennen flyte over arket 2-3 ganger før du setter ned tuppen
• Ha en skissebok med deg overalt
• Tegn hele tiden
• Skissing er prosess

Å tegne kuber i dimensjon er visst hyperviktig å kunne. Du øver deg på å skisse i dimensjon ved å øve på enkle kuber, og det vil hjelpe deg å kunne visualisere dimensjoner i f.eks. scenarioskisser.

Det er viktige at alle som jobber med design kan å tegne mennesker (Mark). Klienter som ser en som jobber med design tegne strekmennesker, tenker: “Det der kan jeg også gjøre”. Derfor øvde vi på tegne mennesker tegne annerledes mennesker.

Når du skal tegne storyboards/scenario:

• Hva er bevegelsene?
• Hva er produktaktiviteten?
• Hva er proporsjonene?

Se etter:

• Viktige øyeblikk: hovedhandlinger, definable, designable
• Sekvens: interaksjoner over tid
• Anvendelser: recording/capturing key moments
• Visuell historiefortelling: begynnelse, midten, slutt

Tegn i flere nivåer: bruk det språket du trenger
Etabler et språk for seeren: ikoner, bilder, bevegelser.
Tenk inngangspunkt og retning: stort og tydelig hvor du begynner

Skiss gjerne små miniatyrer før du begynner på større tegninger, visualiser deg for deg og tilfør det som trengs for å få frem budskapet.

Vi fikk et ark som kunne vært til hjelp når man arbeider med scenarioskissing. Arket (se bildet) har tre kollonner, hver med rader for ulike oppgaver. Oppgavene er hensiktsmessige både i prosessen med å visualisere et scenario, men også til å kunne kommunisere mellom hverandre hvis man er flere som arbeider. Siden oppgavene er en sekvens, skriver jeg de ned her, du trenger ikke arket for å jobbe på den måten.

Events: List out the key points of interaction that can be design for
Inventory of elements: List the key objects, people, elements, that shape this interaction
Statement:Write a brief summary statement to focus and inform the sketch
Sketch: Draw this interaction from a key viewpoint. Integrate people, elements, objects and context to creat a compelling scene
Alternative view thumbnail sketches: Draw this interaction from multiple angels. Play with scale, cropping, proximity and detail

Denne workshoppen var akkurat så hands-on som jeg håpet den var. Selv om jeg ikke tegner hver dag, tenker jeg at jeg har blitt litt flinkere til å tegne. Vil legge til at foredragsholderne brukte også mye foto i arbeidet sitt med å forstå aktiviteter og å gjengi de. Men for å bli god til å skisse, må man øve.

Nedenfor er resultatet av vår gruppetegning. Vi er lei av å måtte vaske klær (selvsagt), men hvorfor må man ha i vaskemiddel for hver vask? Dette var et steg av en idé om at vaskemaskiner bør ha en vaskemiddeldispenser som posjonerer riktig mengde vaskemiddel og at man bare trenger å fylle den med vaskemiddel ca. en gang i måneden.

Han er skikkelig god på eksempler og er flink til å vise hvordan ting kunne vært gjort annerledes i stedet for la det være med kritikken på skjema han kommer over. Han la opp sesjonen slik at vi fikk presentert et skjema og litt tid til å ramse opp mangler og feil ved det. Gjennom resten av foredraget hadde vi deretter bingo. Jeg vant en utgave av boka hans. Yay!

Nedenfor lister jeg opp notatene mine fra best practice presentasjonen og lenker til relevante ressurser.

Path to completion

• Skap en tydelig sti mot ferdigjøring
• Bruk progresjonsindikatorer for å kommunisere omfang, status og posisjon
• Hvis det kreves betydlig tid eller oppslag av informasjon, vurder å bruke en startside
• Bruk mer generelle progresjonsindikatorer for skjemaer med variable sekvenser

Hovedmålet med skjema er å fullføre det, det er viktig med en tydelige skannelinje, både for at brukeren ikke skal gå glipp av input og fordi du ved å se skjemaet skal få en oversikt over hva som forventes. Han forteller om en google-folklore som forklarer hvorfor de har en footer nederst på siden: Hvis det ser ut som om siden fortsetter nedeover, skroller gjerne folk. Hvis det ser ut som om siden er sluttet (med en footer) skroller ikke folk. Google satte inn en footer fordi folk trodde at nettstedet brukte ekstremt lang tid på å laste inn, siden den var veldig stor og hvit med uvant lite innhold (gamle dager).

Label alignment

• For å redusere tiden til ferdigjøring og datainput er kjent: top-justert
• Når vertikal skjermplass er en begrensning: høyre-justert
• For ukjent eller avansert dataoppføring: venstre-justert

Se bloggpostene om justering av labels og labler inne i inputfelter.

Help & tips

• Minimer mengden med hjelp og tips som kreves for å fylle ut et skjema
• Nærliggende og synlig hjelp til en dataforespørsel er mest nyttig
• Når folk kanskje er usikre på hvorfor og hvordan svare, vurder et automatisk inline system
• For komplekse eller gjenbrukte skjemaer, vurder bruker-aktiverte systemer
• Bruk inline hjelp om ikke du har mye hjelpinnhold (tekst, grafikk, diagrammer)
• Bruk en konsistent hjelpseksjon hvis du har mye hjelpinnhold

Bruk gjerne mouseover for å vise forklaring til feltene eller dynamiske input-hjelpetekster som hos Wufoo. Bruk pop-up vindu hvis det er mye hjelpetekst, eller seksjoner som hjelp-funksjonen til Windows. På en tidligere versjon av eBay fikk du 18 (!) forskjellige hjelp-innganger når du skulle selge et produkt.

Inline validation

• Bruk inline validering til input som har potensiell høy feilrate
• Bruk foreslått input for å fjerne uklarhet
• Kommuniser begrensninger

Han viser eksempel fra opprettelse av bruker på Twitter. Hvordan du får beskjed om hvor kraftig passordet ditt er, er et annet eksempel. Hvordan de gir brukerne tilbakemelding i Yahoo Answers er et eksempel på god feedback.

Primary & secondary actions

• Unngå sekundær-funksjoner hvis det er mulig
• Imotsatt fall, ivareta en tydelig visuell forskjell mellom primær- og sekundær-funksjoner
• Sammenstill primær-funksjoner med input-feltene for en tydelig sti mot ferdigstilling

Primary action er den viktigste detaljen på skjemasiden, den må stikke ut. Separer den fra andre, bruk farger og tekstlenker for å skille. Hans forskning viser at det er veldig naturlig for brukeren å trykke første knappen nede til venstre. Veldig få trenger å gå tilbake i en wizard, se bloggposten om plassering av knapper.

Actions in progress
Du trenger ikke en egen valg-boks til å huke av at brukeren godtar avtalen, eller lignende, la det være en del av submit-aktiviteten. Ikke deaktiver submit-knappen, la den være synlig hele tiden.

Errors

• Kommuniser tydelig at en feil har oppstått: topplassering, med visuell kontrast
• Sørg for at feilene får handlingsgivende hjelpemidler for å rette opp feilene
• Assosier aktuelle felter med primær feilmelding
• “Fordoble” the visuelle språket der hvor feil har oppstått

De må være synlige, gi god hjelp og bruk dobbelt visuelle formateringer, både farge og tyngde. Husk at noen brukere er fargeblinde. Toppnivå beskjed samt en indikering på hvilket felt det gjelder.

Unnecessary inputs
Fjern unødvendige inputfelter. Du trenger foreksempel ikke oppgi hvilket kredittkort det skal betales med, da tallene på kredittkortet gir denne informasjonen. Se bloggposten om internasjonale adressefelter i webskjemaer. Trenger en bruker oppgi både fullt navn, epostadresse og lage et brukernavn ved førstegangsregistrering av en tjeneste? Nei, rensk bort og ta hensyn til det viktigste.

Form organizations

• Ta deg tid til å evaluere hvert spørsmål du spør
• Forsikre deg om at skjemaet snakker med en stemme
• Etterstreb konsistens
• Hvis et skjema naturlig brytes opp i noen få korte emner, bruk én nettside
• Hvis et skjema inneholder et stort antall spørsmål som bare relaterer seg til hverandre med få emner, prøv sammensatte nettsider
• Hvis et skjema inneholder et stort antall spørsmål relatert til et enkelt tema, bruk en lang nettside

Ikke vreng organisasjonen i et skjema. Før en samtale med brukeren. Han demonstrerer hvordan et enkelt kontakt oss-skjema kan gå fra fint til forferdelig etter at forskjellige avdelinger av en organisasjon får være med å forme det.

Gradual engagement

• Prøv å unngå registreringsskjemaer
• Reflektér tjenesten din sin hovedessens gjennom enkle interaksjoner
• Gjør folk vellykket med en gang
• Hvis du autogenerer kontoer, forsikre deg om at de er enkelt tilgjengelig
• Ikke fordel de forskjellige inputfeltene til et registreringsskjema over sammensatte sider

Dependent inputs

• Hvis det er mange avhengige inputs, bruk side-nivå
• Vertikale og horisontale faner yter like bra, men har utfordringer ved gjensidig utelukkelse
• Lang liste med innledende inputs, få avhengige inputs for hver, bruk drop-down meny
• Short list of initial options og få avhengige, exposed inline.
• Oppretthold et tydelig slektskap mellom innledende valgmuligheter
• Assosiér tydelig supplerende inputs med trigger-input
• Unngå “hopping” som atskiller innledende valgmuligheter

Additional inputs

• Planlegg supplerende inputs etter prioriterte brukeres behov
• Mest effektivt når det er brukerinitiert
• Unngå overdreven hopping mellom sider
• Sørg for veier ut
• Oppretthold en konsistent tilnærming

Tanker om fremtiden
Huffduffer bryter helt med skjemeoppstillingen og lar brukeren registrere seg gjennom tekst (lose the form factor).

Sign up forms must die

Nettjenester bør engasjere brukerne, forklar og vis tjenesten, la registreringen være resultatet. La folk begynne å bruke tjenesten din med en gang.

Han demonstrerer ulike familitrenettsteder og hvordan geni.com gjør det annerledes og bedre fordi de lar brukeren begynne å lage et familietre med en gang. Første handling knyttes til det du egentlig vil lage/har kommet til nettstedet for å gjøre

Tilsvarende jumpcut.com, hvor du lærer tjenesten ved å bruke den (nå er riktig nok jumpcut lagt ned…). Patientslike.me har også en annerledes og god start på tjenesten, du velger ditt utgangspunkt og får registreringsvalget senere
.

Tripit er en annen tjeneste du lærer ved å bruke: send reiseplanene til de på epost og du får inntrykk av hvordan tjenesten virker.

Han mener også at tjenester bør bli flinkere til å finne “smart defaults”, altså forhåndsutfylte valg som dekker 80% av tilfellene. Særlig reiseselskaper kan bli flinkere til dette, enten ved å lese hvor den besøkende befinner seg og foreslå det som utgangspunkt, eller huske “typiske reisestrekninger” brukeren gjør.

Han nevner videopplastning på youtube som et eksempel på veldig godt skjema der de har forstått brukerens aktivitet. Dette skjemaet var et skjemavelde før, tungvindt og omfattende, hvor masse detaljer om videoen skulle fylles ut før du fikk laste opp videoen. Nå har de snudd helt og ber de laste opp videoen med en gang. Mens den laster i bakgrunnen fyller du ut de elementære feltene, og kan velge å legge til mer informasjon når videoen er ferdig lastet. Youtube har revidert dette skjemaet i 3 år.

Han har holdt foredrag om skjemadesign i mange sammenhenger, og selv om jeg ikke hadde lest hele boka, kjente jeg til resultatene fra arbeidet deres blant annet gjennom bloggen hans. 4-timers workshop i skjemadesign forventet jeg dermed hadde litt flere elementer ved seg enn oppramsing av best practice, og var derfor litt skuffet at vi ikke hadde mer hands-on praktiske oppgaver. Men han har som nevnt gode eksempler og best practice er veldig nyttig i skjemadesign fordi det er ofte veldig konkret.

Vi fikk stille spørsmål og diskutere momenter. Han passet på å føye til “it depends…” ofte både under presentasjonen og diskusjonen fordi skjemadesign er ikke rett frem. Og som han sa: “Jeg får ofte spørsmål fra folk som sier at disse best practice ikke går an å bruke på deres skjemaer, fordi skjemaene er skikkelig kompliserte. Hvis du tenker at du gjør noe skikkelig komplisert og står fast ved det, har du i utgangspunktet et problem. Du må i tilfelle jobbe ekstra hardt for å gjøre det enkelt.”

Se også eksempler fra presentasjon han har gjort tilgjengelig tidligere på bloggen sin (pdf).