OneZoom/OZtree

Positioning of tree on default loading

Closed this issue · 7 comments

This one has annoyed me for a while now...

If I load just /life.html with no other instructions, it does not nicely centre the full tree on the screen - it's displaced upwards.

Hrm, seems to me it drifts to the left, not upwards. But I think there's some timing magic going on.

/life/@biota is nicely centered. I think we need to always do some kind of init_move_to, and default to moving somewhere than rely on the default tree position. Assuming this will happen should make the tree setup cleaner.

However, is @biota the right choice? Would @Tetrapoda make a better default? Then you have a lot of familiar names within easy reach.

Besides, the tree root has always felt a bit unsatisfying to me (even when centred), and doesn't feel like something to show off by default.

Hrm, seems to me it drifts to the left, not upwards. But I think there's some timing magic going on.

/life/@biota is nicely centered. I think we need to always do some kind of init_move_to, and default to moving somewhere than rely on the default tree position. Assuming this will happen should make the tree setup cleaner.

However, is @biota the right choice? Would @Tetrapoda make a better default? Then you have a lot of familiar names within easy reach.

Besides, the tree root has always felt a bit unsatisfying to me (even when centred), and doesn't feel like something to show off by default.

Agreed this is the way forwards - and yes the root is bad both for users and scientifically as it's dodgy - we don't really know where it is. Conversely @Tetrapoda is too deeply in and biased against the broad variety of things we have.

I think we can go for @Eukaryota=304358 or @Metazoa=691846 as the default

The default location is in global_config.js, if you'd prefer something other than @Metazoa=691846:

/** @property {string} default_init_pinpoint - Default initial pinpoint if none specified in the URL, i.e. "/life/"
*/
config.default_init_pinpoint = '@Metazoa=691846';

Challenge is that this makes /life/ blow up when using a non-default tree that doesn't include Metazoa.

Obviously each tree owner can change default_init_pinpoint to some other default, but that seems unnecessarily painful when they don't need a non-root default (and most smaller trees don't need one).

Suggestion: if default_init_pinpoint doesn't exist, just ignore it and go to the root, without displaying the "Sorry, the species or group that you asked for is not on the OneZoom tree" error.

Challenge is that this makes /life/ blow up when using a non-default tree that doesn't include Metazoa.

Hrm, very good point. Although silently eating errors seems like a recipe for frustration.

How about we set default_init_pinpoint inside completetree.js instead of within the JS config, and if you haven't set one then we default to @_ozid=1?

Or we just set the default to @_ozid=1 and forget I suggested changing the default :)

Note that I was not suggesting always ignoring unknown pinpoints, but only ignore it if it happens to match default_init_pinpoint. But yes, that might still be quirky.

completetree.js is the data file generated by the tree-build repo, right? So that would mean generating the line that sets it from somewhere in https://github.com/OneZoom/tree-build/blob/d0aa5b9d2e8306eb316497b582b73c84713b946a/oz_tree_build/utilities/make_js_treefiles.py. I wonder if that just moves the same issue to somewhere else, in the sense that someone generating a custom tree would need to remove that line.

In a perfect world, it would be all data driven. e.g. a taxon in the newick would be marked in a way that makes us treat it as a default start, and it would all fall from this. But that's way over engineered for the benefit.

So yes, maybe focusing on @jrosindell's original positioning issue without changing the default is probably simplest. And frankly, I think there is something quite cool about seeing the entire tree by default, even if the taxa that show up are less familiar.

Note that I was not suggesting always ignoring unknown pinpoints, but only ignore it if it happens to match default_init_pinpoint. But yes, that might still be quirky.

For example what if I try and set config.default_init_pinpoint = '@mammal'(sic), I now have to hunt through the source to find out why it's not working, only to find out I got the pinpoint wrong.

completetree.js is the data file generated by the tree-build repo, right? ... I wonder if that just moves the same issue to somewhere else, in the sense that someone generating a custom tree would need to remove that line.

The other way round IMO, someone generating the OneZoom tree would have to add that line, or at least it'd be an option set somewhere in tree-build-land, which is set to the root node by default.

OTOH, there's other things that are going to require poking for a radically different tree, The popular places for one. If the option lived at this level instead it'd be an easy spot when setting up a non-default tree.

Another option is we already have a table called tree_startpoints, maybe we should pull it out of there.

I think there is something quite cool about seeing the entire tree by default

I think part of my beef with it is the pzoom animation doesn't make sense at top-level. You don't see there's more detail, it's just a twig landing from on high. A special case that reverses the pzoom at the top level, e.g. onezoom.controller.fly_on_tree_to(827928, 1) would help matters I think.