by Matthew Ellison
Digitext, a UK-based consultancy specializing in online information, has recently conducted two different usability tests, each of which sheds new light on the way in which people respond to secondary windows in online Help.
The overall conclusions from the two tests were:
- There is little reason to assign specific types of topic to different secondary windows.
- It can be helpful to use a secondary window for a link to a sub-procedure or layer of additional detail, as long as the current window remains visible on screen when the new window appears.
This article explains how the tests led to these findings.
Brief History of Secondary Windows
The technique of using multiple windows has been employed in Windows Help since the days of WinHelp 3.1. In these early Help systems, procedural topics commonly appeared within a narrow secondary window positioned on the right-hand side of the screen so as to leave as much as possible of the underlying application in view. Microsoft went on to establish a very clear windowing design model in their Help for Windows 95 by displaying each identifiable type of information (concept, feature, procedure, error response, etc.) within a different secondary window. WinHelp 4, the Help format for Windows 95,also enabled Help authors for the first time to add a button bar to a secondary window. The vast majority of Help authors responded to this new functionality and followed Microsoft’s lead, with the result that a Help system without secondary windows became the exception rather than the rule.
What are Secondary Windows Used For?
Help authors have used secondary windows for a variety of purposes in online Help:
- To display context-sensitive Help for an application within a relatively small window that enables the user to see most of the underlying application.
- To provide an immediate visual clue as to the type of information being displayed (in the case of a Help system that uses a different size and position of window for each information type).
- To enable two Help topics to be displayed simultaneously, each within a separate window.
These apparent advantages of secondary windows would seem to imply that the decline in their use would have a negative impact on users’ experience of online Help. It was with this in mind that Digitext decided to investigate the way in which users actually respond to secondary windows. Digitext wanted to find out whether reducing the use of secondary windows in HTML-based Help would cause any problems.
The First Usability Test
The first usability test was actually designed with the general aim of comparing the ease of navigation of the three Help user interfaces: WinHelp 4, Microsoft HTML Help, and standard HTML. One of the specific objectives relating to secondary windows was to answer the question: How does the WinHelp 4 model of using separate windows for different information types affect users’ ability to navigate a Help system successfully?
To test this, we created three different versions of the Help file for AOL 4.0, each with the same information content:
- The first version was implemented as a WinHelp file, and used a secondary window for procedure topics, and the main window for all other types of topic.
- The second version was an HTML Help file that used the main (tripane) window for all topics.
- And the third version was written as plain HTML and displayed all topics in the same browser window.
Participants in the tests were asked to complete a series of tasks that involved navigating through the Help systems. They used only the Help files, and did not use the actual AOL software, so we were not able to test the potential benefits of using secondary windows for displaying context-sensitive topics on top of the application.
The test observations revealed an important usability problem relating to the use of secondary windows. We called it “Breaking the Back button.” By this, we meant that when users navigated from a topic in the main window to a procedure topic in the secondary window, they were then unable to use the Back button to return to the previous topic. Instead, the Back button returned them to the last procedure topic displayed within the secondary window. Users were seen to rely heavily on the Back button when finding their way around the unfamiliar Help structure, and any apparent inconsistency in the behavior of this button caused frustration and undermined confidence in the Help.
Users of the WinHelp version were asked at the end of the test why some of the topics had appeared in a separate window. Not one of the nine participants was able to state correctly the convention of procedure topics (and no other types of topic) always appearing in a secondary window.
One participant had assumed that, when the two Help windows were displayed simultaneously, this meant that the information in these two windows was somehow related. In fact, a user displaying a procedure topic, and then navigating to a (possibly unrelated) topic of a different type causes the simultaneous display of two windows. In this case, an assumed relationship between the topics in the two windows is potentially misleading.
We were drawn towards the conclusion that, leaving context-sensitive Help aside, secondary windows offered little benefit to the user. Indeed, there was some evidence that the use of multiple windows caused confusion and led to inconsistencies in the navigational behavior of the Help system.
HTML Help system showing single window interface
WinHelp system showing sub-procedure in secondary window
Click on the screens for a full-sized image
The Second Usability Test
Following on from this research, a second usability test was devised with the objective of establishing whether secondary windows can, in special circumstances, positively assist a user to navigate successfully between topics. Again, three different versions of the same Help content were tested, only one of which used multiple windows.
This time, the test included a specially designed scenario that involved the participants working through a procedure topic from beginning to end. At the midpoint of the procedure the participants were required to link to a sub-procedure that provided detailed instructions for one of the steps in the main procedure (see Figure 2). In the case of the Help system that used multiple windows, the sub-procedure was displayed in a separate secondary window beside the main procedure window.
We observed that users of this Help system were able successfully to resume at the correct place within the main procedure after completing the sub-procedure. Because the main procedure had remained on screen, users were able to simply close down the secondary window for the sub-procedure.
Users of the other two Help systems, by contrast, experienced greater difficulty. They had to remember how to get back to the main procedure after completing the sub-procedure, and surprisingly few of them thought of using the Back button. The fact that they had been forced to leave the main procedure before completing it caused them significant usability problems and slowed up their completion of the overall task.
In conducting these two tests, Digitext set out to investigate how the discretionary use of secondary windows might contribute to the overall goal of easy-to-use Help systems. The overall conclusion is that there is little reason to assign specific types of topic to different secondary windows. However, it can be helpful to use a secondary window for a link to a sub-procedure or layer of additional detail, as long as the current window remains visible on screen when the new window appears. In this case, the two windows show a valid relationship between the two topics, and the user is able easily to return to the main topic after completing the sub-procedure.