Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web site features for GemBrow #27

Open
16 of 18 tasks
ppavlidis opened this issue May 11, 2023 · 7 comments
Open
16 of 18 tasks

Web site features for GemBrow #27

ppavlidis opened this issue May 11, 2023 · 7 comments
Assignees

Comments

@ppavlidis
Copy link

ppavlidis commented May 11, 2023

Jotting down some required features/improvements/tasks

n.b.: GemBrow is just an internal name!

Reiterating the two big use cases:

  • User wants to see what we have in Gemma.
  • User wants to identify specific data sets for downstream use.

These have to motivate our development approach.

  • Integration with the current web site. This should be linked from the Gemma home page and match the style to the extent possible (this means changes to the header, footer, fonts). The old search can still be provided (and it covers searches of genes etc. that GemBrow doesn't)
  • Add "what's new" (see Add "whats new" #1)
  • Screening of non-useful terms from the side display. Examples: "Wild type genotype" "reference subject role". These can be programmatically identified at least in part using BaselineSelection.isBaselineCondition, and Ogan also has been developing a list of stopterms for GemmaDE that might be useful.
  • "Study design" should not be shown as a category as this is only used for "Subset" which we don't need to expose here. Nor should "Dose" which by itself is meaningless.
  • Eliminate the ontobee links associated with the ontology terms. Instead, consider a (?) tooltip that gives the ontology definition of the term.
  • Add a title to the experiment characteristics section, it is not clearly separate from "Platform"
  • The ordering of categories should be kept constant. Currently, when you check a box to filter, the order can change so "organism part" is now above "genotype" or vice vera. This is confusing.
  • The number of entries shown for each category seems limited right now? The smallest count is 50. We should just show "everything" (until performance becomes an issue)
  • Experiment table: rows should be expandable (like the old browser) or there could be a pane at the bottom to show details for the selected experiment like here - in any case some way to show some more detail.
  • Clicking on an experiment name in the table currently replaces the browser. I am not sure this is the best behaviour, though it's a bit of a toss-up. To discuss.
  • Experiment table: Allow this to be downloaded as TSV
  • Experiment table: show status and presence of DEA like on the old browser. Possibly allow filtering by this.
  • Experiment table: default sort should be by most recently updated, currently it is by ID.
  • Generate R code to load the data sets and display this in a pop-up perhaps (i.e. on user request). Some thought might need to be put into this - we wouldn't want it for hundreds of experiments! I'm thinking if they locate 5 or 10 that would be fine, so this feature would be disabled otherwise or trigger an error message if they try it for too many data sets. (see Code snippets to download datasets with R, Python and curl #31)
  • Cosmetic: the word "Search" is clipped at the top of the page at least on my browser.
  • Type-ahead searches might not be a good idea if it triggers a lot of searching. The "There's already pending search" message must be eliminated in any case
  • Searching should result in the reason for the positive hits being shown, like in the current search page. For example, show a clip of the text that matched, or describe the association (e.g. via FactorValue). Users should be able to tell why the hit was retrieved.
  • Give a clearer visual indication that the view is filtered by a search term. One way to do this is to display "Showing 123 experiments" at the top of the table. It currently only has this as small text under the table.
@ppavlidis ppavlidis transferred this issue from PavlidisLab/Gemma May 11, 2023
@arteymix
Copy link
Member

I've added a debounce of 1 second when the user is actively typing and removed the check for pending requests. We might have a few queued requests, but it's not perceivable since the site is reply quickly.

@arteymix
Copy link
Member

Terms are sorted by entropy (the closest they are to split 50:50 the total number of datasets, the best) and category by taking the term with maximal entropy. Terms that are selected always appear first.

If not using the best term, what should be the ordering? A predefined one? or alphabetic?

@ppavlidis
Copy link
Author

Terms are sorted by entropy (the closest they are to split 50:50 the total number of datasets, the best) and category by taking the term with maximal entropy. Terms that are selected always appear first.

If not using the best term, what should be the ordering? A predefined one? or alphabetic?

Are you referring to the "The ordering of categories should be kept constant" point?

I would suggest a fixed ordering. We can debate what ordering is most aesthetically pleasing but that's what it comes down to.

A heuristic would be to go off how many relevant datasets we have for each category in total - not for the current query/filter, but in Gemma. So Disease might be first, OrganismPart second or whatever. My intuition is that will align with what people are most likely to be looking for on average.

@arteymix
Copy link
Member

Ok, that might require some kind of configuration for the default order of categories.

For Gemma integration, the Vue router can pass parameter from the URL fragment to the browser:

image

This way we can generate links from the main Gemma website to perform a specific search on GemBrow.

@ppavlidis
Copy link
Author

Having a search field elsewhere on the site that goes to the browser would be nice, but minimally we just need links to the browser, and the browser should have the same or at least similar chrome (header, footer ... menus? etc) as the rest of the site. That's what I mean by integration. Of course I don't mean to make that into a major job.

@arteymix
Copy link
Member

The number of entries shown for each category seems limited right now? The smallest count is 50. We should just show "everything" (until performance becomes an issue)

Past 2000 terms, it's challenging to handle from the browser because of the rendering. We might need some kind of lazy-loading strategy to query sub-trees.

Experiment table: show status and presence of DEA like on the old browser. Possibly allow filtering by this.

I'll see if this is covered by the filters. From what I recall, this is filled in the detailed EE VO.

@arteymix
Copy link
Member

arteymix commented Jul 7, 2023

I think @libby-natola can handle the following:

  • sorting results by last updated
  • show the number of search results in the appbar
  • generate gemma.R and gemmapy snippets to download and also curl snippets, we might want to use a library for highlighting the code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants