Microsoft "Longhorn" Help Highlights
Click a link below to jump to a particular section; click any "
Microsoft's announcement at the 2003 Professional Developers Conference of the next version of Windowscode named "Longhorn"included an unveiling of the proposed new Help format. Prior to the announcement, most of us might have anticipated a modest evolution of the current HTML Help formatperhaps the long-awaited release into the public arena of Help 2, polished up for consumption by non-technical end-users? Clever money might have been on an enhanced version of the Help and Support Center that we have in XP, since that's where Microsoft seems to have been targeting most of its own user assistance efforts in recent OS releases.
In the event, Microsoft's specification for "Longhorn" Help goes much, much further, and represents a major revolution in user assistance development for the Windows platform. Instead of simply refining the technical infrastructure of Help (windowing, links, search, etc.), Microsoft has given a good deal of thought to the needs of both Help authors and end-users. Ralph Walden, the original architect of WinHelp and HTML Help, puts it like this:
"Much of HTML Help's focus was taken up by the new display system, without very much functionality added specifically for user assistance. With Longhorn, the Help team has returned to focusing foremost on providing user assistance."
The result is a Help system designed specifically for creating task-based assistance that can be highly integrated with the application UI.
This article provides you with a synopsis of the key concepts and features of "Longhorn" Help, as currently documented by Microsoft at http://longhorn.msdn.microsoft.com. Even though "Longhorn" may not be released to the general public for two years or more, the paradigm shift in the Help authoring and deployment process demands significant up-front analysis and preparation. It obliges you to rethink your entire publishing strategy for user assistance, and may also require investment in new tools and technologies. For that reason, it may not be too early to start planning how you will take advantage of "Longhorn" Help.
Focus on Semantics
Authors will develop content for "Longhorn" Help using an XML-based markup language called Microsoft Assistance Markup Language (MAML, pronounced "mammal"). Unlike HTML, this markup language is presentation-independent: topics and the elements they contain are defined semantically. For example, in HTML it's common practice to format menu options and other user interface elements with a bold tag. In MAML, you would instead apply the <ui> element to identify the purpose of the text. MAML consists of a number of distinct content types, each of defines its own set of valid constituent elements. Examples of content types include conceptual, FAQ, glossary, procedural, troubleshooting, and tutorial.
There are a number of significant advantages to this approach. It enables authors to concentrate on writing good content without having to be concerned about formatting or how to achieve certain special presentational effects. It also ensures consistency in structure and presentation between Help topics, and makes it easier to manage, manipulate, and reuse the Help content using a content management system.
A variety of different types of active content is possible in Longhorn Help. These include:
Since the content is stored with semantic markup and no formatting, it needs to be transformed to a suitable presentational markup in order to be displayed on screen. This transformation takes place on the user's PC at viewing time, and actually happens in three stages:
"Longhorn" Help is designed for displaying user assistance of all kinds. Help for installed applications, drivers, peripherals, and for the operating system itself will be displayed in a common viewer called the Help Pane, which docks to the side of the desktop by default. As a result of sharing the same viewer, all types of Help will use the same standards for presentation, navigation and interaction. This is a welcome change from the current rather fragmented situation, where assistance on the operating system is provided by the Help and Support Center, and application Help is typically available from standalone HTML Help (.CHM) files.
"Longhorn" Help is highly task-orientedaccess to user assistance is always via an "assistance task," which provides a link to a Help topic. Each task has associated metadata, such as keywords and a description, and may show up in a variety of locations. For example, a task such as "How to create a strong password" might be included within a FAQs page in the "Help and Support Center" (which is still available as a safety net in "Longhorn")nothing surprising about that. However, it may also appear in a number of other locations, including within the actual UI for setting a password, or as the target of a general search within the file system. Thus, highly relevant and focused Help can be provided as, and when, people need it.
"Longhorn" Help is deployed on the user's PC as a compiled file with a .HELP extension. However, in contrast to WinHelp and HTML Help, the file is not compressed. The advantage of this approach is that it makes it possible to publish incremental updates to a Help system, thus freeing up Help from the product release cycle and enabling what Microsoft terms a "continuous publishing" cycle. Updates will normally be provided using a Help server, in a similar way to the current Windows Update model.
The preliminary web-based documentation published by Microsoft already provides a surprising level of detail. However, the information is subject to change, and is by no means completea number of important questions remain to be answered. Here are some of the issues that occurred to me after reading through it:
How should we migrate our existing content to Longhorn Help?
Due to the semantic nature of the MAML markup language, the conversion of legacy HTML-based content to Longhorn Help will be quite labor-intensive. Presumably third-party authoring tools will provide utilities for assisting with the migration process, but I don't see how the conversion could be automated to the extent that it was able to be, for example, for the conversion from WinHelp to HTML Help.
What will be the primary information access method?
Assuming that a user needs to find a specific a Help topic, what will be the primary mechanism for doing this? Will an author-designed index still be as important as it is now in online Help, or will the combination of richer metadata and more sophisticated searching make a manually created index redundant?
How will "Longhorn" Help cope with detailed reference-type topics?
The Help Pane is by default a narrow window that docks to side of the Windows desktop. This makes it rather unsuitable for displaying large amounts of information such as detailed text, complex graphics, or multi-column tables. It remains to be seen how Microsoft will address this issue, and whether they may need to provide an alternative viewer for such topics.
How much control will authors have over presentation?
As described in this article under the heading "Just In Time" transformation for presentation, style sheets are applied automatically by the Help engine at viewing time. It's not clear to me whether authors will be able to create and deploy their own style sheets, or whether a standard "look and feel" will be imposed on all Help topics.
What is the future role of WinHelp and HTML Help?
Microsoft have committed to ongoing support for both WinHelp and HTML Help in future operating systems, so presumably authors will have a choice when supporting "Longhorn" applications: migrate to the new Help standard, or stick with one of today's tried and tested formats. It will be interesting to see if enough software vendors buy in to the "Longhorn" Help approach to make the common Help experience a reality.
An advantage of using either HTML Help or WinHelp in "Longhorn" is that you can continue to ship the same Help files for all versions of Windows. By contrast, if you migrate to "Longhorn" Help but also need also to support earlier versions of Windows, then you'll need to create your Help in two different formats ("Longhorn" Help is not designed to run on Windows XP or earlier). In this situation, it would make sense to generate both these Help outputs from a single MAML-based source, transforming the content to HTML before compiling the HTML Help version.
What tools will there be for creating "Longhorn" Help?
Microsoft will make a "Longhorn" Help compiler publicly available, but history suggests that they will leave the job of designing, creating, and editing "Longhorn" Help content to third-party authoring tools. All of the major vendors have already pledged support for "Longhorn" Help. However, the shift to structured authoring raises the issue of how well the paradigm of each of today's tools is suited to semantic markup and a less "WYSIWYG" authoring environment.
"Longhorn" Help promises to be the most radically new and exciting Help format from Microsoft since the launch of the original WinHelp format. As Microsoft MVP Paul Neshamkin puts it:
"This is not a rewrite of the traditional Help we all have come to love/hate, but a whole rethinking of user assistance in the Windows environment."
However, it's worth noting that Shane McRoberts, Group Program Manager at Microsoft, cites the top two priorities on the user assistance escalation path as: a well-designed application UI, followed by assistance placed directly in the application UI.
Further details on "Longhorn" Help will be provided at WritersUA Conferences throughout 2005.
Matthew Ellison has 18 years experience as a user assistance professional in the software industry. He has been a popular speaker at WritersUA events throughout the world since 1997, and now runs his own independent UK-based training and consulting company specializing in online Help design and technology. Matthew holds a B.Sc. in Electronic Engineering and a Post-Graduate Certificate of Education from Bristol University in the UK.