A simple plugin system allowing for custom bullet types created by the community like
whiteboards, LaTex Math display, PDF viewer, Charts, Spreadsheets, forms, …
On the technical side it could work like this: A new iframe bullet type. Then in the settings you can add a plugin by defining a custom command like “whiteboard” and then the url of the third party tool. Then when you type the /whiteboard command on a new bullet it turns it into a iframe with the url www.pluginurl.com/{{bullet_id}} where the bullet_id is the same id used by workflowy to indetify the bullet.
The iframe should also be able to communicate with workflowy using the postMessage api with these event types.
SIZE - Allow the iframe to adjust its own height and width
FULLSCREEN - Open the iframe in fullscreen, e.g. for whiteboard app to bring up a frull screen editor
SET/READ DATA - Allow the iframe to store some json data in the bullet, like a LaTeX Plugin can store the maths right in workflowy and then display it in the iframe. Like this plugin developers don’t need to run their own database, keep cost of plugins cheap / free.
Additoinal optional features
In the settings along with the custom command and plugin url, add a third input for “licence key”, which is then sent along with all requests to the plugin (maybe as query parameter or using postmessage after iframe is loaded). Like this paid plugins are possible.
Maybe the iframe csp property can be used to sandbox the iframe so that no network requests can be made. Like this no customer data would ever leave workflowy, plugin data ist stored right in workflowy using the api described above.
Plugin marketplace where plugins are uploaded as zip and are then hosted by workflowy for more reliable access.
I also like the plugin system of RemNote, which is more advanced. But i think along with the new Workflowy Rest API this simple plugin system would be enough.
You mean plugins in general or my technical implementation?
Plugins in general:
Support for whiteboards, LaTex Math display, PDF viewer, Charts, Spreadsheets, forms, …
My implementation:
Using Iframe and postMessage API is simple to implement both for Plugin developers and Workflowy team. Provided Workflowy is built on web technologies on all platforms, which I think it is. Or does Workflowy have true native apps?
I’ve noticed in other products that a plugin system can lead to this bad situation:
Users have a need for a particular feature (say, Latex math).
It’s low priority for the developers, so someone writes a plugin.
Now that the plugin exists, the developers really don’t have to do it, so they remove it from their to-do list permanently.
But the plugin was written hastily by a third party who has bad UX sense, didn’t do a complete and good job, and has since lost interest.
The existence of the plugin leaves the feature in a bad state that it can’t get out of. Without a plugin system, the devs will either do a good job or not implement it. I’d rather have that, and some hope of having a well-maintained and well-implemented feature, than see a slew of plugins in a bad state that I know they’re unlikely to improve from.
We could maybe have the best of both if the devs committed to regularly reviewing popular plugins and internalizing them as official features. I’ve not really seen this done elsewhere, though, I think it’s too easy to do other things on the to-do list.
My notes are split up over many different apps (Whiteboard app, Todolist app, even other Note taking apps like remnote and notion) which i really don’t like. My favorite notes app is Workflowy and i would love to have everything here in one place. I personally would prefer hastly written plugins with bad UX over having my notes all over the place. Having these features natively implemented would be better of course,
but giving the slow progress of workflowy, i just don’t see that happening any time soon. I mean just look at the amount of plugins there are for obsidian, there is just no way that workflowy on there own would even get close to the amount of features the competition offers. I was hoping that with workflowy opening up their system with the new API they might also be willing to create a simple plugin system.
Hey, I’ve been a Workflowy user since 2019 and wanted to share a different perspective on some of your points.
On Slow Progress: From my experience, the team has been releasing new features at a breakneck pace lately. In fact, I’d say they’re more active than ever. We’ve seen a ton of great improvements over the past year or so that have made a huge difference in my daily use.
On Importing from Other Apps: You mentioned wanting better import functionality. Workflowy already has import features, and with Zapier or the API, you can connect it with a ton of other apps. Have you tried using the existing export/import features to move your data? Many apps let you export as OPML, which you can then just drop into Workflowy.
On a Plugin System: This is a super interesting idea. What specific features would you want from a plugin system? I use Logseq too, and I agree that its plugins are critical for its functionality. However, the reason I find Workflowy so powerful is its simplicity. I can see a plugin system potentially going against the core design philosophy of keeping the app clean and lightweight.
I think the magic of Workflowy is that it’s just a blank canvas for your thoughts. Adding a bunch of plugins might overcomplicate the experience, especially since many users, including me, value it for its minimalist approach. I’m curious to hear more about what specific problems you’re trying to solve.
Hi, @thesamosborne,
WF already have an elegant way to hide features you don’t need, so that could solve the problem of breaking the UX for minimalists. I see the value in this too.
Many ideas (proces flow, data relationships, infrastructure) don’t fit well a tree structure. Therefore whiteboard (like Excalidraw) would be extremely helpful.
In case of diagrams, they could behave very similarly to current FW notes, because each process could break down to another diagram, and they could (should) be also reused. The difference is in more complex relationship with their siblings (multiple connections) and of course the visuals . Both atomicity and fractal structure could be reserved.
. Both atomicity and fractal structure could be reserved.