There are two major forms of documentation, online help text and printed manuals. There are strong proponents of both. However if you look at the questions asked on this list it is completely obvious that almost no one reads the printed manuals. Their questions are easily answered by a very quick look at the manual. It is certainly the case that on average most major program producers have been moving more toward online documentation, quite possibly because it is cheaper rather than better. Ebase is somewhat different than most programs in that what is important to the users is how their organization uses the various facilities provided by ebase. A good example of this is matching contributions, which crops up all the time on this list. There are multiple ways of doing it but each organization will pick only one of those ways. So we have to ask the question of whether ebase should provide a manual for the IT person implementing ebase at their organization or if it should provide a framework for organizations to document how they use the facilities. For some small organizations, there is only the one IT person who does it all. For most others there are many staff/volunteers who do the bulk of the work. With that as a background, let me tell a little about what we do. I am the IT person but there are 4 staff and about 10-15 part time volunteers who do the real work. I have a startup page in front of ebase.102 that provides the user interface to not only ebase but also several other FileMaker databases, but more important in this case it also provides a database that is help text that explains how to do each of the things we normally do (still very much a work in process). The FileMaker find command provides an easy way to locate help for specific problems and the ebase users are already familiar with to use it. I would strongly recommend doing online documentation rather than a printed manual which need only cover how to get ebase installed. Further I would suggest documenting multiple ways of doing things where appropriate and flagging them such that the local IT person can select the way they want to do it and suppress the other ways. Some of the pages should be fill in the blanks type where each site customizes those pages to suit their way of doing business, but they need the skeletal outline to get a jump start. Furthermore that needs to be a whole section on database management issues, e.g. backups, validation, training, etc. The FAQ (or actually a very updated FAQ) should also be distributed as help text as should a digested version of this mailing list. Yes, I understand that the program described above is way over your budget and personell availability. Structuring it as a FileMaker help database should allow the many users to contribute bits and pieces with the techrocks staff providing a grand scheme, a correctness check, and integration. ------------------ Reminder to each recipient: To change your list account preferences, go to http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address you used to subscribe to the ebase support list:: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] --------------------------------------------------------------------- ebase - Relationship Management for Nonprofits, http://www.ebase.org ---------------------------------------------------------------------
