Search UI: Deactivate elements that are not of use (and other things to help the user)

[sveinugu]

There are currently many elements in the search panel and I think it is easy to get lost, especially for new users. A very simple way to make the interface more intuitive would be to dynamically deactivate elements when they are not usable, so that the user knows where to look. By deactivating, I mean giving a greyed out look and having no usability, such as with some of the buttons today. Also, add warnings/errors before the user does something that will not work.

Suggested logic:

• By default, only the left-hand side browser (with filtering options) should be active
• The "add to query" button should only be active If a value is selected in the left-hand browser
• All elements in the middle column should be inactive if there is no text in the search query text bow, including the headers. The only exception to this rule is that the text box itself should always be active so that it is possible to paste (or write) text in it. Deactivating the header ("Search query") should be enough to bring focus to the left-hand model browser, where the action is.
• Make sure that clicking "Clear all" deactivates all the element in the middle column (except the text box), a consequence of the above rule.
• The result browser and export buttons should only be active if there are results shown
• If the search query is changed after a search has been done, I think the results box should have a warning (like if you type letters in the "Limit" box) with a tooltip saying that "the search query has changed since these results were generated, and a new search might give different results", or something to that effect. This so that "clear all", or changing the search query do not remove the results (as it might have been a mistake), while it is clear when those two do not add up.
• "Filter values" and "Limit" should have a checkbox to the left of the titles, showing whether the functionality is active or not. This is in order to make the user aware of the choices. For "Limit", the default is 10, which I think is useful, but only if the user is aware of that. If not, the user might think he always gets 10 results. A checkbox draws just enough attention to the box, I think.
• If such a checkbox is unchecked, the text box should be deactivated. To activate and provide a value is then two clicks. I think this is a very small price to pay for a more intuitive interface
• The checkboxes should not have any dynamics depending on the contents of the text box. Meaning that it is perfectly possible to end up with a checkbox and an empty field. However, such a case should give a warning, similar to the one that appears when writing letters in the "Limit" box
• The "Categories" selection should also have such a checkbox to the left of the title (inside the title box, I think that will work visually). By default this is unchecked, and the category selection list is deactivated. Checking it obviously activates the category selections.
• If the "Categories" checkbox is checked, but no categories selected, there should be a warning, and the search button should be greyed, as when adding a letter to the "Limit" box.
• I am unsure whether all categories should be checked by default or not. I think perhaps the best choice would actually be that only the FAIRtracks categories are checked, so that the same solution could be used as a quick way to only return those (i.e. by just clicking the header checkbox, without having to select each one manually). If the default is no categories, then the warning from the above point will appear when activating the category list. If the default is all categories, one would typically need to click a lot to get the (I think) most common choice, which is just a single category. Only the FAIRtracks categories is at least i better.
• Even though this is for advanced users, there should be some logic checking the references. If not all categories are included in the same reference "clique", I think the "categories" checkbox should be checked by default. Furthermore, if the set of selected categories (by default FAIRtracks) are still not in the same clique, there should be a warning that disappears only when a correct set of categories are selected. In this way, if only the FAIRtracks categories are linked, but not the rest (a likely scenario), the default choice would work.
• An additional check for the categories box is that if the search query contains attributes from a category that is not selected, there should be a warning in the category selection box (with specific info on which categories are missing). Currently, there will be no results, but no indication on what is wrong.

Some text improvements:

• "Model browser" is not a good title. What about "Select metadata value(s)"?
• "Categories" -> "Filter categories to search in"
• "Limit" -> "Max. number of results"
• "Clear all" -> "Clear search query"
• "Export (XX) entries as..." -> "Export results (10 items) as..."
• Improve the naming of the result files, for instance TF-Blueprint-2020-01-25T23-49-09Z-152x.gsuite. Format: TF-(hub)-(date in iso-8601)-(#results)x.(suffix)

[dtitov]

Some text improvements:

All items from this section are fixed in ac290fb.

However, regarding the first list, I think we should have a meeting, because I don't completely agree with all the items there (as well as with some items in #111, #112 and #113). Might be worth inviting some potential users (Geir Kjetil? Ankush?).

[sveinugu]

Sure, I did not expect all of these to be accepted without process. In my experience, users without ui design experience are often not very good at the idea stage but more useful when one can observe their use patterns and receive complaints. @sandve would be a natural choice for such a meeting, though, if he has time.

[sandve]

I could provide some input. I would have preferred to test it out in a real analytical scenario, though, as I am a bit skeptical to hypothetical use cases (in my experience, what becomes natural/intuitive when I have real use case may be quite different from what appears reasonable when I just try out a tool without a purpose). Will you be presenting TrackFind e.g. at a Tuesday meeting soon? It could perhaps be tried out for the hGSuite analysis that Sumana and Diana are currently doing or something..

[dtitov]

Will you be presenting TrackFind e.g. at a Tuesday meeting soon?

We could, I guess... However, we will have to finalize a couple of things here and there first.