Ett klicklöst gränssnitt
På www.dontclick.it finns en Flash-animation som testar ett intressant gränssnittskoncept. Du behöver nämligen aldrig klicka med musen, utan bara röra pekaren. Det fungerar faktiskt ganska bra, men i ett mer komplext gränssnitt är det frågan om det skulle fungera över huvud taget. Man vill nog också kunna flytta muspekaren ifred, utan att det börjar hända saker som man inte vill.
Dessutom är vi så vana vid att klicka idag, att det är svårt att låta bli. Däremot är det lätt att blanda ihop miljöer som kräver dubbel- respektive enkelklick (ex. vanliga Windows-program respektive Internet-länkar).
Uppdatering: på 1,5 miljoner besök har användarna klickat över 900 000 gånger, trots att det inte behövs. Jag råkade också göra det... Vanans makt är stor!
Tangentbordslayout inte så enkel som den verkar
Jag har stött på två olika företag som säljer tangentbord med bokstäverna ordnade i bokstavsordning. ”Setting a New Standard for User-Friendliness and Efficiency”, skriver det ena, och det andra ”Why go through the pain of learning a dying skill, ’qwerty’ when you can use the ABC you know right now?” Båda dessa påståenden är bevisat felaktiga, och jag läste om det första gången i Donald Normans Design of Everyday Things. Ett traditionellt QWERTY-tangentbord är alltid lika bra eller bättre än ett ”alfabetiskt”.
Norman och Fisher skrev en artikel 1982, ”Why alphabetic keyboards are not easy to use: Keyboard layout doesn’t much matter.” Den går tyvärr inte att hitta online, men jag har hittat en nyare artikel som jag kan citera:
Norman and Fisher studied a strictly alphabetical layout of the physical keyboard. They expected novice users to type faster on such a keyboard than on QWERTY, but found that this was not true. The key problem with an alphabetical keyboard, they concluded, was that the keys were laid out in multiple rows. The location of a key depended on the length of a row – the break point from which the next letter had to start at the left end of the keyboard again.
Där har vi problemet. Att bokstäverna är ordnade från a till z (eller ö) hjälper inte nybörjaren, eftersom raderna med tangenter är brutna. Om jag vill hitta a går det fort, men var hittar jag o? Jag kan inte instinktivt säga på vilken rad eller var i raden o finns. Därför är QWERTY precis lika (in)effektivt för nybörjare, men faktiskt snabbare för ”experter”. För en lång och intressant historia om tangentbordslayouten, se The Rutherford Journal.
(The New Standard Ergonomic Keyboard har en lite annorlunda layout, med a-m till vänster och n-z till höger. Det är förmodligen något bättre än den strikta a-z-ordningen på The ABCkeyboard.)
Svåranvända kreditkortsterminaler
När jag handlar med kort i butiker får jag ofta dra kortet i en apparat själv. I stort sett varje gång måste jag dra kortet två gånger, eftersom jag inte förstår åt vilket håll jag ska vända det. Det finns alltid en liten skåra ovanför eller bredvid en knappsats med siffror och andra symboler. Magnetremsan på kortet ska självklart vändas mot apparaten, men ska den peka åt höger eller vänster? Alternativt uppåt eller nedåt. Det är olika varje gång, vilket är själva problemet. Hade det funnits en standard hade jag lärt mig för länge sedan. (Exempelvis SL-korten vänder man åt samma håll överallt, så det är aldrig något problem för oss vana kollektivresenärer.)
Eftersom jag är medveten om problemet brukar jag titta efter ledtrådar, så att jag slipper dra kortet mer än en gång. Ibland ser jag en liten symbol som jag försöker tolka. Symbolerna kan vara pilar eller stiliserade kreditkort – men på något sätt blir det ändå fel. Jag kan inte minnas att jag sett någon otvetydig symbol eller instruktion någonstans.
Jag tycker själv att det mest logiska vore att rikta magnetremsan mot apparaten. Det känns mest naturligt, eftersom det är apparaten som ska läsa av kortet (i min mentala modell). När jag riktar remsan bort från den tycker jag det känns märkligt, eftersom utrymmet bortanför skåran är minimalt. Det är dock det rätta sättet väldigt ofta.
Exempel på Not Invented Here i Göteborgs hamn
Göteborgs hamn har nyligen fattat ett modigt beslut, nämligen att lägga ned sitt misslyckade 57-miljonerkronorsprojekt. Man började år 2000 utveckla ett eget IT-system, eftersom det inte fanns något existerande system som täckte hamnens behov. Det är ett typiskt exempel på not invented here-syndromet. Det brukar tas upp i kurser om projektstyrning, och innebär förenklat att en organisation avvisar eller ignorerar existerande lösningar, eftersom de inte tros vara tillräckligt bra.
Nu är inte jag någon expert på hamnar och deras IT-system, men borde det inte finnas system någonstans i världen, som fyller också Göteborgs hamns krav? Om inte någon av världens alla hamnar i Göteborgs-klassen är tillräckligt bra, borde man kanske höra med Shanghai, Singapore, Rotterdam eller Hongkong. Eftersom de är världens största hamnar, borde deras system vara mer än tillräckligt avancerade.
Å andra sidan har Joel Spolsky skrivit en bra artikel, som försvarar de ”not invented here-drabbade”. Han menar att det faktiskt är bäst att göra vissa viktiga saker själv, även om det finns existerande system som kan göra samma saker. Då kanske man var rätt ute i Göteborg, i alla fall – men i sådana fall borde man ju inte lagt ned projektet nu.
Boktips: Konstruktivt tänkande
Som utvecklare bör man ha förmågan att kunna tänka konstruktivt, och hitta på smarta lösningar på användarnas problem. Jag vill därför rekommendera en bok som inte handlar ett dugg om (system)utveckling; Konstruktivt tänkande av Edward de Bono (48 kronor). Den första och bästa delen av boken är en enda lång rad av löst sammanhängande textstycken om ”konstruktivitet”.
”Utformning” är på sätt och vis motsatsen till analys. I analysen bryter vi ned saker och ting till standarddelar som vi kan känna igen. Inom utformningen sätter vi ihop saker för att uppnå ett värde och ett syfte. Utformning är på sätt och vis motsatsen till omdöme. Genom omdömet försöker vi hitta en standardreaktion på en standardsituation. Inom utformningen försöker vi utforma en ny reaktion som passar situationen bättre.
Boken handlar dels om olika sätt att tänka, där utformning och värdeskapande lyfts fram som det viktigaste. Dels tar författaren upp korta exempel på konstruktivt tänkande (exempelvis myten om att ryssarna använde en blyertspenna i rymden, när amerikanerna la ned miljoner på att utveckla en ny rymdpenna). Den var mycket inspirerande och absolut läsvärd.
Dagens lästips
Några artiklar från andra bloggar och webbplatser, som jag tycker är läsvärda:
- Lord Palmerston on Programming, Joel on Software: om vad erfarenhet och kunskap inom programmering egentligen innebär, och varför det tar många år att bli en riktigt duktig programmerare.
- Beyond usability testing: user-centred design and organisational maturity, Mercurytide: en introduktion till ISO-standarden 13407, som beskriver en användarcentrerad designprocess.
- Nu fattar t.o.m. jag Fitts lag, Design pending: en förklaring till Fitts lag, som säger att ju mindre och längre bort från muspekaren objekt befinner sig, desto svårare är det att få tag i dem.
- Why marketing should make the user manuals!, Creating Passionate Users: något jag aldrig tänkt på själv; manualer är alltid fula och trista, men reklambroschyrerna är snygga och välgjorda.
Ruby on Rails, CakePHP och Code Igniter
Efter att ramverket Ruby on Rails lanserades i juli 2004, har det följts av åtskilliga kopior. Slagordet är ”web development that doesn’t hurt”, och meningen är bland annat att ramverket ska tillhandahålla mycket färdig funktionalitet för utvecklaren. Majoriteten av koden i nästan alla webbapplikationer gör ungefär samma saker (exempelvis hanterar användare, laddar upp filer, visar dokument, låter användaren mata in data i formulär). Om ramverket kan göra de vanligaste uppgifterna lättare – och samtidigt utgöra ett stöd för utvecklingen – borde man kunna korta ned utvecklingstiderna.
De ramverk jag har tittat lite på är CakePHP (PHP), Code Igniter (PHP) och django (Python) – men det finns många fler. Alla dessa ramverk slåss naturligtvis om att vara det bästa. Ett citat som jag tycker är lysande och helt rätt tänkt, hittade jag i Code Igniters forum:
Use the one that you can figure out how to do something with. The less time you spend figuring out the framework, the more time you can spend coding.
Jag försökte använda Ruby on Rails, men det tog för lång tid att förstå hur jag skulle göra något. Och jag kan inte språket Ruby, alltså valde jag bort det ramverket. Istället provade jag CakePHP, som jag hade läst mycket bra saker om. Det visade sig att den inspelade video-guiden för nybörjare var helt felaktig, eftersom den inte uppdaterats efter ändringar i de senare versionerna. Den skrivna dokumentationen var knapphändig, och när jag frågade en sak i deras IRC-kanal fick jag svaret att jag nog borde titta i källkoden. Det tog alldeles för lång tid, och även CakePHP ratades.
Slutligen hittade jag rätt: Code Igniter! Inte lika mycket finesser som CakePHP, men fullt tillräckligt för att skapa webbapplikationer med. Jag var lite skeptiskt till CakePHP, eftersom det var så mycket ”magi” bakom kulisserna som jag inte hade kontroll över, eller ens förstod. Jag tror att skillnaden är att CakePHP utvecklas utan mål, medan Code Igniter, liksom Ruby on Rails, utvecklades för att möjliggöra ett konkret projekt. Ruby on Rails togs fram för att göra samarbets- och produktivitetsapplikationerna i Basecamp, och Code Igniter för att göra det kommersiella blogg/wiki/publicering/forum-verktyget ExpressionEngine. Det gör att CakePHP driver vind för våg, och ingen ställer de viktiga kraven på utvecklarna.
Också django verkar lovande. Det handlar i och för sig mest om att jag inte gillar PHP, men älskar Python. Det är dock få webbhotell som har stöd för Python, så jag har inte provkört django än.
Model-view-controller (MVC)
Dessa ramverk implementerar alla designmönstret Model-view-controller, som kan sägas vara en variant på treskiktsarktitekturen. Man separerar modellen (”model”), presentationen (”view”) och händelsehanteraren (”controller”, jag kan inget bättre svenskt ord). Genom att dela upp all kod i olika lager eller hanterare, får man renare och mer lättunderhållen kod.
Så här kan ett typiskt informationsflöde i en webbapplikation gå till:
- Användaren öppnar en URL
- Rätt händelsehanterare aktiveras beroende på URL, och denna skickar eventuellt formulärdata till modellen
- Modellen bearbetar och stoppar in data i databasen
- Händelsehanteraren startar presentationen, som hämtar data att visa från modellen
- Input från användaren inväntas
Det går självklart att använda sig av MVC utan att använda något ramverk. Men jag upptäckte att strukturen i Code Igniter uppmanade till separation, och gjorde det lite svårare att skriva fulkod. Det är ingen heltäckande lösning, förstås, men jag skulle rekommendera alla webbutvecklare att ta en titt på MVC-ramverken, och prova ett av dem. Alla mina framtida webbprojekt kommer nog göras i Code Igniter.
Webben har fyllt 15, och PC:n 25
Den 6 augusti 1991 nämner Tim Berners-Lee projektet WorldWideWeb för första gången, i nyhetsgruppen alt.hypertext:
The WorldWideWeb (WWW) project aims to allow links to be made to any information anywhere. The address format includes an access method (=namespace), and for most name spaces a hostname and some sort of path.
We have a prototype hypertext editor for the NeXT, and a browser for line mode terminals which runs on almost anything. These can access files either locally, NFS mounted, or via anonymous FTP. They can also go out using a simple protocol (HTTP) to a server which interprets some other data and returns equivalent hypertext files. For example, we have a server running on our mainframe (http://cernvm.cern.ch/FIND in WWW syntax) which makes all the CERN computer center documentation available. The HTTP protocol allows for a keyword search on an index, which generates a list of matching documents as annother virtual hypertext document.
The project started with the philosophy that much academic information should be freely available to anyone. It aims to allow information sharing within internationally dispersed teams, and the dissemination of information by support groups.
Det blev startskottet för utvecklingen av webben. BBC har en ganska bra sammanfattning av de stora händelserna under de 15 år som gått sedan dess. Bland annat dröjde det till oktober 1994 innan Netscapes webbläsare lanserades. Aftonbladet hade då publicerat nyheter online sedan ett par månader tillbaka. Ett år senare kom Internet Explorer.
IBM PC 25 år
Knappt en vecka efter att WWW-projektet offentliggjorts (fast tio år tidigare) lanserar IBM sin Personal Computer, IBM 5150. I dagens penningvärde kostade den ungefär 3600 dollar, eller 25000 kronor (utan diskettenhet eller bildskärm). Som tillval fanns 11” monokrom bildskärm, CGA-färgskärm, matrisskrivare och 5,25” diskettenheter. Utan skärm kopplade man datorn till tv:n, precis som Amiga och Atari. Utan diskettenhet kunde man använda en kassettbandspelare och kassettband, precis som Commodore 64. Det kompletta paketet med färgskärm, två diskettenheter och skrivare, kostade motsvarande drygt 70000 kronor.
I pressreleasen skriver man:
”This is the computer for just about everyone who has ever wanted a personal system at the office, on the university campus or at home,” said C. B. Rogers, Jr., IBM vice president and group executive, General Business Group. ”We believe its performance, reliability and ease of use make it the most advanced, affordable personal computer in the marketplace.”
Bland programvaran som medföljde fanns VisiCalc, EasyWriter, rollspelet Microsoft Adventure och en BASIC-tolk.
Navigeringsmönstren på webben har förändrats
Hur vi navigerar på webben har förändrats sedan mitten på 90-talet. Inte så konstigt, kanske, men det visar att användarna är mer aktiva och kanske mer mogna – och webbplatserna har förmodligen blivit avsevärt bättre på att guida besökarna genom sidorna.
10,5% av alla öppnade länkar öppnas i ett nytt fönster (uppgång från 0,2%): anledningen till att jag öppnar länkar i nya fönster är för att dela upp sessionen i flera. Jag vill följa en länk, men samtidigt stanna kvar på den aktuella sidan. Ibland öppnar jag flera länkar i bakgrunden, som jag sedan läser efter den aktuella sidan. Jag tolkar det som att användarna är mer mogna (har lärt sig att öppna länkar i nya fönster) och att webbsidor idag innehåller fler länkar.
15,3% av alla ”övergångar” är ett formulär som skickas (uppgång från 4,4%): webben har blivit mer interaktiv, och användarna skriver kommentarer, köper varor, loggar in etc. Det handlar nog mest om en mognad hos webbplatserna än hos användarna. I början var ju webben ett statiskt medium för information, men nu är det ett mer interaktivt medium.
Bakåtknappen används vid 14,3% av alla ”övergångar” (nedgång från 35,7%): det här är svårare att analysera. Jag tror att jag själv oftare klickar på webbplatsens logotyp för att komma till huvudsidan, än jag använder bakåtknappen. Kanske är det så att det finns färre ”återvändsgränder” (med inga eller väldigt få länkar) på dagens webbplatser. Det finns nästan alltid länkar kors och tvärs, var man än befinner sig. Då har man kanske inte samma behov av att återgå till den förra sidan. Jag kan tänka mig att man förr länkade till en sida, men inte lika ofta därifrån.
Etiketter
Flitiga kommentatorer