Reading Usable Help
@UsableHelp on Twitter
Gordon R. Meyer
Stumbling towards standards
If someone were to write a history of onscreen help systems, I think that one of the themes that would emerge is how this micro-industry mirrors that of the software industry as a whole. Initially, help systems were built for specialized environments, such as Hypercard or ISPF. These help systems were fine, but they couldn't benefit other applications, so a more general solution was needed.
To answer this, OS vendors built general purpose help systems, such as Apple Guide or Win Help. This approach worked well, and onscreen help flourished, but eventually the costs of porting from one system to another--or simply keeping up with the changes of a single system--proved too costly and troublesome.
To answer this, "portable" formats, primarily HTML-based, emerged. It's a fine media, but the abhorrent standards continue to cause headaches for help authors today. Just as the web struggles with supporting each browser's rendering quirks, help systems must be ready to display just about any poorly-formed HTML an author chooses to use, in the interest of backwards compatibility. If you think there are lots of old, out-of-date web sites out there, the situation is worse with HTML-based help. Perhaps not in sheer number, but certainly in magnitude, since publishing departments are notoriously slow to fix what doesn't seem to be broken. Of course, it is broken, but overly-tolerant help systems mask that from the perpetrators.
So what's next? One approach is to move towards stricter standards such as XHTML. Or, use XML and completely separate the realms of content and style, such as Microsoft's MAML approach for Longhorn. Or, if you prefer a nonproprietary approach, the less ambitious HelpML.