I know we’re probably collectively a bit tired talking about macOS Tahoe, but I just noticed something that I think is a good example of how small details can ladder up to bigger things.
This is macOS Sequoia (the pre-Tahoe release) and a typical pop-up button:
One clever thing macOS has been doing since basically the dawn of GUIs is that upon clicking on a button like this, the currently selected row will be in the same place as before you clicked. (As opposed to, for example, the entire menu appearing below like it would from a top menu bar.)
This has interesting and often underappreciated consequences. It allows you to orient yourself quicker since you don’t have to find the selected option again. And, it saves you movement overall: the next or previous option will always be at the absolutely shortest possible distance. (Of course, the approach also has some challenges,for example if the button is positioned close to the top or bottom of the screen.)
There’s another clever thing that happens throughout macOS: All the menus work using a classic click-to-open and click-to-select sequence, but they are also usable via the slightly more advanced, but faster mousedown-drag-mouseup gesture.
These building blocks work together and mean that selecting the next option can be as simple as a little flick of a mouse.
Now, check out macOS Tahoe (current release):
You will notice that iCloud Drive, upon clicking, is now misaligned both horizontally and vertically.
On the surface, this feels just like a visual blemish – slighly embarrassing, but without much consequence. But check out what happens if you hold your mouse button at a certain position, and then release it without moving:
The stability of macOS’s interface and the thoughtful set of aforementioned rules allowed for an emergent fast behaviour: mouse down and up meant you could “peek” into a menu safely, or you could change your mind right after seeing what’s inside. In a bigger sense, it created a certain trust between you and the operating system: it’s worth learning those gestures, as they will be rewarded.
In Tahoe, some of that learned behaviour – by the way, I see it in all of these buttons, not just this one – will now work against you. Now, you can accidentally change an option without intending to do so.
Is it a big deal? No, not really. This likely – hopefully! – simply fell through the cracks in a rush to get Liquid Glass out the door, rather than no one being there to care, or no one understanding that all these gestures add up in aggregate, creating a GUI that feels fast, trustworthy, and catering to your motor memory in a way that elevates your experiences with the interface in the long run.
But I’d feel better if it wasn’t almost half a year since the release, and if we hadn’t already seen other things exactly like it.
The year is 1981. Your IBM PC is equipped with a tragic speaker that sounds awful for anything except occasional beeps. (Those beeps sound awful, too.)
You can’t afford a sound card and besides, sound cards for your PC have not been invented yet. You can’t even afford a floppy drive, so you’re one of the rare people who actually uses an audio cassette player as a storage device – a technique usually reserved for more primitive machines that have half the bits your new PC does.
But there’s a silver lining. Your cassette player has a little relay that controls its motor. You can engage and disengage the relay at will.
So, someone figured out that toggling the relay kind of sounds like a metronome. Like percussion. It’s a hack, but in the sonic landscape inhabited solely by your sorry speaker, it’s a breath of fresh air (scroll to 7:26 if you don’t land there automatically):
The year is 2026. Your computer itself is the size of an audio cassette, fits in your pocket, has better storage, graphics, sound, pretty much everything compared to a 1981 PC. It even has a special haptic motor. Except, that motor can only be controlled by native apps, and there is no official API to do it from a browser.
But there’s a silver lining. Tapping any checkbox on a site generates a haptic pulse. And that apparently works even if the checkbox is hidden and if thecomputer is doing the tapping.
I love these kinds of hacks, and I wonder what’s going to happen to this one. Will it fly under a radar, or will some websites start abusing it? If so, will Safari clamp it down, or will it actually give people a proper API for haptics?
This blog is about craft, but sometimes the answer to craft is not skill or taste or awareness or effort, but it’s creating conditions for craft to flourish. Workday looks like Workday, and your banking app looks like your banking app, not because there aren’t enough designers and engineers around that know how to do it better.
This is a thoughtful post by Anil Dash about Apple’s recent announcement of introducing video podcasting, warning how the conditions set up right now will lead to enshittification, and proposing changes:
This will also start to impact content. You don’t hear podcasters saying “unalive” or censoring normal words because there is no algorithm that skews the distribution of their content. The promotional graphics for their shows are often downright boring, and don’t feature the hosts making weird faces like on YouTube thumbnails, because they haven’t been optimized to within an inch of their lives in hopes of getting 12-year-olds to click on them instead of Mr. Beast — because they’re not trying to chase algorithmic amplification.
It’s worth reading even if you don’t care much about podcasts.
One of the most mysterious keys on the PC keyboard has always been Scroll Lock, joining Caps Lock and Num Lock to create the instantly recognizable LED triumvirate:
Scroll Lock was reportedly specifically added for spreadsheets, and it solved a very specific problem: before mice and trackpads, and before fast graphic cards, moving through a spreadsheet was a nightmare. Just like Caps Lock flipped the meaning of letter keys, and Num Lock that of the numeric keypad keys, Scroll Lock attempted to fix scrolling by changing the nature of the arrow keys.
This is a normal arrow key usage in Lotus 1-2-3, doing what you’d expect, if likely a bit slower:
And this is Lotus 1-2-3 with Scroll Lock enabled. Here, the arrows do not move the cursor, but move the spreadsheet:
In time, scrollbars helped with the problem, then mice with wheels solved it in one direction, and then trackpads in both. (Although even though my 2025 Windows laptop doesn’t have a Scroll Lock key, its onscreen keyboard does, and the key still works in Excel.)
But, I grew to believe that UI problems never fully die, and often come back dressed up in new clothes.
This is the TV app on my Apple TV, doing movement as you’d expect:
But Netflix a while back picked a different approach – scrolling almost as if Scroll Lock was on:
More recently, I saw that approach spread to HBO Max and YouTube apps as well:
Is this good? To me personally, the Scroll Lock-esque approach feels strange and claustrophobic. I see the (hypothetical) value of keeping the selection in one place, but the downsides are more pronounced: things feel lopsided, going back in this universe is flying blind, and the system creates strange situations at the edges, where Scroll Lock struggled as well.
And yet, given I just dated myself by reminiscing Lotus 1-2-3, I’m curious how it feels to others.
From May last year, a 21-minute video by Linus Boman about font piracy, specifically during the era of personal computing and early internet:
The nuances of what separates font piracy from non-pirated revivals or general inspiration are too much even for me, but I liked how the video moved on from the obvious and cheap “haha, you wouldn’t pirate a font” story to cover a few of the more complex issues with panache.
My small contribution to the discourse is that I just scanned an interesting booklet from 1979 called Typeface Analogue, which catalogs various names different phototypesetting manufacturers used for their “replica” fonts – a sort of a translation table between once-relevant parallel type ecosystems.
Some are pretty uninspired: CS for Century Schoolbook, OP for Optima, Eurostyle for Eurostile, and so on. Others are more interesting: a version of Palatino called Patina, American Classic becoming Colonial, or Futura renamed to Twentieth Century. Absolute fav? Helvetica becoming Megaron.
The display fonts you see on this blog are my vector conversion and slight improvement (kerning pairs!) over a bitmap PC/GEOS font called University, which itself was inspired by the original Macintosh’s Geneva. Inspired or downright stolen? You decide:
Those terms confused me back in the day, and occasionally they still do, so I thought it might be nice to write it all out. This is how I understand them:
deterministic: whenever you do something, it gives you identical results as any previous or next time you do it
idempotent: if you do something twice, or thrice, or more times, it will be the same as doing it once
But “deterministic” in UI design might mean something more specific. Let’s take pressing ⌘B to bold, for example:
Every time you press ⌘B on an identical selection, it will behave the same. But, pressing ⌘B doesn’t guarantee something will get bold. If it already is bold, the command will reverse its meaning. In this sense, ⌘B is non-deterministic.
It’s not hard to imagine a determistic version of bolding. Make ⌘B bold the text, and make another shortcut – say, ⌘U – unbold it. This way, you can always press either and be absolutely confident you will get a predetermined result without worrying about anything else. It’s a boon for motor memory, but it is more complex to explain, and it adds more UI surface.
There is also another, more interesting way: you can make ⌘B always bold first, and unbold second. This way, your fingers can remember ⌘B is for bolding, and ⌘BB is for unbolding. But this also gets tricky: for already fully bolded text, it might seem the feature is broken, because the first keystroke does nothing!
Only the second of these three approaches is idempotent,meaning you can invoke it many times and it will always give the same result:
⌘B toggles bolding from current state: non-deterministic, non-idempotent
⌘B bolds, ⌘U unbolds: deterministic, idempotent
⌘B toggles bolding, always starts from bold: deterministic, non-idempotent
One of my favorite idempotent concepts is the Clear key present on many calculators, and still on some larger Mac keyboards.
The idea behind Clear is simple. Let’s say you’re a professional keypad user – maybe an accountant? – typing in numbers for hours a day. You just made a mistake. Pressing Backspace will remove the last digit, but are you sure you only made a mistake on that last digit? What if your fingers brushed another key and you typed in two digits by accident?
Instead of using the non-idempotent Backspace key where you’d have to look at the screen to confirm, it’s easier just to press the idempotent Clear which will always remove the entire number, and then start from scratch without even having to look anywhere (as gamers would say, “no scope!”).
And, for people who are moving fast, it feels safe just to press the shortcut or a button instinctively, for ease of their mind, even if nothing has to be done. Some people might choose to press it a few times, just in case. The Esc key often has that property – isn’t it just nice to slam Esc many times? – and Jeff Jarvis in his 2014 essay talked about another shortcut that felt that way:
Since I don’t need ⌘S anymore, I can now appreciate how much it had become a part of my ritual of writing and even of thinking. I used to hit ⌘S not just as data insurance — hell, I’d often hit it after having not made a single change in my text since the last time I’d hit it. I hit ⌘S as a break, a psychic, semiotic semicolon. It gave me a moment to search for the right word, to plan the structure of where I would go next, to commit to what I’d written, or to wonder whether I had the courage to erase what I’d written and try again.
(In Figma, where ⌘S wasn’t necessary, we used to show this – but we only showed it once every fortnight, since some people would press the shortcut instinctively like Jarvis, and find the message distracting and maybe even patronizing.)
All of these options have pros and cons. The beauty of determinism and idempotence is that they free you from paying attention. I always get a bit nervous when someone tells me that in their country, you can press the elevator button again to unset it. Even if you don’t make a button a toggle, visually disabling it or showing a message (“Nothing to delete!”) when it has nothing to do could feel like a friendly gesture toward newcomers, but its non-idempotence will grate people who know what they’re doing. Determinism and idempotence are good for motor memory to develop, but – just like the above bolding example – might be initially more confusing.
The approaches can coexist; browsers give you ⌘⌥←→ to move between tabs (non-deterministic, non-idempotent) and ⌘1/2/3 to switch to a specific tab (deterministic, idempotent). Some places even offer a choice. In macOS, you can say whether you want clicking on a scrollbar chute to be deterministic or not:
…although usual choice-giving caveats should apply.
I think it’s good to think about those things, especially for interfaces used professionally. Magical things happen if you can trust your fingers and sometimes, if you worry too much about novice users, that might make it hard for pro users to emerge.
As a former ISP employee I occasionally like dipping my toes into some networking stuff, and this 25-minute video from The Serial Port is a good retelling of the day in 2014 when one of internet’s important routing tables crossed a threshold of 512K, which caused all sorts of trouble:
What I appreciate about The Serial Port is that they always seem to actually test the vintage hardware or rebuild the old software they’re commenting on, and this time was no exception: they grabbed a classic unsung hero of ISPs, a Cisco Catalyst 6500-series router, and then recreated “The 512K Day” in their studio.
This was a nice comment under the video:
Have absolutely no knowledge about networking, but watched this video as if a thriller movie. Thanks for opening my world of tech to networking.
Yeah, the video is kind of nerdy and intense, but maybe you’ll enjoy it; even a classic aging piece of hardware with an arbitrary ticking-bomb limit deserves some respect.
Also, the funniest comment:
I had a 2.4k day a couple days ago when I realized Farm Sim 22 only allows a max of 2400 bales. Couldn’t load into my saved game. Had to go into items.xml and temp remove a hundred bales.
I read Erika Hall’s Just Enough Research. I’m not going review the entire book as it feels a bit off-topic for this blog, but the chapter about surveys had me nodding my head so much I’d love to excerpt a few things:
The questions can be asked in person or over the phone, or distributed on paper or collected online. The proliferation of online survey platforms has made it possible for anyone to create a survey in minutes.
This is not a good thing.
Surveys are the most dangerous research tool — misunderstood and misused. They frequently blend qualitative and quantitative questions; at their worst, surveys combine the potential pitfalls of both. […]
If you ever think to yourself, “Well, a survey isn’t really the right way to make this critical decision, but the CEO really wants to run one. What’s the worst that can happen?”
Brexit.
Hall highlights that surveys are much harder to debug than other methods:
It’s much harder to write a good survey than to conduct good qualitative user research—something like the difference between building an instrument for remote sensing and sticking your head out the window to see what the weather is like. Given a decently representative (and properly screened) research participant, you could sit down, shut up, turn on the recorder, and get useful data just by letting them talk. But if you write bad survey questions, you get bad data at scale with no chance of recovery. It doesn’t matter how many answers you get if they don’t provide a useful representation of reality. […] Surveys are the most difficult research method of all.
[…] Bad code will have bugs. A bad interface design will fail a usability test. A bad user interview is as obvious as it is uncomfortable. […] A bad survey won’t tell you it’s bad.
And that they might be seductive because they feel like hard data:
Designers often find themselves up against the idea that survey data is better and more reliable than qualitative research just because the number of people it is possible to survey is so much larger than the number of people you can realistically observe or interview. [… But] unless you are very careful with how you sample, you can end up with a lot of bad, biased data that is totally meaningless and opaque.
There’s also this hilarious bit:
Managers love NPS because it was designed to be loveable by managers. It’s simple and concrete and involves fancy consultant math, which makes it seems special. But is this metric as broadly applicable and powerful as it claims to be?
Nah.
NPS is not a research tool. I shouldn’t even be talking about NPS in a research book.
The entire book is worth a read, with a lot more to offer than the pithy quotes I excerpted above. I really liked its pragmatic approach to research that understands the realities of the industry.
Mac allows you to assign keyboard shorcuts to menu items, but the interface is clunky – you have to select the app even if you just came from it, and then type in the menu item name by hand without any assistance:
Other tools, like Keyboard Maestro, do something similar. You either have to type it again, or you can point to it, but in a replica of the menu of the app shown in a very different style and orientation:
But this week I learned of another app, KeyCue, that approaches this differently. You simply point to the menu item and hold the desired key for a while:
Okay, this is not a universal endorsement. The feature works clunkily, and KeyCue as a whole is way too comfortable adding itself to login items without asking.
But as far as singular interactions go, this is great and eye-opening. It made me realize that the previous things I’ve shown – System Settings, Keyboard Maestro – are really not GUIs, and they don’t practice direct manipulation. They’re still partially command line interfaces dressed up in GUI clothing.
We kind of lightly made fun of Jonny Ive going angelic on “staying true to the material” and things being “beautifully, unapologetically plastic.” And there is, of course, value in command line and those kinds of approaches. But this part of KeyCue at least is unapologetically a graphical user interface, and it is nice to still be surprised in this space.
Before computer graphics, movies relied on matte paintings to extend or flesh out the background. This is perhaps my favourite matte painting, from the end credits of Die Hard 2:
Turns out, videogames do something similar, except the result is called a skybox, since it has to encompass the player from all sides. It’s another way to use cheap trickery to pretend the world is larger than it is.
This 9-minute video by 3kliksphilip shows a few more advanced skybox tricks from Counter Strike games using the Source engine:
I particularly liked two discoveries:
In real world, you wouldn’t style backfacing parts, because the player will never be allowed to see from the other side. Here, you don’t even have to render them.
Modern skyboxes have layers and layers of deceptions: more realistic 3D buildings closer to you, and completely flat bitmaps far away. It almost feels like each skybox contains the history of skybox technology that preceded it.
On the other hand, seeing clouds as flat bitmaps was really disappointing.
Beagle Bros was a 1980s software company making apps for Apple II that is still remembered fondly for their personality.
The company had a hobbyist slant, selling various small tools and collections with fun names like Beagle Bag (in the “Indoor Sports” collection) and DOS Boss and Utility City – similar perhaps to Norton Utilities on the PC side, but with a lot more fun and charisma. This is one of their loading screens, also showing both their recognizable logo and their endearing quirkiness:
How do you understand a man who has three clocks on his wall, showing the time in three different cities-San Diego, Fresno, and Seattle-all, of course, showing the same time (″If anything changes in those cities, we’ll know about it”)?
(I find the anachronistic combination of hedcuts and dot matrix printer typography particularly fascinating.)
Some of their software was more serious; Beagle Bros released many useful tools and even text editing and presentation apps. They also made practical posters:
But other stuff…? It was just goofing off:
How does this relate to craft and quality?
There is this interesting question about how much product and marketing and vibes and lorecorrelate. Did we forgive Sierra On-Line the numerous flaws of their games because we liked the company? Do we love Panic because we like what they do, or because of how they do it? Did Google put doodles on its homepage to distract people from more nefarious things, or because it just felt like a fun way to celebrate things? Is there such a thing as pure selflessness? What is the nature of free will?
Those are, perhaps, topics for future posts.
But Beagle Bros must have been doing something right if there is still a living, elaborate catalog of their works online, 40+ years later. Jeff Atwood also argued in 2015 that it was more than just fun – or that “fun” itself can give back in great ways:
Here were a bunch of goofballs writing terrible AppleSoft BASIC code like me, but doing it for a living – and clearly having fun in the process. Apparently, the best way to create fun programs for users is to make sure you had fun writing them in the first place.
But more than that, they taught me how much more fun it was to learn by playing with an interactive, dynamic program instead of passively reading about concepts in a book. […]
One of the programs on these Beagle Bros floppies, and I can’t for the life of me remember which one, or in what context this happened, printed the following on the screen: “One day, all books will be interactive and animated.”
I thought, wow. That’s it. That’s what these floppies were trying to be! Interactive, animated textbooks that taught you about programming and the Apple II! Incredible.
Steven Frank, the co-founder of Panic, wrote this in 1999, with similar themes:
You never knew exactly what you were going to get. I remember one program listing printed on the side of a bird that, when run, produced a series of wild chirping noises from the Apple’s speaker. And this was from a program that was only five to ten lines long. As a neophyte BASIC programmer myself, I was stunned and amazed. How could you make something this cool with this small amount of code? […]
Beagle Bros’ tools were fantastic. They literally let you do the (allegedly) impossible, like change the names of operating system commands. And they always packed the disks full with extra stuff. Demos of their other products, and strange graphics hacks that existed for no reason other than the fact that they were cool, and because there was spare room on the disk. Beagle Bros. had a lot to do with why I ever wanted to learn programming in the first place. […]
I’ll never forget the book. […] The book was a huge compilation of all around interesting stuff. Weird Apple II tricks that were pointless, but endlessly fascinating. Like the fact that there were extra offscreen pixels of lo-res graphics memory that you could write to, that never got displayed. Or how to put “impossible” inverted or flashing characters into your disk directory listing. Or how to modify system error messages. Not very useful, but really fun to know and really, really cool to mess with. My dad was convinced I was going to somehow break the computer with all this hacking, but a simple reboot always fixed everything.
(I swear I did think of Panic above as a spiritual successor to Beagle Bros without knowing that their work literally inspired one of the Panic’s founders!)
The subtlety: They had utilities which would produced formatted Basic listings and they would give example output of these utlities in their ads and catalogs. It was quite a while before I realized that most of those examples were not program excerpts, but complete programs which of course contained the Beagle Bros signature weirdness. And then there were the seemingly innocent hex dumps. My favorite was from the cover of one of their catalogs, which had a classic picture of this fellow sitting in a chair. On the floor next to him is a handbag with a piece of tractor paper sticking out. On the paper is a hex dump: 48 45 4C 50 21 20 and so on, which are ASCII codes that spell out the message: “HELP! GET ME OUT! I’M TRAPPED IN HERE!----SOPHIE”
After the work the company had done on AppleWorks 3.0, Simonsen felt ready to jump into the Macintosh market with a “Mac AppleWorks” of their own – they called it Beagle Works. Unfortunately, other companies – giants in the Mac market such as Microsoft, Claris, and Symantec – had the same idea. Their resources were far greater than Beagle Bros had imagined, and the race was costly.
The gamble killed the company. It’s likely that the changing software market would anyway.
But the years before seem to still inspire some people. Check out the Beagle Bros Repository – the homepage is a bit confusing (I think it prominently shows last-updated or last-added things for some reason?), but just use the nav at the top. Maybe it will inspire you, too.
In short, the way I think about software quality is the amount of meaningful problems. […]
There are problems in Finder — resizing columns, renaming or deleting files synced with a FileProvider-based app, and different views not reflecting immediate reality. There are problems with resizing windows. AirPlay randomly drops its connection. AirDrop and other “continuity” services do not always work or, in an interesting twist I experienced a couple days ago, work fine but display an error anyway. The AirPlay and AirDrop menus shuffle options just in time for you to tap the wrong one. […]
These are the products and features I actually use. There are plenty others I do not. I assume syncing my music collection over iCloud remains untrustworthy. Shortcuts seems largely forgotten. Meanwhile, any app augmented by one of Apple’s paid services — Fitness, News, TV — has turned into an upselling experience.
As I’m reading this and thinking about my own Apple usage patterns and a similar litany of problems, I keep returning to Apple TV, which feels by far like the most stable and least troubled platform. I wish I had a better explanation for it: Is Apple magically really good at TV interfaces? Are their benefitting from it being a “hobby project”? But I think the Occam’s Razor here is this: tvOS is just a lot simpler.
And just like that, a thought appears: Is what we’re seeing overall is really just Apple losing the battle with complexity?
Apple won once, in the late 1990s, when on the hardware side all the Performas and Newtons and LaserWriters were cut ruthlessly, and on the software front Mac OS X pushed Classic away as the operating system. The situation was different then, however, because there was no other choice. Today, Apple seems successful on paper, so the pressure needs to come from inside, from someone high up enough to recognize that what Apple is doing vis-a-vis software quality is not sustainable and hasn’t been for some time now. That the bill already came due on all of the decisions where systems thinking and deep testing and focus and preventative maintenance and paying off design debt have been deprioritized in favour of another shiny launch event that stretches the teams and platforms even thinner.
When thinking about complexity, a different go-to framework I have is “can I explain a situation in a short paragraph?” This can help separate regular bugs (where the explanation is typically: I am doing the thing that used to work and it’s no longer working, so something broke), from bigger problems that require some serious long-term system-thinking approach. Off the top of my head, there are many things I can no longer explain:
I cannot explain Apple’s widget strategy
I cannot explain what is going on with the Fn/Globe key
I cannot explain the long-term thinking surrounding icons in Tahoe menus
Of course, it’s not me who should be explaining those things. And I haven’t done this exercise before so I don’t know for sure if things are getting worse here. It feels like it, though. I wonder if Apple just hit a limit of some sort of being able to deal with complex things, and first course of action should be: don’t throw even more complex things on your plate.
It’s probably impossible to tell the upper echelon of Apple that it’s breaking revenue records in spite of its software design, not because of it. I hope the next regime knows better.
When you start a new game in SimCity 2000 (you can try it in the browser yourself), as the city is generated, you see a few messages fly by: Creating Hills, Tracing Rivers, Smoothing. Among them, for a bit, one can see “Reticulating Splines”:
“Reticulating splines” is a giant pulling of our legs. Will and some others made up the phrase because they thought it looks and sounds as if it means something. It might: the word “reticulate” means to divide something so that it looks like, or appears to be, a net or a network generating, perhaps, from a single point; a “spline” can be an irregular curve or the approximation of a curve. Individually the terms have meaning. Together – in the case of SimCity 2000 – they don’t. It’s just a prank and a joke.
In some versions of the game, there was also a seductive woman’s voice saying the phrase out loud, which presumably made it even more memorable.
The phrase moved to other Maxis games, notably The Sims…
I’ve heard the argument that it wasn’t just Reticulating Splines – that Will Wright’s joke was the beginning of the habit of putting “cute” loading messages in apps, including actual not-game and definitely-not-cute applications. I am 100% sure there are some earlier examples of “funny” loading or error states, but I also see how this one attained a certain critical mass and influence.
I hate these cute loading strings with passion. I think I’m in the minority. It’s a topic for a future time, but it was fun at least to trace some part of its history, sifting through hundreds of pages earnestly explaining the concept of “reticulating splines” to people. Whether they’re in on the joke, I am not sure.
Also, okay. Fair enough. I chuckled just now when I saw this:
This was a fun 15-minute architectural video from Stewart Hicks (absolutely worth a follow otherwise) that mapped precisely into the same kind of tension and internal debate I sometimes feel when talking about minimalism in UX design: Minimalism is good! Until it’s not!
One interesting lesson here is that the famous “less is more” was actually – surprise! – perverted from the original poem, where it meant “less technical perfection means more emotional impact.”
I wasn’t fully sure why Hicks decided to incorporate a commentary to his own story this way – maybe he was afraid that the sarcasm of “steel wanting to share its joy” and “lessness” and “simplificity” wouldn’t land well? Or perhaps it was just the introduction that didn’t quite work for me, as it confused the entire joke.
But it was fun to watch it twice anyway. Those stories are never easy. I am not ready to draw too many parallels between architecture and UX design, even if Hicks lightly does so at the end. There’s no gentrification and displacement when Liquid Glass takes over Aqua, although I think a lot of people would love to see a Apple’s recent design decisions meeting the business end of a wrecking ball.
My favourite recent saying to replace “less is more” is this, by Paul Valéry (another poet!):
Everything simple is false. Everything complex is unusable.
You can see it as unsolvable, cynical, maybe even nihilistic. I do too, on a dark day. But more often, I see it as a great challenge. “Less is more” has this simplistic seductiveness that feels naïve. “More” is not an option, but often in my work on complex systems “less” is neither, and a lot of UX design is finding the perfect shade of gray.
I keep thinking about this very good 11-minute Not Just Bikes video about traffic calming. In it, a simple argument is made: the posted speed limit of any given street or road doesn’t really matter. What matters is how the street feels. Generously wide and separated lanes, sparse traffic lights, and the road being straight past the horizon will make you unconsciously speed up. Reducing the posted speed limit or adding flashing YOUR SPEED signs won’t help:
The truth is that many drivers will not slow down because of signs or speed limits. They’ll slow down either because they don’t feel safe, or because they’re afraid of damaging their car.
The only answer is redesigning the street for the desired speed limit – narrowing the lanes or joining them, creating choke points and speed bumps, adding posts and planting trees close to the road, and even adding visual cues like “dragon’s teeth.”
One of the great thing about driving in the Netherlands is that it’s rarely necessary to look at the speed limit. The road design takes care of that for you.
There is an app I use a lot called Forklift, a suped up Finder, with one of its functions being syncing files to a remote server.
In its version 3, the syncing window looked like this:
This is a pretty straightforward and dependable function – and I’ve depended on it for years.
I recently updated to version 4 to check it out, particularly since it promised faster syncing. But I was thrown aback by how it randomly deteriorated:
It’s not that there seem to be some UI challenges: the new icons make it harder to understand hierarchy, and one of the switches starts with “Don’t” in contravence of rules of avoiding double negatives.
No, the worst part is this:
This is a new temporary state that meant to help me understand the details of what’s changing.
On the surface, it’s a thoughtful thing. But it’s done in the worst possible way for this kind of a power-user interface: It’s very slow to invoke and slow to cancel. I often activate it by accident – it makes large swaths of UI a minefield where you can no longer rest your cursor safely. It also changes the hierarchy of the output in a way that’s confusing – and it even animates the text wrapping in a distracting way. Then, if you press Esc instinctively to get rid of whatever happens, the window closes altogether.
It’s a “delightful,” luscious transition that is completely out of place. I think this is how many people misunderstand craft – that it’s only about “high polish” without any thought underneath. Here, the effort was spent on executing something that couldn’t be saved this way and needed a more serious rethink. It seems like its creators forgot who’s using the app and for what, and embarked on accidental UI calming.
There are other challenges along the same lines, both downgrades from version 3:
when the app analyzes the differences, I can no longer press the Sync button and walk away
even when the button becomes active, I can no longer press Enter to activate it – I have to use the mouse
In version 3, I could invoke Sync, immediately press Enter, and get on my merry way, with syncing continuing in the background. It was exactly what I wanted. Version 4 slows me down by requiring me to pay constant attention to the interface: it matters where I rest my mouse, it matters when I click the button, it matters what input device I use to commit.
It’s okay to think of friction and sometimes transitions are indeed very helpful for UI calming to avoid drastic movements or accidental activations. But here, this isn’t great at all; the creators of Forklift promised me faster syncing and achieved the opposite.
I thought Safari’s release notes are pretty good – exhaustive, direct, something you won’t ever read for pleasure, but something you can actually learn a lot from even if you are just scanning.
I wish either MDN or Can I use… integrated them in some way (and, of course Chrome’s and Firefox’s as well), so that looking up a certain feature or property – for example, will-change – would show you the recent changes in browsers in reverse chronological order, which could help you understand the details of the feature evolving, and help with debugging.
A really interesting 28-minute video by daivuk about making a first-person shooter game QUOD that fit in just 64 kilobytes:
I found watching it strangely enthralling and even nerve racking. The creator keeps adding stuff that seemingly has no chance of fitting into such a small space – textures! sounds effects! music! his own language! – and somehow finds a way to squeeze them all in.
This is inspiring, but also practically useful: even though you and I are maybe never likely to need such high optimization, some of these techniques alone could be useful in some tight quarters like a load-bearing CSS file, or embedded software.
As an example, the author wrote his own “music tracker,” which is a clever way to reduce the weight of music: instead of the tune being one big audio file, only the instruments are sampled, and then arranged in repeating patterns.
Except in his case, there were no instruments… just audio effects already existing in the game. And audio effects themselves were generated in a similar way, by combining smaller waves and effects.
The same was done for textures: the creator wrote a bespoke text editor that saves each texture as smaller pieces and combination instructions – a sort of a “PDF” of a texture rather than a more costly scan of the printed page – and re-generates it on entry.
Lastly, this debug view of “cost” was really interesting. (Good debug views, in my opinion, are generally underrated.)
As you progress in your UI design career, you learn that there are quite a few unsolvable challenges:
do you write My Items or Your Items in UI?
do you put hand cursors over buttons?
for a boolean item (especially in the menu), do you talk about the present state or the future state?
do you try to solve for change blindness or change aversion?
I was reminded of one of those today: how do you sort items in a bottom-aligned menu?
One school of thought is to keep it in the same order as you would a regular top-aligned menu:
On the positive side, this allows to build consistent understanding of how menus are structured: the most important thing is at the top, Quit is always at the bottom. But the downsides are obvious, too – now the most important item is furthest away from where you cursor started, and you have to awkwardly cross all the other items on the way to it.
iOS’s springboard went, literally, the other way:
Here, the bottom aligned menu reverses its item order. This tripped me up today. The dock in macOS was actually more defensible upside down because there, every menu was always going the same way. Here, the inconsistency starts rearing its ugly head.
Of course, the best way to not face an impossible choice is to avoid it altogether. Not sure how one could accomplish it here, though. Placing the menus consistently below would make some of them scrollable, or basically invisible for bottommost icons. You could also slide the entire screen up to make room for the menu, but that would probably feel disorienting.
So, I can’t say this is a wrong solution. The inconsistency might only bother people who use this often, and maybe no one uses this often? Or, perhaps, it was really important to allow to resize widgets and make that item as easy to tap as possible? But still, I think I would have done it the other way – align as needed, but items always in the same order.
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.
I feel macOS these days starts feeling like Windows in the 1990s where occasionally some core component of it breaks, and a reboot is necessary to restore it to full functionality again.
But even with that in mind: this happened literally right after the reboot, with nothing much happening and no other signs of the system in distress.
It’s hard for me to even understand what would make this kind of thing pop up. Trash feels like one of the core tenets of a GUI – like undo, or copy/paste, or windows gaining focus. You don’t expect it to just… stop working, especially with a circular error message like the above.
The breathing light – officially “Sleep Indicator Light” – debuted in the iconic iBook G3 in 1999.
It was originally placed in the hinge, but soon was moved to the other side for laptops, and eventually put in desktop computers too: Power Mac, the Cube, and the iMac.
The green LED was replaced by a white one, but “pulsating light indicates that the computer is sleeping” buried the nicest part of it – the animation was designed to mimic human breathing at 12 breaths per minute, and feel comforting and soothing:
Living through that era, it was interesting to see improvements to this small detail.
The iMac G5 gained a light sensor under the edge of the display in part so that the sleep indicator light wouldn’t be too bright in a dark room (and for older iMacs, the light would just get dimmer during the night based on the internal clock).
In later MacBooks, the light didn’t even have an opening. The aluminum was thinned and perforated so it felt like the sleep light was shining through the metal:
And, for a while, Apple promoted their own display connector that bundled data and power – but also bundled a bit of data, which allowed to do this:
Back when I had a Powermac G4 plugged into an Apple Cinema Display, I noticed something that was never advertised. When the Mac went to sleep, the pulsing sleep light came on, of course, but the sleep light on the display did too... in sync with the light on the Mac. I’ve tested that so many times, and it was always the same; in sync.
Just a little detail that wouldn’t sell anything, but just because.
To do this I shifted the first gaussian curve to that its domain starts at 0 and remains positive. Since the time domain is 5 seconds total and the I:E ratio is known, it was trivial to pick the split point and therefore the mean. By manipulating sigma I was able to get the desired up-take and fall-off curves; by manipulating factor “c” I was able to control for peak intensity.
But at that point, in the first half of 2010s, the breathing light was gone, victim to the same forces that removed the battery indicator and the illuminated logo on the lid.
I know each person would find themselves elsewhere on the line from “the light was overkill to begin with” to “I wished to see what they would do after they introduced that invisible metal variant.”
I know where I would place myself.
This blog is all about celebrating functional and meaningful details, and there were practical reasons for the light to be there. This was in the era where laptops often died in their sleep – so knowing your computer was actually sleeping safe and sound was important – and the first appearance of the light after closing the lid meant that the hard drives were parked and the laptop could be moved safely.
The breathing itself, however, was purely a humanistic touch, and I miss that quirkiness of this little feature. If a save icon can survive, surely so could the breathing light.
By definition security and usability coexist wearily, so it was nice someone thought about allowing me to do this at an opportune time, rather than at a random moment that might be extremely untimely or stressful.
I think a lot about bugs or design decisions that make software appear dumb.
At some point in my career I started fitting everything against two principles: “don’t make your app treat your user as if they’re dumb” and “don’t make your app itself feel dumb.”
To wit:
This is, very obviously, my website. I have made it from scratch. I have visited it a million times. And yet, at some point my friend Noah shared a link of it with me, so now Safari occasionally announces that with glee when I check it out.
Me having visited something many times should outweigh someone sharing it with me once.
There is a close box here, although you have to hover over the bar to see it. (And, after closing, it seems to come back after a few days!) I can also right click and choose Remove which does… absolutely nothing.
I believe this whole feature is called Shared With You. Elsewhere, on occasion, I find it useful. But its tentacle right here makes Safari appear just… kinda obtuse.
Also, speaking of obtuse: Can you spot a grave typographical mistake I made on this screenshot? (I already fixed it in production.)
Over the past few years, I’ve found myself relying on TextEdit more as every other app has grown more complicated, adding cloud uploads, collaborative editing, and now generative A.I. TextEdit is not connected to the internet, like Google Docs. It is not part of a larger suite of workplace software, like Microsoft Word. You can write in TextEdit, and you can format your writing with a bare minimum of fonts and styling. […]
I trust in TextEdit. It doesn’t redesign its interface without warning, the way Spotify does; it doesn’t hawk new features, and it doesn’t demand I update the app every other week, as Google Chrome does.
But I get the feeling that Chayka would be better served switching from TextEdit to Apple Notes for most of these things he’s creating. Saving a whole pile of notes to yourself as text files on your desktop, with no organization into sub-folders, isn’t wrong. The whole point of “just put it on the desktop” is to absolve yourself of thinking about where to file something properly. That’s friction, and if you face a bit of friction every time you want to jot something down, it increases the likelihood that you won’t jot it down because you didn’t want to deal with the friction.
Part of me agrees with this vehemently – for casual text wrangling, Notes is by far the best iteration of what both the old Stickies app and TextEdit attempted.
But Notes are still evolving. The UI keeps changing. I’ve had a note shared by a friend hanging alongside my own notes for years, without me asking for it. I remember the moment when tags were introduced, and suddenly copy/paste from Slack started populating things in the sidebar. Then there was this scary asterisked dialog that slid so well into planned obsolescence worries that it felt like a self-own:
And the attendant warning, ostensibly well-intentioned, adorned my notes for months, just because I had an older Mac Mini I barely touch doing menial things in a dusty closet:
On top of that, the last version of Apple Notes on my macOS occasionally breaks copy/paste (!), which led to some writing loss on my part. (If you cut from one note intending to paste in another, and realize nothing was saved in the clipboard, you lost the text forever.)
These are not show stoppers. But they too are friction that has to be juxtaposed with what Gruber lists in his essay. They’re also friction of the unexpected, new, stochastic flavour. TextEdit’s challenges, on the other hand, are known knowns. In this context, TextEdit is in that rare – and maybe increasingly treasured – place where it no longer gets updates, but it doesn’t feel abandoned, or falling apart, or at the risk of outright cancellation. (I think on the inside of tech companies this is called being “maintenanced” – not actually staffed to be improved, but still eligible for breaking bug fixes and security updates.)
We need to normalize declaring software as finished. Not everything needs continuous updates to function. In fact, a minority of software needs this. Most software works as it is written. The code does not run out of date. I want more projects that are actually just finished, without the need to be continuously mutated and complexified ad infinitum.
Personally I would be very happy to live in a postcapitalist world where it was 100% FINE that desktop operating systems had “stopped evolving” because they were good enough to meet basically everyones’ needs, and there was no stock price to crash from an old monopoly having clawed its way to the top with nowhere else to go. “Let [certain] software be finished” has always felt to me like oblique pining for humanity to outgrow our current political-economic system.
The fact that in the 10+ years I’ve been using it, there’s only been a single major overhaul update is a feature, not a bug to me.
I have seen this sentiment grow in recent years, as AI is seemingly shoved into every crevice of everything whether or not it even had crevices to begin with. Liquid Glass on the Mac side and incessant ads plus bugs on the Windows side add to the malaise.
But I’ve also been in technology so long that even outside of tensions of capitalism, it’s hard for me to imagine software not changing. Code does run out of date even if you try very hard. So I don’t know yet how to square all this.
Bear is not finished/“maintenanced,” but it seems to not be changing the same way some other software is changing, either. I’m excited reading its blog – even if there are features or updates that do not pertain to me, they don’t bother me, and make me excited for others benefitting. Its innovation feels considered, not reckless.
In a week I’m praising products I didn’t expect to praise, I feel similarly about Lightroom Classic. When Adobe in 2017 forked Lightroom Classic out of the newly-refreshed Lightroom, a lot of us got worried about the “Classic” tag having “dead man’s walking” connotations. But nine years later, and Lightroom Classic is still being lightly updated with fixes, camera presets, and – occasionally – feature changes that largely feel welcome. Lightroom Classic appears, to once again use industry jargon, “stable.”
Maybe the answers are somewhere in this post: celebrate and fund “maintenanced” apps, fork apps into “stable” and “modern” paths, or encourage and practice slow, considered growth. I bet there are other approaches and altogether new ideas to try, too. (There used to be a tradition, when software was physical, to list all the new stuff at the back of the box. What if we started writing out the things we didn’t add?) But I like at least talking about it to begin with. There are apps in my life I want to feel like TextEdit, there are apps that I want to feel like Notes, and there are ones I’m happy to put on the cutting edge/beta/canary path, where bugs are a promise, and motor memory a distant dream.
I yearn for a software ecosystem that allows all of these types of apps to blossom.
As a Mac user I naturally focus on that platform, but Windows 11 has had its own share of problems – and that list has grown so vast it’s hard to know where to start.
So let’s pick it up at random, with a post by Thom Holwerda with a great title “You can actually stop Windows Explorer from flashbanging you in dark mode”:
One of the most annoying things I encountered while trying out Windows 11 a few months ago was the utterly broken dark mode; broken since its inception nine years ago, but finally getting some fixes. One of the smaller but downright disturbing issues with dark mode on Windows 11 is that when Explorer is in dark mode, it will flash bright white whenever you open a new window or a new tab. It’s like the operating system is throwing flashbangs at you every time you need to do some file management.
I find the videogame-inspired nickname darkly – I’m sorry! – funny, but the problem is real. It looks like this (video via windowscentral.com):
It’s not a problem unique to Windows 11 – just the other night I saw this on Wikipedia on my iPhone, exacerbated by the delayed reaction of Liquid Glass buttons spastically adapting to the changing background:
But there is something about this that feels a notch more important than other visual and layout issues.
I think this is because dark mode is a contract – we’ll lower the brightness, and we’ll let your eyes rest. There’s a physiological part to it: a sudden flash of light when your eyes are not expecting to it can be actually physically painful. I think it’s worth thinking about it and futureproofing and sanding dark-mode views especially at their edges: loading states, error messages, signing in and logging off areas. The “flashbang” analogy is very apt, and especially so on bigger screens.
I have been enthralled with this tiny feature in Google Sheets called “Show edit history,” which premiered in 2019:
Mind you, it’s not unconditional love. The execution feels a bit clunky, showing the edit values in a pop-up rather than in situ, with formatting that feels too heavy, and an awkward “No more edit history” state rather than just disabling the button.
But! Just its very presence here is delightful. Version history is often this huge, comprehensive, perhaps disorienting mode you enter that by design deals with the entire file. It always feels like a longer trip:
But edit history reimagines the feature from the perspective of the cell. You can just peek inside, quickly and effortlessly. Right click menu, a few arrows, I learned what I needed, and I barely even moved my hand. It’s a perfect example of the rule “to make something feel faster, make it smaller.” It’s like picking your newspaper at your doorstep in your pajamas rather than having to dress up to go to the newspaper store.
(…he said, dating himself and perhaps also thinking of The Sopranos for some reason.)
This kind of reimagining of something that already exists (see: undo send in Gmail) can be really hard, and I don’t even imagine Google Sheets was the first with this idea – but for me seeing this remix was eye-opening, and it inspires me to this day.
I’m not going to spoil the surprise. Am I fully supportive of the approach? Not sure. PlayStation’s region protection complicates my feelings, and any sort of DRM-esque approach eventually backfires when it comes to software preservation. But you can’t deny what Spyro developers did is a really fascinating and weird approach.
The quote in the title of this post refers to the hackers who eventually did conquer the Spyro’s copy protection system. I guess – and I apologize in advance – game recognize game.
Palette cycling is an interesting technique borne out of limitations of old graphic cards. Today, any pixel can have any color it wants. In the 1970s and 1980s, you were limited to just a few fixed colors: as few as 2 for monochrome displays, or 4, or 8, or – if you were lucky – 16. Some of those fixed palettes, like CGA’s, became iconic:
But there was an interesting hybrid period in between then and now where you still were only allowed 4 or 8 or 16 or 256 color choices in total, but you could assign any of these at will from a much bigger palette.
So, as an example, each one of these three is made out of 16 colors, but each one is 16 different colors:
Moving pixels was slow. But palette swaps were so fast and easy, that it led to a technique known as palette cycling. This is probably the best-known example, from an Atari ST program called NEOchrome.
Despite so much apparent movement, no pixels are changing location, as that’d be prohibitively slow in 1985. Only the palette is changing. If you watch the same animation with the UI visible, you can clearly see which colors are “static,” and which are moving around:
But this was 1985, so why I am mentioning it 40 years later?
I like looking at old computers for a few reasons. Some of these seeminly-ancient techniques are inspiring and remind me that the limitations are often in the eye of the beholder. Seeing someone really good pushing a platform to its limits is just a good thing to load into your neurons – this could be you next time! And, believe it or not, some tips and tricks can still be relevant.
For example, this is a 9-minute video by Steffest from just earlier this year that walks through a modern attempt to make a palette cycling animation, including starting on an iPad:
The end result goes much harder than I expected. It was interesting to see again the technique of dithering to simulate transparency (we’ve seen it before, but this one is more advanced). But what particularly stood out to me here was the artist making his own little tools to aid in the creative process; I’ve always loved the notion that a computer is really just meant to be an accelerant, making it easy for you to avoid drudgery.
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.
My post about Flickr URLs gathered some interesting responses (especially on Mastodon, thank you all!), so I thought I’d do what podcasts call a “mailbag episode”!
Some people pointed out other good examples for inspiration. Chris Silverman:
The idea of URLs as user interface elements is such a good take. I’ve seen some people use URLs as design/communications elements as well, like Jessica Hische:
www.jessicahische.is/thinkingthoughts
www.jessicahische.is/working
jessicahische.is/anoversharer
I love that approach. Modern browsers and preview cards often obscure URLs, but people still see these things; printed materials, links in emails, etc.
Matt Goldman:
I really like letterboxd’s urls these days:
all the films in my diary in 2024? letterboxd.com/robotmlg/diary/films/for/2024/
movies I’ve tagged as seeing at Film Forum? letterboxd.com/robotmlg/tag/film-forum/films/
five star reviews that I wrote in 2021? letterboxd.com/robotmlg/reviews/films/for/2021/rated/5/
Both Erin Sparling and Nelson Miner highlighted how much the craft of Flickr URLs related to the craft of its API:
Literally used to talk about how good this URL scheme was in class, it was so informative. The Flickr API still informs everything I do these days, URLs included.
There was some discussion about the pattern I suggested. Which one should it be?
I will admit: I don’t know. Each has pros and cons – some are better for autocomplete, others better for conveying hierarchy or surviving “removing from the end.”
This note arrived via email:
Hey, www is not redundant. In services like NextDNS it allows blocking only main site, without subdomains. So it gives more control and cost nothing :)
To which my answer is: I don’t think you’ll get to great user experience by prioritizing corner cases like this one.
Jim Nielsen shared some of his favourites, and Søren Birkemeyer suggested more evergreen reading on the subject, with more inspiration inside:
The middle one caught my attention because it talks about URLs that are not just user readable, but also user guessable. I think that’s a perfect word for something I tried to capture in my post: if a user successfully guesses a URL from your scheme, then you know you have something good on your hands.
Lastly, a few people mentioned the late 1990s classic written by a relatively unknown dude going by “Tim BL,” called Cool URIs don’t change.
Historical note: At the end of the 20th century when this was written, “cool” was an epithet of approval particularly among young, indicating trendiness, quality, or appropriateness. In the rush to stake [out] DNS territory involved[, ] the choice of domain name and URI path were sometimes directed more toward apparent “coolness” than toward usefulness or longevity. This note is an attempt to redirect the energy behind the quest for coolness.
It is incredible how far we have come for these barely-distinguished placements to be called “visually separated”. Google’s ads, for example, used to have a coloured background, eventually fading to white. The “sponsored link” text turned into a little yellow “Ad” badge, eventually becoming today’s little bold “Ad” text. Apple, too, has made its App Store ads blend into normal results. In OpenAI’s case, they have opted to delineate ads by using a grey background and labelling them “Sponsored”.
Now OpenAI has something different to optimize for. We can all pretend that free market forces will punish the company if it does not move carefully, or it inserts too many ads, or if organic results start to feel influenced by ad buyers. But we have already seen how this works with Google search, in Instagram, in YouTube, and elsewhere. These platforms are ad-heavy to the detriment and frustration of users, yet they remain successful and growing. No matter what you think of OpenAI’s goals already, ads are going to fundamentally change ChatGPT and the company as a whole.
For a few months now, when re-running search queries in Bluesky’s iOS app, I ended up occasionally arriving on the wrong search, and it happened enough that I started suspecting something’s afoot. (Ahand?)
So I opened the app on my Mac via iPhone Mirroring, and started clicking testing carefully. This is what I saw:
Turns out there was something wrong there – the touch targets are so vertically lopsided you’ll often end up tapping the item below by accident.
This is a nice way iOS Safari behaves the moment you tap one of the font size buttons – it immediately ejects all the other chrome:
After Liquid Glass specifically, we seem to be going through an interesting re-evaluation of whether “the content is the king; it should feel expansive and UI should get out of the way at all costs,” so seductive as a principle, is ultimately the right approach. Liquid Glass-sporting operating systems have so many contrast and blending and distraction issues that I wonder if they alone are radicalizing people, making them appreciate traditional rigid toolbars with solid backgrounds and fortified borders.
But here? Here letting contents shine and putting the UI atop feels like the absolutely right thing to do, since you are redesigning your reading experience.
Contrast this with Books:
It’s not even that the crossfaded transitions feel awkward. It’s mostly that the interface takes up so much room that the content preview slice becomes almost claustrophobic. And it’s even weirder when you tap the Customize button, and whatever was visible gets inexplicably replaced by a pop-up with… largely the same content anyway.
How will the entire page feel? For that you have to use your imagination – or keep tapping back and forth.
San Andreas was released in 2004, but the game started breaking only after Windows got updated… in 2024. Turns out the bug was sort of a ticking time bomb just waiting for the right set of conditions. We covered one similar bug before, in Half-Life 2 – but this investigation goes deeper, and shines a light on the difficulty of making Windows, whose backwards compatibility comes at a price.
This was incredible and a breath of fresh air. No redundant www. in front or awkward .php at the end. No parameters with their unpleasant ?&= syntax. No % signs partying with hex codes. When you shared these URLs with others, you didn’t have to retouch or delete anything. When Chrome’s address bar started autocompleting them, you knew exactly where you were going.
This might seem silly. The user interfaceof URLs? Who types in or edits URLs by hand? But keyboards are still the most efficient entry device. If a place you’re going is where you’ve already been, typing a few letters might get you there much faster than waiting for pages to load, clicking, and so on. It might get you there even faster than sifting through bookmarks. Or, if where you’re going is up in hierarchy, well-designed URL will allow you to drag to select and then backspace a few things from the end.
Flickr allowed to do all that, and all without a touch of a Shift key, too.
Any URL being easily editable required for it to be easily readable, too. Flickr’s were. The link names were so simple that seeing the menu…
…told you exactly what the URLs for each item were.
In the years since, the rich text dreams didn’t materialize. We’ve continued to see and use naked URLs everywhere. And this is where we get to one other benefit of Flickr URLs: they were short. They could be placed in an email or in Markdown. Scratch that, they could be placed in a sentence. And they would never get truncated today on Slack with that frustrating middle ellipsis (which occasionally leads to someone copying the shortened and now-malformed URL and sharing it further!).
It was a beautiful and predictable scheme. Once you knew how it worked, you could guess other URLs. If I were typing an email or authoring a blog post and I happened to have a link to your photo in Flickr, I could also easily include a link to your Flickr homepage just by editing the URL, without having to jump back to the browser to verify.
Flickr is still around and most of the URLs above will work. In 2026, I can think of a few improvements. I would get rid of /photos, since Flickr is already about photos. I would also try to add a human-readable slug at the end, because… flickr.com/mwichary/sets/72177720330077904-alishan-forest-railway
…feels easier to recall than… flickr.com/photos/mwichary/sets/72177720330077904
(Alternatively, I would consider getting rid of numerical ids altogether and relying on name alone. Internet Archive does it at e.g. archive.org/details/leroy-lettering-sets, but that has some serious limitations that are not hard to imagine.)
But this is the benefit of hindsight and the benefit of things I learned since. And I started learning and caring right here, with Flickr, in 2007. Back then, by default, URLs would look like this:
Flickr’s didn’t, because someone gave a damn. The fact they did was inspiring; most of the URLs in things I created since owe something to that person. (Please let me know who that was, if you know! My grapevine says it’s Cal Henderson, but I would love a confirmation.)
Shadeed argues that this ugly responsive interregnum happens a lot more than people might assume, as part of natural window management on larger screens. If you un-maximize the window, use one of the many split-screen features, or something like link preview, it might push the browser into a width slice you might have thought was not actually realistically occupied.
Also, what caught my attention at the bottom of the post was this smart visualization. I wish the responsive design features in my browser’s web inspector did this kind of thing automatically:
★★★★★ (as books)
★★★★☆ (for the purposes of this blog)
I still remember Mac OS X arriving on the scene with icons that felt infinite in every possible way: in size, in color palette, in dimensionality. We got used to them over the last quarter century, but Michael Flarup’s books rekindled that feeling for me; the icons presented here are lavish, larger than life, and basically pixel-less.
I do not generally like coffee-table books. But I really liked these. The iOS App Icon Book came out in 2022, and the macOS App Icon Book followed two years later. They’re “almost-coffee-table” – which is a compliment! – extremely well-made but portable, and with soul, and thoughtful details, and inspiring evidence of being labours of love.
Each one has an almost-absurd amount of icons (I counted almost 1,200 in one book, and consequently didn’t even attempt counting in the other), but it’s not just the quantity that impresses. The icons are laid out carefully on gorgeous color-coordinated spreads. Many appear in variations so you compare their evolution over the years. Each one is big enough and printed so well you can study it in detail, and I have not noticed one technical flaw in their reproduction.
In addition to beautiful collections of beautiful icons, the book also veers a bit into history, and design advice, and adds ~10 interviews with icon designers each. Those are welcome additions that elevate the books from a boring coffee-table existence, but those are also its weakest parts – although “weakest” in a comparative sense. The things missing for me in the book are: more work in progress and rejected efforts, more specific advice and hard-learned lessons rather than general-interest interviews, a bit more about recognition of icons when reproduced small on screens, and some harder/cerebral conversations about iconography and its place in the universe.
On the other hand, I know that of all icons it’sapp icons that get to be least concerned with semantics and semiotics, as they’re maybe the closest to just pure art and graphic design. I can understand how talking through it all would be an extremely hard task; all of the fantastic icon designers I know personally would struggle with explaining why their output is better than others. It’s possible the extra “left-brain” stuff I want from these books would also make them less desirable for those who just seek visual or artistic inspiration.
Both books are otherwise basically a love letter to app iconography, and awash in memorable details: delightful covers, colour-coordinated ribbon bookmarks, beautiful ex librissen, and a product index and an artist index.
The price – $84 without shipping (they’re printed in Denmark, so for once Europe gets an advantage) – might be a bit of a showstopper. The books are well-made, but you are definitely paying a premium for a short/bespoke print run. The volumes complement each other well on a shelf, but you’ll do no wrong with getting either one if two is too much for your budget. (There is also a half-price PDF version, if that’s of interest to you, but I cannot vouch for that.)
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.
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.
I was randomly checking the Wikipedia entry for killer apps – apps that were so good that they single-handedly made people buy a particular hardware platform just to run them (Wii Sports for Nintendo Wii, Super Mario 64 for Nintendo 64, and so on).
There are some interesting nuggets in there I didn’t know, like Sibelius (music software) being a system seller for the British computer Acorn Archimedes, Xevious doing the same for Famicom (I had no idea Xevious, as beautiful as it is, was so huge!), and Steve Jobs focusing so much on making calls on the first iPhone. How quickly we started taking visual voicemail for granted…
But I was suprised not to see killer apps for Fortnite, Minecraft, Roblox, or even Mac OS X. Does the concept of killer apps not work anymore? Is iMessage a killer app for those who want blue bubbles, but it’s much harder for us to know that?
(I’m also curious about a parallel list of botched updates: Digg in 2010, Sonos in 2024, the “simplified” iMovie ’08 and Final Cut Pro X, Liquid Glass, as some of them ended up being anti-killer apps. I don’t immediately see anything like this online, but it could be an interesting series of posts to analyze those more carefully, going past schadenfreude or ridicule.)
Also, it made me think of one of my favourite ads. It’s for VisiCalc, the first computer spreadsheet, and the first-ever killer app. The ad was unassuming, small, in a corner of a 1979 computer magazine. But, in hindsight, what a prescient and brilliant question: How did you ever do without it?
We take spreadsheets for granted, too, but chills. Literal chills.
I was embarrassed for Apple when I saw the recent bug fix for columns introduce a new bug, explained in this post by Jeff Johnson:
Without the path bar, the columns are now taller, but the vertical scrollers remain the same height as before, leaving vertical gaps, a ridiculous amount of space between the bottom of the scrollers and the bottom of the columns, looking silly and amateurish.
It’s impossible to talk about craft without talking about embarrassment, and pride, and shame, and lust, and a lot of other words – all tricky to describe, all fluffy. So, I tried to interrogate my feelings.
First, it was embarrassing that it broke. I’ve been there: you build a complex system, and forget about some lesser-known state. That’s why it’s important to invest in whatever it takes to shine a light on those states: quality assurance, automatic screenshotting, tests, and so on. Sometimes it’s simple hacks – like half of your team having scrollbars visible. And when you notice a bug, you try not to just fix it, but to rebuild it to be stronger (“leave the campsite in a better place you found it”) – be it by fixing the cause and not just the symptom, adding unit tests, changing practices, and so on.
But it also felt embarrassing how it broke. It feels clear there’s some manual calculation going on somewhere, and someone forgot to add this new change to it. One of the tricks I learned over time is that a well-designed system designs itself, but it takes effort and imagination to make a system resilient in this way. Here, if there was some abstraction of “adding stuff to the bottom,” then you wouldn’t have to worry about adding extra math. The system would take care of itself in many of these corner cases you will forget about.
I don’t want to shame (see, that word again!) individual people at Apple because I don’t know if it’s the lack of talent, or the whole system being wired in a way that doesn’t reward forward thinking or the kind of invisible work that needs to happen in those spaces. But the embarrassment should be there – if it doesn’t exist inside Apple, then that’s perhaps the sign of a real problem.
Old-school computing has a term “molly guard”: it’s the little plastic safety cover you have to move out of the way before you press some button of significance.
Anecdotally, this is named after Molly, an engineer’s daughter who was invited to a datacenter and promptly pressed a big red button, as one would.
Then she did it again later the same day.
You might recognize molly guards from any aerial combat movie you ever watched:
And some vestigial forms of molly guards exist everywhere in civilian hardware, too: from recessed buttons, through plastic ridges around keys, to something like a SIM card ejection hole.
Of course, molly guards happen in software, too: from the cheapest “are you sure?” dialogs (which sometimes move buttons around or disable keyboard activation to slow you down), through extra modifier keys (in Ctrl+Alt+Del, the Ctrl and Alt keys are the guards), to more elaborate interactions that introduce friction in places where it’s needed:
But it’s also worth thinking of reverse molly guards: buttons that will press themselves if you don’t do anything after a while.
I see them sometimes, and always consider them very thoughtful. This is the first example that comes to my mind:
Here’s what became a standard mobile pattern:
These feel important to remember, particularly if your computer is about to embark on a long process to do something complex – like an OS update or a long render.
There is no worse feeling than waking up, walking up to the machine that was supposed to work through the night, and seeing it did absolutely nothing, stupidly waiting for hours for a response to a question that didn’t even matter.
It’s good to think about designing and signposting those flows so people know when they can walk away with confidence, and I sometimes think a reverse molly guard could serve an important purpose: in a well-designed flow, once you see it, you know things will now proceed to completion.
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.
I am pretty sure this is nothing new for heavy command-line gurus (and heavy Raycast users, and so on), but I found it delightful to see someone so excited about creative uses of the terminal, and it made me realize how much time I do waste going through the browser, then Google Search, then scrolling. I am sure tightening some of these loops would feel great.
There is also something interesting in the argument about terminal being the ultimate “reading mode” of any website, chiefly because it cannot be anything else.
Mostly, this and Strudel before make me excited to see some new (to me) stuff happening with text-based user interfaces.
But it also made me think. I still strongly associate macOS shake with “wrong password,” meaning “you’re doing something wrong” – something the system has been teaching us ever since the late 1980s NeXT computer, whose windowing manager it inherited. Am I careful about the motion vocabulary and the semantics of shake, or am I simply overthinking it? Sometimes it is hard to tell.
(By the way, is it okay for me to link to random work by strangers, or is it weird? Don’t be afraid to let me know. One thing I want to practice on this blog is various ways to be a critic, in the sort of Roger Ebert sense.)
I spotted this interesting thing at work today, and was curious about that phrase at the end:
Turns out, it is basically a unique human-readable encoding of a 32-bit digit, I’d guess particularly for ease of voice/phone support communication. (Otherwise I imagine copy/paste would work well?)
What is novel in Asana is the form these IDs take. In most other applications, a customer-facing ID is usually a long jumble of numbers and/or letters. There are lots of small, subtle drawbacks to representing a number to a human this way, and so for the sake of curiosity—and to add a little levity to an otherwise frustrating situation—we tried something different.
Imagine representing 32 bits of information (numbers up to 4 billion) as a sentence instead of a jumble of digits. One possible sentence structure can be: count + adjective + plural noun + verb + adverb, e.g. “6 sad squid snuggle softly.”
I am very curious what data gets encoded this way since 32 bits is not really a lot. That detail, however, is not covered in the post.
When the project succeeded, her work had dissolved into the project’s infrastructure. The doc was just “the doc.” The tracker was just “the tracker.” The alignment was just how things were. People forgot it had ever been otherwise. That’s the thing about good coordination. I’ve realized that when it works, it disappears. You can’t see it precisely because it worked.
Even though Pandya didn’t call that out, it’s worth highlighting that his “founder friend” example wasn’t a woman by pure chance; often the invisible work becomes the second shift of women in the workplace. And then:
The problem is that recognition follows narrative. When a project succeeds, credit flows to the people whose contributions are easy to describe. The person who presented to the board. The person whose name is on the launch email. The person who shipped the final feature. These contributions are real, I’m not diminishing them. But they’re not more real than the work that made them possible. They’re just easier to point at. Easier to put in a slide. And I think that’s where the unfairness starts, slowly, without people really noticing.
However, I disagreed with these parts:
There’s no framework that fixes this. You can’t design a rubric that captures “held the project together.”
Wait, why not? This is a similar challenge to quantifying design contributions (some of which might not clearly map to KPIs or sometimes even OKRs). You can’t measure being in the flow, true user satisfaction and frustration, or world-class-adjacency of taste. But it doesn’t mean you cannot design a system or a rubric that recognizes and talks about them.
I learned from Diana Berlin’s always excellent newsletter Diagonal that Stewart Brand has a new book out, and it’s about maintenance, and it’s published by Stripe Press. From the introduction:
This book, I’m pretty sure, is the first to look at maintenance in general. It asks: What can be learned if you think about all the varieties of maintenance at the same time? I doubt if there are any non-trivial “laws” of maintenance to be discovered. All I can offer here is to muse across a representative sample of maintenance domains and see what emerges.
Very excited to give it a go, somewhat worried about “Part One” appearing in the title, disappointed in Stripe not caring enough to ask one woman for a blurb.
This is incredible – a story of a museum exhibit that replicated an experience of being a tech support person for a videogame company some time in the early 1990s:
You knew hint lines existed, right? 1-900 numbers, long-distance charges, hoping whoever answers actually knows what they’re talking about. They had incomplete documentation, contradictory notes, whatever the previous shift scribbled down. Nintendo’s Power Line is probably the most famous example. There’s a few great videos floating around about them.
The team invented a few new games (“We weren’t just making a game about hint lines. We were making the games that would’ve required hint lines to exist in the first place”), a few personas, and put together a 300-page realistic binder:
The entire story is so worth a read.
Looking back, we think ACMI said yes because we pitched infrastructure, not nostalgia. If you’re old enough, you probably remember that hint lines existed. We wanted people to experience what it was like to be part of that system.
[…]
Next time you tab over to a wiki page or watch a YouTube guide, spare a thought for hint line counselors of the early 1990s, armed with incomplete documentation, good intentions, and hope that the person on the other end was asking about a game they’d actually played. They were unsung heroes of gaming’s most chaotic era, and now, for a few minutes at least, you can experience their particular brand of helpful desperation firsthand.
The exhibit is still available at ACMI in Melbourne until March this year, “along with a life-size usable corporate cubicle (with a dead plant!) and matching hardware straight from the ’90s.”
You can also play it online, although the team warns: “Online is not the intended experience. Flipping through the physical artifact is half the fun.”