I call it “Ghost Cut”, and it works like this: pressing Ctrl+X fades the selected text and makes it inert—you can’t click on the cut text and the cursor just kind of leaps over it, but it is still present in the document. Nothing is placed in the clipboard at this point and there is nothing to undo. If you decide you don’t want to paste then hitting Escape will restore the text to its active editable state.
I do not think this is a good idea. It seems like McGugan proposes somewhat arbitrary reasons that cut and paste are “broken,” and to me the proposal fails even within his own framework: for example, it still doesn’t avoid the reflow, but moves it to the other side, making paste feel unstable (the included JavaScript playground feels disorienting to use). I think it also is at odds with the editor’s own about page, which talks about distraction and simplicity – and yet, what’s introduced here is a host of complex new things: a new visual state for cut text (that looks like AI autocomplete), some new logic to avoid moving into the cut text (which will also prevent easy selection adjustments), likely new confusion around undo, and a necessary new Esc gesture to get rid of a cut you decided not to pursue.
But! There is something interesting in seeing this ghost text, and specific critique aside, it is fun to see experiments like these, with interactive explainers, poking at long-established interactions. Just yesterday, a second one appeared: an interesting new way to extend selection upwards – similar to double and triple clicking on text, but via the keyboard. This is the power of prototyping: sometimes seeing an idea you disagree with is the only thing that can unlock a different solution in your head.
Let’s go back to cut and paste, though. You will notice that what’s listed as a precedent is not File Explorer, but Excel. It also doesn’t immediately remove selected cells on cut, but leave them in a temporary “possibly getting moved or removed” state first, only to have them disappear after paste:
Why is that? I believe out of a similar principle, but a distinct reason that File Explorer too opts to leave a cut ghost behind. The stakes are higher in a different sense: cells refer to other cells. Were the removed cells to disappear immediately, you might witness the rest of the spreadsheet error out or show zeroes, as its formulas start pointing to emptiness.
And it’s a good principle to generally avoid frightening your users.
Here’s an example from Numbers, which doesn’t do ghosting, making cut a bad choice to do a simple move, as it doesn’t even recover after paste:
I don’t think anyone particularly enjoys typesetting in monospace.
Regular text is okay – at least as okay as it can be:
Right aligning is also fine, as long as you don’t mind counting spaces, but centering already gets tricky, as you don’t have a half space to make things truly even:
And full justification is where things get particularly weird. The spaces are just too large, and cannot be distributed evenly, creating a really unpleasant feeling:
The solution used in typesetting elsewhere is hyphenation, but in monospace hyphenation also feels unpleasant, with the hyphens drawing too much attention to themselves (and subsequently messing up copy and paste):
This is why you don’t see full justification in text files very often.
But there is one more option. You can rewrite the text to choose only words that precisely add up to the line length to avoid any double spaces.
It’s astonishing, as it goes like this on for 17,000 more words, each right margin perfectly ending on a letter, no twin spaces in sight.
The author lightly covers in the FAQ at the bottom:
What program did you use to justify the text?
None. I just chose words carefully so that everything lined up on the right hand side. Everything was done with an ASCII editor.
I’m sharing this mostly as a curiosity; some rewrites for physical books are par the course to avoid widows and orphans, but you don’t see them as much in onscreen writing.
At the same time, who among us didn’t nod in recognition at least, having once spent hours massaging a button UI string or a tooltip just to get it to fit under the certain width in a densely packed interface?
I have used vim since around 2000. I have written five books, a PhD thesis, a few dozen papers and over 150 articles with it. At this point, my higher brain functions are not engaged at all when I use a bunch of common vim commands, they just happen. Documents I wrote with anything else have random :w in the middle.
Chisnall goes on to talk about one specific vim feature:
Persistent undo is one of my favourite features of vim. […]
I don’t often need the persistent undo. But on the few occasions when I have needed it, it’s been invaluable: ooops, I deleted something from this file, maybe last week and one reboot ago, what was it? Undo until I find it, copy it, paste it into the current version. Or, a bit more commonly: I had this working, then I tidied it up ready to commit, now it isn’t working, what did I do?
Vim has kept this working across major version upgrades over a period of about 20 years. I don’t even think about it, it’s just part of Raskin’s First Law: A program may not harm a user’s data or, through inaction, allow a user’s data to come to harm. If vim or the computer crash, or if I close a file and come back to it six months later, my undo history is still there.
So I tried NeoVim when it was quite new. Vim that you are familiar with, but better? Great!
The first thing I noticed in NeoVim was that undo didn’t work. I tried opening the file in vim and undo didn’t work there either.
Neovim had changed the format of the undo files. It hadn’t upgraded the old one. It hadn’t used a different name for its undo files. It had just noticed the existence of a vim undo file, deleted it (losing all of the data in it) and replaced it with one that vim couldn’t read.
I raised an issue about this and was told that the persistent undo format was unstable and users should not rely on data being preserved in a feature explicitly called persistent undo. It had changed once and would probably change again.
And that ended my experience with NeoVim. The authors showed immediately that they absolutely could not be trusted with any of my data. Breaking persistent undo is something I could forgive as a bug, but the attitude that just because something is a persistent file on your filesystem that contains data that you might want is no reason for their program not to delete it meant they had no concept of a duty of care to their users.
I liked this post (which I quoted almost in its entirety), because it covers a few important things:
I have never heard of the persistent undo like that, and it seems kind of amazing.
People do remember when software loses their hard work or disrespects them.
I can see how “It had changed once and would probably change again” can be such a powerful feeling.
I also loved it for the appearance of Raskin’s First Law. Jef Raskin, of Macintosh and Canon Cat fame, put together the three laws in his 2000 book The Humane Interface, and they go as follows:
A computer shall not harm your work or, through inaction, allow your work to come to harm.
A computer shall not waste your time or require you to do more work than is strictly necessary.
An interface is humane if it is responsive to human needs and considerate of human frailties.
It was a very important and formative book for me to encounter as a young designer. I have no idea how these laws haven’t made it to Unsung before today.
If you haven’t played Kern Type yet, you’re in for a treat – released by Mark MacKay in 2011, it’s a delightful browser game that teaches you the art and the math of text kerning:
If you have played it, you’re still in for a treat, as MacKay under the Method of Action label released a few similar games since:
They’re interesting not just because you can explore the feel of visual, typographical, and color craft by play – but also because they’re also really nicely made explainers. Here, you can learn things, but also learn about making things that teach things.
For example, I liked the thoughtful onboarding, animations, and sound design of The Boolean Game, the keyboard navigation in Kern Type, and this general idea present in a few games that it’s fun to learn by fixing slightly broken things, rather than starting from scratch.
As far as I can tell, MacKay also occasionally revisits the older games, so Kern Type today might feel much better than when you played it last. MacKay also vibecoded a quick aspect ratio game, and is thinking of a new game to teach text editing, which excites me to no end.
I added a new tag to Unsung, #explainer, to cover explainers and playgrounds like these.
The most common use of double-clicking is as a shortcut way to perform an action. For example, clicking twice on an icon is a faster way to open it than clicking once to select it, then choosing Open from the File menu; clicking twice on a word to select it is faster than dragging through it.
I knew that double click an icon was a shortcut to the first action (typically Open), but I never really thought of double-clicking a word as a faster way to drag across to select it – even though, in hindsight, it makes perfect sense.
Another vintage thing I learned of recently from a coworker is this, also covered in the 1987 HIG:
If the user begins a double-click sequence, but then drags the mouse between the mouse- down and the mouse-up of the second click, the selection becomes a range of words rather than a single word.
This doesn’t feel (to me) like a very pleasant gesture to perform repeatedly, but what feels nice about it is that it automatically snaps the selection to the endings of the words:
Part of me would prefer this to be the default behaviour when selecting more than 3 words, or so, so you could be less precise.
Anyway. The double clicking to perform default action applies to a lot of lists of things. Here are some examples from Scrivener, Word, and Lightroom – you can double click on each of these items to proceed, without having to select and click the button:
But sometimes the creators of such dialogs forget. Here’s Screen Sharing in MacOS, and a notification in Chrome where only the slow path is available – double clicking on items doesn’t do anything:
The tricky part about not being a good citizen of a shared user interface is that those omissions aren’t just local to your app – they can ruin the gesture in other places, as people’s fingers learn to distrust it in not just your app, but in general.
I praised the note-taking app Bear before for its memory; the app would always remember your last-visited note and the precise place within it, even if it had every right to forget it.
But there is a general problem here: memory that kicks in when not expected can be frustrating, as you have to undo its results and “reset to normal.” For Bear that’s not a problem, though, right? The whole iOS has a nice “tap near the top to scroll to the top” gesture that would work here as well, making it easy to recover if you return to the note where you last happened to type.
Except, with any writing app, the very bottom is as valid of a destination as the very top.
Bear designers understood it and tried to solve it in a new way, by adding two gestures: a two-finger swipe up takes you to the very top, and a two-finger swipe down to the very bottom:
It doesn’t quite work as well as I hoped – for some reason, it scrolls way too far down, and does feel a bit sticky mechanically.
It’s also, like any complex gesture, not very discoverable. But here’s where Bear tries to help, by… adding even more gestures atop these two. There is a two-finger swipe left or right for jumping back and forward in history…
…and even a two-finger tap to reveal a navigation menu.
That last one feels like overkill to me, but there is something interesting about the app building an entire little universe of compatible gestures – “Come here for all your navigation needs!” – knowing that it increases the chances users will develop a habit of learning and using them. (The gestures also work whether you’re in view or edit mode.)
I am curious, though: Would allowing to tap somewhere near the bottom edge not work as the “obvious” solution to get all the way down?
I still use Sublime Text for all of my programming and all of my newsletter-ing. […] The app is simple and superfast; I have it set up exactly the way I like it […], and it’s difficult for me to imagine ever switching to anything else.
Here is a piece of software as sturdy and obedient as a cast-iron pan.
I don’t know who develops it and I don’t care. All I know is that I can place my text cursor and read the surrounding code without a bombardment of popovers, pop-unders, pop-left-and-rights, pop-inlines, pop-in-and-out-too-fast-to-sees. […]
The perfect dev stack is a collection of software that each does one job and doesn’t suffer main character syndrome. I want to code, I’m not looking to make lifestyle choices. I don’t want a bloated everything app. Don’t get me started on the “unified toolchain” plague! Show me the latest VC-backed build tool and I’ll show you ten lines of PHP that does a better job.
If you’re fed up of the absolute state of things, Sublime Text still works.
I do care who develops good software since, at the very least, I want to give them credit. This is the best I could find, if you too are curious. It was prompted by someone asking:
I’ve been a Sublime Text user for over a decade, and now a Sublime Merge user, too. But it occurs to me that I know almost nothing about the team/company behind it.
I wonder if this is a nice example of the (quiet) posture of the company matching the (utilitarian) personality of the software it is making.
Minimaps are an interesting UI element because they often feel very exciting – something about things being small, or responsive, or maps just being cool? – but fail to actually be useful.
I find minimaps for coding particularly tricky because, at least in my world, code all looks very much the same from far away. Seeing a thumbnailed/greeked version of it felt just like a more expensive and distracting version of a regular scrollbar, without any benefits.
But Xcode does something interesting. It allows you to use MARK to create a sort of a “header” for the minimap anywhere you want:
The minimap then shows those headers not greeked, but as human-readable text:
I thought this was clever, allowing you to see the bird’s eye view of the code not just in the most obvious visual sense, but also as a sort of “table of contents,” adding so much more utility.
This, of course, is technically no longer a “zoomed out view” but then again, it’s not that there is some sort of rule that it has to be. As a matter of fact, quite the opposite; it all reminded me of the famous London subway map by Harry Beck, which also broke the expectations in a similar way.
The original, geographically accurate map of London’s tube looked like this:
Beck decided to take liberties with the geography and reimagine the map as a diagram to help the travellers, and ever since he’s done so in 1933, many transit maps followed suit:
A strange thing happens when you press Enter on an empty item in a list in most text editors – the entire list item disappears:
This feels counterintuitive. Isn’t Enter for committing and adding more things? Wouldn’t Backspace be the right key to press to break a list?
Yes, and no. I am not sure who invented this pattern (I spotted it first in Word 95), but that someone understood a strange interaction contract existing in text editing – Enter is actually an escape hatch. In text editing, no matter where you are, you can always press Enter multiple times to just create more room for writing.
In an app that doesn’t cancel a list on Enter, you can face a terrifying moment where you get stuck in a list, and getting stuck is never fun.
This principle feels so useful that I see more and more apps apply a version of it for other things. For example, in many modern text editors pressing Enter after a headline returns you to regular text, just so it’s not as easy to get stuck in a headline style:
Over the years, I acquired this weird collection of almost-invisible, but important signifiers of when I know a product really focuses on craft and thinks about its users.
I thought about one recently. Here’s what happens when you try to copy a long block of text from YouTube’s (otherwise very useful) text transcript pane:
And here’s an analogous example from GitHub:
GitHub’s arrives ready to go. YouTube’s throws in a lot of messy things in between the lines.
Why does it matter? Because these both feel like places you’ll be copying a lot from, and dealing with a messy paste can feel so, so unpleasant.
You have probably seen this chart before, from xkcd:
This is the fabled automation trade-off, or the high fixed cost vs. low variable cost dilemma.
Yeah, if you’re doing a lot of copy/paste, you might invest in creating some sort of a clean-up step, or even going through a programming text editor which has multiple cursors or other casual automation. But what if you don’t do that often, or if you don’t even know how much time it’d take you to automate it? Then the investment seems scary or insurmountable, and you’re stuck doing something like this, time and again:
And it’s really nice to encounter a place like GitHub, where the team was thoughtful enough to save you all this trouble.
There is also an asymmetry that’s worth pointing out. I believe making this good doesn’t have to be a lot of work for people putting these surfaces together. Here’s me fixing the YouTube situation with two simple lines of CSS with user-select: none:
I don’t know if it’d be as easy for all big text block situations, but I think it’s good practice to look around a bit and think about what are tiny things that you can do on your side that will save your users minutes or hours of tedium (see also: recents and paste and even more recents).
For decades now, Raymond Chen has been posting to his blog The Old New Thing about various technical Microsoft quirks, occasionally venturing into Unsung territory. Last week, Chen shared a nice remembrance of Tony Krueger, a person responsible for implementing the red squiggly underlines in Word:
Tony worked on Word 1.0, 1.1, 2.0, then on Word for OS/2 and Word for Mac, then returned to Word 6.0 and several versions beyond that. He probably holds the record for “most versions of Word shipped.” […]
Tony made the spell checker much more unobtrusive so that it didn’t interfere with your foreground work. And when it found a problem, instead of waiting for you to trigger a spell check, it immediately drew red squiggles under potentially-misspelled words (and later green squiggles under potential grammatical errors). […]
Today, there are red (and even green and blue) squiggles in nearly every word processor, and often outside word processors. Tony did it first. The next time a red squiggle catches one of your mistakes, say thanks to Tony. I think he’d appreciate it.
Read on for some fun celebrity encounters, and even a touching comment from Krueger’s father. Another person adds that a “PM named Diana” and another Microsoft employee, Jim Walsh, might have been the people who designed the feature.
Chen doesn’t name it specifically, but it’s my understanding that the red underlines were named Spell It (meh), and appeared in Office 95 in 1995. Steven Sinofsky confirms it on his blog, adding “The red squiggles were simply reflective of a proofreader’s style of mark (also one of the early uses of color in the interface).”
As far as I can tell by looking at various screenshots and photos of boxes, the feature wasn’t advertised at all. It was only mentioned more explicitly a few years later in Office 97:
Every once in a while, I stumble upon a long thread in a random corner of the internet where someone discovers Paste And Match Style, and everyone erupts in applause. “Yeah, it’s a life saver.” “I use it all the time.”“I can’t believe this isn’t the default!”
Then, inevitably someone chimes in: “Oh yeah? I can show you how to make it the default.” And they explain how to wire ⌘V to use Paste And Match Style.
And I always get worried seeing that.
I believe this is the core problem people are bothered by before discovering PAMS – when you copy and paste from another doc, you inherit its style/visual appearance:
And Paste And Match Style, well, does what it promises:
This feels nice. So, what’s the problem? The problem is that PAMS is drunk with power and flattens everything on its way:
That includes:
emphasis by italics or bolding
links
bulleted and numbered lists
strike-through text
headlines
None of these are “style.” This is actual information that should not be removed. If you wire PAMS as your main ⌘V shortcut, or even if you use it occasionally, you might remove valuable data from text you’re moving around, without even noticing.
(And if you do notice, the frustrating irony is that recreating the information lost in transit – for example, re-linking things one by one – is often more work than fixing the style would be.)
If you are designing an app that handles rich text, here’s what I have seen others do:
Do not have styles to begin with. If you use Notion, Dropbox Paper, Medium, or anything that relies on Markdown, they give you no way to customize fonts, colors, letter spacing, and so on, so regular superliteral Paste has a limited blast radius and works well:
Have a very strong center of gravity toward the default style. Apple Notes does this well. Use Notes for years, paste into it from all over the world, and you might never realize it allows you to change fonts and colors. Its default Paste removes style, but it doesn’t remove any valuable information like links or bullet points.
Notes also introduces a shortcutless Paste And Retain Style as a third option after a “semantic” paste (which keeps data and removes style) and PAMS (which removes everything), for those who really want to paste extremely literally:
Word has Paste And Match Formatting that seems to be what Notes does by default, but it’s not the default:
Help users understand the options they have more. For example, Word offers a little post-paste menu. I don’t personally love (it doesn’t have a preview + it doesn’t remember my preference + the options are scary), but it uses better-than-default language like Keep Text Only, and it protects people from the harrowing backrooms of its own Paste Special:
Have some contextual rules – for example Figma does things differently depending on whether you paste into a new text box (preserve style), or a text box that’s already filled (match formatting).
(If you’re seeing some other apps doing something interesting, please let me know!)
Doing the right thing won’t be easy. Books have been written about the illusion of the difference between “stylistic” and “semantic.” People use bolding for either. Others treat headlines as visual style, right aligning means something different in English than it does in Arabic, you might still have to normalize indentations, and so on.
But I believe it’s necessary to put in the effort to make regular Paste work as well as humanly possible, rather than relying on people to know about the far-from-perfect ticking time bomb that is PAMS.
This is perhaps my favourite feature in Lightroom. You press ⇧T, you draw a few lines, and presto – your photo is now even:
This is doubly magical to me. The first part is that this is even possible – that you can straighten the photo in both dimensions after the fact, and save for some parallax nuances the viewer won’t know any better.
For decades, this has been the domain of tilt-shift lenses, but if you ever tried to use one, you know how harrowing of an exercise this is. A tilt-shift lens looks more like a medical device and less like a piece of photography equipment:
The “obvious” way to emulate a tilt-shift lens in software is a bunch of sliders, and Lightroom has those also…
…but that’s still pretty cumbersome in practice, abstracted in a strange ways, like piloting a plane by pulling the linkages connected the flying surfaces: you will admire someone who can do that, but won’t ever want to do it yourself.
Hence the second magical moment: The team created the new interface I showed at the beginning, where you point to things that should be straight directly, and the necessary tilt-shift calculations happen behind the scenes.
Alas, Lightroom didn’t fully stick the landing. The interface is a bit jittery, and missing nice transitions that could help understand what’s going on. But what brought me here was this unpleasant interaction:
What’s wrong with it? If you want to play along, stop here and ponder: How would you improve it? Because this is a classic UI exercise where there are symptoms, and there are problems, and there are principles under the hood of it all.
The first possible improvement: Don’t do a dialog like this. These are ancient and so annoying. Every time I see a centered dialog covering everything, popping up in response to a delicate mouse operation, I want to shout “read the room!” It’s better to drop a little tooltip next to the cursor that automatically disappears: more modern, and more “compatible” with mousing.
Then: Why am I allowed to start and finish an action that the machine already knows won’t go anywhere? Disable the drawing option, put a little “verboten” icon on the mouse pointer, or do something else that will prevent me from drawing a line to begin with.
But that brings us to point three, and how I would approach this as a designer. Because I would – counterintuitively – go the other way and allow the user to draw as many lines as they wanted, and just didn’t permit to commit the entire operation if there were more than four lines on the screen.
Why is that?
It’s the same principle as you see in all the social media composing fields, and in well-trained forms: do not constrain the editing process.
This field is limited to 300 characters, but it’s clever enough to only enforce its limits when you try to post. There is no downside to allowing you more room in the editing process. Maybe you write by constructing a few sentences first and only then combining them into one, maybe you want to see two riffs one below the other to choose the better one, or maybe – this is most likely – you’re not even paying attention and your motor memory is doing the editing for you, instinctively. Use any text editor for just a few months, and cut, copy, and paste, word swapping, and splitting sentences become second-nature gestures – that is, until the UI starts throwing in some arbitrary barriers.
Above in Lightroom, it might actually be easier for me to draw a fifth line and then delete a previous one, instead of doing it in the precise order Lightroom desires, or by dragging an existing line to move it instead of creating a new one.
Maybe an overarching principle would be this: If you are aiming to build something so delightfully direct manipulation as Lightroom did here, you have to fully commit to that stance, even deep in the weeds. Because every time I see a 1990s dialog appear when my fingers are flying fast, I feel like this:
I believe these are used by people who prefer intentionally limited visual choices, for low-key diagramming to put in source code, and – increasingly – as an entry point to gen AI.
They’re so interesting from the standpoint of this blog:
Fun to see a contemporary take on something that peaked between 1970s–1980s – you can look up TUIs and Turbo Vision if you want – but (just like Mario the other day) now with modern sensibilities, performance, web access, mouse and trackpad affordances, and so on.
It’s interesting simply as an exercise in constraint. I believe constraint practice will become more and more important as computers become more and more capable. It’s already useful to constrain yourself in order to make things easier for you. With the rise of AI, self-constraint will become important to make things harder, as well.
There is a certain power and longevity of monospace plain text that’s worth celebrating – not just because the file format is portable, but because text editing as interface is so well-known and potent.
Also, ASCII spray in Mockdown is just really fun:
(Caveat: These tools are “ASCII” in a colloquial sense, the same way people use “GIF” to refer to a certain category of looping animations.)
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.
