Feedback form - Ray Stefancsik - Hi team, I would like to draw attention to a usability bu...

[monarch-issues-tracker]

Name
Ray Stefancsik

Email
[email protected]

GitHub Username
@rays22

Details
Page: /feedback
Browser: Firefox 126.0
Device: Apple Macintosh
OS: Mac OS 10.15
Engine: Gecko 126.0

Hi team,
I would like to draw attention to a usability bug.
When I try to enter any text in the filter box, for example, here
https://monarchinitiative.org/HP:0006501?associations=biolink:GeneToPhenotypicFeatureAssociation
I can enter only one character, then the focus on the filter box is lost, and I need to click and select inside the box againg with my mouse if I want to continue and complete the input text.
This makes finding relevant lines in the table very cumbersome and frustrating.

Thank you in advance.

[rays22]

I have been able to reproduce the problematic text input behaviour in Firefox, Chrome, Safari and Vivaldi browsers.

[sagehrke]

Hi @rays22,
Thank you for submitting this help desk ticket! I am going to move this to our Monarch-app repo so that the technical team can add this bug to their to-do list.

All the best,
Sarah

👀 @kevinschaper @glass-ships @amc-corey-cox

[rays22]

Thanks @sagehrke !

I would like to add another problem with the search box. Partial matches do not seem to work. You need to enter a complete matching string to get any results. For example, "TNN" does not match any lines, although there are lines that should match TNN*.

[glass-ships]

Thanks for the issue, @rays22.
(CC @kevinschaper and @amc-corey-cox in case they have additional thoughts or input)

Regarding the click and type issue:

This happens because when a new search is entered, or really if any of the following occurs:

• a new category is selected
• the traverse orthologs button is checked/unchecked
• the per page number is changed
• the page itself is changed

A new query must be made, and the Association table must re-render, including the text box,
which therefore makes the text box lose focus.

You technically can type multiple characters before this happens, but the time between keystrokes has to be less than 500ms.

The best solution I can think of to implement for now is to increase that debounce time, maybe to something like 900ms, to allow the user extra time to type before having to click in again.*

It's possible that there is a more elegant way to handle this, perhaps with the use of a third party libraries (see #147) but this would require significant research, and unfortunately we're not likely to get around to this in the super-near future.

* Let me know of this solution seems acceptable for the time being.

Regarding partial matches, I'll have to look into this a bit further, will update when I have more info.

[kevinschaper]

partial matching would be controlled by adding fields suffixed with _ac to association_search_query_fields()

probably we’d want subject_label_ac and object_label_ac (but we maybe wouldn’t want starts-with matching on all entities in the closure, at least not without also adding some kind of text highlighting to know why rows are being matched against).

We’ll also need to populate those _ac fields on the monarch ingest side. We’ll have to add an additional copy fields stanza to add_association_copyfields.sh

Maybe include taxon and qualifier labels on the assumption they’ll be shown in the table?

for field in subject_label subject_taxon_label object_label object_taxon_label qualifiers_label onset_qualifier_label frequency_qualifier_label sex_qualifier_label
do
  curl -X POST -H 'Content-type:application/json' --data-binary "{
  \"add-copy-field\": {
      \"source\":\"$field\",
      \"dest\": \"${field}_ac\"
  }
}" http://localhost:8983/solr/association/schema
done

predicate wouldn’t work here, since it starts with biolink:, we’d need a tokenized starts-with matching field type for that.

[kevinschaper]

@glass-ships We could trigger the search with a button rather than having it act like a live search, if nothing else as a short term solution until we can figure out how to keep focus in the box while other elements get re-rendered.

[glass-ships]

@kevinschaper I'm not really sure that would work, actually, because of how the AppTextbox component is written (see AppTable.vue Line 171 and components/AppTextbox) - at least not without overhauling some of that functionality.
(As written, it displayed a non-interactive icon when the text is empty, and a clear button if it's not)

[glass-ships]

@vincerubinetti (sorry to drag you into this, feel free to ignore / comment as you're willing and able)
would you by any chance have some input on how we might approach this?

[vincerubinetti]

I'm out of office at the moment. I don't remember exactly how I wrote these particular components at the moment. But I think there may be a @change event in the text box component you could use to trigger the search in the case of the table component, instead of the debouced event. That should trigger on blur or enter press, and you could modify the component such that the magnifying glass icon in the text box is a button (with an accented color to indicate clickability) that will also explicitly trigger the change event as well.

I can comment more next week.

[vincerubinetti]

I also remember encountering this bug a while ago and fixing it in some manner. Might be worth looking through the git blame for the textbox/table/associationstable components to see if anything was overwritten during merge conflict or something.