I love the idea of Logseq and the basic workflow, but I can’t help but frequently stumble across some of the features that aren’t really part of the core of what Logseq does.
The most obvious one is the spaced repetition feature. I like spaced repetition, but I don’t use it from within Logseq. Nevertheless, I always have the “Flashcards” tab featured prominently in the left menu, and can’t turn it off. This may seem like a small thing, but I like my “mental workspaces” as clean as possible, and such things clutter that.
It doesn’t stop there - things like presentation mode, Git integration, TODO/DOING, Zotero integration, etc. aren’t as visually prominent but are still non-core features that make Logseq more complex to use.
Don’t get me wrong, those are cool features for the people who use them. But I think they should not be included for everyone who downloads Logseq by default, or impossible to remove. Logseq has a great plugin system and marketplace - that seems to me like the ideal solution!
Moving these features into plugins would increase separation of concerns, keep the base Logseq client slim and allow everybody to pick and choose which features they find useful for their individual workflow.
I do agree with what you are saying about unused features being somewhat noticeable in the GUI, but at the same time, I think this is a rather limited problem at the moment. I personally find the Logseq GUI quite clean and uncluttered.
In fact I do like that a lot of the features are native to Logseq and do not rely on plugins. Supported by the team, all build with the same ‘way of working’. It feels coherent to me.
I come from Obsidian and the need and sometimes non-interoperability to use plugins for advanced functionality is what drove me away eventually.
I changed task plugin 2 times as those where not supported anymore by the plugin-author for example.
Or I used inline fields for dataview in Obsidian (like fieldname:: ) but not all plugins supported that way so I needed to add some fields in the YAML header and so on.
The more plugins I used the more it felt like an incoherent product. To me at least.
Discovering Logseq felt like a breath of fresh air to me.
And of course, also the fact the outlining matches more with my way of thinking was another big factor.
I think the part about features being officially supported and well-integrated wouldn’t necessarily be a problem if more features were moved into plugins. Those plugins would simply be plugins that “happen to” be made by the same developer(s) that take care of the core of Logseq. They would still benefit from the additional insight and deep integration, since the people responsible would be the very same as the ones designing the plugin API!
I do think that some features (like the block/page attributes) should remain in the core of Logseq so that other plugins have a consistent interface. But I don’t think the majority of “extra” features actually benefits that much from a consistent interface (eg. the way of interacting with Git doesn’t change much whether it’s a Logseq-feature, plugin, or just a repo that is managed by an external git client).
If nothing else, I would appreciate options to turn off non-core features so they don’t appear in the navigation. That shouldn’t conflict with any of your concerns, and still help people like me a bit.
I think doing it the Obsidian way and making some of this functionality into “core plugins” one can turn off would be great. I turned off about half the core plugins in Obsidian, and while I like the full feature set of Logseq, I can see the value of being able to deactivate unused features. Less clutter + better performace.
I’m in favor of something similar to Obsidian’s “core plugin” area where entire features can be disabled. For now, I’d see the flashcards, zotero, and github topics as things that a new user could disable to keep things simple and then enable if the need arises.
This is NOT to be confused with a preference for plugins. Obsidian is in danger of going the way of Wordpress, where really important functionality is only available via plugin that may or may not be well maintained.
I like the ability of having plugins, but I detest the dependence on them. I’m happy with what I’ve seen logseq bringing into core. It’s a tricky balance, I know.
was the 1st thing i noticed when I started using Logseq… the idea of a modular app is definitely widely adopted (look at Confluence, for example) - core product ships with core plugins developed by the product team, but can be selectively turned-on/off and: what’s even more important - those can be upgraded not touching the core system
I suggest as others have that most features could be plugins. I also suggest the plugin api needs more hooks. This could mean when looking to integrate features the maintainers use each opportunity to explore how the plugin api could be extended to accommodate the feature as a plugin.
Code Simplicity, an underrated classic, suggests that in each iteration you make the software no more complicated than it need be. Then as new features are added, you refactor to extensibility making it easy for the new feature to be hooked in. These principles are among the best in software development.
To summarize most new features should become an opportunity to extend and use the plugin api. Logseq may ship with a prerequisite set of plugins, but users can opt out. All the while the plugin api evolves for the better. If Zotero, a core feature I will most probably never use, were a plugin I’d drop it.
I give huge props to the creators/maintainers of Logseq. It is amazing FOSS.
Couldn’t agree more. As a Workflowy user who likes some of the features and wanted to give Logseq an honest run, I just couldn’t handle all the excessive noise in the interface. Couldn’t do it for more than a minute. Instant turn off. If everything started “off” and I was allowed to add things as I got more comfortable, you’d probably have gotten me to switch. But I can’t even handle the flip/flop of markdown code being revealed, or the overlays when I accidentally rest my mouse somewhere. Just give me bullets in plaintext (and a slash command and encryption and me owning the data). I’ll find the rest when I want it.
I think this is logseq’s major limiter to more adoption right now, personally.