Blogs

Mark Miller

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:

TufteBook 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?:

TwoPaths3

 

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

 BothTablesSideBySide3

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:

 VisualWeightRansom2

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:

ReorderParametersVS

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:

ReorderParametersInRefactor2

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.

Published Feb 17 2009, 09:03 AM by
Filed under:
Bookmark and Share

Comments

Dew Drop - February 18, 2009 | Alvin Ashcraft's Morning Dew

Pingback from  Dew Drop - February 18, 2009 | Alvin Ashcraft's Morning Dew

February 18, 2009 11:22 AM

Jason

Speaking of clarity, I don't recommend putting your images side-by-side. The right images are being cut off. Unless your browser is maxed on a 19" monitor.

February 18, 2009 5:27 PM

Mark Miller

In our last post, we saw that information in parallel allows viewers to more efficiently understand data

February 19, 2009 3:05 PM

Jonathan McComb

Firstly, I am loving these articles.

Secondly, I've just started using CodeRush and RefactorPro and that text "Num Enter or Enter" in the shortcuts window always confuses me. It's enough to make me click Esc and do it on my own. Maybe it's just me.

Why not just go with "Enter" and let people discover that Num Enter works as well if that's their preference? Or, reduce the contrast on "Num Enter" and make it the second option?

February 19, 2009 9:34 PM

Ivan

I don't really understand the examples given but if i'm not wrong,what you are trying to say is that all info in table(point form) is better than in paragraph

April 27, 2009 4:41 AM

About Mark Miller (DevExpress)

Mark Miller is a C# MVP with strong expertise in decoupled design, plug-in architectures, and great UI. Mark is Chief Architect of the IDE Tools division at Developer Express, and is the visionary force behind productivity tools like CodeRush and Refactor!, as well as the DXCore extensibility layer for Visual Studio. Mark is a popular speaker at conferences around the world and has been writing software for over two decades.
LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, Silverlight, ASP.NET, WinForms, HTML5 or Windows 8, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2014 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners