Ett fokus som jag kommer att ha är att försöka få svar på vilka eventuella problem asynkrona uppdateringar av sidor ger vid användandet av till exempel skärmläsare. Enligt tidigare forskning på området som jag läst så är har skärmläsare väldigt svårt att hantera asynkrona uppdateringar och de informerar inte användaren om att innehållet på sidan har ändrats. Kanske är detta bättre idag?
Det blir också intressant att höra vad den lag som införs 2010 för tillgänglighet på bland annat myndigheters webbplatser kommer att innebära i pratiken.

Mitt mål är att försöka komma med en sammanfattning här när jag är tillbaka på fredag.

Vad tror ni om denna Sonygrunka? Verkar lovande….

Regel 2) Markera alltid aktivt menyval

Bakgrund:

I princip samtliga webbapplikationer kräver någon form av navigationssystem, webben bygger trots allt på användarens möjlighet att navigera via hyperlänkar. Vad skiljer då ett bra navigationssystem från ett mindre bra? Jakob Nielsen (Nielsen, 2001:188) sammanfattar att ett navigationsgränssnitt måste besvara tre grundläggande frågor för användaren:

• Var är jag?
• Var har jag varit?
• Vart kan jag gå?

Vidare menar Nielsen att den första frågan är den viktigaste. ”Var är jag?”. Nielsen menar att för att få en förståelse för en webbsidas struktur krävs det att vi vet var i strukturen vi befinner oss.

Man måste vara medveten om att användare idag väldigt ofta dyker rakt in i vår webbapplikation ”utan att passera Gå”, det vill säga, utan att först besöka startsidan för att sedan följa en av oss utstakad väg till aktuell sida. Istället trillar användare ofta in mitt i vår applikation på grund av sökningar i sökmotorer, inlänkningar från andra webbplatser eller besök via bokmärken. Av denna anledning är det viktigt att vår webbplats tydligt förmedlar användarens aktuella position i förhållande till: (Nielsen, 2001:189)

• Webben som helhet
• Wepplatsens struktur

Den första punkten trycker på vikten av att användaren oavsett vilken undersida man är inne på, tydligt kan se vilken sajt man besöker. Något som ofta är problematiskt i frameade lösningar.

Jag ska dock fokusera denna artikel på vikten av att klargöra var användaren befinner sig i förhållande till webbplatsens struktur.

Varför markera aktivt menyval?

Det finns många fördelar med att markera aktivt menyalternativ. Först och främst så har vi redan nu klargjort vikten av att låta användaren tydligt veta var denne befinner sig för att lättare få en överblick över
webbplatsen men det finns även andra finesser med att markera menyalternativet.

Den ouppmärksamme
Om webbplatsen följer konstens alla regler och använder en enhetlig layout på samtliga sidor och dessutom är snabb för användaren att ladda in så kan effekten bli att användaren klickar på en länk i menyn men inte hinner uppfatta att innehållet laddats in. Om då inte det aktiva menyalternativen är markerade är risken stor att användaren klickar flera gånger på samma länk innan användaren uppmärksammar att man faktiskt redan bytt sida.

Den noggranne
Många användare söker systematiskt igenom webbplatsen, menyalternativ efter menyalternativ, för att hitta vad som söks. Om då aktivt menyalternativ inte är markerat i kombination med en större meny och att det inte finns något som utmärker redan besökta sidor kan användaren ha svårt att indentifiera vilket som är nästa länk i ordningen.

Den upptäckande
Användare som navigerat till den webbplats via till exempel en sökmotor har stor hjälp av att veta vilken sida som man befinner sig på i menyhierarkin. Användaren har i detta fall inte själv gjort valet av att klicka på menylänken och har därför ingen möjlighet att veta var man befinner sig.

Den handikappade
Vissa former av kognitiva funktionshinder kan leda till att användaren har svårt att navigera i tid och rum. Detta gör det extra viktigt för oss att ge användaren tydlig information om var denne befinner sig.

Bakåtsträvaren
Om en användare navigerat under en tid på din webbplats och sedan vill backa tillbaka till en sida som denne läst tidigare är det mycket lätt att följa det markerade menyalternativet i takt med att man klickar på tillbaka knappen. Givetvis är det också viktigt att använda tydliga sidtitlar så att användaren direkt kan välja en tidigare sida med avseende på dess titel, men det är en helt annan historia.

Plus många, många fler anledningar till att markera aktivt menyval…

Hur bör ett markerat menyval se ut?

Med anledningarna till att ha väl markerade menyalternativ klargjorda kan vi nu gå över och titta på hur menyvalen ska utformas.

Det viktigaste är att det aktiva menyvalet klart och tydligt skiljer sig från mängden. Jag har en svag förälskelse i flikmenyer då dessa är mycket tydliga på denna punkt. Inte bara kan man se till att färgen skiljer sig åt, man kan även skapa effekten av att aktiv flik befinner sig framför de övriga menyalternativen. Betrakta följande bild som är tagen från en kurshemsida skapad av Mats Loock:

Här råder det ingen som helst tvekan om vilken sida som användaren besöker just nu. Lite mer tvekan är det dock på undermenyn. Är användaren inne på ”Laborationsuppgifter” eller ”Stegtest”? Rätt svar i detta fall är ”Laborationsuppgifter”.

När man använder färger för att särskilja menyalternativ gäller det dock att man är uppmärksam på hur dessa färger uppfattas om i svartvitt. Alltså vilken kontrast som färgerna har i förhållande till varandra.

Betrakta följande exempel:

Här är det väldigt svårt att se skillnad på de olika färgerna när man ser dem i svartvitt medan de i färg är tydliga. Cirka 10% av männen och ett fåtal procent av kvinnorna (Surfa utan hinder) har svårt att urskilja färger på ett eller annat sätt, även kallat färgblinda. Det är därför viktigt att ha tydliga kontraster mellan alternativen. Betrakta istället följande meny:

Här ser vi att alternativen tydligt är skilda från varandra oavsett om menyn är i färg eller i svartvitt.

Hur du väljer att utforma din markering av aktivt menyval är helt upp till dig själv så länge som det är tydligt vilket val som är aktivt.

Tekniskt

Hur går man då tillväga rent tekniskt för att uppnå detta. Vanligast och helst uppnår man dessa effekter med hjälp av CSS. Typiskt gör man det genom att i sin HTML-kod tilldela aktivt menyalternativ en CSS-klass som man sedan låter överskugga övriga menyalternativ.

HTML:

<ul>
	<li><a href="sida1.html">Sida 1</a></li>
	<li><a href="sida2.html">Sida 2</a></li>
	<li class="active">Sida 3</li>
	<li><a href="sida4.html">Sida 4</a></li>
</ul>

CSS:

.active {
  background-color:#125471;
}

Observera att jag här även valt att ta bort länken från aktivt menyval. Det gör att detta menyval inte heller är klickbart om man redan besöker sidan. Bonusen här är att menyalternativet även blir markerat då man besöker sidan utan stilmallar.

Det finns andra sätt att uppnå ovanstående effekter på. Bland annat skriver Jeffery Zeldman om ett angreppssätt som lämpar sig bättre då man har dynamiskt genererat innehåll. (Zeldman 2007:268)

Källförteckning:

Nielsen, Jakob, 2001. Användbar webbdesign. Stockholm: Liber

Zeldman, Jeffery, 2007. Designing with web standards second edition. Berkeley: New Rider

Tidigare artiklar:

Regel 1) Se till att ha tydliga rätt- och felmeddelanden

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:

....
<body>
 
   <div class="hide">Ett fel har inträffat. Din text har inte sparats.</div>
       <div class="menu">
           <ul>
        	<li>Item 1</li>
                ...
           </ul>
        </div>
 
        <div id="mainContent">
            <div class="error">Ett fel har inträffat. Din text har inte sparats.&lt; /div&gt;
             ...
        </div>
    </div>
</body>

Förhoppningsvis kommer du nu att ha informativa fel- och rättmeddelanden i dina applikationer.