Feedback form - Chris Mungall - 1. One of the most important things a user wants to see o...

[monarch-issues-tracker]

Name
Chris Mungall

Email
[email protected]

GitHub Username
cmungall

Details
Page: /node/MONDO:0011675?associations=biolink:DiseaseToPhenotypicFeatureAssociation
Browser: Chrome 116.0.0.0
Device: Apple Macintosh
OS: Mac OS 10.15.7
Engine: Blink 116.0.0.0

1. One of the most important things a user wants to see on a mendelian disease entity page is the causal gene. There is nothing on the TOC on the left to indicate this. Right now one has to scroll down past lots of text and histopheno to "associations". From there, you need to know enough inside baseball to know that there are two kinds of associations, and we need to switch from "phenotype" to "gene". This is non-obvious. There should simply be logic that detects if I am on a mendelian disease entity page, and just show me the gene
2. There is a lot of generic inside machinery in the URLs. Do we have to have "node" in the URL? Having biolink association CURIEs in the http params is also quite obscure. I appreciate that the site is generic and schema driven, which is a good pattern in a lot of cases, but as can be seen in my previous comment, the optimal layout for a typical Monarch user may not be isomorphic to biolink.

[cmungall]

See also monarch-initiative/monarch-ingest#429

[vincerubinetti]

There is a lot of generic inside machinery in the URLs. Do we have to have "node" in the URL? Having biolink association CURIEs in the http params is also quite obscure.

/node is not necessary, it was just added for clarity and to avoid (a probably very unlikely) name collision with another page, e.g. if there was a node named "phenomics-first".

The biolink association in the url is just to remember what types of associations the user is currently viewing, it's not necessary for the page to load. It needs to be a stable, unique identifier for the type of association, so if someone can tell me a shorter/abbreviated string that meets that criteria, I can put it in.

[vincerubinetti]

One of the most important things a user wants to see on a mendelian disease entity page is the causal gene.

Is there only ever one causal gene? If so, that could be included in the top level of the node api response, and I could display it in the "Overview" or "Details" section. I could also auto-select the casual-gene associations in the associations section when it's a particular type of node. But I don't think it would be a good idea to conditionally move the associations section up to the top, if that's part of your suggestion; best to keep things in a consistent order.

[cmungall]

for a disease entity you can assume a distrubution that is mostly zero or one, sometimes 2, rarely 3 etc but for grouping classes obviously more - but still relevant to show these up top. E.g for MPS a user would expected the causal genes to be shown prominently

[ValWood]

Related,
I'm presuming that your users will be much more interested in associations between genes and phenotypes or diseases, or associations between diseases and genes, than in the ontology or the external references. And surely the taxon should be right up in the top header with the gene name not in "details" right down the page?

[vincerubinetti]

Suggestion per @kevinschaper , when first loading node page, and auto-selecting first association type, don't put that in url. Wait for user to explicitly change association type to put in url.

[ValWood]

I'm not sure the solution (although it is an improvement) addresses the issue that the actual disease association is quite hidden?

It still isn't clear why you would want to put "hierarchy" or "details" above "associations" (anywhere). I guess heirarchy is above annotations because you want to focus on the "knowledge graph" aspect of Monarch . But how key is this to most of the end users of the website?

"Details" is a slightly random collection (source, taxon, external references), but it's also odd that "taxon" ( a key piece of information) isn't in the overview.

[vincerubinetti]

@ValWood Make sure you are looking at dev.mi.org and not next.mi.org. The change that closed this issue should've been automatically deployed to dev, but hasn't made it to beta or next yet.

Taxon was moved to the overview section.

Regarding your other comment, it sounds like you're proposing the order should be: Overview, Associations, Hierarchy, Breadcrumbs, Details. It's very easy to change the order of these sections. I just don't want them to be in different orders on different nodes. Another thing is that other members of the team signed off on this order in the design. If @putmantime or someone wants to give me the go ahead, I'd be happy to change the order.

[ValWood]

Yes the ordering was only an observation- definitely something you should check with UX rather than a single feedback.