While we are still in the early stages of web-based Help, many of us have started working with it and are building up a body of experience. It is useful to look at what we value in a web-based Help system. Our survey question asked respondents which of several features their web-based Help solution has. We limited the response to those who are currently supporting web-based applications.

Desired Web Help Features

As seen in the figure below, the response showed extremely high support for the traditional navigation components of Contents, Index, and Search. Over three-quarters of the respondents place these elements right at the top of the list. This may indicate that many early adopters are following the Windows Help model. They may be using a turnkey authoring tool from eHelp or Quadralay or creating custom components. Another likely factor is that the need for navigation components tends to increase with the power and complexity of a product. Web applications are just now evolving beyond the very operations involved in most mainstream e-commerce web sites. However, in the future we may see this reliance on navigation components decrease as more effective ways to guide the user to the appropriate goal are found.

Just half of the respondents are using context-sensitive Help at the page level. Linking specific Help topics to specific areas of the interface has been found to be a most effective form of user assistance delivery, but many of us still do not employ it. Even with client-based applications, context-sensitive Help is not as widely used as it should be. On the client side, this usually has to do with the lack of programming resources for adding Help links to the application code. The problem is exacerbated in the Web world because there is no standard API for streamlining the coding of Help links.

Support for field-level Help is minimal at 15%. This may be due in part to the difficulty in effectively employing field-level Help in a browser. But it may also reflect the trend in the Windows world away from What's This? Help. Many Help authors are doubtful of the effectiveness of this component because there is a high probability that the user will be unsure how or when to request it.

Only a small percentage of respondents (16%) are using database-driven content. This appears to a fairly low figure if you consider the likelihood that a high percentage of web application pages are database driven. This may suggest that user assistance developers are not receiving (or choosing not to use) the same technology used by the rest of the application development team. On the other hand, those 16% of Help developers are clearly embracing new techniques and technologies (ASP, SQL, etc.) that would not have been in their skill set four years ago.

Of those responding, %52 are using a separate custom browser window for hosting Help content. This requires attention to cross-browser compatibility and can consist of some code-wrangling. But, it makes it possible to more effectively integrate the Help content with the application. An implication here is that the other half of the Help authors are displaying Help within the same window as the application, as you find in Help on dot com sites like Yahoo, Monster, and Expedia.

Shortcut links from the Help to the app are used by a quarter of respondents. This can be an excellent method of directing the user to a specific portion of the application. It's also an area where implementation may be easier in the Web world than trying to accomplish the same effect in client-based apps.

Application Environment

The environment in which our web applications reside has a lot to do with how we build them. While the Web is largely based on open standards, it has been done in a way that still provides developers with the ability to extend and customize their software. As a result, the decisions we may make for an Internet-based application may be different from those made for apps on a corporate intranet or apps from a consortium tied together in an extranet. To explore this, we asked the respondents to identify the environments where their web-based applications reside.

As the following figure shows, two thirds of the applications live on the Web. This means a need for extensive browser compatibility testing and close adherence to W3C standards. It may also require implementing the W3C accessibility guidelines. Bandwidth limitations are a major factor in determining the architecture of the app.

Intranet applications are also very popular with 64% of respondent identifying that as their environment. Generally intranet applications are behind corporate firewalls and are designed based on a known set of guidelines. The use of proprietary extensions to web standards is very common. For example, an organization may have standardized on Internet Explorer to the exclusion of Netscape browsers. This can significantly simplify browser compatibility worries. It also makes possible the use of specially designed components, like search engines.

Extranet applications (23%) are a growing facet of the software world. Security issues loom large and will have an effect on how an application is designed. Help elements will likely need to be examined to make sure they create no unauthorized entrances to the network. Working with an extranet will also mean developing a design that is acceptable and compatible with the systems of partner organizations.

A third of the respondents support both Internet and intranet apps. For some of these developers, the Internet app may be completely different from the intranet app. For others, a single application is being designed for both environments. In the latter case, your development challenges increase as you try to deal with cross-browser compatibility, accessibility, proprietary extensions, security, etc.—all at once.