This GUI claims to have the expressive power of a CLI. If you squint, it's a visual programming environment. One that keeps track of the tasks you are working on, and the workflow you need to complete those tasks. With built in support for collaboration with other people. These seem like useful features for a visual programming environment. @Sébastien any reaction to that?

I like the idea of breaking down application into composable components (which was the platonic ideal of OpenDoc, and BeOS's translators, to some extent), and evolving the CLI so that it is not text-based but hybrid text/visual is something that hopefully will happen to our everyday OSes. The thing that I don't like about Mercury specifically is an extreme Apple-ification of the user experience: instead of letting people decide, the author provides a set of curated micro-experiences revolving around common operations. Interfaces should simplify actions, but they should not simplify at the cost of removing degrees of freedom. But in the case of Mercury, it's primary goal was to reduce the cognitive load, so it makes sense to do so. To me, creating a visual environment used for intensive work (like programming) means that task performance, flexibility and information bandwidth have to be considered as priorities -- Mercury does provide some interesting elements, but its fundamental goals are not in line with requirements for a high-performance work environment.

Pour one out for OpenDoc.. 🍺

I'm dubious of any "OS" design discussion that starts and ends with the GUI.

Counterpoint: why not start with a GUI when designing an OS? After all, an OS exists to serve the user?

I think starting with the GUI is fine, but my point was begins and ends. If you start with the GUI and interactions you'd like to have, then that may inform the rest of the architecture

Ah right yeah. I have no idea where this will go. But I find it useful as a visualization of an alternative idea to app orientation: intention/workflow orientation.

This person is a visual / interaction designer. There are a lot of those people on the planet. When they're working on their own, they make mockups. Like this: http://nenadmilosevic.co/ableton-live-redesign/ Or like this: http://www.minimallyminimal.com/blog/2012/7/3/the-next-microsoft.html You could call these "mockups that never went anywhere". But that'd be like a BFA saying all the Lisp compilers or quines or rendering engines or constraint systems we programmers whip up are "products that never went anywhere". As a visual / interaction designer, the offering that this person is making to the world is — "Here's an idea I had, and here's how I would realize the parts of that idea that I have the skills to create." You could hand that same idea to a programmer, and they could make a usable prototype, but in the absence of help from a visual / interaction designer it'd almost certainly look so bad that it'd be hard to use. And in the absence of someone skilled at sales or marketing, it'd probably never take root in the world at large. So don't dismay that this is yet another mockup. Learn what you can from this, so that when it comes time for you to make your demo, it might be benefitted by you having studied good visual / interaction design.

Going back to the actual idea... I quite like this concept. It's a refreshing change from the silo app world where any integration between apps is really poor and crude file-copy based. My intention/goal is also split across apps, each with it's own distractions since they intermix all my intentions. E.g. Gmail shows me all my emails - I don't really care about emails but the greater purpose they serve. Maybe I'm working on a home improvement project and waiting for a package containing a tool and am just interested in that email. I also have other ideas and resources (how to videos) I bookmarked for the same project - these are split across a note app and my browser bookmarks. So if the computer let me make a 'space' where I could freely intermix these kinds of objects, that would be awesome. I've thought about context sensitive spaces before. E.g. when I'm thinking of travel, 'everything' I'm looking for in the destination is centered around some dates. I have to type out those same dates so many times in different places it's irritating. What if I could make a space, 'pin' a date onto the space. Then anything I bring into the space (drag and drop an event calendar for instance) automatically highlights and scrolls to the contextual dates. The same idea can be extrapolated to places, people, project names, etc.

In my own work, Onex, you have a tree/graph of objects on the left half of the UI, and a workspace on the right where you can pin any object you come across. There are no applications, just these objects. You can create new objects on the left aggregating stuff you collected on the right. Everything is linked so you can pick up anything of any type by its link and put it in another object.

I think I like the core metaphor of modules and flows, where I think a module is a state mind (studying for a certain class, catching up news, sorting incoming tasks, etc) and a flow is the encoded multi-application set of microtasks that solve some module-level goal. But I sure do hate the term "module"! With respect to scripting, I like thinking about it as collaboration (https://www.ianbicking.org/blog/2014/02/collaboration-as-a-skeuomorphism-for-agents.html). I think it would benefit from an OS-level distinction between staging an action and performing an action: our permission systems usually only let an app/agent/script either perform an action or not do it at all. Having a UX metaphor for staged actions also let's us group and review past actions.