search

YunoHost / issues

General issue tracker for the YunoHost project
71 stars 8 forks source link

Application categories : specification draft ? #1322

Closed alexAubin closed 4 years ago

alexAubin commented 5 years ago

Soooo after thinking so many times about the whole application category thing, randomly decided to give it a try for real because yolo.

The need and motivation for application categories comes from the fact that we now have many many applications and you ain't gonna spend time reading the description of the ~100 workings apps or 250+ apps if you include inprogress/notworking to find what you're looking for ... Instead, having application categories would allow to filter application according specific need / interest and might allow people to discover applications they would not have realize existed... Even for us contributors of the project, I believe it's difficult to keep track of what app does what and how use-cases / needs are covered or not by the current app catalog.

There are three main things to design

List of categories

Sooo here is an attempt. I tried to keep the number of categories to something like ~15 while covering most of the existing apps, and trying to make it so that apps fit in a single category (or sometime two if there's really ambiguity, no big deal).

I came up with the following (order doesn't really matter) :

Of course this is still to be discussed :wink: I tried to apply those categories to existing apps in official and community json to see how it goes. This is very drafty as I didn't took to think a lot about each of the 250+ apps. Some stuff I noticed and still thinking about is that : "Contacts & Calendar" and "News / RSS reader" are pretty small, dunno if that's a concern or not. Also I was not able to find a suitable category for some apps which are quite specific projects (Coin, wifiwithme, Dynette, Duniter, or tools like Searx ...)

We could also go for a much larger number of categories, e.g. having categories "Forum", "Wiki", "Password manager", etc... But the idea of sticking to just 15~20 categories is to not overwhelm the user with so many category choices.

Implementation

For the implementation, I propose that the app categories should be managed at the list-level. This gives us more control and flexibility on the long run if we want those to evolve (in comparison to, say, adding categories to the app manifest, which implies to change all manifests if we ever want to refactorize categories later, and imply to trust packagers with what category they declare).

One app can be in multiple categories (though c.f. previous discussion, I think should be in max. 2 categories but no need to put any hard limit on this) ... It's not clear to me if we should allow an app to be in no category tho, but that's a detail.

So, in practice, one would add a list of categories via the new categories key. E.g. let's say Nextcloud falls into the "File storage and sharing" and "Contacts & calendar" category : 

    "nextcloud": {
        "branch": "master",
        "categories": ["files", "contacts_and_calendar"],
        "level": 7,
        "revision": "HEAD",
        "state": "validated",
        "url": "https://github.com/YunoHost-apps/nextcloud_ynh"
    },

So that mean we have to keep somewhere a list of the known / allowed category IDs... And their corresponding human-readable translation. I guess we can do something similar than for levels description and store this in the apps repo, somewhere like app_categories/en.json

So for instance : 

{
    "files": "File storage and sharing",
    "contacts_and_calendar": "Contacts & calendar",
    "email_and_messaging": "Email & IM",
    "personal_tools": "Personal tools",
    "collective_organization": "Collective organization",
    "news_and_rss": "News & RSS readers",
    "social_media": "Social medias",
    "cms_and_websites": "CMS & Websites",
    "multimedia": "Multimedia",
    "email": "Email",
    "iot": "Internet of Things",
    "games": "Games",
    "small_utilities": "Small utilities",
    "dev_tools": "Development tools",
    "system_tools": "System tools",
    "other_technical_tools": "Other technical tools"
}

Still not sure to know how to properly propagate this info up to yunohost and the webadmin ... but that's sort of a detail and we can figure out something later

Integration in the webadmin

When browsing the installable apps, one would be able to filter the apps according to categories and therefore find or discover more easily applications corresponding to one's need.

So e.g. something like this where category filters "File storage" and "System tools" are selected (though not propagated to the apps below because that's just a very drafty HTML/CSS experimentation :wink: )

Capture du 2019-03-24 03-42-38

I also randomly added the 'Featured' button to list only featured app ... though we might want to have it more as a filter in terms of quality (so, similar to the current filters "official", "working app" filter and "all").

To be discussed !

maniackcrudelis commented 5 years ago

That's really nice to see some stuff going forward about that (old) idea of categories. We have really a lot of apps, and I'm sure a lot of them aren't well know because we don't know what they're doing.

I'm really in favor of fixed categories instead of free tags, because I think free tags will ended with a lot of tags for the same idea. Instead fixed categories could help users to know where to look for a kind of apps.

I was wondering why a Other technical tools, but looking at your file, I understand... Globally the categories you've propose looks good to me. Technically, I think this list should be in a separate file, so it would be easy for us to add or remove some. Since I'm pretty sure we're going to add some, especially at the beginning.

Agree with the idea of a new key in the manifest, best way for me to be sure the syntax is correct and all categories exist. And it's also a way to check if the chosen categories fit the app.

The only thing I'm worried about, but that's another problem, is the very strict and specific syntax of json. I'm afraid this file becomes too difficult to edit without mistakes for non dev packagers.

Considering the Feature tag, I'd rather prefer to keep it as a quality tag, apart of categories, because we would like to have a clear view on it in the app list. And for the final user as a quality filter because that's more what it is.

eauchat commented 5 years ago

Nice feature :)

I understand the idea of having few categories, and I think it fits more the filtering UX you are introducing.

I think tags could be a great value as well. They can help searching, sorting. I believe that stackoverflow use a tag system that's limited (= the list of tag is predefined and you can't just add any tag you want), but there are still a huge number of tags, that could be an interesting approach to tagging.

I have the feeling that maybe those are two distinct features, but it might be easy to build them both at once.

The way I would see the tagging, in terms of UX, would be that in the app card (where you see the name, description...) there would be the list of tags this app is associated to, you can click on one, and it'll show you the list of apps that have the same feature. It can help you see different alternatives quickly compare and choose which one you prefer. I'm saying that, because when the categories are general, you may have a quite long list of apps to try and compare, while maybe you're searching one specific feature. For example tags could be "music", "video", "card game", "password", "wiki" (like you said)... The more the list of apps will grow, the more the tags will be useful I think, but maybe at this stage it's not indispensable yet, not sure.

decentral1se commented 5 years ago

Ah, some relevant discussion in https://pad.lqdn.fr/p/yunohost-04-06-2019 regarding this.

https://degooglisons-internet.org/fr/alternatives/ has good examples of categories.

zamentur commented 5 years ago

Aleks your file is not reachable anymore.

I have sort wishlist and working apps : https://fichier.reflexlibre.net/index.php/s/JpcqmakwLKXRf5Q

I think we should rename "other_technical_tools" into "other".

I have put all "erp" into "collective_organization".

It was not clear where to put things like networking tunnel (openvpn, tor, wireguard, zerotier ...)

alexAubin commented 4 years ago

Btw, posting the draft of interface I worked on a few month ago : 2019-06-24-220710_1366x768_scrot

tituspijean commented 4 years ago

Hi,

quick feedback on the apps list with categories : ❤️ , but is it possible to display the search bar on the main page too? It only appears after I click on one category.

image image

alexAubin commented 4 years ago

We've been wondering with that but that makes the whole code a bit funky. In fact I implemented what you suggested in one of the first iteration but we decided with ljf to instead have an "All apps" virtual category instead... But maybe I forgot to implement another small change which was to move the "All apps" button to be the first one. Would that sounds like an acceptable solution to you ?

tituspijean commented 4 years ago

UX-wise, it still requires an extra click, but an "all apps" button can be a middle ground if the code is too funky to be adapted this way, indeed. Nevertheless, the whole feature is a great improvement.

alexAubin commented 4 years ago

Closing because initial issue got fixed ... 'All apps' pseudo-category got moved to top (at least in unstable, soon in testing). Will see if we bring back the search bar to the top of the category list or not ...