[Alg] Hoe schrijf je een goede handleiding?

[Shedman]

Tijdens mijn afstuderen ben ik erachter gekomen dat het schrijven van een handleiding is niet zo makkelijk als het lijkt. Zeker niet als je het goed wilt doen. In mijn studie heb ik nooit geleerd hoe je een (goede) handleiding schrijft.

Aangezien jullie ook software schrijven, schrijven jullie vast ook handleidingen, dus mijn vragen zijn:
• Hoe schrijf je een goede handleiding?
• Hoe heb je geleerd een handleiding te schrijven? Welke boeken, sites etc.

[Zoijar]

Die worden meestal geschreven door iemand anders toch? Het is denk ik ook beter als de programmeur geen handleiding schrijft, omdat deze dan dingen als vanzelfsprekend aan neemt waar een user moeite mee zou kunnen hebben. En bovendien kan een programmeur vaak niet heel goed schrijven, of is het in ieder geval niet zijn specialiteit.

[Boss]

Handleiding leren schrijven tijdens diverse projecten/vakken voor mijn studie (werktuigbouwkunde). Als ik nu voor mijn werk programma's maak, probeer ik ze eigenlijk zo te maken dat er geen handleiding bij hoeft: alle functies spreken voor zich, duidelijke interface, etc.

Mocht er echt behoefte zijn aan een handleiding, dan doe ik dat meestal door alle schermen van het programma te bespreken, inclusief hun doel/functie en handigheidjes die erin zitten. Met verwijzingen naar andere hoofdstukken als er onderlinge samenhang is tussen twee delen.

Maar het blijft moeilijk. Mijn zus is afgestudeerd op handleidingen, erg leuk: voor bestaande voorwerpen een andere handleiding schrijven, waardoor het product een volledig andere werking/betekenis krijgt. Zo zie je maar dat het wel belangrijk is!

[Anoniem: 35513]

Boss schreef op 18 juli 2004 @ 13:36:
alle functies spreken voor zich, duidelijke interface, etc.

Dit is natuurlijk het belangrijkste. De gebruiker moet eigenlijk de handleiding niet nodig hebben. Bij ingewikkelde programma's is dat wat lastiger te realiseren. Er zijn eigenlijk twee scenario's wanneer de gebruiker de handleiding raadpleegt.

Ten eerste als de gebruiker het programma voor het eerst gebruikt en wil weten hoe hij snel aan het werk kan. Hier is een tutorial geschikt voor, waar een stappenplan de gebruiker door enkele handelingen loodst.

Ten tweede werkt de handleiding als naslagwerk, als de gebruiker wilt weten wat een bepaalde functie precies doet, of als hij wilt weten hoe hij iets moet doen. Het laatste geval brengt weer wat meer problemen met zich mee. Een gebruiker kan bijvoorbeeld een backup op een CD willen zetten, terwijl jou programma dat helemaal niet ondersteunt. Je kan het dan toch in de handleiding zetten als een beperking van het programma, al kan je natuurlijk niet alle dingen die je programma niet doet er in zetten.

[Tim Schuhmacher]

Boss schreef op 18 juli 2004 @ 13:36:
Als ik nu voor mijn werk programma's maak, probeer ik ze eigenlijk zo te maken dat er geen handleiding bij hoeft: alle functies spreken voor zich, duidelijke interface, etc.

Vanzelfsprekend voor een IT'er? Ik heb geleerd dat dat dus een foute aanname is. Je moet iemand in je achterhoofd houden die totaal niet thuis is in de wereld van de computer / jouw software.

Maar binnen een bedrijf waar geld verdient moet worden zal er wel minder tijd in de handleiding gestopt worden en een ondergeschoven kindje zijn.

[NMe]

Ikzelf ben er ook achter gekomen dat een handleiding schrijven niet zo makkelijk is als het lijkt. Zoals Zoijar al zegt: een programmeur neemt dingen voor vanzelfsprekend aan, terwijl ze dat voor anderen niet zijn.
Het beste is, als je toch zélf je handleiding moet schrijven, dat je jezelf helemaal leeg maakt, en je voorstelt dat je het programma niet kent. Vervolgens ga je alle schermen één voor één af, eventueel met screenshots (wel aan te raden ). Dan vertel je in lekentaal wat iets doet. Gebruik je vage termen, verduidelijk ze dan met voorbeelden, enz. En het belangrijkste: als je denkt klaar te zijn, geef dan de handleiding en het product aan iemand die er niet bekend mee is, en vraag om feedback.

[Anoniem: 35513]

Als je programma ook door slimme mensen gebruikt gaat worden is het wel eens handig om een leken-sectie en een expert-sectie te maken. Niets is vervelender dan dat je een foutmelding krijgt of een helppagina leest waarin staat: "Neem contact op met uw systeembeheerder". Drie keer raden wie dat is.

[CubicQ]

Shedman schreef op 18 juli 2004 @ 13:31:
Aangezien jullie ook software schrijven, schrijven jullie vast ook handleidingen, dus mijn vragen zijn:
• Hoe schrijf je een goede handleiding?
• Hoe heb je geleerd een handleiding te schrijven? Welke boeken, sites etc.

Ik heb op de UT een keuzevak 'Schrijven van computerhandleidingen' gevolgd. En dat was achteraf best wel een nuttig vak.

Daar hebben we het boek Handleidingenwijzer van Steehouder en Jansen (9075566395) gebruikt.

Zoijar schreef op 18 juli 2004 @ 13:36:
Die worden meestal geschreven door iemand anders toch? Het is denk ik ook beter als de programmeur geen handleiding schrijft, omdat deze dan dingen als vanzelfsprekend aan neemt waar een user moeite mee zou kunnen hebben. En bovendien kan een programmeur vaak niet heel goed schrijven, of is het in ieder geval niet zijn specialiteit.

Tsja, in het ideale geval natuurlijk wel. Maar zoiets kan alleen bij een bepaalde schaalgrootte. En ik denk niet dat er in Nederland veel bedrijven zijn die groot genoeg zijn om eigen mensen in dienst te hebben die gebruikershandleidingen schrijven. BTW: ik weet niet of je het woord programmeur bewust gekozen hebt, maar het sluit echt perfect aan met http://software.ericsink.com/No_Programmers.html

[KillR-B]

Mijn ervaring met handleidingen is dat men deze bijna niet leest. Gebruikers gaan het liefst aan de slag zonder de instructies te raadplegen. Het is dus van belang dat de handleiding kort en duidelijk is, geen omslachtige beschrijvingen van een functie. Wat ik altijd doe is functies omschrijven in stappen, bijvoorbeeld:

- druk op de knop "Nieuwe abonnee"
- type de naam van de abonnee in
- type het telefoonnummer in
- druk op de knop "Opslaan"

Wat ook belangrijk is om veel afbeeldingen (screenshots) in de handleiding te plaatsen, die betrekking hebben op de beschreven functie. De gebruiker weet dan meteen dat hij op de goede plaats zit binnen de applicatie . In de tekst verwijs je dan naar een plaatje.

Naast een goede inhoudsopgave is een index ook belangrijk als je een omvangrijke applicatie hebt. Men heeft namelijk geen zin om heel de handleiding door te spitten. Men leest de handleiding niet als een boek, maar in gedeelde stukken op het moment dat iets binnen de software onduidelijk is.

Laat je handleiding ook altijd testen door iemand die de applicatie echt helemaal niet kent. Want zoals Zoijar al zei: een programmeur bekijkt anders tegen de applicatie aan dan een nieuwe gebruiker.

Naast de handleiding zijn er wellicht ook andere betere/snellere/goedkopere manieren om de gebruiker kennis te laten maken met de applicatie, zoals goede hints binnen de applicatie of geef een minicursus aan de gebruiker (afhankelijk van de omvang natuurlijk )

Ik hoop dat je hiermee verder kunt, suc6 iig!

[Tomatoman]

CubicQ schreef op 18 juli 2004 @ 14:00:
Tsja, in het ideale geval natuurlijk wel. Maar zoiets kan alleen bij een bepaalde schaalgrootte. En ik denk niet dat er in Nederland veel bedrijven zijn die groot genoeg zijn om eigen mensen in dienst te hebben die gebruikershandleidingen schrijven.

Je kunt er ook gewoon een gespecialiseerd bureau voor inhuren. Zoek bijvoorbeeld eens in de gouden gids op het zoekwoord 'tekschrijvers'.

[markvt]

CubicQ schreef op 18 juli 2004 @ 14:00:
[...]

Tsja, in het ideale geval natuurlijk wel. Maar zoiets kan alleen bij een bepaalde schaalgrootte. En ik denk niet dat er in Nederland veel bedrijven zijn die groot genoeg zijn om eigen mensen in dienst te hebben die gebruikershandleidingen schrijven. BTW: ik weet niet of je het woord programmeur bewust gekozen hebt, maar het sluit echt perfect aan met http://software.ericsink.com/No_Programmers.html

Er zijn wel degelijk bedrijven met handleidingschrijvers in dienst.

Inderdaad is het niet makkelijk een handleiding te schrijven voor een product wat je zelf hebt gemaakt, voor een al bestaand iets van iemand anders schrijf ik makkelijker een handleiding die voor iedereen begrijpelijk is. Omdat je dan zelf ook nog niet precies weet hoe alles werkt.

[Anoniem: 35513]

Ben ik net een beetje aan het AutoCADden, zegt de Active Assistance (de Office Paperclip, zonder paperclip) tegen me: "Magnifying the image
[...] is called zooming in." Daar zou ik niet aan denken als programmeur, dat mensen niet weten wat inzoomen en uitzoomen is. Ik denk eerlijk gezegd ook niet dat iemand die met AutoCAD werkt dat niet weet. Wat ze er echter niet bijvertellen is dat je niet moet klikken, maar moet slepen om in en uit te zoomen.

[ILUsion]

Als programmeur is het inderdaad niet altijd de beste keuze om zelf een handleiding te schrijven omdat je vaak op je eigen niveau probeert te schrijven zodat je misschien eerder de werkwijze van een functie zal bespreken dan het nut ervan. Daarnaast vind ik wel dat een programmeur de aangewezen persoon zou zijn bij kleine projectjes omdat hij de enige is die het programma door en door kent (in bedrijven kan je natuurlijk makkelijk zo'n opdracht aan ervaren schrijvers overlaten).
Wat ik je dus zou aanraden: let erop dat je de handleiding begrijpelijk maakt voor je publiek en concentreer je op het nut van functies en pas in de tweede plaats op de interne werking ervan (al is dat natuurlijk leuk voor een zeer tehcnisch product, en in dat geval is het zelfs een meerwaarde voor de lezer als die weet wat er gebeurt).
Zorg, indien mogelijk, voor screenshots en aan de hand daarvan kan je vaak beter hulp geven dan gewoon in een lapje tekst. Tegenwoordig is het ook zeer leuk om een echte multimedia-handleiding te geven: een video (gewone formaten of Macromedia Flash) waarbij je dan uitleg op het scherm kunt laten zien, uitleg kunt inspreken en dergelijke. Daarnaast heb je natuurlijk technieken die nog verder gaan: hetzelfde als hierboven maar met functies voor de gebruiker om zelf te experimenteren met het programma door het na te bouwen en enkel functies toe te laten die voor een bepaald doel in je handleiding nodig zijn.
Voor technische handleidingen (SDK's etc.) bestaan er genoeg tooltjes die elk language-specific zijn en je code doorspitten en een structuur aanmaken zodat je makkelijk je objecten etc. kunt bespreken.

Enkele gekende programma's:
SnagIt: voor screenshots, opnemen van video
Camtasia Studio: zelfde als hierboven ongeveer
InstallShield Expo: zeer leuk stukje software dat automatisch bij een ander scherm screenshots maakt, muisbewegingen registreert etc. zodat je daarna makkelijk een flash-movie kunt maken als uitleg.

Als het dus eerder de bedoeling is om de gebruiker te laten wennen aan een product is zo'n multimedia-oplossing wel geschikt mijkt mij (Microsoft heeft dat ook vaak gedaan (doen ze dat nog?) bijvoorbeeld bij Windows Me, Windows 2000, Office 2000 waar je tientallen tutorials had oor die producten (naam: 'Step by Step Interactive')) en voor beginnende gebruikers staat het natuurlijk wel zeer mooi als ze niet moeten lezen maar gewoon moeten kijken en luisteren.

Voor een echte handleiding als naslagwerk/technische achtergrond volstaat dat natuurlijk niet maar het hangt eigenlijk volledig van je publiek af.

In mijn eigen projecten geef ik vaak geen volledige handleiding mee. Sommige programma's zijn zo basis dat ik vaak gewoon de Hint-properties gebruik van de componenten en eventueel een veld dat die hint mooi laat zien omdat gebruikers vaak niet wachten op die gele veldjes. Bij moeilijkere projecten geef ik enkel een technische handleiding mee (ik schrijf vooral open-source) en die is vaak maar enkele bladzijden lang. In het beste geval is dat een Word-document en anders is dat gewoon een readme.txt of leesmij.txt . Maar dat is natuurlijk enkel geschikt voor kleine projectjes want professioneel staat het in geen geval.

[Anoniem: 37864]

ILUsion schreef op 18 juli 2004 @ 20:48:
Als programmeur is het inderdaad niet altijd de beste keuze om zelf een handleiding te schrijven omdat je vaak op je eigen niveau probeert te schrijven zodat je misschien eerder de werkwijze van een functie zal bespreken dan het nut ervan. Daarnaast vind ik wel dat een programmeur de aangewezen persoon zou zijn bij kleine projectjes omdat hij de enige is die het programma door en door kent (in bedrijven kan je natuurlijk makkelijk zo'n opdracht aan ervaren schrijvers overlaten).

Als er inderdaad een schrijver voorhanden is. Helaas blijken programmeurs in de praktijk gewoon C++ ofzo te praten en geen 'nederlands' of 'engels'. Bij het bedrijf waar ik werk maken de programmeurs over het algemeen de technische documentatie. Op basis hiervan wordt dan de documentatie gemaakt die geschikt is om aan klanten te geven (technisch dialect er uit en termen waar een klant gelukkig van wordt erin)...

Wat ik je dus zou aanraden: let erop dat je de handleiding begrijpelijk maakt voor je publiek en concentreer je op het nut van functies en pas in de tweede plaats op de interne werking ervan (al is dat natuurlijk leuk voor een zeer tehcnisch product, en in dat geval is het zelfs een meerwaarde voor de lezer als die weet wat er gebeurt).

Dat is leuk als je een naslagwerk schrijft, maar in de praktijk merk ik dat dat toch een heel ander soort handleiding is. Eigenlijk wil je twee handleidingen schrijven: 1 die inderdaad een naslagwerk is, voorzien van een fatsoenlijke index enzo, en 2 een 'quick start guide' of in ieder geval een document wat de gebruiker door een aantal veel voorkomende scenario's loodst. (In het geval van bijvoorbeeld een tekstverwerker is dat 'Hoe voeg ik afbeeldingen in?', 'Hoe maak ik een automatische index van m'n afbeeldingen', 'Hoe doe ik een mail merge'... dat soort dingen. Het naslagwerk hebben ze dan veel minder vaak nodig en ze leren dan de samenhang tussen functies begrijpen (vooropgesteld dat het programma qua user interface en workflow enigszins logisch in elkaar zit, wat helaas vaak ook tegen valt weet ik uit ervaring...)

Zorg, indien mogelijk, voor screenshots en aan de hand daarvan kan je vaak beter hulp geven dan gewoon in een lapje tekst. Tegenwoordig is het ook zeer leuk om een echte multimedia-handleiding te geven: een video (gewone formaten of Macromedia Flash) waarbij je dan uitleg op het scherm kunt laten zien, uitleg kunt inspreken en dergelijke. Daarnaast heb je natuurlijk technieken die nog verder gaan: hetzelfde als hierboven maar met functies voor de gebruiker om zelf te experimenteren met het programma door het na te bouwen en enkel functies toe te laten die voor een bepaald doel in je handleiding nodig zijn.

Multimedia presentaties kijken is hopeloos en duurt veel te lang. Wel een nuttig gebruik van multimedia is in de ingebouwde help van het programma (een contextgevoelige handleiding hoort onder F1 te zitten!). Als een gebruiker zoekt op 'Afbeelding invoegen' zou je dan behalve het stappenplan ook een 'show me' knop kunnen maken die de gebruiker in een kort filmpje of zelfs in het programma zelf laat zien hoe iets werkt.

Voor technische handleidingen (SDK's etc.) bestaan er genoeg tooltjes die elk language-specific zijn en je code doorspitten en een structuur aanmaken zodat je makkelijk je objecten etc. kunt bespreken.

Enkele gekende programma's:
SnagIt: voor screenshots, opnemen van video
Camtasia Studio: zelfde als hierboven ongeveer
InstallShield Expo: zeer leuk stukje software dat automatisch bij een ander scherm screenshots maakt, muisbewegingen registreert etc. zodat je daarna makkelijk een flash-movie kunt maken als uitleg.

Als het dus eerder de bedoeling is om de gebruiker te laten wennen aan een product is zo'n multimedia-oplossing wel geschikt mijkt mij (Microsoft heeft dat ook vaak gedaan (doen ze dat nog?) bijvoorbeeld bij Windows Me, Windows 2000, Office 2000 waar je tientallen tutorials had oor die producten (naam: 'Step by Step Interactive')) en voor beginnende gebruikers staat het natuurlijk wel zeer mooi als ze niet moeten lezen maar gewoon moeten kijken en luisteren.

Voor een echte handleiding als naslagwerk/technische achtergrond volstaat dat natuurlijk niet maar het hangt eigenlijk volledig van je publiek af.

En toch kan je stellen dat 'het publiek' meer prijs stelt op een goede contextgevoelige help en een stapeltje korte quickstarts dan lijvige papieren boekwerken. Maar... ik ben het wel met je eens dat dat wel afhankelijk is van het soort product en het gebruikende publiek...

In mijn eigen projecten geef ik vaak geen volledige handleiding mee. Sommige programma's zijn zo basis

Voor jou wel ja

dat ik vaak gewoon de Hint-properties gebruik van de componenten en eventueel een veld dat die hint mooi laat zien omdat gebruikers vaak niet wachten op die gele veldjes.

Een functie zoeken en telkens moeten wachten op tooltips is uitermate vervelend .

Bij moeilijkere projecten geef ik enkel een technische handleiding mee (ik schrijf vooral open-source) en die is vaak maar enkele bladzijden lang. In het beste geval is dat een Word-document en anders is dat gewoon een readme.txt of leesmij.txt . Maar dat is natuurlijk enkel geschikt voor kleine projectjes want professioneel staat het in geen geval.

Het bevestigt wel wat vooroordelen over programmeurs en open source .

[PeeJay]

De handleiding moet in ieder geval foolproof zijn. Ook tussen Linux gebruikers zitten enorme amateurs
Ik denk dat het gebruik van screenshots wel aan te raden is.

Ik heb telefonisch al eens instructies gegeven om een mailtje op mijn pc te openen. Van dat gesprek ben ik wel een jaar ouder geworden

Maar als je een concept-handleiding hebt, geef die dan maar aan de persoon die nu tegenover je zit. Dan zal ik mijn licht er wel even over laten schijnen

[curry684]

KillR-B schreef op 18 juli 2004 @ 14:03:
Mijn ervaring met handleidingen is dat men deze bijna niet leest. Gebruikers gaan het liefst aan de slag zonder de instructies te raadplegen.

Online help is ook een handleiding, en die moet wel degelijk verdomd goed geschreven zijn.

Mijn mening: bij een pakket dat niet op professionals is gericht kan de programmeur geen handleiding schrijven om dezelfde reden als dat een programmeur nooit zijn eigen software grondig kan testen, omdat je bij beide processen dezelfde aannames maakt als je tijdens het ontwikkelproces hebt gevolgd, waardoor je vitale stappen/voorbereidingen niet bedocumenteert of aftest. Het is ook niet voor niets dat 'Technical Writer' een gespecialiseerde doelgroep is.

Anoniem: 37864 schreef op 18 juli 2004 @ 22:58:
[...]


Als er inderdaad een schrijver voorhanden is. Helaas blijken programmeurs in de praktijk gewoon C++ ofzo te praten en geen 'nederlands' of 'engels'. Bij het bedrijf waar ik werk maken de programmeurs over het algemeen de technische documentatie. Op basis hiervan wordt dan de documentatie gemaakt die geschikt is om aan klanten te geven (technisch dialect er uit en termen waar een klant gelukkig van wordt erin)...

Hmm nu kan het aan mij liggen, maar over het algemeen maakt een projectleider de Functionele documentatie en een developer de Technische documentatie, en is de TD alleen geschikt voor developers 'na zijn tijd', en kun je de FD met wat geluk omschrijven tot handleiding. In een FD staan de processen vanuit user-perspectief reeds beschreven, en de onzin als DB-diagrammen en flowcharts in een TD lijken me niet echt nuttig voor 'de users'

[ Voor 38% gewijzigd door curry684 op 19-07-2004 09:38 ]

[Shedman]

Dus de conlusies tot nu toe zijn:
• Programmeur/ontwikkelaar geen handleiding laten schrijven (bij zijn eigen werk);
• Ervoor zorgen dat de handleiding op eindgebruikersniveau zit en niet op techneuten-niveau;
• Screenshots gebruiken (1 beeld <--> 1000 woorden-verhaal);
• Handleiding opdelen in 2 stukken: installatie-handleiding en gebruikshandleiding;
• De handleiding aan mensen laten lezen die het programma niet kennen en geen (niet veel) technische kennis bezitten.

Literatuur tot nu toe:
• Handleidingenwijzer van Steehouder en Jansen (thanx CubicQ);
Dit boek is echter op het moment nergens verkrijgbaar. Weet iemand nog andere bronnen?

[Anoniem: 37864]

curry684 schreef op 19 juli 2004 @ 09:36:
[...]
Hmm nu kan het aan mij liggen, maar over het algemeen maakt een projectleider de Functionele documentatie en een developer de Technische documentatie, en is de TD alleen geschikt voor developers 'na zijn tijd', en kun je de FD met wat geluk omschrijven tot handleiding. In een FD staan de processen vanuit user-perspectief reeds beschreven, en de onzin als DB-diagrammen en flowcharts in een TD lijken me niet echt nuttig voor 'de users'

Ja en nee. Mijn 'afdeling' maakt server software en de gebruiksaanwijzingen zijn dan ook bedoeld voor systeembeheerders. De technische documentatie laat zich in ons geval redelijk eenvoudig aanpassen naar systeembeheerderstaal zodat zij ermee uit de voeten kunnen.

[Tsjipmanz]

Shedman schreef op 19 juli 2004 @ 11:28:
Dus de conlusies tot nu toe zijn:
• Programmeur/ontwikkelaar geen handleiding laten schrijven (bij zijn eigen werk);
• Ervoor zorgen dat de handleiding op eindgebruikersniveau zit en niet op techneuten-niveau;
• Screenshots gebruiken (1 beeld <--> 1000 woorden-verhaal);
• Handleiding opdelen in 2 stukken: installatie-handleiding en gebruikshandleiding;
• De handleiding aan mensen laten lezen die het programma niet kennen en geen (niet veel) technische kennis bezitten.

Literatuur tot nu toe:
• Handleidingenwijzer van Steehouder en Jansen (thanx CubicQ);
Dit boek is echter op het moment nergens verkrijgbaar. Weet iemand nog andere bronnen?

Als een programmeur tekstueel en didactisch sterk genoeg is zie ik geen reden waarom hij/zij zelf niet een gebruikershandleiding zou kunnen schrijven. Wel zijn er veel programmeurs die zich niet echt in een leek kunnen verplaatsen en ook weinig gevoel hebben voor het schrijven van een duidelijke en gestructureerde gebruikershandleiding.

Hierboven zei ook iemand dat mensen nauwelijks moeite nemen om eventuele gebruikershandleidingen te lezen, deze ervaring kanik bevestigen. Bij een stuk software een gebruikershandleiding schrijven is vaak ondankbaar werk, mensen stellen je vaak vragen die ook (eenvoudig) in een handleiding zijn te vinden. Het RTFM-idee.

Het "eindgebruikers"-niveau vind ik wat een open deur, een gebruikershandleiding is voor de eindgebruiker en de techneut mag zich doorgaans uitleven op de technische documentatie.

[Boss]

Ik zie ook niet in waarom ik niet zelf mijn handleidingen zou kunnen maken. Ik acht me zelf tekstueel vaardig genoeg om iets over te brengen op andere personen, van ieder niveau

Bovendien heb je in een klein bedrijf niet altijd een aparte handleiding-afdeling bij de hand.

[Anoniem: 39586]

Shedman schreef op 19 juli 2004 @ 11:28:

• Handleiding opdelen in 2 stukken: installatie-handleiding en gebruikshandleiding;

En een hoofdstuk met foutmeldingen en wat je eraan moet doen om die op te lossen!

[Shedman]

Ik denk toch dat je als ontwikkelaar/programmeur bepaalde zaken over het hoofd ziet als je een handleiding bij je eigen programma schrijft, omdat ze in jou ogen logisch zijn. Maar op zich moet het wel kunnen als je terugkoppeling op je handleiding vraagt aan iemand die het programma niet kent.

Anoniem: 39586 schreef op 19 juli 2004 @ 13:54:
[...]

En een hoofdstuk met foutmeldingen en wat je eraan moet doen om die op te lossen!

Goed punt!

[alienfruit]

Hmm. Ik gebruik altijd yellow mijn help framework, hierbij kun je dus als gebruiker van het programam de standaard helptekst aanpassen, op zo'n manier dat je het snapt. Als je bijv. een database applicatie hebt met verschillende gebruikers, kan een soort beheerder, als de algemene tekst onduidelijk is deze aanpassen en herschrijven dat het wel begrijpelijk is voor de medewerkers.

Vervolgens kun je dan opnieuw een handleiding en/of boekwerk hier uit laten generen, tot nu vinden de klanten dit erg handig en makkelijk werken. Verkoopt alleen nog niet lekker aan derden