Add number of search-results to category dropdown

[madsrh]

• Add the number of search results for each category in the right side of the dropdown
• Change the color of categories with no results to gray / deactivated

[Feichtmeier]

I fear this is not possible without decreasing performance. You can search with given category or none. This would require one search for each category (21) for each letter you type. This will def. decrease performance. I am not sure if this is worth it 🤔

[Feichtmeier]

What we can do out of the box, is to display the number for search results in the dropdown button

[madsrh]

I fear this is not possible without decreasing performance.

Makes sense

This would require one search for each category (21) for each letter you type.

Well, there's no need to update it as the user is typing. You can't type and click the dropdown at the same time, so there's a delay from when the user stops typing and then opens the dropdown. The "closed" dropdown should not list the number of results, only when opened.

Would this still be a too demanding task to do?

[Feichtmeier]

It is not about demanding but to not reduce performance by no essential UI features

Easy and no performance loss because the search is done anyway and the model only needs to count the result: show amount of results in the dropdown header (ignore if the text fits or not, this can be changed):

Hard: re-do the whole search for 20 categories when the user opens the popup. Two options:

• make it sync call which will be see-able as lagging UI
• make it async: the user search results "drop in" while the popup is opened

both options do not seem good to me. Also it makes no sense from the UI workflow

1. you select a filter, or you dont't and go with the default (all)
2. you get a result which has a number
3. this number fits to the query you did, including the category

If you selected a filter, why would you open the popup again to see how many results the other categories have? 😆

[madsrh]

Having the number 👇 of results shown here isn't useful at all. I am only asking about the open popup/dropdown

I see your point and perhaps it's a rare usecase, but what I find frustrating is that if I've (doing a list like you):

1. Selected All Categories
2. Typed Gnome in the search
3. Too many results, I'll open the popup
4. Now I can't tell which categories actually contain a search result or if they are empty
5. I have to click through each category

I would love to have empty categories grayed out, even if it's async. But I totally see your point and maybe that is not how people do their searches.

If you selected a filter, why would you open the popup again to see how many results the other categories have?

LOL, that would only be me 🤣

And thanks for the patience 😇

[Feichtmeier]

Another problem: the categories only affect snaps
Packagekit.dart currently does not support to search by PackagekitGroup
If this would happen some day, we would also need to map the SnapSections to the PackageKitGroup (with overlap)

We can keep this open but this won't happen any time soon

[Feichtmeier]

Depends on https://github.com/ubuntu-flutter-community/software/issues/560

[madsrh]

We can keep this open...

Let's not 😊 thanks for answering all the questions

[Feichtmeier]

Ok! :)
NP, it was from the start obvious to me that making a store against two packends/APIs is a challenge. I guess this is one reason why gnome-software struggles so much. Imagine we would add more packageformats.....

[anasereijo]

I proposed the same thing as @madsrh here. I also believe it would be helpful for the user to know how many results they can find on each category.

Displaying the items that have no results (with the zero and greyed out) it is a good usability practice — provides a first level of feedback and prevents the user wondering what happened to the other categories. Always better to display instead of hiding choices.

[anasereijo]

@madsrh I really like the use of icons on the dropdown 👌
I would just change the text from 'Search all' to 'All categories'.

[Feichtmeier]

@anasereijo this screenshot is outdated

it now says "All snap categories"

classic packages/debian packages do not follow those categories for snaps. As written some comments up https://github.com/ubuntu-flutter-community/software/issues/560

As always I must be the performance police 👮‍♂️
Getting this information for all 20+ categories for every letter you search is really heavy
The search searches for snaps with given name in either all snaps or in snaps with selected category.
To implement this idea we would need to send either 20+ requests successively or in parallel. In parrallel would mean the whole screen hangs/loading screen until you searched all categories. successively would need the numbers in this popup to change while the results drop in. another option would be to only add the last search to the numbers

[Lukewh]

Snaps: when you search on the snap store, you can request fields, such as category – is it not possible to calculate the number of packages in each category on the frontend based on this field, no additional requests needed? Also for the snap store, we can file a ticket to ask that the response returns category counts. It might not happen immediately, but it keeps this open for the future.

Debs: It's true we need to map the snap category → group, but we have that already @robert-ancell should be able to help there.

Edit: Just seen your linked issue to the mapping :)

[Feichtmeier]

Snaps: when you search on the snap store, you can request fields, such as category – is it not possible to calculate the number of packages in each category on the frontend based on this field, no additional requests needed? Also for the snap store, we can file a ticket to ask that the response returns category counts. It might not happen immediately, but it keeps this open for the future.

Debs: It's true we need to map the snap category → group, but we have that already @robert-ancell should be able to help there.

Edit: Just seen your linked issue to the mapping :)

Yes, we use the category feature already. But it just returns a list of snaps.
The count response would be great and would totally solve this issue without any additional frontend computing which will reduce performance

[Lukewh]

Launchpad issue for tracking: https://bugs.launchpad.net/snapstore-server/+bug/1998482