lillbra.se

Fel, fel och åter fel

Att få ett felmeddelande kastat i ansiktet är alltid lika frustrerande. Men det finns saker att göra för att lindra användarens plåga då ett fel uppstår. J. Frank Carr listar de viktigaste punkterna att tänka på när man skapar felmeddelanden (via DotNetKicks.com, fritt översatt av mig):

1. Undvik att fel uppstår; koda så att fel fångas upp och hanteras i möjligaste mån
2. Använd inte default-meddelanden från programmeringsspråket/plattformen
3. Undik vaga och ospecifierade meddelanden
4. Hjälp användaren att lösa problemet (t.e.x. Googles ”did you mean” när man stavat fel)
5. Skyll inte på användaren, utan var hövlig

Och i bara farten ger han instruktioner för hur man skriver just hövliga felmeddelanden:

1. Undvik CAPS LOCK
2. Undvik nedsättande och alarmerande ord som katastrofal, olaglig, felaktig
3. Om ikoner ska användas: Använd standardikoner och inte någon dödskallesymbol eller liknande
4. Se till att meddelandet är grammatiskt korrekt och rättstavat

Även Johan Berndtsson tar upp några liknande riktlinjer för bättre felmeddelanden:

1. Fundera på om du verkligen behöver skriva felmeddelandet. Går det att programmera om systemet så att felet inte uppstår?
2. Om felmeddelandet verkligen behövs, formulera det som en fråga och ge användaren möjlighet att avhjälpa felet direkt. T.ex. “Microsoft Office Excel väntar på att Outlook skall stänga fönstret där filen Tidrapport.xls visas. Vill du stänga filen Tidrapport.xls?” Ja | Nej
3. Om du inte kan erbjuda en möjlighet för att avhjälpa felet direkt i felmeddelandet kan du berätta vad användaren kan göra för att ta sig runt problemet. T.ex. “Microsoft Office Excel väntar på att Outlook skall stänga fönstret där filen Tidrapport.xls visas. Stäng filen Tidrapport.xls och klicka sedan på Försök igen.” Försök igen | Avbryt

Själv fick jag följande tvåspråkiga felmeddelande förra veckan:

Så ännu en punkt kan läggas till listorna ovan: Håll dig till ett språk – det blir proffsigare…
Fler ”roliga” felmeddelanden brukar man kunna hitta på Worse Than Failure.
(Tack till Peter och Kristian).

[tags]användbarhet, felmeddelanden, fel[/tags]

Använda tel eller callto i länkar

Som jag nämnde i inlägget Konsten att länka är en av riktlinjerna i Vägledningen 24-timmarswebben att göra det möjligt att ringa upp telefonnummer på sajten. Detta eftersom fler surfar med telefonen och att IP-telefoni blir allt vanligare.

Genom att i koden markera telefonnummer som tel-länkar ges möjlighet att direkt ringa upp numret. På samma sätt som e-postlänkar (mailto:) automatisk ger möjlighet att skicka e-post ger telefonlänkar (tel:) möjlighet att direkt ringa upp numret.[…] <a class="phone" href="tel:+46855050000"> 08 – 55 05 00 00</a>

Vägledningen 24-timmarswebben 5.5.3 Gör det möjligt att ringa upp telefonnummer

När man spenderat lite tid på webben kan man snabbt konstatera att det inte är många som länkar sina telefonnummer (inte ens Verva själva). Bland dem som gör det, t.ex. hitta.se, används callto-schemat istället för tel. Och då man installerar Skype och Neetmeeting tycks det som att callto i flera webbläsare associeras med dessa progam, men inte tel-länkar. Varför ska man då använda tel-schemat, och inte callto?
Min kollega Kristian Ledung kontaktade Verva och för att få klarhet runt riktlinjen. Det visade sig vara två anledningar till varför tel är att föredra framför callto.

Tel-elementet valdes eftersom det är det element som standarden rekommenderar. […] Tel fungerar enligt våra tester (som inte är heltäckande) bättre än callto i mobiltelefoner, vilket sågs som det huvudsakliga användningsområdet när rekommendationen skrevs.

Magnus Burell, Verva E-post till Kristian Ledung (2007-05-23)

Följande testresultat bifogades:

Tel är alltså fastslagen standard. Callto finns inte med bland de URL-scheman som är tillåtna för länkar. Och det är naturligtvis ett tungt argument för att använda tel.

Mobila användare ringer upp numret om de klickar på en tel-länk, men PC-användaren kommer till en “sidan kan inte visas” eller får ett felmeddelande om att webbläsaren inte vet hur länken ska hanteras.
Det kan vara förvirrande för användaren och frågan är om inte tel-länkar gör mer skada än nytta just nu? Spontant känns tel-schemat inte moget för när man surfar på något annat än en telefon, och att det är ett typiskt fall då man vill servera olika innehåll beroende på om användaren surfar på mobil eller inte.
Jag anser att man får avvakta med att använda både tel eller callto, tills webbläsartillverkare börjar följa standard.

Callto håller som sagt på att utvecklas till en de facto-standard. Men det finns också fler alternativ: sip och h323. De är standardvänliga och ska användas till Session Initiation Protocol respektive H.323, protokoll som är vanligt förekommande bland Voip-klienter. Och vem vet, kanske är det så vi ska märka länkar till telefonnummer i framtiden? Kastar in en sådan brasklapp här bara för att krångla till det hela lite

[tags]tel, callto, URL-scheman, länkar, vägledningen 24-timmarswebben, voip[/tags]

OS 2012 skadar besökaren

Kraftiga animeringar på en webbsida är distraherande och ska helst undvikas. I bland annat Vägledningen 24-timmarswebben kan man läsa att rörelser, flimmer och blinkningar inte bör finnas i gränssnittet:

Flimmer är mycket störande och kan skapa stora problem för användaren. För en del användare kan det till och med vara skadligt.

Vägledningen 24-timmarswebben 3.3.21 Använd inte flimmer och blinkningar

Ovanstående var något som inte organisationen bakom London-OS 2012 tog i beaktning. När den nya OS-sajten lanserades för två veckor sedan fanns där nämligen en animerad film som framkallade epileptiska anfall hos flera besökare. Filmen visade en simhoppare som dök ner i vattnet. Plasket från hoppet övergick till en blinkande färgkaskad – en animering som ledde till att minst 18 personer drabbades av anfall.
Det blev ett beklagligt sätt att lära sig en läxa, och filmen är nu borttagen från sajten.

[tags]OS 2012, London 2012, epilepsi, vägledningen 24-timmarswebben[/tags]