Browser and GUI Chrome

What do we mean when talking about the "chrome" in a user interface design? An attendee asked this question during a recent course on Visual Design for Mobile and Tablet. Whenever someone asks us a basic question, I assume that many more people want the answer as well — and thus, this article on chrome.

• Definition: Chrome is the visual design elements that give users information about or commands to operate on the screen's content (as opposed to being part of that content). These design elements are provided by the underlying system — whether it be an operating system, a website, or an application — and surround the user's data.
• Not coincidentally, "Chrome" is also the name of Google's web browser, though I don't use the term in that sense here.

I don't know who came up with the term "chrome," but it was likely a visual analogy with the use of metal chrome on big American cars during the 1950s: the car body (where you sit) was surrounded by shiny chrome on the bumpers, tail fins, and the like.

Similarly, in most modern GUIs, the chrome lives around the edges of the screen, surrounding the middle area, which is dedicated to the user's data.

Chrome at Different System Levels

Following are some examples of chrome, which vary depending on the "underlying system":

• On a Windows PC, the underlying system is the Windows operating system. In Windows 7, the chrome consists of the Start button, the task bar, the system tray, and the recycle bin. We might also consider the gadget area to be chrome, particularly if a user simply sticks to those gadgets that ship with the system. (As many do, due to user inertia and the power of defaults.)
• When using application software, such as a word processor, the chrome is found in the menu bar, the ribbon or toolbars, rulers, scrollbars, and various specialized panes, such as Word's thesaurus bar or Photoshop's palette of color swatches.
• In a web browser, the chrome includes the URL field, the browser toolbars, the browser buttons, the tabs, scrollbars, and status fields.
• In a mobile app, the chrome often includes a status bar across the top of the screen and a tab bar with command icons across the bottom. Sometimes, there's also a navigation bar below the status bar.
• On a website, the chrome includes navigation bars, footers, logos, branding, the search box, and so forth.

Chrome Obesity: Don't Eat My Pixels

The penalty of chrome is clear: chrome takes up screen space, leaving less for the target content or data. This is particularly bad on mobile devices, where screen space is at an even higher premium than on tablets or PCs. But even on my 30-inch desktop monitor, the combined Windows and Excel chrome means that I can see only 67 rows of data in a spreadsheet instead of the 80 rows that would theoretically fit on the screen. Thus, without the chrome, I'd be able to review about 19% more data.

The spreadsheet example shows another downside of chrome: it accumulates as systems are nested within layers of other systems, each with its own chrome. Let's say, for example, that you use Facebook. Within a typical desktop browser window, the user's Facebook news feed accounts for only about 48% of the web page; Facebook's chrome and wasted screen space eat up the remaining 52%. (According to our definition, advertising isn't true chrome — because it's useless — but it's still overhead, so I'm counting it here.) When you further subtract the browser and OS chrome, the user's news feed is allowed less than 40% of the screen space.

When I analyzed a range of website homepages 9 years ago, I found that the actual content was allocated a paltry 20% of the user's screen. On today's bigger monitors, the relative overhead consumed by OS and browser chrome is less bloated, so the 40% allowed by Facebook is probably fairly representative of major websites.

Because cumulative chrome often eats more than half of our pixels, one guideline is certainly to beware chrome obesity.

A second guideline is to consider ways of temporarily hiding parts of the chrome and reveal it only when needed. Doing so is dangerous, however, because what's out of sight is often out of mind — and you definitely cannot rely on short-term memory in user interface design. Chrome that comes and goes works only if you:

• Use a simple and reliable operation to reveal the chrome (don't use gestures that are obtuse or subject to accidental activation).
• Offer rock-solid consistency so that the hidden chrome's existence is drilled into the user's long-term memory through excessive repetition and the absence of any deviations or exceptions that would undermine learning.

Chrome's Benefits

Although expensive, chrome has considerable benefits:

• Chrome empowers users by providing a steady set of commands and options that are always visible (or at least easily revealed if my guidelines are followed). Chrome also stays in the same spot, liberating users from having to locate it. Further, users are freed from the whims of particular web page or content designers; that's one reason the Back button is one of the most popular features on the web. Chrome might be overhead in terms of screen pixels, but it's power at the user's fingertips that serves as an immediate escape hatch from obnoxious or useless web pages.
• Chrome offers a set of generic commands that work on all the different types of content and data that appear within its framework. Because it's always the same, users have less to learn, meaning that they can focus on their real-world needs rather than on the computer.
• Chrome promotes consistency and standards in the user interface, which facilitates learnability and makes users feel even more incontrol of their experiences. (Of course, this applies only if you follow the standard, rather than invent your own weird chrome to confuse users.)

On balance, chrome is good for usability. Just don't overdo it.