Nexmoe

Nexmoe

一个开发者。关于勇敢与热爱,互联网/创造/赛博朋克
twitter
github

[Translation] Introduction to Mercury OS

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 brand 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 simultaneously digested a vast amount of human-computer interaction literature and switched back and forth between different prototypes. I experimented with concepts ranging from a "smart finger ring" that serves as a universal remote control to pondering whether a rubber band could serve as an interface. Despite how illogical such things may seem, they sparked so many exploratory ideas, yet nothing seemed to capture the feeling of Mercury that I described in my poetic declaration.

Chaos, maddening. The sketch in the lower left was drawn by my friend Marisa Lu during an efficient call where we explored the mental model of "flow."

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 a better experience.

First, Mercury's design is meant to be inclusive of people with limited executive function and cognitive load. People like me, who live on the autism spectrum, have attention deficit hyperactivity disorder, and other neurological differences, 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 that 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 document folders can be placed. Further reading: https://www.woshipm.com/ucd/1269800.html

Desktop or trash can? You decide. (Image credit to my dear friend Lindo)

Research shows that people 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 the process. 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 an incredibly draining experience, 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.

Why is this normal? Why should I expend limited cognitive energy to deal with this?

At this point, let's delve into what Mercury really 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 process resistance that comes 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 intentionally 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#

image

Structure#

At an atomic level, Mercury consists of modules. Modules are combinations of content and actions assembled based on user intent.

image

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 still qualifies.

image

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.

image

Each 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#

image

Modules are the cornerstone of Mercury. They are defined using a combination 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 dictate the action the user intends to take (if any).

image

User-defined modules can certainly follow the aforementioned noun-verb model. However, verb-noun constructs are also supported so that users can request modules in everyday language. This use case is particularly common when using voice input.

Note that if the 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.

image

The Power of the Locus (Action Bar)#

Users can redefine modules at any time through the action bar of the module. 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 functionalities.

Users can use commas to denote arrays.

Standardized Shortcuts#

In traditional operating systems, shortcuts are hard to remember and difficult to find. Additionally, different applications may require different shortcuts to accomplish 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.

1_e6RutoXwIsrFbEeVfq5kkQ

Responsive Modules#

Contextual modifiers (such as conditional statements) can help automatically execute more nuanced tasks on demand without leaving the current context.

image

Coexisting Modules#

If users choose to create mirrors, modules can exist simultaneously in multiple flows and spaces. Mirrors are foundational 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, functionalities 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 aims 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 your keyboard.

An empty module will be filled with contextual actions and items that Mercury thinks you might need.

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.

1_cK82E0Z66wwZdD5MDZkkag


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.

1_YnMpv3qx_NCPXy3He5myWg

Entering a space from the timeline feels like zooming into a different dimension. The interface fades from view, allowing you to focus on entering the flow. While in a space, you will not receive any notifications unless you intentionally indicate your availability within the space's rules. There are no barriers between you and your intent.

1_II22jDqVklsjxIchhy1i7Q

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 various 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.

1__oheIKgYWWX7HG8wggl0RQ

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.

1_mYxlKHAS8lB_owyl3E8SEw

image

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.

image

You can request collaborators to automatically generate modules or limit their activities based on context. Collaborators will not have access to any information outside of the modules directly affected by their input. 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 show with your fellow fans. Invite others to join your space to share documents, images, and collaborate in real-time.

You can even allow your secretary to add and remove emails from your inbox without sharing a password.

Design Principles#

Mercury's visual identity merges the rational structure of Western modernist design with the East Asian instinct for seeking tranquility amid 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 shrouding irrelevant noise in a soft mist.

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 and then settles into 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 making no compromises on clarity.

Where the Light Is#

As night falls, Kiri retreats into the shadows. The backlighting of the modules, inspired by the ethereal glow of moonlight, radiates a sublime brilliance.

You know I would never miss an opportunity to design a dark mode.


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 result of incorporating the insights of others, obtaining feedback, or collaborating. Gaining ideas from numerous collaborators and working towards a shared goal is intoxicating; I am consumed with how much I want to dedicate the rest of my life to this endeavor.

That is precisely what I intend to do.

I will complete my Bachelor of Fine Arts degree at RISD, with less than a week remaining, 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 cannot find a team, I plan to build one myself.

I still have many questions to answer, much ambiguity to explore, and many gaps to revisit. The universal undo/redo functionality is so crucial, yet oddly absent in almost all operating systems today (shake to undo is not a viable replacement).

Nor am I shamelessly plagiarizing Raskin's Canon Cat keyboard.

So what about the screen as a whole? Is the future of computing really just sliding fingers across a glass pane?

I choose to no longer resist the overwhelming pull of curiosity 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.

What I do know is that I must keep moving forward.

Sincerely.

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.