CHI 97 Electronic Publications: Design Briefings
Simplified Applications for Network Computers
Don Gentner, Frank Ludolph, Chris Ryan
Sun Microsystems, Inc.
2550 Garcia Avenue, CUP01-102
Mountain View, CA 94043-1100 USA
email@example.com, +1 408 343-1957
firstname.lastname@example.org, +1 408 343-1975
email@example.com, +1 408 343-1966
This paper describes the design of HotJava Views, a user environment and suite of applications for a Network Computer. A Network Computer differs from the common Personal Computer in that it has no permanent local storage, but instead obtains its software and data as needed over the network from a central server. We have abandoned some characteristic features of current GUI interfaces, such as the desktop metaphor, file systems, and the distinction between applications and documents. Our design principles are focused on simplicity, efficiency of operation, clarity of the interaction model, and tight integration between applications.
Calendar, email, HotJava Views, human interface design, Java, minimalist, Network Computer, NC, simplicity, Web.
© Copyright ACM 1997
Over the past fifteen years, personal computers have continually become more powerful and complex. Although these changes have often been in response to the needs and requests of users, the result has been systems and software that are difficult to learn, use, understand, and maintain. Most people use only a small fraction of the power and functionality of current "personal" computer systems.
The Network Computer (NC) represents a different approach to desktop computers. It is based on the Java language and Web protocols, and has no permanent local storage. The operating system, applications, and data are centrally stored and loaded over the network as needed. Unlike terminals connected to a shared central computer, however, much of the application processing takes place on the local NC client, and therefore NCs do not have the scaling problems of X-Terminals where all the processing occurs on the central computer and bulky screen-display commands tend to clog the network. The arrival of the NC gives us a chance to rethink the basic design of computer applications.
The great promise of Network Computers is that they will reduce the burden of system administration for large networks of personal computers. Because all programs and data are centrally stored, updating software and backing up user files is a simple matter for the support staff. And if one of the NCs should have a hardware failure, it can simply be unplugged and replaced by a spare machine. Because they do not have any permanent storage, turning on the power switch is the only operation required to install new versions of the software on the client NC--the same procedure typically used every morning when the NC is started.
Another important advantage of NCs is that, because all the data is centrally stored, it makes no difference which client machine a user logs in from. The user can access their data, programs, and normal environment from any machine that is connected to the network.
Although the central storage of programs and data has many important advantages, it also places serious constraints on NCs. In particular, all information on the client NC is lost every time the power is turned off, so the operating system, applications, and data must be downloaded from the network the first time they are needed after the power is turned on. Thus an NC would probably not be a good choice for someone, such as a graphic designer, who uses a complex operating system, a variety of large applications, or large data files. NCs and Personal Computers (PCs) have separate niches in the cyber-environment.
User Environment and Application Suite for NCs
Sun Microsystems is producing an NC based on the Java language and JavaOS. The initial prototype machines were shipped with only the operating system and the HotJava Browser, with the intention that customers would create their business applications as Web-based applications running in the browser. But many potential customers also expressed an interest in a set of simple applications for employee communication and scheduling. A group of human interface designers at Sun were asked to develop such a set of simple applications. That project has evolved into a product called HotJava Views, and the design of the human interface for HotJava Views is the topic of this paper.
The HotJava Views user environment includes:
The Common Desktop Environment (CDE) shipped with Sun's Solaris operating system already includes a suite of personal applications including electronic mail and a calendar application, but rather than simply porting our existing applications to the Java language we decided to take advantage of this opportunity to rethink these common computer applications.
- Selector--the application switch
- MailView--electronic mail
- CalendarView--appointment calendar
- NameView--a directory of people in the organization
- InfoView--Web browser for viewing intranet or Internet documents.
The Transaction Worker
The target users for HotJava Views are what we refer to as "transaction workers". Examples of transaction workers are order takers for a mail-order catalog business, insurance agents, or customer support personnel at a bank's telephone call center. They use computers for a limited set of tasks. Typically, their primary-task applications access records in a central database, and were developed by an in-house MIS department. In addition to using their primary-task applications, transaction workers are members of the organization, and need to communicate with other workers and management, attend meetings and access company documents such as benefit plans and policy manuals. Currently these transaction workers are using 3270 terminals or PCs connected to a mainframe computer, but they are likely candidates for NCs, which can offer more functionality than terminals with simpler client administration and simpler user environment than PCs.
The HotJava Views user environment and application suite are based on a set of general design principles. Although we group these principles together in this paper, in fact they evolved somewhat haphazardly in the course of designing the individual applications. Some principles were declared in advance; others were noticed only after they had been around for some time. As we recognized emerging principles during the design process, they were fed back to structure the overall design.
Early on, we knew from the marketing requirements that we would have a small, fixed set of applications for the first release. We would provide mail, calendar, a directory of people, and a Web browser. There would also be a small set of applications for the user's primary tasks, developed in-house by the customer's MIS department. We needed a way for the user to access these applications and decided to simplify the model by letting the user view only one application at a time.
We were inspired by the 3270 terminal applications that our transaction workers often use now. These terminal applications usually have one function per screen and the users can quickly switch between screens when they want to access the different functions. In interviews with several potential users, we saw a similar behavior on PCs. They often kept a set of documents and applications at the side of the screen and operated on them one-at-a-time in sequence. By assigning each application (mail, calendar, etc.) to a separate screen and letting the user switch between screens, we could give the user easy access to the functions they needed without the clutter of overlapping application windows. We considered a model based on tabbed cards, but tabs with text labels look best at the top of the screen and vertical space was at a greater premium than horizontal space on an NC monitor. Instead, we quickly settled on the Selector with a set of graphic icons along the left side, one for each screen (see Figure 1). Rather than digging for a buried window, the user clicks on an icon to switch between screens. The state of a screen is saved when it is switched out and restored when it is switched back in. Because these applications are effectively always running, the user does not have to be concerned with starting and stopping applications.
Our switched screens are also reminiscent of the Switcher in earlier versions of the Macintosh operating system, which allowed users to switch sequentially through several applications resident in memory. The two designs are similar in that the user can see and interact with only one application at a time. But the Macintosh Switcher did not provide the random access to applications that is provided by the Selector along the left hand side of the screen. A second difference is that although the HotJava Views user can use only one main application at a time, the applications are tightly integrated and the user can access "task-specific" versions of other applications in windows that appear in front of the main application screen (see the later section on Application Integration).
Figure 1. A screen shot showing the HotJava Views interface. The user switches between different application screens by clicking on one of the icons in the switch along the left side of the screen. This figure shows the MailView. The current mail message contains a calendar appointment as an attachment. Clicking on the button under the pointer will schedule the appointment in the user's calendar (see Figure 4).
Keep It Simple
Another early decision was to simplify the typical PC applications. We had several motivations. First, today's PC applications have generally become so bloated with features that most people use only a small portion of their functionality. In particular, our users would be focused primarily on their "transactions" and they would not need all the "power user" functions in applications such as electronic mail. Second, simpler applications would have reduced user training costs. Third, we were on a tight schedule and simple programs would be quicker to design, program, test and document. Finally, to improve response time and reduce network traffic, the applications should be small enough to be quickly loaded over the network and to fit easily in the limited memory size of an NC.
For our first attempt to simplify applications, we focused on electronic mail. We started with the mail program from the UNIX Common Desktop Environment (CDE) and made a list of all its functions. The CDE mail application already has fewer functions than the typical PC mail application, but we forged ahead and eliminated any function, preference or control that did not seem essential to the modest use of electronic mail that we expected from our target users, the transaction workers. We ended up throwing out about half of the functions in CDE mail and very few of those have crept back in as the design matured.
For example, we eliminated a whole set of functions for moving and copying messages to mailboxes, opening and closing mailboxes, and creating new mailboxes. Instead, because we expect transaction workers will be light users of email, we provided them with just a single folder for storing messages that they want to save and another folder where copies of outgoing messages are automatically saved. We also provided a set of commands for sorting and searching these mail folders, which could become moderately large. The net effect was that 21 mailbox related commands in CDE mail were reduced to 7 commands in HotJava Views mail. Similar reductions were made to other areas of functionality.
Our early decision to eliminate mail attachments was more problematic. Our users would not have access to a file system or the typical PC applications needed to view attachments. Thus mail attachments would be of limited use and they were excluded from early designs. However, feedback from customers and marketing, along with the realization that our users would be getting mail that might contain attachments from users of other email systems, led us to build in limited support for mail attachments. Our users can view and print some types of attachments in email from others, and they can also create new messages with calendar appointments and Web links as attachments.
We are big fans of placing the most commonly used functions on a button bar where they are visible and can be more easily accessed than through the menus, but again we wanted a simple button bar, not a vast button bazaar. So our next step was to try to fit our most important functions onto the button bar. To our surprise, we had done such a thorough job at reducing non-critical functions in email, that all the remaining functions fit on a single button bar (see Figure 1). Buttons on the button bar are identified only by a graphic, but if the user's pointer lingers over a button for more than a fraction of a second, a text label, called a Button Tag, appears below the button to describe its function, similar to the popup labels found in many applications today. Having placed all the functions on the button bar, we were suddenly confronted with the unthinkable: If all the functions fit on the button bar, did we need menus at all?
The pull-down menus of a typical GUI application arrange the application's functions into a hierarchy. Counting the menu names as one level, this hierarchy is often three and occasionally four levels deep. Menus allow the user to access a large number of functions without permanently dedicating screen real estate for each of the functions. This advantage was especially important in computers with small screens, such as the early Macintosh computers. The negative aspect of menus is that the list of functions is hidden most of the time and it can be difficult or tedious to manipulate the menus. Many users show a preference for using buttons when they are available in the interface. As typical computer screens have become larger, more and more of the menu functionality has been duplicated in tool bars, palettes, floating windows and modeless dialogs, which keep the functions conveniently at hand. The MailView interface carries this trend to the extreme. By eliminating menus entirely and putting all the functionality directly in the main interface in the button bar, we keep the functionality visible and easy to access.
Having ruthlessly simplified the mail application and eliminated menus, we were eager to know whether this approach would work with our other applications. When examining the CDE calendar, however, we did not find a large number of functions in the application menus that could easily be eliminated. So it was clear that the remaining menu functions would not fit into a reasonable button bar. Instead we took a different approach to simplification, and converted some of the menu operations into direct manipulation operations in the screen display. In the CDE calendar (see Figure 2), the users are provided with both graphical and textual views of their weekly appointments, and they use a separate window to create, edit or delete an appointment. We chose to combine all the information into a single graphical view of the week's appointments that could be directly edited, as shown in Figure 3. Many of the functions that had been available from the menus were thus converted into direct manipulation of the appointment's graphical representation on the calendar. For example, to create a new appointment, the user simply clicks in the appropriate time slot and types in some text. The starting or ending time of the appointment can be changed by dragging the top or bottom border of the appointment.
Another technique that we used was to move functions from the main application menus to a place associated with their use. For example, the CDE calendar and HotJava Views calendar provide a list of other people's calendars that you can also view. In CDE, both the list of other people and the facility for editing that list were in the main application menus. In CalendarView, we put the name of the current calendar's owner at the upper left of the calendar and made it a popup menu, so that clicking on the button offers a choice of other people's calendars to view. The last item on the option list lets the user edit the list. This is another example of moving functionality from the main application menus to a place where it is more directly relevant.
The net result of these simplifications was that we were also able to eliminate the application menus from the CalendarView screen. In fact, there are no menu bars in any of the HotJava Views screens.
Figure 2. The CDE calendar application lists appointments in a textual form and also has a graphical representation of the week.
Although our applications are simpler than typical PC applications, we wanted to improve the usability of the system by tightly integrating the applications so that they could easily be used together. At first we planned to use drag-and-drop as the primary technique for application integration. For example, an address from NameView could be dragged and dropped onto the "To:" field of an email message. We soon realized, however, that there were several serious problems with drag-and-drop in our environment. First, how could we drag objects from one application to another, when only one application was displayed at a time? Second, many people find drag-and-drop difficult or slow, so in any event we would need to provide an alternative for keyboard-only operation. Such alternatives are normally made available from the menus, which we wanted to eliminate. But the final problem was the most definitive: HotJava Views would be shipping with the first version of JavaOS, which did not yet have support for drag-and-drop.
With drag-and-drop no longer a contender as the mechanism for application integration, we looked into the possibility of using buttons in the button bar. But what should happen when the user pressed such a button? We considered having the button cause a switch to the other application, but that would be disruptive. We also considered having the button bring up the other application in a window above the current application, but that violated our "rule" about having only one application visible at a time and led us down the path toward the standard overlapping window model. Finally, we developed a model in which a button in one application could display a "task-specific version" of another application. These task-specific views have limited functionality and thus keep the focus centered in the current screen. This turned out to be a very fruitful approach. We will explain the mechanism with an example.
Our user has received an email message announcing an upcoming meeting, and the message contains a calendar appointment as an attachment. See Figure 1, where the appointment attachment can be seen as an icon in the upper left corner of the message. When the user clicks the "Schedule Appointment in Calendar" button in the button bar, a task-specific version of the CalendarView is displayed in a window in front of MailView, as shown in Figure 4. The task-specific calendar shows the day of the appointment, with the new appointment scheduled and selected (selection is indicated by a red border not visible in the figure). The standard facilities for editing, printing, or deleting the appointment are available, but many of the other calendar functions are missing in this task-specific application. For example, it is not possible to change to a month view or go to another day.
Figure 3. The CalendarView. New appointments are created by clicking at the desired time and typing in text for the appointment, and then change the times by dragging the top and bottom borders of an appointment. Appointments containing an envelope icon have an associated email message.
When the user later switches to CalendarView, they will see the new appointment with a small envelope icon in the lower right corner of the appointment (see the first Thursday appointment in Figure 3). The envelope icon serves as a reminder that this appointment was scheduled from the mail application and provides another example of application integration. If the user wishes to see the original message, perhaps to get more information about the meeting, they can click on the envelope icon and the original message is displayed in a task-specific mail window in front of the calendar, as shown in Figure 5.
Although these floating windows, shown in Figures 4 and 5, may appear to be similar to the standard overlapping windows of today's GUI interfaces, they are fundamentally different. The main application screen (for example, the mail viewer screen in Figure 4) always remains as the background and cannot be resized. The task-specific application window (for example, the calendar in Figure 4) can be moved and resized, but always floats in front of the main application screen. The user can move the keyboard focus between the task-specific window and the screen, interact with the controls in either place, and even cause additional task-specific windows to appear when other buttons are pressed, but these windows always remain in front of the main application screen. Although the task-specific application window is non-modal and can be moved out of the way, the user will typically treat it as a dialog. That is, when the user schedules an appointment from the mail screen, the task-specific calendar window is posted just for confirmation, and we expect the user to close the window almost immediately.
Figure 4. When the user schedules an appointment from the current mail message, this dialog is posted to confirm the appointment. The window is a "task-specific" version of CalendarView with limited functionality.
Figure 5. Viewing the message associated with an appointment.
PASSING OF THE OLD ORDER
Having given a flavor of the interface for our applications, we'll now describe the basic principles that we've followed and how they differ from the principles found in typical PC graphical user interfaces. First, we will discuss some common principles that we are not using.
The Desktop Metaphor
The desktop metaphor, with its overlapping windows, folders, documents and trash can, has been the basis for most graphical computer interfaces. As the Macintosh Human Interface Guidelines state, "The desktop is the primary metaphor for the Macintosh interface." But a careful examination of the figures in this article will show that the desktop metaphor has been banished. The static desktop has been replaced by active objects. Only one application screen is visible at a time. Views replace each other, rather than appearing as overlapping pieces of paper on a desktop. Although task-specific application windows can overlap the main application screen and each other, they are temporary, second-class citizens in this world.
Our user never interacts with documents, folders, filing cabinets, or trash cans. One of our strategies for simplifying the interface is to minimize metaphors with objects in the physical world and develop models that are closely attuned to the computer-based activity. A metaphor to another realm always has a tendency to bring along irrelevant baggage. [3, 4, 5] Of course, we are not completely free of metaphor. Our buttons have graphics that refer to envelopes, pencils, trash cans, and other objects in the real world. The important difference is that we do not use metaphorical actions. For example, to delete an object in a traditional GUI interface, the user physically drags the object with the mouse pointer and drops in over the trash can. In our interface, the user selects the object and clicks a Delete button.
Distinction Between Application and Document
PC applications make a strong distinction between applications and documents, analogous to the computer science distinction between program and data. Users can separately manipulate applications and documents, for example with a file manager. The basic components of HotJava Views, however, are more like computer science "objects" with intertwined methods and data. Our applications act as viewers onto the data, and our users never interact with applications and documents separately. For example, they never see a calendar application that is not viewing someone's appointments, and they never encounter a calendar data file outside of the calendar application (or inside it, for that matter).
File System and File Manager
The lack of a distinction between applications and documents is closely related to the lack of a file system representation and a file manager in our interface. HotJava Views is essentially a set of information appliances that provide the only way to view data. The user deals with information objects, such as email messages or calendar appointments, rather than with files and directory hierarchies. These information objects may be represented as files or as database records on the central server, but that is of no concern to our user. The only file manager-like functionality that our users need is a way to choose among a relatively small, fixed set of application screens, and this is provided by the Selector on the left side of the screen. The installation and administration of the applications and data files is handled on the central servers by a system administrator. The end user does not have to deal with file systems.
Double-Click to Open
The basic interaction model in PC graphical interfaces is to click on the icon representing an object to select it, and then choose an action on the selected object from a menu. Frequent use of menus can be a hassle and therefore a shortcut was added to the model: single-click to select, double-click to select and perform the default action. For most objects, such as documents, the default action is to open or view the object, and thus double-clicking on the object usually selects it and opens it.
In part because we do not distinguish between applications and documents, our users generally do not have a variety of operations that they could meaningfully perform on objects without first viewing them. Therefore we have yoked selection to viewing. Single-clicking an object selects it and displays it.
A NEW APPROACH
Although we did not start with the intention of developing a distinctive look and feel, our early decision to switch between single-application screens and our desire for simple, tightly integrated applications, led naturally to an interaction model that is somewhat different from the model in the typical PC environment.
Our basic model is that a single-click selects an object and displays it. In the HotJava Views interface, shown in Figure 1, a single-click on one of the icons in the Selector on the left displays the corresponding object in the remainder of the screen. The selection is indicated by a rectangular border around the selected icon. This model is illustrated again in Figure 1 where the "In Box" is selected at the top of the mail application and its contents are displayed below. Within the In Box, a message header is selected from a scrolling list and the body of the message is shown in the lower part of the display.
We usually allow only single selection from collections of objects. In most cases that is the only reasonable choice. Selecting more than one application in the switch or more than one mailbox within the mail screen would not fit with our overall model of a single main application screen. In some cases, multiple selection might be reasonable. For example, the user might want to select several message headers and delete the messages with a single operation. We explored using multiple selection in these cases. However, in the interests of keeping the model simple and consistent, we have decided to restrict the design to single selection in almost all cases.
Web Look and Feel
You might have noticed that the graphic design in HotJava Views is somewhat reminiscent of the World Wide Web. This is intentional. We have tried to move away from the hardware look of contemporary interfaces, in which the excessive use of borders and bevels has often resulted in a "boxy," visually noisy style. Instead, the Selector uses drop shadows without borders to achieve a floating, three dimensional effect. We experimented both with shifting the graphics and reducing their shadows in order to achieve the "depressed" feel when the mouse button is down, and found that most people preferred the look that resulted from reducing the shadows on button-down. Elsewhere, button bar graphics are angled and bleed to the edge of single-pixel borders. This downplays the repeating rectangle effect of bevel, white space, and icon border, and increases the space available for detail in the graphics without enlarging the size of the buttons. Throughout the interface, selected objects are marked by an enclosing border rather than a "depressed button" look.
The single-click model described earlier also fits with the feel of Web documents. We expect that our users will spend a significant portion of their time browsing Web documents. We didn't want to present them with one interaction style while they are using the browser and another interaction style while they are using other applications.
Although we were originally forced to use buttons for application integration because drag-and-drop would not work in our environment, we have grown fond of this approach. Our general interaction model is that the user selects an object to view it, and then has the option of clicking one of the buttons on the button bar for further operations on the selected object. Clicking a button to exchange information with another application becomes a simple extension of this model, usually opening a task-specific window to view additional relevant information.
We believe that we have developed a coherent model for a graphical computer environment that is significantly different from the model currently being used in the graphical user interfaces of personal computers. Nonetheless, it is also clear to us that this model will not replace the current personal computer model in many environments. Where does the HotJava Views model make sense and where is it inappropriate?
As this paper is written, HotJava Views is in the midst of development, so we have had no opportunity to evaluate it with transaction workers on the job. In the limited user tests that we have conducted so far, participants have found the environment and applications easy to learn and natural to use. One intriguing finding is that a number of participants have commented on how much "fun" it is. This reaction was somewhat unexpected, given that the typical tasks were activities like replying to email messages and scheduling meeting appointments. Perhaps it has to do with the simplicity and that most of the functionality is exposed in buttons. Perhaps it has to do with the close tie between single-click and viewing. We're not sure of the source of this "fun", but we would like to understand it better and make it more prominent in the interface.
Rather than competing with other application suites on the basis of the number of features, HotJava Views has tried to focus on simplicity, while meeting the needs of light to moderate users. Once our software is deployed with actual users, we plan studies to determine if it really does meet the needs of a significant fraction of users. We certainly expect that there will be people who will find the functionality inadequate for their needs. In the future, we plan to extend the design to support a broader audience of users while still pressing for the essential simplicity of the original model.
Our design center has been the transaction worker: a person who spends most of their time performing a relatively small number of well defined tasks. Their computer tools are tailored to their task and they are experts in using these tools. The applications in HotJava Views may be peripheral to their main tasks, but they fill important needs for communication, coordination, and scheduling within the organization. We hope our applications will meet these needs and that our efforts to simplify the designs will provide ease of learning and use.
This is certainly not the first attempt to apply minimalist design to computer systems. Carroll and his coworkers  have argued for some time for the superiority of minimal instruction manuals for computer tasks. It is worthwhile to reflect that as in writing haiku poems, limitations can often be liberating. Our task was to design an environment and application suite for users who do not need "power user" functionality and who use inexpensive Network Computers with no permanent storage. And in the process, we had an opportunity to rethink graphical computer applications.
We thank Jakob Nielsen for helpful comments on the manuscript.
- Apple Computer. Macintosh Human Interface Guidelines. Addison-Wesley, Reading, MA, 1992.
- Carroll, J. M., Smith-Kerker, P. L., Ford, J. R., and Mazur-Rimetz, S. A. The minimal manual. Human-Computer Interaction, 3, 2 (1987-1988), 123-153.
- Gentner, D. and Nielsen, J. The Anti-Mac Interface. Communications of the ACM, 39, 8 (August 1996), 70-82.
- Halasz, F, and Moran, T. P. Analogy considered harmful. Proceedings of Human Factors in Computer Systems, 1982, 383-386.
- Nelson, T. H. The right way to think about software design. In B. Laurel (Ed.). The art of human-computer interface design. Addison-Wesley, Reading, MA, 1990.
CHI 97 Electronic Publications: Design Briefings