1. Represent different metadata consistently.
2. Attributes that are continuous, linear spectrums should be represented as axes along which the data is plotted. ie. Dates, relative priorities, relative preferences,

Compare this with a list of items that are labeled with alpha-numeric dates. There is a lot to parse in order to understand the relative order of the dates.

Most visual displays of data give short shrift to the physical location of information in space. A terrible waste of a very effective opportunity to chunk data down. By assigning semantics to the location of data in space, you are finding yet another way present metadata to the user in a visually distinct way.

For example the New York Times has a rigidly consistent layout which communicates a lot about the content of the articles without requiring you to read a single sentence or a single headline.

Articles found above the fold in the middle of the page are always the Top headlines and generally considered News....etc...(find analysis of NYT layout).

However, semantically meaningful areas can be chunked down even further by assigning consistent semantics to the 2 dimensions of the screen. Reading one axis at a time, the user can easily chunk down their data to a boolean statement.

Everything to the right of center is in the Future. Everything to left is the Past.

It also becomes very easy to understand the relative placement along the axis of any two items in the data set.

This lends an easy to understand uniformity to the presentation of metadata. Physical location along each axis of the screen now represents the same attribute or facet, which is much easier to understand than 8-10 area plots representing a motley crew of attributes or when location represents nothing at all.

Case study: Maps

• Taken from CA map by Raven maps
  

Here is an enormous amounts of data consistently and meaningfully visually chunked and therefore eminently grokkable.

At the highest level, there are clear distinction between: Municipalities, Roads, Rivers and Topography

Municipalities are further sub-typed into: Capitals, Cities, Towns, Villages and Hamlets
Roads are further sub-typed into: Interstate highways, State highways, Highways, Roads, Streets and Dirt-roads.
Rivers are further sub-typed into: Rivers, Tributaries, Streams and Creeks
Topography is further sub-typed into: Water, Valleys, Mountains and Man-made

All of this data would be much harder to understand if it was presented in a tree of folders.

The data becomes knowledge when it is laid out in a semantically meaningful way where Up, Down, Right, Left translate readily into North, South, East, West. The mapping of the x and y axes to the North-South and West-East axes is a particularly good fit. There will be few

In other words, the semantic encoding of the dimensions of physical space is the visual counterpart to the spectrum group. Once you've set up a homogeneous, continuous concept, it becomes very easy for the user to Get and Forget. (need to explain this more.)

Given that we are primarily concerned with software, we are limited to a two-dimensional information space.

Case study: Mind-map visualizations

• Taken from Thinkmap's Visual Thesaurus
  

There's a lot of mind-mapping interfaces out there right now (a la visio) that attempt to execute on Alexander's dream of a world accurately reflected in org charts, file systems and library catalogs as semi-lattii that emphasize relationships over hierarchy. But many of these mind maps are in the end sometimes more limiting and less meaninful, less expressive than they're traditional treed counterparts. For example in the visual thesaurus above is the one of the best, most visually compelling mind maps I've come across. The physical arrangement of synonyms and antonyms is engagin, draws you in. Presumably size, proximity, saturation and relative location to the focal word all express the many complex, overlapping relationships of words related to "pilot." Synonyms are green, antonyms are pink. (Side note: I'm assuming the color coding maps to GREEN=GO=YES and RED=STOP=NO. However, pink is just different enough from red that it makes the visual affordance meaningless, red communicates NO or NOT precisely because it is so glaring, raucous and harsh. Here the designer softened the red to pink to make it more visually pleasing and as a result also rendered the color coding meaningless and downright confusing.)

At a glance, the visualization offers a rich world of meaning and relationships. The physical arrangement of words (Left, Right, Above, Below), size, proximity to focal word and saturation express tenfold the information offered in a standard Roget's entry in paragraph form.

After the first few moments however, the selfsame visual cues that seemed to burst forth with meaning begin to feel meaningless, random, disorienting. There is no clear explanation or narrative explaining what the various visual cues actually mean. Each cue represents a certain kind of relationship, but the visual cue doesn't really naturally map to the relationship it represents. Proximity might mean closeness in meaning. But then what does size or saturation or relative location mean? On maps relative location (ie N, NNW, SEE) is a natural affordance that maps elegantly to reality. But what does it mean with respect to words in a thesaurus? Clearly there are several trees overlapping simultaneously to form a complex semi-lattice. What's not immediately clear is the meaning of each tree and the how / why narrative of how the trees overlap and interact? The semi-lattice exists without an obvious story to tell: no build up, no break down, no context. There exists potential expressiveness in the semi-lattice, but in the end the semi-lattice is stone-faced, layers of information trapped beneath an uncommunicative interface.

Even if the user were able to decipher the meaning encoded in the visualization, there is still too much information to take in all at once. Our brain is the bottleneck, we can't fit such large unweildy, growing in all directions at all times things through the door into our heads. Instead we need to feed our brain in series: linear (or at most planar), skinnier trees, oversimplied, presented in bits and pieces as if all the world were a tidy sequence.

To sum up, 3 reasons why visual information mapping hasn't already taken over the world:

1. It's extremely hard to do right. Each visual map has to be custom made and the person making it needs strong visual skills. Whereas a tree is one size fits all and extremely easy for anyone to put together.
2. It takes up too much space and oftentimes expresses little more than a tree or a table.
3. Overhwhelms users because they're hard to read and present too much information at once without in-place, explanatory narrative.

Getting PIM data back to a state of nature

Where is PIM data too generic? Where do we need to provide differentiation in how we present PIM data to users? Where do we need to provide users with the ability to build differentiation into their data?

PIM data and PIM metadata, like most data, is encoded and presented as alpha-numeric strings. Making it easy for computer to quickly parse their meaning, but very hard for humans to do the same.

As a result, who an email is from, what an email is about and

Most PIM data systems DO NOT allow users to generate ad-hoc facets or attributes to better describe their data. Instead, users are provided with blunt, but infinitely flexible instruments in the form of Folders and Categories or Labels with which to satisfy all of their organizational needs.

But as we have reaffirmed in the course of this paper, folders, cateogories, labels, tags, whatever you want to call them are all essentially variations on a single theme, and that theme is generality. And generality, as we have just demonstrated, sounds the death knell for the human capacity to discern patterns in large sets of data. In other words, PIM data is generally too hard to make sense of much beyond the scope of a single item or a few items at a time.

Another problem is that relationships in most data systems are generalized as well.

• Hierarchies have parent-child relationships and sibling relationships and nothing in between or beyond.
• Faceted systems have intersecting facets and siblings within a facet.
• Tags, well tags have the all-inclusive "is related" relationship. Doesn't get more generic than that.

Relationships in a state of nature

But what about relationships in the real world?

Scenarios

• Economics and Sociology are siblings that overlap: both are Areas of study or Disciplines.
• Modern, Occidental, Fine arts are independent facets that intersect.
• Feet and Toes are a variant strain of Parent-child relationships. All things that have Toes also have Feet, but all things that have Feet, don't necessarily have Toes.

"Big Announcement" and "re: Big Announcement" is an example of yet another type of relationship that is not Facets, Siblings or Parent-child though it is usually modeled as a Parent-child relationship. It is a thread relationship where "re: Big Announcement" is not some sub-area of "Big Announcement", but a response to it. In threads, ordering is of primary importance, but the items themselves are on equal footing, more siblings rivalry, less filial devotion.

Differentiating between the relationships between items is as important as differentiating between the items themselves. It is yet another way to help people recognize and understand patterns, where 101 "generic relationships" can be chunked down to 5-6 types of relationship.

In the "real world" there is no such thing as the generic "isRelated" relationship. Whenever humans talk about relationiships, there is always some context to the relationship to make it comprehensible. It's only when we're "fuzzy" about why 2 things are related that we resort to generic descriptions: "I don't know why, but in my gut, I feel like these two things have something to do with each other."

So, a "fuzzy" understanding of their data is what users get out of software that presents data relationships to them as generic "isRelated" relationships that are agnostic to relationship type. And sometimes "fuzzy" quickly turns into overwhelming or incomprehensible or I give up even trying to really understand this, I'll just click around and see what I end up with.

I think this is actually what happens to all of us, even when we interact with software we're reasonably happy with. But this is only because we don't really expect very much out of the software to begin with. We don't really expect to be able to wrap our heads around all that data and understand what it all means at a high level. We're satisfied if we can just click around and find the one thing we thought we were looking for and maybe chance upon something interesting and related along the way.

The end result...

...is hopefully a system which presents data that is loosely structured by the data system based on an aggregation of relatively simple user actions (ie. tagging and describing items) to users that is meaningful and easy to understand

1. Even though we want to present as much data as possible, the data should always be easily parse-able into no more than 5-6 chunks, any way you slice it and at every level of the structure.

1. Unlike a fixed hierarchy, what constitutes those 5-6 chunks and how you proceed to sub-divide those chunks should be flexible and up to the user to decide and freely change.

1. In other words, leave people to build their own inferences and data structures IN THEIR HEADS, ground-up from the data presentation. Don't force the data into some kind of organizational structure. Don't force the user to explicitly hard-code structures into the data itself. Ultimately, data structures in the mind are more readily processed and easier to change than explicitly expressed structure.

We've come full circle. What we're proposing the UI should do "automatically" through intelligent presentation of data is what people are already doing today. The only difference is that today, users must do these things explicitly, make explicit groupings in an attempt to capture patterns they've detected by painstakingly parsing each individual item into permanent folders so that they don't have to re-parse the same information again in the future. The problem is that over time, the explicit groupings themselves become too many in number and too short on distinguishing characteristics to be easily parsed.

The hope is that the patterns and structure that emerge naturally from well-presented data are similar to the ones users explicitly encode into hierarchical structures today.

Alec Flett, of OSAF Apps Team fame is currently working on a ...... This sets us up with an interesting feedback loop for testing the efficacy of both our efforts to successfully visualize data such that natural patterns emerge in a bottoms up and successfully structure data with an algorithm in a bottoms up way. In other words, it will be interesting to see if Alec's algorithms and our data visualization UIs yield the same "chunks".

Case Study: Chandler Sticky planning

The use of color

How to communicate rank ordering

Overlaying different attributes to find relationships

Top-down and Bottom-up organization