While I think that online documentation is a great idea, I urge you not to
abandon the printed manuals.
I am personally much more comfortable with manuals than with online
documentation, for reasons of convenience and eyestrain. With many of our
old, slow computers, I must spend several minutes going to online docs,
often frustrated by long waits for pages to load or occasional
disconnections. I can pick up my manuals and find what I need in seconds.
Low-tech is not inherently inferior. Also, I already stare at a screen far
too much during the day, even using a fast computer. Looking up information
in a paper manual is a break from that incessant eyestrain.
That's how it is for me, and I'm a FileMaker developer. Most of my users are
over 30. Many are *way* over 30 and not too comfortable with computers. Only
a few are really computer-savvy. Just convincing the others to use ebase is
a task. Asking them additionally to go online would be counter- productive,
to put it mildly. Every question would come to me and my time would be spent
explaining simple things over and over. There is certainly a place for
printed manuals and will remain so for at least another generation. Users
who want to be told everything are no more likely to look things up online
than they are to pick up the manual.
My only criticism with the current ebase books is indexing. A reference is
only as good as its index. Starting with a full read-through is a good idea
and helps us get launched. But nobody wants to read it twice, searching for
something they missed the first time through. Most answers to most questions
are in the ebase manuals, if we can just figure out what page they're on.
The manuals would be dramatically improved by a much more comprehensive
index.
There has been mention of a documentation database. I like that idea in
theory, but most database docs that I've seen were confusing and not very
easy to use. I think that's a great concept in that it allows the use of a
search engine for retreival. It also can be updated, which is a valuable
attribute. But the user interface must be well conceived for it to be
useful.
My $0.02.
Gary Bogue
Landmark Society of Western New York
> Subject: Delivering documentation
> From: "Walt Daniels" <[EMAIL PROTECTED]>
> Date: Tue, 6 Mar 2001 13:25:28 -0500
> X-Message-Number: 7
>
> 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
---------------------------------------------------------------------
