Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Tree Views for Zest"

m (Added to Category:GEF and Category:SOC)
Line 1: Line 1:
This is a project proposal for [[Google_Summer_of_Code_2009]]
+
This is the wiki page for a project [[Google_Summer_of_Code_2009]]
  
 +
* Student: [mailto:mateusz.matela@gmail.com Mateusz Matela] (IRC: mmati)
 +
* Mentor: Ian Bull
  
== Personal Details ==
+
== Abstract ==
 
+
Name: Mateusz Matela
+
 
+
E-mail: mateusz.matela@gmail.com
+
 
+
IRC nick: mmati
+
 
+
== Project Summary ==
+
  
 
The goal of this project is to provide two additional viewers into [http://www.eclipse.org/gef/zest/ Zest] project: Space Tree and Tree Map. Space Tree is a powerful form of visualization for large sets of tree-structured data, that concentrates on dynamic rescaling and hiding of branches. Tree Map is a well known visualization method using nested rectangles, which areas correspond to some aspects of presented data. This project will implement this idea in a traditional form but also try to experiment on it.
 
The goal of this project is to provide two additional viewers into [http://www.eclipse.org/gef/zest/ Zest] project: Space Tree and Tree Map. Space Tree is a powerful form of visualization for large sets of tree-structured data, that concentrates on dynamic rescaling and hiding of branches. Tree Map is a well known visualization method using nested rectangles, which areas correspond to some aspects of presented data. This project will implement this idea in a traditional form but also try to experiment on it.
  
 
+
== Detailed Description ==
== Project Proposal ==
+
  
 
I became interested in the Zest project after seeing how it is used in the [http://www.eclipse.org/pde/incubator/dependency-visualization/index.php plug-in dependency visualization]. I had a dilemma whether I wanted to work on this feature to make it more mature or rather add some functionality to the Zest project itself. I decided it's probably better to improve Zest first as it may provide even better solutions for the plug-in dependency tool (that is a viewer specifically designed for trees).
 
I became interested in the Zest project after seeing how it is used in the [http://www.eclipse.org/pde/incubator/dependency-visualization/index.php plug-in dependency visualization]. I had a dilemma whether I wanted to work on this feature to make it more mature or rather add some functionality to the Zest project itself. I decided it's probably better to improve Zest first as it may provide even better solutions for the plug-in dependency tool (that is a viewer specifically designed for trees).
 +
 +
=== Space Tree ===
  
 
Space Tree is presented [http://www.cs.umd.edu/hcil/spacetree/ here]. The idea of presenting parts of a tree by scaling and hiding its parts is simple yet powerful. The [http://hcil.cs.umd.edu/trs/2002-05/2002-05.pdf paper] publicized on the site provides a lot of  information on what presentation methods are preferable to the user and which just look cool without increasing usability. Generally I'm going to stick to this advice, but to some extend I also want to try some new ideas. For example I think it won't harm to use some transparency effects while hiding a subtree (although I don't know yet whether the underlaying graphic libraries allow transparency). I think a good way to present the Space Tree viewer in action is to add it to the plug-in dependency visualization project (the Plug-in Dependency View in SDK is based on a tree after all).
 
Space Tree is presented [http://www.cs.umd.edu/hcil/spacetree/ here]. The idea of presenting parts of a tree by scaling and hiding its parts is simple yet powerful. The [http://hcil.cs.umd.edu/trs/2002-05/2002-05.pdf paper] publicized on the site provides a lot of  information on what presentation methods are preferable to the user and which just look cool without increasing usability. Generally I'm going to stick to this advice, but to some extend I also want to try some new ideas. For example I think it won't harm to use some transparency effects while hiding a subtree (although I don't know yet whether the underlaying graphic libraries allow transparency). I think a good way to present the Space Tree viewer in action is to add it to the plug-in dependency visualization project (the Plug-in Dependency View in SDK is based on a tree after all).
  
The second viewer I'd like to provide is [http://en.wikipedia.org/wiki/Treemap Tree Map]. One practical use of this presentation method I've seen is to show sizes of files and folders on disk. Personally, I never liked Tree Maps because the constraint of all areas being perfect rectangles tiling a bigger rectangle seems unnatural and unnecessary to me. Its only advantage I can see is that it's easier to put labels on the tiles. But in most applications I've seen tiles aren't even labeled. That's why I'd like to try some other forms of Tree Map in addition to the traditional one.  
+
=== Tree Map ===
 +
 
 +
The second viewer I'd like to provide is [http://en.wikipedia.org/wiki/Treemap Tree Map]. One practical use of this presentation method I've seen is to show sizes of files and folders on disk. Personally, I never liked Tree Maps because the constraint of all areas being perfect rectangles tiling a bigger rectangle seems unnatural and unnecessary to me. Its only advantage I can see is that it's easier to put labels on the tiles. But in most applications I've seen tiles aren't even labeled. That's why I'd like to try some other forms of Tree Map in addition to the traditional one.
 +
 
 +
==== Circle View ====
  
 
One idea is to use circles. The graph area will have some empty spaces between circles, but I think it will look more natural. If smaller circles are put in the empty space between bigger circles, the whole picture will resemble foam (or fractals :)).
 
One idea is to use circles. The graph area will have some empty spaces between circles, but I think it will look more natural. If smaller circles are put in the empty space between bigger circles, the whole picture will resemble foam (or fractals :)).
 
Subtrees can be showed as a set of smaller circles inside a bigger circle. This requires either to break the rule that the area of a node is the sum of its children area, or to not show all the children. This might be a problem in some uses. Another option is to show a node's children in a form of pie chart, but I think this would cause too much inconsistency. Also, the algorithm for placing the circles so that they don't leave a lot of empty space will probably be complicated. But I think finding an approximate solution will be enough to make the graph look nice. It's worth to note that the circles won't have to be completely repositioned if their sizes change (it would only cause some more empty space). All in all, I think it's worth to implement this idea.
 
Subtrees can be showed as a set of smaller circles inside a bigger circle. This requires either to break the rule that the area of a node is the sum of its children area, or to not show all the children. This might be a problem in some uses. Another option is to show a node's children in a form of pie chart, but I think this would cause too much inconsistency. Also, the algorithm for placing the circles so that they don't leave a lot of empty space will probably be complicated. But I think finding an approximate solution will be enough to make the graph look nice. It's worth to note that the circles won't have to be completely repositioned if their sizes change (it would only cause some more empty space). All in all, I think it's worth to implement this idea.
 +
 +
==== Polygon View ====
  
 
Another option is to form something resembling a [http://en.wikipedia.org/wiki/Voronoi_diagram Voronoi diagram]. Of course the cells won't have to completely fulfill Voronoi diagram's properties, the main idea is to resign from rectangles and use more irregular polygons. I think this will allow more balance in the picture in comparison to traditional Tree Maps, where usually there are a few big tiles on one side and all the small tiles are crowded in the corner. This method also won't be vulnerable to changes of cell sizes (it would have to resize all the cells, but without changing their positions). Again, designing an algorithm to create charts that look good is quite a challenge but I think I can manage to find a reasonably effective solution.
 
Another option is to form something resembling a [http://en.wikipedia.org/wiki/Voronoi_diagram Voronoi diagram]. Of course the cells won't have to completely fulfill Voronoi diagram's properties, the main idea is to resign from rectangles and use more irregular polygons. I think this will allow more balance in the picture in comparison to traditional Tree Maps, where usually there are a few big tiles on one side and all the small tiles are crowded in the corner. This method also won't be vulnerable to changes of cell sizes (it would have to resize all the cells, but without changing their positions). Again, designing an algorithm to create charts that look good is quite a challenge but I think I can manage to find a reasonably effective solution.
 +
  
 
All the implementations of Tree Maps will also require a mechanism for cutting out subtrees that are too deep and zooming into selected nodes as it will not always be possible to show all leaves of the tree in a readable fashion. The exemplary application for Tree Map will be a simple disk-usage presentation.
 
All the implementations of Tree Maps will also require a mechanism for cutting out subtrees that are too deep and zooming into selected nodes as it will not always be possible to show all leaves of the tree in a readable fashion. The exemplary application for Tree Map will be a simple disk-usage presentation.
Line 32: Line 34:
 
To sum it up, I think the Space Tree viewer will be very useful as its functionality has been tested in aforementioned paper. The Tree Map, and especially the last two presentation methods are more risky, but also more interesting :)
 
To sum it up, I think the Space Tree viewer will be very useful as its functionality has been tested in aforementioned paper. The Tree Map, and especially the last two presentation methods are more risky, but also more interesting :)
  
== Possible mentors ==
+
== Timeline ==
  
Ian Bull
+
* '''May 23 - June 5:''' prepare a tree model and general architecture of the tree viewer
 +
** Features: TBA
 +
* '''June 6 - July 17''': working on Space Tree
 +
** Features: TBA
 +
* '''July 18 - August 17''': working on Tree Maps
 +
** Rectangle View features:
 +
*** TBA
 +
** Circle View features:
 +
*** TBA
 +
** Polygon View features:
 +
*** TBA
  
 
== Comments, suggestions, ideas... ==
 
== Comments, suggestions, ideas... ==
  
 
Feel free to add your thoughts:)
 
Feel free to add your thoughts:)
 +
 +
 +
 +
 +
----
  
 
[[Category:SOC]]
 
[[Category:SOC]]
 
[[Category:GEF]]
 
[[Category:GEF]]

Revision as of 17:17, 18 May 2009

This is the wiki page for a project Google_Summer_of_Code_2009

Abstract

The goal of this project is to provide two additional viewers into Zest project: Space Tree and Tree Map. Space Tree is a powerful form of visualization for large sets of tree-structured data, that concentrates on dynamic rescaling and hiding of branches. Tree Map is a well known visualization method using nested rectangles, which areas correspond to some aspects of presented data. This project will implement this idea in a traditional form but also try to experiment on it.

Detailed Description

I became interested in the Zest project after seeing how it is used in the plug-in dependency visualization. I had a dilemma whether I wanted to work on this feature to make it more mature or rather add some functionality to the Zest project itself. I decided it's probably better to improve Zest first as it may provide even better solutions for the plug-in dependency tool (that is a viewer specifically designed for trees).

Space Tree

Space Tree is presented here. The idea of presenting parts of a tree by scaling and hiding its parts is simple yet powerful. The paper publicized on the site provides a lot of information on what presentation methods are preferable to the user and which just look cool without increasing usability. Generally I'm going to stick to this advice, but to some extend I also want to try some new ideas. For example I think it won't harm to use some transparency effects while hiding a subtree (although I don't know yet whether the underlaying graphic libraries allow transparency). I think a good way to present the Space Tree viewer in action is to add it to the plug-in dependency visualization project (the Plug-in Dependency View in SDK is based on a tree after all).

Tree Map

The second viewer I'd like to provide is Tree Map. One practical use of this presentation method I've seen is to show sizes of files and folders on disk. Personally, I never liked Tree Maps because the constraint of all areas being perfect rectangles tiling a bigger rectangle seems unnatural and unnecessary to me. Its only advantage I can see is that it's easier to put labels on the tiles. But in most applications I've seen tiles aren't even labeled. That's why I'd like to try some other forms of Tree Map in addition to the traditional one.

Circle View

One idea is to use circles. The graph area will have some empty spaces between circles, but I think it will look more natural. If smaller circles are put in the empty space between bigger circles, the whole picture will resemble foam (or fractals :)). Subtrees can be showed as a set of smaller circles inside a bigger circle. This requires either to break the rule that the area of a node is the sum of its children area, or to not show all the children. This might be a problem in some uses. Another option is to show a node's children in a form of pie chart, but I think this would cause too much inconsistency. Also, the algorithm for placing the circles so that they don't leave a lot of empty space will probably be complicated. But I think finding an approximate solution will be enough to make the graph look nice. It's worth to note that the circles won't have to be completely repositioned if their sizes change (it would only cause some more empty space). All in all, I think it's worth to implement this idea.

Polygon View

Another option is to form something resembling a Voronoi diagram. Of course the cells won't have to completely fulfill Voronoi diagram's properties, the main idea is to resign from rectangles and use more irregular polygons. I think this will allow more balance in the picture in comparison to traditional Tree Maps, where usually there are a few big tiles on one side and all the small tiles are crowded in the corner. This method also won't be vulnerable to changes of cell sizes (it would have to resize all the cells, but without changing their positions). Again, designing an algorithm to create charts that look good is quite a challenge but I think I can manage to find a reasonably effective solution.


All the implementations of Tree Maps will also require a mechanism for cutting out subtrees that are too deep and zooming into selected nodes as it will not always be possible to show all leaves of the tree in a readable fashion. The exemplary application for Tree Map will be a simple disk-usage presentation.

To sum it up, I think the Space Tree viewer will be very useful as its functionality has been tested in aforementioned paper. The Tree Map, and especially the last two presentation methods are more risky, but also more interesting :)

Timeline

  • May 23 - June 5: prepare a tree model and general architecture of the tree viewer
    • Features: TBA
  • June 6 - July 17: working on Space Tree
    • Features: TBA
  • July 18 - August 17: working on Tree Maps
    • Rectangle View features:
      • TBA
    • Circle View features:
      • TBA
    • Polygon View features:
      • TBA

Comments, suggestions, ideas...

Feel free to add your thoughts:)




Back to the top