A few years ago, I suggested adding a new interaction to Figma. If your text cursor was on a misspelled word (anywhere inside, or the edges), you could press Tab to quickly accept the suggested correction, without even seeing it:
Independently, Google Docs approached it from a slightly different angle, but landing on a similar interaction – in their version there’s a small visual callout, although you can still press Tab (and then Enter) to accept the suggestion:
I know the Tab key has a lot of jobs – from indenting bullet points to jumping through GUI elements – but in this context this new addition doesn’t seem to be in conflict.
(Should I write a long photoessay about the Tab key, similar to the ones I wrote for Return/Enter and Fn keys?)
Since we added it, I’ve really loved how it feels. From various typeaheads and autocompletes elsewhere, Tab has a strong “forward movement” energy so it makes conceptual sense, and it’s just really fun to go around and quickly fix your writing this way.
I think a lot about how to make keyboard interactions feel superpower-y: a good keyboard shortcut on a large key, a tight interaction, a blink-of-an-eye velocity – something that’s eminently designed to lodge itself in your motor memory as quickly as possible, as it builds on top of prior motor memory. I’m biased, of course, but I like the “no scope” Figma version more, and it has that feeling to me.
I just stumbled upon a nice little power-user innovation in Chrome’s Web Inspector.
In Safari, and previously in Chrome, when editing CSS properties, you’d get a usual editing typeahead for the property name, and then the same on the other side for the property value.
In newer versions of Chrome, the typeahead menu works as before on the right side. However, the menu on the left side also includes the right side.
I think this is really clever in this context – not just to speed you up, but also to aid understanding. Just like the inert mouse up and down in the previous post could serve as a safe “peek” into the values, this new interaction can quickly allow you to explore the CSS space if you are curious, or if you only lightly remember part of the name, or even just one of the values.
This blog is authored in Apple Notes, and some time ago Notes added quick linking via typing >>, and that has a similar effect: The interactions are so nimble and precise that it is very easy to link to something, but a nice side effect is that it also feels very welcoming just to type a few letters to remind yourself of a title of an article, and then cancel out.
The downside of the Chrome change is, well, more stuff matching, but I think the audience for this UI is going to be okay with that.
Over the past few years, I’ve found myself relying on TextEdit more as every other app has grown more complicated, adding cloud uploads, collaborative editing, and now generative A.I. TextEdit is not connected to the internet, like Google Docs. It is not part of a larger suite of workplace software, like Microsoft Word. You can write in TextEdit, and you can format your writing with a bare minimum of fonts and styling. […]
I trust in TextEdit. It doesn’t redesign its interface without warning, the way Spotify does; it doesn’t hawk new features, and it doesn’t demand I update the app every other week, as Google Chrome does.
But I get the feeling that Chayka would be better served switching from TextEdit to Apple Notes for most of these things he’s creating. Saving a whole pile of notes to yourself as text files on your desktop, with no organization into sub-folders, isn’t wrong. The whole point of “just put it on the desktop” is to absolve yourself of thinking about where to file something properly. That’s friction, and if you face a bit of friction every time you want to jot something down, it increases the likelihood that you won’t jot it down because you didn’t want to deal with the friction.
Part of me agrees with this vehemently – for casual text wrangling, Notes is by far the best iteration of what both the old Stickies app and TextEdit attempted.
But Notes are still evolving. The UI keeps changing. I’ve had a note shared by a friend hanging alongside my own notes for years, without me asking for it. I remember the moment when tags were introduced, and suddenly copy/paste from Slack started populating things in the sidebar. Then there was this scary asterisked dialog that slid so well into planned obsolescence worries that it felt like a self-own:
And the attendant warning, ostensibly well-intentioned, adorned my notes for months, just because I had an older Mac Mini I barely touch doing menial things in a dusty closet:
On top of that, the last version of Apple Notes on my macOS occasionally breaks copy/paste (!), which led to some writing loss on my part. (If you cut from one note intending to paste in another, and realize nothing was saved in the clipboard, you lost the text forever.)
These are not show stoppers. But they too are friction that has to be juxtaposed with what Gruber lists in his essay. They’re also friction of the unexpected, new, stochastic flavour. TextEdit’s challenges, on the other hand, are known knowns. In this context, TextEdit is in that rare – and maybe increasingly treasured – place where it no longer gets updates, but it doesn’t feel abandoned, or falling apart, or at the risk of outright cancellation. (I think on the inside of tech companies this is called being “maintenanced” – not actually staffed to be improved, but still eligible for breaking bug fixes and security updates.)
We need to normalize declaring software as finished. Not everything needs continuous updates to function. In fact, a minority of software needs this. Most software works as it is written. The code does not run out of date. I want more projects that are actually just finished, without the need to be continuously mutated and complexified ad infinitum.
Personally I would be very happy to live in a postcapitalist world where it was 100% FINE that desktop operating systems had “stopped evolving” because they were good enough to meet basically everyones’ needs, and there was no stock price to crash from an old monopoly having clawed its way to the top with nowhere else to go. “Let [certain] software be finished” has always felt to me like oblique pining for humanity to outgrow our current political-economic system.
The fact that in the 10+ years I’ve been using it, there’s only been a single major overhaul update is a feature, not a bug to me.
I have seen this sentiment grow in recent years, as AI is seemingly shoved into every crevice of everything whether or not it even had crevices to begin with. Liquid Glass on the Mac side and incessant ads plus bugs on the Windows side add to the malaise.
But I’ve also been in technology so long that even outside of tensions of capitalism, it’s hard for me to imagine software not changing. Code does run out of date even if you try very hard. So I don’t know yet how to square all this.
Bear is not finished/“maintenanced,” but it seems to not be changing the same way some other software is changing, either. I’m excited reading its blog – even if there are features or updates that do not pertain to me, they don’t bother me, and make me excited for others benefitting. Its innovation feels considered, not reckless.
In a week I’m praising products I didn’t expect to praise, I feel similarly about Lightroom Classic. When Adobe in 2017 forked Lightroom Classic out of the newly-refreshed Lightroom, a lot of us got worried about the “Classic” tag having “dead man’s walking” connotations. But nine years later, and Lightroom Classic is still being lightly updated with fixes, camera presets, and – occasionally – feature changes that largely feel welcome. Lightroom Classic appears, to once again use industry jargon, “stable.”
Maybe the answers are somewhere in this post: celebrate and fund “maintenanced” apps, fork apps into “stable” and “modern” paths, or encourage and practice slow, considered growth. I bet there are other approaches and altogether new ideas to try, too. (There used to be a tradition, when software was physical, to list all the new stuff at the back of the box. What if we started writing out the things we didn’t add?) But I like at least talking about it to begin with. There are apps in my life I want to feel like TextEdit, there are apps that I want to feel like Notes, and there are ones I’m happy to put on the cutting edge/beta/canary path, where bugs are a promise, and motor memory a distant dream.
I yearn for a software ecosystem that allows all of these types of apps to blossom.
This is of course competence porn, made even better by the dry Polish lektor-like delivery. But it’s also a puzzle. I watched this so many times. There are so many great UI lessons in here:
You can absolutely put graphics inside a textbox
Sparklines rule
Slider is still the best UI element in history
Previews don’t have to feel like training wheels
Synchronizing sounds to visuals is so powerful (see: turn signals on a car dashboard)
I found myself thinking about how you’d design something that feels real-time, but also needs to be resilient against typos, and has a distinct “commit” moment (which is what I think those yellow flashes are); some of the best moments in the video are the quick fixes that aren’t narrated.
Ultimately, this also shows how powerful and underrated plain text can be as interface. It’s a bit like designing straight in CSS, operating at the weird intersection of motor memory, creativity, and abstraction. (Is there a CSS editor that feels more like this?)
On top of all of this, the act of building the track this way is also how the finished track would sound like. Amazing stuff.
Remember all these jokes that went like this?
[God looking at a pug dog for the first time] What the hell did you humans do with my bad ass wolf I gave you?
Imagine sitting the creators of the typewriter in front of YouTube and having them watch this video.
