Diff for "GroupViews"

TableOfContents([2])

Proposal

The goal is to provide different ways of viewing a group of nodes of a network. We must provide a visualization that will present nodes with specific characteristics or similarities in a clear and organized manner without intrusion on the view of the rest of the network.

To accomplish this goal we will introduce use cases that will present a different type of group view that will provide an option for this feature.

Biological Questions / Use Cases

1 - Group View

This tool will provide the ability to group together nodes and edges of a network and view them in a clear and organized manner. The group view can have multiple ways of representing the grouped nodes and fall into two categories described. Only one group view can be active at a time but the user will have the ability to change between different views at any time.

1a) Child Nodes Hidden

• Solution: A group of nodes can be visualized by collapsing the selected group (child nodes) into a single parent node. The connections that exist between the child nodes and the surrounding nodes of the network will be represented in this view. All the edges connected to the child nodes will be connected to the single parent node. The group node will have the option of having specific characteristics that will help in representing the data attributes of the child nodes as visual attributes of the group node.

  • Average: The parent node can inherit a color that will be more helpful in representing the child nodes within. This can be done by using a color value that is an average of all the color values of the child nodes. Similarly, the following node visual attributes can be averaged this way: Node Border Color, Node Border Opacity, Node Font Size, Node Height, Node Label Color, Node Label Opacity, Node Label Position, Node Line Width, Node Opacity, Node Shape, Node Size, Node Width.

  • attachment:Average.png

    • Pie Node: The group characteristics can also be represented by a pie node. The pie chart can show segments of the colors that the child nodes represent, the size of each segment will be representative of how often that color appears in the child nodes. An implementation of this idea exists and can be found at: http://genepro.ccb.sickkids.ca/screenshots.html

      • attachment:PieNode.png

    • Grid Node: The group characteristics can also be represented by a grid node. The cells of the grid node can represent each colour that appears in the child nodes of the group. The grid node will appear as a square shape with a square grid inside.

      • attachment:GridNode.png

      Aside from node colour, the Grid and Pie nodes can also visualize the following node visual attributes: Node Border Color, Node Border Opacity, Node Font Size, Node Height, Node Label Color, Node Label Opacity, Node Line Width, Node Opacity, Node Shape, Node Size, Node Width.

      Custom Graphics: The user will have the ability to create custom graphics by combining various graphics and be able to render the group node view. The use case for this tool can be found here http://www.cytoscape.org/cgi-bin/moin.cgi/groupAPI/UseCase_10A

  Use Cases:

  • 1."Clustering-Biomodules" - http://www.cytoscape.org/cgi-bin/moin.cgi/groupAPI/UseCase_1 2."Protein Complexes–Pico/GenMAPP" - http://www.cytoscape.org/cgi-bin/moin.cgi/groupAPI/UseCase_2A 3."Sub-Gene Data Visualization" - http://www.cytoscape.org/cgi-bin/moin.cgi/groupAPI/UseCase_3A 4."Black box pathways" - http://www.cytoscape.org/cgi-bin/moin.cgi/groupAPI/UseCase8

Allan Kuchinsky, October 13, 2007: An alternative to showing the distinct attribute values of all child nodes would be to use just two visual attributes: one to represent a measure of centrality, such as arithmetic mean, and one to represent a measure of variability, such as standard deviation. I think that the multiple color node requires the user to conciously decode the colors to interpret attribute values, rather than to just pick up easily noticeable patterns. So, it shifts the visualization from the perceptual to the cognitive domain, which makes it much less effective.

1b. Child Nodes Visible

• Solution: A group of nodes can be visualized by a bounding box. This box will have the ability to move around and as a result move the child nodes along with it. Surrounding nodes of the network can then be dragged and dropped into the bounding box and will behave as child nodes. All the child nodes will be clearly visible along with their characteristics as they were before the grouping. The characteristics of the bounding box can change to reflect different characteristics of the group nodes.

Allan Kuchinsky: October 13, 2007: Should we allow the user to remove child nodes by dragging them out of the bounding box? If so, then under what conditions should we allow this?

• Adaptive boundary: The shape of the bounding box can change to the shape that the grouped nodes make. This will allow easy grouping and visualization when there are many surrounding nodes in the network. Different types of groups can be represented by a shape of a different colour.

  • attachment:DifferentShape.png

  Set Shapes: The bounding box can have different appearances that can represent different types of groups (from a biological standpoint). For example the bounding box may appear as a simple rectangular frame or a circle or a set of brackets, and a legend can explain the associations.

  • attachment:DifferentShapes.png

  Box Width: The width of the border of the bounding box can change with the number of nodes that are inside the group.

  • attachment:DifferentSize.png

  Box Location: To avoid clutter and show a clear distinction between the grouped nodes and the rest of the network, the bounded group should be moved to a separate, empty part of the network panel.

  • attachment:BeforeGrouped.png attachment:AfterGrouped.png

  An implementation of this idea named the “Bubble Router” can be found at: http://conklinwolf.ucsf.edu/genmappwiki/Bubble_Router_Plugin

Use Cases:

• 1."Named list of genes. Piet & GenMAPP" - http://www.cytoscape.org/cgi-bin/moin.cgi/groupAPI/UseCase_7A

2 - Group Window View

This is an optional, independent view of the group nodes that can be active during any of the above group views.

Stacked View: After expanding the grouped nodes, show the child nodes as vertically stacked. During stacked view, different sections of a single node can be viewed and each section of the node will have edges connected to it. Each section of the node will be presented by a block and each block will be stacked on top of each other to represent a single node. Each block can be differentiated with a name and a separate color. Use Case: "Paralogs" - http://www.cytoscape.org/cgi-bin/moin.cgi/groupAPI/UseCase_5A New Window: After expanding the grouped nodes, show the child nodes as a new network in a separate window. A “+’ symbol will appear when the mouse is moved over a parent node and when clicked, a new network window pop-up that will show the child nodes as a new network. The pop-up window can also be activated using a right-click menu. Use Case: One idea for implementing this view can be found here http://www.cytoscape.org/cgi-bin/moin.cgi/groupAPI/UseCase_3A Use Case: "Protein superfamily networks" Use Case 6 from http://www.cytoscape.org/cgi-bin/moin.cgi/groupAPI

• attachment:NewWindow.png

Group Panel: For each grouped visualization described above, create a group panel in Cytoscape that will show a more detailed, hierarchical structure of the group. This panel will be very helpful when the groups become more complex with multiple levels of parent nodes. The parent node will be listed in the panel with all the child nodes and their characteristics branching from it. This view will be very similar to Windows Explorer that shows the file hierarchy. One example of this functionality is the Group Panel in the current Named Selection plugin shown below.

• attachment:GroupPanel.png

Tree Map: A hierarchical node grouping can be flattened out and shown as a birds-eye, textual representation. This view will work for groups that can be represented by strict trees, ie: only one parent per node. Directed acyclic graphs (DAG) will not be supported by this view. Visual Aid: An example of this visualization taken from http://ivtk.sourceforge.net/

• attachment:TreeMap.png

Allan Kuchinsky, October 13th, 2007: TreeMaps are really an extension of Pie Charts, so make sense when you want to show the relative values for different child nodes. They really only make sense if you have a highly nested data structure. Given such a data structure, TreeMaps provide strong visual cues and might be an alternative to Pie Nodes and Grid Nodes.

Mouse-Over Tool: Create a viewing tool that will be controlled by a mouse and will travel over the network panel, when the tool moves over a parent node, the inside of the parent node.This tool will show an “x-ray”, detailed view of the inside of the parent node. Visual Aid: An example of this type of tool can be seen here. However instead of a zoomed view, the user will be able to see the child nodes that are inside the parent node. Image taken from http://ivtk.sourceforge.net/

• attachment:Bubble.png

Allan Kuchinsky, October 13, 2007: Using distortion might be a very intuitive way to give the user a quick overview of the children of a parent node. Coordinating this display with the Cytoscape renderer may be a challenge. Also, performance will be an important consideration. The user should be able to move the magnified area smoothly, the display should update immediately

Tool Tip: The user can have the ability to view information within the node without expanding the group node. A tool tip window can appear when a cursor moves over the group node and a list of names of all the child nodes can appear in the window. Other important information can also appear in this window, such as a list (or a percentage figure if the number child nodes is large) of the type of nodes that exist in this group or other features such as color if necessary.

• attachment:ToolTip.png

General Notes

• Some interesting ideas about group nodes can be found in a document found here http://www.nature.com/nbt/journal/v25/n5/pdf/nbt1304.pdf

Converting Between Visualizations

• The user should be able to convert from one type of a visualization to another with a simple mouse click.

Group view layout

• There should be a layout for the graph that contains the group nodes as well as a layout for the child nodes. These layouts could be different and the layout engine would apply them automatically in a hierarchial fashion when the children nodes are visible in the network. This idea should be discussed in more detail as a separate RFC. One specific use case would be layout of biological pathways where network motifs (e.g. a biochemical reaction) is represented as a group, then the groups are layed out, then the groups/motifs are layed out as they would be in a textbook e.g. biochemical reactions would be viewed as they are in textbooks (substrates on one side, products on the other, enzymes in the middle). This would include the ability to apply a standard layout to members of a group and view the result.

Requirements

Deferred Items

Open Issues

• Mapping Node Attributes to Nodes

  • How should the attributes of the grouped child nodes be mapped to the parent node?

• Mapping Edge Attributes

  • Should attributes of edges that are contained within a group be mapped to the edges of the parent node. If so, how?

• Sharing Child Nodes

  • Problems may arise when two or more parent nodes share the same child nodes. How should those child nodes be grouped and visualized?

• Different Data Attributes

  • If the group node has data attributes that are different than the children data attributes, how should they be mapped to group node visual attributes? Should we allow the user to switch to a group node view that supports normal data to visual attribute mapping for the group node without considering the children nodes?

Backward Compatibility

Expected growth and plan for growth

References

Implementation Plan

Comments

How to Comment

Edit the page and add your comments under the provided header. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.

Allan Kuchinsky -- October 13, 2007: I added some comments inline.