r16 - 25 Jan 2009 - 07:13:46 - GrahamPerrinYou are here: OSAF >  Projects Web  >  UIDesignArchives > BrowserDesign

Browser

Status Presented to the Design team. Need to work out modeling issues with Mitch 1-on-1. Need to add:

  1. Discussion of orthogonal buckets
  2. Further explanation of how the visual thesaurus is an attempt to visualize the entire semi-lattice all at once

Chao pointed me to Christopher Alexander's A City is not a Tree, a diatribe against the simplifying organizational tendencies of the human mind. Trees abound in modern organization, from hierarchical org charts to computer file systems to book stores and supermarket aisles. Hierarchies are sometimes broken (ie strawberries sitting suggestively next to an Entenmann's poundcake and cans of whipped cream, Apple Menu>>Recent Applications, Amazon.com's "People who bought this...also bought that...") On the whole however, trees prevail. They are easy to create and easy to understand. Yet they clearly limit us as well. Pyramidal command chains, planned communities, communes, search algorithms: all too strict, too dry, too simplistic for the real world.

Reality and the human brain's ability to grok it are far more complex than a tree. Alexander calls it a semi-lattice. Read his essay for more context but the basic thing to know is that semi-lattii allow areas of overlap whereas trees do not. As a result, semi-latti are more expressive, more complex, more true to the truth of reality. Trees imply that data, bits, entities live in a 2 dimensional universe (all things have either parent-child or sibling-sibling relationships) of self-contained containers. Semi-lattii imply that all things intersect, overlap, intertwine, entangle, forming a web(s) of relationships in n-dimensional space.

If semi-lattii are so much better, why the prevalence of trees? The culprit(s): the simplifying, organizing tendencies of the brain. Presented with thingmabobby X, the human mind will invariably try to break it down, distill to its simplest form, even if our attempts to understand thingmabobby X, ultimately distort it beyond recognition. Marxism, capitalism, fascism, Global Climate Models are all examples of human attempts to grok reality via a tree. Overwhelmed by the complexity of nature, society, ourselves, we resort to cliff notes, the executive summary, pithy expressions that ultimately fail to express the true nature of bigger, hairier, more tangled issues.

Alexander positively condemns this natural human tendency. He calls it the "mania of every simple-minded person for putting things with the same name into the same basket." He recommends we all do some serious self-criticism and try to purges such urges from our brain's daily interactions with the outside world. It's an admirable goal, but I'm thinking, why fight it? It's the way we are. Fighting the hardwired hardware is too hard. Let's improve on the software. Besides, dumbing down isn't always a bad thing. One could argue that you don't really understand something unless you can explain it in 5 words. The key is not to go overboard. We need to keep the following in mind: just because our brains like to see things as trees, doesn't mean that things really are trees.

Random thought from Mitch: Mitch pointed out that trees have a direction, there's a top and a bottom and you can go from top to bottom. Semi-lattices are non-polar, where do you start, where do you end? at each intersection there could be n-choices. Caveat: Trees with too many branchings can get just as confusing.

Mind mapping for the 21st century

  • visualthesaurus.gif:

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.

This is not to say that the semi-lattice is an intrinsically flawed way to present information. In the end, it is really the ONLY way to present information. It's simply hard to do. Figuring out how to express the full complexity and richness of information in 2-D is predictably a complex endeavor.

Maybe Semi-lattii all at once is BAD, but Tree+Tree+Tree=Semi-Lattice might be GOOD
On the other hand human brains ARE really really good at seeing relationships, oftentimes relationships that break the tree. Clearly our trees are breaking already. While it is difficult for the human mind to imagine or interpret multiple trees at the same time (aka semi-lattice), we ARE extremely adept at looking at the same data and reorganizing it into different trees in rapid succession (aka linear doublethink or stop-motion semi-lattice building). (Or at least that's what's meant as being able to keep an open mind.) Unfortunately technology thus far has for the most part discouraged linear doublethink, forcing us to look at our data in one tree, organized in one file cabinet, on one bookshelf, in one way.

Challenge: Find balance between trees (too simple, not expressive, distorts the truth) and semi-lattii (overwhelming, incomprehensible, expressive but often not communicative).

Proposed solution Stop-motion trees. Morphing trees. Animated trees. Flexible trees that result in linear semi-lattice buildilng. Allow users to experience their data as trees. But allow them to view the same data in as many different kinds of trees as they want. Allow users to start at any point in the tree. Allow users to rotate the tree 30, 60, 90, 247 degrees. The same data, different perspectives. The net result of all of these trees = semi-lattice.

TREE + TREE + TREE = SEMI-LATTICE

Canoga reality
For Canoga, a turbo-powered query by example interface a la Browse mode in iTunes might suffice. It allows users to browse the same data via many different trees (basically walk different parts of the semi-lattice as trees) AND easily walk from one tree to another (see semilattice.gif below). What's missing is the ability to visualize how these trees overlap to form a semi-lattice. In the future Chandler may have a richer graphical interface that provides a narrative tree-based user experience of semi-lattii by:

  1. Visualizing different tree organizations of the same data
  2. Overlaying the visualizations thereby...
  3. Forming a resultant, composite semi-lattice

Guiding principle: The whole is greater than the sum of the parts. Provide the complex richness of semi-lattii, but feed it to users in a way they can easily understand: trees.

Note: the iTunes browser is actually just a UI variant on browsing a fixed hierarchy. In Chandler, columns on the right will filter columns on the left as well and users will be able to move columns around. (ie. Start out with Artist, see what Genres that Artist belongs in). Basically turn a hierarchy that is organized like this:

  • Genre
    • Artist
      • Album

into one that looks like this:

  • Artist
    • Genre
      • Album

  • iTunesbrowse.gif:

  • semilattice.gif:

Turbo-charged Chandler browser UI

  • Where it lives
  • The browser lives inside of the summary view (a la iTunes)
  • There is an easy affordance to show / hide the browser (accompanied by an animation)

  • How it interacts with the Search bar
  • All parameters set in the browser are reflected in the Search bar
  • Parameters can be saved to the "Saved rules" bar (formerly the Bookmarks bar) which is visible at all times

  • Internal workings
  • The browser is organized into columns.
  • Each column represents an AND parameter of the rule
  • Users can customize what attributes appear in each column
  • Users select 1 or more attribute values in each column (results in creating an OR)
  • The same attribute can appear in 1 or more columns
  • Users can type in a value in a text box at the bottom of each column and the relevant attribute values will be auto-selected (see middle orange column)

  • The result is that the browser is a description of the items displayed in the summary view.

  • browser.gif:

Constellations: Even better than the semi-lattice

  • What we really want How the browser might work in Chandler n.0 where n=some uncertain point in the future
  • Allowing users the "walk" the semi-lattice via a series of intersecting trees is better than limiting users to a single tree and better than overwhleming users with a semi-lattice all at once. However, it is still a make-shift solution or at the very most, only a part of the final solution.
  • Rather than hiding the potentially scary semi-lattice wolf in the sheep's clothing of our old, but aging friend the tree, we're still "dumbing down" the data for the user in an effort to avoid UI shock via information overload.
  • In the end, we will have to revisit the semi-lattice and figure out a way to present users with the full-force and complexity of their information in a way that is understandable. This must be possible, even within the confines of the 2-dimensional screen we all inhabit.
  • Revisiting the problem: as we demonstrated with the Thesaurus interface above, one of the problems of semi-lattic interfaces is that relative location, size, hue and saturation are often "random" with respect to the data they are supposed to represent.
  • However, assuming that with good design, we can overcome this problem, the "final frontier" of semi-lattice interfaces is two-fold:
    1. Semi-lattices need to be staged. Users need to be able to browse individual trees of the semi-lattice and overlay them on top of each other so that they can visually walk through the different layers of the semi-lattice one-by-one. The ability to literally "watch" in "slow-motion" or user manipulated motion how the semi-lattice is constructed by various overlapping trees provides the user with contextual history that will make the final "assembled" semi-lattice easier to read and more meaningful.
    2. The result of more meaningful , tighter coupling of "visual cues" and the information they are meant to represent will naturally result in a semi-lattice picture that is resolves itself into immediately indentifiable shapes. Instead of a homoegenous, chaotic network of interconnected nodes, the semi-lattice should strive instead to be a series of interlinked constellations. Each constellation is a clear, contained, meaningful tree, but any individual star (node) in the constellation could be a member of one or more constellations.

  • 400map.jpg:

Comments

ChaoLam 15 Jun, 2004 Interesting blog entry and comments thread about gmail breaking away from hierarchy and how people used to hierarchies of folder are coping: http://weblog.edventure.com/blog/_archives/2004/4/19/36468.html

MimiYin 15 Jun, 2004 Thanks for the link. I think it confirms our direction. We want to give users the freedom and amorphous-ness of a search-centric navigation paradigm, but we want to help them with a little built in structure too by:

  1. Differentiating between mark-up attributes, core attribute values and "See also" collections.
  2. Providing OOTB collection types
  3. Dashboard view / triage workflow as a point of entry into their repository

Basically people should

  1. Build a little bit of structure (See also collections) and
  2. Use the browser UI to further narrow their options AND
  3. Be given a workflow to help them manage their structure in an orderly manner.

This is consistent with some of the Haystack studies I read about how people mostly use search to get within range of their target item and then navigate using contextual clues to find the exact item. Sometimes we don't know what we're looking for until we see it in context. Depending purely on a Search UI doesn't take advantage of our brain's ability to use environmental clues to remember things.

Its like the social contract. Democracy isn't libertarianism. Depending on whether you're France or Greenland, it's either a participatory bureacracy or a moderated free-for-all. Hehe.

MimiYin 24 Jun, 2004 Backwards workflow Why fixed hierarchies present a workflow bottlenck

We've talked about how the file folder metaphor misdirects users to first try to make fine-grain (where does this go?) decisions before making coarse-grain (processing) decisions. Fixed hierarchies also wreak similar havor within the filing (where does this go?) workflow. Oftentimes, we know what topic to file something under, but we don't know where that topic belongs in the hierarchy. This is perhaps the single biggest reason why filers end up with uncontrollable piles of emails in the Inbox and why pilers never bother to file in the first place.

  1. Fixed hierarchy means you have 1-shot at getting the right hierarchy
  2. Fixed hierarchy also means it's fixed! If something new comes along to screw up the hierarchy, you have to rebuild it from scratch...which rarely happens. Instead, we simply get unwieldy taxonomies with duplication and confusion.

Ex. Apples, Oranges, Watermelons, Pineapples, Footballs, Grapes, Tennis balls, Potatos, Bowling balls, Grass

File by: Fruit v. Non-fruit, Geographic region, Size

MimiYin 03 Aug, 2004 Browser and Search bar

  • Is the browser reflected in the Search bar?
  • Does the search bar limit options in the browser? A Yes.
    • Search bar parameters limit Browser column options to show: only options that will not result in a null set
    • Search bar parameters bring Browser column options that meet the parameters to the top of each column (ie. Search bar: "Shar" will bring "Shares" and "Sharing" to the top of the Collections column)
  • Multiple terms typed into the Search bar should limit the search results

MimiYin 09 Aug, 2004 OOTB Browser columns

  • Who
  • Date
  • Headline
  • Collection
  • Mark-up bar attributes

  • Toggle switch: All column are ORs, All columns are ANDs

-- MimiYin - 05 May 2004

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r16 < r15 < r14 < r13 < r12 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.