Tree display should visually distinguish exemplar from non-exemplar

[jar398]

nice to have, not urgent

[jar398]

Example: Epichloe amarillans in study pg_2300 https://devtree.opentreeoflife.org/curator/study/view/pg_2300/?tab=trees&tree=tree4862 . All five tips look the same to me in the tree viewer. Here are two showing that there is at least one exemplar and one non-exemplar among them.

"otu328054": {
"^ot:originalLabel": "Epichloe amarillans 906", 
"^ot:ottId": 369201, 
"^ot:ottTaxonName": "Epichloe amarillans", 
"^ot:treebaseOTUId": "Tl38711"
}, 
"node847334": {
"@otu": "otu328054", 
"^ot:isTaxonExemplar": false
}, 

"otu328063": {
"^ot:originalLabel": "Epichloe amarillans 273", 
"^ot:ottId": 369201, 
"^ot:ottTaxonName": "Epichloe amarillans", 
"^ot:treebaseOTUId": "Tl38720"
}, 
"node847338": {
"@otu": "otu328063", 
"^ot:isTaxonExemplar": true
}, 

[jimallman]

This was confusing to me, since I was pretty sure we do in fact use color to identify conflicting nodes, chosen exemplars, and non-exemplars in the tree popup. On a hunch, I tried editing the study and marking this tree as preferred (ie, a candidate for synthesis). This activates a higher standard for curation, including the expected node colors and prompts to choose an exemplar from among conflicting (non-sibling) nodes with the same OTU.

TL;DR - Mark the tree as "preferred" to see the feature requested here.

[jimallman]

Reminder: The legend (sub-tab of the tree viewer popup) shows the color convention used for conflicting nodes. Maybe this needs a note explaining that this only appears in preferred trees?

[jar398]

But I expect people will want to do conflict analysis on non-preferred trees, and exemplars are essential for conflict analysis. How about we enable the coloring all the time, and allow setting exemplars for any tree, but only prompt for exemplars when it's the preferred tree?...​

[jimallman]

That works for me. As I recall, we wanted to keep the curation burden (and scoring, and prompting) manageable for studies that include non-preferred trees. We'll need a bit of prompting to direct them to the conflicting nodes, which really helps in making a choice. But we could ignore the non-preferred trees when reckoning the study's "curation quality" score.

Would this approach send mixed messages and be confusing? Paging @kcranston for her thoughts.

[kcranston]

I think we should allow setting exemplars on all trees. Why don't we provide a warning for conflict analysis on trees with duplicate OTUs that don't have exemplars marked?

Longer term, I would like to change the study quality score to remove the strong distinction between preferred and non-preferred trees, but that's a separate issue.

[jimallman]

Why don't we provide a warning for conflict analysis on trees with duplicate OTUs that don't have exemplars marked?

Agreed, esp. since this is an easy test from the client side. Since we're prompting for corrective action, we'll need to be more clear about them needing to modify and save the current study before running the analysis (since we're not submitting Nexson fresh from the curation app). @jar398, am I correct in assuming that changes saved to phylesystem will be immediately reflected in a new test?

[jar398]

"am I correct in assuming that changes saved to phylesystem will be immediately reflected in a new test? ..." - well, this is work in progress. You can ensure it's fresh by adding &use_cache=false. I need to implement a way to do this automatically, and that in turn will require some phylesystem-api support (conditional get with etag, or equivalent: https://github.com/OpenTreeOfLife/phylesystem-api/issues/171).

Or, if you think the service is fast enough when it doesn't use the cache (whenever the study isn't the same as on the previous call, or when use_cache=false), I can just turn off the cache.