Screen Layout – Part I: General Considerations
By Gerd Waloszek, SAP AG, Product Design Center – 03/20/2002, updated 07/30/2002
The Steps in Screen Layout | Aspects of Screen Layout | Final Word
This article is the first in a series of short articles on screen and page layout. Putting controls on a screen finally makes an application come to life and visible for everyone. Thus, this process is a very important step in the development of an application or Website. Irrespective of how a screen came into being – either through a well-defined, user-centered design process, or through a last-minute effort – there it stands as it is without a label stating the process that created it...
Luckily, from a purely layout point of view we don't even need to know that process. There may be some indicators of the process used because the screen exhibits some severe usability or aesthetic problems. But layout and usefulness, although they work hand in hand, are two quite separate aspects. For example, from a layout point of view, we may find that two screens look very similar. From a user's perspective, however, one screen may be usable because it fits the task, while the other may not because it contains irrelevant or wrong elements. On the other hand, an ugly screen may be usable – even though it could be much more usable with a better layout – if it contains the elements that users need for performing their tasks.
Overview of the Article Series
In this short series on screen and Web page layout, I want to focus on pure layout issues, that is, on the arrangement of screen elements. I will not go into how a screen was created and whether the elements on it fit a task from a "content" point of view. I do, however, consider relations between screen elements, such as flow of control and dependencies, because these can be discussed in an abstract manner without knowing application details.
This first article describes general steps and aspects of layouting applications, such as Web or R/3 applications. A second article covers the sequencing and nesting of screen elements, and in this I present a simple layout theory or scheme that is applicable to a wide range of applications. It is based on the concept of a "layout hierarchy", which describes the sequencing and nesting of screen elements in a hierarchical fashion. For a specific application type, such as iViews, Web applications, or R/3 applications, the layout rules can be adapted and transformed to table overviews and text rules. A third and final article will present practical examples that demonstrate the application of this concept.
The Steps to Screen Layouting
There is a preliminary step (step zero) to screen layouting, which I want to call "setting the stage": This step determines the application type and the available technology. The actual layout process consists of three steps, which can be performed in the following order. Determine the:
- Sequence of elements (vertical, horizontal)
- Nesting of elements
- Spacing between elements at different hierarchy levels.
The sequence takes care of the flow of control, dependencies, and information about which elements belong together – the latter in a more linear fashion. The nesting also takes care of dependencies and of togetherness – but in a hierarchical or top-down fashion. The spacing takes care of aesthetics and of the proper application of Gestalt principles (mostly togetherness).
Step zero is important in restricting the design space: It determines, which screen elements are at your disposal, when using a specific technology for implementing an application. Prototypical designs often care little about technology. They may use elements that are not available, or leave the choice of a specific design element open to the application developer. Therefore you as a developer or user interface designer need to know the design options well – the ones available as well as those unavailable. If you know the alternatives to certain design solutions you can create workarounds in case an element is not at your disposal. You also need to know the pros and cons so that you can develop a design strategy, beginning with suboptimal solutions using what is available and approaching better solutions for the future.
The application type further restricts the design space because an application type may have characteristics, which forbid the use of certain design elements or solutions. For example, a simple application may appear in a dialog window and therefore cannot use menus. An iView is intentionally a simple and small application, which prohibits the use of long tables or deep nesting.
Aspects of Screen Layout
Laying out a screen is not just "throwing" controls on a screen. Apart from "content" considerations, which are not discussed here, several general aspects have to be considered, such as
- Flow of control –how users progress through a screen when doing their work
- Dependencies – how elements on a screen affect each other
- Togetherness – which elements on a screen belong together. There may be closer and farther relations between elements.
- Aesthetics and general Gestalt principles – how information can be effectively communicated visually
The application type and available technology may be seen as "boundary conditions" for the screen design.
The Role of Sequence
The sequence of elements should typically be determined by the flow of control. Flow of control means that the focus of activity moves across a screen or page while the user performs a certain task. Flow of control is important in two respects: (1) for the efficiency in performing a task, and (2) for the transparency and understandability of a screen or page.
"First things first" is a motto, which illustrates a natural progression in most things we do. For example, when entering customers' addresses we start with their name, which is the main information that determines the remainder of the information. We do not start with the street and number, even though one might infer the customer's name from that information. So, efficiency can be hampered because users have to step back because of a bad screen layout or because of errors.
In addition, conventions, such as the reading direction, play an important role for the arrangement of elements. If we follow such conventions we also make a screen easier to understand. What people regard as a natural flow of control, depends on their cultural background. For Western cultures the natural flow is from left to right and from top to bottom - just like reading. If the flow is reversed, efficiency and understandability are severely hampered. People are puzzled, may start to flounder, and may even have problems finishing a task at all.
Figure 1 shows examples of flows that are recommended and not recommended.
 |
 |
Goal
Start |
||
Yes
See the arrows for recommended flow between two areas |
No
See the red and blue paths for flows from start to goal that are not recommended |
|||
Figure 1: Basic rules for flow of control
Dependencies between screen areas or elements are also typically communicated through spatial relations. With dependencies, I refer to cause-effect relations, not to movements of the focus of activity; for example, you select an item in an overview list and expect that its details will be displayed below the list, not above it.
Dependencies are closely related to the flow of control because essentially the same basic rules are in effect, here: we expect, at least in Western cultures, that dependencies are from left to right and from top to bottom. Such a rule may be natural to everybody and most designers follow it without even thinking about it. Problems occur, however, if this rule is broken, and the flow or dependencies go in the opposite direction. As already mentioned, such reversals may present severe obstacles for users.
Figure 2 shows examples for dependencies that are recommended and for those not recommended.
 |
 |
|
Yes
See the arrows for recommended dependencies between two areas |
No
See the arrows for dependencies between areas that are not recommended |
Figure 2: Basic rules for dependencies
Arranging elements on a page is the first step in page design. This can also be done in a prototypical fashion and tested with users (for example with paper prototypes) without worrying about the details of the page design.
The Role of Nesting
There are two basic ways to visually indicate the relation between elements - closeness and nesting. Closeness means that objects, which are located closely together, are perceived as more closely related than objects that are farther apart from each other. Closeness refers to objects that are arranged on the same level. I will return to closeness in the context of spacing below.
Closeness of elements is typically combined with direction to indicate flow of control or dependencies. For example, first you enter a value into a search field (left) and then you click the related Go button next to it (right).
Nesting is used to indicate more complex hierarchical relations and dependencies between objects. Nesting is also a way to hide details from users because users can first deal with the high-level objects and then decide, which one they want to inspect more closely.
Nesting can make pages much more complex than simple sequencing of elements because nesting requires the introduction of borders or other visual separators that may clutter pages visually. Therefore, I will present nesting rules in the next article. They aim to prevent the creation of overly complex pages. Spacing can help to reduce the cluttering effect, but often requires more space than is available.
Nesting can also be explored in a prototypical fashion (paper prototypes, HTML prototypes; see also the article Using Prototypes). Here, the prototype may already be more detailed than in the initial phase.
The Role of Spacing
Spacing is very important in communicating which elements belong together; it also affects readability and the ability of users to recognize information on a page.
In general, application developers should not need to bother with the details of spacing, that is, with how many pixels they have to insert between, for example, a button and the border of a group. Currently, there are two HTMLB controls, the grid layout and the flow layout, which take care of the exact spacing. In addition, containers, such as the tray and the group also care for the outer spacing.
Only high-level prototypes aiming to offer a realistic preview of a final page need to bother about detailed spacing.
Final Word
The next article of this series on layout issues will present the two concepts of generalized containers and the layout hierarchy; the latter is the basis for nesting screen elements.
