Document-centric workflows were once the great promise of the future, and inspired Microsoft's OLE, Apple's "Publish and Subscribe", and then OpenDoc.
I remember reading a computing magazine in the early 1990s that promised a future where we would decompose applications and the OS would only really worry about a file, and you would bring functionality to the file.
You would in essence be able to build your own perfect word processing environment (for example), by bringing Company X's editing tools, Company Y's grammar checking and spelling tools, perhaps some embedded spreadsheet tables from Company Z if you were writing business reports, and so on.
We kind of have this a little today with browser extensions, in that we can extend functionality onto a webpage we're viewing, but our environments are still very application-centric and not workflow or content-centric at all.
This article shows an application that _might_ be interesting (and the CRDT is a mandatory requirement in today's environment), but while the OSes we use require us to do this sort of work in a windowed application, it won't quite appeal to me as having the full potential.
I often think back to that article as it made me quite excited about the future of user interfaces and how operating systems could support workflows tailored to the individual and the task they wanted to achieve. This was all in a time when we had moderately novel ideas in OSes popping up (Windows NT, OS/2 Warp, NeXT, etc.), and just before the web was starting to get popular.
The main reason we don't have a future like this isn't technical. It's that there's no business model here. Developers want apps that jail everything inside to force people to buy or subscribe to the app. Interoperability means no moat, and decomposing apps entirely means no products at all just a tool box that nobody can really control. So far nobody has ever found a way to reliably monetize this kind of software landscape.
No business model means no long-term maintenance, no polish, no marketing, no attention to detail, no usability iterations, and so on. Quality software that is easy to use (especially for non-technical users) is extremely expensive. Developers are expensive. So instead you get "WIMPs" (Weakly Interacting Massive Programs) that win in the marketplace because they are more polished, more maintained, and more supported. (Because people pay for them.) Lately most of these WIMPs are in the cloud.
The more I've matured as a developer the more I've realized that business models are the tail that wags the dog and that a lot of the landscape of software is defined by what people will pay for and/or what is structured so as to make people pay for it.
Business models are also why things are increasingly centralized and in the cloud. It's not because it's inherently better, though it does make certain things easier to implement. In many cases it's a lot worse: higher latency, not available offline, much more limited and slower UI, etc. It's because the cloud is DRM and makes it easy to force a subscription. I mean look at Figma... there is no fundamental reason that had to be in the cloud except that it provides a ready-made subscription model that users can't evade.
This is something I think about, and there are some underlying technical issues as well, in coordinating all the plugins with common interfaces. We do not have workflow centric software even in the open source world which has managed to build a large family of apps in the usual mode.
Or maybe we have done it in the past(interactive software in SmallTalk), but have forgot about it.
Also, the business reasons are not prohibitive - if lot of users use the workflow model, there can be a store where they can request, raise funds for plugins with a specific functionality. Developers won't ignore it, even if the moat is weak, as there is potential revenue. It would be like consultants providing solutions rather than selling a product.
In the 1980s and 1990s there was a ton of very interesting work done on deeply thought out user-centric software designed to augment human intelligence and give people maximum control over what they were doing while still being approachable. The Smalltalk stuff was some of it, but there was some pretty spectacular stuff back in the old Windows 3.x, macOS classic, and even MS-DOS days where apps would interact richly and you had document-centric customizable work flows. You even had things like (gasp) composability of applications in GUIs.
All of this was completely abandoned and forgotten because there's no money in it. Make software like that and there's no moat, and make it local and people will pirate it. Lock it down in the cloud and lock down the data and people will pay you.
That which gets funded gets built. We get shit because we pay for shit. People won't pay for good software because the flexibility and user-centrism of good software allows them not to.
This is a very cool video. I am interested in making a dynamic notes app with user defined types and cutomizable flows. This is partly done already in Roam, AnyType... if you include the plugin system. But it seems like there is a lot of history.
Nevertheless, I am more optimistic about such a product. The key issue is building composable interfaces to which plugins can glue in.
Piracy is not such a big problem as one can give the product free of charge to users and charge for hosting or charge commercial businesses for whom piracy is not a risk worth taking.
If anything, the business implication of a ubiquitous workflow interaction is its threat to the ads model (users dont visit social media sites but read in data via apis). The ad model might need to be replaced by something like micropayments to content creators, but that is a distant issue.
In my mind, QuickLook on macOS is probably the closest thing we have to document-centrism in a modern mainstream OS, with how the OS discovers QuickLook extensions in app bundles and uses them to make QuickLook capable of understanding more document formats.
The only problem is that it’s read-only. If QuickLook extensions could provide write capabilities too, you’d have 90% of a document centric setup.
> You would in essence be able to build your own perfect word processing environment (for example), by bringing Company X's editing tools, Company Y's grammar checking and spelling tools, perhaps some embedded spreadsheet tables from Company Z if you were writing business reports, and so on.
Tree-sitter, LSP, various linters -- we're getting there!
I remember reading a computing magazine in the early 1990s that promised a future where we would decompose applications and the OS would only really worry about a file, and you would bring functionality to the file.
You would in essence be able to build your own perfect word processing environment (for example), by bringing Company X's editing tools, Company Y's grammar checking and spelling tools, perhaps some embedded spreadsheet tables from Company Z if you were writing business reports, and so on.
We kind of have this a little today with browser extensions, in that we can extend functionality onto a webpage we're viewing, but our environments are still very application-centric and not workflow or content-centric at all.
This article shows an application that _might_ be interesting (and the CRDT is a mandatory requirement in today's environment), but while the OSes we use require us to do this sort of work in a windowed application, it won't quite appeal to me as having the full potential.
I often think back to that article as it made me quite excited about the future of user interfaces and how operating systems could support workflows tailored to the individual and the task they wanted to achieve. This was all in a time when we had moderately novel ideas in OSes popping up (Windows NT, OS/2 Warp, NeXT, etc.), and just before the web was starting to get popular.