Reading Usable Help
@UsableHelp on Twitter
Gordon R. Meyer
Settling for browser-based help
WinWriter's 2002 Survey of Help Authors offers many insights into the current state of the field. Trying to get behind the numbers and ask "why" for some of the findings is a worthwhile mental exercise. For example, most of the respondents author for Windows, yet one of the "most valued" technologies is Web browser-based help. Microsoft's "HTML Help" technology falls much lower in the rankings.
This seems odd at first, since you'd expect that the current help system on the dominant platform would virtually lock-in the top results in all categories. What's going on here? WinWriters provides much of the answer in their own brief analysis. MS HTML Help's proprietary technology and lack of support for remote content, plus the inertia of the old WinHelp being "good enough", moves authors to settle for delivering help in a Web browser instead of a well-designed and optimized help environment.
Check out the list of "most important" features in Web browser-based help -- an index, table of contents, and full-text searching. When we've sunk so low as to list such basic, no-brainer functions as "features" we're clearly just settling for the lowest common denominator when developing Web browser-based help. And beyond these, with so few people citing contextual links and natural-language searching as important, is it any wonder that browser-based help implementations seem so unpalatable?