Jag skulle vilja börja den här bloggen med att skriva om ett uttryck som alltid varit viktigt för mig, men jag inte haft ett bra ord för, nämligen Conceptual Integrity (härmed förkortat CI). Begreppet, som inte är speciellt nytt (det myntades redan -75 av Fred Brooks) går i korthet ut på att ett användarvänligt system, kräver en nivå av övergripande samhörighet, som genomsyrar hela designen.
CI handlar inte bara om användargränssnitt i datorprogram. Det handlar också om hur du designar dina klasser, hur du skriver din kod. Det ingår helt enkelt i all design, även utanför datorvärlden. Principerna bakom begreppet går att skala upp hur mycket som helst, och applicera på alla brancher. Heminredning är ett annat fält där man strävar efter en enhetlig design, liksom marknadsföring (förmedla samma budskap i alla kanaler och kampanjer, övergripande grafisk profil etc.).
Conceptual Integrity kräver ledarskap
CI kan vara väldigt enkelt att uppnå om man är en ensam utvecklare, och kan vara extremt svårt att uppnå om man är flera, eller jobbar med kundunika system, där kunden ges för stort inflytande. För att lyckas med sin design så behöver man ledarskap. En eller ett fåtal designers som har en övergripande bild av designen och som ansvarar för vad som faktiskt läggs till och vad som inte passar in. Hur du väljer att lägga upp dina rutiner bestämmer du själv, men en dokumenterad och uttalad riktning för designen är att föredra.
Open Source saknar ofta Conceptual integrity
Detta gäller inte Open Source som sådant, utan snarare sättet som open source-programvara ofta utvecklas på. Har du till exempel provat installera ett program i Linux miljö utan att läsa manualen först? Ja och hur gick det? Jämförelsevis ser de flesta installationsprogram i Windows likadana ut, och fungerar på liknande sätt. CI handlar om att ett system ska genomgående fungera likadant, och om man skalar upp detta kan man säga att liknande system ska fungera likadant. Man vänder inte plats på ”Ja/Nej” knapparna i en enda dialog i ett system. Man knyter inte F5 till att logga ut (Lotus Notes). Man vill inte ha fönster som ser olika ut (läs Gnome/GTK och KDE/Qt (ja jag vet Oxygen GTK verkar ta hand om detta, vilket är väldigt positivt)). På telefoner svarar man med den gröna knappen till vänster och lägger på med den röda knappen till höger. ”Tillbaka” knappen ska alltid ligga på samma ställe (hejja Android (ok, knappen flyttar sig mellan olika telefoner, men ligger åtminstonde alltid på samma ställe på min HTC Hero)). Ändra på detta och se förvirringen svämma över
Innan du kliar dig i skägget, vässar fingrarna och skyndar dig ner till kommentarsfunktionen (risken finns att du redan är där) så vill jag ge ett par exempel på lyckad CI. Och här vänder jag mig återigen till Linux, nämligen Linux kärnan i sig. Här ser vi ett helt annat mönster. Här har vi ett överflöd av utvecklare som bidrar till samma kodbas, men endast ett par få som faktiskt bestämmer vad som kommer med och inte. Detta betyder att Linux utvecklare kan garantera en homogen design och välskriven kod. Jag vill påstå att detta är en av de främsta framgångsfaktorerna för Linux kärnan.
Vad gäller problemet med installationer under Linux hanteras detta idag väl utav de pakethanterare som finns för att installera/avinstallera program. Detta är något som jag ofta saknar på Windows.
Kunden har (inte) alltid rätt
När du jobbar med kundunika system är det vanligt att kunden kommer med idéer och krav som ibland är trångsynta, i den meningen att de inte ser helheten, och orealistiska. Långt ifrån alltid, men det kommer garanterat att hända. I detta läge är det upp till dig som designer att se till att behålla CI samtidigt som kunden blir nöjd. Detta kan vara en svår utmaning, men utmaningar är bra. Oftast går det att tala kunden till rätta genom väl underbyggd argumentation. Detta betyder att du behöver tänka igenom varför du har tänkt som du tänkt, vilket leder till bättre design för alla. Ibland kan du dock inte övertyga kunden, och då får du helt enkelt försöka göra det bästa av situationen, eller välja att avstå från projektet.
Avslutningsvis
Avslutningsvis vill jag säga att CI inte är nyckeln till framgång i sig, men utan det flyger du enkel resa till misslyckande.
Läs mer
Joel Spolsky skriver väldigt bra om samma principer som här och bidrar med mer handfasta tips i sina artiklar om användargränssnitt.
