End-user documentation in MS Access

Question

How do you implement user documentation in Access? I've never bothered with formal user documentation in the past; I tend to rely on good interface design to guide users (or so I tell myself). But I'd really like to know what people smarter than me are doing...

Here are things I think I would consider important (in order):

1. Simplicity: it needs to be simple enough that it can be updated easily as the code changes, otherwise the documentation will end up out of sync
2. Screen shots: a picture's worth a thousand words; screen shots must be easily integrated into the documentation
3. Integration: the user can get to the relevant part of the documentation with as little effort as possible; ie, pressing F1 on a form brings up help for that form vs. opening a help file and having to navigate a table of contents
4. Searchable: full-text search capabilities would be nice

Other considerations:

• Online vs. local: local would be faster/more reliable, but online would be always available plus search engine indexable (allowing use of google site: searches and providing some SEO benefit as well)
• User Editable: how much do you allow users to make changes to the documentation: full access (ie, wiki), no access, moderated forums, etc.
• Version control: text-based formats are more conducive to versioning than say, an Access table with help text inside the mdb
• Exportable to PDF: seems like a nice-to-have

Answer 1

You may find HTML Help suitable.

Answer 2

I don't produce documentation for my client projects unless the client pays me big $$$ for it, as it's extremely difficult. I often guide users in producing in-house materials that document procedures and standards, but in general, I design my apps for EASE OF USE.

That is in contrast to EASE OF LEARNING.

EASE OF USE and EASE OF LEARNING often conflict with each other, as a UI design that makes it really easy to perform a task the first time often gets in the way once the user is accustomed to how things work.

However, it's important to design the UI with two things in mind:

1. things that are done on a daily basis don't need to be easy to learn -- they need to be really fast and friendly for the person who already knows how to use the app. I have a 10+20 rule -- 10 minutes of training and 20 minutes of use and the user will never forget how to use it.

2. things that are done only very seldom should be designed with a UI that is transparent and easy and doesn't require the user to remember anything at all. These kinds of tasks are great candidates for wizard-style interfaces that step the user through the process and provide hints and tips as text along the way.

I also have a number of UI design conventions that I implement throughout an app. The example that springs to mind is that any subform that is a datasheet or continuous form has a doubleclick event that when activated opens a popup form with the full details for the selected record. Once users grasp this convention, they will assume that any subform is doubleclickable in order to navigate to the detail.

There are other such conventions, but that's the basic idea, i.e., to implement similar behaviors in similar contexts so that if a user learns to do something in one context, when she finds herself in a different place with a similar UI, the things learned in the original context are transferrable in terms of basic UI behavior.

Answer 3

In Access I've never created end user documentation. No wait, I did once about 12 years ago. And I paid someone to write the manual along with screen shots. I did also have the hlp files, etc, etc. But I don't recall the details now.

Now for the Auto FE Updater, where appropriate, I have a text control which is underlned and blue which the user can then click on. The code then opens up their web browser to the appropriate page on my website using the ShellExecute API Much simpler for me than trying to figure out some kind of help system that would work for both offline and online. I also update the ToolTip control to put in the exact URL so they can see where they are going to go if they click on the text control. That's a VB 6 program but close enough for your requirements.

Answer 4

You will need to do two things:

1. Create a help file with topic-ID's for all of the topics
2. Link this help file to your access database, and link the topics

We have had very good results with http://www.helpandmanual.com/. From one single source, you can create any sort of help file that you want: pdf, online, chm, hlp, xml, ... It has a screenshot tool integrated.

Every topic can have it's own ID and you can just link your access forms / controls to this ID.

Answer 5

I have done a very similar thing to Tony. Its kind of a user generated content type thing let me explain.

• The database contains a table with a list of the form names and then the path of a help file (word doc) that corresponds with that form.

• Certain users have access to a form that allows them to say what help file corresponds to each form

• Each form then has a help button so when the user clicks on it they open up the correct help file.

This way it is totally flexible, if they just want one big help file then all the links point to that but if the users want to put the effort in then they can make a file for each one. As they help files are separate from the DB storage is not a problem and also help files can be changed without having to recompile the application.

You could merge this idea with Tony’s and have the help files online if you wanted. I just find this a nice design pattern

Answer 6

I recently stumbled upon TiddlyWiki and have been thinking about using that as a backend to the systems Kevin and Tony described.