Handleiding Methodes

[neothor]

Omdat ik niet helemaal wist waar dit topic thuis hoorde heb ik hem hier maar neer gezet. Het is niet direct programmeren maar heeft er wel mee te maken.

Oke nu ontopic. Ik moet voor mijn afstuderen een handleiding maken voor hun nieuwe product. En ik ben nu opzoek of er methodes zijn voor het opbouwen van zo'n handleiding.

Zoeken op google geeft mij meestal tools om de handleidingen te maken maar helaas niet de methodes. Daarom heb ik maar een aantal handleidingen doorgenomen. Tot nu toe heb ik 2 verschillende stijlen gezien, namelijk:

• Per onderwerp; hierin pakken ze een onderwerp en leggen die uit. Soms komen hierdoor schermen dubbel voor
• Per functie/scherm; hierin pakken ze elk scherm en leggen die uit. Hier is het af en toe zoeken naar wat je wilt hebben.

Mischien zijn er mensen die mij nog een aantal andere methodes of zoektermen kan vertellen waarmee ik wat verder kan in mijn zoektocht.

Op het moment zou ik het liefts per onderwerp willen doen omdat het dan het duidelijkst is voor de klant. Wel is dat wat meer werk.

[WouZz]

Ik denk dat je wat meer info moet geven. Voor wat voor een product moet je een handleiding schrijven? Is het een Desktop applicatie, Web applicatie? Is het een propietary of open source product?

Verder, wat is je doelgroep? Oftewel, voor wie moet je de handleiding schrijven? Zijn dat programmeurs? Dan zijn API docs meestal wel een vereiste. Zijn het eindgebruikers? Wat is het niveau van die doelgroep? Zijn het beginners, experts? Wat is de scope van de handleiding? Ga je diep op alle functionaliteit is of lever je alleen een QuickStart manual?

[ Voor 6% gewijzigd door WouZz op 28-01-2008 16:41 ]

[neothor]

Het gaat om een handleiding van een desktop applicatie voor eindgebruikers. Het niveau van de gebruikers zal laag zijn op het gebied van computers. Verder moet het wel vrij diep gaan.

[WouZz]

Als ik jou was zou ik beginnen met het uitzoeken wat je moet documenteren. een opzet zou kunnen zijn

• Introduction
• Basic tasks
• Advanced tasks
• Troubleshooting
• Glossary

In introduction zet je in het kort uit wat de applicatie doet / waar die voor bedoelt is. Wat kan je er wel mee, wat kan je er niet mee. Ook leg je globaal uit wat de verschillende componenten van je interface doen.

Daarna ga je aan de slag met het uitwerken van verschillende use cases. Welke taken onderscheid je in het systeem en welke interactie is daarvoor vereist. Per taak maak een (sub)hoodstuk. Daarbinnen kan je relateren naar andere hoofdstukken.

Probeer kort en bondig te schrijven, mensen houden niet van lezen. Gebruik waar nodig een screenshot, maar gebruik ze niet te veel.

Als voorbeeld zou je ook kunnen kijken naar de helpfunctie van een willekeurig programma.

[neothor]

Bedankt alvast. Ik zal morgen het met de gasten er over hebben en zal wel eens zien wat er uit komt.
De index zoals jij hebt lijkt me wel wat.

Tomorrow an other day

[Bosmonster]

neothor schreef op maandag 28 januari 2008 @ 16:31:

• Per onderwerp; hierin pakken ze een onderwerp en leggen die uit. Soms komen hierdoor schermen dubbel voor
• Per functie/scherm; hierin pakken ze elk scherm en leggen die uit. Hier is het af en toe zoeken naar wat je wilt hebben.

En wat is er mis met beiden toepassen? Je wilt EN de schermen uitleggen EN de meestvoorkomende applicatie-flows uitleggen. Ze dienen gewoon een ander doel.

edit: beetje zoals WouZz zegt dus

[ Voor 6% gewijzigd door Bosmonster op 28-01-2008 17:34 ]

[Borizz]

Een tip die ik ooit op school geleerd heb:
Zorg ervoor dat je per hoofdstuk (of zelfs per screenshot of iets dergelijks), de foutmeldingen vermeld die in dat hoofdstuk op kunnen treden, met de bijbehorende oorzaken en oplossingen. De foutmeldingen zijn zo makkelijker terug te vinden voor de gebruiker.
Eventueel kan je alle foutmeldingen dan ook nog vermelden in een apart hoofdstuk ter referentie.

[Orphix]

Google op 'technical writing' of 'technical writers' .. in die sferen kom je wellicht meer tips tegen dan op meer development georienteerde sites/weblogs.

[neothor]

Bedank ik zal idd daarop google nog even raadplegen. Ik heb nu gelukkig wel een redelijk beeld van hoe ik de handleiding vorm ga geven.