Previous | Table of Contents | Next |
4.3.3. Hierarchy of Control and Metaphors
The interface design should be based upon an understanding of which are the highest priority features and of the order in which a user would want to move through the steps of any given task. The interface should be organized so as to maximize the discoverability and perceived ease of use of high priority features. Perceived ease of use is defined to include a minimum number of key presses, a minimum number of dialogue screens, and a minimum amount of time and effort required to complete a task and achieve a goal (this is verified in usability testing).
The location of a feature is determined by its importance to the user and the frequency of access, as verified in the Refinement and Analysis Stage. Frequently used features are allocated to the top level of the interface. In the case of the Orbitor interface, priority is given to the most important time-critical task: real-time voice communication. Highly used features are either located on the first screen or on hard keys that can be accessed directly at any time (e.g., navigation arrow keys). Less-used features are located on-screen, one layer down (e.g., telephone configuration controls were located in a folder within the filing cabinet environment; see Figure 11.7).
Figure 11.7 Hierarchy of controls and metaphors.
The first screen should support the most important frequent task. With the Orbitor, a system of spatial, object-based metaphors was used to create an understandable hierarchy of primary and secondary foci of attention. The size of an object, the location, and the level of detail were all used to communicate the hierarchy. The most important objects were large, highly detailed, and located in the foreground. Smaller, less-detailed objects in the background were still easily accessible, despite the visual cue indicating their reduced importance. Also, within any screen there was generally a top-to-bottom, left-to-right hierarchy (building upon the users experience with the typical layout of newspapers, books, and other paper-based graphical information).
At the highest level, an environment metaphor was used to logically organize the various features into three groups (Call Environment, Message Center Environment, and Filing Cabinet Environment). This metaphor was chosen to make it explicit to the user that there were three distinct modes in the interface. For example, the Call Environment was used only for real-time voice or note communication. The Message Center Environment was used only to view stored voice messages, ink messages, or text messages. We wanted the user to view these not as abstract or arbitrary modes, but as spatially distinct places (environments). I know I am in the Message Center because I see messages and they look graphically distinct from objects in the Call Environment or the Filing Cabinet environment. Within each of the environments, the interface was modeless, i.e., any input from the user had the same consistent response anywhere within that environment. The user could also navigate at any time between any of the three environments without any destructive effects.
At the next level down within each environment an object metaphor was used; all communications links were represented by graphical objects. For example, a voice call between two people was represented by a single call object in the foreground. This call object had text to identify the callers name and telephone number, an icon to identify the location (home, office, cellular, other), and an icon to represent the type of link (e.g., a voice call on Hold, an active voice call, message, etc.).
4.3.4. Animation Extending the Range of a Metaphor
Animation is a technique that can be used to extend the useful range of a small and simple set of icons. For example, a static telephone icon could indicate a free line, while an animated version of the same icon could signal an incoming call. Animation can also be used to provide visual cues to the internal structure of the interface, as well as providing feedback to the user as to what is happening. In this way, users can discover the function and location of various objects from the interface itself. With the Orbitor, for example, if a user did not answer an incoming call because she was busy writing a note, the incoming call object would be automatically shrunk and moved to the Message Center. At a later time the user would know exactly where to go to look for a message left by the caller.
4.4. STRUCTURED VS. UNSTRUCTURED INTERFACE
An overall interface, or specific tasks within an interface, can be implemented in either a structured (task-oriented) or unstructured (subject-oriented) manner. A structured interface is one in which the user is clearly guided through a particular task in a lock-step fashion. The Wizards used in Microsoft products are a clear example of a structured interface. Structured interfaces are ideal for novice users or where there are strict business or legal rules that regulate the sequence in which tasks must be completed. The converse is an unstructured interface, in which the user is presented with objects which can be manipulated in many different ways to complete a task. Unstructured interfaces are generally appropriate for experienced users.
It can be advantageous to design an unstructured interface for new generation products, particularly in the early part of their product life cycle. The reason is that new generation products are often put to completely different uses from what was originally envisioned by the design team. For example, MacroMedia Director was originally designed to facilitate simple scripted business presentations. It is now the premier package for the development of multimedia games, interactive WWW services, as well as user interface prototypes. With a new generation product, a detailed track record of field use is obviously unavailable, and an excessively structured interface will limit the unanticipated uses.
Similarly, the general user interface for the Orbitor product was designed to be unstructured or subject-oriented for a number of reasons:
It is likely that future Orbitor applications which are specifically targeted for infrequent use by a particular group of users would be designed with a structured interface.
Previous | Table of Contents | Next |