Add button to zoom tree to visible tips

[trvrb]

Context
Currently, there are two primary ways to interact with the tree:

1. Click on clades to zoom in. This works pretty well much of the time but may require multiple clicks and with large trees it may be impossible to actually find the clade to click on. @batson summarizes this issue well in User cannot identify and click individual branch if there are too many #1111.
2. Filter to a subset of tips via filters interface. This works well to highlight particular samples and show where they fit in the larger tree. However, once filtered it can be difficult to examine these in more detail. For example, https://nextstrain.org/ncov/north-america?c=division&f_location=Grand%20Princess%20cruise%20ship&r=division shows the 7 Grand Princess genomes but it's hard to see much other than that they cluster roughly together.

There is often a user desire to filter (or otherwise subset) to a portion of the available samples and "zoom" into this subset in the tree.

Description
I propose adding a button to the tree panel titled "ZOOM TO VISIBLE". Clicking this button acts to find the common ancestor of visible tips and initiate a clade zoom for this node.

However, there will situations where a filter subsets to a non-monophyletic (discontinuous) group of tips. In this case, I'd recommend that this "zoom" also compress y-values surrounding non-visible tips. @jameshadfield previously implemented this "accordion" style zoom in the branch js-y-vals. Here's an example of this compression:

Here, I'd still take the minimum and maximum y values as the min/max of the selected tips, but in between this min/max non-visible tips would be compressed.

The entire tree would be restored by clicking on "RESET LAYOUT" as is behavior for clade zoom.

This direction sets us up to have a box-selection option (say hold down option while dragging over the tree) that could select a user-specified region and followed with "ZOOM TO VISIBLE". I believe this would solve @batson's original issue, but would add significant flexibility by interacting through visible nodes rather than a direct tree operation.

What do folks think about this proprosal?

[batson]

I like this proposal very much!

Non-monophyletic is our generic use-case: after selecting all samples in some location + time window, we get groups scattered around the tree whose common ancestor is usually the root. If the accordion is compressed enough, we may get much of the benefit of exploded trees showing all the groups at once without having to fully hide the contextual nodes.

It will be important to be able to select nodes with option+rectangle, so we can zoom to a group of nodes which is currently difficult to select on the div tree (where the internal node which would specify them are kind of on top of each other) or the time tree (where the node specifying the group might be far to the left on the screen of the set of nodes we are interested in.)

Here's an example of a selection which might be an interesting test case: select all CA and then ZOOM. Notice afterwards a group of samples in the bottom I want to see closer, and ZOOM again (orange rectangle).

Terminology: might ZOOM TO SELECTED by more accurate? (The branches without terminal nodes still look visible to me, but this may not comport with the terminology in use on the backend.)

[mingiryu]

I think most people are familiar with the "select to zoom" interaction (ie, plotly). It's simple and intuitive.

[frogsquire]

Why was the js-y-vals branch ultimately not merged - was it just a proof of concept?

If the idea is to start with zoom-to-filtered-items, and then use that code to handle a zoom-to-selection, that makes sense to me. They can be separate issues, with one dependent on the other.

I think you could use the "zoom-to-selected" terminology for both of these operations; the mouse-drag selection, in that case, is really just a custom "filter" where the criteria for filter are "had x and y positions inside this bounding box."

[rleir]

I am trying out a few things along these lines. First, I need to make a simplified build with only the tree running in React. Auspice is a big complicated project. If I can improve the tree on its own, then we can find a way to fit the changes into the complete build. @jameshadfield James, do you have a trimmed build for when you are working on the tree? I am several steps down this path already.

[rleir]

@trvrb blab/sars-like-cov seems a bit more usable at first glance. Is this mostly due to having a smaller amount of data? I would like an overview of the differences compared with the Auspice project please

[trvrb]

Thanks for looking into things @rleir. The tree at https://nextstrain.org/groups/blab/sars-like-cov / https://nextstrain-blab.s3.amazonaws.com/sars-like-cov.json is pretty small, though I often work with https://nextstrain.org/zika / http://data.nextstrain.org/zika.json if I want a smaller test case to experiment with.

[allenkj2]

I think this would be really helpful! NCBI added this type of feature to their pathogen detection portal and I found it really helpful for zooming in on areas of interest especially on some of the 5000+ Salmonella isolate trees. They call it 'common subtree' and in their interface it opens a new tab with a new subtree, but I think the collapsing option proposed works well.

[corneliusroemer]

Should this issue be closed now? Zoom to selected seems to be implemented now in the way @trvrb intended with this issue.

[trvrb]

Perhaps the issue can be closed and we can make a new more targeted issue. The current implementation is 80% of the way there. We do have issues with zooming into some clades and an "accordion-style" zoom would be really nice for situations where tips from multiple clades are selected. I'll close this issue and plan to make a new one that addresses the updated needs.