Enforce a minimum zoom level

[Robert Leach]

Perhaps allow user to change this in the preferences.

[Robert Leach]

I figured this would be an easy issue to start off with to familiarize myself with the code.

[Robert Leach]

Implemented a minimum zoom level for the "zoom selection" feature only. Arbitrarily chose a minimum dimension of 20 and ensured that the selected spot is always in the center of the zoomed area (by going past the minimum zoom level if the center of the selection is less than 10 from the edge).

[Anastasia Baryshnikova]

Sounds like one of your alpha-testers (Justin Nelson) finds this unintuitive, so I though I'd reopen this issue for discussion. His comment is: the zoom-to-selection behaves in an unexpected way, it does not zoom-to-selection but zooms-to-something-centered-on-selection. I can see his point and maybe we should reverse this to the default behavior? Justin's comment is below:

Bug 5) When you zoom to a small enough selected area, if you select a region in the middle of the heatmap, it will not zoom in completely (it shows what you selected and an extra margin). If you select a point along the edge of the heatmap, it will not longer show a margin along one of the axis. In the extreme case, selected the top left point of the heatmap and then zoom to selected area" will bring up one "pixel" as the entire view.

Activate by: 1) Select the top left, top right, bottom left, or bottom right pixel, or any pixel along an edge 2) zoom to selected view

[Christopher Keil]

We should either let it zoom to a set minimum in all possible cases or allow full zoom for all possible cases. I suppose the reason why Justin finds the behavior unintuitive at the moment is because it is inconsistent.

[Anastasia Baryshnikova]

Yeah, exactly. I think full zoom in all cases would be ok.

[Robert Leach]

I had emailed this earlier from my phone. I'll copy it here for documentation purposes.

Don't have my bitbucket password on my phone...

Well, we'd spoken about this when I implemented it. The edge case was intentional because we wanted to keep the selected spot in the center. The concern there was that the user would zoom in and not see their selection in the center, and I think that's possibly just as disorienting for the user. I agree that neither solution is ideal and think we can do better. I'd suggest a smaller minimum zoom, like 3x3 with no full zoom in edge/corner. The dot not being in the center should not be as much of an issue at that level.

Possibly even a better idea (or perhaps not) would be to always zoom so that the yellow selection is always 1-in from each edge, except on the edges of course. The idea here is that it's hard to see the yellow border when it is fully zoomed and the user may need a moment to orient themselves with the sudden zoom.

Perhaps the best idea would be to animate the zoom all the way down to full zoom. This is something I believe I could do given my new zoom code.

Rob

[Robert Leach]

I'll do the work for this issue. Let me know what you guys think about the possible solutions proposed thus far:

1. Always full zoom - easy
2. New 3x3 minimum with no "centering/full-zoom" on the edges/corners - easy
3. Always full zoom + 1 row/column on each edge with no "centering/full-zoom" on the edges/corners - medium easy
4. Always full zoom with animated zoom (using new zoom code for opt-click of zoom-to-selection button) - medium

Rob

[Anastasia Baryshnikova]

I think we should do the full zoom at all times (possibly with animation, if not too difficult). Yeah, the original implementation was intentional but, as far as I remember, not to keep the selection in the center (with full zoom it's in the center by default, it takes up the whole screen) but to give a little bit of context to the selection (show what's in the immediate vicinity of what you selected). I now realize that, once the user learns the zoom in/out buttons, this is not really an issue. And with the animation, it will be even less of an issue. So I vote for the simplest (and the most predictable?) behavior: select area -> maximize the selection to the entire screen.

[Robert Leach]

Will do. I'll give the animation a shot. Should be fairly easy in principle. Just need to loop a zoom increment call to the function "zoomToward" and put like an N millisecond delay in there.

[Robert Leach]

Hey @TreeView3Dev, what's the best way to implement a delay/sleep for the zoom-to-selection loop? I saw TimeUnit.MICROSECONDS.sleep(int), but there are other methods.

[Robert Leach]

I'm still working on cleaning up code and organizing it into more appropriate classes, but the functionality now works as intended. If the animation speed needs tweaked, please open a new ticket. Note, there is a new "easter egg" for power users. Holding command while clicking either the zoom-to-selection or home buttons will jump to the target area suddenly without animation. Clicking home when the matrix is enormous still lags slightly. If it's bothersome, a tweaking of the log scale for deciding amount of zoom per step should be done.

[Robert Leach]

Merged to master.

[Robert Leach]

Removing milestone: Navigation (automated comment)