Ebba säger:
Enklare blir bättre, alltså

Svaren var alldeles entydiga. Så enkelt som möjligt. Inte en massa olika behörigheter och nivåer. Det mesta öppet och tillgängligt för alla. En mindre, avskiljd del för vd och de högsta cheferna. Så lite krångel som möjligt.

Vi presenterade undersökningen för kunden. Ett par ex av FrontPage och några veckors kurs för de tilltänkta redaktörerna framstod som ett bra alternativ.

Men kunden valde något helt annat. Man bestämde sig för att låta utveckla ett databasdrivet system där behörigheter kunde styras in i minsta detalj: efter företag, efter verksamhetsland, efter befattning i koncernen och efter särskilda intressen. Man kunde till exempel ställa in att en viss sida bara skulle kunna ses av ekonomer i koncernens alla polska dotterbolag. Eller av de miljöansvariga i Acme-bolaget, i alla länder utom Finland. Eller bara av medlemmarna i golfklubben på huvudkontoret.

Vad hände?

När behörighetssystemet skulle utvecklas stötte man på en hel rad tekniska problem. Många av företagen i koncernen hade redan egna intranät; man ville inte ge dem ännu fler lösenord, så koncernnätets användar- och lösenordshantering måste kopplas ihop med dotterbolagens. Delar av de tekniska tillämpningarna var nya och oprövade. Projektet drog ut på tiden och projektledare och beställare byttes ut. Specifikationer ändrades under tiden: nya tillägg gjordes, eftersom man kommit på nya krav.

Projektet blev mer än ett år försenat och drev både kund och leverantör till vansinnets rand och till tröskeln på domstolen.

Många av er känner förmodligen igen er, mer eller mindre. Projekt med stolta ambitioner som blir försenade. Teknik som strular. Funktioner som visar sig bli många gånger krångligare än vad man föreställt sig.

Behöver man plädera för enkelhet? Förmodligen inte - i princip. De flesta inser de enkla lösningarnas fördelar: snabbare att göra, billigare, enklare att underhålla, går mer sällan sönder, och så vidare. (Och det gäller förstås inte bara webbdesign, utan design och skapande i allmänhet.) Men varför skenar då så många projekt iväg, om alla egentligen känner till fördelarna med enkelhet?

Jag tror vi bör försöka lära oss känna igen en del orsaker eller mekanismer till varför saker blir onödigt krångliga - så vi kan stävja dem när de visar sig.

Jag tror också att det behövs en enkel formulering att ta till - ett motto - för att påminna oss själva om vikten av att hålla igen när det börjar dra iväg.

En viktig insikt är att tillkrånglandet är en process som förstärker sig själv.

"Ju länge tid man tar på sig för att designa något, desto sämre blir det, eftersom folk uppfinner fler och fler skäl att krångla till det. Och ju mer komplicerad en sak blir, desto dyrare blir det att göra fel, så designen måste analyseras ännu noggrannare, vilket gör att allt tar ännu längre tid, vilket ger alla chansen att lägga till nya krångligheter och hela cykeln startar om igen."

Det här är en av de bästa designfilosofier jag vet.

Irv Culver, som formulerat den, var inte formgivare eller art director utan ingenjör. Från 40-talet och ett par decennier framåt verkade Culver i den ingenjörsbyrå hos den amerikanska flygplantillverkaren Lockheed, som skapade en lång rad legendariska flygplan (bland andra U-2 och SR-71). Alla slog olika typer av flygrekord; och flera av byråns projekt levererades under budget och före utsatt tid!

Culver och hans kollegor bekände sig till en princip, som man ofta citerar på engelska: the KISS rule. Förkortningen utläses Keep it simple, stupid.

KISS-regeln är en kraftfull princip - men den funkar ju inte så bra på svenska.

Jag har länge funderat på hur man skulle kunna formulera en svensk variant. Och mitt förslag är att vi i Sverige i stället inför EBBA-regeln: Enklare Blir Bättre, Alltså.

Ebba är en finurlig tjej med glimten i ögat. Hon är ingen sträng predikant, utan talar med mild auktoritet. Ebba kan vi hänvisa till när en webbdesigner envisas med att bygga sidor i frames, med layers och javscriptmenyer. Och när ett system projekteras med massor av i och för sig lockande funktioner, kolla om man inte kan ta med Ebba i projektgruppen.

För många funktioner - så kallad featuritis - är en viktig källa till krångel. Jobbar man med ett system är det ofta lockande att lägga dit en funktion till. Bara en valmöjlighet till; det gör väl inte så stor skillnad?

Men att lägga till saker innebär snarare multiplikation än addition, därför att den nya funktionen kombineras med gamla.

Kornet är ingen tekniksajt, men låt mig ge ett principiellt exempel. En sökmotor som jag arbetade med gav från början den sökande tre valmöjligheter: att söka på egenskaperna land, titel, författare - en i taget eller alla på en gång. Det betydde att träfflistan kunde se ut på sju olika sätt: med träffar

• bara för land
• bara för titel
• bara författare
• land och titel
• land och författare
• författare och titel
• land, författare och titel

Alla varianterna krävde sin speciella utformning av presentation, texter och alternativ.

Men mitt i projektet tillkom en ändring, framtvingad av politiska skäl på hög nivå: lägg till ett val för språk också.

Det lät ju inte så farligt; bara en kryssruta till på sidan med sökformuläret. Men plötsligt fanns det inte längre sju möjliga varianter på träffsidor, utan femton - mer än dubbelt så många (4 varianter med ett val, 6 varianter med två val, 4 varianter med tre val och en variant med alla fyra valen).

Det lilla tillägget medförde betydligt mer arbete än projektledningen hade föreställt sig. När saker kombineras med varandra - och det är regel snarare än undantag - ökar krånglighetsfaktorn snabbt.

En fördel med att hålla sig till Ebba är att man då ofta slipper stöta på den här betydligt otrevligare gynnaren: HUGO - "Häll ut, gör om" - ett öde som alltför ofta drabbar projekt som inte hållit sig till Ebba-regeln från början.

Vad hände förresten med industrikoncernens intranät?

Jo, ett drygt år försenat skulle det tas i bruk. Och behörighetssystemet fungerade rent tekniskt.

Men... i praktiken visade det sig att gränserna inte var så skarpa som man föreställt sig. Varje användare måste knytas till ett land: antingen var man svensk eller dansk eller polack. Men i verkligheten var till exempel VDn i det danska bolaget ABC samtidigt ordförande i det svenska bolaget XYZ. Hur skulle han göra? Loggade han in som dansk kunde han inte se sitt svenska bolags sidor, och tvärtom.

Så vid ett kort möte med ledningen bestämdes att lands-märkningen inte fick användas över huvud taget.

Och som webbredaktörer placerades sedan just de användare som ville ha enkelhet från början. De såg sällan något material som specifikt måste gömmas för sekreterare i DEF-bolaget, eller medlemmar i konstföreningen i GHI-bolaget. Så i praktiken kom behörighetssystemet knappt att användas alls.

Hur mycket hade man sparat, i tid och pengar, om man följt användarnas ursprungliga vilja - och Ebba? Mer än man vill tänka på.

Det tycks finnas en starkt förförande kraft i tekniken, i att hitta på nytt och bygga nytt.

Skapande människor - tekniker likaväl som designers - vill gärna skapa nya saker. Det är en del av yrkesidentiteten. Men dessvärre betyder det ibland att saker görs för att de kan göras: kanske inte alltid för att de är bättre, eller ens behövs.

Varför valde förresten industrikoncernen den krångliga lösningen?

Ja, egentligen hade den rätt åldrade ledningen lite motvilligt gått med på det här med intranät; de hade en mycket restriktiv syn på information - så lite som möjligt till var och en ("need-to-know-basis", som det brukade formuleras).

Projektledaren, en yngre påläggskalv som profilerat sig med intranät-idén bland gubbarna i ledningen, skulle kanske också ha kunnat övertyga dem om att fritt informationsutbyte i koncernen var en tillgång snarare än en fara.

Men istället för att riskera få nej till sitt projekt, höll han med fossilerna. För som van datoranvändare insåg han att det uppenbarligen var görbart: man kunde göra ett intranät med ett finmaskigt behörighetssystem. Några kategorier att märka sidorna med. Behörighet och inlogging innebär ju inga svårigheter. Borde i alla fall inte. I princip. Det kan göras - alltså gör vi det.

Och utvecklarna såg just möjligheten att pröva nya ideer, lära, tillämpa nya lösningar.

Men svårigheterna underskattades alltså. Och behovet av lösningen överskattades.

En orsak till krångel är ibland prestige.

Det ger mer beundran att kunna säga att man utvecklat en helt ny, unik lösning, än att ha tillämpat något som någon annan redan gjort.

Prestige syns också i språket. Det är fortfarande inte lika fint att uttrycka sig kort och enkelt. Det vill säga, vi tror inte att det duger. Så när vi ska skriva något viktigt, tar vi i med krånglig meningsbyggnad och ord som sätter sig i repekt: "Härmed anhåller jag..." istället för "Jag vill...".

Eller horrörer som den här: "Planområdet genererar trafikströmmar som måluppsöker destinationer i kommersiella regioncentra vilka erbjuder faciliteter som inte tillhandahålles i de såväl horisontellt som vertikalt sortimentbegränsade butikscentra med lokalisation i perifera bebyggelseområden."

Skulle Ebba uttrycka sig så? Knappast. Vi kallar in Hugo:

"Folk åker till stan för att handla det som inte finns i närbutiken på landet."

(Fler exempel på hur krångligt språk, och hur man förenklar det, finns i min bok "Att skriva för webb är att skriva för publik" - se länk nederst till höger.)

Prestige spelar också in när webbar planeras. Det är lätt att se vilka finesser och funktioner en konkurrent har. Har de en sån, måste vi också ha en. Men det är inte alltid lätt att se om de över huvud taget används, eller hur krångligt det är att underhålla eller sköta dem.

Moderaterna skaffade inför valrörelsen en "digital assistent" på sin sajt - en liten animerad figur, som kunde ge svar på frågor från besökarna. De andra partierna följde efter; moderaternas "Emma" fick digitala kusiner som Chris, Folke, Rosen och Lars. Först i efterhand insåg man hur mycket arbete som krävdes bakom kulisserna, för att lära assistenten att förstå frågorna. Folkpartiet valde till exempel att direkt efter valet stänga av sin assistent, lejonet "Folke", och gå tillbaka en enkel lista över vanliga frågor.

Fascinationen över tekniken är stark inom IT-sektorn och webbranschen. Men inte bara där, utan i hela samhället.

Förstå mig rätt. Jag är inte emot teknisk utveckling.

Men att tvingas avstå från avancerade lösningar - till exempel av brist på resurser - kan till och med leda till bättre resultat. Fast det är bara ibland som alternativen blir synliga. New York Times berättar om ryska raketmotorer:

"Moskva förlorade visserligen det kalla kriget, men nu klår ryssarna väst i raketmotortillverkning. Med en teknologi som är enkel och pålitlig, kraftfull men tämligen billig vinner ryssarna inte bara kommersiella kunder världen runt, utan till och med det amerikanska försvaret. Ryssarna har byggt bättre raketer genom att lita till ett "låg-teknologiskt" bränsle."

När amerikanska gamla kärnvapenmissiler nu byggs om för att lyfta kommunikationssatelliter, monterar amerikanerna därför in ryska motorer i dem.

"Hemligheten ligger i att ryssarna under kalla kriget lärde sig att nå bästa möjliga resultat utan att satsa på den senaste spetstekniken - den raka motsatsen till inriktningen i väst.
Till exempel litade ryssarna till fotogen, ett billigt bränsle som kan användas i rumstemperatur. USA satsade på att använda flytande syre: ett mycket dyrbart bränsle som måste kylas ner till mer än 200 grader under noll, en temperatur som kan ställa till stora problem för raketens övriga delar."

Enklare blir bättre, alltså.

Fysikprofessorn och matematikern Neil Gershenfeld berättar något liknande.

Matematiker i väst har, med nästan obegränsad tillgång till datakraft, kommit att använda datoriserade modeller i allt högre grad. I boken "When things start to think" berättar han om hur han hört en lång presentation om hur Pentagon använde sådana modeller för att simulera krig:

"Mot slutet räckte jag upp handen. Jag undrade om han hade någon aning om hans modeller, som kostat miljarder dollar att utveckla, verkligen skulle fungera, med tanke på att det är opraktiskt att starta ett krig för att testa dem.

Hans svar blev, i princip, att det var en sådan svår fråga att de inte brydde sig om det. Vid samma tid trälade matematiker i det före detta Sovjet på med mycket begränsad tillgång till datorer och inga andra resurser än att tänka. Ett resultat av detta är att en överraskande stor del av modern matematisk teori kommer från Sovjet, oproportionerligt mycket större än resultaten inom andra tekniska områden."

Byråkratin inom det amerikanska försvaret är en god måltavla för den som vill slåss för enkelhet.

I mitten av femtiotalet behövde det amerikanska flygvapnet ett stort lastplan, och gjorde en specifikation som var åtta sidor lång. Irv Culvers Lockheed lämnade in ett anbud som var drygt en centimeter tjockt, fick uppdraget och levererade transportplanet C-130, mer känt under namnet Hercules.

När det amerikanska flygvapnet 1980 började planera för ett nytt transportplan, var specifikationerna 2.750 sidor. Lockheeds anbud vägde tre ton. För att leverera det till Pentagon var företaget tvunget att använda ett av sina fortfarande aktiva Herculesplan.

Säkert har världen blivit mer komplicerad sedan femtiotalet - men har den blivit 350 gånger mer komplicerad? Med tanke på att Herculesplanet faktiskt ännu idag används över hela världen - även i det svenska flygvapnet - verkar det knappast rimligt.

Kravspecar, förstudier och tester är dock inte i allmänhet onödigt krångel.

En samstämmig bild av vilka användarna är och vad de behöver är en förutsättning för att man bara utvecklar det som är nödvändigt.

Projektmetoden DSDM (se länk nere till höger) använder ett intressant hjälpmedel som kallas MoSCoW-prioritering, vilket ska utläsas som Must have - Should have - Could have - Won't have. Kraven på ett system delas in i dessa grupper. Poängen är att det tvingar en att tänka på vad som verkligen är väsentligt i ett system, och vad som är extrafinesser man kanske kan undvara.

Alan Cooper's persona-teknik är också ett gott redskap för att undersöka om design är ändamålsenlig.

Att tidigt och löpande testa vad man gör mot användarna har också visat sig vara en avgörande faktor bakom lyckade projekt. (se länken "Why Evolutionary Software Development Works" nere till höger). Testerna kan vara enkla: pappersprototyper eller enkla skisser räcker oftast för att fånga in viktiga synpunkter.

Mycket av det ovanstående har handlat om funktioner hos system. Men även grafisk design tjänar på att präglas av enkelhet.

Det betyder inte att det ska vara påvert eller tråkigt.

Om webben är en stad, så behöver vi inga fler betonggrå informationsförorter, som min kollega Tommy brukar säga. Det ska vara snyggt - men snabbt: långsamma sidor, med massor av bilder, är fortfarande ett av de största irritationsmoment på webben. Det är fortfarande många som inte har bredband utan relativt långsamma modem, och som dessutom betalar för varje sekund av nedladdningstid. Ebbas tips är att använda små, men starkt laddade uttrycksmedel. Enklare blir bättre, alltså.

Även för design gäller att enkla lösningar är enklare att testa. Vid komplicerade tekniker tenderar olika webbläsare att ge olika utseende. Det betyder att man måste testa noggrannare, och vara beredd på fler förändringar över tiden.

Enkelhet i designen betyder också större tillgänglighet för alla. Tabeller nästlade i tabeller är till exempel ett problem för blinda och synskadade webbanvändare. Javscriptmenyer gör det svårt både för synskadade och alla som inte har perfekt motorik (se På Kornet-artikeln om SVTs nya design.) Till onödigt krångel vill jag också räkna ramar (frames), som gör det svårare att skriva ut, länka eller bokmärka sidor.

Det finns många skäl till varför projekt blir onödigt krångliga. Det vore förmätet av mig att tro att jag har listat mer en en bråkdel här.

En del system - websajter eller annat - ska förstås vara avancerade. Det är naturligtvis omöjligt att rent generellt säga var gränsen går mellan krångel och enkelhet. En gammal aforism säger "allt bör förenklas så långt det är möjligt - dock ej längre".

Men vår värld blir mer komplicerad varje dag - på tusen olika sätt. Det stjäl vår tid och våra liv.

Jag tycker att vi alla har ett ansvar inför våra medmänniskor att försöka göra världen lite enklare.

Just därför behöver vi, tror jag, en enkel minnesregel att ta till. Ett motto eller mantra för att ständigt påminna oss själva: Enklare blir bättre, alltså.

Puh! Att plädera för enkelhet kan vara ganska komplicerat. Du som orkat läsa ända hit - tack för din uppmärksamhet! När den här artikeln publicerades den 4 november, lovade jag en t-shirt med Ebba som belöning åt de första tre, som mejlade mig. (Klicka på bilden för att se motivet i större storlek). De tre lyckliga har redan fått sina tröjor; men du kan också få en egen (för 160 kronor plus moms och porto). Skicka mig bara ett mejl - och glöm inte att ange din storlek.

Och även om du inte blir bland de tre första, vill jag gärna dina synpunkter på enkelhet, på krånglets orsaker och hur man kan undvika det.

(Tack till Sara för bildena på Ebba och Hugo!)

>> Synpunkter? Skicka ett mail med länken ovan.<<