Great User Interfaces, Clarity, and Information in Parallel

In the last post, we talked about the elements of design we can adjust to match information relevance. In this post, we'll talk about another, equally important guideline to presenting with clarity, called information in parallel.

This concept is introduced in an amazing book by Edward Tufte:

Title: Visual Explanations: Images and Quantities, Evidence and Narrative ISBN: 0961392126

The book and title both look dreadfully dry. However, proof of Tufte's genius lies therein.

The idea behind information in parallel is simple. It's much easier for humans to compare and understand when they see information side-by-side, rather than when the same data is presented in serial. This is crucial for user interfaces, because the very nature of software -- representing a large amount of information in a constrained space -- lends itself to solutions that tend toward the presentation of information in serial.

Take for example, the trusty standby, the modal dialog box. Since the age of windows, modal dialogs have been with us. Two questions:

1. Have you ever clicked the mouse down on the title bar of a modal dialog, the dragged it off to the side just so you could see something underneath it?
2. Have you ever clicked the Cancel button on a modal dialog, just so you could access information behind it (perhaps copy some text to the clipboard),  information necessary for successful interaction with the dialog itself?
3. Have you ever had to click the Back button on a browser, to see a previous page, just so you could then immediately click the forward button to use that information on the current page?
4. Have you ever had to scroll up when viewing a document, just so you could see information above necessary to understand the information below?

If you answer yes to any of these questions, then you may be the victim of information presented in serial.

Examples of information in serial include:

• Audio podcasts
• PowerPoint presentations
• Stacked modal dialogs
• Wizards
• A long paragraph of text.

So far in covering the science behind great user interfaces, a number of comparisons have been presented using information in parallel. Some examples you may remember:

A failure of efficiency in Why is Great UI so Hard to Achieve?:

A failure to match visual weight to information relevance, from a table in Microsoft Word, from Great UI, Clarity, and Information Relevance:

An illustration showing how adjusting too many elements of emphasis (e.g., saturation, size, and contrast) can lead to visual noise, in Great User Interfaces, Clarity, and Emphasis:

Let's compare information in parallel with information in serial, to see how they differ.

Information in parallel is more effective than information in serial, because it can be exploited by our eyes which are excellent at quickly moving back and forth. All layers are simultaneously visible, and the viewer has full control over the pacing and the sequence in which information is understood. Information in serial, on the other hand, burdens the viewer with pacing challenges (information may arrive too quickly or too slowly). Viewers also have no control over the sequence of presented information when arriving in serial.

That last paragraph was an example of information in serial.

Here's the same data presented in parallel:

A viewer can...	Serial	Parallel
Control the pacing of information:	No	Yes
Control the sequence of information:	No	Yes
See all information simultaneously:	No	Yes

Notice when information is presented in parallel, our eyes can move back and forth, easily and quickly comparing data in the columns at a pace that feels right.

One note about pacing and information in serial: Sometimes UI provide viewers with a mechanism to control pacing, as in the example of a wizard dialog that allows you to navigate forward or backward through its pages. This all comes at the expense of introducing an interaction mechanic (e.g., reaching for the mouse to click the Next or Back buttons) that is likely to be far less efficient than simply shifting gaze, which is all it takes to control pacing with information in parallel.

So the goal is to take a serial interface (e.g., stacked modal dialogs) and flatten that out. How can we do this?

Well, it isn't easy. It often requires careful thought applied to layout as well as an understanding of what information is essential and needs to be readily available, and what information is less important. Sometimes it requires innovation, in the form of new user interface elements. Let's look at an example from the world of software development.

Let's say your challenge was to create a user interface that assisted developers in reordering parameters in a method declaration. Using traditional software-building tools, you might crank out a modal dialog that looks something like this screen shot taken from Visual Studio 2008:

There are good things here, and there are also some undesired consequences. Let's talk about the good first. There are two:

1. The dialog appears under the method you are trying to rename, so that the source code you are trying to change, as well as the dialog itself, are both in view. This is information in parallel.
2. The Preview method signature box shows the impact of your changes before you apply them. This is also information in parallel.

Next, the issues:

1. The dialog hides a significant amount of otherwise visible code in the document. When a window hides information below it, this is information in serial.
2. The user model changes. Developers are used to working with the keyboard and source code, but now developers have to adapt to a new unfamiliar model, one that uses a grid, buttons and mouse clicks to manipulate code.

So, how do we flatten this down? Is there a way to remove the dialog completely, yet still allow interaction with a preview before changes are committed? The answer is yes. Here's how we do it:

1. Move the UI elements down to the lowest layer of the UI (the source code, in this example).
2. Introduce a similar state-like ability for the interactive phase (where developers can reorder the parameters without reaching for the mouse and without having to adapt to an unfamiliar representation of method signatures).

That UI might look something like this:

On the good side, we've removed the modal dialog that blocked out so much of the code. And we've introduced an interactive phase that allows parameters to be reordered without reaching for the mouse (efficiency gains) while keeping a familiar representation of the data (clarity gains). On the downside, in keeping with the familiar representation of the code and losing the dialog, this in-source interactive phase will no doubt be an unexpected surprise the first time developers encounter it. So we compensate, improving discoverability by adding the shortcut hints window in the lower-left.

So yes, flattening the UI can take some effort, and even the introduction of new UI elements or states. However the gains in efficiency and clarity (and sometimes even discoverability), can make it all worth it.

Free DevExpress Products - Get Your Copy Today