Tags, categories and keywords - search feature is inefficient

[PascalLadalle]

I feel like I'm having more and more trouble finding what I'm looking for in GDevelop, and I'm supposed to be an experienced user. The search fields, be they for events or examples, return too much noise.

Here, for instance, I want a mouse action, but can't remember the name, so I write "mouse". The cursor action I'm looking for appears below the unrelated force actions. I suppose it's because of "MOvement USing forcEs", but what's the point of that? How comes such a far-fetched match comes before a full word category match? And I can't use quotes in that field for a strict search, to filter the noise out.

Now, in the Examples section. I'm looking for an example with dragging. The first result that actually contains my keyword is, as you see with the scrollbar, near the end of the results (about 15th position). I suppose that all the results before that one use the draggable behavior and have been tagged as such, but I think the search result priority should be: title > description > invisible tags. On a side note, this search didn't return the example I was looking for, because it's called "Move object with mouse joint". 😅

I hope you can do something about it. 😃

[Silver-Streak]

The most recent update definitely did something with the examples search.

It feels like the search logic got hampered somehow. Searching for an example by partial name now feels impossible, its like its going Tag > exact name search only, whereas most search engines go Exact Match > Partial Match > Metadata (tags/description/etc)

I know the layout change was intentional, was the search result change intentional? It definitely seems much less accurate than before.

[AlexandreSi]

Thank you for taking the time to report this! I felt like there was something off with the search.

We didn't change the logic for the search, only the UI/UX. I think your suggestion of having Exact Match > Partial Match > Metadata should be the way. Maybe even: Exact Match in Title > Exact Match in Description > Partial Match in Title > Partial Match in Description > Metadata

[4ian]

I think there are two things here:

• First a "placebo effect" on the search itself - because the logic was unchanged. I think you have the impression that it's less effective because the search is not updated anymore on each keystroke (contrary to the old search and the asset store search for example).
  • @AlexandreSi I reckon we should ensure the search is done at each change in the search bar, so that we don't have to press enter.
• Even with this change (going back to filtering the results at each key stroke), I think we could indeed see if we can push forward the results that are an exact match.

Internally, there are two logics going on according to where you are in the interface:

• actions/conditions/expressions are doing a fuzzy search (but should prefer exact matches).
• asset store, extensions, etc... are doing a search using prefixes.

[AlexandreSi]

I'll have a look for this search on each key stroke but it was slow on my side with a good computer and a good connection. Any feedback on the speed of the search?

Here, "slow" applies to both fetching results, and displaying the letter corresponding to the key I just typed.

[4ian]

Ok that's a bit strange because we're supposed to use js-worker-search so that the search is done in the background (https://github.com/bvaughn/js-worker-search) for extensions. Note that this is all done client side: the whole list of extensions is fetched once and there is no network request done after that :)

This might be the rendering of the list that is slow BUT that's also why we use a virtualized list.

[Silver-Streak]

@4ian Are we sure nothing changed on the search logic? This used to pull "not-a-vania" up as the first result.

Now on some resolutions it's not even on the first page, but for me it is the last result

But yeah, even if nothing has changed and this is an odd outlier, it should really be Exact match for word in title as a first priority. Right now it seems to be partial matches in descriptions/titles over exact matches (my best guess is that the first result is showing up because "not" is in "another"), which seems unoptimized compared to other search engines.

[4ian]

I'm pretty sure we did not change anything, just removed the filter, moved them to autocompletions in the search bar, but the search itself was not touched 🤔 (see the same searchItems={filteredSearchResults} in https://github.com/4ian/GDevelop/commit/365bc56940bb2e6c2c083f7c3079a02476088cc8#diff-e5882e5853a99845e2fd9b666b5cf62c90db9688b253b2f409ff4be9e07406e7R84)

Anyway I agree it's not great, let's see if we can tweak or instruct the search engine to move up things that are exactly a match or give more importance to the titles.

[AlexandreSi]

@PascalLadalle @Silver-Streak have you had the time to try out the new search in the example and extension stores? I would like to implement it in the action/condition search, I'm looking for feedbacks

[PascalLadalle]

Much better, and I love the highlighting. 👏 But full word match should have priority over partial match. IMO, even a full match in description should have priority over partial match in title.

But maybe it's an edge case, I haven't noticed it with other keywords.

On a side note, I clicked on the search box, and saw the list of available filters, I typed in "audio" because I saw it in the list, and the search returned 0 results while selecting the Audio filter returns plenty. I found it confusing, so perhaps we should make it more explicit that the filters are for features, and not just popular keywords... 🤔 Like instead of "Apply a filter", it could be... "Filter by used features" or "Select a feature to filter the results".

[AlexandreSi]

Great thank you for the feedback!

The engine behind that is Fuse.js. Regarding the priorization, we do not really have control on it, fuse.js computes a score for each result using Levenshtein distance that does not really express if there's an exact match. Adding more computation on the search results might slower the search.

Regarding the Audio filter, I'll have a look, it seems weird, thanks for noticing that.

[AlexandreSi]

I didn't add the search on each key stroke in the stores because I feel like having changes in both the dropdown and the list of examples/extensions might be a bit disturbing