SAP DESIGN GUILD

Bridging the Gap: From Structured Data to UI Designs – Part II: Mapping Approaches

By Gerd Waloszek, SAP User Experience, SAP AG – September 10, 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. The following article, the second in the series, looks at mapping.

 

Removing the Mystery: From Magic to Mappings...

In the above-mentioned editorial, I report that UI designers from Cooper acknowledged that some sort of magic is involved in bridging the gap between the requirements and the design itself (see also Figure 1). Other designers neither believe in magic, nor do they offer any convincing alternatives to it.

Figure 1: My own mouse-made version of Sidney Harris' cartoon (see the original cartoon on Sidney Harris' Website)

Therefore, I would like to resort to a more formal approach and say that mapping offers the bridge to span this gap. In mathematics, a map is defined as an association of objects in one domain with objects in another one (the association may have various characteristics, which is what mathematicians are interested in). In the first article of this series, I have already touched on the objects involved in both domains:

However, suitable objects may not exist for the task at hand in the design domain and will need to be created. Therefore, we might be tempted to conclude that the mapping concept is more or less useless to UI design. It definitely would be if we started designing user interfaces from scratch. But after more than 25 years of Human-Computer Interaction (HCI) as a discipline and even more of interactive computing, the design domain already offers a wealth of possible solutions. (Almost) all we need to do is pick the right ones. In the following sections, I will demonstrate ways in which thisn can be done.

Canned Solutions, UI Patterns

In an ideal world, every problem that we encounter has already been solved by someone else. All we need to do is pick a solution and, maybe, adapt it a little to our needs. This is the basic idea behind UI design patterns, which have a number of advocates in the UI design field (Jennifer Tidwell and Jan Borchers, for example) and have been inspired by ideas from Christopher Alexander who introduced patterns to architecture. Thus, on the one hand, we need UI designers who prepare libraries of useful UI patterns, and, on the other hand, all we have to do is scan these libraries for useful patterns. Libraries can also serve as implicit guidelines and thus help standardize applications.

Apple font mover

Figure 2: The Apple Font/DA Mover can be regarded as a "canned solution" that has been repeatedly imitated

As an example, the Apple Font/DA Mover (see Figure 2) is an instance of a UI pattern that solves the problem of manually selecting items from a set to create a subset. The shuffler (see Figure 3), on the other hand, is an example of a UI pattern that is used to filter sets of items according to certain criteria without having to use logical operators.

Shuffler 

Figure 3: Example of a shuffler, a combination of controls for creating "natural-language-like" queries

This is all I would like to write here about "canned solutions." The only issue causing some headache might be that we cannot find a useful solution and have to resort to other approaches.

Elementary Actions

This approach is similar in spirit to the preceding one. It is based on the notion that at various levels of abstraction we can identify tasks as "elementary actions," which is more or less the task of mapping between "contextual" and "abstract" actions. For example, we can interpret a certain task as a comparison of objects and thus implement it as such. This approach can also help standardize applications over a wide range of tasks, which is highly desirable for large business application suites, such as the SAP Business Suite. Again, we need people who create program modules that perform frequently-used actions and can be adapted flexibly to specific needs. UI guidelines can also help standardize the modules.

As an example of elementary actions, I would like to present the following list, which originates from an earlier paper in which I already approached the issue of "bridging the gap:" In this paper, I proposed a preliminary set of generic actions to which specific tasks could be mapped:

The example below, looking up a colleague's address, shows how mapping to elementary actions can be performed using a table:

Screen or Screen Area

Task-Specific Step

Elementary Action

Log-on screen

Enter name and password

Enter data

Press "Log-on" button

Initiate action

--- Screen change ---

Search area of screen

Enter name of colleague using certain fields (for example, last name, first name, and so on)

Enter data

Hit list area below search area

Scroll hit list and search for colleague

Browse data

Select line where colleague is displayed

Select data

Press the "Details button

Initiate action

Quit application

Initiate action

Table 1: Mapping specific actions to elementary actions for the task "Find address"

We should not take the list of elementary actions and its application too seriously: It was just an initial idea, and I have included it here to give an impression of what I was and still am aiming at. By the way, I was also able to demonstrate that this list corresponds fairly well to SAP R/3 screen types and application patterns.

Imitation

I firmly believe that most software is developed using imitation. Its application is only constrained by the fact that a similar piece of software exists. But as a lot of today's software is "me too" software, I cannot see any problems with this approach. The mapping is, of course, straightforward and only endangered by the risk of patent infringement. But at a company such as SAP, I would actually appreciate even more imitation: Far too many designers and developers prefer to reinvent the wheel on their own. Imitation can also help standardize software – even without excessive use of UI guidelines – provided that at least the forerunners followed them.

Windows Explorer

Figure 4: The Windows Explorer is another UI paradigm that has been imitated several times

Perhaps, I should add one last word concerning the difference between imitation and the use of UI patterns. UI patterns are abstract, while instances like the Font/DA Mover or the shuffler are concrete ; they can be instantiations of abstract UI patterns, but need not be. Thus, if designers borrow directly from ready-made solutions such as the Font/DA Mover or the shuffler, they imitate and may not even be aware of the abstract UI pattern and idea behind it.

 

Outlook

The third and final article in this series will discuss some structural approaches and will close with a short conclusion.

 

References

 

top top