Felmeddelanden i Windows 7

Felmeddelanden i Windows 7 varnar användare om problem som redan har inträffat. Varningsmeddelanden varnar däremot användarna om villkor som kan orsaka problem i framtiden. Felmeddelanden kan visas med hjälp av modala dialogrutor, meddelanden på plats, meddelanden eller pratbubblor.

Ett typiskt modalt felmeddelande.

Effektiva felmeddelanden informerar användarna om att ett problem har uppstått, förklarar varför det inträffade och tillhandahåller en lösning så att användarna kan åtgärda problemet. Användarna bör antingen utföra en åtgärd eller ändra sitt beteende till följd av ett felmeddelande.

Välskrivna, användbara felmeddelanden är avgörande för en kvalitetsanvändarupplevelse. Dåligt skrivna felmeddelanden resulterar i låg produktnöjdhet och är en ledande orsak till påverkbara tekniska supportkostnader. Onödiga felmeddelanden bryter användarnas flöde.

Obs! riktlinjer som rör dialogrutor, varningsmeddelanden, bekräftelser, standardikoner, meddelandenoch layout visas i separata artiklar.

Är det här rätt användargränssnitt?

Du kan ta ställning till följande frågor:

• Presenterar användargränssnittet ett problem som redan har uppstått? Annars är meddelandet inte ett fel. Om användaren aviseras om ett villkor som kan orsaka ett problem i framtiden använder du ett varningsmeddelande.
• Kan problemet förhindras utan att orsaka förvirring? I så fall kan du förhindra problemet i stället. Använd till exempel kontroller som är begränsade till giltiga värden i stället för att använda obegränsade kontroller som kan kräva felmeddelanden. Om du inaktiverar kontroller när du klickar kan det också leda till fel, så länge det är uppenbart varför kontrollen är inaktiverad.
• Kan problemet åtgärdas automatiskt? I så fall hanterar du problemet och undertrycker felmeddelandet.
• Kommer användarna sannolikt att utföra en åtgärd eller ändra sitt beteende som ett resultat av meddelandet? Om inte, motiverar villkoret inte att avbryta användaren så det är bättre att undertrycka felet.
• Är problemet relevant när användare aktivt använder andra program? I så fall bör du överväga att visa problemet med hjälp av en meddelandeområdesikon.
• Är problemet inte relaterat till den aktuella användaraktiviteten, kräver det inte omedelbara användaråtgärder och kan användarna fritt ignorera det? I så fall använder du ett meddelande om åtgärdsfel i stället.
• Gäller problemet statusen för en bakgrundsaktivitet i ett primärt fönster? I så fall bör du överväga att visa problemet med hjälp av ett statusstaplar.
• Är it-proffsen för de primära målanvändarena? I så fall bör du överväga att använda en alternativ feedbackmekanism, till exempel loggfil poster eller e-postaviseringar. IT-proffs föredrar starkt loggfiler för icke-kritisk information.

Designbegrepp

Egenskaperna hos dåliga felmeddelanden

Det bör inte vara någon överraskning att det finns många irriterande, ohjälpsamma och dåligt skrivna felmeddelanden. Och eftersom felmeddelanden ofta visas med hjälp av modala dialogrutor avbryter de användarens aktuella aktivitet och kräver att bekräftas innan användaren kan fortsätta.

En del av problemet är att det finns så många sätt att göra det fel. Tänk på de här exemplen från Error Message Hall of Shame:

Onödiga felmeddelanden

felaktig:

Det här exemplet från Windows XP kan vara det värsta felmeddelandet någonsin. Det indikerar att ett program inte kunde startas eftersom Själva Windows håller på att stängas av. Det finns inget användaren kan göra åt detta eller ens vill göra åt detta (användaren valde trots allt att stänga av Windows). Och genom att visa det här felmeddelandet förhindrar Windows sig själv från att stängas av!

Problemet: Själva felmeddelandet är problemet. Förutom att avvisa felmeddelandet finns det inget för användarna att göra.

Ledande orsak: Rapportera alla felfall, oavsett användarnas mål eller synvinkel.

Rekommenderat alternativ: Rapportera inte fel som användarna inte bryr sig om.

felmeddelanden

felaktig:

Det här felmeddelandet berodde på att användaren valde att inte starta om Windows omedelbart efter att programmet tagits bort. Programborttagningen lyckades från användarens synvinkel.

Problemet: Det finns inget fel från användarens synvinkel. Förutom att avvisa felmeddelandet finns det inget för användarna att göra.

Inledande orsak: Uppgiften har slutförts från användarens synvinkel, men misslyckades ur avinstallationsprogrammets synvinkel.

Rekommenderat alternativ: Rapportera inte fel för villkor som användarna anser vara acceptabla.

Helt värdelösa felmeddelanden

felaktig:

Användarna får reda på att det uppstod ett fel, men har ingen aning om vad felet var eller vad de skulle göra åt det. Och nej, det är inte okej!

Problemet: Felmeddelandet ger inget specifikt problem och det finns inget användare kan göra åt det.

Ledande orsak: Troligtvis har programmet dålig felhantering.

Rekommenderat alternativ: Utforma bra felhantering i programmet.

Obegripliga felmeddelanden

felaktig:

I det här exemplet är problembeskrivningen tydlig, men den kompletterande förklaringen är helt förbryllande.

Problemet: Problembeskrivningen eller lösningen är obegriplig.

Ledande orsak: Förklara problemet ur kodens synvinkel i stället för användarens.

Rekommenderat alternativ: Skriv felmeddelandetext som målanvändare enkelt kan förstå. Tillhandahålla lösningar som användarna faktiskt kan utföra. Designa programmets felmeddelandeupplevelse har inte programmerare som skriver felmeddelanden på plats.

Felmeddelanden som överkommunikerar

felaktig:

I det här exemplet försöker felmeddelandet tydligen förklara varje felsökningssteg.

Problemet: för mycket information.

Ledande orsak: Ge för mycket information eller försöka förklara en komplicerad felsökningsprocess i ett felmeddelande.

Rekommenderat alternativ: Undvik onödig information. Undvik även felsökare. Om en felsökare behövs fokuserar du på de mest sannolika lösningarna och förklarar resten genom att länka till lämpligt ämne i Hjälp.

Onödigt hårda felmeddelanden

felaktig:

Programmets oförmåga att hitta ett objekt låter knappast katastrofalt. Och förutsatt att det är katastrofalt, varför är OK svaret?

Problemet: Programmets ton är onödigt hård eller dramatisk.

Ledande orsak: Problemet beror på en bugg som verkar katastrofal ur programmets synvinkel.

Rekommenderat alternativ: Välj språk noggrant baserat på användarens synvinkel.

Felmeddelanden som skyller på användare

felaktig:

Varför får användarna att känna sig som en brottsling?

Problemet: Felmeddelandet formuleras på ett sätt som anklagar användaren för att göra ett fel.

Ledande orsak: okänsliga fraser som fokuserar på användarens beteende i stället för problemet.

Rekommenderat alternativ: Fokusera på problemet, inte den användaråtgärd som ledde till problemet, med hjälp av den passiva rösten efter behov.

Fåniga felmeddelanden

felaktig:

I det här exemplet är problembeskrivningen ganska ironisk och inga lösningar tillhandahålls.

Problemet: Felmeddelandeinstruktioner som är fåniga eller icke-sequitorer.

Ledande orsak: Skapa felmeddelanden utan att ta hänsyn till deras kontext.

Rekommenderat alternativ: Få dina felmeddelanden skapade och granskade av en författare. Tänk på kontexten och användarens sinnestillstånd när du granskar felen.

Programmer-felmeddelanden

felaktig:

I det här exemplet anger felmeddelandet att det finns en bugg i programmet. Det här felmeddelandet har endast betydelse för programmeraren.

Problemet: Meddelanden som är avsedda att hjälpa programmets utvecklare att hitta buggar finns kvar i versionen av programmet. Dessa felmeddelanden har ingen betydelse eller värde för användare.

Ledande orsak: programmerare som använder normalt användargränssnitt för att göra meddelanden till sig själva.

Rekommenderat alternativ: Utvecklare måste villkorligt kompilera alla sådana meddelanden så att de automatiskt tas bort från versionsversionen av en produkt. Slösa inte tid på att försöka göra fel som detta begripliga för användarna eftersom deras enda publik är programmerarna.

Dåligt presenterade felmeddelanden

felaktig:

Det här exemplet innehåller många vanliga presentationsmisstag.

Problemet: Få all information fel i felmeddelandepresentationen.

Ledande orsak: Att inte känna till och tillämpa riktlinjerna för felmeddelanden. Inte använda författare och redigerare för att skapa och granska felmeddelandena.

Typen av felhantering är sådan att många av dessa misstag är mycket lätta att göra. Det är störande att inse att de flesta felmeddelanden kan vara nominerade till Hall of Shame.

Egenskaperna för bra felmeddelanden

Till skillnad från tidigare dåliga exempel har bra felmeddelanden:

• Ett problem. Anger att ett problem uppstod.
• En orsak. Förklarar varför problemet uppstod.
• En lösning. Tillhandahåller en lösning så att användarna kan åtgärda problemet.

Dessutom visas bra felmeddelanden på ett sätt som är:

• Relevant. Meddelandet visar ett problem som användarna bryr sig om.
• Angripbara. Användarna bör antingen utföra en åtgärd eller ändra sitt beteende till följd av meddelandet.
• Användarcentrerad. Meddelandet beskriver problemet när det gäller målanvändaråtgärder eller mål, inte när det gäller vad koden är missnöjd med.
• Kort. Meddelandet är så kort som möjligt, men inte kortare.
• Klar. Meddelandet använder vanligt språk så att målanvändare enkelt kan förstå problem och lösningar.
• Specifik. Meddelandet beskriver problemet med hjälp av ett specifikt språk, med specifika namn, platser och värden för de berörda objekten.
• Artig. Användare bör inte klandras eller fås att känna sig dumma.
• Sällsynt. Visas sällan. Felmeddelanden som visas ofta är ett tecken på felaktig design.

Genom att utforma din felhanteringsupplevelse så att den har dessa egenskaper kan du hålla programmets felmeddelanden borta från Error Message Hall of Shame.

Undvika onödiga felmeddelanden

Ofta är det bästa felmeddelandet inget felmeddelande. Många fel kan undvikas genom bättre design, och det finns ofta bättre alternativ till felmeddelanden. Det är vanligtvis bättre att förhindra ett fel än att rapportera ett.

De mest uppenbara felmeddelandena att undvika är de som inte kan åtgärdas. Om användarna sannolikt kommer att stänga meddelandet utan att göra eller ändra något utelämnar du felmeddelandet.

Vissa felmeddelanden kan elimineras eftersom de inte är problem från användarens synvinkel. Anta till exempel att användaren försökte ta bort en fil som redan håller på att tas bort. Även om detta kan vara ett oväntat fall ur kodens synvinkel, anser användarna inte att detta är ett fel eftersom deras önskade resultat uppnås.

felaktig:

Det här felmeddelandet bör elimineras eftersom åtgärden lyckades från användarens synvinkel.

Anta till exempel att användaren uttryckligen avbryter en uppgift. För användarens synvinkel är följande villkor inte ett fel.

felaktig:

Det här felmeddelandet bör också elimineras eftersom åtgärden lyckades från användarens synvinkel.

Ibland kan felmeddelanden elimineras genom att fokusera på användarnas mål i stället för tekniken. När du gör det bör du tänka över vad ett fel egentligen är. Är problemet med användarens mål eller med programmets förmåga att uppfylla dem? Om användarens åtgärd är meningsfull i den verkliga världen bör det också vara meningsfullt i programvara.

Anta till exempel i ett e-handelsprogram att en användare försöker hitta en produkt med hjälp av sökning, men den literala sökfrågan har inga matchningar och den önskade produkten är slut i lager. Tekniskt sett är detta ett fel, men i stället för att ge ett felmeddelande kan programmet:

• Fortsätt att söka efter produkter som bäst matchar frågan.
• Om sökningen har uppenbara misstag rekommenderar du automatiskt en korrigerad fråga.
• Hantera vanliga problem automatiskt, till exempel felstavningar, alternativa stavningar och felmatchning av pluraliserings- och verbfall.
• Ange när produkten ska finnas i lager.

Så länge användarens begäran är rimlig bör ett väl utformat e-handelsprogram returnera rimliga resultat, inte fel.

Ett annat bra sätt att undvika felmeddelanden är genom att förhindra problem i första hand. Du kan förhindra fel genom att:

• Använda begränsade kontroller. Använd kontroller som är begränsade till giltiga värden. Kontroller som listor, skjutreglage, kryssrutor, alternativknappar och datum- och tidsväljare är begränsade till giltiga värden, medan textrutor ofta inte är och kan kräva felmeddelanden. Du kan dock begränsa textrutor för att endast acceptera vissa tecken och acceptera ett maximalt antal tecken.
• Använda begränsade interaktioner. Tillåt endast att användare släpper giltiga mål för dra-åtgärder.
• Använda inaktiverade kontroller och menyalternativ. Inaktivera kontroller och menyalternativ när användarna enkelt kan ta reda på varför kontrollen eller menyalternativet är inaktiverat.
• Ger bra standardvärden. Användare är mindre benägna att göra indatafel om de kan acceptera standardvärdena. Även om användarna bestämmer sig för att ändra värdet låter standardvärdet användarna känna till det förväntade indataformatet.
• Att få saker att fungera. Användare är mindre benägna att göra misstag om uppgifterna är onödiga eller utförs automatiskt för dem. Eller om användarna gör små misstag men deras avsikt är tydlig, åtgärdas problemet automatiskt. Du kan till exempel automatiskt korrigera mindre formateringsproblem.

Att tillhandahålla nödvändiga felmeddelanden

Ibland behöver du verkligen ange ett felmeddelande. Användare gör misstag, nätverk och enheter slutar fungera, objekt kan inte hittas eller ändras, uppgifter kan inte slutföras och program har buggar. Helst skulle dessa problem inträffa mindre ofta, till exempel kan vi utforma vår programvara för att förhindra många typer av användarmisstag, men det är inte realistiskt att förhindra alla dessa problem. Och när ett av dessa problem inträffar får ett användbart felmeddelande användarna att snabbt komma igång igen.

En vanlig uppfattning är att felmeddelanden är den sämsta användarupplevelsen och bör undvikas till varje pris, men det är mer korrekt att säga att användarförvirring är den värsta upplevelsen och bör undvikas till varje pris. Ibland är den kostnaden ett användbart felmeddelande.

Överväg inaktiverade kontroller. För det mesta är det uppenbart varför en kontroll är inaktiverad, så att inaktivera kontrollen är ett bra sätt att undvika ett felmeddelande. Men vad händer om orsaken till att en kontroll är inaktiverad inte är uppenbar? Användaren kan inte fortsätta och det finns ingen feedback för att fastställa problemet. Nu har användaren fastnat och måste antingen härleda problemet eller få teknisk support. I sådana fall är det mycket bättre att låta kontrollen vara aktiverad och ge ett användbart felmeddelande i stället.

felaktig:

Varför är knappen Nästa inaktiverad här? Bättre att lämna den aktiverad och undvika användarförvirring genom att ge ett användbart felmeddelande.

Om du inte är säker på om du ska ge ett felmeddelande börjar du med att skriva det felmeddelande som du kan ge. Om användarna sannolikt antingen utför en åtgärd eller ändrar sitt beteende som ett resultat anger du felmeddelandet. Om användarna däremot sannolikt kommer att stänga meddelandet utan att göra eller ändra något utelämnar du felmeddelandet.

Designa för bra felhantering

Det kan vara svårt att skapa bra felmeddelandetext, men ibland är det omöjligt utan bra felhanteringsstöd från programmet. Tänk på det här felmeddelandet:

felaktig:

Chansen är stor att problemet verkligen är okänt eftersom programmets stöd för felhantering saknas.

Även om det är möjligt att detta är ett mycket dåligt skrivet felmeddelande återspeglar det mer sannolikt bristen på bra felhantering av den underliggande koden, men det finns ingen specifik information som är känd om problemet.

För att skapa specifika, åtgärdsbara, användarcentrerade felmeddelanden måste programmets felhanteringskod tillhandahålla specifik felinformation på hög nivå:

• Varje problem bör ha en unik felkod tilldelad.
• Om ett problem har flera orsaker bör programmet fastställa den specifika orsaken när det är möjligt.
• Om problemet har parametrar måste parametrarna underhållas.
• Problem på låg nivå måste hanteras på en tillräckligt hög nivå så att felmeddelandet kan visas ur användarens synvinkel.

Bra felmeddelanden är inte bara ett användargränssnittsproblem, de är ett programvarudesignproblem. Ett bra felmeddelande är inte något som kan åtgärdas senare.

Felsökning (och hur du undviker det)

Felsökningsresultat när ett problem med flera olika orsaker rapporteras med ett enda felmeddelande.

felaktig:

rätt:

Felsöka resultat när flera problem rapporteras med ett enda felmeddelande.

I följande exempel gick det inte att flytta ett objekt eftersom det redan har flyttats eller tagits bort eller åtkomst nekades. Om programmet enkelt kan fastställa orsaken, varför lägga bördan på användaren att fastställa den specifika orsaken?

felaktig:

Nå, vilket är det? Nu måste användaren felsöka.

Programmet kan avgöra om åtkomst nekades, så det här problemet bör rapporteras med ett specifikt felmeddelande.

rätt:

Med en specifik orsak krävs ingen felsökning.

Använd endast meddelanden med flera orsaker när den specifika orsaken inte kan fastställas. I det här exemplet skulle det vara svårt för programmet att avgöra om objektet har flyttats eller tagits bort, så ett enda felmeddelande med flera orsaker kan användas här. Det är dock osannolikt att användarna kommer att bry sig om de till exempel inte kunde flytta en borttagen fil. Av dessa orsaker är felmeddelandet inte ens nödvändigt.

Hantera okända fel

I vissa fall känner du verkligen inte till problemet, orsaken eller lösningen. Om det skulle vara oklot att förhindra felet är det bättre att vara i förväg om bristen på information än att presentera problem, orsaker eller lösningar som kanske inte är rätt.

Om programmet till exempel har ett ohanterat undantag är följande felmeddelande lämpligt:

Om du inte kan förhindra ett okänt fel är det bättre att vara i förväg om bristen på information.

Å andra sidan, ange specifik, användbar information om det är troligt att det är till hjälp för det mesta.

Det här felmeddelandet lämpar sig för ett okänt fel om nätverksanslutningen vanligtvis är problemet.

Fastställa lämplig meddelandetyp

Vissa problem kan visas som ett fel, en varning eller information, beroende på betoning och frasering. Anta till exempel att en webbsida inte kan läsa in en osignerad ActiveX-kontroll baserat på den aktuella Windows Internet Explorer-konfigurationen:

• Fel. "Den här sidan kan inte läsa in en osignerad ActiveX-kontroll." (Frasat som ett befintligt problem.)
• Varning. "Den här sidan kanske inte fungerar som förväntat eftersom Windows Internet Explorer inte har konfigurerats för att läsa in osignerade ActiveX-kontroller." eller "Tillåt att den här sidan installerar en osignerad ActiveX-kontroll? Om du gör det från ej betrodda källor kan det skada datorn." (Båda beskrivs som villkor som kan orsaka framtida problem.)
• Information. "Du har konfigurerat Windows Internet Explorer för att blockera osignerade ActiveX-kontroller." (Formuleras som en faktaförklaring.)

För att fastställa lämplig meddelandetyp fokuserar du på den viktigaste aspekten av problemet som användarna behöver känna till eller agera på. Om ett problem blockerar användaren från att fortsätta bör du vanligtvis presentera det som ett fel. Om användaren kan fortsätta kan du presentera den som en varning. Skapa den huvudinstruktionen eller annan motsvarande text baserat på det fokuset och välj sedan en ikon (standard eller på annat sätt) som matchar texten. Huvudinstruktionens text och ikoner ska alltid matcha.

Felmeddelandepresentation

De flesta felmeddelanden i Windows-program visas med hjälp av modala dialogrutor (som de flesta exempel i den här artikeln), men det finns andra alternativ:

• På plats
• Ballonger
• Meddelanden
• Ikoner för meddelandeområde
• Statusstaplar
• Loggfiler (för fel som riktas till IT-proffs)

Att placera felmeddelanden i modala dialogrutor har fördelen att kräva användarens omedelbara uppmärksamhet och bekräftelse. Detta är dock också deras främsta nackdel om den uppmärksamheten inte är nödvändig.

Behöver du verkligen avbryta användare så att de kan klicka på knappen Stäng? Om inte kan du överväga alternativ till att använda en modal dialogruta.

Modal dialogrutor är ett bra val när användaren måste erkänna problemet omedelbart innan du fortsätter, men ofta ett dåligt val annars. I allmänhet bör du föredra att använda den lättaste viktpresentationen som gör jobbet bra.

Undvik överkommunikation av

I allmänhet genomsöker användare inte. Ju mer text det finns, desto svårare är texten att skanna, och desto mer sannolikt kommer användarna inte att läsa texten alls. Därför är det viktigt att minska texten till dess väsentligheter och använda progressivt avslöjande och hjälplänkar när det behövs för att tillhandahålla ytterligare information.

Det finns många extrema exempel, men låt oss titta på ytterligare ett typiskt. I följande exempel finns de flesta attributen för ett bra felmeddelande, men texten är inte koncis och kräver motivation för att läsa.

felaktig:

Det här exemplet är ett bra felmeddelande, men det överkommunikation.

Vad står det egentligen i den här texten? Ungefär så här:

rätt:

Det här felmeddelandet har i stort sett samma information, men är mycket mer kortfattat.

Med hjälp av Hjälp för att ange information har det här felmeddelandet en inverterad pyramidstil presentationen.

Fler riktlinjer och exempel på överkommunikation finns i Användargränssnittstext.

Om du bara gör åtta saker

1. Utforma programmet för felhantering.
2. Ge inte onödiga felmeddelanden.
3. Undvik användarförvirring genom att ge nödvändiga felmeddelanden.
4. Kontrollera att felmeddelandet ger ett problem, en orsak och en lösning.
5. Kontrollera att felmeddelandet är relevant, handlingsbart, kort, tydligt, specifikt, artigt och sällsynt.
6. Utforma felmeddelanden från användarens synvinkel, inte programmets synvinkel.
7. Undvik att involvera användaren i felsökningen genom att använda ett annat felmeddelande för varje identifieringsbar orsak.
8. Använd den lättaste viktpresentationsmetoden som gör jobbet bra.

Användningsmönster

Felmeddelanden har flera användningsmönster:

Etikett	Värde
Systemproblem Operativsystemet, maskinvaruenheten, nätverket eller programmet har misslyckats eller är inte i det tillstånd som krävs för att utföra en uppgift.	Många systemproblem kan lösas av användaren: Enhetsproblem kan lösas genom att aktivera enheten, återansluta enheten och infoga media. Nätverksproblem kan lösas genom att kontrollera den fysiska nätverksanslutningen och köra Nätverksdiagnostik och reparation. Programproblem kan lösas genom att ändra programalternativ eller starta om programmet. I det här exemplet kan programmet inte hitta en kamera för att utföra en användaruppgift. I det här exemplet måste en funktion som krävs för att utföra en uppgift aktiveras.
Filproblem En fil eller mapp som krävs för en uppgift som initierats av användaren hittades inte, används redan eller har inte det förväntade formatet.	I det här exemplet går det inte att ta bort filen eller mappen eftersom den inte hittades. I det här exemplet stöder programmet inte det angivna filformatet.
Säkerhetsproblem Användaren har inte behörighet att komma åt en resurs eller tillräcklig behörighet för att utföra en uppgift som initierats av användaren.	I det här exemplet har användaren inte behörighet att komma åt en resurs. I det här exemplet har användaren inte behörighet att utföra en uppgift.
Aktivitetsproblem Det finns ett specifikt problem med att utföra en uppgift som initierats av användaren (förutom ett system, en fil som inte hittades, filformat eller säkerhetsproblem).	I det här exemplet kan Urklippsdata inte klistras in i Paint. I det här exemplet kan användaren inte installera en programuppgradering.
Problem med användarindata Användaren angav ett värde som är felaktigt eller inkonsekvent med andra användarindata.	I det här exemplet angav användaren ett felaktigt tidsvärde. I det här exemplet är användarindata inte i rätt format.

Riktlinjer

Presentation

• Använd aktivitetsdialogrutor när det är lämpligt för att få ett konsekvent utseende och en layout. Aktivitetsdialogrutor kräver Windows Vista eller senare, så de är inte lämpliga för tidigare versioner av Windows. Om du måste använda en meddelanderuta separerar du huvudinstruktionen från den kompletterande instruktionen med två radbrytningar.

Användarindatafel

• Förhindra eller minska användarindatafel när det är möjligt genom att:
  • Använda kontroller som är begränsade till giltiga värden.
  • Om du inaktiverar kontroller och menyalternativ när du klickar på det uppstår ett fel, så länge det är uppenbart varför kontrollen eller menyalternativet är inaktiverat.
  • Ger bra standardvärden.

felaktig:

I det här exemplet används en obehindrat textruta för begränsade indata. Använd ett skjutreglage i stället.

• Använd lägeslös felhantering (fel på plats eller ballonger) för problem med kontextuella användarindata.
• Använd ballonger för icke-kritiska problem med enstaka användare som identifieras i en textruta eller omedelbart efter att en textruta förlorar fokus.Ballonger inte kräver tillgängligt skärmutrymme eller den dynamiska layout som krävs för att visa meddelanden på plats. Visa endast en pratbubblan i taget. Eftersom problemet inte är kritiskt krävs ingen felikon. Ballonger försvinner när du klickar, när problemet har lösts eller efter en timeout.

I det här exemplet anger en pratbubblan ett indataproblem medan den fortfarande finns i kontrollen.

• Använd fel på plats för fördröjd felidentifiering vanligtvis fel som hittas genom att klicka på en incheckningsknapp. (Använd inte fel på plats för inställningar som har checkats in omedelbart.) Det kan finnas flera fel på plats i taget. Använd normal text och en felikon på 16 x 16 bildpunkter och placera dem direkt bredvid problemet när det är möjligt. Fel på plats försvinner inte om inte användaren checkar in och inga andra fel hittas.

I det här exemplet används ett fel på plats för ett fel som hittas genom att klicka på incheckningsknappen.

• Använd modal error handling (aktivitetsdialogrutor eller meddelanderutor) för alla andra problem, inklusive fel som omfattar flera kontroller eller som inte är kontextuella eller icke-indatafel som hittas genom att klicka på en incheckningsknapp.
• När ett problem med användarindata rapporteras anger du indatafokus till den första kontrollen med felaktiga data. Rulla kontrollen i vyn om det behövs. Om kontrollen är en textruta väljer du hela innehållet. Det bör alltid vara uppenbart vad felmeddelandet refererar till.
• Rensa inte felaktiga indata. Lämna den i stället så att användaren kan se och korrigera problemet utan att börja om.
  • Undantag: Rensa felaktiga textrutor för lösenord och PIN-kod eftersom användarna inte kan korrigera maskerade indata effektivt.

Felsökning

• Undvik att skapa felsökningsproblem. Förlita dig inte på ett enda felmeddelande för att rapportera ett problem med flera olika identifieringsbara orsaker.
• Använd ett annat felmeddelande (vanligtvis en annan kompletterande instruktion) för varje identifieringsbar orsak. Om en fil till exempel inte kan öppnas av flera skäl, anger du en separat tilläggsinstruktion av varje orsak.
• Använd ett meddelande med flera orsaker endast när den specifika orsaken inte kan fastställas. I det här fallet presenterar du lösningarna i ordning efter sannolikheten för att lösa problemet. Detta hjälper användarna att lösa problemet mer effektivt.

Ikoner

• Dialogrutor för modala felmeddelanden har inte namnlistikoner. Namnlistikoner används som en visuell skillnad mellan primära fönster och sekundära fönster.

• Använd en felikon. Undantag:

  • Om felet är ett problem med användarindata som visas med hjälp av en modal dialogruta eller pratbubblan ska du inte använda en ikon. Att göra det strider mot den uppmuntrande tonen i Windows. Felmeddelanden på plats bör dock använda en liten felikon (16 x 16 pixel) för att tydligt identifiera dem som felmeddelanden.

    

    

    I de här exemplen behöver användarindataproblem inte felikoner.

    

    I det här exemplet behöver ett felmeddelande på plats en liten felikon för att tydligt identifiera det som ett felmeddelande.

• Om problemet gäller en funktion som har en ikon (och inte ett problem med användarindata) kan du använda funktionsikonen med ett felöverlägg. Om du gör det använder du även funktionsnamnet som felämne.

  

  I det här exemplet har funktionsikonen ett felöverlägg och funktionen är föremål för felet.

• Använd inte varningsikoner för fel. Detta görs ofta för att göra presentationen känns mindre allvarlig. Fel är inte varningar.

  felaktig:

  

  I det här exemplet används en varningsikon felaktigt för att få felet att kännas mindre allvarligt.

Fler riktlinjer och exempel finns i standardikoner.

Progressivt avslöjande

• Använd knappen Visa/dölj information progressivt avslöjande för att dölja avancerad eller detaljerad information i ett felmeddelande. Om du gör det förenklas felmeddelandet för vanlig användning. Dölj inte nödvändig information eftersom användarna kanske inte hittar den.

I det här exemplet hjälper knappen progressivt avslöjande användarna att öka detaljnivån om de vill ha det, eller förenkla användargränssnittet om de inte gör det.

• Använd inte Visa/dölj information om det inte finns mer information. Upprepa inte bara den befintliga informationen i ett mer utförligt format.
• Använd inte Visa/dölj information för att visa hjälpinformation. Använd hjälplänkar i stället.

Riktlinjer för etikettering finns i Progressive Disclosure Controls.

Visa inte meddelandet igen

• Om ett felmeddelande behöver det här alternativet bör du ompröva felet och dess frekvens. Om det har alla egenskaper för ett bra fel (relevant, åtgärdsbart och sällan) bör det inte vara meningsfullt för användarna att utelämna det.

Fler riktlinjer finns i dialogrutor.

Standardvärden

• Välj det säkraste, minst destruktiva eller säkraste svaret som standard. Om säkerheten inte är en faktor väljer du det mest sannolika eller praktiska kommandot.

Hjälp

• Utforma felmeddelanden för att undvika behovet av hjälp. Normalt bör användarna inte behöva läsa extern text för att förstå och lösa problemet, såvida inte lösningen kräver flera steg.
• Kontrollera att hjälpinnehållet är relevant och användbart. Det bör inte vara en utförlig omläggning av felmeddelandet snarare, det bör innehålla användbar information som ligger utanför omfånget för felmeddelandet, till exempel sätt att undvika problemet i framtiden. Ange inte en hjälplänk bara för att du kan.
• Använd specifika, koncisa och relevanta hjälplänkar för att få åtkomst till hjälpinnehåll. Använd inte kommandoknappar eller progressivt avslöjande för detta ändamål.
• För felmeddelanden som du inte kan göra specifika och användbara kan du överväga att tillhandahålla länkar till onlinehjälpinnehåll. På så sätt kan du ge användarna ytterligare information som du kan uppdatera när programmet har släppts.

Fler riktlinjer finns i Hjälp.

Felkoder

• För felmeddelanden som du inte kan göra specifika och åtgärdsbara eller som de drar nytta av hjälpen kan du även ange felkoder. Användarna använder ofta dessa felkoder för att söka på Internet efter ytterligare information.
• Ange alltid en textbeskrivning av problemet och lösningen. Beror inte bara på felkoden för det här ändamålet.

felaktig:

I det här exemplet används en felkod som ersättning för en lösningstext.

• Tilldela en unik felkod för varje orsak. Om du gör det undviker du felsökning.
• Välj felkoder som enkelt kan sökas på Internet. Om du använder 32-bitarskoder använder du en hexadecimal representation med inledande "0x" och versaler.

rätt:

1234

0xC0001234

felaktig:

-1

-67113524

• Använd Visa/dölj information för att visa felkoder. Fras som felkod: <error code>.

I det här exemplet används en felkod för att komplettera ett felmeddelande som kan dra nytta av ytterligare information.

Ljud

• Följ inte med felmeddelanden med en ljudeffekt eller pip. Att göra det är skakande och onödigt.
  • Undantag: Spela upp ljudeffekten Kritiskt stopp om problemet är kritiskt för datorns drift och användaren måste vidta omedelbara åtgärder för att förhindra allvarliga konsekvenser.

SMS

Allmänt

• Ta bort redundant text. Leta efter den i rubriker, huvudinstruktioner, kompletterande instruktioner, kommandolänkar och incheckningsknappar. I allmänhet lämnar du fulltext i instruktioner och interaktiva kontroller och tar bort eventuell redundans från de andra platserna.
• Använd användarcentrerade förklaringar. Beskriv problemet när det gäller användaråtgärder eller mål, inte när det gäller vad programvaran är missnöjd med. Använd språk som målanvändarena förstår och använder. Undvik teknisk jargong.

felaktig:

rätt:

I de här exemplen talar rätt version användarens språk medan den felaktiga versionen är alltför teknisk.

• Använd inte följande ord:
  • Fel, fel (använd problem i stället)
  • Det gick inte (det gick inte att använda i stället)
  • Ogiltigt, ogiltigt, felaktigt (använd felaktigt i stället)
  • Avbryt, avsluta, avsluta (använd stopp i stället)
  • Katastrofalt, dödligt (använd allvarligt i stället)

Dessa villkor är onödiga och strider mot den uppmuntrande tonen i Windows. När används korrektkommunicerar felikonen tillräckligt att det finns ett problem.

felaktig:

rätt:

I det felaktiga exemplet är termerna "katastrofala" och "fel" onödiga.

• Använd inte fraser som skyller på användaren eller antyder användarfel. Undvik att använda dig och din i fraseringen. Även om den aktiva rösten i allmänhet föredras använder du den passiva rösten när användaren är ämnet och kan känna sig beskylld för felet om den aktiva rösten användes.

felaktig:

rätt:

Det felaktiga exemplet skyller på användaren med hjälp av den aktiva rösten.

• Var specifik. Undvik vaga formuleringar, till exempel syntaxfel och olaglig åtgärd. Ange specifika namn, platser och värden för de berörda objekten.

felaktig:

Filen hittades inte.

Disken är full.

Värdet ligger inte inom intervallet.

Tecknet är ogiltigt.

Enheten är inte tillgänglig.

Dessa problem skulle vara mycket enklare att lösa med specifika namn, platser och värden.

• Ge inte troligtvis osannolika problem, orsaker eller lösningar i ett försök att vara specifik. Ange inte problem, orsak eller lösning om det inte är troligt att det är rätt. Det är till exempel bättre att säga ett okänt fel inträffade än något som sannolikt är felaktigt.
• Undvik ordet "snälla", förutom i situationer där användaren uppmanas att göra något obekvämt (till exempel väntar) eller programvaran är att skylla på situationen.

rätt:

Vänta medan Windows kopierar filerna till datorn.

• Använd ordet "sorry" endast i felmeddelanden som resulterar i allvarliga problem för användaren (till exempel dataförlust eller oförmåga att använda datorn). Be inte om ursäkt om problemet uppstod under programmets normala funktion (till exempel om användaren behöver vänta på att en nätverksanslutning hittas).

rätt:

Fabrikam Backup upptäckte ett oåterkalleligt problem och stängdes av för att skydda filer på datorn.

• Se produkter med hjälp av deras korta namn. Använd inte fullständiga produktnamn eller varumärkessymboler. Inkludera inte företagsnamnet om inte användarna associerar företagsnamnet med produkten. Inkludera inte programversionsnummer.

felaktig:

rätt:

I det felaktiga exemplet används fullständiga produktnamn och varumärkessymboler.

• Använd dubbla citattecken runt objektnamn. Det gör texten enklare att parsa och undviker potentiellt pinsamma uttalanden.
  • Undantag: Fullständigt kvalificerade filsökvägar, URL:er och domännamn behöver inte vara inom dubbla citattecken.

rätt:

I det här exemplet skulle felmeddelandet vara förvirrande om objektnamnet inte var inom citattecken.

• Undvik att starta meningar med objektnamn. Att göra det är ofta svårt att parsa.
• Använd inte utropstecken eller ord med alla versaler. Utropstecken och versaler får det att kännas som om du skriker åt användaren.

Fler riktlinjer och exempel finns i Style och Tone.

rubriker

• Använd rubriken för att identifiera kommandot eller funktionen som felet uppstod från. Undantag:
  • Om ett fel visas av många olika kommandon bör du överväga att använda programnamnet i stället.
  • Om rubriken skulle vara redundant eller förvirrande med huvudinstruktionen använder du programnamnet i stället.
• Använd inte rubriken för att förklara eller sammanfatta problemet som är syftet med huvudinstruktionen.

felaktig:

I det här exemplet används rubriken felaktigt för att förklara problemet.

• Använd versalisering i rubrikformat utan att avsluta skiljetecken.

Huvudinstruktioner

• Använd huvudinstruktionen för att beskriva problemet på ett tydligt, tydligt och specifikt språk.
• Var kortfattad använd bara en enda, fullständig mening. Parera huvudinstruktionen till den viktiga informationen. Du kan lämna ämnet implicit om det är ditt program eller användaren. Ta med orsaken till problemet om du kan göra det kortfattat. Om du måste förklara något mer, använd en kompletterande instruktion.

felaktig:

I det här exemplet placeras hela felmeddelandet i huvudinstruktionen, vilket gör det svårt att läsa.

• Ange deras namn om det finns objekt.
• Undvik att placera fullständiga filsökvägar och URL:er i huvudinstruktionen. Använd i stället ett kort namn (till exempel filnamnet) och placera det fullständiga namnet (till exempel filsökvägen) i tilläggsinstruktionen. Du kan dock placera en enda fullständig filsökväg eller URL i huvudinstruktionen om felmeddelandet annars inte behöver en kompletterande instruktion.

I det här exemplet finns endast filnamnet i huvudinstruktionen. Den fullständiga sökvägen finns i tilläggsinstruktionen.

• Ge inte den fullständiga filsökvägen och URL:en alls om det är uppenbart från kontexten.

I det här exemplet byter användaren namn på en fil från Utforskaren. I det här fallet behövs inte den fullständiga filsökvägen eftersom den är uppenbar i kontexten.

• Använd presens när det är möjligt.
• Använd versalisering i meningsformat.
• Ta inte med de sista perioderna om instruktionen är en instruktion. Om instruktionen är en fråga ska du inkludera ett slutligt frågetecken.

Huvudinstruktionsmallar

Även om det inte finns några strikta regler för frasering kan du prova att använda följande huvudinstruktionsmallar när det är möjligt:

• [valfritt ämnesnamn] kan inte [utföra åtgärd]
• [valfritt ämnesnamn] kan inte [utföra åtgärd] eftersom [orsak]
• [valfritt ämnesnamn] kan inte [utföra åtgärd] till "[objektnamn]"
• [valfritt ämnesnamn] kan inte [utföra åtgärd] till "[objektnamn]" eftersom [orsak]
• Det finns inte tillräckligt med [resurs] för att [utföra åtgärden]
• [Ämnesnamn] har inget [objektnamn] som krävs för [syfte]
• [Enhet eller inställning] är inaktiverat så att [oönskade resultat]
• [Enheten eller inställningen] är inte [tillgänglig | hittades | aktiverad | aktiverad]
• "[objektnamn]" är för närvarande inte tillgänglig
• Användarnamnet eller lösenordet är felaktigt
• Du har inte behörighet att komma åt "[objektnamn]"
• Du har inte behörighet att [utföra åtgärder]
• [programnamn] har upplevt ett allvarligt problem och måste stängas omedelbart

Gör naturligtvis ändringar efter behov för att huvudinstruktionen ska vara grammatiskt korrekt och följa riktlinjerna för huvudinstruktioner.

kompletterande instruktioner

• Använd den kompletterande instruktionen för att:
  • Ge ytterligare information om problemet.
  • Förklara orsaken till problemet.
  • Lista de steg som användaren kan vidta för att åtgärda problemet.
  • Ange åtgärder för att förhindra att problemet upprepas.
• När det är möjligt föreslår du en praktisk och användbar lösning så att användarna kan åtgärda problemet. Kontrollera dock att den föreslagna lösningen sannolikt kommer att lösa problemet. Slösa inte användarnas tid genom att föreslå möjliga, men osannolika, lösningar.

felaktig:

I det här exemplet är problemet och dess rekommenderade lösning möjliga, men de är mycket osannolika.

• Om problemet är ett felaktigt värde som användaren angav använder du den kompletterande instruktionen för att förklara rätt värden. Användarna ska inte behöva fastställa den här informationen från en annan källa.
• Ange ingen lösning om den kan härledas trivialt från problembeskrivningen.

I det här exemplet krävs ingen kompletterande instruktion; lösningen kan enkelt härledas från problembeskrivningen.

• Om lösningen har flera steg visar du stegen i den ordning de ska slutföras. Undvik dock lösningar i flera steg eftersom användarna har svårt att komma ihåg mer än två eller tre enkla steg. Om du behöver fler steg läser du lämpligt hjälpavsnitt.
• Håll kompletterande instruktioner koncisa. Ange bara det som användarna behöver veta. Utelämna onödiga detaljer. Sikta på högst tre meningar med måttlig längd.
• Om du vill undvika misstag när användarna utför instruktioner lägger du resultatet före åtgärden.

rätt:

Klicka på OK om du vill starta om Windows.

felaktig:

Klicka på OK för att starta om Windows.

I det felaktiga exemplet är det mer troligt att användarna klickar på OK av misstag.

• Rekommendera inte att du kontaktar en administratör om det inte är en av de mest sannolika lösningarna på problemet. Reservera sådana lösningar för problem som egentligen bara kan lösas av en administratör.

felaktig:

I det här exemplet är problemet troligtvis med användarens nätverksanslutning, så det är inte värt att kontakta en administratör.

• Vi rekommenderar inte att du kontaktar teknisk support. Alternativet att kontakta teknisk support för att lösa ett problem är alltid tillgängligt och behöver inte höjas upp via felmeddelanden. Fokusera i stället på att skriva användbara felmeddelanden så att användarna kan lösa problem utan att kontakta teknisk support.

felaktig:

I det här exemplet rekommenderar felmeddelandet felaktigt att du kontaktar teknisk support.

• Använd fullständiga meningar, versalisering i meningsformat och avslutande skiljetecken.

Incheckningsknappar

• Om felmeddelandet innehåller kommandoknappar eller kommandolänkar som löser problemet följer du deras respektive riktlinjer i dialogrutor.
• Om programmet måste avslutas på grund av felet anger du knappen Avsluta program. Undvik förvirring genom att inte använda Stäng för det här ändamålet.
• Annars anger du knappen Stäng. Använd inte OK för felmeddelanden, eftersom den här formuleringen innebär att problemen är OK.
  • Undantag: Använd OK om felrapporteringsmekanismen har fasta etiketter (som med MessageBox-API:et.)

Dokumentation

När du refererar till fel:

• Se fel i deras huvudinstruktion. Om huvudinstruktionen är lång eller detaljerad sammanfattar du den.
• Om det behövs kan du referera till en dialogruta med felmeddelanden som ett meddelande. Se som ett felmeddelande endast i programmering och annan teknisk dokumentation.
• Formatera texten med fet stil när det är möjligt. Annars placerar du texten endast inom citattecken om det behövs för att förhindra förvirring.

Exempel: Om du får en Det inte finns någon CD-skiva i enheten meddelande, infogar du en ny CD-skiva på enheten och försöker igen.