I recently stumbled upon this 20-minute YouTube video by iSongs of someone recreating Eminem’s “Lose Yourself” in GarageBand on their iPhone:
Like the previous video, I believe this is so tight as it was previously rehearsed/prepared, which makes for an interesting watch if you even just check out a fragment of the video.
I can’t speak for the verisimilitude/quality of the composition, but it was fascinating to witness because The. UI. Just. Kept. Coming. I had no idea Garage Band is so fully-featured on the iPhone, and that there is so much going on!
Maybe my fascination is this: it’s amazing that “power users” come in various shapes and forms. Would I recommend using the iPhone to do this? Not really. Is it cool that this is possible, for people who might not have access to other platforms? Yeah.
I generally avoid think pieces about AI because a) a lot of them are boring, and b) they rarely match the pragmatic posture of this blog.
But this essay on a new No One’s Happy blog was really interesting to read, and feels different in a few ways.
First, it examines what happens as AI slop spreads in the context that is less discussed – in a workplace:
This is a new form of slop, and it is more expensive than the public kind, because the people producing it are being paid a salary to do so. […]
The cost of producing a document has fallen to nearly zero; the cost of reading one has not, and is in fact rising, because the reader must now sift the synthetic context for whatever the document was originally about.
A lot in the essay feels pertinent to Unsung as real craft is not feelings or fluffiness. Real craft is deep expertise:
Generative AI can produce work that looks expert without being expert, and the failure arrives in two shapes. The first is when novices in a field are able to produce work that resembles what their seniors produce, faster or more advanced than their judgment. The second is when people generate artifacts in disciplines they were never trained in. The two failures look similar from a distance and are not the same. Research has mostly measured the first. The second is what it is missing, and in my experience it is the riskier of the two.
The term for this new challenge is, apparently, “output-competence decoupling.”
Other parts of the essay come back to a topic – toxic velocity – we coveredbefore:
The current generation of agentic systems is built around the premise that the human is the bottleneck — that the loop runs faster and cleaner without the awkward delay of someone reading what is about to happen and deciding whether it should. This is, in a great many cases, exactly backwards. The human in the loop is not a vestige of an earlier era; the human is the only part of the loop with skin in the game. Removing the H from HITL [Human In The Loop – eds. note] is not an efficiency. It is the abandonment of the only mechanism the system has for catching itself.
And one last thing that differentiates this essay from many others is the last “what to do about it” section.
I’m working on a column about the tech annoyances that drive us crazy, and I want it to be as universal as possible, so tell me yours!
E.g. scanning a QR code to read a menu, never receiving the one-time passcode they supposedly texted you, “verify you’re human” by IDing tiny motorcycles, etc.
There are already many responses. I am drafting behind Phillips before he even writes his essay, because I like occasionally checking in with people this way. Not just for commiserating; perhaps scanning the answers will also give you some inspiration, or validation, or quotes for something you can push to make better, wherever you are.
Some patterns I noticed:
A lot of logging in woes: password requirements, bouncing people from apps to web to log in, login flows forgetting context, “I trusted this device” settings you cannot trust.
“Local news websites that crash under the weight of all their pop-up ads and auto-play videos.” This post had a great take:
The way super sketchy bootleg websites used to look (written in questionable English, 2/3 of the window overtaken by ads, constant popups and redirects, incorrect information more often than not) is just how all websites are now.
Hatred of QR codes, or perhaps what they represent: needing to install an app, removing people out of the equation, introducing phones where they weren’t needed before.
Surprisingly little AI. Is that because of the audience or the way the question was phrased?
Actors are overwhelmingly diurnal, overtime is expensive, and film emulsion struggles with limited light, so since the dawn of time Hollywood has been using a technique called “day for night” – shooting during daylight, and then darkening and blue-tinting in post to pretend it was night time all along:
Now that you know it, you might spot it in movies that use it poorly: the ones that darken everything too much, the ones where too bright of a sky gives it away, or the ones where the shadows appear lunatic in the wrong sense of the word.
In UX design, you can day-for-night your dark mode as well – long before proper dark mode was a gleam in someone’s bloodshot eye, operating systems allowed you to invert their screens – but the limitations of that approach are apparent very quickly:
Sure, black becomes white, white becomes black, and grays swap places. But in real life, shadows do not get brighter at night, and photos do not behave that way, either.
The “proper” answer is not to do anything automatically and to go all out with a perfectly hand-crafted dark mode that’s an equal partner to light mode: a distinct set of semantic colors, a new strategy for shadows and layering, and a second set of visual assets like icons and images.
Here’s a comparison of naïve inverting and a proper dark mode:
A lot of apps do that for colors and shadows, some even providing multiple dark mode flavors…
…but visual assets is where things get tricky. Yeah, vector graphics can use the same swappable color variables as CSS text and elements, although in practice it is quite a bit of work and from my experience SVG doesn’t make it very easy, either (here’s an example from my essay):
But when it comes to bitmaps, they are usually left alone. Overtime is still overtime, and producing each bitmap twice is a lot of effort.
Since swappable variables don’t exist in this context, the only automatic approach method left is inverting, but a) inverting an already- dark image can make things lighter,and b) inverting things like photos makes them look creepy and mixes up all the colors:
What explains the last part? This has to do with the fact that inversion happens in the RGB color space. R becomes 1–R, and the same for G and B.
Everyone who’s into gradients knows of a similar challenge that results in the gray dead zone effect. This is fixable if you convince a gradient to traverse through a different space instead, or coax it through the RGB space on a more… bespoke path (this is e.g. what Figma gradient plugins do).
Could we invert in HSL or OKLAB color space, then? Yes, we could. They both look similar – this is HSL:
You can see how the photos get inverted now, but the colors remain the same! Still a curiosity, perhaps, but the bottom of the above screen shows this technique feels really interesting for diagrams, screenshots, and things of similar nature. Here’s another bitmap that looks pretty great inverted this way:
Unfortunately, while there are techniques and plugins to do gradients in non-RGB color spaces, I am not seeing a lot of options for inversion customization anywhere. Neither the graphics apps I use, nor CSS offer anything here.
But there’s a trick: do a regular invert and then rotate the hue halfway through. Through the magic of math, this is the same as inverting just L in the HSL space, which means the colors are preserved. This is actually achievable in graphic programs…
…and, more importantly, available in CSS as a filter: instead of invert(1), use hue-rotate(180deg) invert(1).
So, if you have dark-on-light diagrams, bitmapped text, illustrations, or other similar things – or even vector graphics you cannot throw dark mode variables at – this day-for-night trick that can get you places very cheaply. (And for other bright bitmaps, just reduce the brightness by 25%.)
It’s the same as with Hollywood trickery: remember to add a bit more nuance in the right place, and you get something that feels bespoke for the price of only light – please excuse the pun – manufacture.
This 22-minute video by Karl Jobst describes a pretty wild discovery of a glitch called Crystal Storage Glitch, allowing to skip a certain level for much faster completion times in Mega Man X2:
I won’t spoil the glitch because it’s a fascinating combination of a corner case, a race condition, and even a dose of dumb luck. Its finding unveils almost like a scientific discovery over many years – first a theoretical possibility, then a first sighting done in a modified emulator, then confirmation made by a machine via a tool-assisted speedrun, and eventually actual performance by someone by hand. And a lot of this achieved by relative newcomers to the community, too.
There is certain poetry here in having to go slow to go fast – you’ll see what I mean.
In Figma, when choosing a font, you can filter down a list of fonts from “all” to specific categories or e.g. only fonts present in the current file.
But when you type into the search field, the search cuts across all fonts again, ignoring the applied filter. The search effectively lives outside the filter.
In Keyboard Maestro, when adding an action, you can click in the nav to filter down to a specific category. And when you search, the current filter remains active, so you search inside the filter.
Which one is better?
I don’t have a universal rule here, because it will depend both on the UI treatment, and the specific filters and searches people do.
But I think here, my recommendation for Keyboard Maestro here would be to do the same thing as Figma does. I designed that flow in Figma, so I might be biased, but my reasons are:
There aren’t really a lot of options in each category, so you don’t benefit a lot from double filtering.
But the most important thing: For both Figma and Keyboard Maestro, the text field might smell like a text filter and as such expected to be multiplexed with the category filter, but I think this field is actually something else: It’s quick keyboard access, like ⌘F or Spotlight or Raycast. And if you think about it this way, it’s important for it to be deterministic – I can always type “Output Sans,” no matter what state am I in, and get to the font.
On that last note, I find it’s good to look around what you’ve designed once in a while and consider not what the UI set out to be, but what it became – there might be more examples of that around you.
Andrew Gleeson designed Analog Mono, “fixing the crimes of VCR OSD Mono.” There used to be this classic pixel font that you’d see everywhere in the 1990s on hi-fi equipment: VCRs, TVs, camcorders, etc. One of its challenges was a low baseline which resulted in all the letters with descenders pulled up, for example:
Analog Mono fixes that problem:
Elsewhere, Kumiko Yoshida made Coral Pixels (also on Google Fonts), a color font that comes with the 1990s and 2000s colorful fringing baked in. The fringing was once an artifact of subpixel rendering, but now it is meant to evoke nostalgia or just as an interesting visual element in and of itself. (Perhaps adjacent to chromatic aberration?)
Lastly, here’s Two Slice by Joseph Fatula – a font that’s only 2 pixels tall, “and somewhat readable.”
Of course, these are all vector fonts – e.g. ready to be installed on a modern operating system – pretending to be pixel fonts. That’s maybe a separate post altogether, but it leads us to the last font, Geist Pixel from Vercel:
The copy introducing the font is a little pretentious/spicy, but it touches upon something important:
Geist Pixel isn’t a novelty font. It’s a system extension. [… It] was designed with real usage in mind, not as a visual gimmick, but as a functional tool within a broader typographic system. […] This matters because pixel fonts often break in production. They don’t scale properly across viewports, their metrics conflict with existing typography, or they’re purely decorative. Geist Pixel was built to solve these problems, maintaining the visual texture teams want while preserving the typographic rigor products require.
There are definitely fonts whose Achilles’ heel is not the letterforms, but the invisible hard work put into everything that surrounds them: the kerning, the metadata, the extra glyphs, the vertical metrics. It seems that the team being Geist Pixel is proud of especially that last part.
A nice, but unpolished onboarding callout directing people towards a more useful shortcut, in Google Docs. I’m holding arrow keys without ⇧ here first, then with ⇧:
To improve it, I would add some sort of small celebratory “completed!” state, and auto-hide it afterwards; right now, it seems that it hides on a delay, likely regardless of what happens.
(Testing onboarding is hard because once it’s invoked it disappears forever. If you are worried about onboarding experiences in a place you work, please insist on easy toggles to bring it back for testing. And no, one-size-fits-all “reset onboarding” is too crude; ideally you can reset each specific one easily through a simple UI.)
Here’s a 2002 story from a younger internet, by programmer Trey Harris (link to the original and if you don’t like the classic Usenet formatting – my browser’s reader mode can’t even prettify it! – here’s a nicer-looking format):
“We’re having a problem sending email out of the department.”
“What’s the problem?” I asked.
“We can’t send mail more than 500 miles,” the chairman explained.
I choked on my latte. “Come again?”
“We can’t send mail farther than 500 miles from here,” he repeated. “A little bit more, actually. Call it 520 miles. But no farther.”
It would be easy to assume this is a classic case of pebkac, “problem exists between keyboard and chair,” the derisive term used (supposedly!) by support people, describing naïve public who had a tenuous grasp of technological reality. But the story goes to an unexpected place.
This might be the most widely-shared computer bug story of all time I’ve seen – I just saw a comment from 2008 calling it “oldie but a goodie,“ and it even has an FAQ page that’s actually a really great read. There’s quite a bit of chatter inside about something important to me: the balance between the needs of good storytelling and going deep into technical details:
In the story, I make it sound like it took all of ten minutes from being made aware of the 500-mile email limit and determining a 3 ms light-speed issue. In fact, this took several hours, and quite a bit of detective work. The point is, eventually I came up with that figure, ran units, and gagged on my latte.
You can sense author’s frustration with every nerd trying to “gotcha” him instead of just enjoying the story. Even a younger internet wasn’t without faults.
The video helped me understand the difference between tunes purely synthesized from soundchips, those sequenced with samples (e.g. MIDI or sound trackers), and those that are completely “streamed” (e.g. MP3). It’s stuff in between that’s the most interesting – it always is – with really surprising sources of samples (and, surprising samples!) needed to “perform” sequenced music.
The video itself is frenetically edited, and the opposite of “dry” (which I mean as a compliment).
I love looking at origins of obvious things, because of two things:
They help me get unstuck. If you go far enough, you will find out that even the most ossified conventions that are older than you haven’t always been this way.
They put me in the mood of “what of the things that feel normal today that deserve to feel dated, obsolete, or awkward?”
I’ve been emulating the Apple Lisa recently, and I was struck by how many of its UI strings were slightly or wholly different than what we’re used to.
It makes sense. Lisa came out in 1983 as Mac’s predecessor and really the first GUI that is directly linked to what we’re using today. Even though it borrowed things from work done at Xerox, tons of conventions were not established yet.
So, I thought it would be fun to actually take a closer look.
For context, Lisa was as slow as it was expensive, and generally considered a failure. It was basically abandoned by 1985. Not much third-party software has ever been written, but Lisa shipped with 7 impressive office apps with fantastic names: LisaWrite, LisaCalc, LisaDraw, LisaGraph, LisaList, LisaProject, and LisaTerminal.
The screenshots below come from an emulator and from manuals (this links to the 1984 version, but each manual also includes a link to the original 1983 edition). The emulator is pretty harrowing; please upvote the idea of Lisa in Infinite Mac if you would want to see it!
As Lisa powers up, we see the appearance of the “wait” dialog box. We’ll encounter more symbols like this triangle, inspired by traditional flowcharts.
Let’s start with menus, as these really were the treasure map to the whole system.
The Desk menu is basically the equivalent of the dock today.
The File menu has Print appended to it, indicating how important printing was still then; a truly “paperless office” won’t really be possible for two more decades (and seemingly still hasn’t fully arrived).
There is no Window menu yet, so the menu also contains some of that burgeoning functionality. Set Aside is what we would call Minimize today. Save & Continue is basically a contemporary Save, and Save & Put Away a hypothetical Save & Close. Revert to Previous Version is the same as today’s Revert. By the way, in the Revert dialog I appreciated the nice gesture of telling the user how much time passed since the last save, and a warning about undo (we’ll get back to this):
Print Current Selection would today be just Print Selection. Print As Is is basically Print… but skipping the setup dialog with number of copies, etc. It was added later in Lisa’s life, and today, we’d probably call it Print Again?
If you’re noticing a pattern already, it is more wordiness compared to what we see these days. It makes sense. Our growing familiarity with these concepts is what will allow these strings to become tighter over time.
This is that Print… dialog, by the way, with beautiful “while you wait” and “while you work” verbiage (although usually I do not condone strings getting so close to each other). The manual explains: “You can have the Lisa use most of its attention to print your document while you wait. A document will print more quickly if you choose While You Wait, but you won’t be able to use the Lisa for any other tasks.”
The other strings feel less typical. Format For Printer… is Page Setup, but with a lot of quirks. Printers were not usually yet WYSIWYG, able to mirror stuff exactly on the screen. They often came with their own fonts, so some matching was necessary:
The manual had an entire section called “When Settings Don’t Match a Printer,” and there were I imagine god knows how many error cases that had to be covered, including:
And Monitor The Printer… is today’s Print Center: a way to see the real-time printing status. Note a lot of writing here elaborates further on the “while you wait/while you work” dichotomy:
Monitor The Printer was important, by the way, since the manual warned you your printer might occasionally become haunted:
But, let’s go back to the File/Print menu. I actually found a version of this menu that comes from a 1982 pre-release Lisa, never launched to the public. Let me show them side by side:
It’s fun to see designers figuring it all out. You will notice the lack of dividers and ellipses actually touching the work-in-progress strings. 1983’s Set Aside is 1982’s very modern Close. Save & Put Away is Put Back. And, at the bottom, it seems the team didn’t yet figure out that the menu options need to consistently use verbs for commands, and adjectives or nouns for toggles – so we see Intended for Printer… (rather than Format For Printer…) and Printing in Progress… (rather than Monitor The Printer…).
Lastly, in a released version of LisaList, this menu would come bearing a harrowing Fix Damaged Document command. Not only it doesn’t even have an ellipsis, but the manual also says “there is always the chance that the recovery process will make things worse instead of better.” Vaya con dios, I suppose.
Let’s move on to the Edit menu.
Today’s Select All is a verbose Select All Of Document, and since this is the first public appearance of undo, that feature is also more descriptive, appearing as Undo Last Change. But otherwise the menu feels surprisingly modern, shortcuts and all.
Unsurprisingly, the first undo wasn’t as developed. We saw earlier in this post “Once you click OK, you will not be able to change your mind, even with Undo,” which today would probably say “This is not undoable.” You could also see a frightening error message arriving without any further clarification, like above.
Sometimes, the app would warn you undo doesn’t have your back. We’ve seen this before, and here’s another example.
Since undo only had one step, LisaCalc and LisaList also had Restore Previous Entry for when you changed your mind after editing a cell in the spreadsheet. You had to employ this strategically, as you did the already-mentioned Revert to Previous Version.
“You can even undo Undo!” bragged the manual, and I imagine there must have been interfaces where undo came without a matching redo. But the eventual solution, of course, was bidirectional undo/redo with many steps. This basically only needed more memory, still very expensive in 1983.
Above we also see Clear Entries that would just be called Clear today.
Elsewhere in Edit menu, Clear Lines Off Top would appear in LisaTerminal only, and was a charming (and I would argue better) way of saying Clear Scrollback.
The next menu, Type Style, would be called Font today. “Type” is typewriter nomenclature – Lisa was meant to be a typewriter replacement. The point/pitch convention for font sizes and letter spacing also comes from typewriters, and in an older version of that menu even font names arrive from that universe (PS = Proportionally Spaced!):
Otherwise, notable is the deterministic Plain Text reset with a P shortcut that would in time lose to printing. I miss this sometimes, this “reset” idea, as I think it would nicely compliment Paste And Match Style.
While Type Style is for selection, Format ¶ is all about paragraphs – HTML people know this distinction as “inline vs. block.” (The pilcrow symbol means “paragraph,” although I did not expect it to be common use even then.) The flyout menus with their convoluted mechanics weren’t invented yet, but in some sense there was no need for them as the options were very limited.
It is interesting to see Margin/Tab Ruler as two options with deterministic shortcuts ([ and ]). But the most unbelievable shortcut must be Same As On Clipboard. It reformats the current selection to match what you have in the clipboard – an early salvo in an endless battle that later brought us Paste Special, Paste And Match Style, Paste And Retain Style, Copy/Paste Properties, Paint Format and so on, and so on. And it was given S, rather than spending it on Save (& Continue).
Otherwise Left Flush and Right Flush would be called aligning today, and the ¶ pilcrow symbol would be replaced by a simple Paragraph Spacing.
In LisaCalc, Format is missing the ¶ because, well, there are no paragraphs in spreadsheets! I love Words Left/Nos. Right, and empathize with trying to align the digits. But it wasn’t even close, was it.
Page Layout shows that we’ve had UI boolean problems from day one. Show Page Ruler and Hide Page Ruler do it deterministically, with one always disabled, and without checkmarks. Preview Pages and Don’t Preview Pages do the checkmark, but introduce a dreaded double negative. (These last options, by the way, is the “pages/pageless format” showing page margins and dividers, that bother us so much about Google Docs.) Today, these would all be in the View menu that doesn’t exist yet.
And speaking of boolean challenges, here are some top-level menus from LisaList with even more conventions:
But, back to the Page Layout Menu. Insert Page Mark would be Insert Page Break today. I really love Allow To Cross Pages as the opposite of Keep On Same Page, and the incredible O and Q shortcuts.
In LisaCalc, this particular menu comes with a beautifully named For Your Information (sentence capped, for some reason)…
…throwing up a sheet-like window showing basic stats. Today, that window would have a more boring name and probably land in the File menu:
The Search menu is fascinating – why wasn’t it called Find like its items are? I am particularly enjoying W keyed off of Find What (today: Find), while F is taken by Find Next Occurrence (today: Find Again). There is some mnemonic sense to it all, but I like today’s proximity of ⌘F/G better.
What we know as Replace is Change here, and I am particularly loving Cases Must Agree and Cases Need Not Agree (today usually called “case sensitivity.”)
Hide Dialog Box is a string with surprising to me amount of UI jargon. The H shortcut was added later in Lisa’s life, presumably at users’ behest. It’s strange today to see a shortcut like this to hide one specific floating dialog box.
Similarly, Insert Wild Card with a confusing ellipsis allows you to insert a symbol in your find dialog that stands for “match anything here” – top-level menu options reaching inside specific dialog boxes were not uncommon in early years of GUIs, but I think fell out of favor over time as the idea can be conceptually confusing.
The menu below is from LisaWrite, and I like how comparing it with other apps makes us see the team trying to settle on a convention. In LisaList there are no ellipsis, but question marks!
And in LisaCalc, there are… both:
You can notice that it wasn’t clear where one would put Find-related commands and their today’s presence in Edit menu doesn’t really make a lot of sense, either. We just got used to it. (Also note the “occurence” typo.)
Spelling menu has a bunch of fun options and conventions, and an extremely generous use of keyboard shortcuts:
Find Next Misspelling (you don’t often see that word!)
Suggest Corrections + Paste Guess (this is just replacing the word with the suggestion – interesting use of the clipboard metaphor)
Put In Dictionary (today: Learn Spelling)
LisaDraw sports the Arrangement menu, which will look very familiar to anyone using Illustrator, Sketch, Figma, and so on. This is where Bring To Front and Send To Back started! With a tiny bit of editing (Arrangement is now Arrange, and some of the Objects nouns would be omitted), this would feel pretty modern.
I love these visual menus, and I think we lost that kind of stuff along the way:
Okay, let’s move on from menus. The system also relied a lot of dialogs. Let’s look at some of them:
This wordy dialog would become a small loading state today. The verbose “To terminate the operation, hold down the Apple key while you type a period” probably felt necessary because other than Shift on a typewriter, people were not familiar with modifier keys. Lisa doesn’t have the Esc key, and Mac still respects the ⌘. convention in many places in 2026.
(By the way, why would you want to stop saving? Presumably because it could take quite a while.)
In this similar dialog, you can see a reference to a “micro diskette.” Even though Lisa’s “Twiggy” disks seem gargantuan today, they were smaller compared to the original, 8″ floppy disk. (In a similar way, Lisa and other machines of the era were called “microcomputers.”)
Lisa had some proprioception: In this dialog, the disk put in the first drive is called an “upper diskette.” (Also note: more undo education.)
Disks were not large, so sometimes you had to deal with this kind of horror. It’s interesting how the dialog plain sends you to the manual – an early equivalent to eventual Learn More links.
This is another example of a rather verbose set of instructions. On one hand, this is better than “Error 456” and nothing else. On the other hand, it feels like a lot of stuff to memorize.
Also of note, the beautiful Housekeeping menu. I actually forgot about the Finder (or, in Lisa’s parlance, Desktop), so here’s a screenshot of it also:
Housekeeping was basically the junk drawer – on the Mac a year later, this will be named Special. It also has some stuff that today would be in the View menu. (This later version of Lisa calls Trash the same as the Mac. Earlier on, you would see it named a Wastebasket instead.)
Of note elsewhere in Desktop is the use of the term Stationery, roughly meaning “template,” but with extra sprinkling of desktop-metaphor skeuomorphism. Also, Attributes Of is an early version of Get Info.
Another verbose dialog (compare with Abort/Retry/Ignore from around the same time). This is before we invented hint text that we’d just put under the buttons themselves.
In case you haven’t noticed by now, Lisa’s strings all have two spaces after a full stop!
There was lot of “you cannot” dialogs, walking you through some recovery steps.
Plug and play didn’t yet exist (this would all happen in the 1990s), so that had to be explained also.
I also love the anthropomorphic phrasing “Preferences has been told,” which I don’t believe you see anywhere today.
And I think we can round up this post with a few small delightful language details like this one.
As a huge fan of the slightly pretentious “presently” over “currently,” I smiled seeing this next to the printing status.
“Just a moment, please…” feels so old-fashioned, somehow.
And I want to end on a pre-release version of the Edit menu we’ve already seen. You can spot here Select Entire Document (instead of eventual Select All Of Document), but of course the best thing is the Copy, Cut, & Paste with an ampersand! I find it so, so charming.
I hope you enjoyed this tour. It was interesting to me to see how many of these became the standard back there and then, how many were tweaked a little bit, and which ones had to be redone more thoroughly.
Now, excuse me as I have to go deal with my whistling printer.
I think it’s worth checking out that list and internalizing it even if you’re nowhere near that kind of a decision, because some of these are universal requirements for a better-feeling interface:
No cursor: pointer on interactive controls. Desktop apps don’t do this. It’s small, but it immediately signals “this is a website.”
No hover highlights on most controls. On macOS, buttons and list items don’t highlight on hover the way they do on the web.
Settings open in a separate native window, not a modal or a side panel.
Popovers and tooltips render as native windows, not as DOM elements inside the WebView. They can extend beyond the window bounds, just like native popovers do.
On macOS Tahoe, we adopted Apple’s new Liquid Glass material so Raycast blends with the system’s updated visual language from day one.
No flickering when views appear or transition. This is a common tell in web apps, and we did a lot of work to eliminate it.
There is more in the blog post, and a lot more still left unsaid. Let me add one that I see all the time: accidental text selection. Web makes all text selectable by default, regardless of whether it makes sense for that text to be selected. On top of that, text selection heuristics on complex layouts are not that great. That means that surprisingly often you will see half a text on the page being selected in response to an accidental click or drag.
Here’s an example from YouTube I just spotted, where dragging a sidebar selects everything inside it:
It’s all solvable via the use of event cancellation and user-select, but requires someone to think about it happening.
Yes, there are moments where GUIs allow you to select text for a reason…
…but it’s always been a tricky proposition given the scarcity of affordances. It might be better to employ a pretty common “copy to clipboard” pattern instead.
Chrome’s find option, like every search coming from a good home, does something clever with accented characters – it normalizes them:
No matter whether you search with a proper accented character, or with its basic Latin equivalent, all the same stuff matches: The “ø” letter is treated the same as “o” both in the input field, and then in the search itself.
Yet, Chrome’s tab search inexplicably doesn’t do that, which confused me when working on a post about diacritics earlier this week. Here, it should match all four open tabs:
Tab search was introduced years ago; the Occam’s Razor says this isn’t a recent bug, but that the feature has always behaved like this. I filed the bug, but even if it gets fixed quickly, I think this doesn’t reflect well on Chrome’s team. If the right code already exists for ⌘F, why not reuse it? If it cannot be reused, why not repurpose at least its unit tests or the QA process to make sure this doesn’t fall through the cracks? Normalization should be treated as a core property of any search, rather than an optional “nice to have.”
But, Marcin, didn’t you just invalidate your assertion that diacritics actually matter? After all, wouldn’t you input “nestlé” instead of “nestle” if they did?
To this, I have a few answers:
Input is not output. This is no different than autocorrect, autocomplete, or other IME helpers.
The very fact that on many keyboards accented characters are hard to input is itself a sign of anglo-centrism of companies that made early typewriters (Remington, which established a lot of European layouts like QWERTZ and AZERTY, employed a person who bragged he didn’t actually speak any languages in a “how hard could it be” way) and then most microcomputers.
There is this really interesting rule, also known as Postel’s Law: “be conservative in what you output, but liberal in what you accept as input.” It’s not universally applicable – sometimes it’s better to teach the user to be more explicit if it benefits them in the longer run – but it feels appropriate to me here.
Why does it matter specifically for the ⌘F and the tab search experience? I have this personal theory: the simplest the search, the more the users will blame themselves if it doesn’t work, and assume the tab or the string just isn’t there, rather than rewrite their query. That’s what happened to me. I assumed that the tab wasn’t open and tried to get to it again, wasting time and effort.
The rule might be universally true for any UI surface – the tighter it gets, the less likely we assume it can break. After all, there is a manual for a typewriter, but there isn’t one for the pencil! And these UIs do feel positively basic; they are small windows with basically one input field and an immediate as-you-type reaction.
Turns out, the startup melody wasintentional in this particular model. The power converters have to adapt the current from the overhead line to convert it to the three-phase motors of the locomotive, and that generates a rising tone. The engineers decided to change the logic to increment the tone in precise few steps resembling a musical scale, rather than allowing it to rise continuously.
I debated whether to include this on Unsung. I guess it is software, even if it’s attached to the hardest of hardware. And sure, it’s “just” delightful, but it is still kind of nice to see someone go extra, adding a human touch atop a technical process that had to happen anyway.
But then, it reminded me of something. No, not the poor CSIRAC trying (and similarly struggling) to become a musician. Rather, a “musical road” built in Lancaster, California, where the engineers messed up the execution, creating a truly unpleasant, atonal melody. David Simmons-Duffin wrote a fun essay in 2008 analyzing the “bug” thoroughly, including useful visuals, and even replicating the problem. Subsequently, Tom Scott visited the road and made a video about it ten years later.
It won’t surprise you that the cause of the bug was bad hand-off between designers and engineers, but there can be no software patch for grooves you cut in asphalt – and so at least as of last year, the embarrassingly sounding road was still there.
Turns out that the breathing light survives, sort of, not really, in an Apple product today:
The AirPods Pro case does this when charging – right at the start, or when you tap it later. But it disappears after a while, the pace is now 28 breaths a minute (over twice as fast as the original iteration), and the light is orange.
Is it still the same thing, reflecting on how smaller organisms breathe faster? Or is it mostly an unrelated idea, with the light fading in and out indicating activity rather than lack of it? My money is on the latter – the light turns white when pairing, too, and it cycles even faster then – but it was nice to imagine the return of the old feature for a second or two… or 2.1, to be precise.
This DOS demo called Wake Up! is astonishingly small – only 16 bytes:
The demo doesn’t just make QUOD feel gargantuan. Output this one solitary emoji, “Woman Technologist with Light Skin Tone” – 👩🏻💻 – and you spent all your 16 bytes, too. (Proof!)
The creator’s write-up is a bit hard to follow, but there are some interesting aspects to it: “stealing” the beauty from math itself, the reliance on the environment being set up properly (to avoid wasting precious bytes on initialization), and the tight connection between the hardware, the visuals, and the sound.
Oh yeah, in case you haven’t noticed, this has sound! Two out of 16 bytes are devoted to its production, using an existing BIOS function that slots nicely into the existing graphics routine.
This is another recent demo that caught my attention: NINE, from about a year ago:
The platform here is a computer of a similar vintage as the early DOS machines, Commodore 64. C64, like many other home microcomputers, supported special graphical entities called “sprites,” which were used for gaming since the rest of the graphics couldn’t move very fast. (Today, your mouse pointer is conceptually similar to a sprite, being imbued with special powers unavailable to anything else.)
C64 could output up to 8 such sprites. The demo inexplicably has… nine.
The NINE demo didn’t focus on absolute minimalism, but instead employed a barrage of ghostly (and ghastly!) trickery to achieve something that was thought impossible. This time around, the explainer from the author – a 22-minute YouTube video – is filled with great storytelling, and absolutely worth a watch:
I think both of these showcase two things that I appreciate and that translate to great UX design as well.
The first demo shows tight integration between design and the capabilities of software and hardware. Let’s pick the sound routine that needed just 2 bytes. If there wasn’t a way to output sound within this extremely tight budget, the author likely wouldn’t fight to their death to get sound… they would instead focus on what else was possible within two bytes. This is getting as close to full understanding of the medium you’re working in as possible.
The second demo highlights how sometimes you can use absolutely horrid sleights of hand to achieve something beautiful – and how you can perhaps find beauty in those sleights of hand, too. It reminds me of the quote attributed to Teller (of Penn & Teller):
Sometimes magic is just someone spending more time on something than anyone else might reasonably expect.
Penn & Teller talk a lot about how there are only two keys to their success: going further than others would think, and not worrying about employing inelegant tricks in service of something that would appear to be of utmost elegance.
Today’s computing limitations are different than the ones from the 1980s. But a lot of this attitude can still be helpful, even four decades in, and even if your work seems as far away from the demoscene as you can imagine.
The iOS 26 update introduced a bug in the Czech keyboard. Instead of the customary háček (ǍǎĚěǦǧǏǐǑǒǓǔY̌y̌) in the bottom row, another key was duplicated, removing access to the accent character (or, a diacritic) very popular in that language.
Here is the before and after of this situation:
Ordinarily, this can be frustrating but not insurmountable; you can always copy/paste, rely on autocorrect to help out, or even add some topical text replacements for common phrases. The problem is that this bug only appeared on the keyboard used for logging on, and at least a few people used that character in their password. There, none of these workarounds were available – and so those people were now completely locked out of their iPhones.
The Register reported on this on April 12, and a few days later suggested that Apple was working on a fix. I won’t keep you in suspense; I just verified that the fix landed with the recent May 11 update.
This is, in an of itself, not a fascinating story, but with interesting things to talk about at its periphery.
First of all, The Register never showed a single screenshot. This led to a lot of confusion and speculation in the comments. Turns out, screenshots are valuable not just with bug reporting, but also with bug reporting.
Second, check out this Czech keyboard. Even within the limitations of the ancient QWERTY, there’s a lot of cool stuff happening here. Two new accented keys just appear on the top layer when you switch to Czech. Both have magical properties, too. They’re the modern “dead keys” that either stand alone, or get combined with the previous letter if that makes sense.
This is the stuff typewriters, and even desktop keyboards, could only dream of. But, as always, more software means more bugs, including some with unforeseen consequences; a typewriter could never break this way.
Thirdly, there is this interesting tension between us being led to believe “more interesting passwords are safer,” but then sometimes being penalized for actually making them interesting. A decade ago someone used emoji in their password without realizing they won’t be able to input it, and I’m sure there were other examples.
But the most interesting, to me, part? It’s the diacritic itself. Under one of the posts, a commenter wrote:
Stick with the 7-bit ASCII subset. You will never go wrong.
7-bit ASCII basically means “26 Western letters and nothing else.”
I hate this. I know it’s objectively true – in the late 1980s I felt a sense of relief my name didn’t have any of Polish language’s nine diacritics, which would complicate my life. Even just yesterday in Germany, I spotted this:
Software still struggles beyond ASCII. But this is why we need to keep pushing. Diacritical characters are to be found everywhere in the world. They’re detailed, and varied, and filled with histories. Umlaut is not diaeresis. Kreska is not the acute. A háček is not a breve. They’re rarely optional decoration, and often not even decoration at all; learning about Turkish dotless i might completely upend your understanding of what’s an accent and what is not.
If you don’t have a favourite diacritic, you are missing out. Even the names – grave! ogonek! horn! – are beautiful. (Háček is also known as caron and a wedge depending on context, and in other regions referred to with beautiful words kvačica and strešica.)
A simple rule for overflow logic that will prevent your app looking a bit stupid…
…is to avoid “more” expanding to just one item. If the expansion takes up as much room as the UI to show the expansion, why not show it in the first place?
A reader asked me this, and I thought I will answer here:
One bit of challenge with [where I work] is that my audience isn’t already almost-guaranteed to be into design! They’re hopefully interested in making good software in general, though, and probably curious about the app [I’m building] they could be using. I’m also afraid that developers sometimes confuse “easy to use” with “beginner-only, limiting”, which makes it harder to write about streamlining UIs; there’s only so many times you can invoke “reducing mental load.”
I love this question because it gets to the core of why I started this blog. I’m perennially unhappy with the conflation of “craft” with “delight,” and the subsequent narrowing of “delight” into “cute strings and slow animations.” In the famous words of Steve Jobs, “Design is not how it looks. Design is how it works. What’s tricky is that they’re sometimes related, and even if you learn how to tell the difference, your exec team probably never will.”
I am quoting from memory.
Anyway, I hope spending time on Unsung – please like and subscribe – helps with examples of what to talk about and how to talk about them. But, just to list some alternatives to “reduces mental load” for well-made software that come to my mind:
is more efficient
gets you home earlier
will allow you to spend more time on things you enjoy
will allow you to choose which parts of the problem to spend time on
reduces tedium
understands and practices progressive disclosure
understands you
speaks your language
learns your preferences
meets you where you are
is made by people like you
respects you
will make you better at what you do
rewards mastery
doesn’t dumb things down
will teach you concepts helpful in other software
never takes control away from you
is easy to customize
adapts to you
doesn’t disobey you
will make you look good in front of others
respects history and legacy of the space
is built well
is conceptually/systemically beautiful
is well-considered or thoughtful
There’s more, and I am curious what comes to your mind and how you all connect with developers! But maybe just going through a list like this will provoke some ideas.
(Of course, if you cannot honestly claim some of these about software you’re working on, and you think they’re important – I guess you have some work to do.)
Software should be as small as it can be. Not as a gimmick, but as a discipline. The floppy disk is the measuring stick: 1.44 MB. If the software that ran entire businesses could fit in that space, then a modern, focused, single-purpose tool certainly can.
In my own work, I have mostly focused on the web side of this equation, as this is where the situation feels the most dire: tens of megabytes dedicated to heavy frameworks, unnecessary tracking scripts, and video ads have a real negative effect on experiencing websites. Progressive loading challenges also make it harder to offer a great experience.
But space considerations are starting to feel more pertinent to local software too, in an era where SSD and hard drive prices are going up, and where local LLM models start taking up more room.
Also, this passage feels very Unsung, and is exactly why the tag #history exists on this blog:
I don’t miss floppy disks. I miss the mindset they demanded—that every byte matters, that constraints breed creativity, and that software should be light on its footprint.
If you reduce tech history to just nostalgia, it won’t be that useful. But if you look at it as inspiration, you might find some truly wonderful and meaningful stuff in there.
On that note: Bonus for a nice classic domain, and a nod toward Mac’s most famous screensaver.
To me, “tap anywhere at the top to scroll to the beginning” is an amazing and underappreciated mobile gesture:
It not only provides an alternative to desktop‘s Home and ⌘↑ keys, but the student laps the teacher here; it’s actually better than every way to scroll to the top on desktop (do you like pressing ⌘↑? do you even have a Home key?), and it’s an icing on a cake of a regular flick to throw the page to the top already being pretty nice.
Tap to return to top is also distinctively mobile in that it allows you to tap just anywhere near the top edge that’s not already a tap target; as far as I can observe, traditional GUIs detest being imprecise in this way, always asking you to click on something specific (although window moving on macOS in the post-title-bar era is also starting to feel similar).
The iPhone gesture seemed to work so well that, over the years, more patterns started borrowing from it. In Bluesky and tons of other apps, you can tap on any tab with scrollable content a second time to scroll all the way to the top. (Again, something that’s hard to imagine on desktop, where you pretty much almost never think of clicking on an already-selected item.)
It’s not just the top, either. In Podcasts, tapping Home goes back to the left:
And in Photos, to the bottom:
To me, the whole “tap to return to the beginning” gesture universe feels ascended to be the core property of the interface. In that way, it is similar to scrolling, undo, copy/paste, arrow keys moving the text cursor, and so on, all inducted to the National Register Of Historic Gestures.
Why? Because these gestures can only blossom if they work consistently, everywhere. You need to start trusting them so much they slide into your subconsciousness. Breaking the gesture in one place will make it less trustworthy in other places, too, ejecting it from motor memory back to the level of deliberate effort, and therefore making it a lot less usable. “Does this thing work here or not?” is a death knell of flow.
The fact that tapping on tabs is idempotent means there’s also no penalty; if you’re already at the beginning but are not sure, tapping it mindlessly won’t hurt or send you back somewhere else.
This is all great. And this is why I’m unhappy Safari started mucking with it.
Safari has tabs at the bottom – starting with two (regular set and “private” set), although you can add more. Above is a long list of site cards, with newest at the bottom. It’s exactly the same situation as in Photos, and yet tapping on either tab doesn’t restore the scroll position. Instead, it opens the settings dialog:
And, tapping around the buttons does nothing.
I would imagine Safari is a pretty important app used by many people, and so this feels like a bad place to introduce an inconsistency that could have a more serious consequences of un-teaching people about tap to scroll to top in the long run.
The funny thing is that the solution is already there: you can tap ··· in the upper left corner to get to the same functionality. The long press on the tab also opens the same menu.
Messing with a “tap to go back to the beginning” system gesture like this means to me the design team doesn’t fully share the understanding of the value of their own creation, or maybe that stewards of the gesture system are not vigilant… or perhaps the awareness is there, but the caretakers aren’t recognized, rewarded, or empowered enough.
It’s similar to the “no, thanks” example I shared before, a possible worrisome tragedy of the UX commons in the making if the respective teams do not change course. Because, wedging that sort of an exception in – even if you have a great set of reasons in the moment – creates a precedent. Inevitably, from my experience, the next team that will want to override scroll to top, or misuse “No, thanks,” will now require less of a justification.
This video combines my first 5,162 attempts to speedrun Super Mario Bros. I recorded 193 hours of attempts (and practice) on an original 1985 Nintendo Entertainment System, then I wrote a custom computer program to process those videos and combine them via machine learning and conventional image processing techniques.
This is not just fun to look at, and – presumably – study as you’re speedrunning yourself. A sign of a good visualization is that it makes you see stuff that you haven’t before and here, at some point (after 1:42), you start noticing strange comb-like patterns in Mario running.
Turns out this is actually a thing called a “frame rule,” a quirk of game’s timing code where it only checks for a completion of the level every 21 frames, or one third of a second. That means that for every level after the first one, your start will be rounded up to the nearest 21st frame:
The analogy often given is to think of a bus that leaves every 21 frames, and levels can only end by getting on that bus, and so other than in the last level (which has no new level to load at the end of it), improvements in Super Mario Bros. can only happen in 21 frame increments. If you save a frame or two in a level, but it’s not enough to make the previous frame rule, it’s not enough to take the previous bus, you’ll just end up waiting for it to happen anyway.
Stay tuned to the end of the video for some fun stats, and click through in the description below to see the same tech applied live during an in-person speedrunning event.
I like sharing, thinking about, and revisiting basic rules and principles because they really do ladder up to help you with more complex things down the road.
I wrote before how a simple rule to give some breathing room to your length-limited edit fields can be upleveled to a more general “let me color outside the lines when I’m editing” principle. This is another example of a similar situation.
I am in Buttondown, which is a mailing list software. I created a quick test draft just to check something out in the editor, I didn’t do anything else, and then I proceeded to delete it. Then, I was greeted with this:
This is nothing more than a larger version of the “You have 1 email(s)” problem. There might be a situation when I’m deleting something that has been published and linked to. In that case, it’d be good to know about how any links to that thing will cease working.
But this is not that kind of a situation, and the software has all the info to know that. In this moment, it could show me a simpler, much less alarming message more appropriate to my situation. This is not the end of a radio pharma ad where you have to rattle out all the legal disclaimers just in case something could happen.
One tiny counterexample from my neck of the woods: in Figma, when you start writing a comment and then exit without posting it, you get a little warning. But you don’t get that warning when you type something that’s <= 8 characters. In this case, the assumption is that retyping a few characters elsewhere (assuming you haven’t just changed your mind altogether) is much easier and faster than cognitively processing and dismissing the warning.
The challenge with Buttondown’s dialog is that this is more than just extra cognitive processing and “cheapness.“ Here, the stakes are higher, as we’re talking about something adjacent to data loss; the dialog really does feel a bit scary and makes me think I can do some real damage in a situation no real damage is possible.
Software engineer Ajitem Sahasrabuddhe recently wrote a 6-post series called “Iron Core” about airline ticketing infrastructure. The entire series is probably too software engineer-y for us, but the third part has some interesting info about a particular 1960s user interface called “cryptic mode”:
Cryptic mode was born from a hard constraint: teletype terminals in the 1960s billed by the character transmitted. Every keystroke cost money. A command that took 50 characters instead of 10 cost five times as much. Commands were compressed to the absolute minimum.
The result is a domain-specific language whose syntax was shaped entirely by economics. AN for Availability Next. SS for Sell Segment. NM for Name. ER for End and Retrieve. No vowels wasted. No words spelled out.
Apparently the official name is “native mode,” but it gained its nickname because… well, see for yourself.
Asking the system for “Availability for Next flight” for February 8, from Nagpur to Delhi, is just 13 characters:
AN08FEBNAGDEL
And the system responds in an equally mysterious way:
** AMADEUS AVAILABILITY - AN ** NAG DEL SU 08FEB 0000
1 AI 416 Z9 C9 D9 Y9 B9 NAG DEL 0840 1030 32A 0
2 AI 416 M9 H9 K9 Q9 T9 NAG DEL 0840 1030 32A 0
3 6E 5317 S9 T9 W9 V9 Q9 NAG DEL 0840 0755 32A 0
With time these commands became wrapped inside more approachable interfaces and GUIs. But they exist under the hood and…
Many experienced travel agents still use it today alongside, and sometimes instead of, web-based agent interfaces such as Amadeus Selling Platform Connect. For a trained operator working a booking-heavy workflow, it is faster than the equivalent graphical interface for the same sequence of operations.
Except today, you get to choose. At the beginning, when “online” didn’t imply internet, and registration computers looked like this, you didn’t have a choice: this was the language you had to fluently write and read.
In light of a recent Googlebook announcement that uses a mouse wiggle gesture for AI (which to me doesn’t seem like a pleasant interaction), some of us were talking about how, on macOS, mouse wiggle helps you locate the cursor by making it bigger.
I am maybe a sucker for videos and podcasts where people start laughing, but here we go – a very short video about a version of Linux that “does not limit how big your pointer can get if you wiggle the mouse pointer”:
It explains those weird moments where sometimes the computer asks you to wiggle your mouse – to generate unpredictable numbers – although the specifics of what exactly was random in my wiggling was a surprise to me.
There is something poetic about computers yearning for that one thing they can never get – complete unpredictability – and collecting it in a little pool like you would something very precious. Also fascinating that in modern CPUs, there now exist hardware components that gather truly random data from the real world.
While I have never needed true randomness in my design career, knowing how to control pseudorandomness (specifically, how to replay it) has been helpful.
Here’s an example. In my essay about Gorton, there is this interactive bit where you can drag a slider for “messiness.” With regular pseudorandomness, the experience is wiggly and gross:
But when you always restart the prng from the same seed (“the Groundhog Day maneuver”), it feels much better:
Maybe it really is possible to build a web app that feels platform native. But I have never used one — not once — and for this mess to be increasingly used in the industry-standard professional suite of creative tools is maddening.
I think it is possible – especially in the realm of classic form fields – but you really have to care and step up and test and replicate a some stuff that the operating system controls give you for free. (As an example, if the web platform/Electron don’t give you access to the “keyboard navigation” OS accessibility setting, you’ll need to build a bridge from the OS to pass it through. This is how Figma’s Electron app got haptics, for example.)
It is true that we don’t see that level of effort often. But there are also bad native interfaces, and there might be more; Roger Wong recently made an interesting observation that stuck with me. Emphasis mine:
The mechanism differs but the outcome is the same: the platform stops being a place a designer can rely on. […] [Text user interfaces] are back because the platforms quit, and the curriculum can’t fix that.
I think I agree with this; I’ve felt there haven’t been a lot of improvements in native desktop interfaces recently.
In the mid-1990s, Apple was losing to Windows 95/98, and after years of falling by the wayside, the team eventually got their priorities in order, and rebooted classic Mac OS into a (I believe generally successful) Aqua. And in later years, Apple as a whole has often been good about creating extra distance from the peloton even if there was no immediate danger of being overtaken.
But not here. Windows lost its way, and perhaps even the memories of the darkness of the 1990s and the revival of the 2000s are now forgotten. Even if Liquid Glass was executed extremely well, macOS would still feel bereft of true evolution and care. I know there have been some slight improvements to window tiling and more recently Spotlight, but little of this betrays urgency or suggests a vision.
Finder feels like it’s been abandoned for over a decade. AirDrop UI is worse in use than many of the file sharing interfaces that came before it. This common UI is stuck in the state of the art of display colour science that is out of theprevious century:
Just on the topic that is fresh on my mind: Why does Shortcuts feel like a toy in all the moments it shouldn’t, but few of the moments it should? Why does the keyboard customization situation feels so messy? Or, why are both macOS and iPadOS still stuck in the ancient way of thinking that menu bars contain all the app’s commands, when the modern approach is: it’s command bars that do, with menus containing only a subset? An innovative modern operating system would offer a universal API for command bars that any app that wants one could use – instead, apps invent their own with varying levels of success and UI quality, and automation tools cannot do much since nothing’s compatible. (This in particular is an example of an area where web apps started leading the way.)
These are just some examples that come to mind. It’s true I have admired and been inspired by some work done on Apple TV and the Vision Pro, but we also have to acknowledge that designing for net-new platforms is in many ways easier than for legacy ones.
2.
Back to Photoshop. In the Hacker News thread, at least one person from Adobe dropped in to comment, and one paragraph caught my attention:
These changes were part of the Beta program. As far as I am aware the response there was not on the same level as this blog post.
It’s not my intention to pick on this Adobe employee, and I am not aware of the specific of their beta program (although I have used Photoshop in beta for a few years). But from my experience, this is why beta testing fails in this regard:
People in beta programs might be more lenient and excited to experiment.
For obviously broken small UI things, people will be more inclined to think “oh, they will surely take care of that in the polish phase.”
In general, reports of smaller UI things are less likely than bigger functional bugs like “this is not working” or “this is really slow now.” You really have to encourage and reward and incentivize people to do that, and usually identify the right people first, too.
Please excuse my directness, but Photoshop’s user interface has felt low-quality for at least a decade now. There are a lot more examples. It’s hard to expect people in the beta to flag small UI stuff – including literal broken windows – when the evidence all around them is that the company doesn’t care.
Just because we all encounter interfaces doesn’t mean everyone knows how to identify the things and say the words and connect the dots, especially when it comes to generally undefinable and unmeasurable craft. Good UI is deepexpertise. Just like you cannot research or data science your way out of fundamentally bad product decision-making process, you also cannot add craft through relying on your users to tell you. You need to foster this on the inside.
3.
Oh, and when I say “broken windows,” I’m not just being cute. Here’s an example of Photoshop’s “explore” halo that occasionally appears on top of another app just because I have Photoshop open underneath. And, there is nothing I can do in Photoshop to get rid of it:
I think there is something fundamentally very broken with Photoshop’s (custom?) window management, seeing how PS windows jump in front of other applications, or how PS breaks other apps’s mouse pointers. But that’s a story for a different post.
The best thing the crypto industry coined might have been the expression “rug pull,” but I’m not happy about that. To me, it perfectly describes how it feels when an app or a website randomly changes your scroll position for no rhyme or reason.
You’ve seen it so many times before:
you start reading a webpage, but it throws you back to the top when JavaScript finishes loading,
you start reading a webpage, and ads or other stuff appear and shove you around up and down,
you press a back button and that goes to the previous page… but to its top, rather than where you actually were,
you zoom in or out, the position isn’t recalculated properly, and suddenly you see a different part of the page and lose your orientation.
To me, the scroll position is as sacred as the mouse pointer position, given the two are related whether Scroll Lock is around or not: one is you, the other is the world around you.
But there are moments when software scrolling with the user or even for the user is appropriate, and here’s one example:
When you switch tabs, the content below should always scroll to the top, but it doesn’t here.
Here’s an even worse example, also from Settings:
Why should the content scroll to the top here? Because in these situations, the fact that the content container gets reused is just a technical quirk of the implementation. From the user’s perspective, this is all new content, and new content should always start at the top. Otherwise, things will get confusing really fast; imagine it especially in the default configuration without scrollbars, where you might assume result number 6 is the first result, or completely miss the most important, topmost options.
Randomly found this 2014 Dribbble from Jamie Nicoll and it made me smile:
For context, Save For Web was a popular export function in Photoshop at the peak of its use for web design, but assigned a rather unpleasant ⌘⌥⇧S shortcut. Using it often turned your hand into a… claw of sorts.
There was a Tumblr cataloging real and humorous photos of people pressing Save For Web. You can still find parts of it on Internet Archive, and here are some choice photos:
This is funny, but I actually found it enlightening – and lightly frightening – to ask coworkers how exactly they press common shortcuts like ⌘Z, ⌘C, ⌘V, and so on. There was a lot more variety than I expected.
(My basic heuristics say: three-modifier-key shortcuts should not be assigned to anything used often.)
How do you squeeze a city that occupies over 50 megabytes into the 32MB memory of the console? You simply do what The Truman Show did, and construct the city around the player as they’re moving around:
This has, as you can expect, a lot of technical and even game-design consequences, and the video goes into a lot of detail on these – including Brown rebuilding the Grand Theft Auto 3 source to visualize things better.
This technique is also used in interface design, for example if you have a really long list of things that would take too much memory or GPU power to render. What the video calls “streaming” is, in the context of UI, often called “virtualization”: instead of having a full long list (or an entire world), you abstract it away – or, virtualize – into something nimbler.
Some of the challenges and techniques used by Grand Theft Auto 3 apply pretty directly here, as well:
you can use UI skeletons as “low poly” models,
in some contexts, you can guess the user is more likely to move in one direction (for example, going through fonts in a font picker), and more eagerly preload where they’re going to look next, rather than symmetrically in both directions.
On the other hand, “speedy players” and “pop in” can’t ever be solved because any UI list is random access, and slowing users down is not typically appropriate; better to make loading as pleasant as possible than introduce any roadblocks, even if figurative ones.
Since the early 2000s, Mac OS X had a few orientations of icons depending on whether they were applications, files, utilities and so on:
In 2020, macOS Big Sur unified those styles and made them more iOS-like:
A few years later, Jim Nielsen revisited the icon “Big Sur-ification”, and showed examples of apps that did the transition really well, but also those where the transition felt… lazy, essentially shoving their previous icon into a roundrect.
For those, Nielsen proposes some alternatives that are delightful to see:
The Word/Excel/PowerPoint/Outlook explorations are particularly nicely done.
In his latest video, Shelby from Tech Tangents unpacked, installed, and put to use a truly forgotten product: IBM 3119, one of the first consumer flatbed scanners.
The setup was a small nightmare, needing a rare hardware card installed in a specific computer, an ultra-particular combination of two operating systems working in lockstep, and even some careful memory balancing.
Even after all that, a 300dpi page scanner in the late 1980s was still a force to be reckoned with. It’s hard to remember how enormous scanned files were compared to anything else then, even on a black-and-white scanner like this one. The video shows a simple 90-degree image rotation in highest quality requiring over 9 hours, and I believe it.
But deep inside the video, at precisely 19:31, for only ten seconds, something appears that is absolutely worth celebrating. The nascent scanner software has a “curves” feature that allows you to redraw the shades of gray to capture shadows, highlights, and midtones exactly how you want them. Today, the feature would look something like this, with a real-time preview:
There would be absolutely no way to do something like this in the late 1980s, when just rotating an image is an overnight operation, right? And yet:
How was this accomplished? Absolutely brilliantly. Remember the palette swapping technique? Here, the entire screen’s palette is 256 shades of gray. It’s a very particular kind of a linear palette, and so you can easily take that line and… well, turn it into a curve. Since palette swapping happens on the graphic card, it takes as little as one frame of time, allowing for it to react to mouse movements as they happen.
This must have been mind blowing to experience in the moment. Sure, it’s only a preview, and actually applying curves to the image would take many minut—
No. This is a wrong frame of mind. Here’s my hot take: There are moments in software where the preview is more important than the feature following it. That’s because the preview making things faster isn’t just the difference between finishing something sooner or later. It’s a difference of doing something or not doing it at all. Would you even attempt to use curves if each adjustment took minutes or hours, especially in a land without undo?
I love this preview that hints at what the future will be. I like this clever use of extremely limited technology and tight collaboration between engineering and design. It must have been nice to be in the room whenever someone had the flash of insight to use palette swapping this way.
I have a confession to make. I prefer Apple TV’s 2015 remote:
The remote was universally ridiculed for its “which way is up?” problem – too much vertical symmetry which didn’t give your hand enough cues to know whether you’re picking it up the right way or the wrong way.
Apple tried a half-measure first; in 2017 they broke the symmetry by making the MENU button slightly distinct in visual and tactile ways. Hindsight is 4K, but I don’t think it had a chance of working – the tactile cues were too subtle, and the visual ones do not matter when you’re not looking:
So Apple overshot – the subsequent 2021 edition was a full-measure-and-then-a-half:
The remote shrank the touch surface but otherwise drastically increased the volume, and added four arrows, two new buttons, and a strange iPod-inspired clock wheel interaction on top. And to me it started feeling a bit complicated, inching toward the very TV remotes that earlier designs ridiculed. (It also wasn’t as pleasant to touch, as the buttons feel a bit rougher.)
But the reason I like the 2015 remote is primarily because it introduced one of my favourite gestures in recent history: tap to see progress.
It’s hard to describe how wonderfully light this interaction feels every time I use it. You just tap anywhere on the remote’s top half, you see where you are in the video via a subtle UI, and then wait a few second for it to disappear. After this, doing the same in every other player – YouTube, Netflix, HBO Max, anything on a Mac or even the iPhone – feels clunky and heavy. In many of them, you can’t even see were you are without stopping the video!
It gets better. Tap for the second time, and the elapsed time gets replaced by current time, and the remaining time by what the clock will say whenever you’re done watching. I thought this is delightful and clever, sneaking in clock functionality without showing it all the time.
There is also this really nice gestural separation. When you watch the video, taps and swipes are safe. Anything that is “destructive” – that is, causes the video to stop, or rewind, or fast forward, is on the “click” layer: press stronger on the center to pause, or on either side to move forward or back.
What I’m describing feels mechanically similar to other input devices, but the devil is in the details. On smartphones, everything is a tap, so you don’t really get anything lighter. On a Mac, tap as a gesture could only be available for people who opt in to press to click on their trackpad (like I do) – but the fact that tap is the default for clicking, means that can never realistically happen.
The Apple TV tap feels conceptually like Mac’s hover instead, but so much more pleasant and elegant and simple. (I want to prototype tap on a Mac as a lightweight “explainer,” showing tooltips there instead of on hover.)
To be fair, the tap gesture still exists in the still-current 2021 Apple TV remote, too – but the tap area is much smaller.
And just in case you were curious, these are the first two editions: the 2005 remote – shipped with the iMac, predating Apple TV – and the 2010 remote. (I’m referring to model years, because Apple’s own names are so confusing.)
I don’t have access to Apple’s user feedback, but I guess that Apple’s 2021 design was likely the very right thing to do. But looking at four-and-a-half of these models side by side, I am still in the 2015’s minimalistic, unusual, innovative corner.
This year was a doozy. We specced and scrapped several different ideas in the months leading up to today. We finally settled on today’s concept just 3 days ago. The need to do something simple was a really useful constraint, and we leaned into the idea of making something primitive but deep.
The team seems to have had a lot of fun with it, including even JavaScript being encoded in Morse Code (the link in the blog post no longer works, but you can still see it on the Internet Archive).
Goodhart also wrote about the immense challenge of adjusting the Morse tapping speed to the user, which counterintuitively ended up needing… adjusting the user to the speed. But the best part is that the server communications used the Morse code in URLs, as well:
We took great pains to make the API for this project use morse code in the transport. If you take a look at the network inspector, you’ll notice that the URLs requested have morse code in them.
This worked for every combination of letters imaginable, with two oddly specific exceptions: a solitary E, and a solitary I.
I liked this description of what transpired next, which would have made me think I was going insane, too:
Then, an even stranger thing happened. I copied and pasted the correct URL into my browser and pressed Enter, and right before my eyes, it deleted the ”.” from the end of the URL and returned a different result.
I was delighted to discover an answer here, not only because in retrospect it’s such an obvious thing that was staring us all in the face for decades, but also because it has interesting URL construction consequences.
The Pixar animated short Lifted was released in front of Ratatouille in 2006:
I’ve always been amused by this imaginary interface, which is so clearly not how any sort of computer would work.
Or so I thought. These are photos I took in Melbourne in 2024 of CSIRAC, Australia’s first digital computer from about 1949:
This is a “console” of the computer, used to tactically probe or input specific memory addresses (in binary), and to control functions like stopping and starting the program. Any proper programming and eventually inputting data would happen using gentler I/O devices like typewriter keyboards, paper tape, and magnetic storage.
Physical consoles like this one were last seen in the 1970s on hobbyist home computers such as the Altair 8800, and the Console app on your Mac diligently spitting out logs is its spiritual and virtual successor. But even if a CSIRAC console feels hostile today, 75 years ago it was quite the opposite:
And [CSIRAC] helped there too. It could display all its working registers and the last 16 instructions executed. It could be given an address at which to stop (a “breakpoint”), and be stepped by one instruction at a time. It even had lights to show the computer’s internal states. This was a user-friendly computer.
CSIRAC stood for Commonwealth Scientific and Industrial Research Automatic Computer, a typical naming scheme of the era. We also got ENIAC (Electronic Numerical Integrator and Computer) in 1945, BINAC (Binary Automatic Computer) in 1949, EDVAC (Electronic Discrete Variable Automatic Computer) in 1946, ILLIAC (Illinois Automatic Computer) in 1952, and then SEAC, SWAC, ORDVAC, TREAC, AVIDAC, FLAC, WEIZAC, BIZMAC, RAMAC, and UNIVAC.
The story goes that the name of 1952’s MANIAC (Mathematical Analyzer Numerical Integrator and Automatic Computer) was chosen to highlight and put a stop to the goofy naming practice. Did it work? I am not sure. Not only two more MANIACs were produced, but we also got 1953’s JOHNNIAC (nicknamed “pneumoniac” since it needed a lot of air conditioning), and SILLIAC (Sydney ILLIAC) in 1956. The last computer I can find using that naming scheme was TIFRAC, operating in India between 1960 and 1965.
CSIRAC had real work to do, but today it is known chiefly for being the first computer to play music in real time. The quality is… I’ll let you judge, with links below pointing to short MP3s preserved by Paul Doornbusch and subsequently Internet Archive:
Engineers working on other room-sized computers of that era did similarthings; whether this was solely one of the first attempts to humanize the big scary machines, or a distraction from the computers’s typically military uses is left as an exercise for the listener.
Today, one of the 1960s machines still plays music, headlining a fascinating annual tradition – every December, the PDP-1 restoration crew at the Computer History Museum in California invites visitors to sing carols with the computer older than most of them.
The last photo takes us back to where we started. Neither CSIRAC nor PDP-1 might be user-friendly by today’s standards but damn, wouldn’t you want some of your computer’s interface to feel this way?
I was inspired by the video, and really enjoyed its exploration of a demanding game that’s composed of just a few mechanics that are done really, really well:
The number of inputs are small, but the expression those inputs allow is deceptively expansive. […] Derelict Star’s various areas are all built to explore the way movement systems function and even interact with one another.
I think of user interfaces similarly, and of their need to build a certain consistent vocabulary of names, gestures, interface elements, concepts, and so on. Perhaps in an enterprise app you right click and discover something useful in a menu, and this will teach you about the usefulness of right click menus in general. Maybe pressing ⌥ to get to alternate symbols on your keyboard would inspire you (either consciously or not!) to try holding ⌥ in said menus, only to discover this brings up useful alternative options. Maybe seeing a keyboard shortcut next to one of these options will suggest to do that next time, and so on, and so on.
I really loved this bit in the video that could apply to a lot more software than just videogames:
It took me maybe an hour to do this, but right on the other side is a checkpoint. The game is hard, but it isn’t cruel. It’s designed to challenge you, but it has faith in your ability to complete it.
The narrator uses the term “ludocentrism” to refer to games that ruthlessly prioritize the mechanics and gameplay over narrative, aesthetics, and so on. (“Ludic” meaning “relating to play.”)
Of course, the calculus of what videogames care about will be different than goals of creative software or enterprise software; no one cares about the hero’s journey of the largest number in your Excel spreadsheet. But I think some version of ludocentrism applies to “boring”software as well. My beliefs here are probably something like this:
you can’t reduce everything to just functionality or just efficiency,
especially in creative moments of software use,
and people use software creatively much more often than we suspect, including software not thought as “for creatives.”
Should you ever be worried that displaying just one glyph could take almost 2 seconds and slow down your website by as much? Naw, of course not. This wasn’t a problem already in the 1980s and, in the lord’s year 2026, computers are pretty good at rendering a letter or a symbol at a moment’s notice.
Ha. I was just messing with you. Of course you should alwaysbe worried about fonts. All the time. Typography is beautiful, but fonts are brutal. They will constantly put you to the test, they will find ways to get out of alignment faster than a Zastava Yugo, and they will teach you about corner cases in places you didn’t even realize had edges.
Fonts will break your heart like it’s the month before the prom again, and again, and again.
Or, in Allen Pike’s case, break a heart somewhat literally. Pike wrote a nice quick story of the complexity of what needed to happen to show the heart emoji, and how under a very specific set of conditions – a certain browser, a certain emoji font, a certain emoji within that font – this led to an extreme slowdown.
What’s really interesting is that in order to fix it, Apple can either improve Safari or the font itself, and at the moment of writing, it wasn’t clear what was the right thing to do. (Oh, yeah. Fonts don’t just have bugs. Fonts have many kinds of bugs.)
Another interesting in-between-the-lines thing is that Apple’s emoji are perhaps the only survivor of the original skeuomorphic pre-iOS 7 era. Even today’s emoji party like 2008 never ended – still glossy, still textured, still bitmapped. I’m curious whether somewhere deep inside Apple, there exist exploratory designs for flat, vector versions of emoji that never saw the light of day.
Screwdriver handles evolved over the decades in response to user needs and usage patterns, with a few clever affordances: some for everyone, some for specific use cases that might not be obvious.
I think by now all the basic onscreen UI elements – input fields, pop-up menus, checkboxes, buttons, top menus, sliders, and so on – have similar richness, as do all the core input devices like a keyboard, a mouse, a trackpad, or a touch screen.
That doesn’t mean that everything is set in stone, that no changes are possible, and that stuff that fell out of favour can ever be taken away – after all, computer usage, input devices, and conventions are evolving much faster than screws at this point – but that one has to be aware of the history so that the changes are intentional, not accidental.
A few select comments from under the video that I found interesting:
The Craftsman handles are also different colors for Phillips and slotted screwdrivers.
The fluted handle was patented. So anyone else wanting to make a screwdriver would have to pay the patent holder. So they tried alternatives to make more money. That is the real reason until the patent expired. Plus if they invented a “better” way and held the patent, others would have to pay THEM.
The Swedish word for screwdriver is “skruvmejsel” with literally translates as “screw chisel.”
It’s hard to be in charge of continuity on a movie set. It would already be difficult under the best of circumstances: after all, you can’t freeze the sun in the sky, prevent hot drinks from going cold, cigarettes from extinguishing themselves, or entropy in general from doing all the stuff it loves doing.
But on top of that, scenes are shot out of sequence, and movies are shot out of sequence. There are pick-ups if you’re lucky, and reshoots when you’re not. About the only time your job will be noticed is if you mess up: cue Superman’s reverse CGI moustache, Josh Trank’s Fantastic Four wig situation, Commando’s damaged-then-pristine Porsche, and so on and so on. (This 7-minute YouTube video is a great walkthrough from an expert.)
Apple famously freezes time on their phones in all the promotional materials to be 9:41am. The specific moment they chose is a celebration of the first iPhone unveiling to be at around that time, but it also makes production easy – while people won’t mind that the time on the screen doesn’t match the current time, or even that it doesn’t seem to advance at a normal rate, they will definitely notice if you happened to splice two screenshots with different time side by side, just because you didn’t anticipate that splice as you were preparing them. So it’s easiest just to avoid this situation altogether.
But what I didn’t realize until today as I was recording the previous post’s screengrab is that 9:41am is also enforced whenever you record your phone’s screen via QuickTime. It’s a peculiar feeling: Start recording, and the time on your phone jumps to 9:41. Yank the USB cord out, and it’s back in sync with the universe:
Oh yeah, the date changes too, for the same reason – to January 9, 2007.
In a time-honored Apple tradition, I can’t decide whether I’m annoyed at it (there seems to be no option to turn it off), or admire it.
I want to show you something glorious. This is Bear, the note taking app:
There are desktop apps that get flustered if you ⌘+Tab away and back, misplacing focus or closing a dialog box inside. There are iOS apps that fully reset themselves whenever they get swapped out of memory and have to be reloaded.
But Bear, right here, remembers which note you were on, and exactly where you were in that note, even between phone reboots.
Software is transient and malleable, and one of the hard parts is knowing when that’s beneficial and when detrimental. In real life, you can leave a notebook on your desk, open on a certain page, leave a pen pointing to a specific word – and then depart for a two-month trip to Europe. You will find your notebook exactly how you left it. Why shouldn’t software behave this way?
Also, another thought: This is very likely not something users will complain about when broken, or suggest when absent, even if you go out of your way to open yourself for feedback. Just swapping an app out of memory is hard to understand and “repro” (in engineering parlance). There’s a certain design mindset and taste necessary to notice and care, and a certain vision to carry it through.
The lack of direct user feedback doesn’t mean it’s not worth doing. It just means that there are some things that designers and only designers will know how to properly weigh, describe, and prioritize. If you have a few design-minded users that actually send you feedback like this – treasure them. But most likely this will have to come from “inside the house.”
To me, it’s clear that within Shiny Frog (the makers of Bear), there are people who care about this kind of stuff, and leadership that trusts them. Kudos.
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:
Some time ago, Daniel Kennett created a little utility called Keyhole with a singular purpose:
Have you ever been annoyed by your Mac’s media keys triggering a random video in your web browser, doing something else weird, or by them doing… nothing? Even though your music player is right there?
Me too! And so Keyhole was born.
Keyhole intercepts media transport key presses before the operating system gets a hold of them, and promises to do a better job dispatching them to the right place.
This week Kennett added another feature – the app will monitor the repeat setting that apparently occasionally gets out of whack, and fix it for the user.
We could call these kinds of apps “janitor apps.” I know of a concept called cron jobs, but I’m assuming these quiet workers do backend-y things like moving files around, cleaning up databases, pinging servers, and so on. I am less aware of work like Kennett’s that fixes stuff on the UI layer.
Is it strange that I find this kind of an app pretty… noble? Of course, Apple should fix it; perhaps Bugs Apple Loves could even introduce a serious multiplier for “a bug bothers someone so much they fix it for Apple.”
Of note in the last dialog box: “Keyhole has fixed Music’s repeat setting X times.” I think this kind of a counter is pretty brilliant.
The original 2004 Gmail iteration of the now-ubiquitous modern status bar (here presenting undo send) was internally nicknamed a butter bar because… well, just look at it:
(I believe at least Google today calls this a snackbar.)
The UI pop-up element hosting Google Talk inside Gmail – the very same thing that’s more commonly called a “toast” these days – was originally termed a mole:
The column view in NeXTSTEP was called a browser, but a few years later someone put together a different kind of a browser on that very same machine, and the original term has been sunset – after NeXTSTEP became Mac OS, the view was renamed to “column view”:
These three are off the top of my head. Please send in more!
I know this won’t have the same effect on you just watching. What happened was that, after I clicked on the Disable button, Lightroom moved the mouse pointer for me.
I don’t think I have ever seen anything like this, and it provoked many thoughts and emotions:
This feels wrong. If the mouse is the extension of my fingers, and the mouse pointer the extension of the mouse, this is in effect the app grabbing my hand and moving it.
I did not know this was even possible. I can see how moving the mouse pointer programmatically can be useful in very specific situations (like scrubbing, or accessibility), but… not like this.
If you do something for the user, won’t that make it harder for them to remember how to do it themselves?
I’ve seen this kind of a thing many times in my career: Someone genuinely asks “hey, if this is such a huge transgression, why wasn’t it codified somewhere in the style guide?” But to me the challenge is that it’s hard to imagine everything that needs to be preemptively captured and prohibited. I have to imagine this stuff for living, and I literally did not think anyone would just move a mouse pointer like this.
So seeing this now, yeah, I’d bundle this inside the “some interactions are 100% sacred” bucket, alongside focus never being hijacked randomly (especially in the middle of typing), avoiding scrolling anything until I specifically ask, undo and copy/paste needing utmost protection, and a few more.
In the opposite camp, here’s a fun new project by Neal Agarwal (only worth clicking on a computer with a mouse). This is a situation where it feels perfectly fine for a cursor to be hijacked; as a matter of fact, there is something really interesting about a mouse pointer feeling less like a deity floating above it all, and more like a regular in-game actor.
This reminded me of that time, in the earlier days of Figma, when I prototyped an interaction where you could select someone else’s pointer and press Backspace to delete it:
We didn’t seriously consider it because it felt just too weird, and not that effective in solving “the other person’s cursor is distracting me” problem. But today it feels like it belongs to the same category as the two examples above.
I’ll let you decide if it’s closer to Agarwal’s delight or Lightroom’s terror.
I had some idea that many popular games have mods to tweak them – from small appearance tweaks and fan-made translations, to bigger gameplay or UI changes (and even an occasional trojan horse).
What I didn’t know was that for some games there is a whole community of modders who do one thing and one thing only: they fix bugs that the developer didn’t bother fixing.
I won’t lie: this video was a bit of a frustrating watch. The presentation is dry and takes its time. I was annoyed at Bethesda for not fixing the bugs to begin with and creating the whole mess. Also, some of the people in this story do not appear very mature, and post-Gamergate I have little patience for that kind of behaviour.
On the other hand, this covers so, so many interesting things and provoked so many thoughts:
how hard it is to agree what a bug even is,
how a bug fix can introduce more bugs and be an overall net negative,
how a new distribution method for something can drastically change its nature,
that everything, as always, boils down to communication,
that in community- and volunteer-led projects, not spending time on governance will come back and bite you.
Not to mention these topics:
dependencies
change management
centralization vs. federation
copyright and DMCA
version control
volunteer burnout
issues of trust and ego and power
If you are responsible for bug-fixing processes at a company or with a community, I am curious if you find this video valuable. I did.
The funniest moment was that drama/debacle about a certain in-game portal was nicknamed… Gategate.
Not to mention the ending is truly poetic, and not something I expected.
But also just the settings themselves gave me a sort of competence contact high. A few clicks in, and I thought “oh, they do know what they’re talking about.” So many things here were for me, to solve specific problems I encountered.
It all gave me confidence this is the right tool for the job. (Also, perhaps a corollary: has there even been a bad tool with well-designed settings?)
Compare with also-new-to-me settings from Affinity, which I was much less impressed with:
It uses the troubled right-aligned style originating in iOS, the capitalization is clumsy, and the navigation muddy (it feels like in-page links on the web, which are always confusing).
Is this a fair comparison? Not at all. I don’t actually want to say that CleanShot is better and Affinity is worse. This is so very much east coast apples and west coast oranges.
I don’t even want to say settings are always worth designing well in the traditional sense; sometimes the only thing between you and 20 unnecessary options in your app is simply having no surface that could host them. A limited (but never unpleasant!) settings UI might be an intentional design decision.
But there was a nice quote in the Shadow of the Colossus book: “I often find myself exploring simply because it’s beautiful.” I too became a tourist in all of CleanShot’s settings because they were put together so well, and I was so curious what’s behind the next corner. Its creators understood that the best way to get to know what the tool is capable of is to take a stroll through the settings. I think it’s a good case study at how a proper welcome mat doesn’t always have to be a few onboarding tooltips flying spastically around the screen. Sometimes it won’t look like a welcome mat at all.
A 19-minute video from Tantacrul about a parallel universe that’s right next to ours, but most of us don’t get to think about – typography of fonts for music notation:
The video has some nice things going on besides specific details and conventions: there is a glimps of an obsolete app with a fascinatingly obtuse interface, a mention of modern standardization developments, and even a little (sad?) story of perfectionism and legacy.
I’m also kind of mesmerized by this shot of what music typesetting used to be:
First of all, correction for part 1 – the “focus mode” wasn’t removed. It was renamed to “quiet mode” and relocated to a different part of the UI, and I failed to spot it there. It’s still slightly perplexing, shiftily capitalized, and I doubt fully effective, but the effort is there:
I also want to warn you there will be no more positive things I say in this post.
Now that I’ve experienced the dialog myself in Photoshop 2026, and a few other dialogs that have been upgraded toward what Adobe calls “modern user interface,” how did it fare?
These are 2025 windows and their 2026 equivalents:
On the surface, it feels like a lateral move. I do not personally find the new design language (Spectrum) attractive, or even particularly “modern.” The gestalt remains off and things are still generally misaligned – they’re just misaligned in net new ways.
But it was digging into the window below that showed all the problems in the still-wet foundations…
…and a lot of them have to do with focus.
1.
The first field is not focused, so you cannot start typing the number after opening this window. You need to immediately move your hand to the mouse.
2.
If you click on any field, the value is not pre-selected, so you cannot start typing a new number then.
Principle: Defaults within fields should be easy to “blow away”
When a user activates a field, the current entry should be auto-selected so that pressing Backspace/Delete or starting to type will eliminate the current entry. Users can click within the field to deselect the whole, dropping the text pointer exactly where the user has clicked. The select-on-entry rule is generally followed today. (Sloppy coding, however, has resulted in the text cursor dropping at various unpredictable locations. )
3.
Clicking on parts of the input field doesn’t bring it into focus even though the hover state promises it. (Discrepancies between hover and focus handling are a horrible new thing I’m starting to see more in recent interfaces.)
4.
Simply backspacing through the field shows a crude error modal and – to add a second injury to the first injury – the dialog removes focus from the field!
5.
Tabbing now goes through “Pixels” menu on the way from Width to Height, making it harder to type width → press Tab → type height → press Enter, in a nice quick keyboard gesture.
I will recognize this is a tricky one, because it exposes a core tension with tabbing: some people use it for comprehensive keyboard access, but others want an accelerator “express train” with only relevant stops. However, macOS already has a “Keyboard navigation” setting for that – you can choose whether tabbing should go through all the controls, or only those you get to type in. Not only does Photoshop ignore that preference, but it’s inconsistent with itself – you can see that you cannot get to Anchor via tabbing anyway!
6.
Clicking on the “relative” checkbox or canvas extension color does not restore focus to last control like it used to.
7–∞.
There are tons of other transgressions. Some are downwind from focus; for example, undoing after moving a slider no longer works, because the ⌘Z keystroke is now swallowed by a UI element that doesn’t know what to do with it. Some are unrelated: Pull-downs are now of the slower kind, pressing ⌥P results in more blinking, and this tooltip below feels so cheap that I’m surprised it’s not a talking point of the current U.S. administration:
I am tired even just noticing all this. (What is that weird clump of pixels on the left of the bottom edge!? Did no one spot it before launch?)
So now what?
I generally avoid such harsh labels on this blog, but: this is awful work.
I’m angry. (Clearly.) We should all be angry in the face of stuff like this. This is how people get fed up with software – because it feels unstable and deteriorates on its own without needing to.
I know I brought up that an existing power user base can be a huge pain in the ass, and I am a decades-old Photoshop power user. But this is different than other examples where the product needs or at least wants to evolve past its core audience or toward a different market. For Photoshop here, nothing I see indicates any change in course or clientele – and yet all of these good moments in UI that used to help me out no longer exist.
Plus, all those transgressions are solved problems. Those issues are not buried in pages of heavily litigated patents, or in seven collective brains of world-class interface designers whose driveways are presently occupied by cash-filled trucks sent over by frontier companies. This isn’t some long lost art that requires archaeologists to decipher. This feels like carelessness and laziness in face of basic UI engineering; in a likely internally-motivated effort to refresh the interface, the team threw an entire nursery worth of babies with the bathwater.
It’s not just about disservice to craft. It’s not even about disrespect for change management, trivialization of institutional memory, and disinvestment in quality assurance. This isn’t only, in Tog’s words above, “sloppy coding.” This is also a failure ofimagination. It’s not that hard to picture people spending 8+ hours a day going through these windows for years if not decades to come, and it’s not hard to add and multiply all of these microfrustrations into numbers that should make one pause. With these many paper cuts, you need to start thinking about establishing a blood bank. How can you expect people to use a professional tool effectively if you throw in so many roadblocks?
In an internally-motivated UI refresh like this, you not only need to meet users where they used to be, you also ideally have to give them more to cover for the pains of change. Sometimes that “more” is better storytelling – here, no one even tried to really sell me on the new interface – but ideally “more” means actual felt improvements. I’m not on the team, but it’s not that hard to imagine some of them:
Change those annoying modals that announce typing errors into something lighter and more modern, like attached tooltips.
Add more comprehensive equation support so e.g. I could type “660*2” like I can in increasingly more and more apps.
Add a bit of memory/stickiness to some options (like Use Legacy in the first window), so I don’t have to keep toggling them over and over again.
I started this post talking about a setting, and there is another setting in Photoshop, buried on the last page – you can turn off this “modern user interface” that feels so underbaked the moment you start actually using it. But is that a real solution to anything? Toggle it on and the existential dread comes back: Am I going to miss out on some good stuff? When is the hammer going to drop? It’s not a tax break, it’s only a tax extension.
Even this view above shows so little care, it would ordinarily deserve its own post.
(This is one of the meta posts about this very blog. If that’s not interesting to you, skip to the next one!)
Thank you for all your feedback and bug reports in response to my call two weeks ago. Since then, I:
revamped the image and video pipelines, which should make the blog load a lot faster and CPU/GPU struggle a lot less,
improved inline video handling on the web, and in (some) RSS readers,
made transparent videos work in Safari, and figured out how to make even better transparent videos,
improved Friday newsletters so they have a link to a nice web view, and GIFs hinting at video content (alas, you cannot put videos straight in email),
and generally made the site work better on older computers and phones.
If you see anything wrong or funny as a result of these changes – or any technical problem otherwise – please let me know (contact info is always in the footer). And, in general, please continue with your thoughts and feedback about content of the stuff I post, too! I’m enjoying hearing from you.
