Chunking over time

Thus far we've spoken exclusively of the importance of chunking items within the 2-dimensional space provided by the screen. But what of the chunking of data through the dimension of time? Certainly if we find it hard to absorb more than 7 +/- 2 pieces of data at once, it is even harder to keep track of the information we experience even over a short period of a few minutes.

This is where chunking over time or having clearly defined relationships is of primary importance.

Case study: Hierarchies

In the hierarchy below, there is no apparent rhyme or reason for the way in which sub-folders and sub-sub-folders are arrayed, making it difficult for you to predict as you navigate through each level of the hierarchy, what sub-levels will appear. It also makes the hierarchy as a whole, difficult to grok once you opened up a few branches of the hierarchy. You're presented with an array of relationships and no easy way to chunk them down.

* Outlook.png:

Counter Case study: Semantically pure hierarchies

In contrast, iboth the example of the Closet hierarchy and in certain portions of the DDC hierarchy, there is a strict predictability to the relationships between one level of the hierarchy and the next level of the hierarchy.

In the case of the Closet hierarchy it is: Occassion>>Mood>>Anatomy>>Layer

• closet_hierarchy_vertical.png:
  

In the case of the DDC hierarchy, parts of the hierarchy are semantically pure: Area of study>>Geographical location.

• generalities.png:
  

Relationships in a state of nature

This is essentially a discussion about chunking relationships in organizational systems into types.

• Hierarchies assume 2 types of relationships: Parent-child and Sibling
• Faceted systems assume 2 types of relationships: Intersecting facets and Siblings.
• Tag systems assume 1 uber-generic type of relationship: Intersecting tags or isRelated.

All of these systems assume the only relationships worth keeping track of are relationships between groupings of items, not items themselves.

Do any of these systems reflect reality?

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 identify and patterns in the data so that they can chunk it down into the 5-6 groupings they need in order to grok the information.

The "isRelated" generic relationship between overlapping Tags fails to map to real world realities. Again, by genericizing the data model, there is a loss of metadata, a loss of the semantic description of how two Tags are related to each other.

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.

Case study: Mind-map visualizations

In recent years, there has been a lot of innovation around more organic presentations of data in the form mind-maps and concept maps.

• You begin to wonder if it's just a big waste of space,
• What would be the difference between what you see below and simply listing the related links in a list view?
  • http://hublog.hubmed.org/archives/001049.html
  • http://www.thebrain.com/
  • http://www.visualthesaurus.com/
• This is because there are no semantics to where the related links fall either in relation to the 2-dimensional surface of the interface or to each other. It's a visualization, but there's no meaning to the visualization.
• A different way to say this is that there are no distinctions between relationships. We're back to the generic "IsRelated" relationship.
• Again, the lack of "chunking" with respect to types of relationships means a lack of chunking over time as you navigate through related items.

Comments on above Mindmapping Notes by SethJohnson

New comments to summarize the comments below, from January 21:

What I think I'm saying is that you can have a generic data structure and also have semantics. Mindmapping software does not currently have this, but there's no reason why it can't be added. The "IsRelated" generic relation can be expanded to terms that allow users to apply specific semantics to specific relations. Instead of:

"this node is related to these children"

we have:

"this particular use (Make a birdhouse) of this particular use type (Woodworking project) has these particular links (get some wood, measure it, cut it, hammer it together) of this particular link type (Project steps)"

When people begin sharing contexts defined by these abstraction they will begin using common use types and link types, thereby allowing chunking over time that's interoperable. One user will be able to chunk over time any way she pleases, and at least when it comes time to interoperate, you do still have the generic notions, so people can ask each other, "Okay, so what is your use type/link type/etc. here?"

Mindmapping in which each branch with children can be designated with specific use types and link types, making each such "forks" unique relations, would let you play with information and also begin to make information usable across particular contexts.

Add to that the ability to visually represent specific such combinations of use types and link types in their own assigned default ways. Then make the visual interface (whether mindmap, email folder, Gantt chart or any other visual interface) provide access to the use types and link types of the relations.

This doesn't answer the design question of how to visually represent such disparate types of relations, whether all at once in one interface or in separate ones, but I hope that it does give an idea how you can have completely generic relations and semantics at the same time.

Now, regarding mindmapping: this interface gives users the ability to arrange things visually to see relationships by grouping -- and to work with and access information that's in flux as far as how it will ultimately be organized -- even if to the application there are no special semantics to the relations being created. Now, to add semantics to mindmapping as I describe above and below, would only augment the traditional mindmapping concept and interface -- as well as all other interfaces. Plus provide the data structure for chunking.

One note: taking chunking as a function of our human ability to comprehend visual information, we can observe that mindmapping naturally leads to that, though without semantics in the traditional form.

-- SethJohnson - 31 Jan 2006

• The difference between those interfaces and listing is not in the conveying of information, but in the manipulability and the overview that gives you comprehensive sense of the totality and relations (not in db terms; I mean by spatial arrangement).
• One of the key things is really the lack of semantics to prejudge what's going to happen to the nodes. There is meaning, even if only to the user (if we're speaking of apps that are used for manipulating and grouping information) -- and even then, grouping and positioning certainly helps others get a sense of the organizing principle of a mindmap. Now, when it comes to the app having and making use of some conception of what's going on -- that's a good question, that's not necessarily addressed as such by the principles that govern the mindmapping interface (no presumed semantics beyond parent and child branches).
• However if we regard the center node as one parent record of a certain type and the branches as children records of another type, then that relation defines a particular notion of what the purpose of the whole is -- the center node is a type of use, and the branches are of a certain type of link.

Now, add to this the abstractions that make up my notion of a "context." If users can designate the kinds of relations (link types), then they "own" the semantics. There's no reason in principle why subbranches could not be treated as linking to other such contexts, sets of relations of use types and link types. Users could do this along with the visual structuring. Since link types are reusable, that provides for chunking over time.

See my comments to the Design list regarding relations and mindmapping.

Here, what I would observe is that it appears you're looking for what set of categories or functions (and on that basis what sort of visualization) would be best or most useful (here with respect to the abstract problem of grokking heterogeneous data).

Try thinking in a slightly different way: Is there a simplified generic way of thinking about heterogeneous data? Then can that be a guide in thinking about representation? Mindmapping is one way of representing a very generic view of data -- think of it as relations. Now, I recommend expanding that to a level of generality that gives a good general concept, while also enabling you to encompass all the data management functionality that's needed. I recommend thinking of "contexts" as an extended, more abstract version of the basic idea of "relation."

Then you can provide tailored interfaces of all sorts, while also having recourse to the most generic notions, which can be key aspects of the visual representation/interface. A mindmap with a menu that lets you select contexts, plus other visual representations, gives you that.

-- SethJohnson - 20 Jan 2006