Community Plugins are sorted after Downloads not Usecase/Topics which results in some plugins being made multiple times. There are at least 5 Math Latex plugins!!!
Because Obsidian only really has an advantage compared to other note taking apps because it is customizable.
However most people dont know much about programming and thus rely on these plugins and css files from the community. Otherwise they would just use another note taking app instead because they definitely have the more userfriendly interface! Thus even the Obsidian Devs rely on Community Devs in some way.
Solutions
Plugins should have tags that we can search through:
to see alternative plugins for our usecase
as well as related plugins that enhace the functionality of our searched/ already installed plugin.
Plugins need to be compareable so that we can see which one is easier to use or fits better for our usecase.
There should be official plugin documentation standards/ guidelines to help plugin developers to create easy to use documentations. (some are huge and the syntax explenation is scattered around).
The devs should work to turn the most used community plugins into core plugins.
Obsidian Devs should help Community Plugin Devs to work together on one plugin instead of developing the same functionality in seperate plugins.
Discussion
Surely this doesnt guarantee that Community Devs actually work together but having less but better developed plugins is still good for everyone because it helps that plugins dont interfere with eachother and eat more RAM than they need to.
Community Plugin Devs also need to help make their plugins compareable because they put in the data regarding their plugin. However if adding 3 tags is enforced by design and the community can vote to add, delete, change tags we can do it by ourself.
This change is a gradual one and needs at least 6 months for most active devs to change their community pages.
You think that there are duplicates because plugin developers are not aware of other’s people work.
The reality is that most developers do not like to read/understand somebody’s else code and/or they prefer to “do their own thing”. At submission time, we try to point out duplicate work, but it rarely works.
There are some guidelines and policies, some are mandatories some are suggestions.
This is a trade-off. If we require more, we get less plugins of higher quality and vice versa. However, it is hard for us to burden plugin developers with more hard requirements since 99% of them are doing this work for free out of passion.
I’d also like (most importantly to me) to have a tag which indicates an app is potentially not maintained (i.e. no updates in a year), so that users can filter these out. There are loads unfortunately. This should be something that can be manually turned off if a plugin is pretty basic and doesn’t require updates to continue working.
Furthermore, I think it would be great if the devs would remove these dead/unmaintained plugins to keep the community plugins tab manageable. In a lot of cases, it’s as simple as sorting by update date, checking the GitHub issues of the plugin and seeing whether it works or not (and warning the maintainer). These could potentially be readied later if there is an update but it would really reduce the bloat of packages in the plugins tab.
I agree that this happens sometimes but with regards to the LaTeX plugins I have used, these plugins are generally quite distinct and where they are similar (the autocomplete/quick typing plugins), they are often implemented in different styles (I.e. Latex suite using vim/ultisnips style compared to quick latex which is a more generic tab completion style) which would be hard to reduce to a single plugin offering the same diversity.
My main opinion is not that there is too many plugins of the same type (there may be but they probably offer different features and are worth checking out for their own merits) but that there are too many of these plugins that are unmaintained which lends to the idea that there are many duplicate plugins.
you might like … Better Plugins Page for Obsidian (BRAT or manual install)
Key Features
Filter and Sort: Seamlessly filter and sort community plugins based on criteria such as download count and last update date, allowing you to find plugins that match your preferences more efficiently.
Hide/Show Plugins: Customize your plugins page by hiding or showing specific plugins. This feature allows you to declutter your interface and focus on the plugins that matter most to you.
Hidden Plugins List: Maintain a list of hidden plugins, which can be easily managed through the Obsidian settings. This list ensures that you can control which plugins are displayed and which remain hidden.
Toggle Visibility: Quickly toggle the visibility of hidden plugins, giving you the flexibility to show or hide them on demand.
User-Friendly Interface: The plugin integrates seamlessly with the Obsidian user interface, providing clear buttons and icons for hiding, showing, and filtering plugins. It enhances the default Obsidian plugin management experience.
Filter by Updated Time: you can easily filter community plugins based on their last update date.
Filter by User Download Count: Gain insights into the popularity of community plugins by filtering them based on their download count. This feature enables you to discover plugins that are widely used and trusted by the Obsidian community.
Saved plugin, Save your favorite plugins and access them conveniently within Obsidian. Keep a curated list of plugins that enhance your productivity and creativity.
Filter by Saved Plugin, Only see your favourite plugins
Plugin note, Add notes and annotations to plugins for easy reference. Keep track of your thoughts, tips, and ideas related to each plugin. If you don’t want this feature, you can turn this off in the plugin setting tab.
… would be great if @yomaru could be persuaded to either add categories or tags one could determine oneself … [not planned].
@yomaru … thanks for the plugin … would you please reconsider including …
… categories - official: perhaps based on @Mara-Li’s categories or Obsidian’s categories.
… tags - personally adjustable: e.g. I use them for their current installation status
enabled-always enabled-toggle enabled-trying install-on-need try-next try-when uninstalled z-isDesktopOnly
… then I could rely totally on your plugin, without the need of maintaining my seatable database.
It’s already possible to sort the plugin list by when they were last updated.
They already do, tho it’s not something that comes up often. I believe the process relies in part on user feedback — if there are a bunch of unaddressed bugs on the GitHub of a plugin that hasn’t been updated in a long time and the developer doesn’t respond to inquiry, then the plugin may be removed. If a plugin hasn’t been updated in 2 years but still works (like Calendar), then there isn’t a pressing need to remove it. Developer policies - Developer Documentation
I fully understand this issue i just think that maybe with some design changes to the way how plugins are displayed, you could help make things a little easier at least for users at least. (knowing that obsidian has an ease of use issue because it only gets really great with plugins)
And if devs see how many plugins already exist they may try to fork insead of doing their own thing.
After all we have to try things in order to find better solutions.
