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
Kapitel3: Val


Av Joel Spolsky
Översatt av Lennart Pettersson
21 april 2000

När du kommer in på en restaurang och ser en skylt där det står "Inga hundar" kanske du tolkar den som ett enkelt konstaterande: restaurangägaren gillar inte hundar, så han satte upp en skylt om att hundar inte är välkomna.

Men om det vore hela sanningen borde det också finnas en skylt som förbjöd ormar; ingen tycker ju egentligen om ormar. Och en "Inga elefanter", med tanke på att en elefant ofelbart skulle krossa stolarna om han försökte sätta sig ner.

Det finns förstås en historisk orsak till att hundskylten sitter där: gäster har försökt ta med sig hundar in på restaurangen.

De flesta förbudsskyltar sitter där de sitter för att innehavaren tröttnade på att folk gjorde X och satte upp en skylt och bad dem vänligen att inte göra det. Titta gärna in på någon femtioårig lunchsylta, jag tänker till exempel på en i New Haven, och du kommer att finna att väggarna är täcka med förbudsskyltar i stil med "Ställ inte ryggsäckar på disken". Klara antropologiska bevis på att folk brukade göra just det - och av åldern på skylten kan du lista ut när ryggsäckar var populära bland ortens studenter.

Andra skyltar kan vara lite knepigare att se orsaken till. "Förbjudet att ta med glasflaskor in i parken" torde betyda att någon en gång skar sig när han eller hon trampade på en trasig flaska och stämde staden.

Programvara har en liknande historisk minnestavla: den kallas "Inställningar". Öppna Inställningar-dialogrutan i ett program och du kommer att hitta spåren av en rad diskussioner bland programutvecklarna. "Borde vi inte automatiskt öppna den senaste filen som användaren arbetade med? Ja! Nej!" Diskussionen drar ut över två veckor, programmeraren sätter in ett #ifdef i koden bara för att gardera sig medan projektledarna slåss om saken. Till sist bestämmer man sig för att göra det till en Inställning.

Det behvöer inte ens vara en diskussion mellan två personer; den kan lika väl vara ett internt dilemma. Jag kan inte avgöra om databasen ska optimeras för storlek eller sökhastighet. Vare sig debatten är intern eller extern finns det risk att den slutar med något liknande vad jag skulle vilja påstå är den mest korkade "Wizard"-dialogen i hela Windows historia. Den är så dum att den förtjänar någon sorts pris - det skulle behövas en helt ny kategori av priser för att belöna den här typen av dumheter. Jag talar om dialogen som dyker upp när man försöker hitta någonting i Windows hjälpsystem:

Det första problemet med dialogrutan är att den ställer sig ivägen. Du försöker få hjälp genom att leta i hjälpfilen. Du bryr dig för tillfället inte ett dugg om ifall databasen är stor, liten, anpassad eller överdragen med choklad. Men mitt i letandet erbjuder denna lilla elaka dialogruta pedantiska föreläsningar om att den behöver skapa en lista (eller databas). Texten är tre stycken lång, och större delen av den är mest förvirrande. Titta till exempel på den smärtsamt klumpiga formuleringen "your help file(s)" - den gör klart för dig att du kan ha en eller flera hjälfiler. Som om du skulle bry dig om det just nu. Som om det skulle spela någon som helst roll.

Men programmeraren som arbetade med den här dialogen var uppenbarligen väldigt störd av det faktum att det kan finnas mer än en hjälpfil och det vore inkorrekt att skriva "help file", eller hur?

Jag tänker inte ens kommentera det faktum att de flesta användare som söker i hjälpfilen inte är den typen som förstår krångliga datatermer. Eller att inte ens kunniga användare, programmerare som har doktorerat i datavetenskap och vet allt om indexering av text, kan räkna ut vad de olika alternativen innebär.

För att strö salt i såren: det här är egentligen inte ens en dialogruta - det är en guide (med två sidor; den andra innehåller bara texten "tack för att du underkastade dig detta meningslösa slöseri med din tid", om än lätt omskrivet). Och det är uppenbart att konstruktörerna hade någon idé om vad som fungerar bäst, de har ju trots allt bemödat sig att rekommendera ett av alternativen.

Vilket leder oss till den andra huvudregeln vid konstruktion av användargränssnitt:

Varje gång du erbjuder en möjlighet till anpassning ber du användaren att fatta ett beslut.

 

Att be användaren fatta ett beslut behöver i och för sig inte vara fel. Valfrihet kan vara underbart. Folk älskar att beställa espresso på Starbucks just för att de har så mycket att välja på: Grande-half-mocha-Valencia med skummad mjölk - extra varm!

Problemet uppstår först när du ber dem att göra ett val som de inte bryr sig om. När det gäller hjälpfilerna så letar folk i dem därför att de har problem att göra något som de verkligen vill göra, som att sätta ihop en födelsedagsinbjudan. Arbetet med inbjudan har tyvärr avbrutits därför att de inte kan lista ut hur man skriver ut uppochnervända ballonger, eller något i den stilen, och därför letar de i hjälpfilen. Men där har någon irriterande hjälpfilsindexprogrammerare hos Microsoft, som kraftigt överskattar sin egen betydelse, mage att avbryta användaren igen för att börja lära ut detaljer om konsten att skapa listor och databaser. Detta andra avbrott har absolut ingenting att göra med födelsedagsinbjudningarna och kommer garanterat bara att förvirra, och i längden reta upp, användarna.

Tro mig, användarna är inte intresserade av tillnärmelsevis så mycket som du kanske tror. De använder ditt program för att utföra en arbetsupgift. Om det är ett grafikprogram vill de förmodligen kunna styra utseendet på varenda pixel i detalj. Om det är ett verktyg för att göra webbsidor kan du ge dig på att de är extremt känsliga när det gäller att få webbsidan att se ut precis som de vill.

De bryr sig däremot inte om ifall programmets eget verktygsfält befinner sig ovanför eller under fönstret. Inte ett dugg. De bryr sig inte heller om hur hjälpfilen är indexerad. Det är väldigt mycket de inte bryr sig om, och det är gränssnittskonstruktörens jobb att se till att de heller inte behöver göra det. Det är höjden av arrogans att tvinga användaren till ett val bara för att konstruktören inte orkar tänka efter vilket alternativ som faktiskt fungerar bäst. (Och än värre är det att försöka dölja det faktum att man påtvingar användaren ett val genom att presentera det i form av en assistent, som i fallet med WinHelp. Som om denne är en idiot som behöver lite undervisning för att kunna göra ett intelligent val.)

Det har sagts förr att design är konsten att välja. Om du ska göra en papperskorg som kan placeras ut i gathörnen har du gott om motstridiga önskemål att ta ställning till. Den måste vara tung, så att den inte blåser bort - och lätt, för att underlätta för den som ska tömma den. Den måste vara stor, så att den rymmer mycket, och samtidigt liten för att inte stå ivägen för folk på trottoaren. Som konstruktör kan du inte skjuta den sortens val framför dig, då gör du inte ditt jobb. Någon annan kommer att göra ett enklare program som fyller samma funktion som ditt men utan alla irritationsmoment, och alla kommer garanterat att älska det.

När Microsoft Excel 3.0 kom 1990 var det det första program som hade ett verktygsfält. Det var en vettig idé, folk gillade den och den kopierades friskt - så friskt att det idag är ovanligt med program som saknar verktygsfält.

Idén var så lyckad att Excel-gruppen gjorde en särskild testversion av Excel, som bara skickades ut till ett fåtal användare. Den samlade statistik över vilka kommandon som användes mest, och skickade in siffrorna till Microsoft. Så i nästa version hade man lagt till ännu ett fält, den här gången med knappar för de mest använda kommandona.

Problemet var bara att Microsoft inte hade vett att stanna där, att upplösa verktygsfältänget innan de drev idén för långt. Därför fick vi anpassningsbara verktygsfält, och därför fick vi möjligheten att flytta dem vart som helst på skärmen. Sen var det någon som började fundera på om inte menyraden egentligen bara var ett glorifierat verktygsfält med ord istället för knappar, så de lät oss dra runt även menyraden på skärmen. Inställningsmöjligheter i kubik, men med ett problem: ingen bryr sig. Jag har aldrig träffat någon som vill ha menyerna någon annan stans än längst upp i fönstret.

En sak som definitivt hör hemma i avdelningen för "detaljer de inte tänkte på" är denna: om du försöker välja Arkiv-menyn men råkar ta tag i menyraden en aning för långt åt vänster så får du med dig hela menyn. Och den hamnar på den enda plats där du garanterat inte vill ha den: rakt ovanpå det dokument du arbetar med.

Känns det bekant? Och om du har gjort det av misstag är det inte helt klart vad som har hänt eller hur man rättar till det. Så här har vi ett exempel på en inställningsmöjlighet som ingen vill ha (OK då, kanske en tiondels procent av befolkningen) men som ställer till det för så gott som alla.

En bekant ringde mig en dag. Hon hade problem med att skicka e-post, sa hon, eftersom halva skärmen var grå.

Halva skärmen var grå?

Det tog mig fem minuter att per telefon lista ut vad som hade hänt. Hon hade råkat flytta Windows Aktivitetsfält till skärmens högra sida och sedan, fortfarande utan att veta vad hon gjorde, dragit ut det så att det täckte halva skärmen.

Det här skulle ingen någonsin göra avsiktligt. Och det finns många människor där ute som inte kan ta sig ur en sådan här röra utan hjälp; om du oavsiktligt har ställt om någon inställning vet du ju per definition inte hur du ska ställa tillbaka den. Förvånansvärt många avinstallerar program och installerar om dem när något börjar gå snett, för det vet de åtminstone hur man gör. (De har lärt sig att avinstallera först, annars är det risk att de felaktiga inställningarna dyker upp igen.)

"Men hallå", hör jag att du tänker nu, "det är viktigt att ge avancerade användare möjlighet att skruva på inställningarna!" I verkligheten är det inte alls lika viktigt som du kanske tror. Jag tänker till exempel på när jag försökte byta till ett Dvorak-tangentbord: problemet var att jag inte använder en dator. Jag använder alla sorters datorer. Jag kör på andras datorer, jag har tre som används regelbundet hemma och tre till på jobbet. Ibland sitter jag vid datorer i vårt testlabb. Om jag ändrar inställningarna på en av dem så följer ändringarna ändå inte med till de andra, så varför bry sig? Det är inte värt besväret.

De flesta avancerade datoranvändare är i den situationen. De uppgraderar sina datorer varje eller varannat år, de installerar om operativsystemet var tredje vecka. Och visst, första gången de upptäckte att de kunde konfigurera om hela tangentbordet i Word flyttade de runt alla kommandon för att få det som de ville ha det. Men sen kom Windows 95, inställningarna överlevde inte uppgraderingen utan försvann, och dessutom hade de inte samma inställningar på jobbet, och till sist slutade de bara ändra på saker. Jag har diskuterat det här med åtskilliga av mina "power user"-vänner och det är i stort sett ingen av dem som gör fler anpassningar än vad som krävs för att få datorer och operativsystem att fungera som de ska.

Varje gång du erbjuder användaren att göra en inställning ber du också honom eller henne att fatta ett beslut. Det innebär att de måste fundera på saken och bestämma sig. Det behöver inte vara dåligt, men generellt sett bör du inte tvinga användarna att fatta fler beslut än vad som är absolut nödvändigt.

Det betyder inte att alla val är av ondo. Det finns tillräckligt många val som folk måste göra i alla fall: hur deras dokument ska se ut, hur webbplatsen ska fungera och allt annat som hänger samman med den uppgift de faktiskt försöker lösa. På den punkten ska du gå dem till mötes och ge allt: ju fler valmöjligheter desto roligare. Och det finns en typ av beslut till som folk faktiskt gillar, nämligen att kunna förändra utseendet på någonting utan att egentligen ändra funktionen. Alla älskar Winamp-teman, och alla ändrar skrivbordsbakgrunden till sin favoritbild. Eftersom det är ett val som inte ändrar några grundläggande funktioner och som användarna kan strunta i utan att det påverkar deras möjligheter att få jobbet gjort är det ett exempel på vettiga inställningsmöjligheter.



> Kapitel4

Originalartikelns engelska titel är User Interface Design for Programmers Chapter 3: Choices  

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