Possible QB improvements?

[yochannah]

Following some user testing (experienced biologist, new to InterMine) on the query builder, a few thoughts:

1. Can we make filters more obvious? While testing, one user comfortably added gene name to the QB but couldn't figure out how to enter which gene they wanted to see.
2. The user built a sane query but searched for a gene symbol under the gene name field. This prompts two thoughts:
   • Should we default to lookup rather than = for filters? It would be easier for naive users, but what other implications are there?
   • An advanced typeahead facility could tell you info about the id you've just type - e.g. "this is a uniprot identifier" or "this is a protein" or so on. This is slightly different from the search simple because it's inline in a QB and therefore needs to be more domain specific - returning a publication in a typeahead for a gene might not make sense, but returning a symbol in a primary gene id field would make sense.
3. The examples worked really nicely to give the user an idea of how to use the QB (excepting perhaps the filters...)

[yochannah]

Further thoughts:

• why does one need to click the pen icon for Constraint Logic? i.e. why can't one just edit it?

• took me a while to figure that if I wanted to add Twi to Zen and Mad that clicking on the filter icon was the right way to do it.

• managed to add protein mass and filter to exclude <50,000 but this reminded me it might be nice to have text search over the model e.g. typing (ideally with type-ahead) "weight" would move to/ highlight-with-context matching parts of the model. I suppose this means that in place of the single Model Browser one might need a way of showing multiple classes opened at the appropriate location(s). Or maybe a class pick list.

• column order tab great

• Gene -> Symbol type-ahead "Too many value to show": is this just a temporary thing?

• the preview of the query is nice and could be very useful in building up queries. I wonder whether there ought to be some auto-column summarisation. This would allow one to iteratively build up a query and then when reasonably constrained show all the rows, rather than going forwards and backwards to the results table. I suppose this almost brings one to the point where the querybuilder and the results table are the same thing. However I suppose really is better to have a clear separation between a building phase and a doing-other-things phase (enrichment, list-making, export etc). Having said that, maybe it would be logical for "Add Columns" on the results table page to go back to the QueryBuilder page? That could reduce code duplication...

• If I do go to the results table, add a filter to a column and then return to QB (by clicking in the top grey bar), the query doesn't reflect the added filter. I think it should...

• (When I added the column filter above, the only way out after applying was "cancel"

  • maybe once you've "applied", "cancel" should become "done"?

[heralden]

Adding another point to this list of improvements: (discovered during usertesting)

• It is not obvious that the Gene class has been preselected for the model browser, as the user jumped into query building without knowing they were building off of the gene class. We can make this process more explicit by replacing the Model Browser with a root class selector (preferably allowing you to filter the dropdown/list of classes with a text input). The selection should be remembered throughout the session when returning back to the page.