(My original introduction from 1997) Network computing promises great opportunities, but -- as usual -- new technologies also provide more rope for designers to hang themselves. Erika Kindlund is a usability engineer at JavaSoft and one of the few people in the world to work full-time on discovering how users interact with applets and how applet usability can be improved.
(Added 2007) This article was written in 1997 and refer to the Java technology of the time. The conclusions still hold today, even if you use another programming language: open in a new window without browser chrome if you offer true application functionality. For a continuously updated set of even newer guidelines, see our 2-day course on application usability with guidelines for all types of applications:
Essay by Erika Kindlund, JavaSoft
(JavaSoft affiliation was current in 1997 when this article was written. Kindlund was the User Research Manager for the QuickBooks Group at Intuit as of 2005.)
You visit the web site of a renowned economics institute to use an applet that calculates and graphs production yields. After meticulously entering your figures into the calculator form, you press the "calculate" button. The applet computes your production ratios and presents a graph inside a new view. As you examine these results, you remember a crucial figure you'd left out of the previous form. You reflexively press the "back" button on your browser -- and find yourself back at the institute's home page. Disoriented, you relaunch the applet: the form is empty, your data lost. Only after reentering all your calculations do you see the "Return to Form" button lurking beneath your freshly charted histogram.
The World Wide Web has emerged as a new application-delivery platform. In response, developers are offering users sophisticated Web-based Java applets that range from cyber shopping carts to complex tools for genome mapping. These applets give you application functionality without taking up space on your hard drive. But trailing behind the applet bounty are new usability questions. A major one, as this example shows, is how to make applet navigation seamless in the Web browser domain.
Java applets are programs you write in Java and integrate into your Web page. Although applets can provide functionality similar to traditional applications, the applet code need not be installed on the users' hard drive. Instead, the applets execute through Java-compatible Web browsers.
Unlike standard Web pages, which users simply visit and browse, applet-enhanced pages let the user manipulate applet components and dynamically interact with information. However, because the Web browser mediates users' interaction with applets, the users' browser navigation model can interfere with how they experience an applet. As applet complexity increases, user reliance on a browser's navigation tools can cause unexpected consequences.
The browser's buttons and menus let users follow links along nonlinear paths through pages, let-ting them go backward and forward sequentially, as well as providing history lists and bookmarks. The Web browser sustains the page metaphor, conveying boundaries such as top and bottom, previous and next. It is precisely this ability to "landmark" inter-action with virtual pages that makes the Web such a useful environment.
Useful as they are in traditional navigation, these browser tools can be a dead end if you rely on them to support user movement through dynamic applets. Thus, when you design with applets, you must either include applet navigation tools or accommodate those of the existing browser.
Several factors influence the relationship between browser navigation and applet navigation, including
- how many views an applet has,
- whether the applet has its own navigation buttons, and
- how the browser manages applet state information.
When applets incorporate large information do-mains, they begin to resemble complex desktop applications. In an applet, as in an application, you might have to move between different screens of in-formation that comprise the applet's domain. For example, in a single applet domain you might have a weather pattern simulation and reference material on different cloud formations. Each component would have its own view; to access both you must be able to navigate between the views. This is different than navigating between Web pages, because all applet code resides in the HTML on a single Web page and the browser's navigation tools navigate "between" pages.
Navigating between the applet views seems straightforward: simply create an applet with its own navigation buttons. Indeed, as Hal Shubin describes in his paper " Navigation in Web Applications ," providing specific buttons and tools for navigating within a Web application greatly reduces user confusion in these environments. However, including applet navigation buttons is not always enough to keep users moving smoothly.
Figure 1. A link on this page executes a Java applet for a server administration tool.
Figure 1 shows a Web page with a link that executes an applet for a server administration tool. After the browser loads the applet, it asks you for a login ID, as Figure 2 shows. After you log in, the applet behaves much like a desktop application. The tool has a tree structure menu, as Figure 3 shows, which lets you open items by double clicking, then access item options by tabbing. Figure 4 shows the options in this tool: you can access set-up, monitoring, or security options. Within these sections, you can further manipulate the applet to administer the parameters of your server, which may reside across the network somewhere.
Navigating within this applet seems reasonable, but it is not without hazards. As Figure 4 shows, there are actually two sets of navigation buttons: those of the applet and those of the browser.
At Javasoft, we conducted a usability study to see how users would man-age these two sets of buttons. The results clearly indicate that users' expectations and experience with Web browsers strongly influence their interaction with the applet. As in the travel applet scenario, users tended to rely on browser buttons to navigate through applet views, a preconception that results in extreme disorientation.
Because the applet is launched within the Web browser, users assumed that these different applet views were on different Web pages. They thus expected to navigate between them as such and repeatedly used the browser's "Back" button to try moving from the view in Figure 4 to the view in Figure 3. The button that would return them to the view in Figure 3 is actually labeled "Services"; when users selected the browser's "Back" button, they returned to the previous Web page (Figure 1).
Figure 2. Once the applet is launched, it acts much like a desktop application.
Depending on how your browser implements the Java Applet API, its "Back" and "Forward" buttons can command the applet to pause, by calling the stop() method, or play, by calling the start() method. Thus, when you select the "Back" button, you pause the applet and return to the previous Web page. If you then selected "Forward," you would restart the applet with the information saved. However, all browsers do not implement the Java API in the same way. In some browsers, the "Back" button rewinds the applet, calling the destroy() method, be-fore returning to the previous Web page. If you then selected "Forward," the browser would call init() method and start the applet over, erasing any information you may have already entered.
In our study, when users selected the browser's "Back" button, the browser called the applet's stop() method and returned the user to the Web page in Figure 1. Confused, users reselected the "Start Administration Applet" button on the initial page instead of returning to their place inside the applet by pressing "Forward." This relaunched the applet, returning users to the login screen. Some logged into the applet as many as four times during the two-hour study.
Confusion is bad. However, if the Web browser happens to call the destroy() and init() methods when users select "Back" and "Forward," using this applet could cause in-formation loss. With browsers that implement Java this way, pressing the browser's "Back" button could call the destroy() method before returning to the screen shown in Figure 1, and all the applet's state information would be deleted. Therefore, when users -- attempting to recover from unexpectedly returning to this screen -- select the browser's "Forward" button to get back to their previous applet view, they will actually return to the applet's initial state as shown in Figure 2. This behavior completely contradicts users' assumptions about how Web browsers work, confuses them, and causes an unsuccessful interaction.
How can we create applets that behave in a manner consistent with user beliefs about Web browser navigation? We redesigned our test applet with this question in mind. Because users assume that the browser navigation buttons could be used to navigate the applet views, we designed an environment that supports the Web browser model while promoting a distinct applet identity. We redesigned the applet so that only the views in Figures 2 and 3 would exist within the Web browser. When the user selected an item from Figure 3's tree menu, the applet would spawn a separate window outside the browser that displayed views of the individual services, as shown in Figure 5. This window contains all the navigation elements relevant to navigating within a service. A user could thus navigate from one service to another by selecting a new item from the tree menu, which remained in view behind the new services window, as Figure 5 shows.
Figure 3. The server administration tool has a tree structure menu that lets users open items by doubling-clicking.
Figure 4. The tools offers users several options for setup, monitoring, and security. It also introduces a new set of navigation buttons, shown beneath the Java Web Server banner. If users operate the applet with these buttons, all is well. However, if they re-flexively select the browser buttons, navigation can become confusing, if not disastrous.
Figure 5. The revised applet spawns separate windows of individual services that are clearly distinct from the browser.
In subsequent usability studies, we found that the new navigation model successfully accommodated users' beliefs about Web browser navigation while letting them seamlessly interact with the applet. Because the additional applet views were now in their own window, users no longer relied on the "page" model to navigate between them. Instead of deferring to the browser's navigation buttons, the users quickly adapted to the applet's navigation methods.
Our integrated navigation model encourages appropriate interaction with the applet and behaves in a way that matches users' cognitive model of browser navigation. The new design encourages users to only use the browser's "Back" and "Forward" button for interpage navigation. Thus, users whose browsers call the destroy() method when the "Back" button is pressed are less likely to accidentally lose state information during the more data rich intra-applet navigation.
As we deploy increasingly complex applets on the Web, we must establish guidelines for applet interactions. Users stumble upon applets while browsing. This context must be incorporated into our applet design so that we can give users appropriate feedback.
If a user can perceive an applet as having multiple pages, you should consider how the browser's navigation model will affect applet interaction. In complex applets, users must be able to distinguish between the browser and applet domains to successfully navigate between the two. Don't assume that applets with their own navigation buttons will make the applet interaction successful. Multiple applet views require a navigation context that distinguishes applet from browser navigation. Launching multiple applet views outside the browser is one effective approach that promotes navigation model integration and a distinct applet identity.
You should also be aware that you have no control over the browsers people use. To minimize negative applet behavior, you should plan ahead for inconsistencies between browsers.
At the time of writing this essay in 1997, Erika Kindlund was a usability engineer at Sun Microsystems, JavaSoft Division. Kindlund worked previously in human factors engineering at IBM and as a research scientist for the Interactive Multimedia Group at Cornell University. As of 2005, Kindlund was the User Research Manager for the QuickBooks Group at Intuit.