UX case study - MercuryOS

# UX case study - MercuryOS ###### tags: `psych-ux` `ux` `non-eink` `case study` ## Authors * Tom Phillips * Paul ## Introduction This article briefly summarises, evaluates and slightly reinteprets [MercuryOS](https://uxdesign.cc/introducing-mercury-os-f4de45a04289), a speculative redesign of the computer interface by Jason Yuan. It is important to note that MercuryOS is a stunning design/art project. This article leaves art criticism to one side, focusing instead on the underlying mechanisms and processes behind the proposed interface. ## MercuryOS by Jason Yuan ### Why a new interaction paradigm for our Operating Systems? #### 1. We do our best work in flow states Most of the time we use computers with a specific intention or task in mind. Completing these tasks efficiently and to a high standard helps us achieve our goals and improves our lives. Yuan highlights that our most efficient and best performance comes during *flow states*, states of hyperfocus in which the only thing in one's mind is the task at hand, while the outside world melts away (Deep Work by Cal Newport) Yuan highlights that our interfaces ought to be designed to help us initiate and maintain these flow states, so that we can do better work and achieve our goals. However... #### 2. Our interfaces are not designed to enable flow states For Yuan, our interfaces disrupt and impede flow states. Interruptions (e.g., notifications, alerts) and interstitial friction (e.g., visual clutter on the screen, having to decide what to name the file and where to save it) pull our minds out of flow, slowing our progress. He points to evidence of the time-costs associated with switching between two tasks. Yuan believes that the 'arbitrary sandboxes' of apps and the desktop metaphor make this worse. Tools and content are siloed within different apps on the desktop. But we often need tools from a number of these apps to perform a task. As a result, we have to switch between whole apps, causing us to encounter content and options that are irrelevant to our task, making it difficult to maintatin focus. (A thought: If voice assistants became the dominant paradigm of interaction, a lot of this would be removed. "Hey siri, send an email to John", is much more focused than open phone, find mail app, see a load of unread emails, click the send email button, type johns email -- altough you might feel self-conscious doing this in public, and it could be distracting to others if working in open-plan office). ### Mercury, a new breed of interface. Mercury's approach involves first breaking down all the siloes around apps, and the apps themselves into their different actions, tools and content. So if you want to just send an email, you can access only that part of the email app without accessing the inbox. Crucially, instead of organising actions, tools and content under the umbrella of apps, Mercury organises them by intentions. *EXAMPLE* A user enters the startup screen of the computer. They must specify their intention, what action do they want to perform? Doing so opens a "space", a kind of thread for this intention/task. If they have had this intention before, the system knows what different bits of apps to assemble within the thread so that they can complete the task. Otherwise, the user must state which bits of which apps it needs. --- Because Mercury organises by intention, the tools and information that you need are the only ones available, removing redundant options and content. This helps the user to stay on task. *Key point:* It is also just a really useful way to organise the different things your computer can do. Instead of having a bunch of unorganised different tabs and windows, you have a smaller number of intention-threads ("spaces"). Knowing the user's intention also enables Mercury to more precisely modify things like whether notifications are on or off. Certain notifications could be enabled without others. For example a message from your professor would be an allowed notification while your intention is to work on your coursework. #### What are the challenges? *Challenge:* Is it too slow/boring to always be specifying your intention? *Response:* Maybe if you always had to write out your intention and what you need to fulfill it every time. But the advantage of Mercury is that over time it eases this process by remembering what tools go with what intentions. Once it has learnt that, then it might be even less work that booting up all the different programs from scratch every time, because once you type your intention the system would do that for you. *Challenge:* No user research supporting mercury *Response: *This is an important challenge, but one that is easily remediable. Probably the most important thing to focus on. *Challenge:* what about when you just want to procrastinate, but don't want to write that as your intention *Response:* Having to write your intention is a great way to deincentivise procrastination. *Challenge:* Would this really improve productivity? *Response:* ... might not work for everyone... *Challenge:* Is it technically possible to do this? *Response:* [Paul] From the software engineering point of view, I don't really see how this would work with any existing software. Desktop software would definitely need to be rewritten with this in mind. Android has a mechanism called "intents" that would really help, but there needs to be something that governs the workflow setup. Actually, the more I think about it... Android is already pretty close to the MercuryOS concept if you disable notifications. Take the email example: if you open your email app, you'll see a list of emails you need to go through. You click on one email, it opens the contents as well as a list of attachments. If you click on an attachment, it sends out an intent to open the file, which triggers a viewer app, let's say a PDF reader. The app launches directly to the file you want to view. The same thing happens in desktop too, but the point here is that Android's intents are more flexible. On Windows (or Linux), an application can request a URI to be opened - that was originally intended to open a web browser to a specific websites, but nowadays it's sometimes employed to launch other apps too, for example, Outlook can notify you about a Microsoft Teams meeting and offer you to join it by clicking a button, even though they're completely separate applications. The way this works is that Outlook requests Windows to open a URI starting with "msteams://" or something similar, and Windows knows that the msteams protocol is handled by Microsoft Teams. So Teams gets the rest of the URI, which is probably an identifier of the action (join meeting) and a meeting id. However, this way you can only send a line of text to the receiving application - encoded in the URI. In Android, though, you're sending a structure object and you can even send binary data such as pictures. Anyway, enough babbling about technicalities. The main takeaways are: we need a central place to manage workflows we need new applications, because the existing ones don't really register intent/URI handlers for everything they do also, something I didn't mention before, there needs to be a better way to exit an intent. That is, an application should know when to close itself and switch over to another application. Ideally, it should even know which application to switch to. That is, instead of exiting and switching back to the one that called it, it should switch right to the next node in your workflow set up. But even if all of these are implemented, there's still a lot of switching between applications to accomplish different steps. A better alternative is to get rid of these "applications" altogether. So you wouldn't have an email client, but technically you'd have multiple separate applications: one that can open a single email and let you read it, one that would let you compose an email, one that would let you list your emails etc. - and of course a shared component that takes care of communicating with the server etc. This is actually what we already do as programmers - but the components are only shared within a single application. In this case, they should be shared by the whole OS. The problem comes when you update your email reader component, then you need to update the shared component as well to make it work, and all the other email-related components that use the shared component. And probably some shared library that is also used by your web browser, so now you're updating your web browser, and so on. My point is, sometimes this seemingly never ends. This is actually a very big problem in Linux, and a reason why you often can't have the latest version of your favorite application unless you upgrade to a newer Linux distribution, because all the core packages are so tightly coupled it's easier to just update the whole thing in one go. For that reason, people are switching to Flatpak, Snap and similar alternative package managers that basically gives each application a sandbox with its own copies of all the shared libraries it needs. That way you lose quite a bit of storage space but you can update each application independently. So MercuryOS would be taking a step or two backwards on this front.