Date: 3/1/96
Presented by: Yusuf Goolamabbas
Topic: Information Visualization 1

Tree-Maps by Johnson & Schneiderman

• The idea is cute, but as with many cute ideas, it suffers from some big problems:
  1. For deep trees, it is almost impossible to determine where in the tree a node is just by looking at the area it covers. You have to manuall identify the ancestors to determine the node's depth.
  2. The approach is not general enough--it assumes a certain weight distribution. If the distribution is "too regular", e.g., all the nodes have the same wieght, you'll just end up with a regular grid, and the tree structure is totally lost (where are the level partitions?). If the distribution is too irregular, nodes with small weights (especially at the top levels) will egenerate into single lines or pixels.
  3. Non-terminal nodes can't be shown.
  4. Obvious problems with "chain-like" structures.
  Figure 8 is an excellent examples of a horrible visualization. I liked the Figure 4 approach much better. The concept is still pretty good--how can it be improved?
• One problem with tree-maps was mentioned in the example in the paper, but not noted as a problem. In the discussion of the 1000-file Macintosh file system tree-map it says "The files in this root level folder can be seen duplicated one level down in subfolders as repeating geometric patters offset 90 degrees from their parent." (emphasis added)
  
  • How good is the human perceptual system at matching two potentially complex patterns when one is rotated 90 degrees from the other?
  • Isn't the transformation also more complicated tha a simple rotation? Couldn't a change of aspect ratio also be involved?
• An exciting aspect of tree maps is the use of color to map attribute to data. Through doing this, a user can easily make general conlusions about the data being shown. For example, a lot of red may imply many more of one X than other X's.
  • How can shape and space in treemaps be used effectively?
  • Why do so many tree maps appear unordered and random as far as shape and organization?
• The authors of the Tree-Map paper see their design as being superior for displaying large amounts of data; using directory information as an example. Personally, I found it difficult to see structure in the tree-maps, and wasn't really sure how the directories were laid out. Directories are inherently trees, yet the authors discarded trees outright. Was this valid?
• SGI developed a tree view of a directory structure, allowing zooming in and out, flying over the directory structure, using color to show file age and size of rectangle to show file size. Is this structure more intuitive? Does this interface provide the same knowledge possible as the tree-map implementation?
• The example in Schneiderman's paper of using tree maps to visualize a hard drive gave the hardware used as a 640x480 monitor and an 80MB hard drive. Mass storage prices have decreased significantly since 1991, allowing even home computers to have drives greater than 1GB. Will the tree maps scale up enough to be useful with the larger hard drives? (Ed. Note) Although monitor resolution has increased as well, it hasn't kept pace (and doesn't seem likely to keep pace) with the rapid expansion of mass storage. Those differences could lead to serious limitations of the Tree-Map approach.
• Using the size of the rectangle to represent the weight of a file seems to only provide qualitative information because the ratio of the width and height of the rectangles may vary. Is there any better algorithm to conserve the width-height (aspect) ratio?
• At the very end of the tree-maps paper, the idea of animating tree maps over time is presented. Has any work been done in this area? Is it possible to smoothly animate changes in hierarchical structure using tree-maps? how would one, e.g., animate insert in a heapsort of a large data set in a meaningful way? Is this example even applicable--or does it depend too much on intermediate nodes?
• The Tree-Maps paper sets up tree-maps in a way that information about long, linear lists of nodes is lost. In fact, in general it is the child nodes which are displayed in easy to see ways, while internal nodes are less "present." There are many hierarchies, however, in which internal nodes are very important (for example, hierarchis of WWW pages -- "important" nodes often have many children--this is a way of identifying them). Is there a way that the space-filling tree-map idea can be modified to bring out any node that the user consideres important or is it more limiting than that? For example, what would happen if node size were mapped to # of children?

InfoViz using 3d Animation by Robertson, Card, and Mackinley

• It seems that the visualizations preseted in this paper do not fit into any of the three categories discussed in Stasko's Polka-3D paper; the data is not inherently 3D, yet the third dimension is not used in the orthogonal fashin exhibited in the augmented 2D views. The cone-tree and the perspective wall, IMHO, utilize the third dimension more effectively. What other kinds of research has been done along these lines, and how come it is not more wide-spread?
• 3D/Rooms seems like a good idea; i.e., using a 3D space to organize a 2D space into more "organizable" space. However, as rooms get filled with information, there are undersirable effects like obscuration and ambiguity.
  • Is there an approach, like a moving sidewalk or other moving 3Dspace, which can prevent this?
  • Why is a static "room" the best alternative for creating a 3D space?
• It seems like the developers of the Xerox PARC Information Visualizer spent a lot of time and put a lot of effort into the project. It's a shame that they picked such a poor user navigation interface (three different mouse controls). If a system is hard to use, it won't be used. Is there a better, more intuitive way to provide users with 3D control over the information being visualized?
• I really don't understand what is meant by logarithmic flight or logarithmic object manipulation.
• A cone tree only shows a part of all the items available, which is very close to a 2D scrollable list. What's the advantge of the 3D representation?