Meddelanden (grundläggande design)
Not
Den här designguiden skapades för Windows 7 och har inte uppdaterats för nyare versioner av Windows. Mycket av vägledningen gäller fortfarande i princip, men presentationen och exemplen återspeglar inte vår nuvarande designvägledning.
Ett meddelande informerar användarna om händelser som inte är relaterade till den aktuella användaraktiviteten genom att kort visa en ballong från en ikon i meddelandefältet. Meddelandet kan bero på en användaråtgärd eller betydande systemhändelse, eller kan ge potentiellt användbar information från Microsoft Windows eller ett program.
Informationen i ett meddelande är användbar och relevant, men aldrig kritisk. Därför kräver meddelanden inte omedelbara användaråtgärder och användarna kan fritt ignorera dem.
Ett typiskt meddelande.
I Windows Vista och senare visas meddelanden under en fast varaktighet på 9 sekunder. Meddelanden visas inte omedelbart när användare är inaktiva eller skärmsläckare körs. Windows köar automatiskt meddelanden under dessa tider och visar de köade meddelandena när användaren återupptar regelbunden aktivitet. Därför behöver du inte göra något för att hantera dessa särskilda omständigheter.
Utvecklare: Du kan avgöra när användaren är aktiv med hjälp av SHQueryUserNotificationState-API:et.
Obs! riktlinjer för meddelandeområde, aktivitetsfältetoch pratbubblor visas i separata artiklar.
Är det här rätt användargränssnitt?
Du kan ta ställning till följande frågor:
- Är informationen det omedelbara, direkta resultatet av användarnas interaktion med ditt program? I så fall visar du den här synkrona informationen direkt i programmet i stället med hjälp av en dialogruta, meddelanderutan, pratbubblaneller på plats användargränssnittet. Meddelanden är endast för asynkron information.
I det här exemplet visas dialogrutan Windows-brandväggsfel som ett direkt resultat av användarinteraktion. Ett meddelande skulle inte vara lämpligt här.
- Är informationen endast relevant när användare aktivt använder ditt program? I så fall visar du informationen i programmets statusfält eller annat statusområde.
I det här exemplet visar Outlook dess anslutnings- och synkroniseringstillstånd i statusfältet.
- Är informationen snabbt föränderlig, kontinuerlig, realtidsinformation? Exempel är bearbetningsförlopp, aktiekurser och sportpoäng. I så fall ska du inte använda meddelanden eftersom de inte är lämpliga för snabb ändring av information.
- Är informationen användbar och relevant? Kommer användarna sannolikt att ändra sitt beteende eller undvika olägenheter till följd av att de får informationen? Annars visar du inte informationen eller placerar den i ett statusfönster eller en loggfil.
- Är informationen kritisk? Krävs omedelbara åtgärder? I så fall visar du informationen med hjälp av ett gränssnitt som kräver uppmärksamhet och som inte enkelt kan ignoreras, till exempel en modal dialogruta eller meddelanderuta. Om programmet inte är aktivt kan du uppmärksamma den kritiska informationen genom att att blinka programmets aktivitetsfältsknapp tre gånger och lämna den markerad tills programmet är aktivt.
- Är it-proffsen för de primära målanvändarena? I så fall använder du en alternativ feedbackmekanism som loggfil poster eller e-postmeddelanden. IT-proffs föredrar starkt loggfiler för icke-kritisk information. Dessutom hanteras servrar ofta via fjärranslutning och körs vanligtvis utan att några användare är inloggade, vilket gör meddelanden ineffektiva.
Designbegrepp
Effektiva meddelanden som främjar en bra användarupplevelse är:
- Asynkron. Händelsen är inte ett omedelbart, direkt resultat av användarnas aktuella interaktion med Microsoft Windows eller ditt program.
- Nyttig. Det finns en rimlig chans att användarna utför en uppgift eller ändrar sitt beteende till följd av meddelandet.
- Relevant. Meddelandet visar användbar information som användarna bryr sig om och inte redan vet.
- Inte kritiskt. Meddelanden är inte modala och kräver inte användarinteraktion, så användarna kan fritt ignorera dem.
- Angripbara. För de meddelanden som föreslår att en åtgärd ska utföras initieras åtgärden genom att klicka på meddelandet. Åtgärden kan dock alltid skjutas upp.
- Korrekt presenterad. Meddelandets presentation (varaktighet, frekvens, text, ikon och interaktivitet) matchar dess omständigheter.
- Inte irriterande! Det finns en fin linje mellan att försiktigt informera användarna om en händelse och plåga dem.
Tyvärr finns det för många irriterande, olämpliga, värdelösa, irrelevanta meddelanden där ute. Tänk på dessa meddelanden från Windows XP Hall of Shame:
I de här exemplen försöker Windows XP till synes hjälpa användarna med den inledande konfigurationen. Dessa meddelanden dyker dock upp alldeles för ofta och långt efter att de är användbara, så de är lite mer än oönskade funktionsannonser.
Användarflödet måste upprätthållas
Helst kan användare som är nedsänkta i sitt arbete inte se dina meddelanden alls. I stället ser de bara dina meddelanden när deras flöde redan är brutet.
I Flow: The Psychology of Optimal Experience säger Mihaly Csikszentmihalyi att användare går in i ett flödestillstånd när de är helt absorberade i aktivitet under vilken de förlorar sin tidskänsla och har känslor av stor tillfredsställelse.
Effektiva meddelanden hjälper användarna att behålla sitt flöde genom att presentera användbar, relevant information som enkelt kan ignoreras. Meddelandena visas på ett lågmält, perifert sätt och de kräver inte interaktion.
Anta inte att om meddelanden lägeslösa en kan de inte vara ett irriterande avbrott. Meddelanden kräver inte användarnas uppmärksamhet, men de begär det verkligen. Du kan bryta användarnas flöde genom att:
- Visa meddelanden som användarna inte bryr sig om.
- Visar ett meddelande för ofta.
- Använda flera meddelanden när ett enda meddelande räcker.
- Använda ljud när du visar ett meddelande.
I Windows 7 har användarna ultimat kontroll över meddelanden. Om användarna tycker att ett programs meddelanden är för irriterande kan de välja att utelämna alla meddelanden från programmet. Se till att användarna inte gör detta i ditt program genom att presentera användbar, relevant information och följa dessa riktlinjer.
Meddelanden måste vara okunniga
Meddelanden kräver inte omedelbara användaråtgärder och användarna kan fritt ignorera dem.
Utvecklare och designers vill ofta presentera sina meddelanden på ett sätt som användarna inte kan ignorera. Det här målet undergräver helt den primära fördelen med meddelanden eftersom det skulle bryta användarnas flöde. Om användarna distraheras av dina meddelanden eller känner sig tvungna att läsa dem har din meddelandedesign misslyckats.
Om du är orolig för att användarna ignorerar dina meddelanden bör du tänka på följande:
- Om du använder aviseringar på rätt sätt och de inte kräver omedelbara användaråtgärder är det avsiktligt att låta användarna välja att ignorera dem. Ändra inte detta.
- Om händelsen kräver omedelbar användaråtgärd använder du ett alternativt användargränssnitt (UI) som användarna inte kan ignorera. Se Är det här rätt användargränssnitt? alternativ.
Använd progressiv eskalering där det är tillämpligt
Om ett meddelande används för en händelse som användarna säkert kan ignorera först, men som måste åtgärdas så småningom, bör ett alternativt användargränssnitt användas när situationen blir kritisk. Den här tekniken kallas progressiv eskalering.
Till exempel indikerar Windows energisparsystem till en början ett lågt batteri genom att helt enkelt ändra ikonen för meddelandeområdet.
I de här exemplen använder Windows energisparfunktioner meddelandeområdesikonen för att meddela användarna om progressivt lägre batteridrift.
När batterieffekten blir lägre varnar Windows användare om svag batterikraft med hjälp av ett meddelande.
I det här exemplet använder Windows energisparfunktioner ett meddelande för att berätta för användarna att deras batterikraft är svag.
Det här meddelandet visas medan användarna fortfarande har flera alternativ. Användare kan ansluta, ändra sina energialternativ, avsluta sitt arbete och stänga av datorn eller ignorera meddelandet och fortsätta arbeta. När batterikraften fortsätter att tömmas återspeglar meddelandets text och ikon den ytterligare brådskan. Men när batterikraften blir så låg att användarna måste agera omedelbart meddelar Windows energisparfunktioner användare med hjälp av en modal meddelanderuta.
I det här exemplet använder Windows energisparfunktioner en meddelanderuta för att meddela användarna om kritiskt låg batteridrift.
Om du bara gör tre saker...
- Använd endast meddelanden om du verkligen behöver det. När du visar ett meddelande kan du avbryta användare eller till och med irritera dem. Kontrollera att avbrottet är berättigat.
- Använd meddelanden för icke-kritiska händelser eller situationer som inte kräver omedelbara användaråtgärder. För kritiska händelser eller situationer som kräver omedelbara användaråtgärder använder du ett alternativt användargränssnitt (till exempel en modal dialogruta).
- Om du använder aviseringar gör du det till en bra användarupplevelse. Försök inte tvinga användarna att se dina meddelanden. Om användarna är så nedsänkta i sitt arbete att de inte ser dina meddelanden är din design bra.
Användningsmönster
Meddelanden har flera användningsmönster:
| Etikett | Värde |
|---|---|
|
Åtgärden lyckades Meddelar användarna när en asynkron, användarinitierad åtgärd slutförs. |
rätt:
I det här exemplet meddelar Windows Update användarna när deras dator har uppdaterats. felaktig: 
I det här exemplet meddelar Microsoft Outlook användare när en datafilkontroll är klar. Vad ska användarna göra nu? Och varför varna användare om lyckat slutförande? Visa när: När en asynkron uppgift har slutförts. Meddela användare om lyckade åtgärder endast om de sannolikt väntar på slutförande eller efter de senaste felen. Visa hur: Använd realtidsalternativet så att dessa meddelanden inte placeras i kö när användare kör ett helskärmsprogram eller inte aktivt använder sin dator. Visa hur ofta: En gång. Irritationsfaktor: Låg om framgång inte förväntas på grund av de senaste felen är framgången efter ett kritiskt eller mycket ovanligt fel så att användaren behöver ytterligare feedback, eller så väntar användaren på att slutföras; om inte. Alternativ: Ge feedback "på begäran" genom att visa en ikon (eller ändra en befintlig ikon) i meddelandefältet medan åtgärden utförs. ta bort ikonen (eller återställ föregående ikon) när åtgärden är klar. |
|
Åtgärdsfel Meddelar användare när en asynkron, användarinitierad åtgärd misslyckas. |
rätt:
I det här exemplet meddelar Windows-aktiveringen användare om fel. felaktig: 
I det här exemplet används Microsoft Outlook för att meddela användarna om ett fel som de sannolikt inte bryr sig om. Visa när: Vid fel av en asynkron uppgift. Visa hur ofta: En gång. Irritationsfaktor: Låg om användbar och relevant; hög om problemet omedelbart löser sig själv eller om användarna annars inte bryr sig. Alternativ: Använd en modal dialogruta om användarna måste åtgärda felet omedelbart. |
|
Icke-kritisk systemhändelse Meddelar användare av betydande systemhändelser eller status som kan ignoreras på ett säkert sätt, åtminstone tillfälligt. |
I det här exemplet varnar Windows användare om låg batteridrift, men det finns fortfarande gott om tid innan de vidtar åtgärder. Visa när: När en händelse inträffar och användaren är aktiv, eller om ett villkor fortsätter att finnas. Om det uppstår ett problem tar du bort meddelanden som visas direkt när problemet har lösts. Precis som med åtgärdsmeddelanden meddelar du användare om lyckade systemhändelser endast om användarna sannolikt väntar på händelsen eller efter de senaste felen. Visa hur ofta: En gång när händelsen först inträffar. Om detta beror på ett problem som användarna behöver lösa kan du redisplaya en gång om dagen. Irritationsfaktor: Låg, så länge meddelandet inte visas för ofta. Alternativ: Om användarna så småningom måste lösa ett problem använder du progressiv eskalering genom att i slutändan visa en modal dialogruta när lösningen blir obligatorisk. |
|
Valfri användaraktivitet Meddelar användare om asynkrona uppgifter som de bör utföra. Oavsett om det är valfritt eller obligatoriskt kan uppgiften skjutas upp på ett säkert sätt. |
I det här exemplet meddelar Windows Update användarna om en ny säkerhetsuppdatering. Visa när: När behovet av att utföra en uppgift fastställs och användaren är aktiv. Visa hur ofta: En gång om dagen i högst tre gånger. Irritationsfaktor: Låg, så länge användarna anser att uppgiften är viktig och meddelandet inte visas för ofta. Alternativ: Om användarna så småningom måste utföra uppgiften använder du progressiv eskalering genom att i slutändan visa en modal dialogruta när uppgiften blir obligatorisk. |
|
FYI Meddelar användare om potentiellt användbar och relevant information. Du kan meddela användarna om information av marginell relevans om det är valfritt och användarna anmäler sig. |
rätt:
I det här exemplet meddelas användarna när ett nytt e-postmeddelande tas emot. rätt: 
I det här exemplet meddelas användarna när kontakter är online och de väljer att ta emot den här valfria informationen. felaktig: 
I det här exemplet är informationen endast användbar om användaren redan har usb-portar med hög hastighet installerade. Annars är det inte troligt att användaren gör något annorlunda som resultat av det. Visa när: När utlösande händelse inträffar. Visa hur: Använd realtidsalternativet så att dessa meddelanden inte placeras i kö när användare kör ett helskärmsprogram eller inte aktivt använder sin dator. Visa hur ofta: En gång. Irritationsfaktor: Medel till hög, beroende på användarnas uppfattning om användbarhet och relevans. Rekommenderas inte om det finns en låg sannolikhet för användarintresse. Alternativ: Meddela inte användarna. |
|
Funktionsannonsering Meddelar användare av nyligen installerade, oanvända system- eller programfunktioner. |
Använd inte meddelanden för funktionsannonser! Använd i stället ett annat sätt att göra funktionen identifierbar, till exempel:
Använd inte meddelanden för funktionsannonser. |
Riktlinjer
Allmänt
- Välj meddelandemönstret baserat på dess användning. En beskrivning av varje användningsmönster finns i föregående tabell.
- Använd inga meddelanden under den första Windows-upplevelsen. För att förbättra sin första upplevelse undertrycker Windows 7 alla meddelanden som visas under de första timmarnas användning. Utforma programmet förutsatt att användarna inte ser några sådana meddelanden.
Vad du ska meddela
Meddela inte om lyckade åtgärder, förutom under följande omständigheter:
- Säkerhet. Användarna anser att säkerhetsåtgärder är av högsta vikt, så meddela användarna om lyckade säkerhetsåtgärder.
- Det senaste felet. Användarna tar inte lyckade åtgärder för givna om de misslyckades omedelbart tidigare, så meddela användarna om att åtgärden lyckades när åtgärden nyligen misslyckades.
- Förhindra olägenheter. Rapportera lyckade åtgärder när du gör det kan undvika att inconveniencing användare. Meddela därför användarna när en lyckad åtgärd utförs på ett oväntat sätt, till exempel när en åtgärd är lång eller slutförs tidigare eller senare än förväntat.
Under andra omständigheter kan du antingen inte ge någon feedback för framgång eller ge feedback "på begäran" Anta att användarna tar lyckade åtgärder för givna. Du kan ge feedback på begäran genom att visa en ikon (eller ändra en befintlig ikon) i meddelandefältet medan åtgärden utförs och ta bort ikonen (eller återställa föregående ikon) när åtgärden är klar.
För FYI-mönstret ger inte ett meddelande om användarna kan fortsätta att arbeta normalt eller sannolikt inte kommer att göra något annat som resultat av meddelandet.
felaktig:
I det här exemplet är informationen endast användbar om användaren redan har portarna installerade. Annars är det inte troligt att användaren gör något annorlunda som resultat av det.
Undantag: Du kan meddela användarna om information av tvivelaktig relevans om det är valfritt och användarna anmäler sig.
rätt:
I det här exemplet meddelas användarna när kontakter är online och de väljer att ta emot den här valfria informationen.
För icke-kritiska systemhändelser och FYI-mönster använda fullständiga meddelanden för en enskild händelse. Presentera inte flera partiella.
felaktig:
Dessa exempel visar bara fyra av de åtta meddelanden som visades av Windows XP när en användare ansluter ett specifikt USB-tangentbord, var och en visar stegvis mer information.
rätt:
I det här exemplet resulterar anslutning av ett USB-tangentbord i två fullständiga meddelanden.
När du ska meddela
- Visa ett meddelande baserat på dess designmönster:
| Mönster | När du ska meddela |
|---|---|
| Åtgärden lyckades |
När en asynkron uppgift har slutförts. Meddela användare om lyckade åtgärder endast om de sannolikt väntar på slutförande eller efter de senaste felen. |
| Åtgärdsfel |
Vid fel av en asynkron uppgift. |
| Icke-kritisk systemhändelse |
När en händelse inträffar och användaren är aktiv, eller om villkoret fortsätter att finnas. Om detta beror på ett problem tar du bort det meddelande som visas omedelbart när problemet har lösts. |
| Valfri användaruppgift |
När behovet av att utföra en uppgift bestäms och användaren är aktiv. |
| FYI |
När utlösande händelsen inträffar. |
- För mönstret för åtgärdsfel om problemet kan åtgärdas inom några sekunder fördröjer du felmeddelandet under en lämplig tid. Om problemet korrigerar sig självt rapporterar du ingenting. Meddela först när tillräckligt med tid har passerat att felet är märkbart. Om du rapporterar för tidigt kommer förmodligen inte användarna att märka att problemet har rapporterats, men de kommer att märka det onödiga meddelandet.
felaktig:
När omedelbart följt av:
I det här exemplet är meddelandet om ingen trådlös anslutning för tidigt i Windows Vista för tidigt eftersom det ofta omedelbart följs av ett meddelande om god anslutning.
- För åtgärdens framgångs- och FYI-mönster använda realtidsalternativet så att inaktuella meddelanden inte placeras i kö när användare kör ett helskärmsprogram eller inte aktivt använder sin dator.
- För det icke-kritiska systemhändelsemönstret skapar inte risken för meddelandestormar genom häpnadsväckande händelser som är knutna till välkända händelser, till exempel användarinloggning. Koppla i stället händelsen till en viss tidsperiod efter händelsen. Du kan till exempel påminna användarna om att registrera produkten fem minuter efter att användaren har loggat in.
Hur länge du ska meddela
I Windows Vista och senare visas meddelanden under en fast varaktighet på 9 sekunder.
Hur ofta du ska meddela
- Antalet gånger ett meddelande ska visas baseras på dess designmönster:
| Mönster | Hur ofta du ska meddela |
|---|---|
| Åtgärden lyckades |
En gång. |
| Åtgärdsfel |
En gång. |
| Icke-kritisk systemhändelse |
En gång när händelsen först inträffar. Om detta beror på ett problem som användarna behöver lösa kan du redisplaya en gång om dagen. |
| Valfri användaruppgift |
En gång om dagen i högst tre gånger. |
| FYI |
En gång. |
- För valfria användaruppgifter ska du inte försöka få användarna att skicka in genom att ständigt visa meddelanden. Om uppgiften krävs visar du en modal dialogruta omedelbart i stället för att använda meddelanden.
Eskalering av meddelanden
- Anta inte att användarna ser dina meddelanden. Användarna ser dem inte när:
- De är nedsänkta i sitt arbete.
- De är inte uppmärksamma.
- De är borta från sin dator.
- De kör ett helskärmsprogram.
- Administratören har inaktiverat alla meddelanden för datorn.
- Om användarna så småningom måste vidta någon form av åtgärd använder du progressiv eskalering för att visa ett alternativt användargränssnitt som användarna inte kan ignorera.
Interaktion
-
Gör meddelanden klickbara när:
- Användare bör utföra en åtgärd. Om du klickar på meddelandet bör ett fönster visas där användarna kan utföra åtgärden. Den här metoden rekommenderas för åtgärdsfelet och valfria designmönster för användaruppgifter.
- Användarna kanske vill se mer information. Om du klickar på meddelandet visas ett fönster där användarna kan visa ytterligare information.
- Visa alltid ett fönster när användare klickar för att utföra en åtgärd. Klicka inte direkt på utför en åtgärd.
- Om du klickar för att visa mer information bör du alltid visa mer information. Omformulera inte bara informationen som redan finns i meddelandet.
Ikoner
- Använd standardfelikonen för åtgärdsfelmönstret.
- Använd standardvarningsikonen för de icke-kritiska systemhändelsemönstren.
- För andra mönster använder du ikoner som visar objekt som relaterar till eller föreslår ämnet, till exempel en sköld för säkerhet eller ett batteri för ström.
- Använd ikoner baserat på ditt program eller ditt företags varumärke om dina målanvändare känner igen dem och det inte finns något bättre alternativ.
- För progressiv eskalering överväga att använda ikoner med ett progressivt mer empatiskt utseende när situationen blir mer brådskande.
- Använd inte standardinformationsikonen. Att meddelanden är information är självklart.
-
Överväg att använda stora ikoner (32 x 32 bildpunkter) när:
- Användarna kommer snabbt att förstå ikonen i stället för texten.
- De stora ikonerna förmedlar sin betydelse tydligare och effektivare än standardikonerna på 16 x 16 bildpunkter.
- Ikonen använder Aero-stil.
I det här exemplet kan användarna snabbt förstå meddelandets natur med en blick på den stora ikonen.
Meddelandeköer
Obs! Meddelanden placeras i kö när de inte kan visas omedelbart, till exempel när ett annat meddelande visas, användaren kör ett helskärmsprogram eller användaren inte aktivt använder datorn. Realtidsmeddelanden finns kvar i kön i bara 60 sekunder.
- Använd realtidsalternativet så att meddelandet inte köas länge för att åtgärden ska lyckas och FYI-mönstren. Dessa meddelanden har endast värde när de kan visas omedelbart.
- Ta bort köade meddelanden när de inte längre är relevanta.
- Utvecklare: Du kan göra detta genom att ange flaggan NIF_INFO i uFlags och ange szInfo till en tom sträng. Det skadar inte att göra detta om meddelandet inte längre finns i kön.
Systemintegrering
- Om programmet inte alltid har en ikon i meddelandefältet när det körs visa en ikon tillfälligt under den asynkrona aktivitet eller händelse som orsakade meddelandet.
SMS
Rubriktext
- Använd rubriktext som kort sammanfattar den viktigaste informationen som du behöver för att kommunicera med användare på ett tydligt, enkelt, koncist och specifikt språk. Användarna bör kunna förstå syftet med meddelandeinformationen snabbt och med minimal ansträngning.
- Använd textfragment eller fullständiga meningar utan att avsluta skiljetecken.
- Använd versal i meningsformat.
- Använd högst 48 tecken (på engelska) för att hantera lokalisering. Rubriken har en maximal längd på 63 tecken, men du måste tillåta 30 procents expansion när den engelskspråkiga texten översätts.
Brödtext
Använd brödtext som ger en beskrivning (utan att upprepa informationen i rubriken) och, om du vill, som ger specifik information om meddelandet och även låter användarna veta vilken åtgärd som är tillgänglig.
Använd fullständiga meningar med avslutande skiljetecken.
Använd versal i meningsformat.
Använd högst 200 tecken (på engelska) för att hantera lokalisering. Brödtexten har en maximal längd på 255 tecken, men du måste tillåta 30 procents expansion när den engelskspråkiga texten översätts.
Inkludera viktig information i brödtexten, till exempel specifika objektnamn. (Exempel: användarnamn, filnamn eller URL:er.) Användare bör inte behöva öppna ett annat fönster för att hitta sådan information.
Placera dubbla citattecken runt objektnamn.
-
Undantag: Använd inte citattecken när:
- Objektnamnet använder alltid rubrikformatets versaler, till exempel med användarnamn.
- Objektnamnet förskjuts med ett kolon (exempel: Skrivarnamn: Min skrivare).
- Objektnamnet kan enkelt fastställas utifrån kontexten.
-
Undantag: Använd inte citattecken när:
Om du måste trunkera objektnamn till en fast maximal storlek för lokalisering använder du en ellips för att indikera trunkering.
I det här exemplet trunkeras ett objektnamn med hjälp av en ellips.
Använd följande fraser om meddelandet kan användas:
Om användarna kan klicka på meddelandet för att utföra en åtgärd:
< kort beskrivning av viktig information>
<valfri information>
Klicka om du vill <göra något>.
I det här exemplet kan användare klicka för att utföra en åtgärd.
Om användarna kan klicka på meddelandet för att se mer information:
< kort beskrivning av viktig information>
<valfri information>
Klicka för mer information.
I det här exemplet kan användare klicka för mer information.
Säg inte att användaren "måste" utföra en åtgärd i ett meddelande. Meddelanden gäller för icke-kritisk information som användarna fritt kan ignorera. Om användarna verkligen måste utföra en åtgärd ska du inte använda meddelanden.
Om användarna ska utföra en åtgärd gör du vikten tydlig.
För åtgärdsfel och icke-kritiska systemhändelsemönster beskriva problem på vanligt språk.
felaktig:
I det här exemplet beskrivs problemet med överdrivet tekniskt men ospecificerat språk.
rätt:
I det här exemplet beskrivs problemet på vanligt språk.
Beskriv händelsen på ett sätt som är relevant för målanvändare. Ett meddelande är relevant om det finns en rimlig chans att användarna utför en uppgift eller ändrar sitt beteende till följd av meddelandet. Du kan ofta göra detta genom att beskriva meddelanden när det gäller användarmål i stället för tekniska problem.
Dokumentation
När du refererar till meddelanden:
- Använd den exakta rubriktexten, inklusive dess versaler.
- Referera till komponenten som ett meddelande, inte som en pratbubblan eller en avisering.
- Om du vill beskriva användarinteraktion använder du klicka.
- Formatera rubriktexten med fet text när det är möjligt. Annars placerar du endast rubriken inom citattecken om det behövs för att förhindra förvirring.
Exempel: När Viktiga uppdateringar är redo att installera meddelandet visas klickar du på meddelandet för att starta processen.
När du refererar till meddelandeområdet:
- Se meddelandefältet som meddelandeområde, inte systemfältet.