I think we need a more radical change: dissolve apps into the operating system.
Many of my frustrations today come from the sharp line between apps and OS. Apps have custom storage formats, custom UIs, and custom settings, and that makes it difficult for a user to deal with their data holistically. Even something as trivial as searching across all my data is not a solved problem, and that's because every app has a different way of representing data.
But what is an app? An app is just a UX/UI on top of a data model with domain-specific rules for transforming that data. What if we could decompose those pieces: the UX is just a custom control; the data model can be represented by a standard database; the domain-specific rules can be a headless component.
The decomposition gives the user more control: all my data is in a standard database. I can drive headless components via script or agents. And I can compose my UX based on my preferences instead of how the app decided to package it.
Agreed! That was also one of the original goals of WinFS in Longhorn, but I wonder if it was just too early. The original problem with WinFS is that it was too slow, but that was before SSDs and several Moore doublings ago.
Possibly too early, or possibly too ambitious. Looking at the Wikipedia article[0], it feels like it was definitely too ambitious. The design seems to have everything that you'd expect out of a full-blown relational database.
BeOS feels more like a document database - no defined schema, just attributes attached to your files.
that's because it was a full blown relational database - it literally shipped with a desktop variant of SQL server (MSDE) and the WinFS bits were implemented in .NET on top of that.
I recall installing the WinFS beta 1 release and suddenly the winfs-related background processes were eating up 150MB+ of RAM at a minimum, even with no stores created or files indexed - when machines back in 2005 had 512MB of memory that's actually a lot for what is supposed to be a background service.
Windows XP back then only needed 128MB of ram to run. they made a mistake in not building it on top of something akin to sqlite - hell they could've implemented maybe 70% of what they shipped in beta 1 with just sqlite alone.
The solution here is interchange formats. These do exist but are generally never _that_ succesful because vendors of apps have to be differentiated in some way.
There are tons of examples of this, Blender cant open Maya or 3dsmax projects, because each vendor has their own differentiating features, their USPs and they have not zero, but negative incentive to help competing Apps easily support them. So we land in some middle ground where FBX or OBJ and JPG and BMP are widely supported and are the formats we can interchange between apps.
I think with all due respect what you are asking for is an impossible goal because it would require complete central co-ordination, which would remove competition and innovation, and I'm not even talking about this in a capitalist vs socialist economic frame, just in the co-ordination sense, how does the precise data model get decided, who does it and how long does it take for me to get my experimental dog poop tracking app approved and folded into the unified model? Forget about dogs I'm tracking ant movements and reproduction across seasons while recording moisture levels within the colony, does this central database have a schema for that already? if not, how can I get it in , and what if someone else was working on a similar app but was tracking reproduction of the ant colony with relation to nutrient levels and soil composition.
Strict global co-ordination is not possible, fundamentally, there is endless examples of this at whatever level you want to look at.
Many of my frustrations today come from the sharp line between apps and OS. Apps have custom storage formats, custom UIs, and custom settings, and that makes it difficult for a user to deal with their data holistically. Even something as trivial as searching across all my data is not a solved problem, and that's because every app has a different way of representing data.
But what is an app? An app is just a UX/UI on top of a data model with domain-specific rules for transforming that data. What if we could decompose those pieces: the UX is just a custom control; the data model can be represented by a standard database; the domain-specific rules can be a headless component.
The decomposition gives the user more control: all my data is in a standard database. I can drive headless components via script or agents. And I can compose my UX based on my preferences instead of how the app decided to package it.