Implementing a Web-based Help System

Users of software applications have come to expect online, context-sensitive help to assist them with operation of the software. A Web-based help system should equal or better the functionality and performance of existing help systems. The approach taken in this paper is to examine expectations of help system functionality, and propose a method of implementing those features into a Web environment.

Expectations of Functionality

The functionality expected of a Web-based Help system will include the following.

This functionality requires changes or extensions to existing technology:

Invocation

Help should be accessible from an on-screen button, keystroke (usually F1), and right mouse click. Current browsers will permit the launching of help through an on-screen button, but not through a keystroke or right mouse click. To achieve this functionality in Web-based Help, browsers will require some enhancement, either through software changes or plug-in.

Context-Sensitivity

Most software applications comprise text entry fields, selection lists, option buttons, and push buttons. Web-based applications use similar (but often less sophisticated) controls within forms, encoded through standard HTML. HTML controls already hold a name attribute, although this is unique to the form, not to the application (which may be a collection of forms). If a collection of help pages is related to a form, then the name attribute could be used as the context hook. If a collection of help pages were related to the application (or collection of forms), another attribute would have to be added to the control tags.

Near Instantaneous Display

When a user requests help, there should be minimal delay in response. This is more critical for What's This style help. For Internet applications over PSTN, such response is not possible, as the delay between HTTP Request and commencement of rendering will always be unacceptably slow. It is therefore desirable that help text be downloaded with the form page itself, so that a help panel could be retrieved locally.

Display in Separate Window or Frame

Most browsers already support hypertext links to pages in a separate window. On older hardware platforms, this puts a very high load on system resources and performance, but is becoming less of a problem on fast systems. For What's This style help, however, where immediate response is required, it is still unacceptably slow on the fastest of systems. Improvements in browser design will no doubt reduce this as an issue over time, but changes in browser software design in this area are highly desirable.

An emerging option for help systems is for help to be displayed in the same window as the application, with content changing as the user moves through a form. This functionality could easily be achieved by displaying help in a separate frame within the same window. The window should be able to be displayed 'Always on Top', to permit reading of content while continuing with data entry.

There is no reason why existing HTML-based Help technologies, such as NetHelp and HTML Help, should not still be able to be used within Web-based help.

Author-Defined Attributes

A pop-up style of content display for Web-based Help would be highly desirable, particularly for What's This style help. Such pop-ups must be capable of rendering HTML content, thus allowing authors to define text and window attributes, and allowing graphical content. The only platform-independent method of displaying pop-ups within HTML currently is through JavaScript. The limitations of this approach include the complicated coding involved, the lack of control over text attributes, and the inability to display graphics.

Implementing Required Features: Browser Changes

The following additions to browser feature sets are required:

  • Ability for the browser to detect an F1 keystroke event and determine the name of the form control that holds focus, and to execute a help URL request based on the form control attributes. The addition of a right mouse button command to execute a help request in a similar way would also be required.
  • Ability to display a child window that renders HTML content. The child window should not be another instance of the browser application, but a small, low overhead subset. As a guide, the window should be able to load within one second of request.
  • Ability for the browser to be able to display a pop-up style window, which unloads when it loses focus. Pop-up windows should be positioned relative to the cursor position on the screen.
  • Ability to process a URL request to retrieve content from a series of paired tags at the end of a page's HTML code. This may be possible to achieve through existing Dynamic HTML used in conjunction with the pop-up window suggested above.

Implementing Required Features: HTML Changes

  • Changes to HTML would only be required for What's This style help. In order to display What's This help without delay, the help text would be downloaded with the page itself. This may be achieved by including text within <HELP> paired tags, either inside or outside the <HTML> tags. The <HELP> content would continue to be downloaded after the form page itself was rendered.
  • Within <HELP>, further paired XML tags that match the name or context of each form object would themselves contain the help panel content. For example, a form input object of <INPUT TYPE='TEXT' NAME='CUSTOMER_NAME'> would have its help text stored within the <CUSTOMER_NAME> pair inside <HELP>.
  • Form objects would require an additional event, such as onHelp. In a similar manner to the existing onClick event, onHelp would allow execution of a URL. The onHelp event would be invoked by an F1 keystroke or selection of the Help option from the right mouse button pop-up menu. (Separate events for F1 and right mouse button might be appropriate; for example, onHelp and onWhat.)