| Olika typer av meddelanden |
| Av: Meta | 10/01/2006 klockan 13:25 |
Hej!
Jag söker en metod att ta reda på vilka typer av meddelanden en applikation spottar ut.
Exempel:
1. Användaren har gjort något otillåtet
2. Användaren har gjort något som i och för sig är tillåtet men på ett felaktigt sätt (och alltså bör korrigeras)
3. Något annat har hänt (som inte användaren rår för)
etc etc.
Någon som känner till en bra mall för hur man ska tänka och lägga upp arbetet? Ordval? Finns det några ord man absolut INTE ska använda.
Tack på förhand, alla tips välkomna. |
Joakim svarade 11/01/2006 klockan 13:56 |
Microsoft definierar tre olika tper av meddelanden (messages): (1) information message, som ger information om utfallet av en viss handling (har bara en OK-knapp i regel (I-ikon i pratbubbla)); (2) warning message, som begär att användaren svara på en fråga innan arbetet kan fortsätta (har i regel en OK/Yes-, ev. en No och ev. en Cancel-knapp beroende på typ av fråga (I-ikon i varningstriangel); samt (3) critical message, där något har gått snett, som t.ex. en felaktig inmatning eller systemfel (har i regel bara en Close-knapp (X-ikon i röd cirkel)).
Det finns dock ett par större frågor i sammanhanget. För det första så bör man ju aldrig skylla på användaren när något har gått fel. Om en användare matar in något tokigt så beror det på att designen av systemet tillåter det och ibland t.o.m. uppmuntrar det. Detta faktum ska också återspeglas i hur ett ev. felmeddelande är formulerat - skyll aldrig på användaren. Vidare så är felmeddelanden sällan det bästa sättet att hantera uppkomsten av fel. Som nämnt, man kan utforma systemet på ett sätt så att felet inte uppkommer från första början. Dock kommer fel alltid att inträffa och man måst möte upp dem. Dett kan dock göras med fördel på andra sätt än att avbryta arbetsflödet genom att skicka upp ett felmeddelande, t.ex. genom att använda sig av tool- eller balloon-tips istället.
Vad gäller formuleringar så har Microsoft en del att lära ut om detta också (du hittar det mesta i Microsoft Windows User Experience-litteratur (finns en bit ner i hierarkin här: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_uidesigndev.asp). T.ex. att alltid uttrycka sig i presens, i första person, etc. Genom annan litteratur kan man läsa att ev. bisatser ska skrivas först, att man ska tala vad som hänt, varför, samt hur det korrigeras (i den ordningen), etc. |
Anna svarade 11/01/2006 klockan 16:46 |
Hej!
I ett tidigare projekt jag jobbade i definierade vi felhanteringsmeddelanden i:
1. Validering av inmatade uppgifter.
Här kunde det handla om att användaren matar in uppgifter i ett fält i en felaktig form eller inte fyller i ett obligatoriskt fält alls.
2. Tekniska fel.
Motsvarar t ex att en server ligger nere eller att ett system som ska anropas inte svarar.
3. Inga uppgifter i svar.
Motsvarar att en sökning inte ger något svar alls. Ur ett systemtekniskt perspektiv är det ju inte ett fel, eftersom inmatad data är rätt och systemet svarar på anrop. Ur användningssynpunkt är det ändå att betrakta ett fel att man inte får fram något svar av den typ man har förväntat sig. Användaren ska ju meddelas om att inget resultat finns att visa. |
Mats Berglind svarade 13/01/2006 klockan 11:44 |
Hej Meta!
Om jag tolkar dig rätt så vill du få fram en metod att ta reda på vad för felmeddelande en (befintlig) applikation spottar ut sig, inte hur du gör för en ny appikation. Då är mitt förslag att du pratar med era testare, de är experter och har helhetssynen (till skillnad på utvecklarna om det inte är ett litet projekt) på allt sådant.
Ett bra sätt att lägga upp arbetet (efter att ha fått tillgång till alla felmeddelanden) skulle kunna vara att titta igenom alla felmeddelanden och se vilja som faktiskt kan designas bort, ex. max antal tecken i ett textfält, felaktiga val, etc.
Lite kommentarer till felmeddelanden:
* Användaren ska väl inte kunna göra något otillåtet, i så fall tycker jag det är ett designfel.
* Om applikationen tillåter användaren att mata in felaktig data så finns även där ett designfel (som visserligen inte alltid går att designa bort, men det går att informera bort) - ex. datumformat.
* Kalla ingenting för "användarfel", det finns inget sådant - bara designfel.
Ett felmeddelande bör bestå av tre delar:
1) Rubrik på feltyp
2) Förklaring på vad som hänt och även kanske varför det hänt - inklusive en ursäkt.
3) Ett förslag på vad användaren ska göra för att lösa problemet
4) Erbjuda vägar ifrån felsidan och ev en sökfunktion
5) Kanske be användaren meddela felet till er
MEN när verkligheten kommer ikapp kan man inte alltid göra bra felmeddelande pga företagspolicys etc. Det kanske inte är så bra för ex. ett webbhotell att förklara att alla en server är nere utan det kanske är bättre att skriva "Tekniskt fel" i sådana fall. |
Meta svarade 16/01/2006 klockan 14:35 |
Hej och tack för kloka ord, man har mycket att lära sig minsann.
Ja, jag har börjat med att gå igenom alla meddelanden applikationen spottar ut och delat in dem i områden. Jag förstår bara inte riktigt hur ni menar med att användaren inte kan göra fel, eller hur man designar bort max antal tecken i ett textfält. |
Anna svarade 16/01/2006 klockan 16:02 |
Se det så här: Designen bör förhindra fel i så stor omfattning som möjligt, genom att vara tydlig, ge feedback, ha bra navigation, rätt sorts begrepp i texter osv. Det går t ex i många fall att bestämma att man bara får skriva in ett visst antal tecken i ett fält för att undvika konstiga inmatningar. Det är lättare i wind32 applikationer än i web dito, men det går.
Det gäller också att se till att förhindra att användaren råkar göra allvarliga saker av bara farten. Att radera saker ska t ex alltid medföra varningsmeddelanden, kanske flera stycken. Eller så ska det helt enkelt inte finnas någon möjlighet att göra det.
Däremot går det aldrig att helt få bort det faktum att en människa aldrig kommer att interagera på ett från systemperspektiv felfritt sätt. Man är ju bara människa - det är mänskligt att fela. Det måste finnas felhantering, med andra ord. Men se'n är det ju det ju vara stor skillnad på hur man väljer att definiera det som inträffar när en användare inte gör som designern/programmeraren tänkt.
|
Karin svarade 16/01/2006 klockan 16:37 |
| Lite tips om design för att undvika felmeddelanden och vad de ovanstående kommentarerna menar med detta kan du hitta i Alan Coopers "About Face". |
Maria Lindström svarade 17/01/2006 klockan 12:07 |
Vill också rekommendera en bok av Alan Cooper: "Inmates are Running the Asylum - Why High-tech Products Drive us Crasy and How to Restore the Sanity".
Underbar bok som är både informativ och underhållande. Läs den om du är intresserad av HCI och usability!
|
Meta svarade 17/01/2006 klockan 15:27 |
| Har köpt Alan Coopers bok och ser fram emot att hinna läsa den! |
