Status Need to figure out how to tie this page in more closely with the previous one about Time, in particular, how Hierarchies fail because they don't separate Organization from Structure.

Given the realities of real data in the real world and how real people interact with, use and understand information...How well do Hierarchies hold up?

Generally poorly.

1. Hierarchies conflate organization and structure. The only way to describe items so that you can find them later is to put them into a folder somewhere in the tree. And if that folders gets too full and you want to describe some subset of items with more specificity, you do that by creating a sub-folder in the folder and moving the items into that. In other words, you organize by adding structure to the hierarchy.
2. Once the structure has been added, it's very hard to undo or change.

The combined effect plays itself in various and sordid ways that usually end poorly for the user, saddled with an unwieldy, un-navigable, inconsistent hierarchy that is hard to file things into and hard to extract things out of and pretty much opaque and unyielding as far as getting any kind of big picture sense of the data is concerned.

Hard to describe data in hierarchies

• No dedicated workflow for describing data. Data is described as a result of the way you group items in the structure
• The way you happen to group items in the structure is generally on an as needed basis...which unfortunately changes over time
• As a result the structure you build, is not necessarily the best for describing an item so that you can find it again

• Example: Transition planning>>Proposal review, Logistics, Planning, Move details
• Proposal review is a temporary grouping, pulled together in preparation for a meeting
• The others are project area groupings
• I have an item that is a Logistical detail having to do with the Move, which should

Real people have different semantic encoding requirements for different branches of the tree...therefore, items lose semantic data if they are moved between branches with incompatible semantic structures

• Case study: FN's Laundry pile needs to be optimized for doing Laundry, not getting dressed
• Laundry>>Material>>Color family
• However, whenever FN moves an item of clothing from his Closet to the Laundry, he loses all of the semantic data encoded in the Closet hierarchy: Occasion>>Mood>>Anatomy>>Layer. Actually, he loses all those semantics as soon as he takes the clothing out of the closet and puts it on.

• Case study: Katie doesn't want to replicate her entire Project hierarchy under the Done branch of her OmniOutliner tree for several reasons:
• She doesn't have that many Done items to warrant such a huge tree
• She really wants to have easier access to her Done items, without having to dig 3 levels deep into a Project hierarchy
• It's a pain in the butt
• BUT, if she doesn't replicate the Project hierarchy within the Done container, she loses semantic data encoded in the Project hierarchy, every time she moves an item from the Project branches to the Done branch
  • Katie's Omnioutliner.png:
    

Users need to browse their data in different ways

• The Closet hierarchy, with it's emphasis on pulling together a particular ensemble for a particular event is not optimized for other scenarios such as targeted retrieval of a single item of clothing: ie. that favorite pair of shorts.
• Instead, the Inverted tree where Anatomy and Layer are at the top of tree is the optimal organizational structure to guide you to that favorite pair of shorts.
• Finding_tree.png:
  

Stuff I need access to DOES NOT HAPPEN TO EQUAL the stuff at the top of the tree aka Hierarchies are bad at Favorites*

• Case study: Katie's OmniOutliner
• To achieve a semantically pure hierarchy, Katie would not only need to replicate the Project hierarchy under the Done branch of her outline, she would also need to nest the Project hierarchy within a Not Done container, such that the top level of the hierarchy can cover the full spectrum of the Status dimension
• To Katie, this would bury her Project in yet another layer of unecessary
• Similarly, Katie doesn't want to bury her Done items in 2 layers of unecessary Project hierarchy. But if she doesn't she looses the semantics of the Project hierarchy.

---

• Footnote: Attempts to shoehorn alternate organizations of data into a single hierarchy muck up the guided navigation experience
• Case study: Yahoo! related links also break the story of the hierarchy...back to being a mole rat
• Want to see things by Anatomy? Drill down to the Anatomy level and travel horizontally across the hierarchy to visit all Anatomy containers
• This feels manageable with something simple and orderly like the Closet hierarchy
• But mole-rate syndrome settles in pretty quickly with something as huge and unwieldy as the Yahoo! directory, Amazon, or our very own wiki...Basically any hierarchy that is semantically impure and therefore hard to grok completely will get even messier with links.
  • When you walk the tree in an orderly fashion, you know exactly what parts of the spectrum you've looked at, in each level of the hierarchy
  • You also know what parts of the spectrum you've decided not to look at, in each level of the hierarchy
  • When you jump around the tree via links (or wormholes), you lose the context of an orderly perusal of the tree
  • This is the difference between looking for a missing document in a file cabinet in an orderly manner, one folder at a time from A-Z...as opposed to jumping around. It's hard to know what you've looked at and what you haven't looked at.
• As we'll see shortly, this foreshadows a similar problem with navigating tagsonomies

• The following are images taken from: http://www.shirky.com/writings/ontology_overrated.html
• hierarchy_lots_links.jpg:
  
• just_links.jpg:
  

---

Take home: Because hierarchies has been the designated one size fits all solution to all our organizational needs, we break our semantically pure hierarchies by overstretching their bounds. As a result, we end up with messy hierarchies that are unusable and unmaintainable.

• We encode different parts of the hierarchy in different ways (ie. Closet v. Laundry, Katie's Projects v. Done)
• We bubble up favorites to the top of the hierarchy
• We use things like Desktop aliases or Yahoo! or Amazon-style "See related links" to travel the hierarchy in alternate ways

[Messy hierarchies are bad at everything.]

• The more varied the data the messier hierarchies become
• The faster the data changes the messier hierarchies become
• Unfortunately for most PIM client users, these are the 2 main characteristics of PIM data

• Case study: Outlook.png
  • Notice the mixture of different semantic encodings at each level
  • Notice the incomplete spectrums:
    • There's a folder for "For Followup", where's Done and No Followup Needed?
    • Rejected companies? Where's Accepted and Pending?

• The screenshot below is a real-life Outlook sidebar of someone who works in the tech industry but isn't a programmer or someone who feels particularly tech saavy.
• The sidebar consists of 5 levels of hierarchy that span 5-6 different attributes: Kind, Sphere, Status, Who, Project Area, etc...
• The levels of the hierarchy are semantically impure:
  • I've color coded the sidebar such that each level of hierarchy is a different hue family: Blue, Violet, Orange, and Pea Green
  • Within each hue family, different attributes are assigned different saturation levels. From the variegated distribution of saturation levels within each level of the hierarchy, you can see that it's very inconsistent.
• Outlook.png:
  

• Messy hierarchies inaccurately represent data
• When the levels of the hierarchy are consistently encoded with the same semantics across all of the branches of the tree, it is easy to see the facets in the hierarchy
• hierarchy_facet_verticals.png:
  

• Ideally, you want to visually represent facets and true parent-child relationships differently.
• parent_child_versus_facets.png:
  

• However, when the levels aren't consistent, you can't tell the difference between true parent-child relationships (ie sub-folders) and semantically-encoded hierarchical levels (ie. consistently semantically encoded child folders that cut across the entire tree). Because actually, very few things are truly sub-things. Most things are facets.

Even if people could be perfect...

Nobody would build a semantically pure Hierarchies like the Closet hierarchy, it's just too much work.

• Look at the number of folders in that hierarchy: 2,142
• Requires foreknowledge of what the different "container types" or facets will be
• Requires foreknowledge of the "optimal" way to structure the hierarchy. Mistakenly assumes that there is a single optimal way.
• Requires a lot of duplication of containers at the lower levels of the hierarchy in order to consistently implement Facets across the Hierarchy