Wait! Who needs manuals?
Good question. These days, help is available at the click of a button, either from within a program or from the internet. So, if you don’t mind the kids in your class faffing about trying to find what they need, and getting distracted by more interesting things in the process, be my guest.
And what if the internet connection goes down? What then? Do you really want 30 hands going up accompanied by cries of “Sir!” or “Miss!”?
In any case, the help that you find online isn’t always couched in the easiest of terms, or directly relevant to what you want pupils to be able to do.
There’s another potential advantage too. In one of my head of department jobs I wrote a manual for a word processor used in school, and then sold it to the wider public. The proceeds were used to buy hardware for the school — and to get us more publicity!
What should a manual contain?
Not the kitchen sink. It’s better to have a very thin manual that will suffice for a particular audience than a huge tome which replicates the pdf manual you can download from the appropriate website. For example, an introductory manual on spreadsheets, like the one pictured, might have some information on what a spreadsheet can do, how it’s laid out, and how you do calculations, plus how to start a new spreadsheet, save it, open up a previously-created one and how to print it, or a section of it, out. You don’t have to include information about data validity, creating your own functions, goal-seeking and so on. Not in this manual at any rate.
My view, expressed as Freedman’s 5 minute rule, is that someone should be able to log into the program and get something useful done and then log out, all within 5 minutes.
How to write the manual
The quickest and most readable way is as follows:
Include only what’s necessary. Rather than put everything into one manual, write different and specialised manuals. That will also have the advantage of creating usable resources quickly instead of keeping people waiting for weeks or months.
Write the instructions on a need-to-know basis. What I mean by that is that, you don’t have to deal with all the options under the File menu, for example, when all you really need to cover is how to start a new document, save it, print it and open it.
Have one operation per page.
Write in lists. Nobody is expecting, or wants, a work of literature.
Use numbered lists where the order is essential; use bullet points where it isn’t.
Use illustrations such as screenshots.
Use other pictures and design to make it look attractive.
Number the pages.
Include a table of contents.
Ask pupils to test it before you have loads of copies printed.
Yes, printed! People can look through a printed manual while waiting for the program to boot up.
The time issue
A natural objection to all this would be that teachers don’t have the time to write manuals. I have to say that I didn’t find it took all that long, but there are work-arounds:
Ask a teaching assistant to write it instead of you.
Ask a technician to write it.
Ask a pupil to write it, perhaps a member of the ‘digital champions’ if you have such a scheme.
Hire a third party to write it. For example, you could look at my writing services, or explore places like Upwork or Fiverr. Or look at Linkedin for potential writers.
The manual shown was written by myself and illustrated by a pupil called Jason Kotey. His drawings really livened the whole thing up!