Open jrosindell opened 10 months ago
Does the term 'branches' here include interior nodes, or could that be treated as a third concept with its separate scheme? i.e. leaves vs interior nodes vs branches.
We should also keep the Extinct Species project in mind, to make sure we end up with a meaningful color scheme for that scenario. In particular:
Good thoughts @davidebbo - actually I too wondered about nodes as a third scheme but didn't want to over complicate things.... In many cases we'll just consider nodes as being like branches. I think it's a good idea to bear nodes in mind though.
With regards to extinct species.... I think they are somehow part of the fundamental tree topology and should be reflected as such in addition to any colouring options. The colours may be switched off whilst the fundamental topology is baked in. We have this already https://www.onezoom.org/life/@Dinornis_robustus=208456 and used a circle rather than a leaf for it. I quite like this difference as a leaf is more synonymous with life somehow. Another (not implemented) idea would be to shorten the branches but a small but perceptible amount if leading to an extinct species.
Love the idea of geological period of extinction for the leaves.... this would actually go hand in hand with a colour scheme showing geological period on branches - if the branches terminate early then it's naturally that they flood the leaf with that colour rather than the present day colour.
For the average extinction risk scheme put forward by @wolfmanstout I think you would discount extinct species i.e. they don't contribute to the average - just as is done for data deficient and not evaluated species.
Most wild idea (researcher hat on now) use mappings to probabilities of extinction within a given timeframe and calculate for each branch the probability of losing all living descendants hence parts of the tree near the tips will be coloured based on endangerment to that branch.
I feel that there are two very different categories of extinctions, that call for different handling:
This ties into the discussion in https://github.com/OneZoom/tree-build/issues/43, and on whether we want these to join the main tree or be kept separate.
Most wild idea (researcher hat on now) use mappings to probabilities of extinction within a given timeframe and calculate for each branch the probability of losing all living descendants hence parts of the tree near the tips will be coloured based on endangerment to that branch.
Yeah, this was basically what I had in mind as the scientific justification for coloring branches based on the averages of their non-extinct child nodes (in addition to the aesthetic and navigability value). In practice, the actual risk of extinction of a branch is likely to be lower than the average of the leaves (depending on how independent the extinction of each leaf is). But I think an average color is intuitive enough and will provide a good spread of colors so we aren't colouring most branches green (which isn't exactly helping with the message of extinction risk).
I'm setting up an issue to contain thoughts on development of colourings of the tree. This is following some ideas suggested by @wolfmanstout for letting extinction risk colourings percolate up the tree branches using the already pre calculated summary data on interior nodes about this.
Issues that came up were interaction between this and other kinds of information that we've thought about showing in the branch colouring (e.g. highlights, common ancestors, polytomies). Also the hacky solution for colour blind friendly accessibility in which every colour scheme has a colour blind counterpart that counts as just an independent colour scheme only with _CBL appended to name.
I like to begin describing things in terms of the ultimate solution see what people think, then scale back from there with a step by step development plan. To that end I think....
A cut back intermediate step to this end would be to divorce leaf and branch colourings in the colour scheme code, let there be a plain branch colouring that's set by the common ancestor feature, and retain the same UX as we have now, hiding from users that when they select a colour scheme they are in fact selecting a pair of independent things.