|Bridging the Gap: From Structured Data to UI Designs – Part I: Introduction|
|Bridging the Gap: From Structured Data to UI Designs – Part II: Mapping Approaches|
|Finding Common Ground...|
|Review of Writing Effective Use Cases (Cockburn)|
|Review of Contextual Design (Beyer& Holtzblatt)|
By Gerd Waloszek, SAP User Experience, SAP AG – September 29, 2009
In my editorial Finding Common Ground... published at the beginning of 2008, I touched on the following issue: In the user interface (UI) design field a gap still seems to exist between the requirements that have been gathered for a design and the concrete design itself. The question is, "How can we derive a design from a requirements specification?" In this series of three design tidbits, I explore ways to bridge this gap. This third and final article in the series looks at structural approaches.
Structural approaches are based on some sort of analogy. Probably the best known analogy in UI design is the desktop, also referred to as the desktop metaphor. In the following, I will distinguish between three types of analogies:
As the third item suggests, objects and processes are often intertwined and the borders between them are fuzzy.
Basing the design of applications on object analogies is, of course, not new to UI designers, and in fact, it has become common practice for graphical user interfaces: Here, the user works on a primary object such as a paint canvas, text document, form, graphic, or photo. Typically, the object fills the screen or a window, and there are tools for performing specific (and unspecific) operations on the object. Often the tools (or functions) are arranged in tool palettes, sometimes they are also available through context sensitive mechanisms, such as context menus (all this fits the object-oriented programming style well). Here are some examples of frequently-used objects and their tool sets:
Figure 1: The drawing program Dabbler uses drawers to organize drawing tools, attributes, accessories, and so on. The whole screen is used as a drawing canvas.
Take a form as an example of how an object shapes the UI design: In a form, fields that are placed on the screen correspond to the object's attributes that the user specifies. Their order is typically determined by the natural structure of the attributes (for example, a hierarchy), and also by our cultural and perceptual preferences (top-to-bottom, left-to-right or vice versa). Innovation may come in here by introducing functionality that relieves users from unnecessary work such as automatic fill-in of attributes. The electronic nature of computer applications may also allow for completely new ways of processing an object that clearly go beyond what is possible in the physical world.
In some cases, the analogy is taken literally, and the electronic objects are more or less presented as if they were objects from the real world. Figures 2-4 show movie players, which have been inspired by the tape recorder analogy, while figures 5-7 show electronic versions of real-world calculators.
Figures 2-4: The QuickTime player (left and center) and The Windows media player (right) more or less use the analogy of a tape recorder. Advanced commands are deferred to menus; they are more easily visible in the Windows version of the QuickTime player (center).
Figures 5-7: The calculator is an example of mimicking a hardware device on a computer (from left to right: Windows XP, Windows Vista, Mac OS 10.5)
Perhaps I should add a warning here: Following an object analogy too closely may bear the risk that new ways of dealing with objects are not fully exploited that would be impossible in the physical world, but are possible in an "electronic" world.
Particularly in a business environment, application contexts may not fit easily to simple objects because the business procedures involved are highly abstract. Other procedures may involve different people at different processing stages or follow a chronological sequence that extends over a longer period of time. In such cases, it would be more appropriate to use a process analogy. In the simplest and most common case, a process is divided into a number of sequential steps, and the user is guided along the steps. This technique is called a wizard or assistant, and nearly every online shop uses it nowadays (see figure 8).
Figure 8: Ordering wizard in an online shop (from www.amazon.com)
Problems with this simple model may arise if the process involves a large number of steps, or if it requires users to make decisions that influence the flow of control and lead to various paths through the process. Here, the simple "step" analogy may no longer be helpful. However, complex flow diagrams that represent the different paths may also confuse users.
Processes that involve many users can be matched to a workflow model, those that extend over a longer period of time to a timeline. Both models can also be used in combination: Workflow inboxes, for example, may provide local snapshots of a process for individual users, while a time line may be used to represent the overall process.
One might argue that object analogies also include processes and, therefore, that there is no point in offering object-and-process analogies as a third category. The point that I want to make here is, however, that this type of analogy is more abstract than pure object analogies – perhaps I should look for a better name for this kind of analogy. Object analogies are typically based on a direct correspondence, while the analogies that I will describe below are much more abstract and can be applied to nearly every application that serves a number of different purposes (which may be subgoals of one primary goal), not just one.
Karen Holtzblatt and Hugh Beyer from Incontext introduced floor plans as a metaphor for user interface design: Rooms have a purpose, and it is important that the inhabitants can easily move from one place to another (see figure 9).
Figure 9: Floor plan (from incontextdesign.com)
Kai's Photo Soap, an application for optimizing photos, uses the room metaphor explicitly, even though its visual presentation is fairly abstract (see figure 10).
Figure 10: The map room in Kai's Photo Soap leads to different rooms, each of which performs a certain type of processing. Here, users usually move from room to room in a fixed order.
Applications rarely use the room metaphor as directly as Soap does. When Beyer & Holtzblatt (1997) use it, they talk of floor plans that serve as an entry point to their generalized and more abstract User Environment Design (UED) formalism (see figure 11).
Figure 11: Example of a User Environment Design (from incontextdesign.com)
In this formalism, rooms turn into "focus areas" that serve one or more purposes, offer functions for accomplishing the focus area's purposes, and have links or pathways to other focus areas (see figure 11). Thus, the paths between focus areas describe the navigation within an application or Website. This formalism has always made sense to me, and I discovered that I had drawn similar diagrams when I retro-engineered existing SAP R/3 applications – long before I had even learned about UEDs (the authors also propose using reverse UEDs for existing applications).
Innovation is typically associated with the notion of creating something new (and useful) that has not existed before. Innovation in this spirit rarely exists in software design. Usually, UI designers create new solutions on the basis of what already exists. Therefore, mapping a UI design to existing solutions is nothing to worry about. In fact, it is a good thing because it supports consistency and conformance to user expectations.
Structural approaches, on the other hand, are often based on analogies: Software is organized around certain known objects and/or processes. Like maps, analogies foster consistency and conformance to user expectations. User Environment Designs (UEDs) allow for designing complex applications without the need for a direct analogy.
Perhaps, innovation is reserved for the few cases where magic is involved. But magic is "magical" and cannot be explained. Therefore, I am sorry to concede that I cannot contribute to revealing how this works.