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.
Decades ago, I used to work for a videogame magazine, but those days are long gone, and any videogame I play is a rare and intentional event.
Shadow Of The Colossus, the 2005 title directed by Fumito Ueda, felt so important to get to know that I had to borrow a PlayStation in order to play it, instead of waiting for a conversion (which never came; the game remains a PlayStation exclusive even today).
If you are not familiar with the title, I’m going to say little – the approach taken by the game, as well – and just point you toward the trailer for its remastered edition:
Boss Fight Books has been publishing books about videogames since the early 2010s, and “Shadow of the Colossus” by Nick Suttner is a book number 10 out of 40+.
The rather small and short volume is divided into chapters talking about each level of the game, one by one. But don’t let this discourage you – after all, recaps can be a literary art form. Here, every chapter goes on a side quest to talk about a larger component of the game or its backstory.
Having said that, the writing didn’t fully connect with me. Some of the tangents do not flow well, and the author’s choice to put himself in the book yields mixed results. In good moments, it’s wonderful to see someone’s passion for the game, but at times we’re also subjected to tenuous anecdotes about, for example, author’s beard, or his walks in San Francisco.
But the game! The game is definitely worth knowing more. It’s widely considered a masterpiece, a testament to choosing only a few things and doing them exceedingly well, a celebration of minimalism and deliberation, with so much – from world design to nuances of haptics – intently focused on creating the right ambiance to tell a story.
This might be strange to say, but I have this belief the rules of world building and care about atmosphere apply even to boring enterprise apps with stock UI elements. You’re still creating a universe and its set of principles, figuring out how to walk the user through it all via certain narrative beats, and – ideally! – thinking about all the small design decisions that will contribute – ideally! – to a consistent overarching tone.
The book occasionally peeks under the curtain to reveal design choices and details that could be inspiring to more than game designers: the control scheme, the fluid camera movement, intentional repetition of themes just to have them subverted, or the fascinating concept of “futile interactivity” (giving the player control even if the outcome is predetermined). What is interesting in particular are paths not taken: the initial idea of 48 monsters pared down to 16, or the multiplayer roots abandoned to focus on a linear, single-player experience.
(In a particularly brilliant decision, the creators took some of the unfinished levels and still put them in the game… as ruins.)
Is it a perfect book? No. But I’m glad I read it, and that writing about videogames in this form still exists – for a while, this was called “new games journalism” – and one way or another, it’s good to get closer to this strange beast of an AAA game with an indie game’s soul.
Before dark mode became mainstream in the late 2010s, there were two main customers of dark UI themes: programming and photo/video production. But, to the best of my knowledge, they arrived at that preference from two very different angles.
Programmers’ fondness for dark mode was a result of decades of bad display technologies. The early CRTs were so awful, the burn-in risks so real, and the pixels so fuzzy and headache-inducing, that you wanted to see as little screen light up as possible – hence, defaulting to black background for everything computers did.
These challenges were there all the way through the 1980s, really, teaching generations of coders that computers meant light letters on dark backgrounds. Games moved away from being “in space” or “at night” as quickly as they could, text editing and spreadsheets went for paper-like livery soon after that, but programming never meaningfully existed on paper, and so the skeuomorphic pull wasn’t really there.
(Have you ever heard of a term “reverse video”? What’s kind of confusing about it is that its meaning was reversed around that time.)
AV professionals took a different route. They already had CRT calibration, gray walls, and monitor hoods so that light from outside wouldn’t contaminate content colors – and when computer UI started appearing on those CRTs, it was likewise best to keep it as dark and as neutral as possible.
Today, things are more flexible. Many people prefer one theme over the other for any of many legitimate reasons, most leave dark theming synced to daylight, and display technology can handle all themes so well that it jumped ahead of our brains, which still have some interesting asymmetries in processing light shapes next to dark ones.
As users celebrated dark mode appearing in popular apps and services in the 2010s, some had to catch up the other way: Apple TV added light mode (for some reason) in 2017, and Affinity apps celebrated new light UI option just earlier this year.
Most programming text editors still default to dark, but allow you to switch; as a software category they were probably the first to fully embrace color theming.
But what led me to writing this post was a delightful discovery today of this setting:
Why, of all apps, would iOS Photos allow you to switch to dark mode, and only while editing to boot?
I think this might be because of the above tradition of pro AV apps, where we learned it’s good for visuals to be surrounded by black; a little nod to its earlier professional roots – similar, perhaps, to the story of the Clear button in calculators.
But I had two more thoughts. First, for all the reasons above, to me at least dark mode still has connotations of “professionalism” and toggling the option makes me feel I’m a bad-ass pro whenever I’m editing a photo. I wonder if others also feel that way, too.
Second, dark mode looksdifferent. Dark UI only when editing means it’s easier to spot whether I’m editing or just browsing, and be ever so slightly better oriented.
(In general, apps today are much more similar-looking, and I’m surprised neither iOS nor Android doesn’t allow you to switch the theme per app, just so it’s easier to know where you are as you move around quickly.)
To follow up from yesterday’s post, in Figma, object selection actually goes onto the undo stack. This is because in a professional tool with objects in multiple levels of hierarchy, it might take a while to construct a selection to work on – and since selection is always just one accidental click away from being completely cleared, undoable selection is extra protection.
However, at the same time renaming a file – or changing settings like file access – is not undoable. This is in part because we didn’t feel people would understand they could cancel out their rename this way (Safari too used to have “reopen last tab” under ⌘Z, until it reverted to Chrome’s ⌘⇧T), but mostly because you could accidentally undo through a file rename during regular work if you were not careful, without noticing, and that felt like it’d have more profound consequences.
In some ways, it helped me to think of these not as “ineligible for undo” but rather “living outside of time.” The moment a file is renamed, it will always have been named that way. (For the purposes of undo, at least. You can acknowledge anything you want on the version history screen.)
I’m not saying these are universally correct choices – as a matter of fact, some users find undoable selection (at least initially) pretty confusing! – but mostly sharing these as examples of intentional thinking about what deserves undo, and what should be exempt from it and taken care of elsewhere.
A fun bit of storytelling on the website for a git client Retcon:
I don’t have personal experience with Retcon. I definitely struggled a lot with git’s syntax over the years, and have my own cheatsheet that looks similar to this.
But what I really liked from this page was the elevation of undo to be the North Star. I think it’s very, very well deserved.
To the best of my knowledge, undo in its modern form arrived in 1983 with Apple Lisa – Byte magazine called it a “tremendous security blanket” – and then over the next decade or so blossomed into its current state: an infinite, multi-level, lightning-fast safety hatch that works pretty much everywhere, always there in the bottom-left corner of your keyboard, so second-nature you might not even realize you’re invoking it.
In early apps, before undo arrived, you had to be very careful about what you did and when you saved your work. Later on, undo worked on just one level, so you had to think a lot about how to spend it before things became irreversible.
Today, undo just works. It truly became Back Space: The Next Generation.
But any user-facing “just works” hand wave means a lot of people’s hard and invisible work behind the scenes. So if you’re reading this, and at some point in your career you worked on making undo better, my tip of the hat to you (and send me a message!).
Minecraft is so complex that it’s sometimes hard to know what is a bug and what is not.
Here’s the logic of the game:
If you fall from height, you receive fall damage.
If you fall from height but you’re in a boat, there’s no fall damage.
If you fall from height and you’re in a boat, but you fall from a distance of 12, 13, 49, 51, 111, 114, 198, 202, 310 or 315 blocks, there is fall damage and you die.
The first is common in games.
The second is – I believe! – a former bug that was grandfathered in as a design decision: people got used to it, started relying on it, and it became “too big to fix.” The retroactive explanation became that the boat is your shield and takes all the fall damage, which is a very Hollywood action movie way of looking at the world.
It’s an interesting video because it’s lighter on bug causes discussion, but heavier on math – and the moment you realize those numbers above are not random at all and coalesce into a nice formula, is genuinely a pretty fun moment.
I thought this was interesting, and a little contribution to a larger debate about how hard it is to even agree what a bug really is (which I previously briefly talked about).
I believe these are used by people who prefer intentionally limited visual choices, for low-key diagramming to put in source code, and – increasingly – as an entry point to gen AI.
They’re so interesting from the standpoint of this blog:
Fun to see a contemporary take on something that peaked between 1970s–1980s – you can look up TUIs and Turbo Vision if you want – but (just like Mario the other day) now with modern sensibilities, performance, web access, mouse and trackpad affordances, and so on.
It’s interesting simply as an exercise in constraint. I believe constraint practice will become more and more important as computers become more and more capable. It’s already useful to constrain yourself in order to make things easier for you. With the rise of AI, self-constraint will become important to make things harder, as well.
There is a certain power and longevity of monospace plain text that’s worth celebrating – not just because the file format is portable, but because text editing as interface is so well-known and potent.
Also, ASCII spray in Mockdown is just really fun:
(Caveat: These tools are “ASCII” in a colloquial sense, the same way people use “GIF” to refer to a certain category of looping animations.)
If there was one go-to example of an impenetrable error message in the 1980s, it must have been this – popping up, for example, if your disk drive was dirty:
On some technical level, the options made sense: “Abort” would stop whatever you were doing, “Retry” would try to repeat the action, and “Ignore” would proceed as if there was no error. But in the heat of a moment, or seeing it for the first time, this was a puzzling choice to be asked to make. Not only were the words weighted improperly (the seemingly most innocuous action here, “Ignore,” was actually the only one that could do actual lasting damage), but it also wasn’t entirely clear what’s the safe thing to do to get out of the situation.
(The redesign of “Abort, Retry, Ignore” was “Abort, Retry, Fail,” and it wasn’t really a huge improvement.)
Last night, I installed Google Photos on my iPhone, and the first message that greeted me was this:
This is really a matryoshka doll of bad dialog presentation.
First: any buttons in a dialog should be labeled with enough information to keep me going. Here, both have generic labels, so now I need to pay attention.
Second: Even after reading, I have no idea what is the choice I’m making. I see the pathway marked “yes, keep it the way I had it” and, sure – this would be generally what I want from any given computer on any given Sunday. But what’s the actual alternative?
But the third, and most important one, is this: this dialog has no safe escape hatch. By now, in UX design, we established quite a few canonical escape hatches:
a Cancel button,
a × close box,
a “No, thanks” link,
a press of an Escape key.
But you can’t × this dialog out. The main button seems positive, but it also feels like I’m taking an action with consequences, and I don’t want to deal with that. There is a “No, thanks,” but it doesn’t feel like the other “No, thankses” I have seen – it’s juxtaposed with copy that makes it seem… a dangerous thing to choose.
And this last bit makes it a pretty serious design offense, because you are now messing with foundational stuff. You need to protect those escape hatches for the future; the moment you introduce hesitation into the mix and taint “No, thanks” as a concept, really bad things will start happening all across your product.
In real life, fire doors have to open outwards when pushed with body weight, aircraft stick shakers are impossible to ignore, and anti-lock braking systems do smart things even after your brain turns off its smart parts.
I know seeing a dialog like this would never happen in a moment of true panic, but sometimes I think of the user in their most absent-minded moment: trying to get their kids to hurry up for school, on hold with an annoying cable provider, with a cat looking like it’s about to jump up directly into a running toaster. A dialog on their phone pops up. If that dialog absolutely has to happen, what is the escape hatch it can offer so they can dismiss it safely if they cannot think about it at all?
This Google Photos screen needs a lot more rethinking and rewriting, but in its current incarnation, it desperately needs a clear and trustworthy escape hatch I can tap absentmindedly, just so I can get to my photos.