High-density Information Display

Examples:

Email software that shows long lists of stored messages, e.g. Netscape or MS Exchange
Good maps, such as the USGS topographic maps and NOAA charts
Large, detailed object diagrams for object-oriented software

Context: There is a need to convey lots of information, either of a homogeneous type or interrelated in some way, but all of roughly equivalent importance.

Problem: In what form should the information be displayed to the user?

Forces:

The user wants to quickly find specific information.
The user also wants to quickly get a "big picture" of what the information is about.
The user shouldn't have to do any more thinking, or manipulation of the artifact, than is absolutely necessary.
The user may be frustrated, or led to a poor decision, by not being able to see all the available information.

Solution: Pack as much information into one working surface as possible, following the precepts of good graphic design, with an organization that accurately reflects the underlying structure of the information. Make the information dense enough so that the eyes do not have to move far from one thing to another, and so that scrolling is unnecessary whenever possible. Sparingly use bright color and/or imagery to highlight specific objects or state information relevant to the task at hand, so that the user doesn't have to read text or scan linearly to find important things. Use negative ("white") space or subtle color, rather than boxes or lines, to organize the information. Don't be shy about using large areas, or small fonts, or tiny controls and peripheral things if the information display is the most important task of the artifact.

Resulting Context: This is a rather high-level pattern; you are still left with a decision on exactly how you present the information. The answer partly depends upon the information's structure. If it's a hierarchy, for instance, you could use a Hierarchical Set. If the information is geographically structured, a map might be appropriate. Data sets of high dimensionality demand more sophisticated display techniques, often leading designers to combine the three spatial dimensions, color, and time; for very complex data sets, you may want to create Navigable Spaces that let the user wander through the complete information space.

The rest of the answer depends on what the user is trying to do -- whether they need qualitative or quantitative information (or both), for instance, or whether it's more important to find one datum, or to see that datum in context with the rest of the data, or to get a big picture. If quantitative information is needed, and the items to be presented have a similar substructure, then a Tabular Set may work well (and it can be creatively combined with other kinds of views, such as an outline). Or use Chart or Graph to give a visual representation to a "flat" data set, especially when a strong qualitative sense of the data is needed.

Notes: When a great deal of information is well-organized and presented in a visually reasonable fashion, the human mind is amazingly good at viewing it all, finding specific pieces of information in it, and getting the big picture out of it. Try to take advantage of human cognitive skills to enhance the data display.

It's easy to confuse "too much clutter" with "too much information" -- it's likely that most cases of the latter are actually misunderstood cases of the former. If a user complains to you that "There's too much stuff to see at once," see if the problem isn't really that it's just badly presented: too many boxes (imagine a 50x10 grid of white edit boxes on a gray background!), too many or too few colors, a hard-to-read font, poor use of negative space or widgetry, etc.

For good discussions of these issues, see Edward Tufte's books, particularly The Visual Display of Quantitative Information and Envisioning Information. Ben Shneiderman's latest edition of Designing the User Interface has an excellent chapter on information visualization, with plentiful examples from the software world.

Comments to: jtidwell@alum.mit.edu
Last modified May 17, 1999