Original Title: Introducing Mercury OS
Original Link: https://uxdesign.cc/introducing-mercury-os-f4de45a04289
Original Author: Jason Yuan
Translator: Nexmoe, first published on Nexmoe's xLog
Mercury OS is an operating system imagined and envisioned based on human-centered design principles.
Nine months ago, I began to try to create a new way of human-computer interaction using a single metaphor — Mercury.
Mercury, the flowing silver metallic element.
Mercury, the deity in Roman mythology that connects two worlds.
Mercury, the planet closest to the sun.
Although these different versions of Mercury have little to do with interaction design, they perfectly encapsulate the feeling I hope for in computing experiences. I want the experience to feel fluid. I want to create something that users can navigate through without resistance or boundaries. I want to bring people closer to their guiding star with speed and elegance.
In the following months, I digested a large amount of human-computer interaction literature while repeatedly switching between different prototypes. I experimented with concepts ranging from a "smart finger ring" that serves as a universal remote to pondering whether a rubber band could serve as an interface. Despite how illogical these ideas may seem, they sparked a lot of exploratory thinking, yet nothing seemed to capture the feeling of Mercury that I described in my poetic declaration.
The breakthrough came when I realized I had been asking the wrong questions. I spent months trying to invent new ways to navigate existing systems — but what if these systems had fundamental flaws? What if achieving the Mercury experience required fundamentally reinventing everything I had taken for granted?
Why?#
In my article titled "The Desktop Metaphor Must Die," I described some fundamental issues with the desktop metaphor and application sandboxing. My personal investment in the future of computing goes far beyond a mere desire for better experiences.
First, Mercury's design is intended to be inclusive of people with limited executive function and cognitive load. Individuals like me, who live on the autism spectrum or have attention deficit hyperactivity disorder and other neurodivergent conditions, often find ourselves overwhelmed by the predictable flood of sensory information in traditional operating systems.
People like me.
Translator's Note: In computing, the desktop metaphor is an interface metaphor, a set of unified concepts used in graphical user interfaces to make it easier for users to interact with computers. The desktop metaphor treats the computer display as the user's desktop, where objects like documents and folders can be placed. Further reading: https://www.woshipm.com/ucd/1269800.html
Research shows that individuals with limited executive function find it harder to get things done when not in a flow state. We are also more susceptible to distractions and resistance during processes. These distractions include the obvious (notifications, alerts, etc.) and the less obvious (Photoshop prompting you to name a file and choose a save location). Unfortunately, this resistance is accepted as an inevitable part of everyday computing, which is truly unfortunate.
For those who already struggle to control where their attention goes, the context switching required to handle these distractions can be a very draining experience, potentially taking up to 15 minutes. In contrast, neurotypical individuals can typically switch contexts in about 10 seconds.
This is why the inherent patterns of application and window environments are particularly frustrating for me. While I understand that for some, the desktop metaphor hasn't deteriorated to the point of needing any fixes (Where's the data? they ask), I stand by my words and my truth.
At this point, let's delve into what Mercury actually is.
Mercury Is#
Fluid#
Rather than requiring people to modify their thoughts and actions around arbitrary application sandboxes, Mercury responds more fluidly to users' intentions, alleviating the risks of process resistance that come with multitasking.
Focused#
The clutter that is commonplace in today's operating systems can be overwhelming for many, especially for those sensitive to stimuli. Mercury respects limited bandwidth and attention, rejecting the idea of "notification-driven engagement." Information is not pushed to users unless they explicitly request it. Mercury's intent and contextual architecture protect users from the intrusion of unintentional information consumption.
Familiar#
Mercury introduces new ideas and metaphors through familiar interaction patterns on existing devices: Mercury is designed for multi-touch tablets that support keyboards — a category often seen as an awkward hybrid, straddling two worlds. Mercury blends the playfulness of multi-touch with the efficiency brought by keyboards.
Mercury reimagines the operating system as a fluid experience driven by human intention.
This Is Mercury#
Structure#
At an atomic level, Mercury consists of modules. Modules are combinations of content and actions assembled based on user intent.
Users can create new modules next to the starting module. A row of horizontal modules is called a flow. Even if there is only one module in the entire row, it is still considered a flow.
Spaces are contextual groupings of different flows needed to achieve an overall intent. For example, if a user declares a "Review Inbox" space, Mercury will automatically populate that space with flows containing unread messages that the user needs to read to fulfill the intent of reviewing the inbox.
Every time a user declares an intent from an empty state, a space is generated, typically named after the stated intent. Almost all interactions in Mercury occur within spaces.
Modules#
Modules are the cornerstone of Mercury. They are defined using combinations of nouns (items), verbs (actions), and modifiers.
System-generated modules adopt a noun-verb construct, as it is assumed that the content of the module will determine the action the user intends to take (if any).
User-defined modules can certainly follow the aforementioned noun-verb model. However, verb-noun constructs are also supported, allowing users to request modules in their daily interactions. This use case is particularly common when using voice input.
Note that if a definition does not specify a noun (e.g., "Play..."), Mercury will not generate a module. Instead, it will suggest different nouns to complete the definition.
The Power of the Locus (Action Bar)#
Users can redefine modules at any time through the module's action bar. The action bar combines the power of command-line interfaces, the convenience of natural language processing, and the discoverability of graphical user interfaces.
The action bar recognizes complete sentences as actions and can even execute tasks involving multiple steps. Simply activate the action bar by clicking or toggling the command key. As you type, the action bar provides context-specific suggestions to help you discover its capabilities.
Standardized Shortcuts#
In traditional operating systems, shortcuts are hard to remember and difficult to find. Additionally, different applications may require different shortcuts to perform the same function.
In Mercury, shortcuts are standardized through the action bar. To view available shortcuts, simply hold down the command key. While holding the command key, start typing to progressively filter the list of actions until you find the desired action.
Responsive Modules#
Contextual modifiers (such as conditional statements) can help automatically execute more nuanced tasks on demand without leaving the current context.
Coexisting Modules#
If a user chooses to create a mirror, a module can exist simultaneously in multiple flows and spaces. Mirrors are fundamental to the Mercury architecture, as they ensure that all items and actions are immediately accessible, regardless of the space (or context) the user is currently in. For example, a mirror of an email from your mentor can exist simultaneously in your inbox space and your course space.
Flow#
In traditional application-driven operating systems, functions are isolated within different applications. Switching from one application to another creates friction, pulling you out of the flow state and distracting you from your original intent.
Mercury is designed to help you enter and maintain a flow state. If you want to perform an action without touching the current module, you can generate a new module by clicking the plus bubble next to the current module or pressing the Tab key on the keyboard.
You can also use continuous gesture input to generate modules without diverting your attention from what you are focused on. Just highlight a piece of text to get started. An empty module with contextual suggestions will greet you where your finger leaves off, allowing you to maintain momentum.
Space#
Everything you do in Mercury is organized within spaces. Spaces can be created from scratch, built on blueprints (template spaces for common contexts and workflows), or generated by Mercury for you.
Swiping up from the main screen reveals your journey through time and space. What did you do last Thursday? You can find it on the timeline. Want to reflect on how much time you spent fermenting games on Twitter this weekend? Let's check the timeline.
Entering a space from the timeline feels like zooming into a different dimension. The interface fades from view so you can focus on entering the flow. While in a space, you will not receive any notifications unless you explicitly indicate your availability in the space rules. There are no barriers between you and your intent.
Within a space, flows represent the necessary steps to achieve the intent of the space. For example, the intent of "Review Inbox" includes all unread emails from different unrelated services and aggregated direct messages. In traditional operating systems, achieving the same intent of "Review Inbox" would require opening multiple browser tabs or applications.
By isolating services from their broader ecosystems, Mercury helps prevent distractions and potential pathways for unintentional content consumption.
Your Space, Your Rules#
Pinch gestures can display an overview of each module within the space, along with the rules and collaborators that define how the space is generated.
AI Collaborators#
In a hypothetical future without applications, businesses could continue to provide services through AI assistants. Adding these assistants to a space would add service-specific functionalities to the modules in that space. For example, while searching for the perfect sneakers, you could enlist the help of several virtual shopping assistants.
You can request collaborators to automatically generate modules or limit their activities based on context. Collaborators will not have access to any information outside the modules that their input directly affects. The sandboxing of collaborators within the space protects your privacy while retaining intentional access to services you may rely on.
Coming Together#
Plan a trip to Las Vegas. Watch BLACKPINK's comeback performance with your fellow fans. Invite others to join your space to share documents, images, and collaborate in real-time.
Design Guidelines#
Mercury's visual identity merges the rational structure of Western modernist design with the East Asian instinct for seeking tranquility amidst chaos.
Kiri#
Kiri (霧), the Japanese word for "fog," is the name of Mercury's visual embodiment. Kiri takes a cautious approach to contrast — bringing clarity only when necessary while cloaking irrelevant noise beneath a soft haze.
Composition#
Movement is used throughout Mercury to maintain spatial consistency and guide users' attention from one module to the next. Mercury's composition is inspired by the Taoist principle of effortless action; the interface responds to human input without resistance, then enters a state of still balance.
Typography#
Mercury emphasizes information hierarchy and spatial consistency through contrasts in font size. The world of Mercury is set exclusively in the Söhne typeface from Klim Type Foundry, a font family that exudes elegance and softness while not compromising on clarity.
Where the Light Is#
As night falls, Kiri retreats into the shadows. The backlighting of modules is inspired by the ethereal glow of moonlight, radiating a sublime brilliance.
What’s Next?#
Throughout this nine-month process, I have become acutely aware of how foolish I was to believe I could do this alone. This particular path of inquiry is so nebulous, so reliant on abstract ideas and metaphors, that I found myself spending weeks down rabbit holes, lost in their elusive depths.
In fact, almost all key moments of Mercury have been the product of incorporating the essence of others, gaining feedback, or collaborating. The feeling of drawing ideas from numerous collaborators and working toward a shared goal is addictive; all I can think about is how much I want to spend the rest of my life doing this.
That is exactly what I intend to do.
I will complete my Bachelor of Fine Arts at RISD, with less than a week left, and my current plan is to head to the West Coast in search of exponential collaborators and network thinkers who are passionate about exploring this field. If I can't find a team, I plan to build one myself.
I still have many questions to answer, many ambiguities to explore, and many gaps to revisit. The universal undo/redo function is so important, yet strangely absent in almost all operating systems today (shake to undo is not a viable replacement).
So what about the screen as a whole? Is the future of computing really just sliding fingers across a glass pane?
I choose not to resist the overwhelming pull of curiosity any longer, but to commit to a lifetime of networked thinking, questioning, and causing trouble. I hope I won't be alone.
So, what’s next? I don’t know.
All I know is that I must keep moving forward.
Sincerely.