Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

under construction

Most folks are pretty familiar with the idea of a document viewed through a window on a computer.

Scrolling. Conceptual view of normal document scrolling.

 

Scroll bars are used to position the document, or the window if you prefer to think of it that way.

Zooming

The notion of zooming also has a pretty clear physical analog.
We can introduce another "scroll" bar to zoom in and out.
From bird's eye view to actual size and beyond to magnification.

Zooming. Conceptual view of document zooming.

 
 

Another zooming technique tried was to click and hold one mouse button for zooming out
and another for zooming in.
This had the advantage of setting a "zoom focus" with the same click.
This focal point would remain fixed as all others around it were modified by the zooming.

With Genoviz, and hence IGB, one can use "semantic zooming"
where each glyph can change appearance as you zoom in or out.

Zooming the two dimensions independently.
Trouble with the widget to effect such zooming.

Genoviz

The Genoviz SDK was developed to display genomic data.
It uses the notion of scene and view as analogs to document and window respectively.
Within the scene (document) glyphs representing data are arranged in a hierarchy.

<NeoMapScene picture>

IGB uses the GenoViz SDK to draw data on the screen, and the GenoViz SDK's modified model-view-controller architecture should make it easy to present many diverse views of data to users. However, this built-in flexibility has been hard to exploit because of complexities in TierGlyph classes that render and represent data tracks in IGB.

In this document, we'll describe some of problems users confront when interacting with data tracks and offer some ideas for how these interactions could improve.

The Rubber Canvas

IGB implements a one-dimensional variant of animated, semantic zooming, in which objects and the data field appear to stretch or contract about a central line during zooming and objects show more detail as users zoom in for a closer look.

In IGB, horizontal and vertical zooming happen independently of each other, reflecting the one-dimensional nature of sequence data and associated annotations. This differs from how zooming works in camera-zooming applications (e.g., Adobe Acrobat) where zooming mimics the action of a camera rising or descending over a two-dimensional field of data.

In IGB, the process of zooming is more like pulling on both sides of rubber canvas, where the canvas has a central stripe that remains in place as it stretches on either side. (Once this central stripe was called the "Hairline;" more recent versions of IGB use the term "zoom stripe.")

Horizontal zooming tends to work very well for users; they seem to instantly grasp how zooming focus works: Clicking a position in the display focuses zooming at that position and operating the horizontal slider zooms in or out. We've also implemented double-clicking to zoom in on a feature and click-drag across the coordinate axis to zoom in a region of interst.

However, it has been harder to communicate the idea of how vertical zooming works, which, in IGB, is more like a vertical stretch rather than a zoom in the usual sense of the word. To stretch/zoom vertically, a user operates the vertical slide on the left side of the main display window. The user's most recent click focuses vertical stretch-zooming, but there is no horizontal zoom stripe to indicate zoom focus.

Note: Adding a cross-hair to the Zoom Stripe may help users master this interaction more quickly. See figure below.

Vertical zooming

The vertical coordinate system in IGB does not have the same meaning as the horizontal coordinates system, which is closely wedded to the sequence data itself. This means that we have considerable freedom to augment vertical layout to convey more information and customize vertical zooming in ways that will help users explore data more effectively.

Multi-track stretch

Currently, operating the vertical zoomer stretches each track by equal amounts during zoom. As a result, all Glyphs in the display are close the same height regardless of the level of zoom. This is good behavior in that it makes it easy for the user to control the display. Once a user understands how zoom-focusing works, he can click a Glyph and then drag the vertical zoomer up or down to cause the data scene to expand or contract around that central location.

Single-track stretch

However, sometimes it would be useful to be able to stretch-zoom tracks independently of each other, i.e., increase the relative height of one track while compressing the remaining tracks by equal amounts.

For example, consider a track that has many reads aligned onto a gene. It would be useful to be able to force that track to stack its reads into a smaller vertical space, thus allowing the user to view the data without the more populous read alignments track seeming to crush or smash other tracks. We already have something of this implemented already - users can click a "-" icon in the upper left of a track to collapse all features into a single row.

Scheme for improving vertical zooming. Users will be able to stretch the canvas in two ways: all tracks together as they do now, or one track by itself.

 

Re-packing to fit available vertical space, but no more

more to come later

Ordered and sorted stacking

more to come later

  • No labels