Foutberichten in Windows 7

Foutberichten in Windows 7 waarschuwen gebruikers van problemen die al zijn opgetreden. Waarschuwingsberichten waarschuwen gebruikers daarentegen voor voorwaarden die in de toekomst problemen kunnen veroorzaken. Foutberichten kunnen worden weergegeven met modale dialoogvensters, in-place berichten, meldingen of ballonnen.

niet wijzigen

Een typisch modaal foutbericht.

Effectieve foutberichten informeren gebruikers dat er een probleem is opgetreden, leg uit waarom het is gebeurd en bieden een oplossing zodat gebruikers het probleem kunnen oplossen. Gebruikers moeten een actie uitvoeren of hun gedrag wijzigen als gevolg van een foutbericht.

Goed geschreven, nuttige foutberichten zijn van cruciaal belang voor een kwaliteitsgebruikerservaring. Slecht geschreven foutberichten leiden tot een lage producttevredenheid en vormen een belangrijke oorzaak van vermijdbare technische ondersteuningskosten. Onnodige foutberichten verbreken de stroom van gebruikers.

Opmerking: Richtlijnen met betrekking tot dialoogvensters, waarschuwingsberichten, bevestigingen, standaardpictogrammen, meldingenen indeling worden in afzonderlijke artikelen weergegeven.

Is dit de juiste gebruikersinterface?

Houd rekening met deze vragen om te bepalen:

• Is de gebruikersinterface (UI) die een probleem presenteert dat al is opgetreden? Zo niet, dan is het bericht geen fout. Als de gebruiker wordt gewaarschuwd voor een voorwaarde die in de toekomst een probleem kan veroorzaken, gebruikt u een waarschuwingsbericht.
• Kan het probleem worden voorkomen zonder verwarring te veroorzaken? Zo ja, dan voorkomt u het probleem. Gebruik bijvoorbeeld besturingselementen die zijn beperkt tot geldige waarden in plaats van niet-gekoppelde besturingselementen te gebruiken waarvoor mogelijk foutberichten zijn vereist. Schakel besturingselementen ook uit wanneer erop wordt geklikt, resulteert in een fout, zolang het duidelijk is waarom het besturingselement is uitgeschakeld.
• Kan het probleem automatisch worden opgelost? Als dit het probleem is, kunt u het probleem afhandelen en het foutbericht onderdrukken.
• Zullen gebruikers waarschijnlijk een actie uitvoeren of hun gedrag wijzigen als gevolg van het bericht? Als dat niet het geval is, rechtvaardigt de voorwaarde niet dat de gebruiker wordt onderbroken, zodat het beter is om de fout te onderdrukken.
• Is het probleem relevant wanneer gebruikers actief andere programma's gebruiken? Als dit het probleem is, kunt u overwegen het probleem weer te geven met behulp van een systeemvakpictogram.
• Is het probleem niet gerelateerd aan de huidige gebruikersactiviteit, is er geen onmiddellijke actie van de gebruiker vereist en kunnen gebruikers het probleem niet negeren? Als dit het probleem is, gebruikt u in plaats daarvan een melding over mislukte acties.
• Heeft het probleem betrekking op de status van een achtergrondtaak in een primair venster? Zo ja, overweeg dan het probleem weer te geven met behulp van een statusbalken.
• Zijn de primaire doelgebruikers IT-professionals? Zo ja, dan kunt u overwegen een alternatief feedbackmechanisme te gebruiken, zoals logboekbestand vermeldingen of e-mailwaarschuwingen. IT-professionals geven de voorkeur aan logboekbestanden voor niet-kritieke informatie.

Ontwerpconcepten

De kenmerken van slechte foutberichten

Het zou geen verrassing moeten zijn dat er veel vervelende, onhelpige en slecht geschreven foutberichten zijn. En omdat foutberichten vaak worden weergegeven met modale dialoogvensters, onderbreken ze de huidige activiteit en vraag van de gebruiker om te worden bevestigd voordat de gebruiker kan doorgaan.

Een deel van het probleem is dat er zoveel manieren zijn om het verkeerd te doen. Bekijk deze voorbeelden uit de foutberichtenhal van schande:

onnodige foutberichten

Onjuist:

Dit voorbeeld van Windows XP is mogelijk het slechtste foutbericht ooit. Het geeft aan dat een programma niet kan worden gestart omdat Windows zelf bezig is met afsluiten. Er is niets wat de gebruiker hier aan kan doen of wil er zelfs niets aan doen (de gebruiker heeft ervoor gekozen Om Windows af te sluiten. En door dit foutbericht weer te geven, voorkomt Windows dat zichzelf wordt afgesloten.

Het probleem: Het foutbericht zelf is het probleem. Afgezien van het negeren van het foutbericht, is er niets voor gebruikers te doen.

Voorloopoorzaak: alle foutcases rapporteren, ongeacht de doelstellingen of het oogpunt van gebruikers.

Aanbevolen alternatief: Rapporteer geen fouten die gebruikers niet belangrijk maken.

foutberichten 'Geslaagd'

Onjuist:

Dit foutbericht is veroorzaakt door de gebruiker die ervoor heeft gekozen Windows niet onmiddellijk na het verwijderen van het programma opnieuw op te starten. Het verwijderen van het programma is gelukt vanuit het oogpunt van de gebruiker.

Het probleem: Er is geen fout in het oogpunt van de gebruiker. Afgezien van het negeren van het foutbericht, is er niets voor gebruikers te doen.

voorloopoorzaak: De taak is voltooid vanuit het oogpunt van de gebruiker, maar is mislukt vanuit het oogpunt van het verwijderingsprogramma.

Aanbevolen alternatief: Rapporteer geen fouten voor voorwaarden die gebruikers acceptabel achten.

volledig nutteloze foutberichten

Onjuist:

Gebruikers leren dat er een fout is opgetreden, maar hebben geen idee wat de fout was of wat u eraan moet doen. En nee, het is niet oké!

Het probleem: Het foutbericht geeft geen specifiek probleem en er is niets dat gebruikers eraan kunnen doen.

Voorloopoorzaak: Waarschijnlijk heeft het programma een slechte foutafhandeling.

Aanbevolen alternatief: Goede foutafhandeling ontwerpen in het programma.

onbegrijpelijke foutberichten

Onjuist:

In dit voorbeeld is de probleeminstructie duidelijk, maar de aanvullende uitleg is volkomen verwarrend.

Het probleem: De probleemverklaring of oplossing is onbegrijpelijk.

Voorloopoorzaak: het probleem vanuit het oogpunt van de code uitleggen in plaats van de gebruiker.

Aanbevolen alternatief: tekst voor foutberichten schrijven die uw doelgebruikers gemakkelijk kunnen begrijpen. Bied oplossingen die gebruikers daadwerkelijk kunnen uitvoeren. Ontwerp de foutberichtenervaring van uw programma niet over programmeurs die ter plekke foutberichten opstellen.

foutberichten die overcommunicaat

Onjuist:

In dit voorbeeld probeert het foutbericht elke stap voor probleemoplossing uit te leggen.

Het probleem: te veel informatie.

Voorloopoorzaak: Te veel details geven of een gecompliceerd probleemoplossingsproces binnen een foutbericht proberen uit te leggen.

Aanbevolen alternatief: Vermijd onnodige details. Vermijd ook probleemoplossers. Als een probleemoplosser nodig is, richt u zich op de meest waarschijnlijke oplossingen en legt u de rest uit door een koppeling te maken naar het desbetreffende onderwerp in Help.

Onnodig harde foutberichten

Onjuist:

Het is onvermogen van het programma om een object nauwelijks onherstelbaar te vinden. En ervan uitgaande dat het catastrofaal is, waarom is het antwoord in orde?

Het probleem: De toon van het programma is onnodig hard of dramatisch.

Voorloopoorzaak: Het probleem wordt veroorzaakt door een fout die catastrofaal lijkt vanuit het oogpunt van het programma.

Aanbevolen alternatief: Kies de taal zorgvuldig op basis van het oogpunt van de gebruiker.

foutberichten die gebruikers de schuld geven

Onjuist:

Waarom kunnen gebruikers zich als een crimineel voelen?

Het probleem: Het foutbericht wordt geformuleerd op een manier die de gebruiker beschuldigt van een fout.

Voorloopoorzaak: niet-gevoelige formulering die zich richt op het gedrag van de gebruiker in plaats van het probleem.

Aanbevolen alternatief: focus op het probleem, niet op de gebruikersactie die tot het probleem heeft geleid, waarbij de passieve stem indien nodig wordt gebruikt.

domme foutberichten

Onjuist:

In dit voorbeeld is de probleeminstructie vrij ironisch en worden er geen oplossingen geboden.

Het probleem: foutberichten die domme of niet-sequitors zijn.

Voorloopoorzaak: Foutberichten maken zonder aandacht te besteden aan de context.

Aanbevolen alternatief: Laat uw foutberichten gemaakt en beoordeeld door een schrijver. Houd rekening met de context en de status van de gebruiker bij het controleren van de fouten.

foutberichten Programmeur

Onjuist:

In dit voorbeeld geeft het foutbericht aan dat het programma een fout bevat. Dit foutbericht heeft alleen betekenis voor de programmeur.

Het probleem: Berichten die zijn bedoeld om de ontwikkelaars van het programma te helpen bij het vinden van fouten, blijven in de releaseversie van het programma staan. Deze foutberichten hebben geen betekenis of waarde voor gebruikers.

Voorloopoorzaak: Programmeurs die de normale gebruikersinterface gebruiken om berichten naar zichzelf te verzenden.

Aanbevolen alternatief: ontwikkelaars moeten dergelijke berichten voorwaardelijk compileren, zodat ze automatisch worden verwijderd uit de releaseversie van een product. Verspil geen tijd om fouten zoals deze begrijpelijk te maken voor gebruikers, omdat hun enige publiek de programmeurs is.

Slecht gepresenteerde foutberichten

Onjuist:

In dit voorbeeld zijn veel veelvoorkomende presentatiefouten opgetreden.

Het probleem: Alle details in de presentatie van het foutbericht verkeerd krijgen.

Voorloopoorzaak: de richtlijnen voor foutberichten niet kennen en toepassen. Schrijvers en editors niet gebruiken om de foutberichten te maken en te bekijken.

De aard van foutafhandeling is zodanig dat veel van deze fouten zeer eenvoudig te maken zijn. Het is storend om te beseffen dat de meeste foutberichten kunnen worden genomineerd voor de Hall of Shame.

De kenmerken van goede foutberichten

In tegenstelling tot de vorige slechte voorbeelden hebben goede foutberichten:

• Een probleem. Geeft aan dat er een probleem is opgetreden.
• Een oorzaak. Hier wordt uitgelegd waarom het probleem is opgetreden.
• Een oplossing. Biedt een oplossing zodat gebruikers het probleem kunnen oplossen.

Daarnaast worden goede foutberichten weergegeven op een manier die:

• Relevant. Het bericht geeft een probleem aan waar gebruikers om geven.
• Beroep. Gebruikers moeten een actie uitvoeren of hun gedrag wijzigen als gevolg van het bericht.
• Gebruiker gecentreerd. In het bericht wordt het probleem beschreven in termen van acties of doelen van doelgebruikers, niet in termen van waar de code niet tevreden mee is.
• Kort. Het bericht is zo kort mogelijk, maar niet korter.
• Duidelijk. Het bericht maakt gebruik van gewone taal, zodat de doelgebruikers het probleem en de oplossing gemakkelijk kunnen begrijpen.
• Specifiek. In het bericht wordt het probleem beschreven met behulp van een specifieke taal, waarbij specifieke namen, locaties en waarden van de betrokken objecten worden opgegeven.
• Hoffelijk. Gebruikers mogen niet de schuld krijgen of zich dom voelen.
• Zeldzaam. Niet vaak weergegeven. Vaak weergegeven foutberichten zijn een teken van slecht ontwerp.

Door uw foutafhandelingservaring te ontwerpen om deze kenmerken te hebben, kunt u de foutberichten van uw programma buiten de hall of shame van foutberichten houden.

onnodige foutberichten voorkomen

Vaak is het beste foutbericht geen foutbericht. Veel fouten kunnen worden vermeden door een beter ontwerp en er zijn vaak betere alternatieven voor foutberichten. Het is meestal beter om een fout te voorkomen dan een fout te melden.

De meest voor de hand liggende foutberichten die moeten worden vermeden, zijn de foutberichten die niet kunnen worden uitgevoerd. Als gebruikers het bericht waarschijnlijk negeren zonder iets te doen of te wijzigen, laat u het foutbericht weg.

Sommige foutberichten kunnen worden geëlimineerd omdat ze geen problemen zijn vanuit het oogpunt van de gebruiker. Stel dat de gebruiker probeert een bestand te verwijderen dat al bezig is met verwijderen. Hoewel dit mogelijk een onverwacht geval is vanuit het oogpunt van de code, beschouwen gebruikers deze fout niet omdat hun gewenste resultaat wordt bereikt.

Onjuist:

Dit foutbericht moet worden geëlimineerd omdat de actie is geslaagd vanuit het oogpunt van de gebruiker.

Stel dat de gebruiker een taak expliciet annuleert. Voor het oogpunt van de gebruiker is de volgende voorwaarde geen fout.

Onjuist:

Dit foutbericht moet ook worden geëlimineerd omdat de actie is geslaagd vanuit het oogpunt van de gebruiker.

Soms kunnen foutberichten worden geëlimineerd door zich te concentreren op de doelstellingen van gebruikers in plaats van op de technologie. Bedenk daarbij wat een fout echt is. Is het probleem met de doelen van de gebruiker of met de mogelijkheid van uw programma om aan deze doelen te voldoen? Als de actie van de gebruiker zinvol is in de echte wereld, moet het ook zinvol zijn in software.

Stel dat een gebruiker in een e-commerceprogramma een product probeert te vinden met behulp van zoeken, maar de letterlijke zoekquery geen overeenkomsten heeft en het gewenste product niet op voorraad is. Technisch gezien is dit een fout, maar in plaats van een foutbericht te geven, kan het programma het volgende doen:

• Ga door met het zoeken naar producten die het meest overeenkomen met de query.
• Als de zoekopdracht duidelijke fouten bevat, wordt automatisch een gecorrigeerde query aanbevolen.
• Veelvoorkomende problemen zoals spelfouten, alternatieve spelling en niet-overeenkomende pluralisatie en werkwoorden automatisch afhandelen.
• Geef aan wanneer het product op voorraad is.

Zolang het verzoek van de gebruiker redelijk is, moet een goed ontworpen e-commerceprogramma redelijke resultaten opleveren, niet fouten.

Een andere geweldige manier om foutberichten te voorkomen, is door problemen in de eerste plaats te voorkomen. U kunt fouten voorkomen door:

• Met beperkte besturingselementen. Besturingselementen gebruiken die zijn beperkt tot geldige waarden. Besturingselementen zoals lijsten, schuifregelaars, selectievakjes, keuzerondjes en datum- en tijdkiezers zijn beperkt tot geldige waarden, terwijl tekstvakken vaak niet zijn en mogelijk foutberichten vereisen. U kunt echter tekstvakken beperken om alleen bepaalde tekens te accepteren en een maximum aantal tekens te accepteren.
• Beperkte interacties gebruiken. Voor slepenbewerkingen kunnen gebruikers alleen op geldige doelen neerzetten.
• Uitgeschakelde besturingselementen en menu-items gebruiken. Schakel besturingselementen en menu-items uit wanneer gebruikers eenvoudig kunnen afleiden waarom het besturingselement of menu-item is uitgeschakeld.
• Goede standaardwaarden bieden. Gebruikers maken minder waarschijnlijk invoerfouten als ze de standaardwaarden kunnen accepteren. Zelfs als gebruikers besluiten de waarde te wijzigen, laat de standaardwaarde gebruikers weten wat de verwachte invoerindeling is.
• Het maken van dingen werkt gewoon. Gebruikers maken minder waarschijnlijk fouten als de taken onnodig zijn of automatisch voor hen worden uitgevoerd. Of als gebruikers kleine fouten maken, maar hun bedoeling duidelijk is, wordt het probleem automatisch opgelost. U kunt bijvoorbeeld automatisch kleine opmaakproblemen oplossen.

De benodigde foutberichten

Soms moet u echt een foutbericht opgeven. Gebruikers maken fouten, netwerken en apparaten werken niet meer, objecten kunnen niet worden gevonden of gewijzigd, taken kunnen niet worden voltooid en programma's hebben fouten. In het ideale geval zouden deze problemen minder vaak optreden, kunnen we onze software ontwerpen om veel soorten gebruikersfouten te voorkomen, maar het is niet realistisch om al deze problemen te voorkomen. En wanneer een van deze problemen zich voordoet, krijgt een nuttig foutbericht gebruikers snel weer aan hun voeten.

Een veelvoorkomende overtuiging is dat foutberichten de slechtste gebruikerservaring zijn en moeten worden vermeden tegen alle kosten, maar het is nauwkeuriger om te zeggen dat verwarring van gebruikers de slechtste ervaring is en moet worden vermeden ten koste van alle kosten. Soms zijn deze kosten een nuttig foutbericht.

Overweeg uitgeschakelde besturingselementen. Meestal is het duidelijk waarom een besturingselement is uitgeschakeld, dus het uitschakelen van het besturingselement is een uitstekende manier om een foutbericht te voorkomen. Wat gebeurt er echter als de reden waarom een besturingselement is uitgeschakeld, niet duidelijk is? De gebruiker kan niet doorgaan en er is geen feedback om het probleem te bepalen. De gebruiker is nu vastgelopen en moet het probleem afleiden of technische ondersteuning krijgen. In dergelijke gevallen is het veel beter om het besturingselement ingeschakeld te laten en in plaats daarvan een nuttig foutbericht te geven.

Onjuist:

Waarom is de knop Volgende hier uitgeschakeld? Het is beter om deze ingeschakeld te laten en verwarring van gebruikers te voorkomen door een nuttig foutbericht te geven.

Als u niet zeker weet of u een foutbericht moet geven, begint u met het opstellen van het foutbericht dat u mogelijk geeft. Als gebruikers waarschijnlijk een actie uitvoeren of hun gedrag als gevolg hiervan wijzigen, geeft u het foutbericht op. Als gebruikers daarentegen waarschijnlijk het bericht sluiten zonder iets te doen of te wijzigen, laat u het foutbericht weg.

Ontwerpen voor goede foutafhandeling

Hoewel het maken van goede foutberichttekst lastig kan zijn, is het soms onmogelijk zonder goede ondersteuning voor foutafhandeling van het programma. Houd rekening met dit foutbericht:

Onjuist:

De kans is groot dat het probleem echt onbekend is omdat de ondersteuning voor foutafhandeling van het programma ontbreekt.

Hoewel het mogelijk is dat dit een zeer slecht geschreven foutbericht is, komt het waarschijnlijker overeen met het gebrek aan goede foutafhandeling door de onderliggende code, er is geen specifieke informatie bekend over het probleem.

Als u specifieke, bruikbare, gebruikersgerichte foutberichten wilt maken, moet de code voor foutafhandeling van uw programma specifieke, algemene foutinformatie bevatten:

• Aan elk probleem moet een unieke foutcode zijn toegewezen.
• Als een probleem verschillende oorzaken heeft, moet het programma waar mogelijk de specifieke oorzaak bepalen.
• Als het probleem parameters bevat, moeten de parameters worden onderhouden.
• Problemen op laag niveau moeten op een voldoende hoog niveau worden afgehandeld, zodat het foutbericht kan worden gepresenteerd vanuit het oogpunt van de gebruiker.

Goede foutberichten zijn niet alleen een probleem met de gebruikersinterface, ze zijn een probleem met softwareontwerp. Een goede foutberichtervaring is niet iets wat later kan worden gehackt.

probleemoplossing (en hoe u dit kunt voorkomen)

Problemen oplossen wanneer een probleem met verschillende oorzaken wordt gerapporteerd met één foutbericht.

Onjuist:

juist:

Problemen oplossen wanneer er meerdere problemen worden gerapporteerd met één foutbericht.

In het volgende voorbeeld kan een item niet worden verplaatst omdat het al is verplaatst of verwijderd of de toegang is geweigerd. Als het programma de oorzaak gemakkelijk kan bepalen, waarom moet de gebruiker de specifieke oorzaak bepalen?

Onjuist:

Wat is het? Nu moet de gebruiker problemen oplossen.

Het programma kan bepalen of de toegang is geweigerd, dus dit probleem moet worden gemeld met een specifiek foutbericht.

juist:

Met een specifieke oorzaak is er geen probleemoplossing vereist.

Gebruik berichten met meerdere oorzaken alleen als de specifieke oorzaak niet kan worden bepaald. In dit voorbeeld kan het voor het programma moeilijk zijn om te bepalen of het item is verplaatst of verwijderd, dus een enkel foutbericht met meerdere oorzaken kan hier worden gebruikt. Het is echter onwaarschijnlijk dat gebruikers het belangrijk vinden als ze bijvoorbeeld een verwijderd bestand niet konden verplaatsen. Voor deze oorzaken is het foutbericht niet eens nodig.

onbekende fouten verwerken

In sommige gevallen weet u het probleem, de oorzaak of de oplossing echt niet. Als het onverstandig zou zijn om de fout te onderdrukken, is het beter om vooraf te zijn over het gebrek aan informatie dan problemen, oorzaken of oplossingen te presenteren die mogelijk niet juist zijn.

Als uw programma bijvoorbeeld een niet-verwerkte uitzondering heeft, is het volgende foutbericht geschikt:

Als u een onbekende fout niet kunt onderdrukken, is het beter om vooraf te zijn over het gebrek aan informatie.

Geef daarentegen specifieke, bruikbare informatie als deze waarschijnlijk de meeste tijd nuttig is.

Dit foutbericht is geschikt voor een onbekende fout als de netwerkverbinding meestal het probleem is.

het juiste berichttype bepalen

Sommige problemen kunnen worden weergegeven als een fout, waarschuwing of informatie, afhankelijk van de nadruk en formulering. Stel dat een webpagina geen niet-ondertekend ActiveX-besturingselement kan laden op basis van de huidige Configuratie van Windows Internet Explorer:

• Fout. "Deze pagina kan geen niet-ondertekend ActiveX-besturingselement laden." (Zinnen als een bestaand probleem.)
• Waarschuwing. "Deze pagina gedraagt zich mogelijk niet zoals verwacht omdat Windows Internet Explorer niet is geconfigureerd voor het laden van niet-ondertekende ActiveX-besturingselementen." of "Toestaan dat deze pagina een niet-ondertekend ActiveX-besturingselement installeert? Als u dit doet vanuit niet-vertrouwde bronnen, kan dit schadelijk zijn voor uw computer." (Beide zinnen als voorwaarden die toekomstige problemen kunnen veroorzaken.)
• Informatie. 'U hebt Windows Internet Explorer geconfigureerd om niet-ondertekende ActiveX-besturingselementen te blokkeren.' (Zinsdeel als een verklaring van feit.)

Als u het juiste berichttype wilt bepalen, moet u zich richten op het belangrijkste aspect van het probleem waarop gebruikers moeten weten of actie moeten ondernemen. Als een probleem de gebruiker blokkeert om door te gaan, moet u het als een fout presenteren. als de gebruiker verder kan gaan, presenteert u deze als waarschuwing. Maak de hoofdinstructie of andere bijbehorende tekst op basis van die focus en kies vervolgens een pictogram (standaard of anderszins) dat overeenkomt met de tekst. De hoofdinstructietekst en pictogrammen moeten altijd overeenkomen.

presentatie van foutberichten

De meeste foutberichten in Windows-programma's worden weergegeven met modale dialoogvensters (zoals de meeste voorbeelden in dit artikel), maar er zijn andere opties:

• In-place
• Ballonnen
• Meldingen
• Pictogrammen voor systeemvak
• Statusbalken
• Logboekbestanden (voor fouten die zijn gericht op IT-professionals)

Het plaatsen van foutberichten in modale dialoogvensters heeft het voordeel dat de gebruiker onmiddellijk aandacht en bevestiging vereist. Dit is echter ook het belangrijkste nadeel als die aandacht niet nodig is.

Moet u gebruikers echt onderbreken zodat ze op de knop Sluiten kunnen klikken? Zo niet, overweeg dan alternatieven voor het gebruik van een modaal dialoogvenster.

Modale dialoogvensters zijn een uitstekende keuze wanneer de gebruiker het probleem onmiddellijk moet bevestigen voordat hij verdergaat, maar vaak een slechte keuze anders. Over het algemeen moet u liever de lichtste gewichtspresentatie gebruiken die het werk goed doet.

Vermijd overcommunicatie

Over het algemeen gebruikers niet lezen, scannen ze. Hoe meer tekst er is, hoe moeilijker de tekst is om te scannen en hoe waarschijnlijker gebruikers de tekst helemaal niet lezen. Als gevolg hiervan is het belangrijk om de tekst terug te brengen naar de essentiële elementen, en om zo nodig progressieve openbaarmaking en Help-koppelingen te gebruiken om aanvullende informatie te verstrekken.

Er zijn veel extreme voorbeelden, maar laten we eens kijken naar een andere typische. Het volgende voorbeeld heeft de meeste kenmerken van een goed foutbericht, maar de tekst is niet beknopt en vereist motivatie om te lezen.

Onjuist:

Dit voorbeeld is een goed foutbericht, maar overcommunicates.

Wat zegt deze tekst eigenlijk? Zoiets als dit:

juist:

Dit foutbericht heeft in feite dezelfde informatie, maar is veel beknopter.

Met behulp van Help om de details op te geven, heeft dit foutbericht een omgekeerde piramidestijl van de presentatie.

Zie User Interface Textvoor meer richtlijnen en voorbeelden van overcommunicatie.

Als u slechts acht dingen

1. Ontwerp uw programma voor foutafhandeling.
2. Geef geen onnodige foutberichten.
3. Vermijd verwarring van gebruikers door noodzakelijke foutberichten te geven.
4. Zorg ervoor dat het foutbericht een probleem, oorzaak en oplossing geeft.
5. Zorg ervoor dat het foutbericht relevant, uitvoerbaar, kort, duidelijk, specifiek, beleefd en zeldzaam is.
6. Ontwerp foutberichten vanuit het oogpunt van de gebruiker, niet het standpunt van het programma.
7. Vermijd dat de gebruiker bij het oplossen van problemen een ander foutbericht gebruikt voor elke detecteerbare oorzaak.
8. Gebruik de lichtste presentatiemethode die de taak goed doet.

gebruikspatronen

Foutberichten hebben verschillende gebruikspatronen:

Etiket	Waarde
Systeemproblemen Het besturingssysteem, het hardwareapparaat, het netwerk of het programma is mislukt of heeft niet de status die nodig is om een taak uit te voeren.	Veel systeemproblemen kunnen door de gebruiker worden opgelost: Apparaatproblemen kunnen worden opgelost door het apparaat in te schakelen, het apparaat opnieuw te verbinden en media in te voegen. Netwerkproblemen kunnen worden opgelost door de fysieke netwerkverbinding te controleren en netwerkdiagnose uit te voeren ente herstellen. Programmaproblemen kunnen worden opgelost door programmaopties te wijzigen of het programma opnieuw te starten. In dit voorbeeld kan het programma geen camera vinden om een gebruikerstaak uit te voeren. In dit voorbeeld moet een functie die is vereist om een taak uit te voeren, worden ingeschakeld.
bestandsproblemen Een bestand of map die is vereist voor een taak die door de gebruiker is geïnitieerd, is niet gevonden, is al in gebruik of heeft niet de verwachte indeling.	In dit voorbeeld kan het bestand of de map niet worden verwijderd omdat het niet is gevonden. In dit voorbeeld biedt het programma geen ondersteuning voor de opgegeven bestandsindeling.
beveiligingsproblemen De gebruiker heeft geen toegang tot een resource of voldoende bevoegdheden om een taak uit te voeren die door de gebruiker is geïnitieerd.	In dit voorbeeld is de gebruiker niet gemachtigd om toegang te krijgen tot een resource. In dit voorbeeld heeft de gebruiker niet de bevoegdheid om een taak uit te voeren.
taakproblemen Er is een specifiek probleem bij het uitvoeren van een taak die door de gebruiker is geïnitieerd (met uitzondering van een systeem, bestand niet gevonden, bestandsindeling of beveiligingsprobleem).	In dit voorbeeld kunnen de klembordgegevens niet in Paint worden geplakt. In dit voorbeeld kan de gebruiker geen software-upgrade installeren.
gebruikersinvoerproblemen De gebruiker heeft een waarde ingevoerd die onjuist is of inconsistent is met andere gebruikersinvoer.	In dit voorbeeld heeft de gebruiker een onjuiste tijdwaarde ingevoerd. In dit voorbeeld heeft gebruikersinvoer niet de juiste indeling.

Richtsnoeren

Presentatie

• Taakdialoogvensters gebruiken wanneer dat nodig is om een consistent uiterlijk en een consistente indeling te bereiken. Voor taakdialoogvensters is Windows Vista of hoger vereist, zodat deze niet geschikt zijn voor eerdere versies van Windows. Als u een berichtvak moet gebruiken, scheidt u de hoofdinstructie van de aanvullende instructie met twee regeleinden.

Gebruikersinvoerfouten

• indien mogelijk, gebruikersinvoerfouten voorkomen of verminderen door:
  • Besturingselementen gebruiken die zijn beperkt tot geldige waarden.
  • Als u besturingselementen en menu-items uitschakelt wanneer erop wordt geklikt, kan dit resulteren in een fout, zolang het duidelijk is waarom het besturingselement of menu-item is uitgeschakeld.
  • Goede standaardwaarden bieden.

Onjuist:

In dit voorbeeld wordt een niet-gebonden tekstvak gebruikt voor beperkte invoer. Gebruik in plaats daarvan een schuifregelaar.

• Gebruik modusloze foutafhandeling (in-place fouten of ballonnen) voor contextuele problemen met gebruikersinvoer.
• Ballonnen gebruiken voor niet-kritieke problemen met invoer van gebruikers met één punt die zijn gedetecteerd in een tekstvak of direct nadat een tekstvak de focus verliest.Ballonnen geen beschikbare schermruimte of de dynamische indeling vereisen die nodig is om in-place berichten weer te geven. Slechts één ballon tegelijk weergeven. Omdat het probleem niet kritiek is, is er geen foutpictogram nodig. Ballonnen gaan weg wanneer erop wordt geklikt, wanneer het probleem is opgelost of na een time-out.

In dit voorbeeld geeft een ballon een invoerprobleem aan terwijl het besturingselement zich nog in het besturingselement blijft.

• Gebruik in-place fouten voor vertraagde foutdetectie, meestal fouten gevonden door op een doorvoerknop te klikken. (Gebruik geen in-place fouten voor instellingen die onmiddellijk worden doorgevoerd.) Er kunnen meerdere in-place fouten tegelijk optreden. Gebruik normale tekst en een foutpictogram van 16 x 16 pixels, waardoor deze waar mogelijk direct naast het probleem worden geplaatst. In-place fouten gaan niet weg, tenzij de gebruiker doorvoert en er geen andere fouten worden gevonden.

In dit voorbeeld wordt een in-place fout gebruikt voor een fout die is gevonden door op de doorvoerknop te klikken.

• Modale foutafhandeling (taakdialoogvensters of berichtvakken) gebruiken voor alle andere problemen, inclusief fouten die betrekking hebben op meerdere besturingselementen of niet-contextuele of niet-invoerfouten zijn gevonden door op een doorvoerknop te klikken.
• Wanneer een probleem met gebruikersinvoer wordt gerapporteerd, stelt u de invoerfocus in op het eerste besturingselement met de onjuiste gegevens. Schuif indien nodig door het besturingselement in beeld. Als het besturingselement een tekstvak is, selecteert u de hele inhoud. Het moet altijd duidelijk zijn waar het foutbericht naar verwijst.
• Wis onjuiste invoer niet. Laat dit in plaats daarvan staan zodat de gebruiker het probleem kan zien en corrigeren zonder opnieuw te beginnen.
  • Uitzondering: onjuiste wachtwoord- en pincodetekstvakken wissen omdat gebruikers gemaskeerde invoer niet effectief kunnen corrigeren.

Probleemoplossing

• Vermijd het oplossen van problemen. Vertrouw niet op één foutbericht om een probleem met verschillende detecteerbare oorzaken te melden.
• Gebruik een ander foutbericht (meestal een andere aanvullende instructie) voor elke detecteerbare oorzaak. Als een bestand bijvoorbeeld om verschillende redenen niet kan worden geopend, geeft u om elke reden een afzonderlijke aanvullende instructie op.
• Gebruik een bericht met meerdere oorzaken alleen als de specifieke oorzaak niet kan worden bepaald. In dit geval kunt u de oplossingen presenteren in de volgorde van de waarschijnlijkheid van het oplossen van het probleem. Hierdoor kunnen gebruikers het probleem efficiënter oplossen.

Pictogrammen

• Dialoogvensters voor modale foutberichten hebben geen titelbalkpictogrammen. Titelbalkpictogrammen worden gebruikt als visueel onderscheid tussen primaire vensters en secundaire vensters.

• Gebruik een foutpictogram. Uitzonderingen:

  • Als de fout een probleem met gebruikersinvoer is dat wordt weergegeven met behulp van een modaal dialoogvenster of een ballon, gebruikt u geen pictogram. Dit is in strijd met de stimulerende toon van Windows. In-place foutberichten moeten echter een klein foutpictogram (16x16 pixel) gebruiken om ze duidelijk te identificeren als foutberichten.

    

    

    In deze voorbeelden hebben gebruikersinvoerproblemen geen foutpictogrammen nodig.

    

    In dit voorbeeld heeft een in-place foutbericht een klein foutpictogram nodig om het duidelijk te identificeren als een foutbericht.

• Als het probleem betrekking heeft op een functie met een pictogram (en niet een probleem met gebruikersinvoer), kunt u het functiepictogram gebruiken met een foutoverlay. Als u dit doet, gebruikt u ook de functienaam als onderwerp van de fout.

  

  In dit voorbeeld heeft het functiepictogram een foutoverlay en is de functie het onderwerp van de fout.

• Gebruik geen waarschuwingspictogrammen voor fouten. Dit wordt vaak gedaan om de presentatie minder ernstig te laten voelen. Fouten zijn geen waarschuwingen.

  Onjuist:

  

  In dit voorbeeld wordt een waarschuwingspictogram onjuist gebruikt om de fout minder ernstig te maken.

Zie Standaardpictogrammenvoor meer richtlijnen en voorbeelden.

Progressieve openbaarmaking

• Gebruik een knop Details weergeven/verbergen om geavanceerde of gedetailleerde informatie in een foutbericht te verbergen. Dit vereenvoudigt het foutbericht voor normaal gebruik. Verberg de benodigde gegevens niet, omdat gebruikers deze mogelijk niet vinden.

In dit voorbeeld helpt de knop progressieve openbaarmaking gebruikers in te zoomen op meer details als ze dat willen, of om de gebruikersinterface te vereenvoudigen als ze dat niet doen.

• Gebruik geen details weergeven/verbergen, tenzij er echt meer details zijn. Pas niet alleen de bestaande informatie in een uitgebreidere indeling aan.
• Gebruik geen details weergeven/verbergen om Help-informatie weer te geven. Gebruik in plaats daarvan Help-koppelingen.

Zie Progressive Disclosure Controlsvoor labelrichtlijnen.

Dit bericht niet meer weergeven

• Als een foutbericht deze optie nodig heeft, moet u de fout en de frequentie ervan opnieuw bekijken. Als het alle kenmerken van een goede fout (relevant, uitvoerbaar en onregelmatig) heeft, zou het niet zinvol moeten zijn voor gebruikers om deze te onderdrukken.

Zie dialoogvenstersvoor meer richtlijnen.

Standaardwaarden

• Selecteer de veiligste, minst destructieve of veiligste reactie om de standaardwaarde te zijn. Als veiligheid geen factor is, selecteert u de meest waarschijnlijke of handige opdracht.

Help

• Ontwerp foutberichten om te voorkomen dat u hulp nodig hebt. Normaal gesproken hoeven gebruikers geen externe tekst te lezen om het probleem te begrijpen en op te lossen, tenzij de oplossing verschillende stappen vereist.
• Zorg ervoor dat de Help-inhoud relevant en nuttig is. Het mag geen uitgebreide aanpassing van het foutbericht zijn, maar moet nuttige informatie bevatten die buiten het bereik van het foutbericht valt, zoals manieren om het probleem in de toekomst te voorkomen. Geef geen Help-koppeling op omdat u dat wel kunt.
• Gebruik specifieke, beknopte, relevante Help-koppelingen voor toegang tot Help-inhoud. Gebruik hiervoor geen opdrachtknoppen of progressieve openbaarmaking.
• Voor foutberichten die u niet specifiek en uitvoerbaar kunt maken, kunt u overwegen om koppelingen naar online-Help-inhoud op te geven. Hierdoor kunt u gebruikers aanvullende informatie geven die u kunt bijwerken nadat het programma is uitgebracht.

Zie Help-voor meer richtlijnen.

Foutcodes

• Overweeg ook foutcodes op te geven voor foutberichten die u niet specifiek en uitvoerbaar kunt maken of dat ze baat hebben bij Help. Gebruikers gebruiken deze foutcodes vaak om op internet te zoeken naar aanvullende informatie.
• Geef altijd een tekstbeschrijving op van het probleem en de oplossing. Niet alleen afhankelijk van de foutcode voor dit doel.

Onjuist:

In dit voorbeeld wordt een foutcode gebruikt als vervanging voor een oplossingstekst.

• Wijs een unieke foutcode toe voor elke andere oorzaak. Als u dit doet, voorkomt u het oplossen van problemen.
• Kies foutcodes die gemakkelijk kunnen worden doorzocht op internet. Als u 32-bits codes gebruikt, gebruikt u een hexadecimale weergave met voorlooptekens '0x' en hoofdletters.

juist:

1234

0xC0001234

Onjuist:

-1

-67113524

• Gebruik details weergeven/verbergen om foutcodes weer te geven. Woordgroep als foutcode: <error code>.

niet geïnitialiseerd

In dit voorbeeld wordt een foutcode gebruikt om een foutbericht aan te vullen dat kan profiteren van verdere informatie.

Geluid

• Voeg geen foutberichten toe met een geluidseffect of pieptoon. Dit is lastig en onnodig.
  • Uitzondering: Het geluidseffect Kritiek stoppen afspelen als het probleem essentieel is voor de werking van de computer en de gebruiker moet onmiddellijk actie ondernemen om ernstige gevolgen te voorkomen.

Sms

Algemeen

• Verwijder overbodige tekst. Zoek ernaar in titels, hoofdinstructies, aanvullende instructies, opdrachtkoppelingen en doorvoerknoppen. Over het algemeen laat u volledige tekst in instructies en interactieve besturingselementen staan en verwijdert u eventuele redundantie van de andere plaatsen.
• Gebruik door de gebruiker gecentreerde uitleg. Beschrijf het probleem in termen van gebruikersacties of doelen, niet in termen van wat de software ongelukkig is. Gebruik de taal die de doelgebruikers begrijpen en gebruiken. Vermijd technische jargon.

Onjuist:

juist:

In deze voorbeelden spreekt de juiste versie de taal van de gebruiker, terwijl de onjuiste versie te technisch is.

• Gebruik de volgende woorden niet:
  • Fout, fout (gebruik in plaats daarvan probleem)
  • Niet gelukt (gebruik kan niet in plaats daarvan)
  • Ongeldig, ongeldig, ongeldig (gebruik onjuist in plaats daarvan)
  • Afbreken, doden, beëindigen (gebruik in plaats daarvan stoppen)
  • Onherstelbare, fatale (gebruik in plaats daarvan ernstig)

Deze voorwaarden zijn onnodig en in strijd met de stimulerende toon van Windows. Wanneer correctgebruikt, communiceert het foutpictogram voldoende dat er een probleem is.

Onjuist:

juist:

In het onjuiste voorbeeld zijn de termen 'catastrofaal' en 'fout' overbodig.

• Gebruik geen formulering die de gebruiker de schuld geeft of gebruikersfout impliceert. Vermijd het gebruik van u en uw in de formulering. Hoewel de actieve stem over het algemeen de voorkeur heeft, gebruikt u de passieve stem wanneer de gebruiker het onderwerp is en krijgt u mogelijk de schuld van de fout als de actieve stem is gebruikt.

Onjuist:

juist:

Het onjuiste voorbeeld geeft de gebruiker de schuld door gebruik te maken van de actieve stem.

• Wees specifiek. Vermijd vage formulering, zoals syntaxisfout en illegale bewerking. Geef specifieke namen, locaties en waarden op van de betrokken objecten.

Onjuist:

Het bestand is niet gevonden.

Schijf is vol.

Waarde buiten het bereik.

Het teken is ongeldig.

Het apparaat is niet beschikbaar.

Deze problemen zijn veel gemakkelijker op te lossen met specifieke namen, locaties en waarden.

• Geef mogelijk geen onwaarschijnlijke problemen, oorzaken of oplossingen in een poging om specifiek te zijn. Geef geen probleem, oorzaak of oplossing op, tenzij dit waarschijnlijk juist is. Het is bijvoorbeeld beter om te zeggen dat er een onbekende fout is opgetreden dan iets dat waarschijnlijk onnauwkeurig is.
• Vermijd het woord 'alstublieft', behalve in situaties waarin de gebruiker wordt gevraagd iets onhandigs te doen (zoals wachten) of de software de schuld is van de situatie.

juist:

Een ogenblik geduld. Windows kopieert de bestanden naar uw computer.

• Gebruik het woord 'sorry' alleen in foutberichten die leiden tot ernstige problemen voor de gebruiker (bijvoorbeeld gegevensverlies of onvermogen om de computer te gebruiken). Verontschuldig me niet als het probleem zich heeft voorgedaan tijdens de normale werking van het programma (bijvoorbeeld als de gebruiker moet wachten tot er een netwerkverbinding is gevonden).

juist:

Fabrikam Backup heeft een onherstelbaar probleem gedetecteerd en is afgesloten om bestanden op uw computer te beveiligen.

• Raadpleeg producten met hun korte namen. Gebruik geen volledige productnamen of handelsmerksymbolen. Neem de bedrijfsnaam alleen op als gebruikers de bedrijfsnaam aan het product koppelen. Neem geen programmaversienummers op.

Onjuist:

juist:

In het onjuiste voorbeeld worden volledige productnamen en handelsmerksymbolen gebruikt.

• Gebruik dubbele aanhalingstekens rond objectnamen. Hierdoor is de tekst gemakkelijker te parseren en voorkomt u mogelijk gênante uitspraken.
  • Uitzondering: Volledig gekwalificeerde bestandspaden, URL's en domeinnamen hoeven niet tussen dubbele aanhalingstekens te staan.

juist:

In dit voorbeeld zou het foutbericht verwarrend zijn als de objectnaam niet tussen aanhalingstekens stond.

• Vermijd het starten van zinnen met objectnamen. Dit is vaak moeilijk te parseren.
• Gebruik geen uitroeptekens of woorden met alle hoofdletters. Met uitroeptekens en hoofdletters voelt het alsof u de gebruiker aan het schreeuwen bent.

Zie Style and Tonevoor meer richtlijnen en voorbeelden.

titels

• Gebruik de titel om de opdracht of functie te identificeren waaruit de fout afkomstig is. Uitzonderingen:
  • Als er een fout wordt weergegeven door veel verschillende opdrachten, kunt u in plaats daarvan de programmanaam gebruiken.
  • Als deze titel overbodig of verwarrend is met de hoofdinstructie, gebruikt u in plaats daarvan de naam van het programma.
• Gebruik de titel niet om het probleem uit te leggen of samen te vatten dat het doel is van de hoofdinstructie.

Onjuist:

In dit voorbeeld wordt de titel onjuist gebruikt om het probleem uit te leggen.

• Gebruik hoofdlettergebruik in titelstijl zonder interpunctie te beëindigen.

hoofdinstructies

• Gebruik de hoofdinstructie om het probleem in duidelijke, duidelijke, specifieke taal te beschrijven.
• Wees beknopt gebruik slechts één, volledige zin. Pareer de hoofdinstructie tot de essentiële informatie. U kunt het onderwerp impliciet laten als het uw programma of de gebruiker is. Neem de reden voor het probleem op als u dit beknopt kunt doen. Als je iets meer moet uitleggen, gebruik dan een aanvullende instructie.

Onjuist:

In dit voorbeeld wordt het volledige foutbericht in de hoofdinstructie geplaatst, waardoor het moeilijk te lezen is.

• Wees specifiek als er objecten betrokken zijn, geef hun naam op.
• Vermijd het plaatsen van volledige bestandspaden en URL's in de hoofdinstructie. Gebruik in plaats daarvan een korte naam (zoals de bestandsnaam) en plaats de volledige naam (zoals het bestandspad) in de aanvullende instructie. U kunt echter één volledig bestandspad of URL in de hoofdinstructie plaatsen als het foutbericht anders geen aanvullende instructie nodig heeft.

In dit voorbeeld staat alleen de bestandsnaam in de hoofdinstructie. Het volledige pad staat in de aanvullende instructie.

• Geef helemaal niet het volledige bestandspad en de URL als dit duidelijk is vanuit de context.

In dit voorbeeld wijzigt de gebruiker de naam van een bestand in Windows Verkenner. In dit geval is het volledige bestandspad niet nodig omdat het duidelijk is vanuit de context.

• Gebruik indien mogelijk de huidige gespannenheid.
• Gebruik hoofdlettergebruik in zinsstijl.
• Neem geen eindperioden op als de instructie een instructie is. Als de instructie een vraag is, neemt u een laatste vraagteken op.

Hoofdinstructiesjablonen

Hoewel er geen strikte regels zijn voor formuleringen, kunt u de volgende hoofdinstructiesjablonen gebruiken, indien mogelijk:

• [optionele onderwerpnaam] kan niet [actie uitvoeren]
• [optionele onderwerpnaam] kan geen [actie uitvoeren] omdat [reden]
• [optionele onderwerpnaam] kan [actie] niet uitvoeren naar [objectnaam]"
• [optionele onderwerpnaam] kan [actie] niet uitvoeren naar [objectnaam]" omdat [reden]
• Er is onvoldoende [resource] om [actie uit te voeren]
• [Onderwerpnaam] heeft geen [objectnaam] vereist voor [doel]
• [Apparaat of instelling] is uitgeschakeld zodat [ongewenste resultaten]
• [Apparaat of instelling] is niet [beschikbaar | gevonden | ingeschakeld]
• [objectnaam]" is momenteel niet beschikbaar
• De gebruikersnaam of het wachtwoord is onjuist
• U bent niet gemachtigd om toegang te krijgen tot [objectnaam]"
• U hebt geen bevoegdheid om [actie uit te voeren]
• [programmanaam] heeft een ernstig probleem ondervonden en moet onmiddellijk worden gesloten

Breng natuurlijk zo nodig wijzigingen aan voor de belangrijkste instructie om grammaticaal correct te zijn en te voldoen aan de belangrijkste instructierichtlijnen.

aanvullende instructies

• Gebruik de aanvullende instructie om:
  • Geef aanvullende informatie over het probleem.
  • Leg de oorzaak van het probleem uit.
  • Lijststappen die de gebruiker kan uitvoeren om het probleem op te lossen.
  • Bied maatregelen om te voorkomen dat het probleem opnieuw optreedt.
• Stel waar mogelijk een praktische, nuttige oplossing voor, zodat gebruikers het probleem kunnen oplossen. Zorg er echter voor dat de voorgestelde oplossing waarschijnlijk het probleem oplost. Verspil de tijd van gebruikers niet door mogelijke, maar onwaarschijnlijke oplossingen voor te stellen.

Onjuist:

In dit voorbeeld, terwijl het probleem en de aanbevolen oplossing mogelijk zijn, zijn ze zeer onwaarschijnlijk.

• Als het probleem een onjuiste waarde is die de gebruiker heeft ingevoerd, gebruikt u de aanvullende instructie om de juiste waarden uit te leggen. Gebruikers moeten deze informatie niet uit een andere bron bepalen.
• Geef geen oplossing als deze eenvoudig kan worden afgeleid van de probleeminstructie.

In dit voorbeeld is er geen aanvullende instructie nodig; de oplossing kan triviaal worden afgeleid van de probleemstelling.

• Als de oplossing meerdere stappen heeft, moet u de stappen presenteren in de volgorde waarin ze moeten worden voltooid. Vermijd echter oplossingen met meerdere stappen omdat gebruikers moeite hebben om meer dan twee of drie eenvoudige stappen te onthouden. Als er meer stappen nodig zijn, raadpleegt u het juiste Help-onderwerp.
• Houd aanvullende instructies beknopt. Geef alleen op wat gebruikers moeten weten. Laat overbodige details weg. Streven naar een maximum van drie zinnen met gemiddelde lengte.
• Als u fouten wilt voorkomen terwijl gebruikers instructies uitvoeren, plaatst u de resultaten vóór de actie.

juist:

Als u Windows opnieuw wilt starten, klikt u op OK.

Onjuist:

Klik op OK om Windows opnieuw te starten.

In het onjuiste voorbeeld is de kans groter dat gebruikers per ongeluk op OK klikken.

• Neem geen contact op met een beheerder, tenzij dit een van de meest waarschijnlijke oplossingen voor het probleem is. Reserveer dergelijke oplossingen voor problemen die echt alleen kunnen worden opgelost door een beheerder.

Onjuist:

In dit voorbeeld is het probleem waarschijnlijk met de netwerkverbinding van de gebruiker, dus het is niet de moeite waard contact op te maken met een beheerder.

• Neem geen contact op met de technische ondersteuning. De optie om contact op te vragen met technische ondersteuning om een probleem op te lossen, is altijd beschikbaar en hoeft niet te worden gepromoveerd via foutberichten. Richt u in plaats daarvan op het schrijven van nuttige foutberichten, zodat gebruikers problemen kunnen oplossen zonder contact op te leggen met technische ondersteuning.

Onjuist:

In dit voorbeeld wordt het foutbericht ten onrechte aangeraden contact op te leggen met technische ondersteuning.

• Gebruik volledige zinnen, hoofdlettergebruik in zinsstijl en einde van interpunctie.

knoppen voor doorvoeren

• Als het foutbericht opdrachtknoppen of opdrachtkoppelingen bevat waarmee het probleem wordt opgelost, volgt u de respectieve richtlijnen in dialoogvensters.
• Als het programma moet worden beëindigd als gevolg van de fout, geeft u een knop Programma afsluiten op. Gebruik Sluiten niet voor dit doel om verwarring te voorkomen.
• Geef anders een knop Sluiten op. Gebruik geen OK voor foutberichten, omdat deze formulering impliceert dat problemen ok zijn.
  • Uitzondering: GEBRUIK OK als uw mechanisme voor foutrapportage vaste labels heeft (zoals bij de MessageBox-API.)

Documentatie

Wanneer u naar fouten verwijst:

• Raadpleeg fouten door hun hoofdinstructie. Als de hoofdinstructie lang of gedetailleerd is, kunt u deze samenvatten.
• Indien nodig kunt u naar een dialoogvenster met een foutbericht verwijzen als een bericht. Raadpleeg het foutbericht alleen in programmeren en andere technische documentatie.
• Maak de tekst indien mogelijk vet. Anders plaatst u de tekst alleen tussen aanhalingstekens indien nodig om verwarring te voorkomen.

voorbeeld: Als u een Er is geen cd-schijf in het station bericht, plaatst u een nieuwe cd-schijf in het station en probeert u het opnieuw.