High priority modifications to front-end of search results

[jmcmurry]

Of course dependent on #1383, and pursuant from #1317, below is a distillation of high priority improvements in order of importance:

Faceting by result type:

• Gene*
• Disease*
• Phenotype

* Note that while disease GROUP and gene GROUP are useful distinctions for each result, they need not be in facets as this may lead to confusion. Other facets will be considered in future.

Faceting by species:

Species facets should be common names wherever possible and ordered by frequency of search, eg.

• human
• mouse
• fish
• fly
• worm
• dog
• cow
• cat
• pig
• chicken
• other

Facet styling

• Facets must be on the left of the page and vertically oriented
• Facet counts must dynamically update with counts (from all results not just first page)
  Note that because both sets of categories are disjoint, it is not necessary to support ternary [+/-/either] styling. Checkboxes are adequate and even without checkboxes is fine as a first pass.

Results styling

• Intro to results currently says "Results for "xxx" searching phenotypes, diseases, genes, and models", however we are not indexing models yet and should remove this in meantime.
• Highlighted string must be shown in bold, this includes support for portions of words
• Gene results must include both the symbol and the name (Concatenated into the same column is fine for simplicity, else the matrix gets awfully sparse when interdigitated types come into play eg. "LHX 1 (LIM homeobox 1)"
• Taxon for diseases is named (99.99 % will be human, but needs to be stated)
• Taxon for phenotypes is named (eg. human, mouse, fly etc. Note that some phenotypes eg. GO cellular processes may require special handling)
• Once a category filter is selected, remove that column from the results table
• On mouseover, highlight the active row and make any part of it clickable
• Update summary text (or representation) to reinforce which facets are selected:

Results paging

• State total number of results: eg 1-50 of 450 results for "LHX"
• Enable user to load more results

Search box

• Don't blank out the search box, keep the searched-for-term in there so the person doesn't have to retype it to refine it.

Note that for now we agreed to stick with the table-style results as-is. We will revisit blob-styling with users after these other improvements are working. There are many other things we could consider, but for simplicity, I've left these out of this ticket as it is meant to be closeable.

[mellybelly]

+1 please make it so.

[jmcmurry]

In many cases, the filtered results won't be more than 1 page (say 50 rows per page)

We currently have no way to see results beyond the first 50 rows (or to even know that they exist). That is the big problem. If you would like to remove the paging buttons altogether if fewer than 50 results (whether filtered or unfiltered), I agree that would be fabulous. As an alternative to paging, lazy loading additional results is fine too.

I will let @jnguyenx and @cmungall speak to how best to structure the back end to be performant, but from the user's perspective

1. the facet counts must always be from the full set of results
2. the facet counts must auto-update based on what facets are selected
3. the total number of results must auto update too

For a working example of this, see Zappos.

[yuanzhou]

In my testing with "p53", it returns 315 total results, which consist of 18 phenotypes, 4 diseases, and 293 genes. If I set the upper limit to any number bigger than 315, I'll only get 315 results. If I set it as n (something smaller than 315), then I'll just get the first n results of 315. There's no way to just get everything back without specifying an upper limit. In this case, the upper limit and the start row 1 are used as the default pagination, which is only one page.

From the user perspective, I agree with your 1) point, because the facets with the counts are used as a information summary. When we also use them as filters that users can click, then auto-updating the counts on what facets are selected is very confusing, at least to me. Because this will also update what species or categories should be displayed once filters are selected. For example, if I select only phenotype with "All Species" clicked, then there's no disease or gene buttons should be displayed or their counts should become 0, in addition all counts of other species should become 0. And then how can I bring those buttons back? This is not a good design.

[yuanzhou]

Just to update that I've made progress on the search filtering. Once we click the two filtering sidebars, the count will be updated.

The Load More button will be gone if there's fewer results than the default per page count (30 for now).

Since some results don't have taxon info, as shown in the above screenshot, we won't be able to filter these diseases using the taxon filter. Since all the rendering of the filtering sidebars are based on the golr response, I consider the missing taxon is a data issue and am not handling that on the client side currently.

The reason I chose to use "Load more button" instead of numbered pagination is because once we load more results, we'll still be able to see the old records on the same page. And it may also encourages users to stay longer on the search result page, and so increase engagement and discovery. And users can also do a in browser search that covers all the loaded content. Another alternative is to use "Infinite Scrolling" and this articles talks a lot more about it versus pagination: https://uxplanet.org/ux-infinite-scrolling-vs-pagination-1030d29376f1

[jmcmurry]

I don't feel strongly about 'load more' versus infinite scrolling. Unless others object, let's leave it as is for now and prioritize the other improvements, thanks. Already sooo great to be able to see more than 50 results :)

[jmcmurry]

One last thing before we close this. I'm concerned about the behavior of the inactive facet when the active facet is changed. For instance, this makes it look like there are many Fanconi diseases in lots of different animals. There are a few such, but not diseases. I personally find it more intuitive when the counts are updated accordingly. Thoughts?

[jnguyenx]

Yep agreed, and the updated count should already be in the solr response.

[jmcmurry]

So this is a UI listener issue, Jeremy?

[jnguyenx]

Yes, and maybe query as well, it needs to ask for the facets.

…

On Mon, Feb 6, 2017 at 11:33 AM, Julie McMurry ***@***.***> wrote: So this is a UI listener issue, Jeremy? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/monarch-initiative/monarch-app/issues/1386#issuecomment-277787673>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEHMGHozLcZns5Y3k08eonIWGihnfkHaks5rZ3WbgaJpZM4KgdCF> .

[jmcmurry]

Should I assign this to you or to someone else?

[jnguyenx]

I can try to have a look when I'll have a bit of time :-)

…

On Mon, Feb 6, 2017 at 11:37 AM, Julie McMurry ***@***.***> wrote: Should I assign this to you or to someone else? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/monarch-initiative/monarch-app/issues/1386#issuecomment-277788705>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEHMGG8Wp1Php57jYcQQ2hjas20QT8tXks5rZ3Z1gaJpZM4KgdCF> .

[jnguyenx]

@jmcmurry I pushed to prod earlier this month, can you have a look?

[jmcmurry]

They look great; it is still a bit hobbled by the missing taxon issues which I've broken out separately here: https://github.com/monarch-initiative/monarch-app/issues/1448

This task: "On mouseover, highlight the active row and make any part of it clickable" had been checked "yes" however it isn't working for me, so I unchecked it. Could you please clarify?

[jmcmurry]

This is not yet fixed. Also, it is frustrating that the top result doesn't seem to forward to the clique leader. It goes to the Gene Reviews one? Then, once there, the hierarchy doesn't render.

[jmcmurry]

cc: @putmantime @DoctorBud