Some thoughts on the List UI after exploring a little today --

• Should we make it possible to add tools to an existing or new list from the tool card itself?
• Tool name suggestions in the “Create a new list” tool name field don’t appear until the entire name is typed out, and the spelling needs to be 100% correct. There’s no actual type-ahead functionality, i.e. showing possible matches as you write, and no fuzzy matching. Cf. Wikipedia search has both.
• To go to one of your lists to edit/delete it, you have to click on the "link" icon in the upper right corner. I think it'd be more intuitive from a UX perspective to have a wider action area, i.e. be able to click anywhere on the tool icon/list name/whole header section.

In T271386#7580574, @Slst2020 wrote:

Some thoughts on the List UI after exploring a little today --

• Should we make it possible to add tools to an existing or new list from the tool card itself?
• Tool name suggestions in the “Create a new list” tool name field don’t appear until the entire name is typed out, and the spelling needs to be 100% correct. There’s no actual type-ahead functionality, i.e. showing possible matches as you write, and no fuzzy matching. Cf. Wikipedia search has both.
• To go to one of your lists to edit/delete it, you have to click on the "link" icon in the upper right corner. I think it'd be more intuitive from a UX perspective to have a wider action area, i.e. be able to click anywhere on the tool icon/list name/whole header section.

• Replying to your first point, I can imagine a situation where this would be useful.
• Can you elaborate more on this? I'm interested in understanding your point. @bd808 can you weigh in on this too? right now we are approaching this problem through stemming but maybe we can do more?

In T271386#7580624, @Raymond_Ndibe wrote:

• Can you elaborate more on this? I'm interested in understanding your point. @bd808 can you weigh in on this too? right now we are approaching this problem through stemming but maybe we can do more?

I think that T295942: Add optimized Elasticsearch field mappings for autocomplete searches is basically talking about the same issue. There is a fancy new "search-as-you-type" feature for this in Elasticsearch 7.x which we do not currently have access to. The new feature however is really just some nice syntactic sugar for creating a custom field type that uses multiple N-gram tokenizers (one with shingle size 2 and another with shingle size 3). N-gram searches end up working a bit like a double wildcard search (*something*) but are more runtime performant at a cost of larger indexes.

I think that T295942: Add optimized Elasticsearch field mappings for autocomplete searches is basically talking about the same issue. There is a fancy new "search-as-you-type" feature for this in Elasticsearch 7.x which we do not currently have access to. The new feature however is really just some nice syntactic sugar for creating a custom field type that uses multiple N-gram tokenizers (one with shingle size 2 and another with shingle size 3). N-gram searches end up working a bit like a double wildcard search (*something*) but are more runtime performant at a cost of larger indexes.

If we can achieve this on our end, then we should definitely do it. Maybe I should pause the "autocomplete feature for the home page search bar" and work on this since it's kinda related

In T271386#7581027, @Raymond_Ndibe wrote:

I think that T295942: Add optimized Elasticsearch field mappings for autocomplete searches is basically talking about the same issue. There is a fancy new "search-as-you-type" feature for this in Elasticsearch 7.x which we do not currently have access to. The new feature however is really just some nice syntactic sugar for creating a custom field type that uses multiple N-gram tokenizers (one with shingle size 2 and another with shingle size 3). N-gram searches end up working a bit like a double wildcard search (*something*) but are more runtime performant at a cost of larger indexes.

If we can achieve this on our end, then we should definitely do it. Maybe I should pause the "autocomplete feature for the home page search bar" and work on this since it's kinda related

Or maybe not. This has a lower priority so I should work on the "autocomplete for home page search bar" feature first instead

In T271386#7581005, @bd808 wrote:

In T271386#7580624, @Raymond_Ndibe wrote:

• Can you elaborate more on this? I'm interested in understanding your point. @bd808 can you weigh in on this too? right now we are approaching this problem through stemming but maybe we can do more?

I think that T295942: Add optimized Elasticsearch field mappings for autocomplete searches is basically talking about the same issue. There is a fancy new "search-as-you-type" feature for this in Elasticsearch 7.x which we do not currently have access to. The new feature however is really just some nice syntactic sugar for creating a custom field type that uses multiple N-gram tokenizers (one with shingle size 2 and another with shingle size 3). N-gram searches end up working a bit like a double wildcard search (*something*) but are more runtime performant at a cost of larger indexes.

What is the advantage here of using Elasticsearch vs. Vuetify's v-autocomplete? (Example Codepen). Do we need advanced full-text search for finding the closest matches in an array of 1-2k tool names?

In T271386#7582339, @Slst2020 wrote:

What is the advantage here of using Elasticsearch vs. Vuetify's v-autocomplete? (Example Codepen). Do we need advanced full-text search for finding the closest matches in an array of 1-2k tool names?

I suppose primarily that we do not have to fetch a list of all tools in the backend database to the browser to populate a v-autocomplete when the component is mounted. We are also currently searching in the toolinfo description as well as the name to produce possible matches. This is being done as we are not at all confident that the "name" value of a toolinfo record and the name that users actually know the tool by are the same.

In T271386#7580574, @Slst2020 wrote:

• Tool name suggestions in the “Create a new list” tool name field don’t appear until the entire name is typed out, and the spelling needs to be 100% correct. There’s no actual type-ahead functionality, i.e. showing possible matches as you write, and no fuzzy matching. Cf. Wikipedia search has both.

You are correct that it does not currently have "fuzzy" matching (see T271386#7581005 and T295942), but it does search on data entry and also match without being exact. The current difficulty is that the search terms and backend index are word tokenized, so you need to type in something that has been tokenized as a word to start finding matches. An example from the demo server of "media" as input:

In T271386#7583310, @bd808 wrote:

I suppose primarily that we do not have to fetch a list of all tools in the backend database to the browser to populate a v-autocomplete when the component is mounted. We are also currently searching in the toolinfo description as well as the name to produce possible matches. This is being done as we are not at all confident that the "name" value of a toolinfo record and the name that users actually know the tool by are the same.

That makes a lot of sense.

In T271386#7583310, @bd808 wrote:

You are correct that it does not currently have "fuzzy" matching (see T271386#7581005 and T295942), but it does search on data entry and also match without being exact. The current difficulty is that the search terms and backend index are word tokenized, so you need to type in something that has been tokenized as a word to start finding matches. An example from the demo server of "media" as input:

Ok, I see. All the examples I tried with had the misfortune of being "unstemmable" -- like "pywikibot", which you need to type out in its entirety before getting any suggestions. I expected there to be suggestions after typing out the first 2-3 letters, but now I understand why this wasn't the case.