Was reading tweets about MercuryOS, stumbled upon this: http://artifacts.fyi/ Looks even more advanced.

I feel like I've seen this before. I mean Mercury OS specifically, not just, say a flow view which is like Glamorous Toolkit and many other things to be sure. I love the general notion of organizing things on screen around activities/workflow primarily. Many system allow this (often accidentally) but too many try their best to prevent it. In short, apps suck. 😿

Maybe I'm missing it. This looks like OLE (Object Linking and Embedding) from Microsoft Windows 3.1-ish days. in the mid 90s. You could put one app's output embedded live any other app that supported it. It turned out to be a horrible idea. One problem was the UI required for each activity conflicted with the UI used for the overall app. To put it another way, when I'm serious about editing an image I want the 1000s of options of Photoshop or Lightroom. When I'm serious about making a diagram I want Omnigraffle or Illustrator. When I'm serious about 3D I want the 5000 features of Blender or Maya. When I'm serious about spreadsheets I want Excel. etc... These apps that claim to put it all together have the most basic of features. I can pop a drawing into my "document" and I get the "notepad" of drawing programs to work on it with. There were other UI issues as well. Embed a 1024x768 image in your document and clicking on it there might be room for the UI. Embed a 64x64 pixel image and suddenly that failed completely. At some level you need both UIs. The UI that lets you edit the image/3d/diagram and the UI that lets you pop out to the containing document. Even with separate apps (so the UI is separate) and just using the linking portion turned out to be a huge problem as then you get the combinatorial problems of having all the apps have version issues so you load up some containing document which links to data from 4 other apps. All those apps need to be loaded to display their embedded data. Of course you might say the apps should display some generic representation which is fine but then you still run into the issue that the moment the user clicks on that data the want the app to be able to edit it and put it back in. Further, outside of basically unformatted text and simple bitmaps most formats are unique and there is no translation between them because they actually support different features. A simple example would be one app might represent a circle and a center and a radius. Another app might represent a circle as the min and max extents which is more flexible. Can do ellipses. There is no easy translation between the 2. Going from ellipse supporting app to only circle supporting app requires adding some kind of scale node assuming circle supporting app supports scale node. Going back is now lossy. There's no way to know did the user start with an only an ellipse or did they have an ellipse as a child of some scaled group. This kind of issue of structure data is yet another reason why this type of thing doesn't work in practice. As another example there are hundreds of Photoshop features not found in gIMP so if you embed a Photoshop image what's supposed to happen when someone tries to edit that elsewhere?

OLE had a crazy-a API though! There's an in-the-middle level of integration. We'd benefit more from a window manager plus limited links... and oh... oh dear... I'm getting close to describing Acme http://doc.cat-v.org/plan_9/4th_edition/papers/acme/.

OLE failed IMO because that kind of rich integration cannot be retro-fitted. Once you start with apps you're already stuck to whatever interchange mechanisms exists - libraries, files etc. To do something different you start from the new idea and you don't have 'apps' but other entities (objects/views?) that live and conform to the environmental constraints.

The approach used in Mercury OS and reminds me of Jef Raskin's Archy https://en.wikipedia.org/wiki/Archy (formerly The Humane Environment). The umbrella term for this type of interface is a zooming user interface (ZUI) https://en.wikipedia.org/wiki/Zooming_user_interface. Ink & Switch's Muse https://www.inkandswitch.com/muse-studio-for-ideas.html was recently discussed here and also uses this paradigm. You could loosely categorize operating systems this way: Traditional desktop OSs (Windows/macOS/Linux) are file-centric, mobile OSs are app-centric (iOS/Android), and ZUI/Mercury OS/Artifacts are document/task-centric.