SAP DESIGN GUILD

Mapping a Conceptual Interface to a Physical Interface

By Gerd Waloszek, SAP AG, SAP User Experience– Updated: January 14, 2002

This article may not only sound a little bit "abstract" – it is. On the other hand, I hope that it includes enough examples to make the issue clear: the problem to distinguish between the abstract properties of a user interface design, that is, its conceptual structure or model (we also use terms, such as "logical" or "semantic" for this level), and its physical implementation. In simple words, we can say that there is a clear distinction between the abstract plans we build for an application's user interface and how the application itself actually looks. But as the first three examples show, we find that the distinction between abstract concepts for something (some thing...) and the properties of its physical realization is not restricted to the application level only.

(Conclusions listed as abstract on the EPSS Central Website – Design & Development – Project Planning & Management)

Example: Logical vs. Physical List Colors

Let me start with a simple example that illustrates the distinction between "conceptual screen elements" and their physical counterparts. Years ago, I was involved in a project that defined a color scheme for ABAP lists. We soon discovered that for this task we had to analyze the existing ABAP lists and to find their common structural elements. We identified headers, the list body, totals and intermediate sums, and several other elements. We mapped these structural elements to a set of 16 "logical" list colors, with many elements having two color gradations (e.g. two header levels, two row types for a stripe pattern in the body, two colors for totals and intermediate sums, ...). These logical colors were given names that reflected the function of the respective structural element in the list, such as COLOR_HEADING. So, the most important part of our work was to identify those conceptual or "logical" list ingredients.

#	Symbolic Color Name	Intensified	Intensified Off
0	COL_BACKGROUND	Background	Background
		GUI-dependent	GUI-dependent
1	COL_HEADING	Headers	Secondary headers
		grayish blue	bright grayish blue
2	COL_NORMAL	List body (1. stripe )	List body (standard coloring or every 2nd stripe)
		bright gray	almost white
3	COL_TOTAL	Totals, subtotals	Subtotals of higher degree
		yellow	bright yellow
4	COL_KEY	Key columns	Highlighting lines/columns
		bluish green	bright bluish green
5	COL_POSITIVE	Positive threshold value	Inserted lines
		green	bright green
6	COL_NEGATIVE	Negative threshold value	Unused
		red	bright red
7	COL_GROUP	Hierarchy header	Hierarchy information
		violet	bright violet

Table 1: The ABAP list colors and their function - the physical colors are given for reference only; they might change if a new color scheme is introduced (see figures 1 and 2 below).

In an ideal world, developers then simply would construct lists out of predefined structural elements without having to worry about the actual colors or any other attributes. In the real world, developers had to hand-code the logical colors but not the physical ones. So, whenever a new color scheme were introduced, all lists would automatically and correctly change their look.

So, what's the problem here? The problem was that many developers chose list colors not because of the function of the respective list element but because of their physical properties, that is, their actual color values. A developer would choose COLOR_TOTAL not because he wanted to display a group, but because he wanted to present numbers on a violet background. But as soon as the list color scheme would be changed and all groups would look, say orange, there would be a problem: the numbers which should looked violet before would look orange afterwards (see figures 1 and 2).

The actual (physical) ABAP list colors - an early color scheme

Figure 1: The actual (physical) ABAP list colors - an early color scheme

The actual (physical) ABAP list colors - the 4.6 color scheme

Figure 2: The actual (physical) ABAP list colors - the 4.6 color scheme

Example: Logical vs. Physical HTML Tags

There is a similar issue with HTML tags. There are "logical" tags, such as "strong" or "citation," and "physical" tags, such as "bold" or "italic." The creators of HTML let it open to the browser developers how they would present a logical tag physically. For example, one browser might display a citation in italic and indented, another one bold and not indented. Even though the W3C consortium discouraged the use of physical tags, many designers used them because they wanted more control over the actual appearance of their pages. So, the initial idea of identifying text portions by their function within a text, such as heading level 1, body, figure caption, citation etc. was soon eroded because designers used physical tags, thus loosing the information about the logical functions of those text portions.

Structural HTML Tags	Logical HTML Tags	Physical HTML Tags
<h1> ... <h6> headings <p> paragraph <ol> ordered list <ul> unordered list <li> list item	<strong> strongly emphasized <code> code <samp> example <address> address <cite> citation	<b> bold <i> italic <u> underlined <big> larger <small> smaller <font> font attributes

Table 2: Examples for structural, logical, and physical HTML tags

Example: Paragraph and Text Styles in Word Processors

Text styles in word processors have a similar function as the logical HTML tags: they describe text portions by their function and assign text attributes to them. Thus, you can change any of the physical attributes of the text portion without changing its function. What is it good for? The outliner in Word, for example, makes use of some of the functions of paragraph styles and helps users to organize the structure of a text document.

It may be hard to tell the function of a text element by simply looking at it. There is one hint: if you put the cursor inside the text portion, its style is displayed in the toolbar. The only other cue one may have is that the physical attributes follow some common logic or convention, such as header text is larger than body text, captions are smaller than body text, header level 1 is larger than level 2 etc. This is what the readers of a text expect, but nobody prevents an author from contravening these principles – if he or she want to confuse his or her readers.

Example: Screen Areas

If you take a look at the guidelines for the Internet Application Components (SAP Interaction Design Guide for Internet Application Components ) you will find that they define a hierarchy of screen elements. This hierarchy includes more abstract and global elements, such as areas or group boxes, as well as low level elements, such as radiobuttons and fields that must be arranged inside the global elements.

On a more general level, you can define screen areas such as a header area, a navigation area, a work area, a status area and the like. Then you can state in your guidelines that error messages have to appear in the status area or that global functions have to be placed into the header area. But aside from some common conventions, which developers and users would expect to be observed, for example, that a header area is on top, no one can tell where these elements actually have to be placed. To make that clear you have to offer a mapping from the abstract screen elements to the physical locations on the screen. That is, you have to present a sketch similar to the one below, which tells developers that the header area is on top, the navigation area to the left, the work area right to it, and the status area at the bottom.

Header Area

Navigation
Area

Work Area

Status Area

Figure 3: Schematic sketch for the physical layout of conceptual screen areas

Example: Portal Areas

To be more concrete let me explain this mapping from conceptual units to physical ones for the new SAP Portals screen layout. Again, we have a number of conceptual entities (logical, semantic or abstract entities), such as the title area and the content area. We can also state on an abstract level that the top-level navigation is based on a two-level concept and that the detail navigation starts with level three. But we still do not know the physical location of these elements and their actual implementation.

So, once again we need a mapping from the conceptual level to the physical level, which states that the top-level navigation is located below the header branding area at the top and that the two-level navigation is handled in a tabstrip-like manner, where the second level is shown for the selected first-level tab only. This mapping can be found in the Developer's Cookbook by the Product Design Center. An alternative, which is logically equivalent to the tab solution chosen, would be to follow the www.sap.com Website design, where the second level acts similar to a dropdown menu when the mouse moves over it. Even a set of dropdown listboxes, one for each first-level tab would logically serve the same purpose, however ugly it may look.

Example: Mapping an UED to Real Screen Elements

In my last example I return to a more abstract level. At one stage in the design process, any design method has to make the step from abstract concepts and entities to the physical and "real" screen elements, that is, to the world the developers live in. Developers do not want to be told that there is a header area on top of the work area and the like. They want to be told "Place the tabstrip here, put these fields into a group box, use radiobuttons for the options" and so on. Many design methods are fairly short about this step - the actual screen design seems like the result of some magic, and the design decisions appear fairly obscure. On the other hand, there are serious attempts at shedding some light at this mystical issue, one of them is the step from the abstract User Environment Design (UED) to actual screens in the Holtzblatt methodology (see reference below).

Let's take a short look at Karen Holtzblatt and Hugh Beyer's approach. The UED describes so-called focus areas, and lists their functions and connections to other focus areas. Focus areas can have additional attributes but for this article these are the most interesting ones. What a focus area will become in reality is open in the beginning - it may turn out as a screen or page or an area within it. In chapter 18 of their book Contextual Design the authors describe, how they map an UED to a window-based user interface as well as to a command-line user interface - the abstract model leaves open, which interaction style is used in the end. They also discuss the mapping of functions to UI controls. Even controls that are functionally equivalent have specific advantages and disadvantages. In one case they may be the first choice in another one not.

Having done the mapping, you are ready to go to the developers and tell them to implement your design. They will not use your UED for the implementation, you have to map it to real screen elements for them (of course you can already discuss the UED with them, but that is a different thing).

Prototype Dilemmas

Let me close this article with another "real life" issue – prototypes. User interface designers build various kinds of prototypes to verify their design proposals and to instruct application developers how to implement an application's user interface. Low-fidelity prototypes, such as paper prototypes often bear little resemblance to the actual application screens. These "application models" may be fairly abstract, and although most of the mapping task has already been done (that is, the screen elements, such as tabstrips or radiobuttons have been defined), there is still a lot of work to do with respect to the exact page layout and graphic design. Often developers find it hard to create a connection between a paper prototype to their world of existing screen elements and the actual application. Consequently, paper prototypes sometimes have problems being accepted because developers do not regard them as helpful for their work.

High-fidelity prototypes, such as Photoshop assemblies or dynamic HTML prototypes are often better accepted by developers because they look much more similar to the actual application; the "gap to bridge" for the mapping is much narrower. On the other hand, other dangers linger around here. A high-fidelity prototype rarely looks exactly like the application. There are always elements that are different from what the final look will be (there are many reasons for this discrepancy, for example, the actual look may not be finalized, or the user interface designer may not use the current version of the screen elements). However, it is hard for the developers and other people as well to realize, which characteristics of the prototype should be taken literally and which not. They may take the prototype literally "as a whole" and implement even the wrong or preliminary features. It is also hard for them to draw a clear-cut line between interaction design and graphic design, as is for most people. Therefore, it will not help much if you tell a developer, "Yes it should be a tabstrip, but the blue of the background should be a bit more reddish." A high-fidelity prototype condemns you to be precise in every aspect.

Conclusions

It is important to make a clear distinction between the conceptual level of a user interface design and its physical counterparts. Often, both aspects are mixed together because people find it hard to distinguish the levels. Typically, the conceptual level is too abstract for them - they cannot envision it. However, if developers or other members of the development team are confronted with a physical representation of the conceptual design, they primarily look at its physical properties and start discussions on issues of personal taste, such as colors or the overall aesthetics of the screens, that little have to do with the functionality of a design.

To my experience, it is difficult to keep the levels apart in discussions with colleagues and developers. Especially, graphical design flaws are easily detected and can lead to fruitless discussions. On the other hand, it is much more difficult to find design flaws in the interaction of a prototype or design specification. So, my advice is to again and again remind developers of the distinction between a conceptual design and its physical counterpart in order to help them to separate these issues.