Tree-Maps: A Space-Filling Approach to the Visualization of Hierarchical Information Structures

1. Tree-Maps: A Space-Filling Approach to the Visualization of Hierarchical Information Structures Presented by: Daniel Loewus-Deitch

2. Introduction • Novel method for visualizing hierarchies. • Makes 100% use of available space • Maps the full hierarchy onto the screen in a “space-filling manner.” • Called Tree-Maps • Interactive Control • Allows users to specify presentation of both structural and content information

3. Introduction • Sections of hierarchy with more important information are allocated more display space. • Collection of rectangular boxes represent the tree structure. • Best suited to hierarchies where • The content of the leaf nodes and the structure of the hierarchy are most important. • The content information associated with internal nodes is largely derived from their children.

4. Main Objectives • Efficient space utilization • Interactivity • Comprehension • Esthetics

5. Motivation (Problems with Current Methods) • Traditional methods for displaying hierarchies can be classified into 3 categories: • Listings • Outlines • Tree diagrams

6. Listings • Can provide detailed content information. • Present structural information poorly. • Requires users to parse path information and move manually through the hierarchy to get a real idea of its structure.

7. Outlines • Can nicely provide both structural and content. • Structure can only be viewed a few lines at a time. • Inadequate for displaying a hierarchical structure with more than a few hundred nodes.

8. Tree Diagrams • Excellent for small structures. • Make poor use of available display space. • Too much space used up for background. • Little content information. • Presenting additional information clutters the display space.

9. Why Tree-Maps are a good alternative • They use display space efficiently. • Can provide structural information implicitly. • Eliminates the need to draw internal nodes. • Provide an overall (global) view of the entire hierarchy. • Makes navigation and orientation easier. • Provides creative visual cues to communicate content information.

10. Presenting Directories • Problems with current methods: • None provide a graphical representation of the relative sizes of files or directories. • Command line listings force user to piece directory tree together manually. • Windows obscure each other and require too much effort to be arranged in any kind of useful manner. • Icons only show the type of the file, but no other properties.

11. Presenting Directories • Origin of Tree-Maps concept • Venn diagrams • Tree diagrams • Because these waste space, decided to use boxes instead of ovals, along with a bin-packing algorithm. • Worked well for small hierarchies only. • Nesting caused problems.

12. Presenting Directories • Origin of Tree-Maps concept • Discovered “slice and dice” method. • Simple linear method (top-down). • Developed a weight-proportionate distribution. • Added a pop-up dialog window for detailed content information. • Simple color mapping helps distinguish various properties of files, such as type and size.

13. Tree Map Method • Structural Information: • Interactive approach gives user control over how tree is displayed. • Requires that a weight be assigned to each node, which determines the size of that node’s bounding box.

14. Tree Map Method • Structural Information: • There are some properties that always hold, maintaining a consistent relationship between the structure of the hierarchy and its Tree-Map representation (pg. 156). • Structural information is implicitly presented, but can be nested to explicitly indicate. • Non-nested display explicity provides direct selection only for leaf nodes.

15. Tree Map Method • Content Information: • Variety of display properties determines how the node is drawn. • Color is the most important property. • Other properties include pitch of tone and color saturation. • Pop-up display provides information about the node currently under the cursor.

16. Coping With Size • Groups of small files can become indistinguishable (completely black regions). • Zooming in on these regions helps the local structure become clear.

17. Future Research • Exploration of alternate structural partitioning schemes. • Appropriate visual display of both numeric and non-numeric content information. • Dynamic views • Animated time slice

18. Future Research • Extended operations • Zooming • Marking • Selecting • Searching

19. Space-Filling Software Visualization Presented by: Daniel Loewus-Deitch

20. Introduction • SeeSys is a system that allows users to visualize statistics associated with code that is divided hierarchically into subsystems, directories, and files.

21. Introduction • Problems with current methods: • Ineffective for large software systems. • Routines for producing flow charts, function call graphs, and structure diagrams often break down. • Incomprehensible, cluttered display.

22. Introduction • Project managers need a tool that facilitates management issues of software development. • Where new development activity is occurring. • Which modules are error prone. • Motivation for SeeSys came from AT&T’s massive communications software system. • Five questions for project managers (pg. 162)

23. Introduction • Statistical methods, alone, don’t provide the context necessary to make valid analyses. • SeeSys visualizes subsystem, directory, and file statistics, but within appropriate context. • Preserves hierarchical relationships in the code. • Makes it easy to relate the statistics to the components.

24. Approach • Based on idea that software system can be decomposed into its individual components. • Subsystems labeled with letters. • Subsystems are partitioned vertically and their area is based on a particular subsystem statistic. • Allows for visual comparison of directories within a subsystem.

25. Approach • Fill represents a second statistic, such as indicating newly-developed code. • Zoom view to get a closer look at an individual subsystem. • Hierarchical decomposition immediately relates the files to their directories and the directories to their subsystems. • Makes cross unit comparisons easy.

26. Approach • The fill represents percentages. • Allows for quick discovery of outliers.

27. Applications • Subsystem information • Size and color brightness represent the size or individual subsystems. • Directory information • Each subsystem is partitioned vertically to show its internal directories. • Area and color represent size. • Fill is related to new development. • Figure 3 is the “software skyline.”

28. Applications • Error-prone code • Directory spikes represent detail for directory bug fixing. • Subsystem g shows an example of a very high bug rate (figure 5), represented by the light gray subsystem rectangle. • System evolution • Animated display portrays growth through the software’s version releases. • Shows history and trends of each subsystem.

29. The Visualization System • SeeSys was designed to display software metrics that have two properties • Quantitative measure • Additive • May be extended to display complexity metrics.

30. User Interaction • Tracks mouse movements and shows extra information about the component that the mouse cursor is touching. • Active component indicated by a red highlighted boundary. • Available stats are shown on lower left side of screen. • Clicking these stats creates a redrawn display focused on this particular statistic.

31. User Interaction • Five buttons control various options such as presence of fill and zoom activation. • ROWS slider controls the number of rows in the display. • Speed slider and frame slider control animation. • During animation, one can watch the active bar in the slider to see that particular subsystem’s evolution.

32. Display Principles • Based on 3 principles: • Individual components can be assembled to form the whole. • Allows users to see relationships between components. • Pairs of components can be compared. • Components can be disassembled into smaller components. • Allows structure of display to reflect structure of software.

33. Screen Real-Estate • 100% of display area is utilized. • Components with large statistics are visually dominant. • Zoom feature allows user to see small directories.

34. Spatial Relationships • Takes advantage of human ability to recognize spatial relationships. • People relate each component to the whole. • It is easier to see relationships between components if the heights of the rectangles are equal. • Row slider allows user to choose number of rows displayed for an optimal display.

35. Color • Redundantly encodes size. • Can also be used to encode age, complexity, activity, number of programmers, etc.

36. Implementation • Four linked views of data: • Colorful space-filling display. • Leftspace – controls, buttons, sliders. • Bottomspace – color scale and statistics. • Zoom view – details of a particular subsystem.

37. Summary • SeeSys provides the following utilities: • Shows the sizes of the subsystems and directories and where the recent activity has occurred. • Zoom in on particular subsystems. • Explore where bug fixes and new functionality have occurred. • Identify directories and subsystems with high fix-on-fix rates. • Find historically active and extinct subsystems

38. Summary • 3 principles should ultimately be observed when designing any visualization system for large software systems: • Structure of display should reflect structure of software. • Individual components should by comparable and decomposable. • Animation helps user visualize the evolution of the software.

39. Summary • Potential users of SeeSys: • Project managers • Feature engineers • Software developers