Web-based applications can be divided into two rough categories:
- Functionality Apps
- Independent mini-applications in their own right with state transitions and multiple views (e.g., a tabbed dialog). Functionality applets often manipulate "real-world" data that exists separately from the webpage (e.g., allowing customers to manage their checking accounts, inventory control, server administration).
- Content Apps
- Tightly integrated with the content of a Web page. Examples include site navigation controls (e.g., an active sitemap, outline flippers to expand and contract a hierarchical listing), active content (e.g., a model of an engine that can be rotated, animated, and otherwise manipulated in place), and minor functions (e.g., a currency converter). Typically, running a content applet has no results other than changing the appearance of the current webpage.
Content applets should be displayed in a browser together with the Web page they belong to; functionality applets should display in a new, non-browser window without any Web navigation controls.
If functionality applets are displayed in a browser window, then users will invariably confuse applet interactions with browser interactions. Most seriously, users will frequently
click the browser's
button when they want to undo an action in the applet or return to a prior state or view
. Of course, going
in the browser takes the user to the previous
page and kills the applet.
The problem is that the hypertext navigation metaphor is too strong as long as the user is within a browser window. Users simply cannot abstract away from using the browser's commands to navigate, even when they are "supposed" to navigate within the applet. The only solution is to open the applet in its own window without any browser controls. Once the applet appears in another window, users stop thinking "Web" and start interacting with the applet on its own terms.
In the long term, the solution to this problem is to eliminate browsers and move to a completely integrated navigation system that unifies navigation between system states and information objects and maintains a single navigation interface for all user actions, no matter whether they are on or off the Web. After all, users should not have to care whether they are dealing with HTML or another data type or whether they connect to the Internet, to an intranet, or to local content on their own harddisk.
Functionality applets may include hypertext links back to the Web . Typical examples include help pages and an airline reservation system that allows users to read more about different types of aircraft. Such hypertext links should take the user out of the functionality applet and back to the Web browser (while the functionality applet remains visible in its separate window).
Erika Kindlund from JavaSoft provides more detail about the design of a particular functionality applet: the administration interface for the Java Web Server. Her test data clearly shows the need to open functionality applications in a new window . Server administration is clearly a "large" applet with its own navigation, and serious usability problems were found in an early design that kept the applet on the browser page.
Other Applet Usability Issues
Most issues in applet usability are no different from traditional rules for user interface design. A functionality applet that spawns its own window(s) should follow application design guidelines, and a content applet that stays on the page should follow Web design guidelines and principles for good information design.
Progress Indicator Needed When Connecting Back to Server
Applets that communicate back to the server should show a progress indicator while doing so. Progress indicators (often shown as percent-done bars ) are necessary in any user interface for any operation that has slow response times (more than 10 seconds). Applets that connect back to the server will often experience highly variable delays due to the weakness of the Internet. It is thus doubly important for the progress indicator to show the actual progress of the operation and its expected duration. For example, the progress indicator could show the proportion of a database that has been searched or the steps in a sequence that have been completed (while avoiding system-oriented terminology). Such progress indications may require a trickle of info from the server to the applet as it is servicing the request.
Applets should have a cancel button to allow the user to interrupt any slow operations. Interruptability is particularly needed for any server connections.
In principle, applets should follow current user interface standards, so there may unfortunately be cases where double-clicks need to be supported at this time. In the future, however, double-click must die since it causes novice users great difficulties and since it conflicts with the single-click interaction style of the Web. The main reason for double-click is to allow two operations to be overloaded onto a single-button mouse. Designers of more recent multi-button GUIs have faithfully duplicated a weaknesses that was made necessary by limitations of an early single-button GUI: let's do better in the future. Content applets should be particularly wary of double-click since people will think of them as single-click Web content. (Former Apple human evangelist Bruce Tognazzini provides further details about how newer window systems copied acknowledged weaknesses of the Mac: see his book Tog on Software Design .)