|Short History of SAP's Web Applications|
|SAP HTMLB Guidelines|
By Esther Blankenship, SAP AG, SAP User Experience – September 12, 2003
Around the office at the Product Design Center here at SAP's development headquarters in Walldorf, Germany, our work centers mainly around user interface controls, or just "controls" for short. We spend our days specifying controls, designing controls, prototyping controls, developing controls and testing controls. But what is a control? Are there different categories of controls? How does a control come into being?
A control is an object that represents an interface to the underlying software. The control has an established interaction model as well as predefined attributes, methods and values. Confused? Stick with me. Let's dissect the first two sentences and take the SAP button control as a concrete example.
A control is a visual metaphor for the benefit of a human user who lives in a world full of tangible objects and who must interact with software and hardware that operates in a very different world. For the computer, a button doesn't have to have a special color or a three dimensional look to carry out a function like "save" or "cancel." This is merely a graphical convention for the convenience of the user. It looks the way it does to simulate the buttons that we push everyday on our telephones, our coffee machines and our cars. This communication layer between humans and machines is the interface.
Each control must have a reason for its existence as well as an established behavior. The purpose of a button is to let users command the underlying system to carry out a function. Users have learned expectations about the behavior of controls. When a user moves his cursor over a button, he expects the hand cursor to appear so that he knows that he can click on it and the system will respond appropriately. If the I-bar cursor were to appear instead of the hand cursor, he would certainly be very puzzled.
Figure 1: On the left, the button control with an I-bar cursor (looks strange, doesn't it?); on the right, the same button control with the hand cursor (says, "I'm clickable").
The attributes of a control are its characteristics. The attributes of a button are that it has a background area that can have a color. It has four borders, each of which can have a color, width and style. It can be enabled or disabled, standard or emphasized, small or normal size. It can be given a particular width and a tool tip, but it cannot have an attribute that allows it to scroll, for example, because that makes no sense for a little button. So, in this way, as creators of controls, we foresee what attributes makes sense for this control and preconfigure them for that control. Each of these attributes has a default setting, but the developer can override the default attribute settings when he chooses to use a particular control.
The methods of a control determine its behavior. Methods can either be evoked by the user or the system. A click on a button is a user-driven event. An example of a system-driven event would be the disabling of a button because the function it initiates makes no sense or is dangerous in a certain usage context.
(Note that there is often a duality between methods and attributes: a developer may either change the attribute setting or use the respective method. For example, one might disable a button by setting its attribute ENABLED to FALSE or by evoking the button's DISABLE method.)
The values are the visual expression of a particular attribute. (At SAP, we have several visual designs or "themes" for our software. Each theme has a separate set of values.) The button has a "background color" attribute. In the SAP Streamline theme, the value of the background color attribute of the standard button is light blue. However, in the SAP Tradeshow theme, the value of the same attribute is light yellow. As you can see, these values can change from design to design, but the attribute background color is constant. The important thing is that within each theme, the look of the controls is consistent throughout all applications.
Figure 2: On the left, the standard button in the SAP Streamline theme; on the right, the same button in the SAP Tradeshow theme.
Our controls are the basic building blocks for SAP applications. All of our Web-enabled controls are made available in a so-called "control library." Application developers choose from controls in the library and then, if necessary, set the preconfigured attributes for that control. But a control library has more benefits than just supplying individual controls to developers. By consolidating all of our controls into one library, the relationships among controls become evident, allowing designers and developers to better ensure consistency on a variety of levels. Aspects like keyboard accessibility, screen reader support, and color usage can be treated consistently, providing users with a unified experience throughout our software. Rendering performance can also be addressed more efficiently, since some principles apply to a variety of controls. Dependencies which are important for design customization for our customers can also be analyzed in a more systematic way.
In brief, the control library streamlines the development process and so saves developers time when they are creating applications because they don't have to create the controls from scratch. For designers and developers, the library is helpful because it reveals relationships among controls. From the point of view of the user, it ensures a consistent look and feel of our software.
To better understand our surroundings, we humans often categorize the things which with we are confronted. That is, we set about determining what a thing is by deciding to what it is similar and from what it is different. As far as I know, there are no "official" categories for user interface controls. I've seen a few control categorizations, and, although they were all different, they were all legitimate for the purpose they intended to serve. The following categorization is my own and is based on the main function of the control, not on visual design, size or complexity. I have identified the following groups of controls in our Web-enabled control library: information display, function, input, navigation, containment, separation, layout, and technical. This categorization is intended to convey an impression of the landscape of the controls that SAP offers to developers who create applications for our software and that make up the interface that people use when they work with our Web-enabled software.
Note: I've broken the controls into several basic groups; however, sometimes a control really belongs in more than one category. If this is the case, I've marked the control with an asterisk (*). The examples below are representative, not complete.
Information display controls serve mainly to inform the user and, in most cases, are not interactive. The obvious exception in this category is the link control. In the "normal" world of Websites, where the majority of screen elements are informative as opposed to interactive, links serve to navigate to another URL or to carry out a function. However, in the world of software, and business software in particular, it is not uncommon for all of the text on a particular page to be made up of links, as all of the data can be acted upon in some way or another.
Examples: Label, Progress Indicator, Roadmap, Text View, Link*, Breadcrumb*
When acted upon by the user, these controls send a command to the system. The link control appears again here in this category, as it is often used in place of a button in interfaces where the visual bulk that is inherent to the button is undesirable.
Examples: Button, Link*
These controls fit into two categories, on the one hand there are those that allow the users to enter free text (although the system may check the data to make sure that it is in the correct format) and on the other those that guide the entry possibilities (by only allowing the user to select from a list or a calendar).
Examples: Input Field, Date Navigator, Dropdown Listbox, Listbox, Checkbox, Radio Button
In this context, "navigation" means any control whose main purpose is to "take" the user to information which is currently not visible. (Because a link inherently contains a reference to a URL or a system command, where ever a link could appear in a control, the control could fall into this category. I have not placed all such controls in this category, however, unless the control's main purpose is navigational in character.)
Examples: Link*, Breadcrumb*, Tabstrip*, Tree
A containment control is one that visually groups other controls in a specified area. Although the containment category is logically the opposite of the separation category, the goal is very similar. By confining one group of controls, one per se separates them from other controls and vice versa.
Examples: Group, Tabstrip*, Tray
As mentioned in the section above, this category is closely related to the containment controls. These controls simply consist of a straight line which visually separates two or more controls from one another. These lines are combined with increased spacing to provide a stronger visual separation than that which can be achieved with spacing alone.
Examples: Horizontal Divider, Toolbar Separator
Layout controls are generally "non-visual" controls (i.e. they have no color or image attributes) that make it possible to place other controls into rows and/or columns, thus fostering a more usable and organized interface. They also regulate spacing and alignment of the controls that they contain. In some cases, a layout control is specially designed to contain one specific control; examples of these are the button row and checkbox group.
Examples: Button Row, Grid Layout, Checkbox Group, Radio Button Group
This last group of "non-visual" controls is necessary for the framework to work properly, but the controls go mostly unnoticed by the user.
Examples: Drag Source, Drop Target
The journey from usability problem to feasible solution to control in the development library is a challenging one indeed. The following section explains how this process works for SAP's standard Web-enabled controls.
Once an idea for a usability solution has been conceived, a detailed specification that clearly defines the purpose and behavior of the control must be created. This document must also detail how the control works under all possible circumstances. Here are a few of the questions a specification for a tabstrip control would have to answer:
Once the questions of behavior are answered, a technically feasible solution must be created. A solution is only feasible if:
For Web-enabled controls, we first build an HTML prototype that must work on all the platforms and browsers that SAP supports. Our goal is to create one code with one look and behavior. If you are familiar with the fickle beast called HTML, you know that this is not as easy as it sounds.
The new control must fit into SAP's design language. That means, first, that similar controls must be taken into consideration. Naturally, there is a certain amount of subjective, creative design work to be done here, but the work must not be so creative that the control no longer fits into the design language that the other controls in the library speak. For example, if the new control can have a selected state, the visualization should be consistent with that of other controls in the library that also can have a selected state. All the details of the visual design must be explicitly stated in a design specification document. This includes padding and margins; thickness and style of borders; alignment; dimensions of the control itself, of its parts and of any images it may require; where transparency and color are used; text size, color and style; tool tips; visualization of all possible states; etc. And, as if that weren't enough, all this must be done for all the themes that SAP delivers (currently five).
For our Web-enabled software, SAP supports a flexible design system based on CSS rendering. That means that we do not create HTML and CSS classes which only support our current visual design. We consider a wide gamut of viable, potential design alternatives for that control and provide parameters and classes to allow for visualizations that might be very different from those in our current themes. Naturally, there is a certain amount of design expertise required for and subjectivity inherent to this task, and at some point we have to draw the line on flexibility or else system performance would suffer. That's the real challenge in this part of control creation – striking the right balance between system performance and design flexibility.
Now that you have had a behind-the-scenes look at SAP's control library and at the process that leads up to the birth of a Web-enabled control, you hopefully have a more complete understanding of the graphical user interface elements which make up SAP's Web-enabled applications. We are constantly defining new controls and refining existing controls to improve the user experience of our software. At the Product Design Center, we believe that an attractive, consistent visual design must be rooted in a sound technological infrastructure and be based on a flexible design concept in order to evolve successfully over the years and provide maximum return on investment for our customers.