Comment on the React/UIkit gene search demo here

[sammyjava]

Adding a to-do checklist here for items brought up in the comments below:

http://lupini.lis.ncgr.org:50030/

• [x] ADF fix the limit of 10 on strain selector (bug)
• [x] ADF drop the Name search, not enough distinct content to warrant (otherwise identifier search works fine)
• [ ] ADF multi-select on selectors -- currently out of scope but queued here
• [ ] ADF multiple CONTAINS in text search fields -- currently out of scope but queued here
• [x] ADF enlarge description field
• [x] ADF/SC different examples: L_HZ6G4Z, Glyma.13G357700, protein disulfide isomerase-like protein
• [x] SC make gene family identifier search CONTAINS, not equals
• [ ] implement specified behavior re. old results display when filters are changed

[adf-ncgr]

It seems good and very performant. I found myself wishing that the dropdown for accession (and maybe those for species and genus too) would allow multi-selection, but our older search didn't support that so could be deferred as an enhancement for later. But it does look like the set of things in the dropdown is limited to 10, which is a problem for accession lists for some species or genera (e.g. how can I get Williams82?)

I would personally vote to suppress the Name field search for now until we have better support for it in the data, so as not to disappoint users who expect to be able to find matches for interesting symbols from anything other than glyma.Hwangkeum.gnm1.ann1; unless we just want to give a boring example like Glyma.01G000200 which would work in either Name or Identifier but won't get anyone's hopes up.

The amount of real estate given to "description" search field seems a little cramped. I also found myself wanting to put multiple terms in and having them searched as CONTAINS this AND CONTAINS that rather than CONTAINS "this that".

I think the only thing in this comment I'd consider a must-have is the full listing of accessions, which I imagine is just a page size on the query that populates them and easy to fix? The rest is for the hill I won't die on. I'd rather get something functional out into production sooner than address any of the other nit-picks.

[adf-ncgr]

PS. This is admittedly fussy but may I suggest different examples? In particular, I think having a gene family that yields results for most species would be good, legfed_v1_0.L_HZ6G4Z seems to be a nice one in that regard. I'd also pick an identifier from a genome most users will be familiar with, like Glyma.01G000200 or Medtr2g093500.

[adf-ncgr]

one other minor UX type thing: the clearing of the results when the search is changed is probably a good thing, but I was initially unclear as to whether it was auto-submitting and my new choice had no results. I don't think we should auto re-submit, but maybe a little note in the cleared results area to the effect of "search cleared: hit return or click button to resubmit with updated filters" wouldn't be amiss.

[StevenCannon-USDA]

I also very much like this. And I'll second adf's request to tweak the examples. Other nice candidates for the gene families: legfed_v1_0.L_2951WH legfed_v1_0.L_4RYTMP

(If it is possible to return results for the family minus namespace, e.g. L_2951WH, all the better.)

For the Name vs. Identifier fields: it is rare (one annotation set for G. max?) that the name is not a substring of the identifier. I think it would be good to add a more typical example under both search fields: e.g. GmHk_U059486 or Glyma.01G001000 e.g. IMPA4_4 or Glyma.01G001000

[alancleary]

All of my feedback is related to UIkit and can be addressed during Web Component implementation. I'll only make one note because Andrew brought it up:

one other minor UX type thing: the clearing of the results when the search is changed is probably a good thing, but I was initially unclear as to whether it was auto-submitting and my new choice had no results. I don't think we should auto re-submit, but maybe a little note in the cleared results area to the effect of "search cleared: hit return or click button to resubmit with updated filters" wouldn't be amiss.

This behavior should be consistent across the site. Currently the other web components don't clear their search results even when you initiate a new search, i.e. they wait until there's new search results. Other than requiring this behavior to be consistent, I don't have strong opinions on when search results are actually cleared; the existing behavior I described is just how I happened to implement it and no one complained so that's how it is.

[sammyjava]

This behavior should be consistent across the site. Currently the other web components don't clear their search results even when you initiate a new search, i.e. they wait until there's new search results. Other than requiring this behavior to be consistent, I don't have strong opinions on when search results are actually cleared; the existing behavior I described is just how I happened to implement it and no one complained so that's how it is.

We should spec this behavior. The reason I clear the results is that if you change a selector, you see a filter that is inconsistent with the viewed results. Because the button generates results.

We could also have it populate results on the fly. The form starts with the top 10 genes alphabetically, and as you hit selectors or submit text it changes. But that's a lot of overhead.

I don't like having search results that don't match what is in the form. Another way of looking at it is I don't like the possibility of being able to take a nonsensical screen grab.

[sammyjava]

OK I've hit the requests that are hittable. I'm calling "out of scope" the more complex search form behavior that ADF mentioned. We have a new task of specifying what happens to previous search results when we change the search form's parameters, so we apply it across the whole site. I don't care what it is, but it should be specified intentionally, not simply left at what we happened to do in some prototypes. I'll make a new issue for that since it's larger than this specific form.

[sammyjava]

So we keep moving, add more change requests OR sign off on the current version. Once I have signoff I'll work on the web-component implementation.

• [x] @adf-ncgr
• [x] @cann0010
• [x] @alancleary

[sammyjava]

Closing this issue since the React demo is history at this point.