User experience

La meg introdusere deg for et lite prosjekt jeg har begynt (og sluttet) på mange ganger i løpet av årene som har gått, men som nå endelig har resultert i noe som i alle fall virker. Si hei til WebREPL!

WebREPL er et multipurpose, HTML/JavaScript-basert terminal-interface. Det består rett og slett av et lite JavaScript som man kan inkludere i siden sin for å få en kommandolinje. Scriptet er helt “dumt”, og kan ikke gjøre annet enn å ta imot input fra brukeren og sende det videre til en funksjon som man har plugget inn. Poenget var å lage noe som er gjenbrukbart, og jeg ser for meg mange potensielle brukstilfeller.

En mulighet er å bruke den som et admin-grensesnitt på en web app, og la den sende kommandoer ned til serveren for eksempel via et JSON API – det er jo enkelt. Jeg kunne også godt tenke meg å lage et tekstbasert spill igjen (jepp, jeg er old school). Eller hva med en Eliza-klone som kan hjelpe deg å debugge programmeringsutfordringer når du ikke har noen kollegaer eller gummiender tilgjengelig?

Jeg har publisert en inntil videre ganske basic online demo du kan ta en titt på (se også skjermdump nedenfor). Ellers finner du prosjektet på Github.

Det er altså ikke særlig avanserte greier dette her, men det er noe jeg har hatt lyst på lenge. Det finnes mange som har gjort det før, men de jeg har funnet er enten hardt knyttet til det bruksområdet de er laget for (f.eks. online ssh-terminal mot Linux) eller de er lite fleksible rent utseendemessig. WebREPL er ingen av delene.

Det jeg kommer til å jobbe videre med er å lage et bedre API for å knytte opp handler-funksjoner mot terminalen. WebREPL kan for eksempel stå for mer av input-parsingen – det vil gjøre den enklere å bruke. Det er også mulig jeg vil forsøke å legge på litt mere bling-bling muligheter i brukergrensesnittet, men det kommer ikke til å bli mye.

Jeg har ikke skrevet noen dokumentasjon enda, men kilden til demoen er kanskje godt nok foreløpig? Så hvis du elsker kommandolinjen, mener musen er en håpløs oppfinnelse, og synes dette virker interessant, så må du ta en titt!

Håvard Kvinnesland er en god venn – min forlover faktisk – men også en kunnskapsrik person. Han har programmeringsbakgrunn, men har funnet ut at hans evner er best utnyttet i andre roller. Han forstår nerden, men han forstår også kunden og ikke minst sluttbrukeren. Og budskapet han presenterer i dagens adventsluke er meget viktig…

Hvem er du?
Nysgjerrig og rastløs fyr fra vestlandet. Oppriktig interessert i nesten alt.

Hva er jobben din?
Fagansvarlig for elektronisk kommunikasjon i Bring Dialog.

Hva kan du?
Snakke forståelig med både utviklere og ikke-teknikere, lage djevelsk god ostekake og er ganske flink til å svømme.

Hva liker du best med yrket ditt?
Jeg får jobbe med flere av de aller største bedriftene i landet. Dessuten får jeg plage utviklere, designere, selgere og markedsførere hver eneste dag.

“Features are meaningless. They mean nothing to users. A coherent product user interface IS the product to users” Kim Goodwin

En av de tingene som sjokkerte meg mest da jeg for 5 år siden sluttet å programmere var hvor lite mine løsninger hadde å si for en sluttbruker. Eller rettere sagt; hvor lite en ellers god funksjon er verdt når den ikke gir riktig brukeropplevelse. Jeg var selvsagt til en viss grad oppmerksom på verdien av godt design og prosessflyt, men det tok ikke mange observasjonsdager med brukere før jeg måtte revurdere verdensbildet mitt.

Det er få ting som er så ydmykende som å se hvor klønete selv den beste prosessflyten er dersom brukeren for eksempel ikke kan gjøre noe i den rekkefølgen det er tenkt. Å se uker med arbeid, tanker og glede over å finne gode løsninger bli redusert til frustrerende ubrukelig søppel på grunn av detaljer er en skjellsettende opplevelse.

Sett av tid til å besøke kunder. Observer hvordan systemet ditt faktisk brukes i det virkelige liv. Det er definitivt verdt tiden.

Kostnadseffektiviteten av å bruke tid og penger på brukeropplevelsen må naturligvis sees i lys av nødvendig kompleksitet og størrelsen på/kompetansen til brukerbasen, men har du brukere kan du, uansett hva du lager, ikke IKKE ha brukeropplevelse. Opplevelse er uunngåelig, spørsmålet er hvor bevisst man er i byggeprosessen.

Med det som bakteppe kan jeg like gjerne kline til med en grov generalisering:

• Dersom brukeren ikke finner funksjonen, eksisterer den ikke
• Forstår han den ikke, er den ødelagt
• Er han ikke hundre prosent sikker på utfallet av å bruke den, er den verdiløs

Spesielt forståelsen og tryggheten er noe man ikke kan løse alene fra designsiden så det er dette jeg har lyst til å fokusere på.

Målet er å gi en forståelse for prioriteringene som foregår på utsiden av det rent tekniske, og å indikere at det ikke alltid er snakk om inkompetanse når designere og oppdragsgivere insisterer på å gå for en løsning som strengt tatt ikke er teknisk riktig.

Forhåpentligvis er ikke dette ny og upløyd mark, så det jeg sikter mot er at du tar en ekstra titt på din egen stol før du avviser noe som PEBKAC.

Først, hva er UX?

ISO 9241-210 definerer user experience (UX) slik: “a person’s perceptions and responses that result from the use or anticipated use of a product, system or service”.

Definisjonen ligger jo selvsagt i ordet, så personlig liker jeg å sette det i et litt mer spesifikt softwareperspektiv:

• Informasjonsarkitekturen definerer den grunnleggende formen og flyten av data
• Interaksjonsdesignet skal gjøre det mulig å behandle og absorbere informasjonen.
• Det visuelle designet skal presentere og fasilitere samhandlingen mellom disse
• Brukeropplevelsen er …

… den subjektive summen av alt.

Nøkkelordet her er “subjektiv”, du programmerer og designeren designer for den følelsen sluttbrukeren sitter igjen med. For mange kan det være en fremmed tanke, det var det i alle fall for meg i begynnelsen. Vi snakker tross alt om algoritmer, matematikk og logikk, omtrent så langt fra følelser man kan komme. Dessverre kan man ikke se logikken i en brukers reaksjonsmønster uten å forstå hvilken motivasjon og hvilke følelser han sitter med.

Her finnes det jo selvfølgelig ingen generell mal å følge, men et godt utgangspunkt er følelsen av trygghet. Klarer du i første rekke å gjøre systemet til noe som oppfattes som en trygg lekeplass er turen til entusiasme, begeistring og kreativitet mye kortere.

Veien til trygghet er heldigvis ikke veldig lang, og kan kort sagt oppsummeres med at kunden sitter igjen med følgende inntrykk:

1. Jeg kan ikke ødelegge noe
2. Jeg kan ikke glemme noe viktig
3. Jeg vet hva som skjer når jeg trykker på den knappen

For hakket mer krevende systemer med kan punktene oppjusteres til:

1. Jeg vet/får vite når jeg gjør endringer som har permanente konsekvenser
2. Jeg minnes på eventuelle forglemmelser som kan gi utslag
3. Jeg vet konsekvensene av å trykke på den knappen

Dette er åpenbare punkter, men husk at det er snakk om brukerens opplevde trygghet, ikke hva du synes.

Selv om veien dit er ganske kort er det også noen skjær i sjøen. Det viktigste punktet er som i alle forhold: Bryter du den tilliten du har fått hos brukeren kan du ødelegge tryggheten til hele systemet. Brukeropplevelsen må tenkes som helhet i alle ledd.

“Know the user. You are NOT the user” Arnie Lund

Den første kommersielle mp3-spilleren ble lansert i 1997 og i løpet av de første par årene var konkurranseparameterne selskapene imellom stort sett pris, antall megabyte, innstillinger for lydbilde og generell lydkvalitet. Brukermassen besto I stor grad av deg og meg, teknisk kompetente personer som ikke hadde problemer med å forstå filstruktur og hva det vil si å mounte en ekstern disk.

I 2001 anslo analysebyrået International Data Corporation (IDC) det globale markedet for portable MP3spillere hadde et potensiale på ca 18 millioner enheter frem til 2006, men i 2005 ble det solgt 32 millioner iPoder.

Hva skjedde?

Da Apple kom på banen sent i 2001 snakket Steve Jobs konsekvent om en iPod som et elektronisk smykke og at overføringen av musikk var automatisk, at du kan ikke gjøre noe galt. Det aller meste av kommunikasjon gikk på hvor lett det var å bruke en iPod.

All kritikk om dårlig lyd ble avvist med at de aller færreste av oss er audiofile. Kritikken av det proprietære filformatet ble blankt avvist med at under 5 % av markedet vet hva et filformat er. De fem prosentene var alle som frem til da var interessert i å ha en mp3spiller, og som dannet grunnlaget for IDCs analyse.

En av Apples mange genistreker var at de definerte brukeren, og dermed hele markedet og konkurranseparameterne helt annerledes enn analysebyråer, Sony, Creative og de andre konkurrentene.

New york Times’ noe avmålte artikkel fra lanseringsdagen er ganske artig lesestoff i etterpåklokskapens lys.

Men hva har Apple med min jobb å gjøre?

Vi vet alle hva vi liker selv, og er alle ubevisste «eksperter» på grensesnitt på den måten at vi vet hvordan vi vil ting skal løses og fungere. Som teknikere er det fryktelig lett å overse at vår logikk, våre tekniske preferanser og fortrolighet med problemløsning ikke gjelder resten av befolkningen.

Klarer du derimot å ta et steg tilbake og jobbe bevisst mot å gjøre brukeren trygg gjør du ikke bare salgsjobben enklere, men du skaffer deg selv også svært lojale kunder. Det skal utrolig mye til, både på pris og funksjon for å overtale en bruker til å bytte ut et system han er trygg på.

Crowdsourcing har vært et hot begrep lenge, men det er først nå i det siste at vi virkelig har begynt å se mange bedrifter etablere seg basert på denne modellen.

Prinsippet er å distribuere problemløsing og produksjon; en oppgave kringkastes til stor gruppe ukjente problemløsere – amatører og frivillige, eller gjerne også profesjonelle. Enkeltpersonene i denne gruppen, the crowd, leverer hver sin løsning. Gruppen kan også brukes til å stemme frem de beste løsningene. Disse blir så levert til oppdragsgiveren, the crowdsourcer, og den/de som vant blir kompansert – enten med penger, en pris, kudos, eller annen form for belønning.

Fordelene ved crowdsourcing kan være at problemer kan løses raskt, og til en relativt lav pris pga. stor konkurranse. Man betaler kun for resultater, og som oppdragsgiver kan man utnytte talentet til mange flere personer enn man tradisjonelt sett kan ansette selv.

Det finnes som oftest tre ulike parter innenfor crowdsourcing, illustrert i tegningen over, og alle posisjonene i modellen er interessante. Som profesjonell utvikler kan jeg utnytte crowds til å levere verdi for meg på en kostnadseffektiv måte. Som et individ med kunnskaper og fritid kan jeg også bli medlem av et crowd community, og kanskje tjene litt penger på småoppdrag som distribueres til alle medlemmene. Og som en person interessert i inovasjon og nettverksbygging høres det utrolig spennende ut å fasilitere crowdsourcing, og å kunne høste en fortjeneste på å formidle oppdrag.

Den siste tiden har jeg blitt oppmerksom på flere, nystartede firmaer som tilbyr softwaretesting basert på crowdsourcing. Her er noen tjenester man ikke bør overse i disse trange tider:

Testcrowd 1: uTest
uTest gir deg et virtuelt QA team når du trenger det. Nettverket består for tiden av over 16 tusen testere. Du gjør tilgjengelig det som skal testes, f.eks. linken til en testsite, og beskriver gjerne hva som skal testes og eventuelt hvordan. Du betaler kun for bugs som blir funnet (etter at du har kontrollert dem), og du kan også lage en liste med kjente feil, slik at du ikke trenger å betale for ting du vet om på forhånd.

Testerne bygger opp en kvalitets-score, og som oppdragsgiver kan du spesifisere hvilken type testere du ønsker, hvor mange, hvor lenge de skal teste, osv. Startup Success Podcast #22 går i dybden på uTest, og diskuterer også hvordan man bygger et crowd community. Meget insteressant.

Testcrowd 2: UserTesting
Dette nettverket har spesialisert seg på usability testing. Dette er en form for testing som ofte er vanskelig å få til selv, og som normalt koster mye tid og penger om det skal gjøres skikkelig. For 29 dollar tilbyr UserTesting en video av en tester som bruker websiten din mens han forteller hva han opplever, samt en skriftelig oppsummering hvor testeren forteller hva han likte, ikke likte, osv.

Last gjerne ned Startup Success Podcast #20, som går i dybden på UserTesting.com.

Testcrowd 3: BrowserMob
Dette er en litt annen form for crowdsourcing. Kanskje er det mer riktig å kalle det cloudsourcing. BrowserMob automatiserer load-testing av websiden din ved hjelp av virtualisering, og viser deg nøyaktig hvordan siden oppfører seg i ulike browsere under høy last. Startup Success Podcast #18 intervjuer Patrick Lightbody som står bak BrowserMob.com, så lytt gjerne på det hvis du er insteressert.

Mange andre typer crowdsourcing..

Sammen med en kollega har jeg forsøkt meg litt på et crowdsourcing-konsept selv også, nemlig The Forecast Exchange, hvor man kan tappe kunnskapen til en gruppe mennesker for å spå om fremtiden. Nå i mai kjører vi andre runde med beta-testing, og tar du en titt på forsiden kan du se hvor stor tro brukerne har bl.a. på hvordan det vil gå med den norske børsen fremover, om Liverpool kommer på andreplass i premiere league, og om Norge vinner melodi grand prix.

Ting som Open Source Software, Wikipedia og StackOverflow er også varianter av crowdsourcing. Uservoice, som vi bruker på Forecast Exchange, er en crowdsource facilitator som gjør det mulig for oss å få tilbakemelding fra brukerne om hva de vil ha i produktet fremover. 99designs er et crowdsourcing community hvor du kan legge opp en konkurranse for grafiske designere, hvor folk konkurrerer om å komme opp med et design som du er villig til å betale for.

Er du interessert i flere slike crowds kan du ta en titt på denne listen fra Open Innovators over plattformer og tjenester. Crowdsourcing i ulike former er fremtiden. Det betyr mindre og mindre hvor man befinner seg i verden, og de som klarer å tappe kunnskap og talent over internett vil komme seirende ut av de komende årene. Dette er et utrolig spennende felt, og jeg gleder meg til å se mange, nye måter å utnytte dette på fremover.

Jeg jobber i et software-selskap (eller ISV om du vil) som heter CMA Contiki. Vi lager en enterprise contract management løsning som brukes av kunder over hele verden – av selskaper som Total, Halliburton, ConocoPhillips og Telenor.

Contiki ECM versjon 6, som er det jeg har jobbet med i snart 3 år, har hele tiden vært et veldig fleksibelt produkt som i stor grad kan tilpasses ulike kunder – bl.a. gjennom en egenprodusert workflow-løsning. Rapportering har også vært en sentral del, og vi hadde bygget inn XtraReports fra DevExpress i klienten vår for å kunne gi kundene en fleksibel rapporteringsløsning.

Nå har vi derimot gått bort fra denne løsningen, og i versjon 6.6 vil våre kunder få et produkt som er fullt integrert med SQL Server Reporting Services (SSRS) fra Microsoft. Vi tror både vi og kundene vil tjene på dette, siden SSRS er en mer kjent løsning som mange allerede har erfaring med.

Vi lar selvsagt kundene definere opp og tilgjengeligjøre alle de rapportene de selv ønsker, men vi har også valgt å ta et ekstra steg og bytter nå ut enkelte, sentrale skjermbilder i klienten vår med SSRS rapporter.

Contiki ECM: Standard contract summary

I skjermdumpen over ser du Contiki ECM versjon 6.5, hvor jeg har åpnet hovedbildet for en kontrakt. Det inneholder 6 faner (til høyre i bildet) hvor man får tilgang til nøkkeldata om kontrakten. Ulempen er at ulike kunder er interessert i ulike ting, og vi skulle derfor hatt en måte å tilpasse dette skjermbildet på. Derfor jobber vi nå med å bytte ut dette bildet..

Contiki ECM: Custom contract summary with SSRS

Skjermdumpen over viser det samme oversiktsbildet for kontrakt, men denne gangen er den en SSRS rapport som lastes. Denne kan enkelt skreddersys til å vise akkurat de dataene kunden er mest opptatt av – de som er viktigst for dem. Takket være vårt konfigurasjonssystem kan man velge å vise ulike skjermbilder (dvs. rapporter) for ulike avdelinger (f.eks. markedsavdelingen kontra innkjøpsavdelingen), eller til og med for enkeltbrukere – CEO kan få sitt helt eget oversiktsbilde for kontrakter.

Som du kanskje ser gjenstår det litt på designet, men det er en smal sak. Vi har lagt mye arbeid ned i integrasjonen, for eksempel for å knytte SSRS mot vårt ACL system, slik at brukerne bare får tilgang til data de skal ha tilgang til.

Contiki ECM: Standard commercial commitment

Her ser du et annet skjermbildet vi ønsker å bytte ut. I bildet over ser du de komersielle dataene for en kontrakt slik det ser ut i versjon 6.5 og tidligere. Her har kundene meget varierende behov, og vi velger derfor å gå for en rapport (bildet nedenfor) som kan tilpasses.

Contiki ECM: Commercial commitment with SSRS

Denne strategien betyr også mere arbeid for våre konsulenter, som vil tilpasse skjermbildene og også lage nye rapporter for kundene. Erfaringen sålangt er bra, og kunsulentene har raskt lært seg å jobbe med SQL Server og Reporting Services. En bi-effekt er muligens at utviklerne ikke har behovet for å forstå kundenes behov i samme detaljgrad, som kanskje også vil kunne øke effektiviteten i utviklingen noe.

For å muligjøre en så tett integrasjon som mulig mellom rapportene og klienten vår har vi også utviklet funksjonalitet får å kunne klikke på linker i rapportene som navigerer til objekter i klienten. Vi har implementert en egen Contiki-protokoll som gjør at vi kan lage linker som f.eks. contiki://open/contract/id/1234 – som vil åpne kontrakten med id 1234. Slik blir rapportene er helt naturlig del av grensesnittet.

Vi bruker selvsagt også SSRS-integrasjonen i webklienten vår, som har vært mitt ansvarsområde. Reporting services kommer med Report-viewer for både WinForms og WebForms.

Jeg mener det har vært et lite genitrekk å knytte rapportene så tett inn i løsningen vår. Etterhvert som vi implementerer rapport-muligheter flere og flere steder i klienten, vil kundene kunne tilpasse produktet mere og mere til akkurat det de trenger, uten at vi behøver å øke kompleksiteten i det vi leverer. Nå gjenstår det bare å gjøre Contiki skriptbart, så kan vi slutte å kode selv også :)

Knagger: Contiki, SQL Server.

Som jeg har nevnt tidligere er jeg – med min bakgrunn fra e-læring – nokså interessert i One Laptop per Child prosjektet til Nicholas Negroponte. Jeff Atwood forteller i bloggen sin Coding Horror om Sugar UI – det nye brukergrensesnittet som utvikles til 100-dollar-laptopen, som blir noe ganske anderledes enn det vi er vandt til fra Windows/Mac/Linux. Nettopp fordi at de potesnielle brukerne av laptoppen sansynligvis vil ha liten eller ingen erfaring med konvensjonelle brukergrensesnitt så har man kunnet tenke helt nytt, og man forsøker her å finne frem til det intuitivt riktige grensesnittet for et barn.