Diff for "VizMapUI"

TableOfContents([2])

About this document

This is an official Request for Comment (RFC) for redesigning the Vizmap and Filter user interfaces.

For details on RFCs in general, check out the [http://www.answers.com/main/ntquery?method=4&dsid=2222&dekey=Request+for+Comments&gwp=8&curtab=2222_1&linktext=Request%20for%20Comments Wikipedia Entry: Request for Comments (RFCs)]

Status

1/17/07 - Not yet completely written. Start writing actual implementation plan.

How to Comment

To add comments, use Comment section below.

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.

Proposal

Visualization of networks is Cytoscape's reason for existence and Cytoscape fittingly provides powerful features for changing and managing the visualization of networks. However, many of these features are hard to use individually and in concert with other features. As a result of this general difficulty users have expressed frustration with the system. This was made apparent during the usability working group at the 2005 Cytoscape retreat and in a survey presented to new users of the system.

Therefore, we propose to redesign the Vizmapper and Filtering interfaces with the goals:

1. Conceptual clarity. Clearly define the goal of each dialog/step/action in terms of intended use cases.
2. Simplicity. Provide clear options, make next steps apparent, reduce available options when possible.
3. Consistency. Whenever possible maintain a similar layout/behavior for similar functions/tasks.
4. Maintain the current feature set.
5. Flexibility. Create an extensible design that will allow for new features to be added in a way that doesn't violate goals 1-3.
6. A design that is easy enough for beginners to figure out, but rich enough for experienced users to accomplish their goals.
7. Accessibility. Make functionality visible/accessible to user, provide affordances so that user can recognize the accessible functionality, rather than have to memorize particular actions.
8. Responsiveness. Changes should be immediately effected where possible (minimize need for an ‘apply to network’ button).
9. Reversibility. It should be easy to undo and redo changes in a highly interactive way.

The new Vizmapper UI is a part of Cytoscape 2.5 features, which will be available in 2nd Q of 2007.

Biological Questions / Use Cases

High Level Use Cases

• I want to compare and contrast nodes/edges, e.g. I want to have nodes/edges that meet certain conditions ‘stand out’.

• I want to see trends for nodes/edges over conditions (attributes), e.g. changing expression values over a time series.

Lower Level Use Cases Implied by High Level Use Cases

• I want to change the {node|edge} {shape|color|etc} based on data attribute XYZ.
• I want particular {nodes|edges} to be highlighted a particular way.
• I want to change the appearance of my selected {nodes|edges}.
• I want to {modify|layout|delete|???} of just a selected set of {nodes|edges}.
• I want to select all {nodes|edges} that match a particular pattern.

• If attribute X is in between n1 and n2 AND attribute Y is abc, then I want to change the color to C1.

General Notes

Definitions

Network visualization amounts to the graphical representation of raw data. The raw input data consists of node network data, edge network data, node attribute data, and edge attribute data. Node and edge network data only define the topology of the network. Node and edge attribute data associate supplemental information with the node and edge network data that define the topology. To create a visualization, this input data is mapped to graphical elements (circles, squares, lines, etc.) and displayed on a computer screen. Creating this mapping is what this RFC is about.

General Concepts

Fundamentally, there are three distinct conceptual acts involved in altering the visual appearance of a network.

1. Selecting the input data that should be used to define the alteration.
2. Selecting the graphical element that should altered.
3. Defining the mapping between the two.

1. Input data consists of two primary types: network and attribute.

The selection of network data is a binary selection. You've either selected an node/edge or not. This binary representation makes the mapping to graphical element (step 3) relatively straightforward. You simply define how a graphical element is to be altered if the associated data is part of the selection. How you go about selecting the data however is where things get interesting. Currently there are three ways of selecting data.

1. Select all data.
2. Hand select a subset of data using the mouse (i.e. Drag-select or click on particular nodes or edges).
3. Use a filter to select a subset of data based on attribute or network data.

Once the selection of data is accomplished we know which nodes and edges the graphical changes will be applied to, but we still don't know how the changes will be applied.

2. Selection of graphical elements is relatively straightforward and is only limited by what Cytoscape can render. What is useful to consider is not the myriad types of graphical elements, but what each is able to communicate. In general, there are two types of data, discrete and continuous. Some graphical elements lend themselves well to one, but not the other. For instance color gradients and size are good at representing continuous variables because there is a simple function mapping the domain of the variable to the range of the graphical element. Other elements, such as shape, are less well suited to continuous variables because there is no natural mapping between the discrete number of shapes and a continuous variable. However, discrete variables, like species, are well suited to limited graphical elements like shape, line type, etc.

• Nominal (categorical), ordinal, interval, and rational data. See http://www.psychstat.missouristate.edu/introbook/sbk06m.htm for descriptions of the different types. It is worth considering whether to present discrete/continous data options as the different types of measurements instead of or as well as discrete and continuous options.

3. Mapping the data selection of step 1 to the graphic selection of step 2 results in the final visual representation. Mappings can be one of three types:

1. Discrete - The data values being categorized are grouped with like values and each group is assigned a specific highlight. For instance any node with a value of 1 is square shaped and and any node with a value of 0 is circle shaped. Discrete data can be textual or numeric. Even continuous data can be treated as discrete with each datum represented by a specific mapping.
2. Continuous - Continuous data can be treated directly with graphical elements like node size or color gradient. It can also be transformed into a discrete variable by assigning intervals to the range of variables. Continuous data can only be numeric.
3. Pass Through or No mapping. Pass Through mapping means that the variable isn't mapped onto a graphical element, but that the variable is used directly by the graphical element. The primary use of a pass through mapper is for attribute data to be used to label nodes and edges.

How Vizmapper and Filters Fit into Cytoscape

Cytoscape has three primary modules, the network data (CyNetwork), the attribute data (CyAttribute), and the visual representations. Filters only affect the selection of nodes or edges from the network data model, however they can use attribute data to provide filtering criteria. The Vizmapper, however, only operates on the underlying attribute data model, although data selected with filters (or by hand) can be used to create or alter attribute data.

The visual representation is affected by both the network and attribute data. Network data is used to determine the layout of the graph while attribute data is used to style the graph.

Possible Designs

• Current Design: attachment:vizmapper1.png attachment:vizmapper2.png

• The first window will be removed. The function like New or Delete will be a part of new toolbar or menu command in the new VizMapper UI.

• Second window will be a part of one of the CytoPanels.

Key design goals

• Provide a clear overview of the mappings that each visual style contains. The point of an overview is to allow the user to gain mastery of the visual mapping system by giving them a clear path from the data behind the scenes to the visualization of the network. The overview should contain all of the relevant information: the data attribute, the visual attribute, which nodes.edges are selected. For example, if your visual style only define mappings for node shape and size you might see something like:
  • My Visual Style
    • Node Shape -- Species -- All nodes
    • Node Size -- p-value -- XYZ filtered nodes
• Provide consistent steps for changing visual attributes.
• Only show what is needed. If a data attribute is discrete, only show discrete mappings.
• Make sure it is apparent what the current settings are.

1. A standard wizard interface. The vision is to roughly follow the steps above with separate screens (within the same panel so we're not spawing new windows for each click).

• Begin with a page that lists the possible visual styles with the current style clearly highlighted. This page might include a summary of the rules the style contains or provide a link to one.
• Ask the users to select the data attribute to map.
• Ask the users to select the nodes/edges to apply the mapping to.
• Ask users what visual attribute they would like the mapping to apply to. This function should be smart enough to limit available options to what the data attribute can naturally represent (i.e. discrete implies shapes, colors; continuous implies size, color gradient).
• The final page of the wizard will be something similar to what we see in the tabs now. This is where you'll define ranges for the variables, etc.
• Finishing the wizard returns to the start page.

* Advantages

• Should be easy for people to follow.

* Disadvantages

• Might slow expert users down.

2. A Tree (JTree) type interface. The levels of the tree would include the available styles, available visual attributes, available data attributes, and a final page that allows users to tweak a particular setting. It isn't entirely clear to me how the levels should be ordered. * Advantages

• The tree itself can provide a summary of existing mappings.
• Allows expert users to quickly click to where they want to go.

* Disadvantages

• Trees can be tedious to navigate as they frequently "explode" providing much more information than can fit in a screen.

3. Same as the Tree interface, but using a Mac OSX finder column paradigm.

4. Implement a DynamicQuery interface, a la SpotFire, InfoVis toolkit, as an alternative filtering capability. Use a set of RangeSlider widgets, one per desired attribute, with filtering performed by an ANDing of the individual attribute/slider queries. Have filtering result in hiding/showing of nodes, rather than selection of nodes. The InfoVis toolkit has classes for Dynamic Queries and range sliders, that we can utilize.

This function is partially implemented by Quick Find Plugin introduced in version 2.4. Remaining issue:

• How can we chain the Dynamic filtering result? This means create selection by AND operation between dynamic filtering results.

• How can Quick Find and Filter plugin communicate each other?

5. Come up with other examples of interfaces for building logic statements for Filters. Ethan is collecting this list for research.

• Perfuse
• Infoviz
• Protege
• Endnote

• Others?

Possible New Features

• Combine multiple attributes by creating new attribute called filtering result.
• Transparency control slider

• Time Slider: Slider to switch attribures. Will be used to view array data.

Requirements

Deferred Items

Open Issues

1. Move vizmap and filter interfaces into CytoPanels.

   • Currently, Cytopanel 3 is not in use, so maybe we can place them in it.
2. Computed attributes, i.e. combining mappings in expressions.
3. Data preprocessing, e.g. to assign mapping types and ranges based upon statistical shape of the data.

4. Evolution versus revolution: Can we keep the vismapper model intact while implementing new user interfaces for manipulating it? If so, then we can implement many of these enhancements as plugins, allowing users to continue using VizMapper classic as the default?

5. There are several visual attributes where it makes sense to manipulate the attribute directly on the network. The example that brings this to light is node label position. It would be nice to be able to click on a node and then, through some mechanism, directly move the node label to the desired location on the screen. The trick here is integrating this movement with the potentially existing visual mapping.
6. How do custom node graphics fit in?
7. How should local visual attributes be dealt with? E.g. the user can select any visual attribute for a node or edge and the visual mapper should respect it.
8. How should node label position be incorporated with the vizmapper?

Backward Compatibility

Expected growth and plan for growth

References

Web Resources

1. Nielsen’s 10 usability heuristics, http://www.useit.com/papers/heuristic/heuristic_list.html

2. Ben Shneiderman’s “Eight Golden Rules of Interface Design”, http://www.cs.utexas.edu/users/almstrum/cs370/elvisino/rules.html

3. Bruce Tognazzini's "First Principles of Interaction Design", http://www.asktog.com/basics/firstPrinciples.html

4. Apple user interface guidelines, http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html

5. Jeff Johnson’s GUI bloopers, http://www.gui-bloopers.com

6. Card, MacKinlay, and Shneiderman’s “Readings in Information Visualization”, http://www.cs.umd.edu/hcil/pubs/books/readings-info-vis.shtml

7. There is also a nice little annotated bibliography at http://www.cs.utexas.edu/users/almstrum/cs370/elvisino/ann_bio.html#9

Books

1. "Designing the User Interface" by Ben Shneiderman, http://www.amazon.com/gp/product/0201694972/104-8618736-1880752?v=glance&n=283155

2. "The Human Factor" by Kim Vicente, http://www.amazon.com/gp/product/0415970644/104-3362403-2293568?v=glance&n=283155

3. "The Design of Everyday Things" by Don Norman, http://www.amazon.com/gp/product/0465067107/ref=pd_bxgy_text_b/104-3362403-2293568?%5Fencoding=UTF8

4. [http://www.amazon.com/gp/product/0060005696/103-9869596-5663827?v=glance&n=283155 The Paradox of Choice]

Implementation Plan

(Tentative)

• Phase 1: Build Mockups - Jan. 2007
  • Based on the discussion above and notes from Cytoscape Retreat 2006, build some mockups.
• Phase 2: Refine Design - Feb. 2007
  • Modify the GUI design based on core developer's feedbacks and finalize it.
• Phase 3: Integration - Feb. 2007 - Mar. 2007
• Phase 4: Testing and Tweaking
  • ["/Implementation Plan"]

Actual Design

The prototype Vizmapper UI has 4 main components:

1. Global VS selection toolbar
2. Visual Property Selection Panel
3. Value exprorler
4. Interactive slider panel

Comments

PageComment2