Creating User Documentation

User documents are created for the same reason that organizations have orientation pamphlets and schools have guideline booklets sent home at the beginning of every school year: They set expectations. Setting the right tone and accurately describing the features is paramount to creating a good user document.

Your users, whether they are students, teachers, librarians, office workers, managers, or interns, all need an accurate description of what to expect. There will be some discussions as roles are redefined, and as some things that may have been previously available are now inaccessible.

In some cases it may be important to state exactly why a certain item is not available. For example, "The Restart menu item was removed because shutting the machine down will remove all temporary files, whereas a restart may not." This gives the user an indication as to why the change was made. Depending on the age of the audience, a walkthrough by a teacher in which students comply is acceptable, as is using Apple Remote Desktop to show all students one machine and then having them repeat the process. Either way, there needs to be documentation to support the system.

Selling the Plan to Users

Perhaps the most interesting part of readying a user document is controlling how that document will be perceived. Often, users of preMac OS X operating systems had no management. There simply was no mechanism for putting it into place. With Mac OS X, unless certain specific steps are wisely taken into account, all administrators are created equal. This has been a bit disconcerting to higher-level administrators, as they have often had to redo or fix what other, less well-trained administrators did.

Keeping all that in mind, you must "sell" the account management strategy to your lesser administrators and users as exactly what it is: a robust, scalable, and feature-rich method of securing the privacy and reliability your users expect, while streamlining the process of account creation, management, and backup. It is at this time when you must put your persuasive skills to the test and make them understand that it is in the best interests of all involved that this plan move forward.

Updating and Delivering Documentation

Everything is fluid, nothing stays the same, and your documentation is no different. First, you must have a method for updating and delivering your documentation to all in a timely manner. This allows for more than one person to understand what changes are being made. If the main administrator leaves, another administrator can use the documentation to trace the changes, past and present, and quickly get up to speed. Second, users need to be apprised of changes quickly, so that they can adapt their habits to any changes.

Consider a Concurrent Versioning System (CVS) for your documentation archive. This is better than just updating a document, because it tracks the changes over time. Also, you may have several administrators making changes to the document. CVS tracks all of their changes. To learn more about CVS, refer to

http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1

CVS may be difficult for some administrators, since it is UNIX-based and the syntax carries a learning curve. For those who want an easier, GUI-based approach, any word-processing application that can track and show editorial changes should work.