In a recent discussion on Tom Johnson's blog, Tom and others were trying to nail down the reasons why many users have a negative impression of help. Most people have used help before, but few seem to find the answers they are looking for.
The post left me wondering if much of the problem is due to a lack of standards in technical documentation. The look and feel of a help system can differ greatly from one product to the next, as can the writing. So how can the technical writing community emphasize the importance of software documentation standards and create a more unified help experience that users can adapt to?
Some users may be alienated by the lack of a standard help viewer. .CHM files are slowly fading into the sunset because they don't work when launched from servers. WinHelp is long dead. Most technical writing authoring tools now produce browser-based help, but the look and feel of HTML-based help can differ greatly from one tool to the next. There is no standard help viewer.
The lack of a standard viewer can cause a lot of grief for users. How can they trust the help as a source of information when they have to acclimate themselves to a new help interface for every different software product they use? A standard viewer would make it much easier for users to find the information they are looking for and leave with a positive impression of the help.
Negative user experiences also demonstrate the importance of standards for organizing and writing help content. The way topics are organized differs greatly from one system to the next. If a user expects to find links from dialog-level help topics to reference information, they might not revisit a help system that does not provide such links, but instead requires that they access reference topics from an Index. The usability of help systems in general would be enhanced if best practices were documented by standards organizations and followed by help authors.
Unfortunately, a standard help viewer doesn't appear to be on the horizon. Nor does a standards organization to promote best practices for structuring and writing software documentation. Perhaps one day these resources for technical writers will become available. Until then, help authors will simply have to make their individual help as user-friendly as possible and hope that their users are smart and determined enough to dig around and find the answers they seek.
See also: How to write a disaster recovery plan
2 comments:
What sort of features would you expect to see in a standard help viewer?
I think that a wide range of features could be included, such as natural language search with ranked results, favorites, and all the bells and whistles.
It isn't so much the choice of features that's the promlem, in my opinion. The real issue is that no single vendor has presented a format that has been supported for long.
For example, MS Word 1.0 users have been able to follow the program through many changes to Word 2007. Sure, things changed from one version to the next, but it was always Word and it resided on most computers. Users can move from one machine to another and still feel comfortable writing a document.
The lack of a long-supported and pervasive help format makes it hard for users to feel comfortable navigating the help.
Thanks for commenting, Dave!
Post a Comment