 |
|
|
Design Tidbits
Design Tools
- My Design Tools – Part I
- My Design Tools – Part II
- UI Toolbox: Capturing and Editing Screenshots – Part I
- UI Toolbox: Capturing and Editing Screenshots – Part II
Simplification
- What Does "Simple" Mean?
- Anti-Simplification – How to Make Life Harder for Users
- Reducing Complexity
- Error Prevention Comes First
- Don't Let Your Interface Lie
- Don't Let Users Suffer from System Weaknesses
Interaction Design
- Did You Make Your Selection? – Part I
- Did You Make Your Selection? – Part II
- Did You Make Your Selection? – Part III
- Did You Make Your Selection? – Part IV
- The Software Works The Way I Think: Beyond Point and Click
- A Layman's View on Interaction Styles – Part I
- A Layman's View on Interaction Styles – Part II
- Selecting Objects By Attributes – Part I new
- Selecting Objects By Attributes – Part II new
Screen Design
- The Art of Hiding – Part I
- The Art of Hiding – Part II
- Screen Layout – Part I: General Considerations
- Screen Layout – Part II: Layout Hierarchy
- Screen Layout – Part III: Examples
Hierarchies
- Hierarchies - Categories vs. Vectors
- Fighting
(with) Hierarchies –
Part I: Basics - Fighting
(with) Hierarchies –
Part II: Presentation - Appendix: Fighting (with) Hierarchies – Presentation Techniques I
- Appendix: Fighting (with) Hierarchies – Presentation Techniques II
Visual Design
- Some Color Mysteries
- Some Mysteries of Colored Text
- Animation – The Chili Pepper of the Web
- Appendix: Definitions of the Most Common Types of Animation on the Web
Design Process
- The Construction Cycle – Another Way to "Organize" the Design Process
- User Feedback
- What Does User Integration Mean for Software Design?
- Mapping a Conceptual Interface to a Physical Interface
Web, Web Applications, Web Design
- The Web – A Short Introduction
- An Introduction to Designing User Interface Controls at SAP
- From Dropdown Listboxes to Comboboxes
- List Box Tweaks (Part II)
- Concept Statements and Website Messages – Part I
- Concept Statements and Website Messages – Part II
Miscellany
- Adding Value to Your Interface by Using Simple Math and Matching
- How Much Documentation Do Applications Need? – A Simple Example
- Narrative User Interfaces
- Golden Rules
for Bad User Interfaces
- Universal Usability
- User Interface Controls and Interaction Techniques of Horror new
Links & More
Screen Layout – Part III: Examples
By Gerd Waloszek, SAP AG, Product Design Center – 07/01/2002
One Container – Many Looks | One Layout – Many Looks | Integrating Layout Rules into Design Tools | Using the Layout Hierarchy for Designing Color Schemes | Final Word
This is the third and last article in my series of short articles on layout in which I will present some practical applications of the concepts of generalized containers and layout hierarchies.
The first example demonstrates that a flexible container concept allows for a variety of different screen designs. This is also shown on a larger scale for a simple application based on a layout hierarchy. The next two examples show how layout rules can be integrated into screen design tools, and how a layout hierarchy can be useful for defining color schemes.
The first article in this series describes general steps for laying out applications. The second article covers the sequencing and nesting of screen elements and presents two concepts: (1) generalized containers and (2) the layout hierarchy.
One Container – Many Looks
In the previous article of this series, I presented the concepts of generalized containers. Containers are screen elements that contain other screen elements – including themselves if the rules defined for the layout hierarchy allow nesting. In addition to containers, there are non-containers and separators.
In the first example, I will show how a generalized container can offer advantages in an environment, where design changes are frequent, such as the Web. The key idea is to keep the basic container structure stable, while changing certain attributes of the container elements. This approach allows containers either to be "hidden" in the background, or to stand out more or less prominently, depending on the visual attributes employed.
The GenBox – A Hypothetical "General" Container
For this example, I have defined a hypothetical container similar to SAP's tray called "GenBox." Unlike trays, GenBoxes may be nested and also used as a group box within GenBoxes. In addition, GenBoxes are conceived as "lying on an application or window background."
The GenBox Structure
The GenBox consists of the following structural elements
- Outer spacing
- Title bar (contains title text)
- Border
- Inner spacing (can be regarded as part of body)
- Body
GenBox Attributes
Now let's define the GenBox attributes. For the sake of simplicity, I have only listed attributes that are relevant for this example – many more are conceivable:
- Outer spacing: pixels (top, left, bottom, right), color
- Title: text, font attributes (font, color, size), background color, extent, position, functions
- Border: thickness, color
- Inner spacing: pixels (top, left, bottom, right), color
- Body: color
Remarks
The outer spacing separates GenBoxes and may let the application or window background show through if this area is transparent. Between the GenBox border and the content or body there is an empty area called inner spacing. The GenBox body might also have a small outer spacing; this would be useful if the inner spacing differed in color from the body background. This is, however, probably rarely needed.
Also note that one possible color is "transparent", which makes the color below the respective area visible.
Schematic Look
In the following example, I have simulated the GenBox container using nested HTML tables. I have not added extra spacing to the title and body areas. For better visibility, the GenBox border initially has a different color to the title area, and for simplicity the border surrounds the body area. So, this is what the GenBox might look like:
|
Outer spacing (the application background may show through if this area is transparent)
|
Below, I have placed four such GenBoxes on a light blue application background so that you can compare the "base design" (which would never be used in real applications) with the examples to follow:
|
|
||||||||||||
|
|
Simulation - Changing the Look but Not the Concept
To start with, I will change the following GenBox parameters: The GenBox border becomes the same color as the title area so that it blends into the title. The body and the inner spacing are made white so that the GenBox has a uniform background:
|
|
||||||||||||
|
|
Next, I will make the border disappear by setting its color to that of the body color; I will also change some other colors as an illustration:
|
|
||||||||||||
|
|
Finally, I let the GenBoxes disappear altogether by making everything transparent so that the application background shows through:
|
|
||||||||||||
|
|
Conclusion
Containers are useful even if there seems to be no justification at first for the additional complexity they introduce. If containers are provided with the appropriate parameters, they enable a multitude of different designs without affecting the application or content itself. On the Web, for example, the attribute values can be affected by exchanging cascading stylesheets (CSS) – either globally or for specific purposes only.
I have two final remarks to make: I simulated the GenBoxes using a number of nested tables, which is not at all the best approach. Therefore, please do not copy the code because there are much better solutions. Also note that a general but complex abstract concept does not necessarily result in complex HTML code. This may be the case if pages or applications are "hand-crafted." A central rendering engine, however, can discard all the unnecessary complexity and render only the HTML code that is really needed (that is, it ignores not needed "internal" or "technical" containers).
One Layout – Many Looks
On a more global scale, the layout hierarchy can serve the same purpose as generalized containers, namely to provide a stable "base layout scheme" that allows for a variety of different designs.
A Hypothetical Layout Hierarchy
Again, I will demonstrate the principle using a simple hypothetical application scheme that is composed of the following screen elements:
- Application (window) background (may be subdivided into rectangular areas)
- Areas (screen sections dedicated to a purpose or subtask)
- Groups (screen sections dedicated to a subtask)
- Tabstrips (screen sections dedicated to a subtask offering different views)
- Complex non-containers: Tables, trees
- Simple non-containers: Fields, selection elements, text, links, buttons, icons, etc.
These obey the following nesting rules:
- Application background: Areas only
- Areas: Groups, Tabstrips, complex non-containers
- Containers (group, tabstrip): No restrictions, but not more than two levels (example: groups may only be placed inside groups once).
A Simple Application Pattern
The following application pattern can be found in many R/3 and Web applications:
|
|
||||||||||
|
The area to the left may, for example, contain an overview list, from which users select a certain item. An item itself may consist of several items and is displayed in the upper right area. Users may select an item from this list and inspect its details in the lower right area. In a real-world application, the area to the left might display shipments, the upper right area the object types that a shipment contains, while the lower right displays details of a selected object type.
Also note that each area may reside on a different application background (comparable to the outer spacing of containers; this area might be colored differently for the same effect).
To illustrate this, I have filled the application scheme with some simple screen elements and a group box. The example below now looks more realistic but still emphasizes the structural elements:
| Goods Entry Application | |||||||||||||||||||
|
|
||||||||||||||||||
|
|||||||||||||||||||
Simulation - Changing the Look but Not the Concept
For the following simulation, I have transformed this structural scheme into more realistic designs to show the usefulness of the concept. The first design, however, is fairly dull:
| Goods Entry Application | |||||||||||||||||||
|
|
||||||||||||||||||
|
|||||||||||||||||||
In this design all containers look the same and even the application background is the same color. This is reminiscent of what was typical for Windows-based application designs.
Now let me add some bells and whistles, such as different shading depending on the position and nesting of containers.
| Goods Entry Application | |||||||||||||||||||
|
|
||||||||||||||||||
|
|||||||||||||||||||
In the previous example, containers are very prominent. The next example integrates containers into the area background, the borders are subtle, and the application background globally structures the application:
| Goods Entry Application | |||||||||||||||||||
|
|
||||||||||||||||||
|
|||||||||||||||||||
Finally, we have an example which is similar in spirit to the last container example: areas blend into the application background and retreat visually. Headers look like text headers, while again the application background takes care of the global structuring. The hierarchical structure within areas is mainly indicated by indenting. Even indenting could be eliminated by setting the inner and outer spacing of the respective containers would have been set to zero.
| Goods Entry Application | |||||||||||||||||||
|
|
||||||||||||||||||
|
|||||||||||||||||||
Conclusion
All examples shown are based on the same structural elements and layout hierarchy. Of course, the last example could have been achieved without the additional effort of defining a layout hierarchy and using containers - arranging simple elements on the screen would have sufficed. But once a schema has been defined for a certain set of elements and an application type, it offers much more flexibility for changing the design. In addition, as already mentioned for containers, a central rendering engine can reduce code overhead when dynamically rendering HTML pages.
Integrating Layout Rules into Design Tools
Abstract concepts, such as the layout hierarchy, may be hard for screen designers to understand. So designers may consider simply ignoring these rules and creating screens or pages according to their "UI feeling." Often, they will be correct with this approach but there will also be cases, where they are not – especially when nesting screen elements.
So, what can be done to help screen designers? Luckily, formal rules have one advantage: they are easily integrated into computer programs, such as screen design tools. Consider a graphical screen or page designer tool as is offered by many modern programming or Web development environments. When using such a tool, screen designers start with an empty screen or page and arrange screen elements on it. Layout rules derived from a layout hierarchy can assist the designers and help them to design screens, which adhere to the constraints for the respective application type. Such a system may even employ different sets of rules according to the application type at hand.
Let me illustrate this point with a simple scenario, the creation of a user interface for a Web application. The designer clicks, for example, a group box on a tools palette and drags it onto the empty page. Next, the designer selects a tabstrip and drags and drops it onto the group box. In this case, however, the designer gets an error because single tabstrips cannot be placed into group boxes in Web applications. If the designer wants to add other elements to the group box content, they have to start by dragging these elements onto the group box and then adding a tabstrip (note: in iViews tabstrips may never be placed into group boxes). Thus, the inbuilt rules derived from the layout hierarchy impose constraints for the placement of screen elements. They guide screen designers and prevent them from having to remember the many and often complex layout rules.
In another scenario the designer might try to nest group boxes. The inbuilt constraints, however, would only allow the designer to nest group boxes of different types.
For different application types, other constraint come into play but again the screen designers need not remember the specific layout rules.
It is not difficult to implement a system with such inbuilt rules. The system can also be extended to take into account the specific spacing rules that are formulated for a certain application type.
Generalized containers offer one more possibility for extending design tools: As these containers are built from elementary parts, the parts can be used to create a modular construction system for containers and other screen elements. This way, the design tool's layout components can be derived from elementary building blocks and flexibly tailored to the needs of specific applications.
Using the Layout Hierarchy for Designing Color Schemes
Often, it is not until things break down that you actually become aware of them – this is true for me in the case of using the layout hierarchy for designing color schemes. I will come back to this further on.
In the "good old" Windows 3.1 times, color schemes were not a real issue for designers. Screens were gray, with a few additional gray shades for borders and other elements that exhibited a three-dimensional effect. The system color palette consisting of 16 or 256 colors was mostly used for icons. This situation changed, however, with the evolution and spreading of the Web and – at SAP – with the introduction of the Enjoy GUI for the R/3 system (Version 4.6).
The Enjoy GUI uses a fine-grained color scheme for presenting screen elements. In addition, the GUI supports hue shifts that keep color distances constant. I do not want to go into detail here, but we can clearly see that color palettes are much more complex nowadays and have to obey many more constraints than in the Windows 3.1 world. (As an example, see the HTML Web palette in the SAP Business HTML Cookbook in the Resources section of the SAP Design Guild.)
So, where does the layout hierarchy come in? The issue here is, that even if color palettes are more complex now, designers still have to settle on a fixed and limited set of shades for certain colors. One reason is that users cannot distinguish two many different color levels. With such a restricted set of colors it is sometimes hard to assign colors to all the possible tasks they may have to fulfill within an interface. As an example of multiple assignments, a color used for shading at element borders may also be used for an inactive tab in a tabstrip.
A layout hierarchy poses certain restrictions on the combinations and nesting of screen elements. Thus, it helps in coping with a limited set of colors and shades: These restrictions make the color palette designer's work easier, as they allow more colors to be reused without conflicts.
A problem may, however, arise if there is an error in the layout hierarchy or its documentation. Designers may reuse colors because of the error and find conflicts. For example, if the description says erroneously that tabstrips may not be placed into group boxes (while the correct rule would state that tabstrips must not be the only elements in group boxes), the palette designer may choose the same color for the group box background and an inactive tab. The designer may then find that inactive tabs blend with the group box background. On the other hand, without an explicit formulation of layout rules the error may even have gone unnoticed.
Going back to the beginning of this chapter, this kind of error actually happened to me and drew my attention to the usefulness of layout hierarchies for the process of designing color schemes.
Final Word
This article concludes my short series on screen layout. I would be glad to hear if other user interface designers find it useful to view screen layout and the visual aspects of control design from a more abstract perspective.
