The post about Photoshop’s new dialogs traveled through some of the internet’s pipes and alleyways. Michael Tsai has a nice roundup of reactions; let me pick a few things that caught my attention.

1.
Nick Heer at Pixel Envy made a discovery that Photoshop’s new windows are… websites:

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 the previous 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 deep expertise. 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.

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.

This 1.5-hour (sic!) video by Fredrik Knudsen talks about a story of such a community for a popular game Elder Scrolls V: Skyrim:

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.

Found in an archive of font design (for Olivetti typewriters) and smiled:

Handoff problems were there before us and will remain after we’re gone.

This, too:

I was impressed with this clever internal interface at Linear, shown inside this larger blog post:

The dev toolbar exists directly inside the app and allows us to easily toggle feature flags on and off. When something didn’t look right in the refreshed UI, it took us just one click to compare it with the previous version. That made it easier to determine whether the refresh had broken something or whether it had behaved that way before. Having the updates live behind feature flags also meant that instead of developing the redesign in isolation and shipping all the changes at once, we could integrate incremental changes to the platform.

I also cut it out here so it’s easier to see:

Here’s what I like about it:

• It’s a separate UI surface: Rather than being awkwardly integrated alongside production UI and adding jank to it, it is a clearly delineated toolbar you know users won’t ever see, allowing the rest of the interface to always feel like production.
• The feature flag toggling is easy: You don’t have to go anywhere else and possibly log in to toggle a flag, and you don’t have to wait for it to take effect. This will mean more people than just the core team members will be using it.
• Toggling this particular feature flag is as easy as clicking on a tile: I don’t know if anyone can promote others flags their care about to be easily toggle’able tiles, but I can imagine this really beneficial, too.
• The feature flag toggling is instantaneous without any visual jank: I understand that the best way to compare two things visually is to switch between them promptly in situ; our visual system is really good at spotting even small changes when aided this way.

Each one of the above bullet points is individually a small point of friction and easy to renege on, especially when it comes to internal-only interfaces. However, a combination of all of them results in great compounded interest, and I bet makes this interface effective – in addition to just feeling like fun to use.

Appreciate Linear sharing this internal detail; if you are using an interesting internal tool or UI that you are allowed to share, please consider it and let me know!

I saw this fly by before, but just today I learned that Pride versioning is a tiny project by Nikita Prokopov, whose work I shared before:

The author says:

This is a parody and a homage to the awesome Semantic Versioning.

…but I think it stands on its own. You can’t have craft without being at peace with pride and embarrassment existing.

An interesting crowdsourcing effort from Mimestream that asks users who want snoozing to pick up a phone and dial their representative put pressure on Gmail to add that feature to the API.

I wonder how much of a chance of succeeding this has. The issue has been open since 2018, and was reopened in 2023. It has over 5,100 stars. Those dates seem old and the numbers seem huge, but I don’t have a full frame of reference. Casual search shows there are only two more bugs that have been starred by more people.

A nice 2024 essay by Jim Nielsen about the process of “sanding” user interfaces he’s working on:

One of the ways I like to do development is to build something, click around a ton, make tweaks, click around more, more tweaks, more clicks, etc., until I finally consider it done.

The clicking around a ton is the important part. If it’s a page transition, that means going back and forth a ton. Click, back button. Click, right-click context menu, “Back”. Click, in-app navigation to go back (if there is one). Click, keyboard shortcut to go back. Over and over and over. You get the idea.

It’s kind of a QA tactic in a sense, just click around and try to break stuff. But I like to think of it as being more akin to woodworking. You have a plank of wood and you run it through the belt sander to get all the big, coarse stuff smoothed down. Then you pull out the hand sander, sand a spot, run your hand over it, feel for splinters, sand it some more, over and over until you’re satisfied with the result.

This is a clever metaphor and I wish I thought of this before. What follows is a specific story of finding a few dead pixels in between related interface elements, which is an absolutely perfect example of something with non-linear frustration: It might not register at all on the first try, but it will bother you 1,000-fold on the 20th go.

I was just on Internet Archive earlier today, uploading some documents I scanned this weekend. Their UI is… how would I put this… let’s just say Internet Archive makes Teams feel like Linear. (I love Internet Archive and their work and mission, but let’s be honest here.)

Yet, I found something marvelous. Whoever put the upload form UI together knew there will be people like me who’ll be filling out 20 of these forms one right after another. So they made sure every pixel in their form is clickable to edit the nearest field. And I mean, every pixel.

Whoever you are, you have my nod of recognition. In at least this one respect, it’s clear someone spent a lot of time with the sander.

Another good post from Roger Wong thinking through Anthropic’s findings on how offloading coding effort leads to understanding less:

So the AI group didn’t finish meaningfully faster, but they understood meaningfully less. And the biggest gap was in debugging—the ability to recognize when code is wrong and figure out why. That’s the exact skill you need most when your job is to oversee AI-generated output.

Inside it, a quote from the Anthropic post that resonated with me:

Cognitive effort—and even getting painfully stuck—is likely important for fostering mastery.

I wonder if part of the appeal of AI tools is the promise of “exercise without exercise,” like the vibrating belt machines of the 1950s.

Elsewhere, I found an essay about the craft of writing by Kristie de Garis:

Writing at speed privileges what arrives first. The obvious phrasing, the familiar structure, a thought that you heard somewhere before.

Also this:

A book is not retrieved fully formed from memory, or pulled up in a full bucket from some deep creative well in your body.

The old saying goes “everyone dreams about having written a book, not about writing one.” Now we’re building software that allows people to “have written a book” and “have designed something.”

I am open (I think!) to the idea that the nature of the effort will change as tools change. But I can’t see mastery arriving without effort. And I’m worried people will start mistaking prompting mastery for material mastery.

• The UI for filing bugs is inscrutable and has too many hoops to jump through.
• No one does anything unless every field has been filed meticulously and there is a clear repro.
• The designer is ridiculed if the thing isn’t actually a bug, is a duplicate, or if it was filed in the wrong place.
• Front-end bugs are automatically “minor” or “nice to have”s without listening (as there is no loss of functionality, and no data loss).
• The designer is always responsible for stating how it should work, without being able to say “I am not sure why, but this started feeling off and it’s in an important place. Can we investigate?”
• “This is as designed” is an automatic conversation ender.
• The tiniest of external reports, social posts, or blog posts, immediately are prioritized higher than in-house experience.
• Once every few years, a designer gets 20+ demotivating automated emails saying 20+ bugs they filed over the years have been closed automatically during a purge, without any word of explanation.
• Simple human touches like “thanks for filing!” or “nice catch!” never enter the picture.
• Engineers never file design bugs themselves.

If you’re an engineer, I can sense you might be getting frustrated, as most bullet points I listed look like extra work. I agree with you. It is. This post is as much about process, as it is about culture and the incentives it establishes. The best places I’ve worked were filled with shared trust and treated bugs as a joined responsibility of everyone, rather than a black-and-white division into “filers“ and “fixers,” with the ultimate end goal always being user’s experience – nothing else.

I also understand this dives right into an age-old tension between manufacture and craft. Bug-fixing processes have to be well-oiled bureaucracies with very specific rules so that they don’t turn into a pile of vibes and Brownian motions. But design (and, by extension, a lot of front-end) doesn’t work like that. Design needs room for taste, for careful exceptions, for escalation of immesurable things, and for a certain flexibility in even the basic definitions.

If it’s a tiny, but embarrassing bug, or a flow killer, or a thing that bothers your most valuable group of users, or something appearing in a well-trafficked place – it is no longer tiny. If it’s working as intended, but it feels buggy to the user – it ought to be a bug. If it’s a long-standing bug, it should be considered as cumulative damage already done, not “oh, this has been like this for a long time, no one cares.” If there’s a shaky repro, but the bug feels important, you need to work from principles or analyze the code. If it’s something no one mentioned externally (ergo: why fix it?), consider a lot of bugs rankle but never get reported, particularly if your company doesn’t project an external presence of caring about feedback and acting upon it. cough cough Apple cough cough cough cough cough dies coughing

Of course, designers have responsibilities in the process also, among them mutual respect and understanding of engineering, clarity of communication (particularly about things that are hard to reason about mathematically), seeing patterns that could be grouped into bigger bug bundles to make fixing more efficient, (occasionally!) helping figure out a fix if the obvious fix isn’t available, and shared understanding with their team about what actually matters. There is always a thousand details that could be better, but for every thousand only a hundred might actually be worthwhile. Flooding the bug process with irrelevant minutiae that won’t realistically ever be fixed is not very helpful.

This is the only way I know of to capture the full spectrum of bugs that ruin software – from front-end to back-end, from visual/​interactive quality to works-or-not functionality, from what can be measured to what never will be. And this is not just about designers, of course. It’s not even about any non-engineering function. Design serves everyone; if your bug-filing UI or your process or your definitions are not well-designed or -balanced, I strongly believe you’re also hurting engineers on your team. And you’re definitely hurting your users.