Jag börjar nu min serie om vanliga design-, layout- och utvecklingsmissar som jag ofta uppmärksammar i samband med studentprojekt och även i andra sammanhang. De missar jag beskriver här är inte på något sätt heltäckande utan är inriktat på de brister som ofta finns i studentapplikationer men givetvis också förekommer på samma sätt i andra sammanhang. Skulle jag skriva om missar som görs av icke skolade utvecklare skulle dock denna lista kunna göras väldigt lång, men det är inte mitt mål med denna artikelserie. Första artikeln behandlar fel- och rättmeddelanden.
Regel 1) Se till att ha tydliga rätt- och felmeddelanden
Felmeddelanden:
I många applikationer som man ser så är just felhanteringen något som verkligen kommit i andra hand. Man kanske har snygg bakomliggande kod för att fånga fel men det brister ofta i hur dessa presenteras för användaren. I värsta fall kastar man helt enkelt ut felet i klartext för användaren, typ:
Critical Error. Could not connect to database foo with username ’superadmin’
Ovanstående är inte bara helt obegripligt för den vanliga användaren utan även helt förkastligt ur ett säkerhetsperspektiv. Genom dylika felmeddelanden ger man värdefull information till illasinnade som vill attackera vår sajt, något som vi absolut ska undvika. I många fall tar man dock hand om detta fel och presenterar det på ett något mer användarvänligt sätt:
Ett fel har inträffat: Kunde inte ansluta till databasen
Detta är definitivt bättre då vi nu inte ger ut kritisk information till attackerare. I vissa fall kan man också se den ännu bättre varianten:
Ett fel har inträffat: Kunde inte ansluta till databasen
Den röda texten talar ganska tydligt om för användaren att något gått fel. Grundproblematiken finns dock fortfarande kvar. Vilken användare bryr sig egentligen om att vi inte kan ansluta till en databas? Användaren vill troligtvis snarare veta vad detta innebär i praktiken? Ett bättre alternativ är då:
Ett fel har inträffat: Din text kunde inte sparas.
Nu har vi kommit en bra bit på vägen. Användaren förstår att ett fel inträffat, men vad ska användaren göra nu? Det är väldigt sällan man ser konkreta förslag på detta. Bättre:
Ett fel har inträffat: Din text kunde inte sparas. Kopiera texten nedan till ett textdokument lokalt på din dator och testa att posta inlägget vid ett senare tillfälle. En automatisk felrapport har skickats till applikationens tekniker.
Nu är vi nära ett bra felmeddelande. Det är tydligt vad som gått fel och vad användaren förväntas göra nu. Dessutom får användaren reda på att denne inte behöver felanmäla felet då det automatiskt loggats. Det finns dock fortfarande en viss risk att användaren missar meddelandet då det, beroende på sidlayout kan vara svårt att upptäcka den röda texten. Bättre då är att skapa meddelandet i stor, röd, tydlig box enligt följande:
Nu tycker jag att vi har ett tydligt och informativt meddelande. Det sista man måste tänka på är placeringen av meddelandet. Om användaren inte får någon chans att se meddelandet så är allt förlorat. Inte allt för sällan så ser jag meddelanden av denna kaliber placeras under till exempel ett formulär. Vad man då måste tänka på är att troligtvis så kommer användarens webbläsare att skrollas till toppen på sidan när förmuläret skickats. Om då meddelandet ligger långt ner på sidan finns det en stor risk att meddelandet undgår användaren. En regel är alltså att meddelandet ska hamna iögonfallande på den skrollposition där användarens webbläsare befinner sig när meddelandet inträffar. Att betänka här är vad som händer om man använder sig av t.ex. Ajaxlösningar där skrollpositionen inte ändras. Då är det inte alls säkert att användaren tas till toppen av sidan. Tänk också på vad som händer om användaren i detta fall inte har Javascript aktiverat och en vanlig post-back sker. Kanske får man då placera meddelandet på olika positioner.
Rättmeddelanden:
Nu har vi behandlar felmeddelanden. Dessa är man ofta ganska duktig på att skriva ut även om kvaliteten på meddelandet vanligen är mindre bra. Något som dock ofta missas grovt är ”rättmeddelanden”. Alltså meddelanden som talar om för användaren att åtgärden lyckades. Inte allt för sällan träffar jag på applikationer där man ska spara en text och när man klickat på spara så laddas sidan om, formuläret är fortfarande ifyllt på samma sätt som innan och man får inget meddelande. Vad gör man då? Testar igen, vilket troligtvis innebär en dubbelpost i databasen alternativt ett felmeddelande som säger att:
Idiot, du kan ju inte posta samma meddelande två gånger… Dhö
En bra bit på vägen är då att visa ett meddelande som istället på ett tidigt stadie talar om att meddelandet är sparats. Dock brukar dessa se ut på nedanstående sätt, eftersom man återanvänder CSS-klassen för sina felmeddelanden. ”Fel som fel…”:
Meddelandet har sparats!
Det är nu jag brukar sätta kaffet i halsen. VAD! Fungerade det inte? Rött har en genomträngande förmåga att förmedla att något falerat och ska givetvis inte användas i detta sammanhang, men det görs. Om och om igen, tro mig. Att man sedan inte ska ge användaren möjlighet överhuvud taget att dubbelposta är en helt annan historia som jag återkommer till. Jag stötte precis på ett liknande senario i publiceringssystemet Drupal. När man sparar en text i detta system får man följande meddelande:
Varför en varningstriangel??? Troligtvis används samma meddelanderuta för fel- såväl som rättmeddelande. Inget bra tillvägagångssätt.
Hur ska man då göra istället? Jo, det är ganska enkelt. Gör på samma sätt som med felmeddelanden fast använd andra färger för att kommunicera budskapet:
Observera att vi givetvis inte kan förlita oss helt och hållet på färg och bild för budskapet utan även måste ha en informativ text för att underlätta för användare med funktionshinder. Vill man vara än mer informativ skulle man kunna tänka sig att lägga till en text om hur man t.ex. uppdaterar sin text.
Placeringen för rättmeddelanden följer samma upplägg som för felmeddelanden. Glöm dock inte bort vikten av att även informera användaren om vad som lyckats i din applikation. Det har redan allt för många gjort före dig.
Meddelanden och tillgänglighet:
Jag har funderat en del kring fel- och rättmeddelanden ur ett tillgänglighetsperspektiv. Om en användare till exempel använder en röstuppläsare för att navigera på vår sajt så kommer troligtvis fel- eller rättmeddelandet aldrig att läsas upp för denna användare då den kanske istället direkt väljer ett menyalternativ som presenteras innan det felmeddelanden som vi skrivit ut på vår sida. Man borde då kunna skriva ut samma fel- eller rättmeddelande före allt annat i sin kod och gömma denna med CSS så att den bara syns om man har css avaktiverat. Exempelvis:
....
Ett fel har inträffat. Din text har inte sparats.
Ett fel har inträffat. Din text har inte sparats.< /div>
...
Förhoppningsvis kommer du nu att ha informativa fel- och rättmeddelanden i dina applikationer.
Mycket intressant läsning! Ska bli spännande att följa denna bloggen.
Varför är det lämpligt att använda ”rättmeddelanden” då det är fråga om webbapplikationer?Antalet ”desktop”-applikation som använder ”rättmeddelanden” är försvinnande få. Har aldrig fått upp en dialogruta med meddelandet ”Filen är sparad.”. Däremot har det hänt ett antal gånger att meddelnaden dykt upp då det inte gick att spara filen. Varför är behovet i webbapplikationer annorlunda? Är det bara för att de är ”stateless” eller finns det månne någon annan anledning?
Intressant frågeställning. Jag tror att anledningen härrör till de många buggiga webbapplikationer som funnits/finns. Användaren är van vid att webbapplikationer buggar ut lite titt som tätt och förväntar sig kanske en högre grad av feeback för att känna sig trygg. Desktopapplikationer som gemene man använder är dessutom ofta skapade av, på marknaden, stora aktörer som har ett väl genomtänkt och utvärderat flöde genom sina applikationer och där mycket fås gratis genom operativsystemen (Fildialogrutor som exempel).
På webben är inte gränssnitten lika strömlinjeformade (även om det blir mer och mer likriktat för varje år) och utvecklarna har en större frihet att designa gränssnitt som kan vara helt obegripliga för användaren (läs facebook) vilket helt enkelt leder till att det krävs mer feedback till användaren för att denne ska förstå vad som händer i applikationen.
Håller med sistnämnda kommentar, det finns alldeles för många buggiga siter så man kan nästan förvänta sig att något gått fel om man inte får bekräftat annat.
Sålänge ”rättmeddelanden” tillför något, varför inte ? Sålänge dom makes sense.
En annan anledning kan vara den långsamma responstid som kan uppstå. En desktop-applikation sparar ju ”direkt”, medan det kanske är förvirrande att klicka på en Submit-knapp på en sajt, vänta flera sekunder eller t.o.m. minuter utan att något händer, för att sedan inte få någon bekräftelse på att allt gått som det ska.
[...] Regel 1) Se till att ha tydliga rätt- och felmeddelanden [...]