Database manual for training

[Percy]

Guys
I have just finished building a Database thanks to most of you who helped.
Now I am supposed to write sort of a manual or training material for using
the database. Is there any quicker way that Access can help me to come out
with clear and concise description of how the database will work. Of course I
will add more stuff to clarify to laymen but I would love to have a
foundation.
Thanks again

 

[Jeff Boyce]

Percy

If you are looking for a way to present a simplified view of how Access
works, there are any number of books ("Step by Step", "Dummies", ...) that
attempt to do this.

However (and this is a big BUT), if you have created an application that
makes it easier for your users to get their work done, then you have hidden
much of the complexity of Access behind forms that are user-friendly, easily
understood, documented (internally) with ToolTips, comply with good User
Interface design principles, etc.

Your users need a User Manual for the application, not for Access, if the
latter is the case...

--
Regards

Jeff Boyce
Microsoft Office/Access MVP


Microsoft IT Academy Program Mentor
http://microsoftitacademy.com/

Microsoft Registered Partner
https://partner.microsoft.com/

 

[Percy]

Jeff
Pardon my ignorance. What I actually need is a User Manual for the
Application that I have build. Realising that I have only built this
application not for my use but for other people to use when I have left I
need to the user manual to also go into details of what is what in the
database so that whoever will maintain it will at least have closer knowledge
to the knowledge of the one who built it.

 

[Jeff Boyce]

I'll point out that you may have two separate audiences. The folks who need
to use the application could care less about "how" it works (as my wife is
fond of reminding me she "just wants to make toast", she doesn't care to
learn about where the toaster is sending the electrons).

The second audience is those folks who will be maintaining the application
(or YOU, if you step away from it for 6 months!). These folks need some
idea of how you did what you did.

The first group needs a user-friendly user manual, without any reference to
"tables" or "modules" or ...

The second group needs a picture of the data structure, query contents, ect.
(available via Tools | Analyze | Documenter). Also, be generous with your
in-line comments in any code modules, and use the Description field in your
objects' properties to do internal documentation.

I doubt you'd be able to teach a novice how to develop/maintain an Access
application with a home-grown Technical Users Manual, so aim for an audience
that already understands how to use Access.

JOPO (Just one person's opinion...)

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[George Nicholson]

For a UserManual, consider using some mixture of the following. None of this
(except for the Relationships diagram) is provided by Access itself:

1) - Start with Screenshots of your main forms, paste them into Word & add
descriptions of how to use the form (add data, edit data, etc.)
- Include a short section at the very start of your document to cover

* buttons are for). Keep this real "quick start" simple.

2) - "Walk-through" section(s) that takes a user through common tasks
step-by-step("How to add an Invoice").

3) - Include an addendum that lists common Window (Ctrl-C, Ctrl-V) and/or
Access shortcut keys (assuming they are enabled). Stuff like this can
usually be grabbed from Help files or MS Knowledge base articles.
- Add an addendum that includes a table relationships diagram. Most users
won't care about this, but Power Users might. It would also be the starting
point of Technical documentation.

4) Place the UserGuide word.doc in the same directory as your app & provide
some means (button, menu selection) for the user to open it from within the
app. (Optionally, include "Back to top" bookmarks within the doc, etc.)

Keep in mind that most users won't ever even look at this document, but the
simple fact that it exists will make them happy. Keep it simple to start and
then add detail in subsequent passes.

HTH,