Search results faceting strategy

[jmcmurry]

This is a high-level ticket meant to spark some discussion (online and off) on longer range goals for results faceting. (It also tangential implications for ontology browsing widgets more broadly.) As the number and complexity of imported datasets grows, and as we begin to combine and render them in new ways (tables, barcharts, graphs, single-page app), it would benefit from a general solution to faceting. Aspects of the Amigo facet widget make it a little too onerous to customize, so it is my understanding that we have put it aside at least for now.

• [ ] Decide on which pages need faceting
  • /search? The number of results is currently capped at 79 and results are fairly exact matches, perhaps overly so. Consequently, as implemented, faceting isn't a pressing need, but if we rethink search, and I think we should, faceting could play a larger role
  • phenogrid
  • uber search / neighborhood (as yet not implemented)
• [ ] Where combinatorial searching doesn't matter (either [any of A B or C] or [just c]) consider either:
  • Go immediately to results (as done in amazon, below)
  • Expand to subgroup options (as done in eagle-i, below)

--	Amazon	Eagle-i
Advantages	Visually cleaner, fewer column width issues with multiple levels of hierarchy	Easier to understand tree structure (I say theoretically because there's so much text that the hierarchy concept gets a little lost)
screenshot		etc. etc. etc. (73 rows worth)

In the eagle-i approach, and the checkbox approach, if a given category has a small number of items (<10?), it may not help to expose the subcategories as all ten results would fit on a single page. In eagle-i I remember that it was a pain point to determine the right level of granularity of categories to display; still now there are 73 categories under instrument alone and how these categories relate to each other is not clear to me. My personal preference is not to display too many categories at any one time; maybe the enough results so that say 80% are in a listed category. After which, I strongly support the "see more" approach taken by Amazon above. The "see more" or "see other" or "expand all categories" approach could also be useful in cases where there are lots of granular categories, each with only a couple of items.

Please this	Not this

• [ ] There are cases where combinatorial searching really matters (A and B but NOT C) In such cases, implement using checkboxes and groups. eg:

  

This would require the SciGraph 'OR' query (https://github.com/monarch-initiative/monarch-app/issues/723) to be implemented.

How to expose the appropriate levels of hierarchy is a separate but related question.

[mellybelly]

@harryhoch does @cborromeo have time to work on this? @jmcmurry suggests there are many related search tickets (see tag), can we define scope for what is next up?

[harryhoch]

@mellybelly yes. @cborromeo is looking at search/autocomplete right now, where this is directly relevant. Similar concepts might also apply to revisions to the data tables. A bit of help/guidance from those more familiar with the indexing and autocomplete code might be needed. Let's talk on Monday.