Coded, Compacted, Contrasting Controls

The visual design of controls for better contrast, use of space, and representation of behaviors.

This month my trusty old 21-inch CRT blew with a catastrophic-sounding sizzle. Maybe it’s my user-interface orientation, but in my mind, nothing is more important to my user experience than vast expanses of unbroken real estate -it matters more than processor speed, hard drive size, or RAM. So when I moved to a Windows 95 machine almost 12 years ago, I bought the largest monitor I could get. Since then, 20 viewable diagonal inches isn’t what it used to be, qualifying only as a medium-sized monitor by today’s standards. Windows, meanwhile increasingly suffer from bloat, and I don’t mean Microsoft Windows; I mean individual windows, particularly of web sites and applications have gotten larger and more cluttered, keeping pace with expanding monitor sizes, just as bloat in executables keeps pace with processor speed. Formerly web sites kept their width to 800 pixels or less. Today 1024 is common. For working with multiple windows at once, I have to up-size my monitor just to keep pace.

Speaking of Windows 95, I think it’s time to re-work its visual design conventions to bring it into this century. Oh, sure we’ve had Windows XP and Vista since then, plus gumdrops, brushed metal, and more from Apple, but in a specific key area, none of these have improved on Windows 95. The Windows 95 style (now called Windows Classic) was Microsoft’s first attempt to make extensive use of 3-D effects, which remain in use in one form or another to this day across all platforms. Windows applied beveled edges to most controls. Unlike Motif, or, for that matter Vista, these effects were more than eye-candy. They provided information to the user, categorizing controls into groups by giving similar-acting controls similar visual attributes. I’ve discussed before the importance of controls having distinct appearances that correspond to distinct behaviors.

Advanced Search with Windows Classic design.

In the physical world, we rely on perceived affordances to judge how to interact with objects. A physical button, designed as a raised object with a concaved top surface about the size of a human finger invites us to press it (with only occasional disastrous consequences). In the digital world, affordances are more symbolic, relying on sometimes arbitrary visual features that users have learned to associated with certain interactions (e.g., the use of color and underlining to mean a link). With Windows 95, the visual features indicating specific behaviors are consistent across the controls. Many other OSs have made effective use of visual design to create affordances from metaphors and other user associations, but Windows 95 is perhaps best at using the same visual design codes or signals across the control set. With such consistency, there are fewer associations to learn, making for a simpler user interface. The user can “read” the user interface, and even anticipate the responses of controls that have never been seen before.

Categorizing and Coding Controls

Controls in general can be categorized as follows:

  • Inert Controls.
  • Interactive Controls.
    • Action Controls.
      • Command Controls.
      • Links.
    • Attribute Controls.
      • Read-only.
      • Modifiable.

At the top level, the most fundamental categories are interactive and inert controls. Before the user can even begin to use a GUI, she or he must know what will respond to input. Misperceiving a control to be interactive when it’s not wastes users’ time as they click on things with no effect. Misperceiving a control to be inert when it is interactive is even worse. The user may never attempt interaction, and thus never discover the functionality associated with the control. Or, the user may accidentally activate something (e.g., when the user intended to click on something unresponsive to clear a dropdown menu). Drawing heavily from Motif of the 1980s, interactive controls in Windows 95 are distinguished from inert by the presence of 3-D beveled edges, an excellent choice as it fits well with the direct manipulation metaphor. A 3-D look makes the controls appear like separate physical objects, and physical objects can be handled, i.e., interacted with.

Among interactive controls, some represent actions, where selection initiates that action, assuming the control isn’t disabled. In Windows 95, the raised border of menus and command buttons signal these controls represent actions. The raised appearance makes the command buttons appear like physical buttons, leveraging that metaphor. If an interactive control doesn’t represent an action, then it represents attributes or parameters, that is, they display a value and selecting the control provides the user with the capacity to change that value, assuming the control is not read-only or disabled. In Windows 95, the depressed borders represents attributes, as seen in text boxes, combo boxes, option buttons, and check boxes. The sunken appearance of these controls suggests that they are containers, in this case containing a value. Another good choice capitalizing on an analogy with the physical world.

Whether it’s action or attribute controls, a disabled state is consistently represented by dimming or graying the foreground, imagery consistent with a dormant state. There hasn’t been a consistent visual code for distinguishing read-only from modifiable attributes in Windows 95 apps. I’d recommend a white background for modifiable attributes and a gray (button-face) background for read-only attributes, but keeping the foreground (the text) dark in both cases to distinguish them from disabled. Read-only controls should also keep the border to distinguish them from an non-interactive label. Thus, a white background means an attribute may be modified, while a gray background means it isn’t. In either case, you have the depressed border to indicate the user is looking at an attribute. This is the default appearance for “locked” controls in VB6, and so this convention is commonly seen.

However, I’ve also seen read-only controls shown without the border. This is what we see for the Location text box in the General tab of the Properties windows for XP’s Windows Explorer. You can see why excluding the borders would be attractive. It’s just some text to read; why clutter it with a border? However, it also introduces confusion with non-interactive text, and, yes, text in a read-only text box is interactive. Users can select it, cursor through it (to read it, if the text string is longer than the text box), and copy it. If the read-only text boxes in your app aren’t interactive in this way, they should be. I’ve found the ability to copy the Location from the Properties window to be pretty handy, but by not having a border, it took me a long time to discover that it’s possible. The border on a read-only text boxes also provides a cue that some of the text may be cropped off. If users see text go all the way to the right border, they know some of it is hidden. Finally a border is necessary for multi-line read-only text boxes so it’s clear what the scroll bar applies to. For consistency sake, your single-line text boxes should use the same visual codes as your multi-line text boxes.

It isn’t perfect but overall, Windows 95 did a fine job having consistent visual codes indicating control behavior. So did Windows XP, which achieved a somewhat lighter look by flattening the attribute controls, but also added additional color, which counteracted the sense of reduced clutter. The coding is still consistent, in any case, with distinct appearances for attribute and action controls, inert and interactive controls.

Advanced Search with Windows XP design.

Then came Vista, which pretty much just let each control look anyway it wants to in whatever app it happens to be. For example, combo boxes may appear raised or flat. Compare, for example the drop-down list at the top of Advanced Search with those in the middle.

Advanced Search with Vista Aero design.

The difference in appearance has meaning (unlike a lot of other variation in Vista), but it is inconsistent. Now an attribute may or may not appear raised. The best rules are those where there is a one-to-one association between appearance and behavior.

Down with Beveled Edges

For all my admiration of Windows 95, the beveled edges can get old pretty fast. Back when they were fashionable, there was the occasional meaningless overuse. But even when used strictly to code control categories, it can become excessive, especially in large tables and forms typically found for database user interface apps. Beveled edges or other kinds of heavy borders work well in dialog boxes, where there are a small number of controls, and the user needs something bold to focus attention, but when the number of attribute controls becomes numerous, such as in a multi-row table or complex form, problems begin to emerge.

Multitude of bevel-bordered controls crowded in a hypothetical window.

Space Hog

The first problem is that those heavy borders use a lot of space. While screens have gotten larger, they are never large enough as far as I’m concern, especially for some database apps I’ve seen with remarkably large numbers of fields. You need at least 21 pixels of height for a text box with eight-point font; 24 to 28 pixels are needed if you want reasonable visual separation between the controls. Compare that to 17 pixels separating items in a list box. No big deal with a dialog box with only a few controls, but for a table shown in a primary window, that means up to 40% less information can be seen in a window of given size, forcing your user to scroll, page, tab, or otherwise navigate more to see the same amount of content. The user has to work harder to acquire the same information.

One not-particularly-good reason to use a grid, list box, or HTML table instead of arrays of text boxes or other single-attribute controls is that it saves space, but at the price of not having edit-in-place. Instead, you have to supply the user with an Edit page or dialog, adding effort and complexity. If our attribute controls were more compact, we wouldn’t have to choose between edit-in-place and efficient use of real estate.

Even if you don’t intend to pack your window or page top to bottom with attribute controls, more compact controls would provide you with more flexibility in layout. Essential for minimizing clutter from large numbers of controls is to provide grouping, labeling, and visual hierarchy among them. Perhaps the best way to group controls is by simply separating them with white space so that it minimizes the graphic variability of your window. One of the best ways to label and provide visual hierarchy to groups of controls is by varying the size of the labels. Both of these techniques cost space, which you’d have more to spend if controls were more compact.

Bordering on Distraction

In a database app, what’s the most important thing for your users to see? The controls? No, the values or content in the attribute controls. Designed for use in dialog boxes with relatively few controls, the visual design of controls for Windows 95 and even XP can soon overwhelm the content you’re trying to show.

With contrasting colors among the window background, control background, control border, plus the odd dropdown or spinner button or two, the controls have more graphic contrast with their background than the control’s content has with its background, drawing users’ attention away from what matters most to them. But at least the control’s content has black text on a white (or nearly white) background. Labels or captions for the controls are not so lucky, having relatively muted contrast with the grayish window background. To users, labels rival content in importance, being what users scan for when looking for the attribute they are interested in. Don’t get me wrong: like I said, it’s important to visually code our controls, and that means they have to be graphically distinct. However, the priorities are reversed. Attribute labels and values should stand out more than their associated controls.

Maybe the visual designers of GUI controls never considered the possibility of apps using a large number controls and the amount this would compete with the content for users’ attention. Thinking of only office-productivity apps, where the primary window is dominated by a WYSIWYG representation of a document, maybe they forgot that most apps are composed of tables and forms. Or maybe it didn’t seem important to them. When you’re designing and comparing controls, you’re not looking at the content. You may not even have any real content to look at. It may be “lorem ipsum” or “Field1″ and “Field2.” It’s easy under those conditions to think that the visual design of the controls is more important than the content. So we get bevel borders, upbeat colors, shiny surfaces, fancy reflections, and 3-D textures, all overwhelming the humble black-on-white Sans Serif that the user is really interested in.

Light is Right

A need for less conspicuous controls is not limited to attribute controls. I have mentioned before that there is a need for “lightweight” buttons for apps that don’t use the  object-selection-action model (i.e., nearly all web applications), and that they could be useful for denoting secondary commands in thick-client apps too. That means having a new means of graphically discriminating command controls that doesn’t depend on heavy borders.

Compact Presentation

In summary, what we need is an alternative to the standard full presentation of controls, one that is more muted and compact. We still need full presentation for dialog and message boxes where controls are few. However, compact presentation should be the norm with primary windows and complex web pages.   Actually, I think you should use compact presentation for any window showing data objects or their attributes (including “Properties” dialogs), while using full presentation only for parameters in command dialog boxes. I think it would be useful to discriminate between windows that show data (possibly editable), and windows that perform a command.

Such a compact presentation should ideally have the following features:

  • Simple one-to-one coding rules for each control category.
  • Compact size to allow a higher density of attributes, approaching that of a list box or grid.
  • Maximum contrast for the attribute content and label rather than the controls themselves.
  • Consistency with conventional full presentation of controls, including links.
  • Minimized reliance on hue for coding, since that may be needed for theming, color coding attribute values, or other functions (plus, a non-trivial proportion of users have color vision deficiencies).
  • Avoidance of the use of spacing or font size or weight for coding, since that may be needed to creating visual hierarchies.
  • Workable with multi-line as well as single line attributes.
  • Workable with various relative positions of the attribute label.
  • Reasonably intuitive, such that users can naturally associate the codes with their meaning, rather it coming across as arbitrary or, worse, inconsistent with experience.

It’s not easy to meet all these criteria, but I’ve been playing around with it for awhile, and here’s what I’ve come up with so far:

  • Inert Controls. No border on any side.
  • Interactive Controls: Border or line on at least one side.
    • Action Controls: Colored (not black, white, or gray) border or line.
      • Command Controls: Rectangular border around whole control (or a group of them).
      • Links: Single underline.
    • Attribute Controls: grayish border or line.
      • Read-only: No side borders (no double side borders for multi-line)
      • Disabled: Half-high side borders.
      • Modifiable: Side borders (double side borders for multi-line)

And here’s what it looks like:Multitude of controls with light limited borders and uniform background.

If you’ve read certain other posts on this site, you’ve seen this presentation before in other illustrations (or some earlier variation of it), most recently in Taking Panes. Perhaps at the time you thought I just meant it to be schematic. But no, that’s really how I want the window to look (for the record, when I mean an illustration to be schematic, I use a font resembling handwriting, such as Technical, in order to suggest a whiteboard sketch). Or perhaps you didn’t notice anything particularly unusual about those illustrations. If so, that may be a good sign: it means you probably weren’t disoriented or confused by it, that it’s sufficient intuitive and consistent with your previous experience that you could easily interpret it. Often the best thing a UI design can do is not draw attention to itself.

The Good, the Bad, and the Ugly

It’s far from perfect, but it’s a starting point for development. There some things I like and don’t like in how it handles actions versus attributes, modifiable versus read-only, and disabling. These are all things that will need to be checked out and possibly modified with usability testing

Action versus Attribute

The use of borders to indicate Interactive is consistent with traditional full control presentation and even links, if you consider underlining a border of sorts. A single pixel non-three-dimensional border is the minimal thing you can draw that delimits a cohesive “thing,” (i.e., something the user can interact with). I’m not entirely pleased with using colored borders to signal action controls, given the criteria to avoid using hue for coding, but it’s about the only thing that comprises links (using color to indicate links was a stupid idea, but we’re kind of stuck with it now). To mitigate the effects, I use some redundant coding with background shade, making it grayish for command controls, and, actually, anything button-like, including ancillary controls for assigning values to attribute controls, such as the buttons on spinners and combo boxes. It’s consistent with conventional use of grayish (”button face”) for command controls.

To reduce the contrast and minimize size of the attribute controls to the bare minimum, I chose grayish for the borders of attribute controls, and gave single-line attributes no borders on top. The border on the bottom is consistent with blanks on paper forms, so I hope users will intuitively associate them with something that one should fill with content (or already has been filled with content). Both attribute labels and attribute contents share the same white (or whitish) background so that labels and content have maximal contrast to their background. Also, I like the idea of not using the background color of controls as a code so that these controls can overlay other information, such as a map or graph.

With both read-only attributes and links appearing with a single underline, I worry about read-only attributes being confused with links. My hunch is that the lack of hue for the attributes, plus the shade mismatch between the border and the attribute content is enough for users to regard them as different creatures. There’s a couple other things that can be done to make attributes look less like underlined text (a link) and more like a filled-in blank (an attribute). First is to put the border completely below the attribute content to contrast it with an underline which cuts through the descenders of letter. It’s only one or two pixels, but to my eye, it makes a difference. Second is to size the border such that it always extends beyond the edges of the attribute content, both left and right, to contrast it with an underline which only goes from the beginning to the end of the text itself.

If it just doesn’t work -if users tend to confuse read-only attributes with links, or vice versa, an alternative approach is to give side borders to both read-only and modifiable single-line attribute controls to make attributes clearly distinct from links. Read-only can then be distinguished from modifiable attributes by using a black (or blackish) border for modifiable and a gray border for read-only (and disabled) attributes.

Multitude of controls, somewhat less lightweight appearing.

Modifiable versus Read-only

Having side borders for modifiable attributes makes it possible to position the attribute label above the attribute control, which may have some advantages. Read-only attributes look a little odd with the label above, making it visually ambiguous where the label stops and the attribute content begins. However, I’m less concerned with read-only attributes. As far as I can tell, the advantages of having the label on top are mostly limited to the task of filling out a form one field after another, and not for tasks more likely to be associated with read-only attributes (e.g., scanning for a particular attribute or content).

The use of side borders to indicate modifiable as opposed to read-only attributes is supposed to suggest the ancillary buttons in spinners and combo boxes. Indeed, for spinners and combo boxes, one side border is the ancillary button. Given that the ancillary buttons give spinners and combo boxes a capacity to be modified, the idea is the same association of stuff-on-the-side will rub off on modifiable text boxes.

I can’t say users will guess that’s what the side borders mean. They may not even notice on their own the difference between attributes with and without side borders. However, I’m hoping that the meaning of the side borders will be memorable and seem reasonably intuitive once users learn it. It does present a problem for multi-line text boxes which need a border all the way around to delimit them. Using a double side border rather than a single side border to distinguish modifiable from read-only is an attempt to stay with the same spirit, but it doesn’t make for a simple rule. Oh, well. The alternative is, once again, to go with black borders for modifiable and gray for read-only, but I’d like to first try keeping them both gray to minimize their visual competition with the attribute labels and contents.

Disabled

Using a half-high side border for disabled controls provides a means to distinguished disabled and enabled for empty text boxes, option buttons, and check boxes. Since gray is used for the border of enabled controls, something new had to be done or else users may confuse disabled with enabled controls (this can be a problem in full presentation too -an empty read-only text box looks the same as a disabled text box). Now, I’ve written before that gray is a sacred color that should only be used to mean disabled precisely to prevent confusions like this, but strictly speaking, that rule applies only to gray in the foreground. I don’t consider a border to be the foreground. Of course, the question is, do users in general consider the border to be the foreground. I haven’t tested that yet. Besides, I like the idea of disabled (can change value, but not now) appearing as something halfway between modifiable (can change value now) and read-only (can never change value). At the same time, the foreground is grayed for both the attribute content and label, to provide redundant, if not sure-fire, coding of disabled, and also suggest disabled is qualitatively different from both modifiable and read-only (it can’t be tabbed to, for example).

Extensions

If something along these lines can be made to work for compact presentation, we could also explore some additional information that can be coded by visual design.

  • A dashed border could be used to indicate an attribute that is not committed, allowing the user to see what attributes have and haven’t been changed since the last save.
  • Based on one user I was trying things on, a heavy double-thick border may be a natural indication of a required attribute or parameter.
  • Rather than Vista’s confusing use of raise and depressed appearances, the presence of a gap between the text portion and the ancillary button in a combo box may be used to indicate that options other than those on the list are valid (this was a convention on some old Unix GUIs).

Combo boxes with and without whitespace between text and button portions.

Far from compromising to reduce real estate demands, the potential exists for compact presentation to be superior to conventional full presentation. Some may argue that the compact visual design I’m pursuing will make our windows boring, what with all this black, white, and gray, and no 3-D textures, or shiny or reflective surfaces, and soothing colors. However, to paraphrase Edward Tufte, if your windows are boring, gets some more interesting content. Don’t try to compensate by decorating the outsides of the controls. When you’re talking about high information density, the visual impact of the controls becomes a low priority, sort of like the visual impact of the pages of a book. Not a whole lot done there with colors, textures, and surfaces, is there? Does that make books boring? Now, visual design of the content, is a different story, but that’s a different post.

Summary Checklist

Problem: The conventional full-presentation visual design of controls takes too much space and competes too much with attribute labels and content when large numbers of controls are present in a window.

Potential Solution: Compact Presentation:

  • Minimal single-pixel borders to indicate interactive controls.
  • Colored borders for action controls, four sides for command controls, single underline for links.
  • Grayish bottom border for attributes, with sides for modifiable attributes.
  • Common whitish background for labels and attribute content.

Comments are closed.