Joel on Software

Joel on Software Joel om mjukvara

 

Användargränssnitt för programmerare
Kapitel1
Kapitel2
Kapitel3
Kapitel4
Kapitel5
Kapitel6
Kapitel7
Kapitel8
Kapitel9

Andra "Joel on Software"-artiklar på svenska

Andra "Joel on Software"-artiklar på engelska

Skicka e-post till författaren (enbart engelska)

 

Användargränssnitt för programmerare
Kapitel2: Att ta reda på vad de förväntade sig


Av Joel Spolsky
Översatt av Lennart Pettersson
11 april 2000

När nya användare sätter sig ner för första gången med ett program börjar de inte från noll. De har någon form av föreställning om hur programmet bör fungera. Om de har använt liknande program förut kommer de att anta att det fungerar ungefär som det programmet. Om de över huvud taget har använt något program tidigare kommer de att utgå från att även ditt program följer vissa gemensamma konventioner. De kanske har några kvalificerade gissningar om hur användargränssnittet beter sig. Allt sammantaget kallas detta för användarmodellen; det är användarnas mentala modell av vad programmet gör.

Programmet har också en "modell" av sig självt, en som är kodad i ettor och nollor och lydigt utförs av processorn. Den kallas programmodellen och utgör Lagen. Som vi såg i kapitel 1 så har du fått till ett lyckat gränssnitt om programmodellen sammanfaller med användarmodellen.

Låt oss ta ett exempel. I Microsoft Word (och de flesta andra ordbehandlingsprogram) kopieras en bild som läggs in i ett dokument in i själva dokumentfilen. Du kan skapa bilden, dra in den i dokumentet och sedan kasta originalet; bilden finns ändå kvar i dokumentet.

HTML låter dig inte göra på det viset. HTML-dokument lagrar sina bilder i separata filer. Ta en användare som är van vid Word, men som inte kan ett dugg om HTML, och sätt henne framför en trevlig HTML-editor som till exempel Frontpage. Hon kommer garanterat att utgå från att bilden lagras i HTML-dokumentet. Kalla det "användarmodellens tröghet" om du vill.

Så vi har en olycklig konflikt mellan användarmodell (bilden lagras i dokumentet) och programmodell (bilden lagras i en egen fil), vilket gör att användargränssnittet kommer att ställa till problem för dig som ska konstruera ett program av Frontpage-typ. Du kan inte ändra HTML, så något annat måste ge vika för att du ska få ihop de två modellerna.

En möjlighet är att försöka ändra på användarmodellen, men det är i allmänhet svårare än man tror. Du kan förklara hur det fungerar i manualen, men alla vet att användare inte läser manualen - och egentligen ska de nog inte behöva göra det heller. Du kan visa en dialogruta på skärmen där du förklarar att bildfilen inte lagras i dokumentet, men det ger två nya problem: det irriterar de vana användarna och det är ingen som läser dialogrutor heller (vi kommer tillbaka till det i kapitel 6).

Så om berget vägrar komma till Muhammed ... ditt bästa alternativ är så gott som alltid att ändra programmets beteende, inte användarnas. När de lägger in en bild i dokumentet kanske du ska lägga en kopia av bildfilen i en särskild bildmapp och länka till den, för att leva upp till det förväntade: att bilden kopieras och att originalet därför kan kastas utan problem.

 

Hur vet jag vad som förväntas?

 

Se där en fråga som faktiskt är rätt lätt att få svar på. Fråga dem! Ta fem slumpvis utvalda personer, familj eller vänner eller arbetskamrater, och berätta för dem i allmänna drag vad programmet gör. ("Det är ett program för att göra webbsidor.") Beskriv sedan situationen, att en bild picture.JPG just har lagts in på webbsidan de arbetar med, och ställ frågor för att försöka lista ut hur deras modell av programmet ser ut. "Vart tog bilden vägen?" eller "Vad händer om du kastar picture.JPG?" till exempel.

Jag har en bekant som håller på med ett fotoalbum-program. När man har lagt in sina bilder i albumet visar programmet en rad miniatyrer, små kopior av de verkliga bilderna. Tyvärr tar det en massa tid att skapa miniatyrerna, framför allt om det är många bilder, så han vill lagra dem någonstans på skivminnet så att varje bild bara behöver skapas en gång.

Det går att göra på flera sätt. Alla miniatyrbilder kan lagras i en stor fil som heter Thumbnails, eller så kan de lagras en och en i en mapp som heter Thumbnails. De kan lagras som osynliga filer, så att användarna slipper känna till att de finns. Min bekant valde vad han tyckte var den bästa medelvägen: för varje bild picture.JPG lägger han miniatyrbilden i filen picture_t.JPG i samma mapp. Om du gör ett album med 30 bilder får du alltså en mapp med 60 bildfiler i.

Man kan diskutera för- och nackdelar med olika lösningar i veckor, men det finns som sagt ett mer vetenskapligt sätt att få sitt svar. Fråga ett par användare hur de tror att miniatyrerna sparas. Naturligtvis kommer många att svara att de inte vet eller inte bryr sig, andra att de aldrig har funderat på den saken, men om du frågar tillräckligt många kommer du till sist att hitta någon form av samstämmighet i svaren. Det som folket röstar på är den bästa användarmodellen, och sedan är det upp till dig att få programmet att följa den.

Nästa steg är att testa den sålunda framröstade idén. Bygg en prototyp av ditt tänkta användargränssnitt och låt några testpersoner utföra givna arbetsuppgifter. Fråga dem, medan de arbetar, vad de tror det är som händer. Ditt mål med övningen är att ta reda på vad de förväntar sig, så om uppgiften är "montera in en bild" och du ser att testaren försöker dra in en bildfil i dokumentet så är den givna slutsatsen att du måste implementera drag-och-släpp. Om någon istället letar i Infoga-menyn är det bäst att du ser till att det finns ett Infoga bild-kommando där. Och skulle du se någon som klickar i typsnittspaletten och skriver över "Times New Roman" med "Insert Picture" så vet du att du har hittat en kvarlevande relik från kommandoradstiden.

Hur många personer ska man då låta testa gränssnittet? Det instinktiva svaret är "ju fler, desto bättre", men instinkten har fel. Så gott som alla som sysslar professionellt med användbarhetstester tycks vara överens om att det räcker med fem-sex personer. Sedan brukar svaren börja upprepa sig, så att fler tester egentligen bara blir ett slöseri med tid.

Du behöver inte heller något kontrollerat testlabb, och det är ingen egentlig vits att leta efter slumpvis utvalda personer - det går att göra "budgettester" genom att helt enkelt grabba tag i nästa person du möter i korridoren och be honom eller henne testa programmet. Se bara till att du inte avslöjar hur de ska lösa uppgifterna; be dem istället att tänka högt, och ställ några öppna frågor efteråt för att få dem att beskriva sin mentala modell.

 

Om din programmodell är icke-trivial är den sannolikt inte densamma som användarnas modell

 

När jag var sex år tog min pappa hem en av världens första miniräknare, en HP-35, och försökte övertyga mig om att det satt en dator inuti den. Jag tvivlade. Alla datorer i Star Trek fyllde hela rum och hade stora bandstationer. Jag var övertygad om att det bara var en smart koppling mellan knapparna och lysdioderna i displayen som gjorde att den producerade matematiskt korrekta resultat. (Tänk på att jag bara var sex år!)

Det illustrerar en viktig sak tumregel: användarmodeller är sällan särskilt komplicerade. När människor måste gissa hur ett program fungerar tenderar de att föredra enkla gissningar framför komplicerade. Sätt dig framför en Macintosh. Öppna två Excel-ark och ett Word-dokument. Varenda novis skulle gissa att fönstren på skärmen är oberoende - de ser definitivt oberoende ut:

Användarmodellen säger att ett klick i kalkylark 1 ska lägga det överst. Vad som istället händer är att kalkylark 2 hamnar överst, en obehaglig överraskning för vem som helst:

Orsaken är att Microsoft Excels programmodell säger att "du har de här osynliga lagren, ett per öppen tillämpning, och fönstren är knutna till dessa lager. När du klickar i ett fönster som tillhör Excel-lagret följer alla andra med till förgrunden".

Ahaaa! Osynliga lager! Hur stor är sannolikheten att användarmodellen inbegrep osynliga lager? Troligen noll. Så nya användare kommer definitivt att få en överraskning när de råkar ut för detta beteende.

Ett annat exempel, den här gången från Windows, är Alt-Tab som växlar till "nästa" fönster. De flesta utgår sannolikt från att kommandot helt enkelt roterar mellan alla öppna fönster: om du har fönstren A, B och C (med A överst) så borde ett tryck på Alt-Tab ta dig till B. Ytterligare ett tryck och du kommer till C. Tyvärr inte, det som händer är att det andra trycket tar dig tillbaka till A. Enda sättet att komma till C från A är att hålla ner alt och trycka två gånger på Tab. Som det fungerar är Alt-Tab ett bra sätt att växla mellan två program, men det är det få som lyckas räkna ut eftersom det är en aning mer komplicerat än den enkla rotera-mellan-fönstren-modellen.

Det är svårt nog att få ihop användarmodell och programmodell om modellerna är enkla. När de blir komplicerade är det ännu mindre chans att lyckas. Så välj enklast tänkbara modell för hur ditt program ska fungera.



> Kapitel3

Originalartikelns engelska titel är User Interface Design for Programmers Chapter 2: Figuring Out What They Expected  

Joel Spolsky driver Fog Creek Software, ett litet programvaruföretag i New York. Han har examen från Yale och har arbetat som programmerare och i chefsbefattning på Microsoft, Viacom och Juno.


Innehållet på dessa sidor representerar en enskild persons åsikter.
Allt innehåll är Copyright ©1999-2005  Joel Spolsky. Alla rättigheter är reserverade.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky