Improve visibility of filtered samples under various conditions

[trvrb]

Context
The implementation of a "Zoom to Selected" button on the tree has been really useful. I'll often filter to say clade 21A and then be able to just click to zoom in properly.

However, there are a number of edge cases where "Zoom to Selected" isn't very helpful. For a simple example, if we filter to early samples (https://nextstrain.org/ncov/global?dmax=2020-02-01) there's no way to zoom into these (the button is deactivated). Or if we filter to clade 19A viruses (https://nextstrain.org/ncov/global?f_clade_membership=19A) there's also no way to zoom in.

Description
We could at some point contemplate a fancier "accordion" view which would help to emphasize situations where multiple blocks of tips are selected, but before this we should get basic bounding box working (the accordion view would require updating node y-values and will necessarily be more involved).

Instead, I'd recommend when clicking "Zoom to Selected" to calculate the maximum x and y-values and the minimum x and y-value out of all visible nodes. Use these values to define the bounding box to zoom to.

cc @joverlee521 who implemented the initial version of zoom to selected in #1257. This PR contains discussion of the implementation challenge of this bounding box design.

This implementation would also resolve #1360.

Related issues

• Button to zoom directly to a filter #1634

[victorlin]

Picking this up after prioritizing in https://github.com/nextstrain/private/issues/129 and chatting with @jameshadfield the other day.

First setting some terminology:

• Zoom: an operation that changes the x/y axis range. The current "Zoom to Selected" does this.

• Focus: an operation that changes the scale within an axis without changing the range.

With these definitions, #1373 is about focus, not zoom. I've updated that PR with a separate "focus" button to distinguish the two. This issue as described is more about improving zoom, not focus. So I don't think it should be closed by that PR.

Changing focus on the y-axis (of the rectangular tree view) is trivial because there is no labeled meaning to the y scale. So adding more gap between the focal tips and shrinking the gap between non-focal tips is trivial. This is what #1373 does currently.

Changing focus on the x-axis is less trivial because the x scale is currently a linear representation of time or divergence. It may be possible, but more thought would have to be put into how to make this user-friendly.

Some open questions:

1. Do we need both zoom and focus?

   In tree: Add toggle to focus on selected #1373 (comment) @jameshadfield says

   I haven’t fully thought through all the use cases here, but I think we could remove [the (existing) “zoom-to-selected” behaviour]. We can still zoom into clades by clicking on branches to explore certain parts of the tree, which is essentially what the button does.

   I would think the opposite: depending on the scenario, if zoom can be adjusted properly for any selection, the ability to focus seems could be less helpful. For example, if it's possible to zoom into a date filter, then it may not be necessary to implement focus for x axis (which is not trivial as described above). However, if filtered tips are scattered across the y axis, focus may be more helpful than zoom but I wouldn't remove the zoom functionality. I can imagine the scenario where both y-zoom and y-focus would be helpful and will try to find a linkable example.
   I'm not an active user of the tree, so hopefully someone who uses it more has additional thoughts.

2. Is y focus useful without x focus?

   It seems like the answer is yes. x focus only becomes more useful as the majority of selected sequences fall within a narrow x range (e.g. filter to early samples). Example where y focus is useful by itself:

   

[joverlee521]

Do we need both zoom and focus?

The zoom/focus split reflects the technical implementation details, but I'm not sure the distinction is totally obvious to the user. It feels like the zoom/focus split should be completely behind the scenes. If the MRCA is not the root, then zoom + focus. If the MRCA already to the root, then just focus.

Is y focus useful without x focus?

Yes, I think it's still helpful with large trees.

[jameshadfield]

Is y focus useful without x focus?

Yes. Using your terminology I'm not sure that x focus will be a good idea, but I think there's a good zoom implementation available.

[victorlin]

Thanks for the answers! I have a better understanding now after fixing up the focus implementation in #1373 – adding my own answers:

Do we need both zoom and focus?

Yes, at least for now. The focus implementation in #1373 has notable differences from zoom:

• Focus is controlled by a toggle in the sidebar rather than an in-panel button.
• When toggled on, focus is updated upon any relevant changes (i.e. "auto-focus"). This is different from zoom which changes when clicking "zoom to selected" or a branch, followed by manual adjustments (zoom out, reset layout, more filtering/clicking).

We could consider adding an "auto-zoom" toggle in the sidebar. If implemented, it might make sense to merge the two toggles.

Is y focus useful without x focus?

Yes, and let's not plan to pursue x focus. The next step in this direction is to implement x zoom.