[Feature Request] Display plugins by categories / Filter for Plugins

As we are adding ability to inlcude Plugins' categories in its manifest, we need to add UI in the app to sort the plugins.

  • By looking at some desktop apps, I have found VS code has very extensive plugins filter.

  • Obsidian has very basic filter currently.
    obsidian-plugins

  • On web side, Chrome Extension have listed them on left side.

  • (Not entirely relevent to this but Chrome Extensions and Atom has Themes as a separate section. I think in future we can also do something similar)

So I think we should implement something similar to VS code's Filter. What do you guys think?

1 Like

Also I am attaching a demo video of what this might look like but this is very basic. We will need to add more to it.

But do you guys think we should also have all the options such as Featured, Most Popular, Recently Published, Recommended, Enabled, Disabled, Sort By? (I am not suggesting that we should copy the exact names here)

Looks good. Though I think the default should be "All", which seems to be missing from your demo/list.

2 Likes

Thanks for the suggestion. If you are referring to the video it does not contain full categories. Its just to give an idea for the UI.
But yeah I also like All category. But if we decided to have an default I would suggest going with Recommended as the plugins have been reviewed.

I think I prefer the VSCode UI with a dedicated filter button. It looks cleaner and, as in VSCode it is nicely extensible for future improvements like popularity sorting or being able to show only recommended plugins for a given category.

1 Like

Yeah, 'VSCode UI' seems to be the right answer in surprisingly many cases. :grin:

1 Like

Yep, I also like the VSCode filter button looks cleaner definitely.

Well the other part is UI consistency, a combination of text input + combobox is yet another UI combination which doesn't exist anywhere else in the UI (that I'm aware of).
The plugins page already has the concept of an icon button combined with menu items (a metaphor I think really should be extended in the UI in other places but that is a different conversation) so to me that makes the most sense.

1 Like

So are you suggesting that text input should be removed? Do you think user should be able to search for the plugin after selecting the category?

Not at all, I'm saying we should be reusing element groups or modules as much as possible and the combination of a text entry box with a combo box would be another unique combination not used elsewhere in the application.

Ohhk got it. An icon with combined menus, just like VSCode's filter icon.
I think now we need to think about where it should added as there is already icon button in plugins section for "Browse all plugins" and "Install from file". If we added separate "Filter" icon maybe it would also contain All category then do we need "Browse all plugins" ?
If not then that icon button will only be used to "Install from file".

I don't think they conflict at all. The "Browse all plugins" is a link to the list on the plugin repo which contains more info and links than is available in-app whereas the filter should be just that. Remember you can already get an unfiltered list by just typing a space so it isn't like we had any differing functionality here.

I just thought that there is almost all information available in-app about the plugins but this may be a different conversation.

Yes, but don't you think it would be easier if we had All category? just my opinion. Sorry if I am causing any confusion here.

But that "all" filter is going to filter on the installed plugins - not the remote ones. To get the ones from the repo don't you still need to take some kind of positive action on the search bar or otherwise have a "fetch" or "refresh" button to initiate it? The set category filter would then apply to the search results rather than just the installed ones.

Personally I don't think we should be showing the repo plugins without a positive action being taken (like how it works at the moment).

Just my $.02... I always thought this was very bad ux. I mean it's not bad that it happens, just a bad way of showing everything. No reason someone would know to do this.

1 Like

Yes that was my exact reasoning behind adding something like All because I discovered we can get all plugins by typing space accidentally but I don't think that everybody will discover this. Even if they did I think maybe we are relying on them to. But its ok if we cannot add this for now.

So you are saying we should only filter "Installed" plugins or
Edit: only selecting a category should not show plugins?
?
If not here is an idea inspired by VSCode's filter,
We can add the name of category in the search bar itself like we do when adding 'Tags' so maintaining UI consistency. As VSCode inserts "@category: 'Extension Name' " we would do it in more user friendly way.
And if search bar is empty we show installed plugins just like how its done now.
category-search

I wasn't making comment on the UX, rather just pointing out that app already features an "all" filter combined with the "browse all plugins" so in that sense there is no change in functionality which was what @makb was commenting on.

No. I'm saying that the filter should work for everything - if you set a filter without having searched for anything then it should filter your installed plugins. If you filter after the info from the repo has been queried then it should be filtering that.

I also think we should remove the "Manage your plugins" label and have the cog icon next to the filter icon.

1 Like

Yes, I have never thought "Manage your plugins" was a correct label. Neither installing a new plugin nor looking at all available plugins are "managing your plugins".

Thanks to everyone working on this!

1 Like

Thanks for clarifying and all the quick replies.

Ok but don't you think user will also want to browse the plugins in some specific category without searching for anything? just as we do in VSCode.

Yes!, I also always felt that it was a bit incorrect.

Yes but I also think the filter should apply to the installed plugins by default - it isn't a great comparison but Atom separates its installed and community packages to two different areas so that you can search and manage your installed plugins independently of the ones stored in the repo.

I might be reaching beyond the scope of this feature by considering the UX of the entire plugin page but I think this might be needed - the list of plugins is still growing pretty quickly and I think there needs to be a better way to help people manage what they already have installed - not only getting more stuff online.

Now whether that should be managed by having a separate UI like Atom or if there simply needs to be a way to "activate" fetching from the repo I'm not sure.

I'll leave it here for a bit and allow others to weigh in on this - don't take my opinions as gospel or an "offical" stance on the matter, I'm just adding my own thoughts on it.
I'm going to go and have a look at some other apps beyond the ones I'm most familiar with.

3 Likes