Means of browsing all snaps in a section


#1

The store uses sections to categorise snaps. We have an API in snapd (e.g. /v2/find?section=<section name>) to return snaps in sections. I expected this to return all snaps in that section, but now I believe it only returns snaps that have a featured-within-category database flag set - a subset of the snaps in that category.

It’s been previously discussed that we should have a means to browse though the categories, i.e. to look at what games are available. To do this we’ll need some new API that allows all snaps in a section to be returned. As this could be potentially very large we’d probably need a means of limiting the data returned. For example by returning only snap names or using pagination.

GNOME Software specifically has UI for this mode of browsing that we’d like to make work with snaps.

We need to decide:

  • What means of browsing we want to support.
  • What API needs adding to the store.
  • What API needs adding to snapd.
  • Implement this feature into GNOME Software / Snap Store.

#2

An example snap given by @cprov is mmapper which is in the games section but not returned from snapd:

$ curl --unix-socket /run/snapd.socket 'http://localhost/v2/find?section=games' | jq .

Doesn’t show it.

$ curl --unix-socket /run/snapd.socket 'http://localhost/v2/find?section=games&name=mmapper' | jq .

Does.


#3

Browsing snaps was explicitly excluded from the original snap (CLI) UX, which, in basic terms, goes:

  1. snap find: globally featured snaps (in the featured section)
  2. snap find --section=games: snaps featured within the games section
  3. snap find --section=games board: snaps in the games section matching board

Thus the lack of API support for browsing and pagination.

The flow described above (search-based) is supposed to be more direct and simpler to users who know what they are looking for, but will defer to @pheurton for a wider rationale considering the whole snap UX (CLI, Storefront and now GS).

Technically speaking, there are no blockers for supporting browsing using the current APIs, but I suspect once it’s allowed we will also have to support sub-categories (e.g. games -> board), at least one level, to make browsing less tedious.


#4

There are two very distinct ways in which we want snaps to publish and install snaps from our interfaces:

  • CLI: We should provide the most relevant (aka featured) Snaps from a given category and avoid cluttering the output as it can become cumbersome to digest and analyse listing all snaps from a category.

  • Storefront / GS: To showcase the breadth and variety of the Snap Store users will be able to browse all snaps from the different categories. We might choose to display the featured snaps differently on the Store front page of the different store interfaces as we do right now, but also we would need to provide a way to paginate through the whole category and allow users to navigate the complete store.

Obviously this approach has some challenges has it can end up surfacing many snaps with no specific metadata, not relevant for the category, snaps on the wrong category and it can connect with the work we are doing for better ranking of search results. To communicate the importance of making the right choice to categore your snap in the UI will help in this front.

In regards to sub-categories, we are planning to give publishers the ability to include (optionally) a second category to include their snaps within. This might help prevent the need for sub-categories. Also, if we provide meaningful categories, we will also contribute to avoid the need for further categorization within a first-level category.

Thoughts?