What's the deal with helpfiles these days?

Question

I added this question at SuperUser for the user's perspective.

So I create an application in Delphi or .NET which will run on a desktop system. Some nice GUI with all kinds of functionality and nice features. It works well, tests tell me it's nearly bug-free and I'm about to deploy it...

WAIT! It needs a help file, so users can call upon context-sensitive help from the application!

Or not? Are helpfiles really a requirement for desktop applications these days? And do they really need to be context-sensitive, holding the hands of the user to tell them they have to fill in their day of birth in this field labelled "Day of birth"? Or are helpfiles becoming a bit old-fashioned?

This is something I wonder about and this is a bit subjective, so instead I'm going to ask something different, to all of you who develop desktop applications: Do you (still) offer context-sensitive helpfiles?

Yes, or no, please. Feel free to add some subjective texts but to me, what is important is knowing if modern developers are still adding context-sensitive help to their GUI applications.

(Btw, I myself have moved to non-context PDF files that can be printed as manual. It's a lot easier to maintain.)

Answer 1

We don't currently, but we don't write a lot of Windows apps. Most are web based. Most of our Windows apps are fairly small and well documented outside of a Help file.

Also, we have the ends users write the documentation during the development process, so the documentation is something they will understand.

However, if I were writing a large app for a lot of users (not an internal app) I would include a context-sensitive help file. I've done it in the past for some of our bigger apps, and in a non-internal situation, it's very helpful.

Actually, we're now designing our web site to have a "need help" feature that is context-sensitive, and the feature has been well-received. We're incorporating it into all of our web development now, whether for our company web site or internal.

Answer 2

Yes, I do.

Reason: I just can't expect the user to know how the program works. Ok, describing what has to be inputed into a "Day of birth" field is a bit extrem, but there's normally more complex stuff in a software system. I had to write a help file for our cost accounting system just today, describing how the system for determining the price that should be used for the calculation works. I don't think any user would know how to configure the system withoug this help file.

Answer 3

I have never provided context-sensitive help in an application, nor have I seen it implemented well enough in any other application to ever use it myself. In my opinion, the effort required to do it well exceeds the benefit.

On the last application I was involved in where this decision had to be made, we used tooltip balloons in the application, which displayed a text balloon when the user hovered over each control. We also provided a conventional manual which was mostly walkthroughs with lots of step-by-step screenshots.

After awhile the users got sick of the balloons and turned them off with a checkbox we provided, but it did seem to help the beginners get started.

Answer 4

I give you a personal opinion, not supported by any other fact that my personal taste.

Writing help files was useful in the past, where everything was new and online resources were scarce. Today, most computer users learn by direct exploration. Contextual help in the form of Tooltips is great and strongly encouraged: it gives hints for this explorative learning.

What about help documentation with a lot of links to click around ? well it's apparently great, but used very seldom I guess. In most cases the user can obtain answers with a proper google search. Moreover, this kind of documentation is expensive. It cannot be written by a developer. You have to hire or allocate specific people for this, with technical writing and clarity as relevant skills.

If I had to manage this decision, I would provide full docs only for those features that are very esoteric and special (I would say unique) for your application. I would in any case tend towards an online tutorial, instead of contextual help files. This has the additional advantage to provide information about how difficult is to use your application, and what are the most requested hotspots (by evaluating the hits and referrer search queries to your online docs).

Answer 5

In a recent application, we did not provide context-sensitive help. This had technical reasons rather than anything else (the help file is, essentially, a multi-language docbook file, which in theory supports context-sensitive help, but it didn't work well). It has one page for each window/dialog in the application, with all controls explained. However, each control also has a fairly comprehensive tooltip, which mostly removes the need for additional help. Each dialog has a help button to bring up the dialog-specific page. Historically, you could store the tooltip text in the help file, but that does not seem to work with recent help systems. And they're stored in resources anyway.

But then, it's not an application for everyone. Since the network system that can be managed with the application is a complex topic in itself, there's a special training for the users anyway, and the application has been designed so that if you know the network system, you also know the application. In other words, the application model lines up with the user model so well that comprehensive help features are not needed. This should be the goal of any application development.

Most information in the help files about the controls is not really more than what is already in the tooltip, because nobody needs more.

Office and Visual Studio solved the problem rather similar - pressing help opens the help page for the entire dialog, not for the single control.

If you have a part of a dialog that is so complicated that it needs additional explanation (and given you can't redesign it to make it easier), you can put the explanation right next to the control. This is used in many applications for special cases, so that the workflow is not interrupted because the user has to look up e.g. how a specific text has to be written.

Answer 6

Speaking as a user, not a developer - yes, I want a context sensitive help file.

For example - I'm currently evaluating 3rd party controls for inclusion in a new project. The controls that have good context sensitive help (i.e. you can select a property in the properties window, or a keyword in code, and press F1 to go straight to the help topic) are much, much easier to learn and use.

Answer 7

All our applications have context-sensitive help in the form of tooltips (similar to the Office 2007 tips) for all critical features of the application.

While we don't offer the traditional, full-blown help file, we definitely have a Knowledge Base which we update regularly. This is a collection of all help provided to clients via telephone, email, etc, on any and all issues, properly categorized and easily searchable. This eventually ends up being the best help that contains more or less what clients look for rather than what we initially think they may need.

While a few clients invariably end up contacting us without as much as a glance at the Knowledge Base, it still helps us from reinventing the wheel time and again.

Answer 8

With Tooltips and a generally increased computer ability in users, some applications do just fine without help files. However, some applications need help files, as much for general topic information as for application usage. For example, in a photo app you might want to explain jpeg compression and include some samples in the help file, even if the user operation is self evident.

It seems to me that Microsoft is a contributor to the decline in context-sensitive help, for better or for worse. First, the help systems in Visual Studio are, to put it mildly, a pain to use. Second, the ease of use of Visual Studio's help system has gone downhill significantly. I'll omit the rant, but suffice it to say that it takes many more clicks and scrolls to get relevant info in the VS2008 help. This tends to set a lower standard for help systems in applications.