out of date content - available for reference purposes only

Introduction

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.

Scrolling

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

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.

One zooming technique tried (e.g. Jazz) 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 would move toward or away from it when zooming.

Zooming can also be done in two dimensions independently. Designing controls for this can be tricky. When zooming in one dimension instead of a focal point there is a focal line. That line would be vertical for horizontal scrolling and horizontal for vertical scrolling. In either case the focal line remains fixed and lines parallel to it move toward or away from the focal line.

Scrolling, Zooming, and Stretching With 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.

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

There is also the notion of stretch to fit which is a sort of automatic zooming so that the subject fills up its container when the container changes size.

Adding Tiers

The notion of tiers was introduced to display tracks of data all aligned to the same horizontal coordinate space. Manipulating these tiers presents some interesting problems. This discussion is limited to vertical manipulations.

Current (targeted) Behavior

There seem to be some bugs at the moment, but this is how the vertical manipulations should be working now. The packing of the tiers seems to get messed up and the border manipulation seems to get in a state where the border can no longer be moved.

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 interest.

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. Vertical placement is by category rather than by some sort of distance from an axis. The whole thing can be zoomed vertically as can any other Genoviz component. This will resize all the tiers except those marked as a fixed size.

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.

Collapsing

A tier can be made to disappear by clicking the little grey - box on it's left. When it is gone the box will change to a + to let the user make it reappear. This can also be done by invoking the widget's pop up menu with a right mouse click. The little boxes may well be going away as they are no longer needed and cause a bit of difficulty with the zoom focus and glyph selection. A click on the button also gets passed through to the map below.

Border Adjustment

Adjust a border between two tiers. Dragging a border up should shrink the tier above and expand the tier below. Dragging it down should expand the tier above and shrink the one below. All other tiers should remain unaffected. No scrolling is instigated. The axis (or Coordinates) tier cannot be resized. If a border of the "Coordinates" tier is dragged then the tiers above the coordinates or axis tier and below it are resized.

Examples From Spreadsheet Column Resizing

Spreadsheets resize columns using mouse drags between columns. Could this behavior be instructive for our vertical resizing of tiers?

JTable: The column to the left of the drag point is resized. All columns to the right are proportionally squished like and accordion. Columns to the left are unchanged. When all columns to the right reach a minimum size the resizing stops. When the target column reaches a minimum size the resizing stops. No scrolling is instigated. All this is visible during the drag. Rows cannot be resized with the mouse.

Open Office Spreadsheet: Resizing is not visible during the drag. Only a bold vertical line moves with the drag. It has a pop up label that displays the new width numerically. The column to the left of the drag point is resized. Dragging can continue past either the right or left edge. When the mouse is dragged further left than the left edge of the target column the pop up tag changes to "hide" and when the mouse is released the column is hidden. No scrolling is instigated. Resizing is effected when the mouse button is released. Other column sizes are unaffected. The overall document grows or shrinks to accomodate the new width of the resized column. Resizing of rows is the same.

Excel?

Others?

Michael notes that in some spreadsheets like Excel (OO does this too) double clicking on a border resizes the column to the left to automatically fit its content.

Moving a Tier (Shuffling)

A user can move a tier over others by grabbing it in the middle (not the border) with the mouse and dragging it vertically. When dropped the tier will take a new position in the stack of tiers and other tiers will be pushed down (or up) to accommodate the dropped tier's new position. All tiers retain their pre drag height. Scrolling is not instigated. Maybe it should be.

JTable allows columns to be shuffled the same way. If a column is moved past the right edge the column can be moved several places of screen (although this is not visible). Open Office Spreadsheet does not allow such shuffling of either rows or columns.

Automatic Resizing

When the window height changes the tiers resize to fit.

Future Possibilities

There are some features of general GUI widgets that users like and might help if added to tiers. One loose analog is the columns of a spreadsheet. Spreadsheet columns can be moved and resized in various ways. However, tiers are not entirely generalizable as Swing components. We might do well to introduce some Swing concepts to tiers though. There are also other possibilities that are specific to genomics that go beyond (or restrict) Swing components.

A few terms: By squeeze, shrink, expand, or stretch we mean change the tier's height repacking its data to fit. By accordion squeeze we mean that tiers are squeezed proportionally until a minimum height is reached for each of them. accordion expansion or stretching is the inverse. By pleated squeeze we mean that one tier is squeezed until it reaches a minimum and then squeezing continues with the next tier and cascades from there. Pleated expansion or stretching is the inverse. By push and pull we mean change the position, but not the height of a tier.

• Scrolling a Single Tier - An alternative to stretching a single tier to fit the vertical space might be to leave it at a fixed size and add a scroll bar when the height of the tier's display exceeds that allocated.
• Zooming a Single Tier Vertically - A single tier might be "zoomable" somehow. Note that this requires scrolling when zoomed in past the point where the entire tier can be seen at once.
• Expanding a Single Tier Vertically - Manipulating a border between two tier labels as above could have other behaviors.
  • For a single tier being expanded or shrunk we could provide a way to toggle the shrink to fit behavior if the tier.
  • Instead of shrinking one tier and expanding the other, one tier could be shrunk or expanded and all the other tiers retain their hight and just be moved up or down in the panel.
  • Or one tier could be directly shrunk or expanded and all other tiers shrunk or expanded in response keeping the overall height of the containing scene fixed. Think of an accordeon pleat being manipulated and all the other pleats reacting by making or taking space with the ends of the accordeon remaining fixed.

• All manual resizing and moving of tiers should be accomplished by manipulating the tier label.
• No tier scrolling (yet)
• Selection partitions tier resizing. Resizing affects tiers within the selection and not those outside it. Resizing tiers outside the selection affects only those tiers on that side of the selection. It does not affect selected tiers. Nor does it affect tiers on the other side of the selection.
• Dragging interior borders (either within a selection or when there is no selection) accordions tiers above and below (again with respect to selection as above).
• Dragging the top or bottom border of a selection squeezes or expands the selection and the tiers on the outside the selection on that side. Tiers on the other side of the selection remain fixed.
• Zoom control expands only selected tiers (or all tiers if none have been selected) and pushes (not squeezes) outside tiers away.
• Dragging a border between tiers expands one tier and squeezes the other. When the squeezed tier reached its minimum height, the next tier is squeezed until it reaches its minimum height. Such squeezing cascades until there are no more tiers to squeeze. Then dragging is inhibited.
• Some spreadsheets have a nice feature of automatically resizing a column to fit its contents when the column's right border is double clicked. When the tier label is double clicked the tier should expand (or contract) to its preferred size. Other tiers should be pushed or pulled to accomodate this.

Stability of the Axis

In the shuffling example above the axis was moved to a new position. However, the position of the axis tier should probably change. Nor should the axis tier be resized. This tier has special meaning in that tracks displayed below it are generally on the reverse strand. So changing the axis position in the stack of tiers would have undesired semantic consequences. Resizing might be allowed within bounds, but those would have to be carefully chosen.

Tier Height Constraints

Is there a way to specify a minimum or maximum height for a tier? This would be useful for the axis tier and maybe for others.

Emulating the Swing API

Even though these are not Swing components it might be instructive to look at how Swing addresses some of these issues. In particular a layout manager and constraints might be employed.

Single-track Stretch

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.

This horizontal portion of the "crosshair" might extend to the edges like the vertical hairline does now. It should also be translucent like the vertical hairline. Both of these things might help avoid confusing the horizontal hairline with glyphs representing data. Also it should probably only appear in the tier that has the focus.