Help

Gebruik Help als een secundair mechanisme om gebruikers te helpen taken te voltooien en beter te begrijpen wat het primaire mechanisme is dat de gebruikersinterface zelf is. Pas deze richtlijnen toe om de inhoud echt nuttig en gemakkelijk te vinden.

Een Help-systeem bestaat uit verschillende typen inhoud die is ontworpen om gebruikers te helpen wanneer ze een taak niet kunnen voltooien, een concept in meer detail willen begrijpen of meer technische details nodig hebben dan beschikbaar zijn in de gebruikersinterface.

In dit artikel verwijzen we naar Help als secundair voor de gebruikersinterface. De gebruikersinterface is primair omdat gebruikers eerst hun problemen proberen op te lossen. Ze raadplegen het Help-systeem alleen als ze hun taak niet kunnen uitvoeren met de gebruikersinterface.

De startpagina van Windows Help en Ondersteuning, beschikbaar via het menu Start.

Opmerking: richtlijnen met betrekking tot stijl en toon worden weergegeven in een afzonderlijk artikel.

Is dit de juiste gebruikersinterface?

Houd rekening met deze vragen om te bepalen:

• Hoe gemotiveerd zijn uw doelgebruikers? Hoe meer gemotiveerd ze zijn om functionaliteit van uw programma te ontdekken en tussenliggende of zelfs geavanceerde gebruikers ervan te worden, hoe meer ze bereid zijn om antwoorden op hun vragen te onderzoeken door Help-onderwerpen te raadplegen.
• Gebruikt u Help om een slechte gebruikersinterface op te lossen? Hoe beter uw gebruikersinterface, hoe minder gebruikers extra hulp zoeken. Als uw programma zeer duidelijke, nuttige primaire gebruikersinterface heeft (zoals jargonvrije foutberichten, goed geschreven wizards en ondubbelzinnige dialoogvensters), hebt u mogelijk helemaal geen secundair Help-systeem nodig.
• Is uw programma relatief eenvoudig? Zo ja, overweeg dan alle benodigde hulpinhoud op te nemen in uw primaire UI-oppervlakken. Gebruikers zoeken waarschijnlijk extra hulp in programma's die complexe taken uitvoeren.
• Is uw toepassing bedoeld voor ontwikkelaars, IT-professionals of andere software-experts? Deze gebruikers verwachten meestal referentie-Help voor programmeertaalconventies en uitgebreide conceptuele Help voor het beheersen van functies.

Ontwerpconcepten

Als u besluit om Help in uw programma op te nemen, integreert u deze in uw algehele ontwerp. De Help-interface moet eenvoudig, efficiënt en relevant zijn; hiermee kunnen gebruikers eenvoudig hulp krijgen en vervolgens terugkeren naar hun taak. Denk aan uw Help-systeem in termen van de tijd van gebruikers: minimaliseer eerst onderbrekingen door te anticiperen op waar ze problemen in uw programma zullen tegenkomen en deze problemen vervolgens op te lossen door fundamentele hulp rechtstreeks in uw gebruikersinterface op te nemen en duidelijke en consistente toegangspunten te maken in uw gedetailleerdeRe Help.

Windows-hulp is ontworpen volgens deze principes. Hier volgen enkele ontwerpwijzigingen in de Gebruikerservaring van Windows Help:

• Meer vindbare toegangspunten voor Help vanuit de primaire gebruikersinterface (met name nieuwe Help-koppelingen van UI-oppervlakken, zoals dialoogvensters, foutberichten en wizards). Met Help-koppelingen gaat u rechtstreeks naar het relevante onderwerp in Help.
• In de rechterbovenhoek van de meeste hubpagina's van het Configuratiescherm en shellmappen is een pictogram voor de Help-knop beschikbaar.
• Gebruikers kunnen ervoor kiezen om de meest up-to-date Help-inhoud van Windows Online Help en Ondersteuning te krijgen wanneer ze online zijn.
• Help-onderwerpen zijn nu taakgericht in plaats van op functies gericht, zodat gebruikers hun taken snel en efficiënt kunnen uitvoeren.
• Help-onderwerpen zijn nu grotendeels gebaseerd op bekende belangrijkste gebruikersscenario's.
• Help-onderwerpen hebben een meer ontspannen en informele toon, waarbij ze alledaagse taal gebruiken.
• Help-onderwerpen zijn ontworpen voor effectieve scanbewerkingen, omdat gebruikers zelden het woord voor woord lezen.

Een analogie voor Help

Als u dieper wilt nadenken over het ontwerpen van uw Help-systeem, kunt u een analogie van het dagelijkse leven overwegen. Je bent verloren in een onbekende stad. Wat voor werk doe je? Velen reageren als volgt:

• Ga georiënteerd; zoek naar oriëntatiepunten, straatborden (namen en aanwijzers naar plaatsen).
• Zoek naar kaarten.
• Als laatste redmiddel vraagt u om een routebeschrijving of belt u een vriend.

Het ontwerp van de "interface" van de stad beïnvloedt uw behoefte aan hulp. Goed gelabelde straten, expliciete aanwijzingen (pointers naar ziekenhuizen, luchthavens, musea en het postkantoor) en duidelijke bezienswaardigheden zoals prominente geografische kenmerken of gebouwen helpen u bij het vinden van uw weg.

Je vraagt om hulp als laatste redmiddel. Het is een indicatie dat de "interface" van de stad is mislukt door slecht ontworpen en verwarrend te zijn. U zult waarschijnlijk om hulp vragen op een plaats met een specifiek label dat nuttigheid voorstelt. U hebt bijvoorbeeld meer kans om hulp te vragen op een plaats met de naam 'Routebeschrijving' of 'Informatie' dan een algemene plaats zoals het stadhuis, ook al kan ongeveer iedereen in het stadhuis u een routebeschrijving geven.

Wanneer je om hulp vraagt, ben je gefrustreerd en wil je gewoon naar je beoogde bestemming. Je bent waarschijnlijk niet in de stemming om tijd te besteden aan een rondleiding door de stad of om te leren over de geschiedenis. Verder hangt uw motivatie af van het belang van de taak. Als u uw hotelkamer zoekt, doet u alles wat u nodig hebt. Als uw doel echter is om een plaats van klein belang te vinden, zult u waarschijnlijk gewoon opgeven na een bescheiden inspanning.

Al deze aspecten van het vinden van uw weg in echte ruimte komen overeen met hoe gebruikers doorgaans hun weg vinden in de virtuele ruimte van uw programma. Hulp zoeken buiten de primaire gebruikersinterface is door zijn aard desoriënterend; doe uw best om een dergelijke ervaring te beperken door een goed ontworpen gebruikersinterface en intelligente "straatborden" om gebruikers naar de antwoorden te leiden die ze nodig hebben.

Gebruikersinterface ontwerpen zodat Help niet nodig is

Probeer Help in de eerste plaats onnodig te maken door:

• Veelvoorkomende taken gemakkelijk te ontdekken en uit te voeren.
• Duidelijke hoofdinstructies.
• Duidelijke, beknopte controlelabels bieden die doel- en taakgericht zijn.
• Het verstrekken van aanvullende instructies en uitleg indien nodig.
• Het anticiperen op vermijdbare problemen door besturingselementen te gebruiken die beperkt zijn tot geldige keuzes, geschikte standaardwaarden te bieden, alle invoerindelingen te verwerken en fouten te voorkomen.
• Foutberichten schrijven die een duidelijke oplossing of actie bieden die de gebruiker moet uitvoeren.
• Vermijd verwarrende UI-ontwerpen, zoals taken met een slechte doorstroom of het gebruik van bedieningselementen die zonder duidelijke reden zijn uitgeschakeld.
• Werken met schrijvers en editors vroeg in de ontwikkelingscyclus om hoogwaardige, consistente UI-tekst te maken in uw programma.

Gebruikers hoeven niet ergens anders te gaan om erachter te komen hoe ze uw gebruikersinterface moeten gebruiken. Voeg essentiële informatie rechtstreeks toe aan de primaire gebruikersinterface, in plaats van gebruikers uit hun directe context en in het Help-deelvenster te dwingen. Als er alleen belangrijke informatie bestaat in een Help-onderwerp, is het een goede kans dat gebruikers deze niet zien. Voor informatie die optioneel en verklarend is, gebruikt u Help-koppelingen van de primaire gebruikersinterface naar het relevante Help-onderwerp voor aanvullende hulp.

Gezien de motivatie van de gebruiker

Voor de meeste gebruikers zijn snelheid en efficiëntie een van de belangrijkste voordelen van goede programma's. Gebruikers willen hun werk doen. Over het algemeen zijn ze niet geïnteresseerd in het leren over het programma en de technologie in eigen naam; hun geduld strekt zich alleen uit voor zover dat programma hun eigen belangen dient en problemen oplost.

Ontwerp uw Help-systeem zodat deze overeenkomt met de motivatie van uw gebruikers. Denk bijvoorbeeld aan een gebruiker die naar een kiosk in een museum heeft gewandeld. Als ze niet weet hoe ze de taak snel moet uitvoeren, geeft ze waarschijnlijk gewoon op en loopt ze weg. Ze zal waarschijnlijk geen tijd besteden aan het gebruik van Help. Een zeer gemotiveerde gebruiker heeft ook een hogere tolerantie voor tijd die is besteed aan het onderzoeken van uw Help-systeem voor antwoorden. Een zakelijke gebruiker die de boeken moet verdelen, is bijvoorbeeld waarschijnlijk bereid om Help-inhoud te raadplegen om optimaal gebruik te maken van die nieuwe boekhoudtoepassing.

Inhoud schrijven voor scannen

Schrijf Help-onderwerpen met de wetenschap dat ze worden gescand op specifieke informatie, in plaats van woord voor woord te lezen. Schrijf beknopt, ga snel naar het punt en geef informatie waar gebruikers op kunnen reageren.

• Schrijf 'how-to'-onderwerpen met genummerde stappen in een consistente opmaak, zodat gebruikers herkennen dat ze stapsgewijze begeleiding krijgen.
• Schrijf naslagonderwerpen met oog op scanbaarheid, bijvoorbeeld met behulp van tabellen om opties van de gebruikersinterface of programmeertaal syntaxis weer te geven.
• Schrijf conceptuele onderwerpen die logisch zijn ingedeeld op subkoppen, zodat de gebruiker hele secties van minder belang kan overslaan.

In alle Help-inhoud is het eenvoudiger om lijsten met opsommingstekens te scannen dan standaardalineablokken met tekst; gebruik lijsten met opsommingstekens kundig, niet als een kruk voor ongeordend materiaal.

Inhoud maken die belangrijk is

Aangezien er geen Help-systeem kan anticiperen op elke vraag die elke gebruiker mogelijk heeft, richt u zich op de meeste inhoud op het beantwoorden van de belangrijkste vragen in de belangrijkste scenario's voor uw doelgebruikers. Effectieve zoekfunctie en het tot stand brengen van netwerkconnectiviteit (onder andere taken) kunnen bijvoorbeeld zeer gewilde onderwerpen zijn. Richt je ook op taken binnen je belangrijkste gebruikersscenario's, in plaats van een functie of technologie uitgebreid te documenteren omwille van zichzelf.

Tip: Technische ondersteuning is een goede bron voor Help-inhoud. Helpdesks houden vaak records bij van veelgestelde vragen over bepaalde programma's of taken die gebruikers proberen (en mislukken) uit te voeren.

Het is niet nodig om hulp te bieden voor elke functie in de gebruikersinterface. Vaak is de help niet nuttig omdat er geprobeerd wordt hulp voor alles te creëren. Als de gebruikersinterface goed is ontworpen, zijn de meeste van deze Help-onderwerpen niet erg nuttig; ze zullen gewoon het voor de hand liggende herstellen.

Als er meer dan één manier is om een taak uit te voeren, kunt u in de meeste gevallen gewoon de meest voorkomende manier documenteren die wordt gebruikt door onervaren gebruikers. Uitzonderingen hierop zijn toegankelijkheidsoverwegingen (bijvoorbeeld toetsenbordequivalenten van muisacties documenteren) en platformoverwegingen (documenteren voor de tabletformulierfactor, bijvoorbeeld voor serveromgevingen waarin de opdrachtregel kan worden vervangen door de grafische gebruikersinterface).

Vergeet niet dat gebruikers vaak niet denken aan de problemen die ze tegenkomen in precies dezelfde termen als u. Gebruikers kunnen het bijvoorbeeld vreemd vinden om zichzelf als een 'account' te beschouwen. Zorg ervoor dat u de zoek- en indexeringsfunctionaliteit ontwerpt om rekening te houden met waarschijnlijke terminologievariaties en synoniemen.

Tussen de primaire gebruikersinterface en het Help-systeem moeten termen echter vergelijkbaar zijn als ze niet identiek zijn. Gebruikers kunnen worden verward wanneer de Taal van het Help-systeem niet erg nauw correleert met wat ze op het scherm zien.

Aantrekkelijke Help-koppelingstekst schrijven

Wanneer u vanuit uw primaire gebruikersinterface een koppeling naar een Help-onderwerp koppelt, moet u aantrekkelijke Help-koppelingstekst schrijven. Duidelijke en specifieke taal inspireert vertrouwen. Gebruikers geloven vaak dat algemene Help-koppelingen (een knop met het woord 'Help' of 'Meer informatie' erop) niet leiden tot de juiste informatie zonder een aanzienlijke investering in tijd.

Als u slechts vijf dingen doet...

1. Ontwerp uw gebruikersinterface zodat gebruikers geen Help nodig hebben.
2. Maak uw Help nuttig door de inhoud te richten op de belangrijkste vragen in de belangrijkste scenario's voor uw doelgebruikers.
3. Presenteer de Help-inhoud zodat u deze eenvoudig kunt scannen.
4. Begrijp dat u geen hulp hoeft te bieden voor elke functie in de gebruikersinterface.
5. Maak de helpsectie gemakkelijk te vinden en aantrekkelijk.

Gebruikspatronen

Verschillende soorten inhoud dienen voor verschillende doeleinden.

Inhoudstype	Voorbeeld
Procedurele Hulp bevat de stappen voor het uitvoeren van een taak.	Procedurele hulp moet zich richten op 'hoe' informatie in plaats van 'wat' of 'waarom'. In dit voorbeeld wordt in het Help-onderwerp beschreven hoe u een functie van het hulpprogramma Schijfopruiming gebruikt, met de stappen die u op volgorde kunt volgen.
Conceptuele Hulp biedt achtergrondinformatie, functieoverzichten of processen.	Conceptuele hulp moet 'wat' of 'waarom'-informatie bieden die verder gaat dan dat nodig is om een taak te voltooien. In dit voorbeeld definieert het Help-onderwerp wat het bureaublad is en bevat aanvullende informatie over wat het bevat en waarom gebruikers ermee werken.
Referentie Help fungeert als een online referentieboek.	U kunt referentiehulp gebruiken om een programmeertaal of programmeerinterfaces te documenteren. In dit voorbeeld bevat het Help-onderwerp typografische conventies die worden gebruikt voor deze specifieke taal of toepassing, waardoor de informatie in een eenvoudig te scannen tabel wordt verstrekt.

Richtsnoeren

Toegangspunten

• Koppeling naar specifieke, relevante Help-onderwerpen. Maak geen koppeling naar de startpagina van Help, de inhoudsopgave, een lijst met zoekresultaten of een pagina die alleen naar andere pagina's wordt gekoppeld. Vermijd koppelingen naar pagina's die zijn gestructureerd als een grote lijst met veelgestelde vragen, omdat gebruikers hierdoor moeten zoeken naar de pagina die overeenkomt met de koppeling waarop ze hebben geklikt. Maak geen koppeling naar specifieke Help-onderwerpen die niet relevant en nuttig zijn voor de betreffende taak. Maak nooit een koppeling naar lege pagina's.

• Plaats help-koppelingen niet in elk venster of elke pagina omwille van consistentie. Als u een Help-koppeling op één plaats opgeeft, betekent dit niet dat u ze overal moet opgeven.

• Gebruik Help-koppelingen voor dialoogvensters, foutberichten, wizards en eigenschappenvensters. Als de Help-koppeling van toepassing is op specifieke elementen, plaatst u deze eronder, links uitgelijnd. Als de Help-koppeling van toepassing is op het hele venster, plaatst u deze linksonder in het inhoudsgebied van het venster.

  

  In dit voorbeeld is de tweede Help-koppeling van toepassing op een groep besturingselementen.

  

  In dit voorbeeld is de Help-koppeling van toepassing op het hele venster.

• Help-koppelingen gebruiken in plaats van algemene tekstverwijzingen naar Help wanneer dat technisch mogelijk is.

  Correct:

  Hoe kan ik schijffouten herstellen?

  Onjuist:

  Zie Help en ondersteuning voor meer informatie over het herstellen van schijffouten.

• Gebruik een Help-knop met het Help-pictogram voor de hubpagina's van configuratiescherm-items. Plaats het in de rechterbovenhoek. Deze knoppen hebben geen label, maar hebben een tooltip met de tekst 'Help'.

  

  Een configuratiescherm-item met een Help-knop.

• F1-hulp is optioneel. Gebruikers zijn gewend aan het vinden van Help-informatie met betrekking tot de directe context van de gebruikersinterface op het scherm door op de F1-toets te drukken, met het label Help op standaardtoetsenborden. U kunt F1 Help opnemen als bijvoorbeeld uit bruikbaarheidsstudies blijkt dat uw gebruikers deze verwachten te vinden, of dat de gebruikersinterface van uw programma complex genoeg is om te profiteren van contextuele hulp.

• Programma's met menubalken kunnen een Help-menucategorie hebben. Zie Menu'svoor helpmenurichtlijnen.

  

  In dit voorbeeld heeft het Windows Paint-accessoire een menucategorie Help.

• Voor toetsenbordtoegankelijkheid kunt u tabstops opgeven voor Help-knoppen en koppelingen.

• De knop en het koppelingsgedrag van de Help moeten er als volgt uitzien: het Help-deelvenster wordt geopend en er wordt een specifiek Help-onderwerp weergegeven; de gebruikersinterface die het Help-deelvenster heeft aangeroepen, moet geopend blijven om de contextuele ervaring te behouden.

• Gebruik niet de volgende verouderde Help-invoerpuntstijlen: 'Meer informatie' of 'Meer informatie over...' koppelingen, algemene Help-knoppen en contextgevoelige Help-knoppen op de titelbalk. Hoewel ze in het verleden zijn gebruikt, hebben bruikbaarheidsstudies vastgesteld dat gebruikers ze meestal negeren. Gebruik in plaats daarvan koppelingen naar specifieke Help-onderwerpen. Voor richtlijnen over het schrijven van goede Helplink, zie Helplink.

  Onjuist:

  

  Gebruik geen koppelingen zoals 'Meer informatie' of 'Meer informatie over...'.

  Onjuist:

  

  Gebruik geen algemene Help-knoppen.

  Onjuist:

  

  Gebruik geen contextgevoelige Help-knoppen op de titelbalk.

Inhoud

• Maak geen duidelijke inhoud. Help-onderwerpen die herhalen wat zich in de primaire gebruikersinterface bevindt, voegen geen waarde toe.
• Maak geen inhoud waaraan de gebruiker op een of andere manier niet kan handelen.
  • Uitzondering: Sommige conceptuele inhoud levert belangrijke achtergrondinformatie zonder dat dit noodzakelijk leidt tot actie van de gebruiker.
• Vermijd vage oplossingen voor problemen. Bijvoorbeeld: 'neem contact op met uw systeembeheerder' of 'installeer de toepassing opnieuw', hebben de neiging om gebruikers te frustreren.
  • Uitzondering: raad aan contact op te stellen met de systeembeheerder als dat de enige praktische oplossing is en systeembeheerders verwachten dat er contact wordt opgenomen met het probleem.
• Vermijd inhoud die betrekking heeft op zeer onwaarschijnlijke gebruikersscenario's. Ontwikkel uw belangrijkste Help-inhoud voor wat u verwacht normaal gebruik; let op belangrijke uitzonderingen op het verwachte gebruik, maar behandel deze inhoud als een lagere prioriteit.
• Verzamel feedback van uw gebruikers over hoe nuttig uw Help-onderwerpen zijn. Gebruikers toestaan afzonderlijke onderwerpen te beoordelen. Voer bruikbaarheidsstudies uit over uw documentatie om problemen met betrekking tot kwaliteit en vindbaarheid van inhoud vast te stellen.
  • Tip: Feedback van gebruikers is ook een uitstekende manier om meer taakinhoud te genereren, gericht op wat gebruikers eigenlijk met uw programma doen, in plaats van op functies gebaseerde inhoud, gericht op een beschrijving van de technologie.
• Bied meerdere manieren om toegang te krijgen tot uw inhoud. Een inhoudsopgave, een index en een zoekmechanisme zijn drie van de meest voorkomende methoden om de detectie te verbeteren.
• Als er meer dan één manier is om een taak uit te voeren, kunt u in de meeste gevallen gewoon de meest voorkomende manier documenteren die wordt gebruikt door onervaren gebruikers.

Pictogrammen

• Gebruik het Help-pictogram alleen voor Verkenner-vensters en de hubpagina's van configuratiescherm-items. Gebruik het Help-pictogram niet met Help-koppelingen.

juist:

In dit voorbeeld wordt in een Windows Verkenner-venster een Help-pictogram gebruikt om toegang te bieden tot Help.

Onjuist:

In dit voorbeeld wordt het Help-pictogram linksonder onjuist gebruikt met een Help-koppeling.

Tekst

Help-koppelingen

• Geef specifieke informatie op over de inhoud van het Help-onderwerp met zoveel relevante, beknopte tekst als nodig is. Gebruikers negeren vaak algemene Help-koppelingen. Zorg ervoor dat de resultaten van de koppeling voorspelbaar zijn dat gebruikers niet verrast zijn door de resultaten.

  • Uitzondering: U kunt 'Meer informatie' gebruiken om instructies aan te vullen die zich rechtstreeks in de gebruikersinterface bevinden, met name als u specifieke informatie opgeeft in de Help-koppeling, leidt tot onnodige herhaling of maakt de koppeling minder aantrekkelijk.

  Onjuist:

  Een sterk wachtwoord heeft ten minste zes hoofdletters, cijfers en symbolen. Wat is een sterk wachtwoord?

  juist:

  Een sterk wachtwoord heeft ten minste zes hoofdletters, cijfers en symbolen. Meer informatie

  In het onjuiste voorbeeld is de Help-link terugkerend. Het stelt een vraag die echt al is beantwoord.

• Formuleer indien mogelijk de Help-koppelingstekst in termen van de belangrijkste vraag die door de Help-inhoud wordt beantwoord. Gebruik geen formulering 'Meer informatie over', 'Vertel me meer over' of 'Hulp krijgen met deze formulering'.

  Onjuist:

  Meer informatie over het toevoegen van uitzonderingen

  Correct:

  Wat zijn de risico's van het toestaan van uitzonderingen?

  Hoe voeg ik uitzonderingen toe?

  In de juiste voorbeelden wordt de koppeling uitgedrukt in termen van de primaire vraag die wordt beantwoord door het Help-onderwerp.

• Als de meest relevante informatie beknopt kan worden samengevat, plaatst u de samenvatting rechtstreeks in de gebruikersinterface in plaats van een Help-koppeling te gebruiken. U kunt echter een Help-koppeling gebruiken om aanvullende informatie te verstrekken.

  Onjuist:

  

  juist:

  

  Beter:

  

  In het juiste voorbeeld wordt de Help-informatie beknopt samengevat, waardoor de kans dat gebruikers deze zullen lezen aanzienlijk wordt verbeterd. Het betere voorbeeld bevat een Help-koppeling voor meer informatie over dit complexe onderwerp.

• Phrase Help links om duidelijk hulp aan te geven. Help-koppelingen mogen nooit als actiekoppelingen overkomen.

• Gebruik de volledige Help-koppeling voor de koppelingstekst, niet alleen de trefwoorden.

  juist:

  Wat zijn de risico's van het toestaan van uitzonderingen?

  Onjuist:

  Wat zijn de risico's van het toestaan van uitzonderingen?

  In het juiste voorbeeld wordt de hele Help-koppelingszin gebruikt voor de koppelingstekst.

  • Uitzondering: Help-koppelingen naar externe websites moeten gewoon de naam van de site of pagina als koppeling gebruiken. Alle tekst die de naam van de site introduceert, hoeft niet in de koppeling zelf te worden opgenomen.

• Help-koppelingen hoeven niet exact overeen te komen met Help-onderwerpkoppen, maar er moet een sterke en duidelijke verbinding tussen de twee zijn. Om deze reden ontwerpt u koppelingen en koppen in paren.

  juist:

  Hoe kan ik de prestaties van deze functie verbeteren? (koppelingstekst)

  Deze functie configureren voor optimale prestaties (onderwerpkop)

  Onjuist:

  Hoe kan ik de prestaties van deze functie verbeteren? (koppelingstekst)

  Volledig overzicht van deze functie (onderwerpkop)

  In het onjuiste voorbeeld verschilt de kop van het Help-onderwerp aanzienlijk van de tekst van de Help-link en kan desoriënterend zijn.

• Als de Help-inhoud online is, maakt u dat duidelijk in de koppelingstekst. Dit helpt het resultaat van de koppelingen voorspelbaar te maken.

  juist:

  Ga naar de Website van Microsoft voor aanvullende indelingen en hulpprogramma's.

  Onjuist:

  Waar vind ik aanvullende indelingen en hulpprogramma's?

• Gebruik volledige zinnen.

• Gebruik geen eindpunctie, met uitzondering van vraagtekens.

• Gebruik geen weglatingstekens voor Help-koppelingen of -opdrachten.

Helpinhoud

• Maak UI-elementen vetgedrukt om ze gemakkelijk te identificeren. Dit is met name handig voor onderwerpen over procedurele Help, zodat gebruikers procedures kunnen scannen en snel relevante UI-elementen kunnen zien.
• Bijschriften opmaken met cursief. Dit geldt voor tabellen, illustraties, schermafbeeldingen en andere grafische elementen die profiteren van korte tekstuele uitleg.
• Raadpleeg Help gewoon als Help. Over het algemeen gebruikt u de term online Help alleen als u echt verwijst naar inhoud op uw website.