Allow row/columns to occupy a portion of the screen

[Anastasia Baryshnikova]

USE CASE: WHAT DO YOU WANT TO DO?

Have more flexibility when adjusting the height of rows and columns

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

Load in a file with only a few rows or columns (example with 1 column -- attached).

CURRENT BEHAVIOR

The columns are stretched to fill in all the available space. The zoom out option (to compress the column width) is disabled.

EXPECTED BEHAVIOR

The zoom out option should still be active, so that the user could compress the column width. The space in the data panel that becomes unused is filled with grey.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

e.g. Add a color selection class

FILES AFFECTED (where the changes will be implemented) - developers only

e.g. selectColor.java & settingsPanel.java

LEVEL OF EFFORT - developers only

trivial/minor/medium/major/overhaul (choose one)

COMMENTS

[Robert Leach]

A few notes...

• To a limited degree, the user can affect the "aspect ratio" of the tiles by resizing the window.
  • Such a manipulation can change by zooming rows or columns
• To a limited degree, the user can affect the "aspect ratio" of the tiles by zooming rows or columns
• We have an issue for fixed-width tiles (Issue #45). This might perhaps be what the user really wants. I doubt the user would ever specifically want a particular tile shape that is not square or which does not fill the available space. Note that if the aspect ratio of tiles is static, then row & column zooms would not be possible - all zoom buttons would zoom the same way.
• We are still restricted to drawing whole tiles, so note that when zoomed in, which should be in the space filled with gray, will not be displayed if the whole tile cannot fit.

Rob

[Anastasia Baryshnikova]

In this specific example, the user figured out the option of resizing the window but saw that you can only do it to a certain point. The size of their matrix was 3 x ~4000, so #45 wouldn't be the answer here either. The use just wanted to get the rows to a reasonable height, not fill in the screen, but not necessarily 1:1 with the columns width either.

[Anastasia Baryshnikova]

This user was using their own file, not the one attached here (this one is just an example to illustrate the issue).

[Robert Leach]

Hmmm... I thought #45 was supposed to accommodate the whole-tile limitation, but apparently it specifies the desired capability of drawing partial tiles. So what I meant to suggest was that instead of allowing any arbitrary aspect ratio (as I infer this issue to advocate), we support 2 modes: a fixed square aspect ratio (with unoccupied area filled with gray) or fill the available area. In fact, I'd probably want to split #45 into 2 issues: 1. a fixed square tile aspect ratio (like this issue) and 2. the ability to display partial tiles.

Note though that zooming would still be a weird issue in the case of staying within the full tile restriction. Imagine a fully zoomed out matrix (a 3 column, 100 row matrix) with wide gray bars on either side. First, do we allow them to zoom out fully to a global view - i.e. a thin strip of matrix down the center? In that case, zooming would change the size of those gray bars. That's one thing the old square-dot feature could not handle. The old TreeView3 used to have a square-dot feature and it was only a momentary aspect ratio. As soon as you zoomed, it would no longer be square.

[Robert Leach]

It just occurred to me that issue #36 would also mitigate (but not fully solve) this issue.

[Robert Leach]

Being concerned about possible unforseen ramifications of this issue that affect the user experience, I went to the effort to simulate how zooming would behave if we implemented this "portion of the screen" idea. Given the legacy restrictions (if we do not do an intensive full rewrite of TreeView3) of only being able to draw full tiles, we can take (as I see it) one of two possible strategies. Both strategies attempt to provide as smooth an experience as possible, meaning the matrix is navigated in a manner that keeps the tiles' relative position from jumping around. Consider these moving gifs to represent the area of the TreeView3 window containing the matrix:

1. Use all available space the window provides

   

2. Use a static area in which to draw that reflects the aspect ratio chosen

   

In option 1, we're always using as much of the available screen area as possible and as a result, there are either gray bars on the sides or on the top & bottom. Both sets of gray bars dynamically change size to keep the tiles from jumping around.

In option 2, either the sides or the top & bottom are fixed and the opposing dimension has gray bars that keep the tiles from jumping around. The fixed bars define an overall space which represents the selected aspect ratio. I drew a black border around this fixed space in which drawing occurs to highlight it.

A third option, which does not necessarily conform to the parameters of this BB issue is an idea I had: a trick to fool the interface into allowing the user to manually create a tile shape that roughly represents squares, but mainly only when zoomed out or by changing the window shape when zoomed in. There would be no way to fix this aspect ratio and there are other downsides/idiosynchrasies, but it would solve Elena's zoomed out tile shape issue. Basically, we could create gray tiles to fill in the space enough to make the tiles look square. Zooming would behave as it does now, allowing tile-shape to change during zooming. Once a user got to a spot of interest, they could either use the scrollbar zoom buttons to change the shape or resize the window. This is a kludgey hack and probably not worth the effort.

[Robert Leach]

Note that both zoom gifs are based on our current slow zoom behavior (control-clicking the plus button) which shaves a row/col off each side on a single zoom step. In both options however, if there was room to draw full tiles, I did not shave off rows/cols of 1 dimension. This only ended up affecting option 2.

[Robert Leach]

After watching the gifs for awhile, and liking neither option aesthetically, I think we need to think of better ideas to address the tile shape issue, such as allowing the user more freedom in changing the window size/dimensions (and possibly rethinking the layout as a result).

[Robert Leach]

OK - another critical detail... The input file I used has an error in it. I have no idea how the file was generated - might have been generated by an old faulty version of treeview clustering... However, one of the middle columns is UID (column "CE" in excel). Most of the values in that column are empty other than a handlful of very large numbers, e.g.:

• 1292105
• 1276380
• 1292535
• 1292829

The rest of the data is roughly between-2 and +2.

Here's the file:

https://bitbucket.org/TreeView3Dev/treeview3/downloads/faulty-UID-column-position-11.cdt.zip

This issue perhaps is simply an issue of catching data errors and presenting the user with an explanation.

[Robert Leach]

I occurs to me that this issue could be mitigated by creating dummy rows or columns that would be artificially set to a gray color. ...Just a thought.