Scrolling row/column labels that follow the cursor ("whizzing labels")

[Robert Leach]

Col/row label areas should always have a fixed-font-sized list of labels with a marker in the center indicating the row/col the cursor is currently hovering over. These lists should animatedly zip by as you drag the mouse over the matrix. Here's an example of how I propose dealing with the edges: if your cursor is over the last column, the last column's label will be under the tick mark in the center and the space to the right would be empty. If the cursor hovers off the matrix, the label scrollers will continue to show the last hovered-over spot. Selected spots should highlight the corresponding labels.

[Robert Leach]

Anastasia commented that she liked this idea, so I changed it from proposal to enhancement.

[Robert Leach]

I just had what might be a better idea for label visibility. I think it's better because I could imagine that the dynamic scrolling described above would likely be annoying to most users. Here's what I propose:

When the zoom level does not permit label viewing, make the row labels pane vertically scrollable and make the column labels pane horizontally scrollable. This way we can always allow the user to peruse their genes and samples. We can draw a highlight of some sort that shows the area the labels correspond to. Here's how I envision it would look:

If the user scrolls the row & column panes, the blue bar would track which section of the image the labels currently correspond to:

Alternatively, you could use a highlight in the data instead of blue scroll bars:

However, the downside of this would be that you could never view the entire tree. I have a few primordial thoughts on addressing this, like the ability to grab the end of the blue scroll bar and expand it, menu options, or completely unlinking the tree from the labels (which I think is what I would lean toward).

What do you guys think?

[Robert Leach]

I was thinking more about this. Mainly, I wanted to address the issue of not being able to see the whole tree. I think that probably the amount of the tree you can see should be statically linked with the amount of data that is visible, so I think that decoupling the labels from the tree and allowing the user to scroll the labels independently would be better. I also think that it would be more intuitive if there was a highlight on hover over the data too. That way, it would make it more intiuitive because the user would see the highlight as they hover over the area that the labels belong to. I mocked up an example of this:

As you can see, the cursor is shown in the image. Above and to it's left, there's a red square on the blue bar representing where you are. There is also a red highlight of the gene/sample names that correspond to that location and a red highlight in the tree which is completely zoomed out (same scale as the image).

Once you get the hang of what's going on, a user might actually want to have the blue bars follow the mouse and additionally have the ability to pin it in place. I could for-see this as a preference setting called "labels follow mouse". I could also imagine a contextual menu from right-clicking a spot that says "pin" or "unpin" column/row labels (or just all labels).

Of course, we'd want to use a color scheme for the labels & bars that would not conflict with the selection color. I was just trying to make it easy on myself for the image mock-up.

[Robert Leach]

So I had wanted to bring this issue up in the last meeting because I wanted to see what you guys think, but decided it was not applicable to the meeting context. I have changed this idea significantly through my comments above. Instead of something that follows the mouse, I decided that if zoomed out to a degree that no labels could be legible, we could show a portion of the labels with a scrollable label area and highlights on mouse-over.

Any thoughts @abarysh, @TreeView3Dev, or @lance_parsons?

[Robert Leach]

I just had a better idea about this. Instead of blue scroll bars, I think it would be awesome to draw a blue highlight (similar to the yellow highlight for selections) around the area whose labels are displayed. Then - get this - scrolling would move the blue box (and also scroll the labels). If the user is zoomed in to a degree, scrolling would move the blue box and when the blue box hits an edge, it would scroll the view.

Once the zoom level is at a point where labels can be displayed normally, the blue box would disappear and the color of the labels would switch from blue to black and scrolling would work as it currently does. As one zooms out, when the labels would normally disappear, a blue box would form on the region that was visible just before the zoom level got too big to display labels.

I know it sounds weird, but I can see if in my mind's eye and I have a feeling that it would work really well. I don't think a static mock-up would do this idea justice. You'd have to experience it to realize how cool I think this idea is... I think it's really cool anyway. But here's a mockup just the same:

[Robert Leach]

This first version of this feature (as is depicted in the 3rd comment in this thread) is implemented in the "whizzing" label idea branch. Refinements of this issue should be a separate ticket.

[Robert Leach]

Merged to master.