My Authors
Read all threads
I actually want to be really clear about why I'm critical of this design. It actually doesn't have anything to do with Roam, interestingly enough. Quite the opposite.
For various fairly obvious reasons, I am extremely fascinated by the development of alternative interface experiences. Which is just a fancy way of saying "new ways to do the crap you do every day."
Mercury, while it looks extremely attractive and is minimalist and clean in a way that appeals to my design aesthetic, is clearly built by someone who has never actually had to get work done. And that's a real problem.
When you postulate a kind of interface and environment which deliberately throws aside the fact that tools already exist and are in common use, and people need to use them in order to get real work done, you set your interface up for failure.
When you design a system which clearly ignores 40 years of design work and design experience which went before it, without a nod, without a whisper, without reflecting that it exists, you set yourself up for the expectation of failure.
The idea of "service as application," which is really the core of Mercury, is in many ways a recapitulation of the original UNIX idea of "tiny utilities that do one job perfectly and are tied together by glue scripting".
It's just that the glue is very pretty and you don't even get a command line that can go around it, the command line is limited to it.
As much as I love UNIX, at both a professional and a personal level, the abstracted UNIX metaphor for interface got tossed away and burned for the most part a long time ago. The Window metaphor largely supplanted it.
There's a good reason for that: it works better. Not in every context nor for every user, but so much so that DOS, CPM, and their whole cohort were either destroyed or buried under a new visual language deep enough to be serviceable.
It's not a shock that productivity spiked upwards among information workers. Thousands were more capable of being information workers than had been before.
Part of the reason was that larger, more coherent applications could be created to deal with larger problems that we had been solving piecemeal with smaller, aggregate tools.
While those individual portions might have been more effective and more efficient at a code and singular task level, they were less so for solving broader, more complex problems. Everyday problems.
In the decades since, we developed application ecosystems because they work. We have large monolithic applications because we have problems which don't have identifiable and isolatable micro-flows.
We also have monolithic application ecosystems because there are 10,000 ways to do information handoff between sub-problems and every developer will choose to do something subtly different making interoperability a nightmare.
But those are all criticisms at a metalevel. There are two major things that jumped out at me while I read through the entire presentation.
Firstly, the example was given of "why does Photoshop ask you for both the name of the file and the place to save it?" In the context of interfaces being too overwhelming in the number of questions they present.
It asks you both because it needs to do both. It asks you both because both of those pieces of information are important to doing the job you're asking it to do. That's the task. The tool already exists.
And yes, I know, the whole deal is to somehow magically question whether or not the entire abstraction of files and file spaces is somehow inherently inferior to implicit clustering by temporal and task attachment.
Remember how I said there was decades of user interface design that were hand-waved by the writer? This is part of it. It's not like this is a new line of questioning.
The problem is that the answer that came out was, "no, temporal and task abstraction is not sufficient for day-to-day operations for most users who have a job to do." And adding the orthogonal axes of information useful to people doing real jobs largely get you right back.
(The history of semantic file systems is a rough and painful space, not least of which for some of us who walked part of it. en.wikipedia.org/wiki/Semantic_… )
Second (I had to get there eventually), Mercury comes across as an absolute nightmare for anyone with a physical disability, particularly disabilities which affect vision and fine coordination.
In attempting to strip out "distraction," the designer structures an environment which is almost entirely devoted to visual feedback.
Yes, there are nods to verbal and conversational interface, but the entirety is built around a visually responsive screen environment with navigation almost entirely spatial.
Even for people with modest visual impairment, that is going to be problematic. For people with severe visual impairment, they are going to find that experience even more bewildering than the current Windowed metaphor.
At least as things stand now, the interface is relatively predictable and things don't move around from moment to moment. Windows open in relationally predictable ways.
Now imagine that you have a motor impairment. Fine manipulation is a challenge. Extending fingers and sweeping them across screens, particularly those on the opposite side of the keyboard which require even greater reach, is daunting.
A mouse gives someone like that a fighting chance, and while Mercury could be navigated with a mouse as presented, it is very clearly described as wanting a multitouch visual interface.
A mouse at least gives you a fighting chance. Imagine trying to navigate Mercury with a mouth stick. Or an eye tracker. Or anything but 10 perfectly flexible, responsive fingers.
I am and have been a critic of the Windowed metaphor since Microsoft Windows was released, and I have helped a lot of people come to grips with various impairments that keep them from "doing the job" on whatever platform they're on.
I shudder to imagine trying to get an assistive screen reader to work with Mercury or helping someone with a gaze tracker and a couple of buttons try to get the most out of it. Windows and Mac suck, but there's a fighting chance.
Now imagine I wrote another couple of thousand words about throwing away all the applications that currently work for people's jobs, and all the rest of the practical objections.
So now, @RoamResearch . One of the great things about Roam is that it doesn't require a paradigm shift in tools. It uses every tool you already have in your hand. Web browser? Cell phone? Desktop? URLs? Language?
In a sense, it is the anti-Mercury. Roam forms itself around your way of thinking, your way of categorizing, your way of linking, using the tools you already have at hand and not demanding that you change them for its sake.
That's a big deal. For some people, that's a massive deal. Rather than trimming away ways to do things like Mercury focuses on, Roam augments the ways you can do things. There are always more ways. You can choose which ones you like that work for you.
If you have problems with cognitive overload, you can use a very spare number of tags and links, just enough so that your recall, your information, is where you can find it and no more.
If you need/want a very densely connected network of notes and references, knock yourself out. Tag aggressively. Tag frequently. Make use of the networks of association to walk those chains and really load that cognitive associative imagination.
It doesn't require physical dexterity. One button and the ability to point will suffice. A screen reader has no problem dealing with anything on the screen (except for graphs, and that makes sense).
I like it because it lets me get the job done. It doesn't let me get every job done because I have some tools that are better for tasks than Roam is. It will never be Photoshop. It won't be graphviz. It's kind of lousy to write in.
But that's okay because I have monolithic applications that can do those other things I need to do, and Roam lets me point at them, reference them, and use them for what they're good at.
A lot of people have a lot of ambition. I'm in favor of ambition. But the same people who embrace visionary ambition often forget that we have one thing that comes first and foremost in every context:
"Do the damn job."
That's true whether you're a grad student with no actual knowledge of the real world, a longtime professional writer, or whatever you happen to be today.
You need to do the damn job. Anything that gets in the way of that? Anything that doesn't let you use the tools that you have to do it? That's not something that you will keep on your toolbelt.
For your convenience: @threadreaderapp unroll
For the EXTRA curious, check out Zeitgeist for "systems kind of like the interesting bits of Mercury based on a tonne of extant activity that no one uses yet."

en.wikipedia.org/wiki/Zeitgeist…
Missing some Tweet in this thread? You can try to force a refresh.

Enjoying this thread?

Keep Current with Weltschmerz Incarnate

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!