To clarify, add detail

Several years ago, I bought Edward R. Tufte’s Envisioning Information. At that time, I was very interested in graphic design and seriously thought about switching careers (which I’m glad I didn’t). Somewhere, I’d picked up that this book was a brilliant one, so I bought it – but I never read it, although I leafed through it, looking at the illustrations (which in itself was very entertaining). Yesterday, at a loss about what to read after having finished the last book I read, I decided to finally read it.

I’m currently a few pages into the second chapter, and so far he has introduced what the book is about, namely general principles for “escaping flatland”. Flatland is the flat medium (paper, television, computer displays, etc) and Tufte speaks about the difficulties with representing, in flatland, things that aren’t flat in themselves. The general principles are: micro/macro readings – the display of structures with detail, which can either be read on the macro scale, studying the larger pattern, or on the micro scale, analyzing the details; layering and separation – about separating different information in different ways, for example by using color; small multiples – repeating elements with different information, so that the reader can compare, for example, some development over a time period; color and information, on the use of color to convey different things; and narratives of space and time, which I think is about visualizing things that expand in space and/or time.

Besides the enjoyment reading something that is written with passion (which seems to always be pleasant), I hope to be able to draw parallels between information design and software design. I recall seeing Tufte quotes in some book I read, probably one of the Extreme Programming books. The chapter on micro/macro readings deals with the false view that simpleness of design equals clarity; and he starts with an example of a stunning map over Manhattan, which illustrates an odd principle: that adding detail can clarify. The map is very clear, although it’s very dense.

In software design you often hear that designs should be simple, although this is a principle that seems to rarely be followed (most projects probably start out simple, but degenerate over time). But if the problem domain is complex, the design of the software can’t be simple; it would be oversimplification. The challenge is great for the information designer when faced with very complex data; Tufte writes:

Showing complexity is hard work. Detailed micro/macro designs are difficult to produce, imposing substantial costs for data collection, [and] custom computing [–––] What about confusing clutter? Information overload? Doesn’t data have to be “boiled down” and “simplified”? These common questions miss the point, for the quantity of detail is an issue completely separate from the difficulty of reading. Clutter and confusion are failures of design, not attributes of information.

Here’s a commonality between information and software design. In software design, you might say: Clutter and confusion are failures of design, not attributes of – hmm, you can’t say problem domain because it can indeed be cluttered and confusing; also, it would constitute the correspondent of data in information design (information being processed data; data being raw and complex). Is there a word for the outcome of analyzing the problem domain, or the body of information that is fed into the design process? In information design, you analyze and process data, which yields information; in software design, you analyze and process the problem domain, which yields “domain information”. Hmm, we’ll see if this gets any clearer as I continue reading. I’ll have to go now.