It’s really funny, romantic (maybe a bit too romantic), and it has a few great examples and explanations of the different kinds of speedruns that exist.

#games #speedrunning #youtube

Perhaps the worst UI crime in MacOS 26 Tahoe was the inexplicable decision to add inscrutable, distracting icons next to every item in the menu bar. You will recall Jim Nielsen writing about it, rightly describing it as exactly the sort of thing that Mac users look down upon in platforms like Google Docs and Windows. You will also recall Nikita “Tonsky” Prokopov writing about it, illustrating that the bad idea wasn’t even implemented well, with different Apple apps using entirely different icons for the same menu items. […]

Top third-party developers rightly rejected the design, adopting open source code from Brent Simmons to disable the default “icons in all standard menu items” behavior. […]

Wonderful news in MacOS 27 Golden Gate: the icons are gone. It’s like Tahoe’s menu item icons never happened.

Kudos to Nielsen and Prokopov for pushing on this and explaining the problem so well. This wasn’t about ugly icons. This was about improper use and misunderstanding of iconography.

(Also may I try to manifest something:) Looking forward to reading the oral history of macOS 26 Tahoe and Liquid Glass some time in the 2030s!

#apple #iconography #mac os

It’s obviously bad craft and crossing over to the “embarrassing” territory, but I thought it’s an interesting question: what happened?

The main piece of the puzzle is that the first menu shows the name of the font in San Francisco, but the second asks to render the font name in itself, serving as a font preview.

Font previews are fascinating because they are the perfect showcase of how tricky fonts can be at scale.

Some time ago, I wrote an essay called Typography is impossible. TL; DR: It’s actually impossible to left align or center text. Ever. Not just because each font does whatever it wants – font size is a number that doesn’t really give you anything to hang a hat on, and the font can place itself in its box however it desires, too – and not just because fonts often lie (via bad metrics) about what they store inside, but also because aligning and centering are really in the eye of the license holder, and have more than one definition.

So, every time you align text to anything, in whatever way, it’s only an approximation. Most of the time that’s good enough. Here it is not.

I worked on font previews at Figma, and wanted to show you three screenshots of what we did.

This first one shows the default attempt: we ask the fonts to render themselves in the same size (16px), vertically centered in a box that’s always 28px tall… and they oblige on paper, but it really doesn’t feel like they are:

The second take shows what happens if you nudge the fonts up and down so they’re aligned to their baselines. This at least creates vertical rhythm; in effect, we need to make the fonts uneven to make them feel even.

And this is the final result, with extra adjustments:

What do we do in the final version? Too many small things to mention, but in essence:

• We literally measure the fonts (programmatically) by rendering them and looking at them, and make adjustments. We blow them up (but not too much) if they’re optically too small, or reduce them (but not too much) if they’re too big.
• We have a multiplier for scripty fonts and monospace fonts, where the traditional measurements are likely to be off.
• We even special-case specific fonts by name. That feels like bad practice, but fonts are so varied and all over the place, that I think it’s perfectly fine to make exceptions for particular individual fonts that are popular or otherwise very important to your users.

These adjustments are all in the same category: getting off math balance to get to optical balance.

Here, you can compare before (the naïve version) with after (the final version):

If it feels subtle, imagine it applied to a much wilder menagerie of very thin, very huge, or very strange fonts. (The go-to example? Open a Mac and try typing in Zapfino.)

I’m not showing this to brag about my work – okay, fine, to some extent I am, we’re all human – and I truly believe this could be so much better, still. There are icon fonts, color fonts, and non-Western fonts so rich in variety and tradition that this category itself is basically a fractal.

Mostly, I wanted to share this lesson: dealing with fonts is hard, and dealing with fonts as a system even more so. Whether it’s the printing press, paper, or Illustrator, it takes people years or even decades to fully learn the craft of setting type, and to believe their eyes instead of only relying on math. But here, what’s needed is manufactured craft: we have to teach the machine to trust its eyes (which it doesn’t have) over math (which it can’t escape).

Now if you’re wondering why font previews look bad in so many apps, I believe it’s because people working on those did not allocate enough time to deal with all that.

But I’ve used the word “embarrassing” as there’s one more thing that the original did poorly, and something the reader identified immediately. The makers of PowerPoint allowed the font to escape its containment:

This is another big lesson: fonts will ignore their bounds at every single opportunity. That infamous CSS IS AWESOME graphic? That’s CSS underestimating text. That naked URL or code snippet pushing the mobile site past the viewport and making it scroll? That’s the creators of the site not building up enough imagination of what fonts can do when they’re not watching. Zalgo text? A joke, but based in reality.

Fonts are so much more feral than you think. Are you ready for it?

Thank you to Giovanni Lanzani for sending in the original PowerPoint screenshots.

#details #typography

(I bet you witness a version of this all the time when dealing with “I forgot my password” flows which should pass on your login from one field to another, but they don’t.)

I’m not saying this dialog is beyond reproach; one way to reduce this problem would be to make those two treatments different enough visually to reduce the chance of confusion. But it doesn’t matter, because the truth is that often there is no dividing line between the problems and the symptoms, and both overlap to a scary degree.

As a designer, I think it’s sometimes good to simply face this truth: no matter what I do, the user might type something into a wrong field. Anything I can do to help then?

#got your back #interface design

As it always happens, what we thought was the first screensaver – Peter Socha’s SCRNSAVE – was far from the original idea:

The accepted answer is often the easy answer, and when doing a little research, you can bust past that to the point of truth. [… But] while Socha deserves credit for popularizing the technique with a broad audience, the idea wasn’t totally new. See, during the 1970s and early 1980s, numerous hardware and software developers attempted to build things in the same wheelhouse as Socha’s early screen saver. The difference was, they weren’t for the IBM PC or even for a computer at all. Rather, they were for dumb terminals or video game systems.

The prior art includes “attract mode” in arcade games, and is accompanied by the absolutely terrifying, jump-scare-adjacent photo of CRT burn-in you wouldn’t want to miss.

2.
This is an enthralling 1-hour-long video by Savvy Sage that talks about the immense popularity of After Dark, a collection of screensavers for Macs and PCs, of the “flying toasters” fame:

This video absolutely blew my mind. I had no idea the screensavers were so popular that they had their own (official) merch and (unofficial) guidebooks, and that the company that made them employed over 100 people – half of them artists – and had tens of millions of dollars in revenue.

There’s tons of inevitable scope creep – screensaver remixers! screensavers with sound! interactive screensavers! licensed screensavers? – but also attempts to branch out to new ideas.

The video is great in documenting everything so you actually see all that’s talked about, in copious detail. And since this is a blog about craft, obligatory caveat: most of these screensavers are absolutely garish, although one also has to account for state of the art of computer graphics at that time.

3.
After Dark had a fish aquarium and so did competing products from Microsoft and Fifth Generation Systems – but in a moment likely recognizable to many people reading this blog, one person got fed up with how bad they all looked and created his own screensaver that became as well known as the flying toasters.

This 16-minute video by LGR talks about the story of The Marine Aquarium Screensaver:

This, too, had a lot more going on than I expected, including the eventual appearance of a hall-of-fame checkbox “Starfish allowed on glass.”

4.
Another popular screensaver was Windows’s 3D Pipes, whose (much shorter) origin story is documented by Raymond Chen on his excellent and long-running The Old New Thing blog.

But it’s the first comment there that steals the show:

These were mesmerizing, but quite often IT folks would enable these on Windows Servers, and they would essentially “bring down the system.” See, they were CPU intensive and would take a tax on the system essentially stealing CPU time away from the business application running. […]

I can recall the first time getting a call on this – and back then things were remote, etc. sometimes using PCAnywhere – and then I saw 3D Pipes running. Just told them to turn it off – and done. From that point forward the first question asked of our customers was “are you running any screen savers?”

3D Pipes also had some interesting lore behind it:

A customer complained that they were losing productivity because employees were spending too much time running the 3D Pipes screen saver and waiting for teapots to appear. They requested an option to increase the likelihood of a teapot, so the employees would be placated more quickly and get back to their work.

If this doesn’t remind you of that scene from The Office with another famous screensaver…

5.
In Smith’s essay, he posts Socha’s recounting of the exact logic of his early screensaver:

How does Scrnsave do all this? The clock inside your PC ticks 18.2 times per second. Scrnsave contains a three-minute counter that starts at 3276—the number of clock ticks for three minutes. On each tick of the clock, Scrnsave subtracts one from this count, and it turns off the screen when it reaches zero. […]

Each time you push or release a key, the keyboard sends an interrupt signal to the PC. Scrnsave intercepts this interrupt; each time you push or release a key, Scrnsave resets its counter to 3276 (three minutes) before passing control to the ROM BIOS routines that read keystrokes. Scrnsave also resets its counter to 3276 every time a program sends characters to the screen. By intercepting these last two interrupts, Scrnsave can tell when you need to have the screen active, so it won’t shut out the lights unless you sit back or walk away for three minutes or more.

It’s a very simple algorithm, but I was amazed by it, because that’s exactly the same algorithm you would use – in reverse – for any sort of debouncing that’s crucial in good front-end engineering; there is something kind of beautiful about these universal algorithms floating around, kind of like math quietly ruling the world around us.

But on that note, one last video. Do you remember that well-known palette-cycling waterfall I posted some time ago?

This wasn’t as much a “prevent CRT burn in” screensaver as it was “a piece of standalone, repeating, interactive art” screensaver. It graced many an Atari ST display.

Well, in April, a YouTuber Techmoan unpacked sort of a “prior art” to that, too – a picture frame that simulates a waterfall (the relevant video segment starts at 6:04):

The art is (again) garish, and there is no screen to save here, but also curiously – there are no electronics at all, either. How was it made? I’ll let you click through to find out.

It was fun for me to revisit this strange moment in time and learn more. It’s not just that there were tons of shared ideas, repeated algorithms, independent reinventions, and one-upping each other. What stood out to me was also how many people engaged here did other things I used and admired – SCRNSAVE’s Peter Socha created the absolute 🐐 Norton Commander, Jim Sachs of the marine aquarium screensaver fame did graphics for the legendary Defender of the Crown game, a few people at After Dark also made the original zoom peek gesture before that, and the incredible The Incredible Machine after.

It seems like a fascinating time that attracted people equally interested in tech as they were in its creative uses.

#easter eggs #graphics #history #real world #youtube

Basic stuff that’s worked reliably for decades — some things that heretofore had worked forever — are dangerously broken. If you’re running MacOS 26 Tahoe, open Journal and make a new dummy entry. Type something like “The quick brown fox.” Then double-click on the word “brown” and delete it. Now invoke Undo.

What you expect is for the word “brown” to reappear. What happens is ... the whole sentence disappears. Gone. Invoke Redo and you only get back to “The quick fox.” The word “brown” is just gone forever. It’s nowhere in the Undo stack. That’s just profoundly fucked up.

I couldn’t believe it, but I reproduced it myself just now on my phone (my backup Tahoe-running Mac is in a closet not responding to pings, I am now assuming out of embarrassment):

Gruber adds:

Apple’s developer message used to be that it was not just easy to develop apps for their platforms, but that it was easy to develop good idiomatically native apps. You got the correct complex behavior — for things like Undo/​Redo — out of the box. That’s still true for AppKit and UIKit, but it’s never been true for SwiftUI, and SwiftUI is now seven years old. That’s too long for any excuses to hold water.

I don’t want to automatically assume that this problem has existed for seven years (vs. being a more recent deterioration), and I don’t know exactly which native apps use SwiftUI, but either way, this reflects very poorly on Apple.

Software engineering typically has some categories of bugs and failures that result in immediate action – a night shift, a war room, “sevs,” and so on. Those are, in my experience, things like:

• the app crashes,
• the site doesn’t load,
• there is data loss.

Depending on what you work on, this list will also likely include security problems, regulatory considerations, privacy-leaking bugs, and so on. In a more mature organization, these are all well documented, but even in early startups there is some shared understanding that some bugs are bigger than life and they take immense priority over pretty much anything else.

At any company, a version of this list needs to exist for front-end and user-experience problems, and undo should be on top of that list. If you break undo, you drop what you’re doing to fix it.

#apple #process #undo

I’ll let you read the whole excellent analysis and Heer poking at the notion of “content over chrome” which feels dogmatically attractive, but needs deeper thinking which usually doesn’t follow.

The interesting thing to me about that last screenshot above is that the team didn’t want a toolbar separated from content – and yet, they walked themselves into recreating a de facto toolbar anyway, just uglier and with more problems. (Just like designers who use all-white for complex surfaces, and arrive at visual hierarchy challenges that now require more work.)

We’re a few hours away from WWDC. I don’t imagine we will see any direct response to the criticism of Liquid Glass as Apple doesn’t work that way, but it will be interesting to spot any indirect signs of reactions or course corrections.

#apple #nick heer

Through buttons right below its text field, the bar also lets you filter results: only show files, only show symbols, or only show symbols in current tabs. Here’s the thing, though: each one of these buttons has four distinct purposes. They’re not just for clicking.

The tabs are clickable as they normally are, but they’re also a treasure map (to tell you something is possible), a cheat sheet (to remind you how to do it again), and an onramp for faster keyboard navigation.

I’d add two more things to the celebration:

• I myself often forget onboarding is not just about the first run, but also about reinforcement. Here, this UI does a lot of reinforcing over time, helping you build the habit. Pressing the key highlights the tab. Clicking on the tab adds a key as if you pressed it, and so does using an advanced shortcut (e.g. ⌃⌘O instead of ⇧⌘O). Even slash as a symbol comes from path names, so you might naturally associate it with files.

• The search pop-up always has a nice contrasty appearance: dark when the background is light, or vice versa. Many modern interfaces go for white background for every UI element and surface. This seems like solely an aesthetic choice, but has more consequences when it comes to visibility of things, and even hierarchy. I am personally always excited when I see a duochrome app these days, because it feels like the team knows what they’re doing and isn’t just chasing visual trends. (Below is an example from Bear.)

#bear #coding #keyboard #onboarding #search

There are as many books about Steve Jobs as there were Quadra models, but they focus mostly on two phases:

• 1955–1985 – Steve Jobs befriending Wozniak, the early days of Apple, Lisa, and the Mac
• 1997–2011 – Steve Jobs’s “second act” at Apple, and the creation of the iMac, iPod, iPhone, and so on

Steve Jobs in Exile by Geoffrey Cain is a just-released, rare volume that focuses on the “in-between years” – starting with Steve Jobs founding NeXT and Pixar after his Apple ouster, and ending with him coming back to Apple under the absolutely strangest of circumstances. It’s a doubly interesting phase, both because we see Jobs maturing as a leader and actually learning from his many mistakes, and because the early technical NeXT decisions eventually became underpinnings for modern macOS and iOS.

I do not see this as a book of new immense insight, technical depth, or design details, but that doesn’t mean it doesn’t go beyond surface level. What I appreciated most was Cain not shying away from pointing at some of Steve Jobs’s mistakes: hiring wrong people he happened to like, almost driving the company to the ground through obstinance, inability to focus on things he considered uninteresting, and a profound dose of duplicity coming into the NeXT/​Apple merger.

Other things that stood out: focus on people around Jobs, spotlight on Jobs’s disappointing moral flexibility around working with government (or befriending Larry Ellison, for that matter), and a really fun pizza ordering story that serves as a prelude to the Starbucks call during the iPhone 2007 keynote.

Some learnings:

• Craft and taste alone are not enough; you can spend your talents and energy on things that don’t “matter” given some definition of the word. That could be okay if that’s a choice you make – “impact” is ill-defined and often overrated, anyway – but you need to approach it clear-eyed, which Jobs didn’t initially know how to do.
• Confidence, like everything, needs to be practiced, and focused, and influenced back by feedback and reactions. (Witness the negotiating acumen of a certain Jean-Louis Gassée!)
• It’s really hard to create a culture of hard and honest and deep conversations that’s also not a culture of abuse and toxicity.

The one thing I didn’t like about the book was that the few photos inside are only perfunctory; there’s a lot of chatter about a beautiful, symbolic NeXT lobby staircase, top-of-the-landline phones, and expensive chairs, but we never get to see them. Many of the photos are by Doug Menuez – which you can also see online – but the problem is that those photos are generally not that interesting.

That aside, it’s still a breezy and entertaining read that filled in some gaps and provoked new thoughts.

#apple #book #book review #culture #next #review

This is an 11-minute video from gruz talking about the fascinating world of South Korean bootleg Marios, such as Super Boy, Super Bros World, and Super Bio Man – existing solely because of Korea’s subpar copyright law of that era:

In short: The code was copyrighted, but the IP was not, so many companies rebuilt Mario for the dominant game console of the region, in the process stripping it of all of the original game’s actual craft – with “levels feeling assembled rather than built” and “getting the [visuals] right and missing almost everything underneath” – and as such become interesting as a reflection of the details that actually made Mario great.

However, as the time moves on, some of the bootleg games actually get better and better, and come into their own. It’s interesting to compare this to Nintendo’s own “clone” I mentioned before.

What I wouldn’t give for some oral history of what looks like an absolutely fascinating time and place for software.

#craft #details #games #history #super mario bros #youtube

I have small reservations here, as reusing a placeholder like this trips up my “this is cheap” alarm. But otherwise I like that this – just like keyboard shortcuts in menus or tooltips – ambiently teaches you the alternative representation of the emoji that you can use later to get to it faster.

(Another way of looking at it: This is a tooltip in a place where tooltips cannot exist.)

#search #touch #typography

In February, Nobert Heger did some analysis of precisely which pixels in Tahoe are intercepted by mouse when trying to resize a window. In April, Steve Ruiz, author of tldraw, did this more extensively for all the drawing apps like Canva, Figma, Illustrator, and so on:

When a user has one or more shapes selected, we display an interactive overlay that allows the user to transform their selection: a drag inside the box will translate the selection; a drag on the edges will resize along that axis; a drag from the corner will resize along both axes; and a drag from further out on the corners will rotate the selection.

Like many features in tldraw, my design here was meant to follow the conventions of design tools. This meant a broad survey of other applications, both new and old, reconciling differences between them, and picking a design that I felt best served the user while remaining conventional.

Remember the “if you put the Apple icon in reverse” joke from January? Last month, Jim Nielsen on his blog pulled on that thread and showed a few more examples:

Some 3rd-party apps continue to fight a good fight, even as Apple’s definition of what an icon should be — or what’s even possible — shrinks all around them.

One finding from this blog post for me was that things changed. In Big Sur, the squircle form factor was encouraged, but not enforced. Well, it is enforced now, when even shapes very similar to the squircle are now inside “the gray box of hell”:

These gray boxes are not some pedestal for icons. They’re the actual icons.

Anyway, I always appreciate efforts of people methodically documenting things so we can all learn and notice patterns and/or continue the work from the best possible starting point.

#iconography #interface design

First, some classic industrial molly guards from a museum in Germany:

This IBM electronic typewriter had a gorgeous perspex molly guard around the power button:

Other machines opted for “softer” quasi molly guards that still aimed to prevent you from pressing a button or switch by accident, but without having to get something out of the way first:

Even softer? This below is not a traditional molly guard, but the placement of “I’m writing to the SD card” red light was not accidental. Ejecting the card while the camera is writing to it might cause some damage, so the light was positioned right next to the card door and the card itself, making you more likely to spot it and wait:

This one is even more clever. You know how some old floppy drives have a handle that lowers the reading/​writing head so that the diskette can be used? That same handle also prevented you from pulling the disk once the head was lowered. It felt so natural, you might not have even realized it’s a molly guard doing its job:

On the other side, these following guards are more of a “you really shouldn’t do this” variety – much closer to a disabled state in graphical user interfaces:

Let’s jump into software.

This is a nice situational molly guard in Finder when you press ⌘O and have a lot of files selected:

iPhone’s “slide to unlock” no longer graces the home screen, with one exception – stopping the alarm:

There’s something about this treatment that doesn’t sit well with me. I’m not sure what it is: The text not feeling centered? The control being circular? The icon on the slider making it seem like it’s a stop button you can press?

Speaking of stuff I don’t love, you might recognize this molly guard from Chrome:

This one never felt pleasant to me. You might say “isn’t the point of the molly guard that it doesn’t feel pleasant”? But I think one needs to separate the intent and the mechanics. I don’t mind the intent here, but the styling is ugly, the message kind of confusing – you don’t really have to hold ⌘Q, just press it again – and you also don’t get any feedback during holding.

Contrast with this extremely skeuomorphic CD burning molly guard in early iTunes, suggested by one of the readers:

And lastly, something I didn’t expect to ever see. Per this issue (page 14) of an alumni magazine of University of Illinois, here’s the actual Molly with her father:

#definitions #interface design #real world

…first-person account of what I saw at the PC revolution from the perspective of joining Microsoft as a newly hired software design engineer fresh from graduate school working on developer tools, through my time as a program manager and ultimately leading Office, and then moving to Windows, and everything in between.

Sinofsky called the series Hardcore Software: Inside the Rise and Fall of the PC Revolution. It covers 1989–2012 and somewhere inside over 100 chapters, there is a fascinating six parter about the “ribbon” redesign of Office 2007.

• What is Software Bloat, Really?
• A Tour of “Ye Olde Museum Of Office Past”
• Competing Designs, Better Design
• Progress From Vision to Beta
• First Feedback and a Surprise
• Defying Conventional Wisdom to Finish Office

The first part covers the challenge of the team in 2007, taking stock of Office after almost 25 years of its evolution. (Number of toolbars in 1983: one. Number of toolbars in 2003: 31.) The second part shows great screenshots of all the Office versions from 1.0 until then, and the remaining four cover the Ribbon redesign process.

Regardless of how you feel about Microsoft Office today, and whether you consider the Ribbon interface a success, it’s a perfect weekend read as it covers universal challenges of software complexity and change management.

It’s such a potent series I’m sure we’ll come back to it. It covers a lot, including – in the first part – wrestling with a definition of bloat or complexity, which in the context of Office was less about the number of functions available, and more about mastery:

[…] In practice, bloat comes from the fact […] that Office does so many things that customers just assume the product can do whatever they need it to do. Despite that fact, customers have no idea how to make the product do what they need. This feeling of helplessness that leads to frustration. […]

Bloat is owning a product that you cannot master.

This below is a great observation about the perils of an idea of a “simple mode,” which Sinofsky argues is always a leaky abstraction:

We tried reducing bloat by hiding features […], but that only added to the mystery of the product. Mac, Windows, and Office all went through periods of “simple means fewer” and tried mechanisms such as short menus, simple mode, or adaptive toolbars. But that frustrated or confused people. No one really wanted to use a simple mode and there was always one command missing that was needed, so simple mode became a complicated way to do that one thing that made someone’s work unique.

It was great to see this argument for a broad definition of a bug, as it slides exactly into my post from a while back:

Ages ago in ancient Microsoft history there was a debate on the original apps team about what it means for something to be a bug. Is it a crash? Is it data loss? Is it a typo in an error message and so on? Out of that was created a notion of bug severity, a measure for how serious a bug might be from losing all data all the way to simple cosmetic issues. However, when it came to talking about bugs with product support or ultimately customers the definition of a bug was very simple “a bug is any time the software does not do what a customer expects”. This definition created a discipline of documenting everything reported about the product and always making sure every issue was looked at, even if a code change did not result. The key lesson was how helpful an expansive definition was.

There are also observations and research about how users “debug” the product to make it achieve something they know is possible, but they don’t know how:

We called the futzing document debugging, and it created a frustration that the product was powerful yet overwhelming. People believed a specific result was achievable but getting from point A to B seemed impossible or unlearnable.

And some about the challenges of figuring out what features people use:

[…] Most people didn’t know or care what buttons they clicked on or menus they chose so long as it was working for them—and that meant when asked, “Did you use X?” most people couldn’t recall. To a skeptical press or IT manager (and they all were) that meant unused features.

I should stop quoting and let you read in peace. But, check this out. Lisa wasn’t the only one having linguistic fun:

Early keyboard shortcuts were simple, like using Ins(ert) key to copy text from the scrap (clipboard).

Scrap!?

#case study #complexity #definitions #flow #history #software evolution

This is not italics. This is not even oblique. This is a side effect of how those displays work. Instead of a whole rectangle of pixels being changed at once, the display is updated line by line, starting from the top one. As it’s moving towards the bottom, the internal horizontal position might have already advanced, the subsequent lines will be drawn slightly to the left, and it all leads to a slanted appearance. (This is in effect the same problem as rolling shutter in photography.)

The interesting thing is that it could’ve gone the other way. Twice. In English or German, we treat scrolling left to be natural, and we consider only one direction of italic slant appropriate. The first has to do with the direction of reading. I believe the second is, like many things in typography, customary; there’s nothing inherently better than right-leaning letters, except we’re used to them since those are the only ones we ever see.

But, the person putting it all together could’ve just as well done it the other way: scrolling to the right, or slanting to the left (by updating the display bottom to top – not as unusual as you might think!). Were those intentional choices, or was it a default? I’m not sure, but it points to the value of knowing this stuff, or creating a culture where this stuff is treasured. Often, more craft will require more work. Sometimes, however, you will get it for free – but only if you choose the right fork in the road.

While we’re here, how about a few other examples of delightful moments in typography where I did not expect them? These, I believe, will be all intentional. But whether you consider them craft, or even good, I don’t know.

Here are some surprising small caps:

Here’s a cute depiction of a train carriage, somewhat hampered by the limitations of a similar workhorse 5×7 pixel font display:

But here’s something even better. This icon of a stadium cleverly leaned into the same limitations. It’s so delightful. These are, I believe, four characters side by side:

Here, someone added nice decoration to fill out the space:

Here, someone removed all the line height to create a fascinating vertical ligature. This is Gorton and the letters are carved into the plastic, so this required some effort!

Speaking of obliques, this NOT is too thick, and slightly too large, but you have to appreciate someone actually slanting the text rather than underlining it, or decorating in a simpler way:

Even if you underline, you can go a little… well, below and beyond:

Or, here, with maybe the most impressive, three-dimensional underline I’ve ever seen:

This I spotted on an old typesetting machine, and I would like to believe this is an intentional easter egg:

This was on a computer keyboard. You don’t expect hyphenation in this context…

…and you definitely don’t expect an old-fashioned contraction:

#above and beyond #craft #details #real world #typography

I picked a few I particularly liked for this post. These aren’t just explaining things useful to know as a designer, but also themselves contain inspiring/​unique interactive moments worth knowing about:

1.
Curves and Surfaces, Bartosz Ciechanowski

• Every example has draggable points, but it also pops up an undo button once you start messing around, so you can feel safe experimenting:

• Specific ideas and definitions are color coded between text and the interactive pieces:

• For complex three-dimensional shapes, you can simply rotate them around to orient yourself better:

• I liked this trick of claiming something is impossible, but leaving a door open to try it anyway – I bet it will get some people more engaged, in the “but I’m sure I can lick my elbow” sense:

2.
ASCII Characters Are Not Pixels, Alex Harri

• I think the traditional “drag a divider to swap between two representations” interaction is actually kind of bad, but this essay subverts it by allowing you to toggle between representation A, representation B, or both side by side:

• A button to copy code to clipboard is always appreciated:

• I don’t know, I liked these minimalistic sliders:

3.
Tab Roving, Niklas Gadermann

• It’s hard to know what to do with complex interactivity, for example a specific sequence of keystrokes… let alone the fact that mobile phones don’t have easily accessible arrow or Tab keys. Here, a brilliant solution: not just on-screen soft keys, but also automatic playback!

Also, kudos to all three creators for their explainers working equally well on phones as they do on desktop computers.

#above and beyond #interface design #undo #web

When you’re around to-do items, you can press ⌘. (period) to toggle any task complete or incomplete. It’s actually a really fun shortcut in practice:

But when you have a larger selection with a mixed state (some checkmarks are on, others off), this is what happens:

This feels like an obvious thing to implement, and this is also where the code itself wants to go when left alone.

But this is not great. The rule is: When you have a mixed state, changing it should collapse (or: normalize) the entire selection to one state or the other, rather than perform individual inversion. Try ⌘B in your text editor on partially bolded text, and you can see that collapse in action:

It feels strange to recommend that, particularly as it seems like it loses data. So, what gives?

The first argument is “do not make the user jump through hoops” or maybe “respect a large selection.” If, as a user, I want to actually make sure all my tasks are done, the shortcut not being idempotent means that I now have to go through tasks one by one, and that’s a lot of work – especially since we’re talking about text selection, which is famously unpleasant.

The second reason is that even the UI layer has an opinion here. In the above bolding example, Pages collapsing the selection to bold when you press the B toggle, makes the toggle UI behave exactly as it normally would with a simple selection:

Elsewhere, in Figma, typing a number on top of a “mixed” state changes all the properties of relevant objects to that number:

Imagine how awful it would feel mechanically in both the above examples if your action would still leave the text in the “mixed” state. It would simply appear like the UI broke, since the change didn’t fully “stick” – kind of like those tiny hated moments when you close the door, but it doesn’t latch on and reopens on its own, or when you engage the turn signal stalk, but it refuses to stay put and snaps right back.

There is also one last reason. It’s the simplest one that I sometimes have to remind myself to put in my head before I jump too deep into the mechanics, or details, or technical nuances. Let’s say the toggles invert individually on a large selection. Who would ever benefit from it behaving this way?

#bear #bugs #details #flow #keyboard

You can tell that this was not the work of an amateur. The garbled text is done with a lot of care and knowledge. You can see a lot of rational decisions about why it looks the way it does in there. They are making very careful additions, such as adding letters… the “-and”s and the “-ng”s… The “y” got stuck in because that’s an English letter. […] I think the fact that it is garbled Latin text, and that it has those other letters in a fairly Latin-based alphabet amount of frequency, speaks to that it was done very, very carefully.

Just a fun watch all around.

#typography #youtube

I don’t think it’s a good announcement, but its flaws are pretty universal, so I want to put words to these flaws. This will extend to a lot of other writing about design, not even necessary even just about typography.

Here’s my advice that I believe would make announcements like this better:

• Write like a human being would. This is famously hard, and takes practice. Here, we see stuff like “unapologetically digital,” “a functional tool within a broader typographical system,” “the result feels both nostalgic and contemporary,” and “constraints weren’t a limitation, they were the design tool.” No one talks like this. I think people believe font releases have to use these kinds of words and phrases, as a way to bring legitimacy to the project. I do not subscribe to that way of thinking. I think it leads to writing that’s optimized only for admiration, which is not as much fun for anyone.
• Show a specific example of a problem you solved. This page hints at some things – “They don’t scale properly across viewports, their metrics conflict with existing typography, or they’re purely decorative.” – but that feels altogether too vague to be useful or even interesting. These are actually fascinating and hard challenges, yet I know as much at the bottom of the page as I did at the top.
• Show details you are proud of. Zoom in literally or figuratively. “Each glyph was manually refined to avoid visual noise, uneven weight distribution, and awkward diagonals.” I would love to see a few examples.
• Show work in progress! Show stuff you discarded. This will be hard, but why not? It’s good practice and I believe this, more than anything else, will have people appreciate what you did. Plus, everybody loves a blooper reel.
• Related: talk about struggle. But don’t just motion in the direction of challenges, or performatively announce that this was the hardest project of your life. Actually talk about something that was hard, and why. Be vulnerable. Be honest. People didn’t care that Rocky lost in the first movie, because people cared about Rocky.
• Talk about your inspiration or history. What we all do here is part of something much bigger. Why a pixel font to begin with? Why is this interesting to you? Is that because Vercel is filled with nerds, or because you got bored with bold and italic, or because it just seems visually interesting in a new way?
• Let me type! Immediately and on every relevant page. I don’t think any modern font announcement/​tester can exist without this. This is the easiest way to getting to know the font and explore specific things that matter to you. (To do this here, you have to go to the font page, switch to Geist Pixel at the top, and then scroll all the way to the bottom. This feels entirely too far away.)
• Show, don’t tell, generally. The Geist Pixel announcement feels rife for an avalanche of “show,” but has so little. I mentioned above wishing to see examples of manual refinements. There is a visual for “seamless mixing,” but it’s really a marketing photo, not a real-use example – it visualizes what, but you want to visualize what and why at the same time. I would love to see the spread of variants, specific examples of how the font is not “breaking in production” and “scaling properly across viewports.” I don’t know what is a “semi-mono approach” and I would like to learn.
• Motion is okay, but it has zero nutritional value. If you have limited resources, don’t spend it on motion. Anything interactive is better. (But again, the best interactive thing is letting you type.)
• The “Already shaping what’s next” is a narratively unsatisfying section, as it promises stuff that you cannot see yet. Either show those, or skip the tease altogether.

I know the elephant in the room here is “how big companies do things.” A lot of redesign announcements and font unveils exist chiefly to make the execs who championed them happy, and perhaps as fodder for future promotion – I bet the whole “Already shaping what’s next” section isn’t really written for external audience – and they get chewed by the big PR machine that often files away whatever personality and quirkiness might have been there. Your job is to fight that machine! But I acknowledge that it might be hard.

However, I’ve also seen all this seeping into personal font announcements, which is unfortunate. (I don’t want to link to specific examples, since that’d be punching down.)

Also, this is not just about the joy of reading or some general notion of “craft” – although they are important, too. This is also purely informational. I feel I haven’t learned enough from the Geist Pixel announcement for the amount of time I spent with it. I don’t understand “multiple variants for different densities and use cases” or “semi-mono approach” or what stylistic sets are included. (My general goal is to write in a way that people can learn something new from any design announcement, even if they don’t have any prior context, and if they never actually use the font.)

It‘s a shame, because the work itself seems thoughtful and excellent, deserves a better intro, and could help others interested in typography as a jumping off point, particularly because this feels like a typeface off the beaten path.

Just to round up this post, some recent counterexamples:

• Fran Sans announcement post by Emily Sneddon (complements the font page) – personal, distinctive, talks about the process, shows interesting artifacts.
• I feel that every small essay from David Jonathan Ross’s Font Of The Month Club teaches me something new – pick a font you like on that page, then click Notes next to it.
• Departure Mono font page by Helena Zhang doesn’t use a lot of words, but still says a lot.
• Shantell Sans process post by Shantell Martin (complements the font page) – already talked about it before.

#craft #david jonathan ross #storytelling #typography

It’s not just something traditionally delightful, a cute big icon moving smoothly. I also think it’s very helpful. Travelling in a new place can be stressful and station names look similar; it’s nice to orient yourself without having to go back to the map, and if the indicator only always pointed to a station, it would introduce off-by-one errors (“was it the last station, or is it the next one”)?

Plus, I think any design features that help your brain transition between abstract (list) and physical (map) views are very welcome.

My suggestion would be to consider making it pulsating and/or blue to tie it better together with the current GPS position, which has had the same visual signature since 2007.

#details #google

On that note, this is an interesting, meandering essay by Ernie Smith at Tedium, reflecting on the enshittification of Google and the two-year anniversary of &udm=14, a simple site that removes AI from Google’s search results:

I spent two hours of my life building a thing. Google has probably spent thousands, if not millions, of collective employee hours building all their AI innovations. And for a surprisingly large number of people, the two-hour workaround I built wins out. There’s a lesson in that.

Somewhere in the middle, the essay transitions into talking about the value of good tools and single-serving websites:

Our world needs more, smaller tools that speak the same language, where everyone makes a little money, but nobody dominates the industry. In the 1980s, the software industry was kind of like this. Oh, sure, Microsoft and Apple were still out front, sucking up all the oxygen. But there were lots of little companies, selling software on disks. The bigger ones put them in boxes in stores. The smaller ones realized that they could just ship software through the mail and let the software spread naturally among user communities.

Shareware didn’t really survive the internet era—but, at least for a while, its spirit did. More recently, that spirit has taken a backseat to the larger companies that realize, if they’re big enough, they can shape how we interact with our world.

In 1991, if you wanted to start a software company, you had to hope that your product was good enough that word of mouth and a P.O. Box could push it around. That’s exactly what happened when Tim Sweeney released ZZT. It became the starting point for Epic Games, the kind of company that today is big enough that, thanks to its Unreal Engine and the success of Fortnite, it can dictate terms to much of the gaming industry.

If you ask me, I want a world where more software is like ZZT than it is like Fortnite, because more people have a chance to succeed in the former environment.

Previously in this general category, we covered Keyhole and (Gmail) Simplify. If you have a favourite small tool or a simple tool-like website, I’d love to hear from you!

#ai #enshittification #google #toolmaking

Resetting to default state happens on your phone, too. I’ve been thinking about it this past week and found a few examples.

The Google Search app comes back how you left it, except if you abandon it for longer than 45 minutes. If that‘s the case, it returns to a pristine, deterministic homepage. (You can always come back to the previous session, though.)

When you pause a podcast or music, at least in my setup, it will be on the home screen for 5 subsequent minutes – you can then resume it by simply tapping on your AirPods. But leave it dormant for longer than that, and the home screen forgets about it and resuming is impossible:

My favourite: if you swipe through the apps back and forth on the iPhone in a touch UI equivalent of command-tabbing, there needs to be a specific moment where the app you switch to becomes the “current” app. On desktop, it’s easy – you can reset the state at the next invocation of ⌘⇥. But there is no such obvious moment on mobile.

When there is no obvious moment, timeout can be a great answer. And so it is here, and it seems to be set at about 5–6 seconds:

I understand the Google Search and the app switching examples. But I am not sure I know why a podcast resets so soon. A challenge when talking about this without seeing the code – as it is with many things on Unsung – is that I don’t know if this is carelessness, a technical limitation, a design consideration I’m unaware of, or just something that’s intentional, but I happen to disagree with. Even testing this has been hard if the delays are longer than seconds.

The extra challenge for Google Search, as it is for many other apps, is that they also reset when iOS itself purges it to make room for other apps. This isn’t great, and can be avoided if you care; we talked before about Bear and how it remembers its precise state even after the system evicts it from its memory.

Whether you want your app to remember you forever, or whether you want some deliberate forgetfulness, it could be important to take ownership of that. My go-to example of a miss in this category is Google Maps, which completely throws away its current trip-in-progress status whenever the iOS kicks it to the metaphorical curb – and returning to that status later again as a user is a really complicated sequence of steps including rewinding back the time, on top of travel already being stressful.

By the way, I can think of fewer examples on the desktop, but that makes sense given desktop apps are less tactical, and given that ⌘Q exists.

But Spotlight does freshen itself up after about 7 or 8 minutes…

…and Raycast actually offers an option to set its short-term memory from between 0 seconds and three minutes, with the default being 90 seconds:

#details #google #interface design #raycast

I linked to his work once before, and today I wanted to share a recent essay about the disaster that was the 1999’s game Ultima IX.

I have never played any Ultima games, but this was a gripping read.

[…] Richard Garriott, the motivating force behind Ultima from first to last, has done his level best to write the aforementioned last out of history entirely. Ultima IX is literally never mentioned at all in his autobiography.

But, much though I may be tempted to, I can’t similarly sweep under the rug the eminently unsatisfactory denouement to the Ultima series. I have to tell you how this unfortunate last gasp fits into the broader picture of the series’s life and times, and do what I can to explain to you how it turned out so darn awful.

In some sense software projects always fail for one of the few obvious reasons, and it’s just details that change. Here, the details are fascinating. The Ultima series started in the very early 1980s as a series of small games made by one person, and ended ignominiously as an almost-AAA title rushed to market that no longer wanted it:

They met the deadline — what other choice did they have? — but the playable game eluded them.

It’s not just the deadline. There’s also a studio past its prime, a fascinating but deeply flawed leader, the market forces and trends, and perhaps even some enshittification long before the word’s invention.

It is also a story of the first two decades of the videogame industry itself. It happened so long ago that it almost feels like a fairytale itself, although one with a sad ending.

Maher also lists some learnings that are universal enough to apply to a lot of other projects:

• No game can be all things to all people.
• Development teams need a clear leader with a clear vision.
• Checking off a list of bullet points sent down from marketing does not a good game make.
• When the design goals do change radically, it’s often better to throw everything out and start over from scratch than to keep retro-fitting bits and pieces onto the Frankenstein’s monster.
• It’s better to release a good game late than a bad game on time.

And, in case you want more, here are handy links to all of Maher’s Ultima essays: I (3 parts!), II (3 parts), III, IV, Multima, V, VI, Worlds, Underworld (2 parts), VII, and VIII. I haven’t personally read them in order, and I’m better for it.

#enshittification #games #software evolution

On a Mac, the shortcuts are iconographic. Command is ⌘. Option is ⌥. Shift is ⇧. Control is ⌃. Fn is 🌐. There are also icons for all the other non-printing keys, from the relatively well-known Tab (⇥), through the perennially confusable End and PgDn (⤓ and ⇟), to the absolutely cryptic Esc (⎋).

On Windows, the keyboard legends are mostly text. PC lost the icon battle in the early 1980s – IBM had them on their 1970s computers, worldwide, but apparently American users of the early IBM PC hated them – and the names are spelled out (Shift and Enter and Home), or close to it (Ctrl, Esc, PgDn, Prt Sc).

Why did Apple go this way? My speculation is the revered Braun and generally hi-fi hardware: a lot of stuff sold in Europe defaults to iconography in part because that makes exporting easier. Icons are also more compact – putting ⇧⌘C in a menu or a tooltip takes up a lot less space than Shift+Ctrl+C – and more beautiful when done well. Here’s Figma’s right click menu on Mac and Windows:

But there are also challenges, as icons are more cryptic and confusing. “Command” tells you something about itself out of the box, but “⌘” is completely abstract. (Arguably, only arrow keys and symbols like ⇥ and ↵ explain themselves visually.) The attendant issue is that icons are hard to talk about if you don’t know their names, hence tons of jargon like “propeller,” “splat,” or “beanie” for ⌘, for example.

It’s a hard situation. Here is one of Mac’s own menus being thoroughly inconsistent, and an example of CleanShot using both the icon and the label to be sure:

“Why not both” seems to be the best way in places you can afford it. Apple started doing that on the keyboards too, but it took them decades to get there for modifier keys alone. Even on the 2026 computers, many other keys like Esc and Tab are still single-legended:

With all that in mind, I want to show you what I saw the other day in Google Docs, on my Mac:

This is one of those cryptic things that I would love to understand the thinking behind. Because, on the surface, this breaks so many rules:

• A strange hybrid of Mac and Windows styling: some modifier keys are spelled out, and the others are iconographic. (It’s very strange to see ⌘ conjoined with others using a plus!)
• Complex and generally uncommon dual key shortcuts – to collapse the sidebar, you really need to press ⌃⌘A and then press ⌃⌘H, in sequence.
• Three-modifier-shortcuts are in general really unpleasant and Google Docs does not seem complicated enough to warrant them.
• (You can’t see that, but they’re also unreliable! ⌃⌘A ⌃⌘H doesn’t always work and seems to depend on where the focus is.)

There is also a visual argument that cannot be ignored. We’ve been there once before; if in your menu keyboard shortcuts start overwhelming the commands themselves, you are probably doing something wrong.

The only explanation for this I can think of off the top of my head is this: these were invented somewhere else (Word?) and inherited by Docs to respect motor memory of the users transition from the older app. That still doesn’t cover the presentation, plus there is a way for Docs to redesign the shortcuts to be better for people who are starting anew.

Ultimately, I think all of this also breaks a cardinal rule: it makes keyboard operation feel more scary and intimidating than it needs to be. Shortcuts are scary enough on their own, and they don’t need any help in this area.

#google #iconography #keyboard #mac os

I recently stumbled upon this 20-minute YouTube video by iSongs of someone recreating Eminem’s “Lose Yourself” in GarageBand on their iPhone:

Like the previous video, I believe this is so tight as it was previously rehearsed/​prepared, which makes for an interesting watch if you even just check out a fragment of the video.

I can’t speak for the verisimilitude/​quality of the composition, but it was fascinating to witness because The. UI. Just. Kept. Coming. I had no idea Garage Band is so fully-featured on the iPhone, and that there is so much going on!

Maybe my fascination is this: it’s amazing that “power users” come in various shapes and forms. Would I recommend using the iPhone to do this? Not really. Is it cool that this is possible, for people who might not have access to other platforms? Yeah.

(The channel has a lot more different songs if this one is not to your liking.)

#touch #youtube

But this essay on a new No One’s Happy blog was really interesting to read, and feels different in a few ways.

First, it examines what happens as AI slop spreads in the context that is less discussed – in a workplace:

This is a new form of slop, and it is more expensive than the public kind, because the people producing it are being paid a salary to do so. […]

The cost of producing a document has fallen to nearly zero; the cost of reading one has not, and is in fact rising, because the reader must now sift the synthetic context for whatever the document was originally about.

A lot in the essay feels pertinent to Unsung as real craft is not feelings or fluffiness. Real craft is deep expertise:

Generative AI can produce work that looks expert without being expert, and the failure arrives in two shapes. The first is when novices in a field are able to produce work that resembles what their seniors produce, faster or more advanced than their judgment. The second is when people generate artifacts in disciplines they were never trained in. The two failures look similar from a distance and are not the same. Research has mostly measured the first. The second is what it is missing, and in my experience it is the riskier of the two.

The term for this new challenge is, apparently, “output-competence decoupling.”

Other parts of the essay come back to a topic – toxic velocity – we covered before:

The current generation of agentic systems is built around the premise that the human is the bottleneck — that the loop runs faster and cleaner without the awkward delay of someone reading what is about to happen and deciding whether it should. This is, in a great many cases, exactly backwards. The human in the loop is not a vestige of an earlier era; the human is the only part of the loop with skin in the game. Removing the H from HITL [Human In The Loop – eds. note] is not an efficiency. It is the abandonment of the only mechanism the system has for catching itself.

And one last thing that differentiates this essay from many others is the last “what to do about it” section.

#ai #craft

I’m working on a column about the tech annoyances that drive us crazy, and I want it to be as universal as possible, so tell me yours!

E.g. scanning a QR code to read a menu, never receiving the one-time passcode they supposedly texted you, “verify you’re human” by IDing tiny motorcycles, etc.

There are already many responses. I am drafting behind Phillips before he even writes his essay, because I like occasionally checking in with people this way. Not just for commiserating; perhaps scanning the answers will also give you some inspiration, or validation, or quotes for something you can push to make better, wherever you are.

Some patterns I noticed:

• A lot of logging in woes: password requirements, bouncing people from apps to web to log in, login flows forgetting context, “I trusted this device” settings you cannot trust.
• “Local news websites that crash under the weight of all their pop-up ads and auto-play videos.” This post had a great take:

The way super sketchy bootleg websites used to look (written in questionable English, 2/3 of the window overtaken by ads, constant popups and redirects, incorrect information more often than not) is just how all websites are now.

• Hatred of QR codes, or perhaps what they represent: needing to install an app, removing people out of the equation, introducing phones where they weren’t needed before.
• Surprisingly little AI. Is that because of the audience or the way the question was phrased?

Also, this little beauty:

My toaster says to unplug when not in use. It also has a digital clock that resets when I unplug it.

#enshittification #software evolution

It’s a method filled with nuance, as this 11-minute video describes really well. This TV Tropes page lists a lot of examples from movies you might recognize, and another video by Rob Ellis has a lot of practical advice.

Now that you know it, you might spot it in movies that use it poorly: the ones that darken everything too much, the ones where too bright of a sky gives it away, or the ones where the shadows appear lunatic in the wrong sense of the word.

In UX design, you can day-for-night your dark mode as well – long before proper dark mode was a gleam in someone’s bloodshot eye, operating systems allowed you to invert their screens – but the limitations of that approach are apparent very quickly:

Sure, black becomes white, white becomes black, and grays swap places. But in real life, shadows do not get brighter at night, and photos do not behave that way, either.

The “proper” answer is not to do anything automatically and to go all out with a perfectly hand-crafted dark mode that’s an equal partner to light mode: a distinct set of semantic colors, a new strategy for shadows and layering, and a second set of visual assets like icons and images.

Here’s a comparison of naïve inverting and a proper dark mode:

A lot of apps do that for colors and shadows, some even providing multiple dark mode flavors…

…but visual assets is where things get tricky. Yeah, vector graphics can use the same swappable color variables as CSS text and elements, although in practice it is quite a bit of work and from my experience SVG doesn’t make it very easy, either (here’s an example from my essay):

But when it comes to bitmaps, they are usually left alone. Overtime is still overtime, and producing each bitmap twice is a lot of effort.

Since swappable variables don’t exist in this context, the only automatic approach method left is inverting, but a) inverting an already- dark image can make things lighter,and b) inverting things like photos makes them look creepy and mixes up all the colors:

What explains the last part? This has to do with the fact that inversion happens in the RGB color space. R becomes 1–R, and the same for G and B.

Everyone who’s into gradients knows of a similar challenge that results in the gray dead zone effect. This is fixable if you convince a gradient to traverse through a different space instead, or coax it through the RGB space on a more… bespoke path (this is e.g. what Figma gradient plugins do).

Could we invert in HSL or OKLAB color space, then? Yes, we could. They both look similar – this is HSL:

You can see how the photos get inverted now, but the colors remain the same! Still a curiosity, perhaps, but the bottom of the above screen shows this technique feels really interesting for diagrams, screenshots, and things of similar nature. Here’s another bitmap that looks pretty great inverted this way:

Unfortunately, while there are techniques and plugins to do gradients in non-RGB color spaces, I am not seeing a lot of options for inversion customization anywhere. Neither the graphics apps I use, nor CSS offer anything here.

But there’s a trick: do a regular invert and then rotate the hue halfway through. Through the magic of math, this is the same as inverting just L in the HSL space, which means the colors are preserved. This is actually achievable in graphic programs…

…and, more importantly, available in CSS as a filter: instead of invert(1), use hue-rotate(180deg) invert(1).

So, if you have dark-on-light diagrams, bitmapped text, illustrations, or other similar things – or even vector graphics you cannot throw dark mode variables at – this day-for-night trick that can get you places very cheaply. (And for other bright bitmaps, just reduce the brightness by 25%.)

It’s the same as with Hollywood trickery: remember to add a bit more nuance in the right place, and you get something that feels bespoke for the price of only light – please excuse the pun – manufacture.

#dark mode #graphics

I won’t spoil the glitch because it’s a fascinating combination of a corner case, a race condition, and even a dose of dumb luck. Its finding unveils almost like a scientific discovery over many years – first a theoretical possibility, then a first sighting done in a modified emulator, then confirmation made by a machine via a tool-assisted speedrun, and eventually actual performance by someone by hand. And a lot of this achieved by relative newcomers to the community, too.

There is certain poetry here in having to go slow to go fast – you’ll see what I mean.

#bugs #games #speedrunning #youtube

But when you type into the search field, the search cuts across all fonts again, ignoring the applied filter. The search effectively lives outside the filter.

In Keyboard Maestro, when adding an action, you can click in the nav to filter down to a specific category. And when you search, the current filter remains active, so you search inside the filter.

Which one is better?

I don’t have a universal rule here, because it will depend both on the UI treatment, and the specific filters and searches people do.

But I think here, my recommendation for Keyboard Maestro here would be to do the same thing as Figma does. I designed that flow in Figma, so I might be biased, but my reasons are:

• There aren’t really a lot of options in each category, so you don’t benefit a lot from double filtering.
• But the most important thing: For both Figma and Keyboard Maestro, the text field might smell like a text filter and as such expected to be multiplexed with the category filter, but I think this field is actually something else: It’s quick keyboard access, like ⌘F or Spotlight or Raycast. And if you think about it this way, it’s important for it to be deterministic – I can always type “Output Sans,” no matter what state am I in, and get to the font.

On that last note, I find it’s good to look around what you’ve designed once in a while and consider not what the UI set out to be, but what it became – there might be more examples of that around you.

#flow #interface design

Analog Mono fixes that problem:

Elsewhere, Kumiko Yoshida made Coral Pixels (also on Google Fonts), a color font that comes with the 1990s and 2000s colorful fringing baked in. The fringing was once an artifact of subpixel rendering, but now it is meant to evoke nostalgia or just as an interesting visual element in and of itself. (Perhaps adjacent to chromatic aberration?)

Lastly, here’s Two Slice by Joseph Fatula – a font that’s only 2 pixels tall, “and somewhat readable.”

Of course, these are all vector fonts – e.g. ready to be installed on a modern operating system – pretending to be pixel fonts. That’s maybe a separate post altogether, but it leads us to the last font, Geist Pixel from Vercel:

The copy introducing the font is a little pretentious/​spicy, but it touches upon something important:

Geist Pixel isn’t a novelty font. It’s a system extension. [… It] was designed with real usage in mind, not as a visual gimmick, but as a functional tool within a broader typographic system. […] This matters because pixel fonts often break in production. They don’t scale properly across viewports, their metrics conflict with existing typography, or they’re purely decorative. Geist Pixel was built to solve these problems, maintaining the visual texture teams want while preserving the typographic rigor products require.

There are definitely fonts whose Achilles’ heel is not the letterforms, but the invisible hard work put into everything that surrounds them: the kerning, the metadata, the extra glyphs, the vertical metrics. It seems that the team being Geist Pixel is proud of especially that last part.

#typography

To improve it, I would add some sort of small celebratory “completed!” state, and auto-hide it afterwards; right now, it seems that it hides on a delay, likely regardless of what happens.

(Testing onboarding is hard because once it’s invoked it disappears forever. If you are worried about onboarding experiences in a place you work, please insist on easy toggles to bring it back for testing. And no, one-size-fits-all “reset onboarding” is too crude; ideally you can reset each specific one easily through a simple UI.)

Thank you to Ezra Spier for the tip.

#google #onboarding

“We’re having a problem sending email out of the department.”

“What’s the problem?” I asked.

“We can’t send mail more than 500 miles,” the chairman explained.

I choked on my latte. “Come again?”

“We can’t send mail farther than 500 miles from here,” he repeated. “A little bit more, actually. Call it 520 miles. But no farther.”

It would be easy to assume this is a classic case of pebkac, “problem exists between keyboard and chair,” the derisive term used (supposedly!) by support people, describing naïve public who had a tenuous grasp of technological reality. But the story goes to an unexpected place.

This might be the most widely-shared computer bug story of all time I’ve seen – I just saw a comment from 2008 calling it “oldie but a goodie,“ and it even has an FAQ page that’s actually a really great read. There’s quite a bit of chatter inside about something important to me: the balance between the needs of good storytelling and going deep into technical details:

In the story, I make it sound like it took all of ten minutes from being made aware of the 500-mile email limit and determining a 3 ms light-speed issue. In fact, this took several hours, and quite a bit of detective work. The point is, eventually I came up with that figure, ran units, and gagged on my latte.

You can sense author’s frustration with every nerd trying to “gotcha” him instead of just enjoying the story. Even a younger internet wasn’t without faults.

#bug deep dives #bugs #change management #storytelling #web

The video helped me understand the difference between tunes purely synthesized from soundchips, those sequenced with samples (e.g. MIDI or sound trackers), and those that are completely “streamed” (e.g. MP3). It’s stuff in between that’s the most interesting – it always is – with really surprising sources of samples (and, surprising samples!) needed to “perform” sequenced music.

The video itself is frenetically edited, and the opposite of “dry” (which I mean as a compliment).

#games #sound design #youtube

• They help me get unstuck. If you go far enough, you will find out that even the most ossified conventions that are older than you haven’t always been this way.
• They put me in the mood of “what of the things that feel normal today that deserve to feel dated, obsolete, or awkward?”

I’ve been emulating the Apple Lisa recently, and I was struck by how many of its UI strings were slightly or wholly different than what we’re used to.

It makes sense. Lisa came out in 1983 as Mac’s predecessor and really the first GUI that is directly linked to what we’re using today. Even though it borrowed things from work done at Xerox, tons of conventions were not established yet.

So, I thought it would be fun to actually take a closer look.

For context, Lisa was as slow as it was expensive, and generally considered a failure. It was basically abandoned by 1985. Not much third-party software has ever been written, but Lisa shipped with 7 impressive office apps with fantastic names: LisaWrite, LisaCalc, LisaDraw, LisaGraph, LisaList, LisaProject, and LisaTerminal.

The screenshots below come from an emulator and from manuals (this links to the 1984 version, but each manual also includes a link to the original 1983 edition). The emulator is pretty harrowing; please upvote the idea of Lisa in Infinite Mac if you would want to see it!

As Lisa powers up, we see the appearance of the “wait” dialog box. We’ll encounter more symbols like this triangle, inspired by traditional flowcharts.

Let’s start with menus, as these really were the treasure map to the whole system.

The Desk menu is basically the equivalent of the dock today.

The File menu has Print appended to it, indicating how important printing was still then; a truly “paperless office” won’t really be possible for two more decades (and seemingly still hasn’t fully arrived).

There is no Window menu yet, so the menu also contains some of that burgeoning functionality. Set Aside is what we would call Minimize today. Save & Continue is basically a contemporary Save, and Save & Put Away a hypothetical Save & Close. Revert to Previous Version is the same as today’s Revert. By the way, in the Revert dialog I appreciated the nice gesture of telling the user how much time passed since the last save, and a warning about undo (we’ll get back to this):

Print Current Selection would today be just Print Selection. Print As Is is basically Print… but skipping the setup dialog with number of copies, etc. It was added later in Lisa’s life, and today, we’d probably call it Print Again?

If you’re noticing a pattern already, it is more wordiness compared to what we see these days. It makes sense. Our growing familiarity with these concepts is what will allow these strings to become tighter over time.

This is that Print… dialog, by the way, with beautiful “while you wait” and “while you work” verbiage (although usually I do not condone strings getting so close to each other). The manual explains: “You can have the Lisa use most of its attention to print your document while you wait. A document will print more quickly if you choose While You Wait, but you won’t be able to use the Lisa for any other tasks.”

The other strings feel less typical. Format For Printer… is Page Setup, but with a lot of quirks. Printers were not usually yet WYSIWYG, able to mirror stuff exactly on the screen. They often came with their own fonts, so some matching was necessary:

The manual had an entire section called “When Settings Don’t Match a Printer,” and there were I imagine god knows how many error cases that had to be covered, including:

And Monitor The Printer… is today’s Print Center: a way to see the real-time printing status. Note a lot of writing here elaborates further on the “while you wait/​while you work” dichotomy:

Monitor The Printer was important, by the way, since the manual warned you your printer might occasionally become haunted:

But, let’s go back to the File/​Print menu. I actually found a version of this menu that comes from a 1982 pre-release Lisa, never launched to the public. Let me show them side by side:

It’s fun to see designers figuring it all out. You will notice the lack of dividers and ellipses actually touching the work-in-progress strings. 1983’s Set Aside is 1982’s very modern Close. Save & Put Away is Put Back. And, at the bottom, it seems the team didn’t yet figure out that the menu options need to consistently use verbs for commands, and adjectives or nouns for toggles – so we see Intended for Printer… (rather than Format For Printer…) and Printing in Progress… (rather than Monitor The Printer…).

Lastly, in a released version of LisaList, this menu would come bearing a harrowing Fix Damaged Document command. Not only it doesn’t even have an ellipsis, but the manual also says “there is always the chance that the recovery process will make things worse instead of better.” Vaya con dios, I suppose.

Let’s move on to the Edit menu.

Today’s Select All is a verbose Select All Of Document, and since this is the first public appearance of undo, that feature is also more descriptive, appearing as Undo Last Change. But otherwise the menu feels surprisingly modern, shortcuts and all.

Unsurprisingly, the first undo wasn’t as developed. We saw earlier in this post “Once you click OK, you will not be able to change your mind, even with Undo,” which today would probably say “This is not undoable.” You could also see a frightening error message arriving without any further clarification, like above.

Sometimes, the app would warn you undo doesn’t have your back. We’ve seen this before, and here’s another example.

Since undo only had one step, LisaCalc and LisaList also had Restore Previous Entry for when you changed your mind after editing a cell in the spreadsheet. You had to employ this strategically, as you did the already-mentioned Revert to Previous Version.

“You can even undo Undo!” bragged the manual, and I imagine there must have been interfaces where undo came without a matching redo. But the eventual solution, of course, was bidirectional undo/​redo with many steps. This basically only needed more memory, still very expensive in 1983.

Above we also see Clear Entries that would just be called Clear today.

Elsewhere in Edit menu, Clear Lines Off Top would appear in LisaTerminal only, and was a charming (and I would argue better) way of saying Clear Scrollback.

The next menu, Type Style, would be called Font today. “Type” is typewriter nomenclature – Lisa was meant to be a typewriter replacement. The point/​pitch convention for font sizes and letter spacing also comes from typewriters, and in an older version of that menu even font names arrive from that universe (PS = Proportionally Spaced!):

Otherwise, notable is the deterministic Plain Text reset with a P shortcut that would in time lose to printing. I miss this sometimes, this “reset” idea, as I think it would nicely compliment Paste And Match Style.

(By the way, Lisa was the last computer to use Apple logo as a modifier key.)

While Type Style is for selection, Format ¶ is all about paragraphs – HTML people know this distinction as “inline vs. block.” (The pilcrow symbol means “paragraph,” although I did not expect it to be common use even then.) The flyout menus with their convoluted mechanics weren’t invented yet, but in some sense there was no need for them as the options were very limited.

It is interesting to see Margin/Tab Ruler as two options with deterministic shortcuts ([ and ]). But the most unbelievable shortcut must be Same As On Clipboard. It reformats the current selection to match what you have in the clipboard – an early salvo in an endless battle that later brought us Paste Special, Paste And Match Style, Paste And Retain Style, Copy/​Paste Properties, Paint Format and so on, and so on. And it was given S, rather than spending it on Save (& Continue).

Otherwise Left Flush and Right Flush would be called aligning today, and the ¶ pilcrow symbol would be replaced by a simple Paragraph Spacing.

In LisaCalc, Format is missing the ¶ because, well, there are no paragraphs in spreadsheets! I love Words Left/Nos. Right, and empathize with trying to align the digits. But it wasn’t even close, was it.

Page Layout shows that we’ve had UI boolean problems from day one. Show Page Ruler and Hide Page Ruler do it deterministically, with one always disabled, and without checkmarks. Preview Pages and Don’t Preview Pages do the checkmark, but introduce a dreaded double negative. (These last options, by the way, is the “pages/​pageless format” showing page margins and dividers, that bother us so much about Google Docs.) Today, these would all be in the View menu that doesn’t exist yet.

And speaking of boolean challenges, here are some top-level menus from LisaList with even more conventions:

But, back to the Page Layout Menu. Insert Page Mark would be Insert Page Break today. I really love Allow To Cross Pages as the opposite of Keep On Same Page, and the incredible O and Q shortcuts.

In LisaCalc, this particular menu comes with a beautifully named For Your Information (sentence capped, for some reason)…

…throwing up a sheet-like window showing basic stats. Today, that window would have a more boring name and probably land in the File menu:

The Search menu is fascinating – why wasn’t it called Find like its items are? I am particularly enjoying W keyed off of Find What (today: Find), while F is taken by Find Next Occurrence (today: Find Again). There is some mnemonic sense to it all, but I like today’s proximity of ⌘F/G better.

What we know as Replace is Change here, and I am particularly loving Cases Must Agree and Cases Need Not Agree (today usually called “case sensitivity.”)

Hide Dialog Box is a string with surprising to me amount of UI jargon. The H shortcut was added later in Lisa’s life, presumably at users’ behest. It’s strange today to see a shortcut like this to hide one specific floating dialog box.

Similarly, Insert Wild Card with a confusing ellipsis allows you to insert a symbol in your find dialog that stands for “match anything here” – top-level menu options reaching inside specific dialog boxes were not uncommon in early years of GUIs, but I think fell out of favor over time as the idea can be conceptually confusing.

The menu below is from LisaWrite, and I like how comparing it with other apps makes us see the team trying to settle on a convention. In LisaList there are no ellipsis, but question marks!

And in LisaCalc, there are… both:

You can notice that it wasn’t clear where one would put Find-related commands and their today’s presence in Edit menu doesn’t really make a lot of sense, either. We just got used to it. (Also note the “occurence” typo.)

Spelling menu has a bunch of fun options and conventions, and an extremely generous use of keyboard shortcuts:

• Find Next Misspelling (you don’t often see that word!)
• Suggest Corrections + Paste Guess (this is just replacing the word with the suggestion – interesting use of the clipboard metaphor)
• Put In Dictionary (today: Learn Spelling)

LisaDraw sports the Arrangement menu, which will look very familiar to anyone using Illustrator, Sketch, Figma, and so on. This is where Bring To Front and Send To Back started! With a tiny bit of editing (Arrangement is now Arrange, and some of the Objects nouns would be omitted), this would feel pretty modern.

I love these visual menus, and I think we lost that kind of stuff along the way:

Okay, let’s move on from menus. The system also relied a lot of dialogs. Let’s look at some of them:

This wordy dialog would become a small loading state today. The verbose “To terminate the operation, hold down the Apple key while you type a period” probably felt necessary because other than Shift on a typewriter, people were not familiar with modifier keys. Lisa doesn’t have the Esc key, and Mac still respects the ⌘. convention in many places in 2026.

(By the way, why would you want to stop saving? Presumably because it could take quite a while.)

In this similar dialog, you can see a reference to a “micro diskette.” Even though Lisa’s “Twiggy” disks seem gargantuan today, they were smaller compared to the original, 8″ floppy disk. (In a similar way, Lisa and other machines of the era were called “microcomputers.”)

Lisa had some proprioception: In this dialog, the disk put in the first drive is called an “upper diskette.” (Also note: more undo education.)

Disks were not large, so sometimes you had to deal with this kind of horror. It’s interesting how the dialog plain sends you to the manual – an early equivalent to eventual Learn More links.

This is another example of a rather verbose set of instructions. On one hand, this is better than “Error 456” and nothing else. On the other hand, it feels like a lot of stuff to memorize.

Also of note, the beautiful Housekeeping menu. I actually forgot about the Finder (or, in Lisa’s parlance, Desktop), so here’s a screenshot of it also:

Housekeeping was basically the junk drawer – on the Mac a year later, this will be named Special. It also has some stuff that today would be in the View menu. (This later version of Lisa calls Trash the same as the Mac. Earlier on, you would see it named a Wastebasket instead.)

Of note elsewhere in Desktop is the use of the term Stationery, roughly meaning “template,” but with extra sprinkling of desktop-metaphor skeuomorphism. Also, Attributes Of is an early version of Get Info.

Another verbose dialog (compare with Abort/​Retry/Ignore from around the same time). This is before we invented hint text that we’d just put under the buttons themselves.

In case you haven’t noticed by now, Lisa’s strings all have two spaces after a full stop!

There was lot of “you cannot” dialogs, walking you through some recovery steps.

Plug and play didn’t yet exist (this would all happen in the 1990s), so that had to be explained also.

I also love the anthropomorphic phrasing “Preferences has been told,” which I don’t believe you see anywhere today.

And I think we can round up this post with a few small delightful language details like this one.

As a huge fan of the slightly pretentious “presently” over “currently,” I smiled seeing this next to the printing status.

“Just a moment, please…” feels so old-fashioned, somehow.

And I want to end on a pre-release version of the Edit menu we’ve already seen. You can spot here Select Entire Document (instead of eventual Select All Of Document), but of course the best thing is the Copy, Cut, & Paste with an ampersand! I find it so, so charming.

I hope you enjoyed this tour. It was interesting to me to see how many of these became the standard back there and then, how many were tweaked a little bit, and which ones had to be redone more thoroughly.

Now, excuse me as I have to go deal with my whistling printer.

#apple #history #interface design #undo #writing

I think it’s worth checking out that list and internalizing it even if you’re nowhere near that kind of a decision, because some of these are universal requirements for a better-feeling interface:

• No cursor: pointer on interactive controls. Desktop apps don’t do this. It’s small, but it immediately signals “this is a website.”
• No hover highlights on most controls. On macOS, buttons and list items don’t highlight on hover the way they do on the web.
• Settings open in a separate native window, not a modal or a side panel.
• Popovers and tooltips render as native windows, not as DOM elements inside the WebView. They can extend beyond the window bounds, just like native popovers do.
• On macOS Tahoe, we adopted Apple’s new Liquid Glass material so Raycast blends with the system’s updated visual language from day one.
• No flickering when views appear or transition. This is a common tell in web apps, and we did a lot of work to eliminate it.

There is more in the blog post, and a lot more still left unsaid. Let me add one that I see all the time: accidental text selection. Web makes all text selectable by default, regardless of whether it makes sense for that text to be selected. On top of that, text selection heuristics on complex layouts are not that great. That means that surprisingly often you will see half a text on the page being selected in response to an accidental click or drag.

Here’s an example from YouTube I just spotted, where dragging a sidebar selects everything inside it:

It’s all solvable via the use of event cancellation and user-select, but requires someone to think about it happening.

Yes, there are moments where GUIs allow you to select text for a reason…

…but it’s always been a tricky proposition given the scarcity of affordances. It might be better to employ a pretty common “copy to clipboard” pattern instead.

#interface design #raycast #web

No matter whether you search with a proper accented character, or with its basic Latin equivalent, all the same stuff matches: The “ø” letter is treated the same as “o” both in the input field, and then in the search itself.

Yet, Chrome’s tab search inexplicably doesn’t do that, which confused me when working on a post about diacritics earlier this week. Here, it should match all four open tabs:

Tab search was introduced years ago; the Occam’s Razor says this isn’t a recent bug, but that the feature has always behaved like this. I filed the bug, but even if it gets fixed quickly, I think this doesn’t reflect well on Chrome’s team. If the right code already exists for ⌘F, why not reuse it? If it cannot be reused, why not repurpose at least its unit tests or the QA process to make sure this doesn’t fall through the cracks? Normalization should be treated as a core property of any search, rather than an optional “nice to have.”

But, Marcin, didn’t you just invalidate your assertion that diacritics actually matter? After all, wouldn’t you input “nestlé” instead of “nestle” if they did?

To this, I have a few answers:

• Input is not output. This is no different than autocorrect, autocomplete, or other IME helpers.
• The very fact that on many keyboards accented characters are hard to input is itself a sign of anglo-centrism of companies that made early typewriters (Remington, which established a lot of European layouts like QWERTZ and AZERTY, employed a person who bragged he didn’t actually speak any languages in a “how hard could it be” way) and then most microcomputers.
• There is this really interesting rule, also known as Postel’s Law: “be conservative in what you output, but liberal in what you accept as input.” It’s not universally applicable – sometimes it’s better to teach the user to be more explicit if it benefits them in the longer run – but it feels appropriate to me here.

Why does it matter specifically for the ⌘F and the tab search experience? I have this personal theory: the simplest the search, the more the users will blame themselves if it doesn’t work, and assume the tab or the string just isn’t there, rather than rewrite their query. That’s what happened to me. I assumed that the tab wasn’t open and tried to get to it again, wasting time and effort.

The rule might be universally true for any UI surface – the tighter it gets, the less likely we assume it can break. After all, there is a manual for a typewriter, but there isn’t one for the pencil! And these UIs do feel positively basic; they are small windows with basically one input field and an immediate as-you-type reaction.

#definitions #keyboard #localization #search

Turns out, the startup melody was intentional in this particular model. The power converters have to adapt the current from the overhead line to convert it to the three-phase motors of the locomotive, and that generates a rising tone. The engineers decided to change the logic to increment the tone in precise few steps resembling a musical scale, rather than allowing it to rise continuously.

I debated whether to include this on Unsung. I guess it is software, even if it’s attached to the hardest of hardware. And sure, it’s “just” delightful, but it is still kind of nice to see someone go extra, adding a human touch atop a technical process that had to happen anyway.

But then, it reminded me of something. No, not the poor CSIRAC trying (and similarly struggling) to become a musician. Rather, a “musical road” built in Lancaster, California, where the engineers messed up the execution, creating a truly unpleasant, atonal melody. David Simmons-Duffin wrote a fun essay in 2008 analyzing the “bug” thoroughly, including useful visuals, and even replicating the problem. Subsequently, Tom Scott visited the road and made a video about it ten years later.

It won’t surprise you that the cause of the bug was bad hand-off between designers and engineers, but there can be no software patch for grooves you cut in asphalt – and so at least as of last year, the embarrassingly sounding road was still there.

I think I prefer my out-of-tune musical scale performed by a train. Given it’s easy to find compilation videos of Siemens locomotives booting up, it seems I’m not alone.

#bugs #real world #sound design #youtube

The AirPods Pro case does this when charging – right at the start, or when you tap it later. But it disappears after a while, the pace is now 28 breaths a minute (over twice as fast as the original iteration), and the light is orange.

Is it still the same thing, reflecting on how smaller organisms breathe faster? Or is it mostly an unrelated idea, with the light fading in and out indicating activity rather than lack of it? My money is on the latter – the light turns white when pairing, too, and it cycles even faster then – but it was nice to imagine the return of the old feature for a second or two… or 2.1, to be precise.

#apple #details #hardware #motion design

The demo doesn’t just make QUOD feel gargantuan. Output this one solitary emoji, “Woman Technologist with Light Skin Tone” – 👩🏻‍💻 – and you spent all your 16 bytes, too. (Proof!)

The creator’s write-up is a bit hard to follow, but there are some interesting aspects to it: “stealing” the beauty from math itself, the reliance on the environment being set up properly (to avoid wasting precious bytes on initialization), and the tight connection between the hardware, the visuals, and the sound.

Oh yeah, in case you haven’t noticed, this has sound! Two out of 16 bytes are devoted to its production, using an existing BIOS function that slots nicely into the existing graphics routine.

This is another recent demo that caught my attention: NINE, from about a year ago:

The platform here is a computer of a similar vintage as the early DOS machines, Commodore 64. C64, like many other home microcomputers, supported special graphical entities called “sprites,” which were used for gaming since the rest of the graphics couldn’t move very fast. (Today, your mouse pointer is conceptually similar to a sprite, being imbued with special powers unavailable to anything else.)

C64 could output up to 8 such sprites. The demo inexplicably has… nine.

The NINE demo didn’t focus on absolute minimalism, but instead employed a barrage of ghostly (and ghastly!) trickery to achieve something that was thought impossible. This time around, the explainer from the author – a 22-minute YouTube video – is filled with great storytelling, and absolutely worth a watch:

I think both of these showcase two things that I appreciate and that translate to great UX design as well.

The first demo shows tight integration between design and the capabilities of software and hardware. Let’s pick the sound routine that needed just 2 bytes. If there wasn’t a way to output sound within this extremely tight budget, the author likely wouldn’t fight to their death to get sound… they would instead focus on what else was possible within two bytes. This is getting as close to full understanding of the medium you’re working in as possible.

The second demo highlights how sometimes you can use absolutely horrid sleights of hand to achieve something beautiful – and how you can perhaps find beauty in those sleights of hand, too. It reminds me of the quote attributed to Teller (of Penn & Teller):

Sometimes magic is just someone spending more time on something than anyone else might reasonably expect.

Penn & Teller talk a lot about how there are only two keys to their success: going further than others would think, and not worrying about employing inelegant tricks in service of something that would appear to be of utmost elegance.

Today’s computing limitations are different than the ones from the 1980s. But a lot of this attitude can still be helpful, even four decades in, and even if your work seems as far away from the demoscene as you can imagine.

#graphics #hacks #youtube

Here is the before and after of this situation:

Ordinarily, this can be frustrating but not insurmountable; you can always copy/​paste, rely on autocorrect to help out, or even add some topical text replacements for common phrases. The problem is that this bug only appeared on the keyboard used for logging on, and at least a few people used that character in their password. There, none of these workarounds were available – and so those people were now completely locked out of their iPhones.

The Register reported on this on April 12, and a few days later suggested that Apple was working on a fix. I won’t keep you in suspense; I just verified that the fix landed with the recent May 11 update.

This is, in an of itself, not a fascinating story, but with interesting things to talk about at its periphery.

First of all, The Register never showed a single screenshot. This led to a lot of confusion and speculation in the comments. Turns out, screenshots are valuable not just with bug reporting, but also with bug reporting.

Second, check out this Czech keyboard. Even within the limitations of the ancient QWERTY, there’s a lot of cool stuff happening here. Two new accented keys just appear on the top layer when you switch to Czech. Both have magical properties, too. They’re the modern “dead keys” that either stand alone, or get combined with the previous letter if that makes sense.

This is the stuff typewriters, and even desktop keyboards, could only dream of. But, as always, more software means more bugs, including some with unforeseen consequences; a typewriter could never break this way.

Thirdly, there is this interesting tension between us being led to believe “more interesting passwords are safer,” but then sometimes being penalized for actually making them interesting. A decade ago someone used emoji in their password without realizing they won’t be able to input it, and I’m sure there were other examples.

But the most interesting, to me, part? It’s the diacritic itself. Under one of the posts, a commenter wrote:

Stick with the 7-bit ASCII subset. You will never go wrong.

7-bit ASCII basically means “26 Western letters and nothing else.”

I hate this. I know it’s objectively true – in the late 1980s I felt a sense of relief my name didn’t have any of Polish language’s nine diacritics, which would complicate my life. Even just yesterday in Germany, I spotted this:

Software still struggles beyond ASCII. But this is why we need to keep pushing. Diacritical characters are to be found everywhere in the world. They’re detailed, and varied, and filled with histories. Umlaut is not diaeresis. Kreska is not the acute. A háček is not a breve. They’re rarely optional decoration, and often not even decoration at all; learning about Turkish dotless i might completely upend your understanding of what’s an accent and what is not.

If you don’t have a favourite diacritic, you are missing out. Even the names – grave! ogonek! horn! – are beautiful. (Háček is also known as caron and a wedge depending on context, and in other regions referred to with beautiful words kvačica and strešica.)

If you’re interested, here is David J. Ross’s 22-minute talk about getting to love diacritics from the perspective of a type designer. It’s filled with craft and playfulness:

My favourite accent is, obviously, ogonek. Just looking at Adam Twardoch’s guide on how it should be drawn fills my heart with joy:

#bugs #david jonathan ross #localization #security #typography #youtube

…is to avoid “more” expanding to just one item. If the expansion takes up as much room as the UI to show the expansion, why not show it in the first place?

#details #interface design

One bit of challenge with [where I work] is that my audience isn’t already almost-guaranteed to be into design! They’re hopefully interested in making good software in general, though, and probably curious about the app [I’m building] they could be using. I’m also afraid that developers sometimes confuse “easy to use” with “beginner-only, limiting”, which makes it harder to write about streamlining UIs; there’s only so many times you can invoke “reducing mental load.”

I love this question because it gets to the core of why I started this blog. I’m perennially unhappy with the conflation of “craft” with “delight,” and the subsequent narrowing of “delight” into “cute strings and slow animations.” In the famous words of Steve Jobs, “Design is not how it looks. Design is how it works. What’s tricky is that they’re sometimes related, and even if you learn how to tell the difference, your exec team probably never will.”

I am quoting from memory.

Anyway, I hope spending time on Unsung – please like and subscribe – helps with examples of what to talk about and how to talk about them. But, just to list some alternatives to “reduces mental load” for well-made software that come to my mind:

• is more efficient
• gets you home earlier
• will allow you to spend more time on things you enjoy
• will allow you to choose which parts of the problem to spend time on
• reduces tedium
• understands and practices progressive disclosure
• understands you
• speaks your language
• learns your preferences
• meets you where you are
• is made by people like you
• respects you
• will make you better at what you do
• rewards mastery
• doesn’t dumb things down
• will teach you concepts helpful in other software
• never takes control away from you
• is easy to customize
• adapts to you
• doesn’t disobey you
• will make you look good in front of others
• respects history and legacy of the space
• is built well
• is conceptually/​systemically beautiful
• is well-considered or thoughtful

There’s more, and I am curious what comes to your mind and how you all connect with developers! But maybe just going through a list like this will provoke some ideas.

(Of course, if you cannot honestly claim some of these about software you’re working on, and you think they’re important – I guess you have some work to do.)

#storytelling

Software should be as small as it can be. Not as a gimmick, but as a discipline. The floppy disk is the measuring stick: 1.44 MB. If the software that ran entire businesses could fit in that space, then a modern, focused, single-purpose tool certainly can.

In my own work, I have mostly focused on the web side of this equation, as this is where the situation feels the most dire: tens of megabytes dedicated to heavy frameworks, unnecessary tracking scripts, and video ads have a real negative effect on experiencing websites. Progressive loading challenges also make it harder to offer a great experience.

But space considerations are starting to feel more pertinent to local software too, in an era where SSD and hard drive prices are going up, and where local LLM models start taking up more room.

Also, this passage feels very Unsung, and is exactly why the tag #history exists on this blog:

I don’t miss floppy disks. I miss the mindset they demanded—that every byte matters, that constraints breed creativity, and that software should be light on its footprint.

If you reduce tech history to just nostalgia, it won’t be that useful. But if you look at it as inspiration, you might find some truly wonderful and meaningful stuff in there.

On that note: Bonus for a nice classic domain, and a nod toward Mac’s most famous screensaver.

#history #performance

It not only provides an alternative to desktop‘s Home and ⌘↑ keys, but the student laps the teacher here; it’s actually better than every way to scroll to the top on desktop (do you like pressing ⌘↑? do you even have a Home key?), and it’s an icing on a cake of a regular flick to throw the page to the top already being pretty nice.

Tap to return to top is also distinctively mobile in that it allows you to tap just anywhere near the top edge that’s not already a tap target; as far as I can observe, traditional GUIs detest being imprecise in this way, always asking you to click on something specific (although window moving on macOS in the post-title-bar era is also starting to feel similar).

The iPhone gesture seemed to work so well that, over the years, more patterns started borrowing from it. In Bluesky and tons of other apps, you can tap on any tab with scrollable content a second time to scroll all the way to the top. (Again, something that’s hard to imagine on desktop, where you pretty much almost never think of clicking on an already-selected item.)

It’s not just the top, either. In Podcasts, tapping Home goes back to the left:

And in Photos, to the bottom:

To me, the whole “tap to return to the beginning” gesture universe feels ascended to be the core property of the interface. In that way, it is similar to scrolling, undo, copy/​paste, arrow keys moving the text cursor, and so on, all inducted to the National Register Of Historic Gestures.

Why? Because these gestures can only blossom if they work consistently, everywhere. You need to start trusting them so much they slide into your subconsciousness. Breaking the gesture in one place will make it less trustworthy in other places, too, ejecting it from motor memory back to the level of deliberate effort, and therefore making it a lot less usable. “Does this thing work here or not?” is a death knell of flow.

The fact that tapping on tabs is idempotent means there’s also no penalty; if you’re already at the beginning but are not sure, tapping it mindlessly won’t hurt or send you back somewhere else.

This is all great. And this is why I’m unhappy Safari started mucking with it.

Safari has tabs at the bottom – starting with two (regular set and “private” set), although you can add more. Above is a long list of site cards, with newest at the bottom. It’s exactly the same situation as in Photos, and yet tapping on either tab doesn’t restore the scroll position. Instead, it opens the settings dialog:

And, tapping around the buttons does nothing.

I would imagine Safari is a pretty important app used by many people, and so this feels like a bad place to introduce an inconsistency that could have a more serious consequences of un-teaching people about tap to scroll to top in the long run.

The funny thing is that the solution is already there: you can tap ··· in the upper left corner to get to the same functionality. The long press on the tab also opens the same menu.

Messing with a “tap to go back to the beginning” system gesture like this means to me the design team doesn’t fully share the understanding of the value of their own creation, or maybe that stewards of the gesture system are not vigilant… or perhaps the awareness is there, but the caretakers aren’t recognized, rewarded, or empowered enough.

It’s similar to the “no, thanks” example I shared before, a possible worrisome tragedy of the UX commons in the making if the respective teams do not change course. Because, wedging that sort of an exception in – even if you have a great set of reasons in the moment – creates a precedent. Inevitably, from my experience, the next team that will want to override scroll to top, or misuse “No, thanks,” will now require less of a justification.

#definitions #details #flow #interface design #touch

This video combines my first 5,162 attempts to speedrun Super Mario Bros. I recorded 193 hours of attempts (and practice) on an original 1985 Nintendo Entertainment System, then I wrote a custom computer program to process those videos and combine them via machine learning and conventional image processing techniques.

This is not just fun to look at, and – presumably – study as you’re speedrunning yourself. A sign of a good visualization is that it makes you see stuff that you haven’t before and here, at some point (after 1:42), you start noticing strange comb-like patterns in Mario running.

Turns out this is actually a thing called a “frame rule,” a quirk of game’s timing code where it only checks for a completion of the level every 21 frames, or one third of a second. That means that for every level after the first one, your start will be rounded up to the nearest 21st frame:

The analogy often given is to think of a bus that leaves every 21 frames, and levels can only end by getting on that bus, and so other than in the last level (which has no new level to load at the end of it), improvements in Super Mario Bros. can only happen in 21 frame increments. If you save a frame or two in a level, but it’s not enough to make the previous frame rule, it’s not enough to take the previous bus, you’ll just end up waiting for it to happen anyway.

Stay tuned to the end of the video for some fun stats, and click through in the description below to see the same tech applied live during an in-person speedrunning event.

#speedrunning #super mario bros #youtube

I wrote before how a simple rule to give some breathing room to your length-limited edit fields can be upleveled to a more general “let me color outside the lines when I’m editing” principle. This is another example of a similar situation.

I am in Buttondown, which is a mailing list software. I created a quick test draft just to check something out in the editor, I didn’t do anything else, and then I proceeded to delete it. Then, I was greeted with this:

This is nothing more than a larger version of the “You have 1 email(s)” problem. There might be a situation when I’m deleting something that has been published and linked to. In that case, it’d be good to know about how any links to that thing will cease working.

But this is not that kind of a situation, and the software has all the info to know that. In this moment, it could show me a simpler, much less alarming message more appropriate to my situation. This is not the end of a radio pharma ad where you have to rattle out all the legal disclaimers just in case something could happen.

One tiny counterexample from my neck of the woods: in Figma, when you start writing a comment and then exit without posting it, you get a little warning. But you don’t get that warning when you type something that’s <= 8 characters. In this case, the assumption is that retyping a few characters elsewhere (assuming you haven’t just changed your mind altogether) is much easier and faster than cognitively processing and dismissing the warning.

The challenge with Buttondown’s dialog is that this is more than just extra cognitive processing and “cheapness.“ Here, the stakes are higher, as we’re talking about something adjacent to data loss; the dialog really does feel a bit scary and makes me think I can do some real damage in a situation no real damage is possible.

#interface design #principles #writing

Cryptic mode was born from a hard constraint: teletype terminals in the 1960s billed by the character transmitted. Every keystroke cost money. A command that took 50 characters instead of 10 cost five times as much. Commands were compressed to the absolute minimum.

The result is a domain-specific language whose syntax was shaped entirely by economics. AN for Availability Next. SS for Sell Segment. NM for Name. ER for End and Retrieve. No vowels wasted. No words spelled out.

Apparently the official name is “native mode,” but it gained its nickname because… well, see for yourself.

Asking the system for “Availability for Next flight” for February 8, from Nagpur to Delhi, is just 13 characters:

AN08FEBNAGDEL

And the system responds in an equally mysterious way:

** AMADEUS AVAILABILITY - AN ** NAG DEL SU 08FEB 0000
1 AI 416 Z9 C9 D9 Y9 B9 NAG DEL 0840 1030 32A 0
2 AI 416 M9 H9 K9 Q9 T9 NAG DEL 0840 1030 32A 0
3 6E 5317 S9 T9 W9 V9 Q9 NAG DEL 0840 0755 32A 0

With time these commands became wrapped inside more approachable interfaces and GUIs. But they exist under the hood and…

Many experienced travel agents still use it today alongside, and sometimes instead of, web-based agent interfaces such as Amadeus Selling Platform Connect. For a trained operator working a booking-heavy workflow, it is faster than the equivalent graphical interface for the same sequence of operations.

Except today, you get to choose. At the beginning, when “online” didn’t imply internet, and registration computers looked like this, you didn’t have a choice: this was the language you had to fluently write and read.

It makes Unix commands, also intentionally short/​cryptic, look like Microsoft Bob.

#command line #flow #maintenance #software evolution

I am maybe a sucker for videos and podcasts where people start laughing, but here we go – a very short video about a version of Linux that “does not limit how big your pointer can get if you wiggle the mouse pointer”:

#humor #mouse #youtube

It explains those weird moments where sometimes the computer asks you to wiggle your mouse – to generate unpredictable numbers – although the specifics of what exactly was random in my wiggling was a surprise to me.

There is something poetic about computers yearning for that one thing they can never get – complete unpredictability – and collecting it in a little pool like you would something very precious. Also fascinating that in modern CPUs, there now exist hardware components that gather truly random data from the real world.

While I have never needed true randomness in my design career, knowing how to control pseudorandomness (specifically, how to replay it) has been helpful.

Here’s an example. In my essay about Gorton, there is this interactive bit where you can drag a slider for “messiness.” With regular pseudorandomness, the experience is wiggly and gross:

But when you always restart the prng from the same seed (“the Groundhog Day maneuver”), it feels much better:

#details #motion design #security #youtube

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.

#adobe #apple #bugs #interface design #nick heer #process

You’ve seen it so many times before:

• you start reading a webpage, but it throws you back to the top when JavaScript finishes loading,
• you start reading a webpage, and ads or other stuff appear and shove you around up and down,
• you press a back button and that goes to the previous page… but to its top, rather than where you actually were,
• you zoom in or out, the position isn’t recalculated properly, and suddenly you see a different part of the page and lose your orientation.

To me, the scroll position is as sacred as the mouse pointer position, given the two are related whether Scroll Lock is around or not: one is you, the other is the world around you.

But there are moments when software scrolling with the user or even for the user is appropriate, and here’s one example:

When you switch tabs, the content below should always scroll to the top, but it doesn’t here.

Here’s an even worse example, also from Settings:

Why should the content scroll to the top here? Because in these situations, the fact that the content container gets reused is just a technical quirk of the implementation. From the user’s perspective, this is all new content, and new content should always start at the top. Otherwise, things will get confusing really fast; imagine it especially in the default configuration without scrollbars, where you might assume result number 6 is the first result, or completely miss the most important, topmost options.

(Before you ask: Yes, I also see this in Tahoe.)

#interface design #mouse

For context, Save For Web was a popular export function in Photoshop at the peak of its use for web design, but assigned a rather unpleasant ⌘⌥⇧S shortcut. Using it often turned your hand into a… claw of sorts.

There was a Tumblr cataloging real and humorous photos of people pressing Save For Web. You can still find parts of it on Internet Archive, and here are some choice photos:

This is funny, but I actually found it enlightening – and lightly frightening – to ask coworkers how exactly they press common shortcuts like ⌘Z, ⌘C, ⌘V, and so on. There was a lot more variety than I expected.

(My basic heuristics say: three-modifier-key shortcuts should not be assigned to anything used often.)

#humor #keyboard

How do you squeeze a city that occupies over 50 megabytes into the 32MB memory of the console? You simply do what The Truman Show did, and construct the city around the player as they’re moving around:

This has, as you can expect, a lot of technical and even game-design consequences, and the video goes into a lot of detail on these – including Brown rebuilding the Grand Theft Auto 3 source to visualize things better.

This technique is also used in interface design, for example if you have a really long list of things that would take too much memory or GPU power to render. What the video calls “streaming” is, in the context of UI, often called “virtualization”: instead of having a full long list (or an entire world), you abstract it away – or, virtualize – into something nimbler.

Some of the challenges and techniques used by Grand Theft Auto 3 apply pretty directly here, as well:

• you can use UI skeletons as “low poly” models,
• in some contexts, you can guess the user is more likely to move in one direction (for example, going through fonts in a font picker), and more eagerly preload where they’re going to look next, rather than symmetrically in both directions.

On the other hand, “speedy players” and “pop in” can’t ever be solved because any UI list is random access, and slowing users down is not typically appropriate; better to make loading as pleasant as possible than introduce any roadblocks, even if figurative ones.

#definitions #games #performance #youtube

In 2020, macOS Big Sur unified those styles and made them more iOS-like:

A few years later, Jim Nielsen revisited the icon “Big Sur-ification”, and showed examples of apps that did the transition really well, but also those where the transition felt… lazy, essentially shoving their previous icon into a roundrect.

For those, Nielsen proposes some alternatives that are delightful to see:

The Word/​Excel/PowerPoint/​Outlook explorations are particularly nicely done.

#iconography

The setup was a small nightmare, needing a rare hardware card installed in a specific computer, an ultra-particular combination of two operating systems working in lockstep, and even some careful memory balancing.

Even after all that, a 300dpi page scanner in the late 1980s was still a force to be reckoned with. It’s hard to remember how enormous scanned files were compared to anything else then, even on a black-and-white scanner like this one. The video shows a simple 90-degree image rotation in highest quality requiring over 9 hours, and I believe it.

But deep inside the video, at precisely 19:31, for only ten seconds, something appears that is absolutely worth celebrating. The nascent scanner software has a “curves” feature that allows you to redraw the shades of gray to capture shadows, highlights, and midtones exactly how you want them. Today, the feature would look something like this, with a real-time preview:

There would be absolutely no way to do something like this in the late 1980s, when just rotating an image is an overnight operation, right? And yet:

How was this accomplished? Absolutely brilliantly. Remember the palette swapping technique? Here, the entire screen’s palette is 256 shades of gray. It’s a very particular kind of a linear palette, and so you can easily take that line and… well, turn it into a curve. Since palette swapping happens on the graphic card, it takes as little as one frame of time, allowing for it to react to mouse movements as they happen.

This must have been mind blowing to experience in the moment. Sure, it’s only a preview, and actually applying curves to the image would take many minut—

No. This is a wrong frame of mind. Here’s my hot take: There are moments in software where the preview is more important than the feature following it. That’s because the preview making things faster isn’t just the difference between finishing something sooner or later. It’s a difference of doing something or not doing it at all. Would you even attempt to use curves if each adjustment took minutes or hours, especially in a land without undo?

I love this preview that hints at what the future will be. I like this clever use of extremely limited technology and tight collaboration between engineering and design. It must have been nice to be in the room whenever someone had the flash of insight to use palette swapping this way.

#above and beyond #flow #graphics #history

The remote was universally ridiculed for its “which way is up?” problem – too much vertical symmetry which didn’t give your hand enough cues to know whether you’re picking it up the right way or the wrong way.

Apple tried a half-measure first; in 2017 they broke the symmetry by making the MENU button slightly distinct in visual and tactile ways. Hindsight is 4K, but I don’t think it had a chance of working – the tactile cues were too subtle, and the visual ones do not matter when you’re not looking:

So Apple overshot – the subsequent 2021 edition was a full-measure-and-then-a-half:

The remote shrank the touch surface but otherwise drastically increased the volume, and added four arrows, two new buttons, and a strange iPod-inspired clock wheel interaction on top. And to me it started feeling a bit complicated, inching toward the very TV remotes that earlier designs ridiculed. (It also wasn’t as pleasant to touch, as the buttons feel a bit rougher.)

But the reason I like the 2015 remote is primarily because it introduced one of my favourite gestures in recent history: tap to see progress.

It’s hard to describe how wonderfully light this interaction feels every time I use it. You just tap anywhere on the remote’s top half, you see where you are in the video via a subtle UI, and then wait a few second for it to disappear. After this, doing the same in every other player – YouTube, Netflix, HBO Max, anything on a Mac or even the iPhone – feels clunky and heavy. In many of them, you can’t even see were you are without stopping the video!

It gets better. Tap for the second time, and the elapsed time gets replaced by current time, and the remaining time by what the clock will say whenever you’re done watching. I thought this is delightful and clever, sneaking in clock functionality without showing it all the time.

There is also this really nice gestural separation. When you watch the video, taps and swipes are safe. Anything that is “destructive” – that is, causes the video to stop, or rewind, or fast forward, is on the “click” layer: press stronger on the center to pause, or on either side to move forward or back.

What I’m describing feels mechanically similar to other input devices, but the devil is in the details. On smartphones, everything is a tap, so you don’t really get anything lighter. On a Mac, tap as a gesture could only be available for people who opt in to press to click on their trackpad (like I do) – but the fact that tap is the default for clicking, means that can never realistically happen.

The Apple TV tap feels conceptually like Mac’s hover instead, but so much more pleasant and elegant and simple. (I want to prototype tap on a Mac as a lightweight “explainer,” showing tooltips there instead of on hover.)

To be fair, the tap gesture still exists in the still-current 2021 Apple TV remote, too – but the tap area is much smaller.

And just in case you were curious, these are the first two editions: the 2005 remote – shipped with the iMac, predating Apple TV – and the 2010 remote. (I’m referring to model years, because Apple’s own names are so confusing.)

I don’t have access to Apple’s user feedback, but I guess that Apple’s 2021 design was likely the very right thing to do. But looking at four-and-a-half of these models side by side, I am still in the 2015’s minimalistic, unusual, innovative corner.

#apple #details #interface design #touch

Engineer Max Goodhart built the front-end and wrote a summary of the whole project:

This year was a doozy. We specced and scrapped several different ideas in the months leading up to today. We finally settled on today’s concept just 3 days ago. The need to do something simple was a really useful constraint, and we leaned into the idea of making something primitive but deep.

The team seems to have had a lot of fun with it, including even JavaScript being encoded in Morse Code (the link in the blog post no longer works, but you can still see it on the Internet Archive).

Goodhart also wrote about the immense challenge of adjusting the Morse tapping speed to the user, which counterintuitively ended up needing… adjusting the user to the speed. But the best part is that the server communications used the Morse code in URLs, as well:

We took great pains to make the API for this project use morse code in the transport. If you take a look at the network inspector, you’ll notice that the URLs requested have morse code in them.

This worked for every combination of letters imaginable, with two oddly specific exceptions: a solitary E, and a solitary I.

I liked this description of what transpired next, which would have made me think I was going insane, too:

Then, an even stranger thing happened. I copied and pasted the correct URL into my browser and pressed Enter, and right before my eyes, it deleted the ”.” from the end of the URL and returned a different result.

I was delighted to discover an answer here, not only because in retrospect it’s such an obvious thing that was staring us all in the face for decades, but also because it has interesting URL construction consequences.

#bugs #encoding #web

I’ve always been amused by this imaginary interface, which is so clearly not how any sort of computer would work.

Or so I thought. These are photos I took in Melbourne in 2024 of CSIRAC, Australia’s first digital computer from about 1949:

This is a “console” of the computer, used to tactically probe or input specific memory addresses (in binary), and to control functions like stopping and starting the program. Any proper programming and eventually inputting data would happen using gentler I/O devices like typewriter keyboards, paper tape, and magnetic storage.

Physical consoles like this one were last seen in the 1970s on hobbyist home computers such as the Altair 8800, and the Console app on your Mac diligently spitting out logs is its spiritual and virtual successor. But even if a CSIRAC console feels hostile today, 75 years ago it was quite the opposite:

And [CSIRAC] helped there too. It could display all its working registers and the last 16 instructions executed. It could be given an address at which to stop (a “breakpoint”), and be stepped by one instruction at a time. It even had lights to show the computer’s internal states. This was a user-friendly computer.

CSIRAC stood for Commonwealth Scientific and Industrial Research Automatic Computer, a typical naming scheme of the era. We also got ENIAC (Electronic Numerical Integrator and Computer) in 1945, BINAC (Binary Automatic Computer) in 1949, EDVAC (Electronic Discrete Variable Automatic Computer) in 1946, ILLIAC (Illinois Automatic Computer) in 1952, and then SEAC, SWAC, ORDVAC, TREAC, AVIDAC, FLAC, WEIZAC, BIZMAC, RAMAC, and UNIVAC.

The story goes that the name of 1952’s MANIAC (Mathematical Analyzer Numerical Integrator and Automatic Computer) was chosen to highlight and put a stop to the goofy naming practice. Did it work? I am not sure. Not only two more MANIACs were produced, but we also got 1953’s JOHNNIAC (nicknamed “pneumoniac” since it needed a lot of air conditioning), and SILLIAC (Sydney ILLIAC) in 1956. The last computer I can find using that naming scheme was TIFRAC, operating in India between 1960 and 1965.

CSIRAC had real work to do, but today it is known chiefly for being the first computer to play music in real time. The quality is… I’ll let you judge, with links below pointing to short MP3s preserved by Paul Doornbusch and subsequently Internet Archive:

• Auld Lang Syne
• Chopin’s March
• In Cellar Cool
• (I particularly enjoyed an alt recording of In Cellar Cool where CSIRAC itself appears in a background as a constant humming presence.)

Do you miss your PC speaker yet?

Engineers working on other room-sized computers of that era did similar things; whether this was solely one of the first attempts to humanize the big scary machines, or a distraction from the computers’s typically military uses is left as an exercise for the listener.

Today, one of the 1960s machines still plays music, headlining a fascinating annual tradition – every December, the PDP-1 restoration crew at the Computer History Museum in California invites visitors to sing carols with the computer older than most of them.

The last photo takes us back to where we started. Neither CSIRAC nor PDP-1 might be user-friendly by today’s standards but damn, wouldn’t you want some of your computer’s interface to feel this way?

#history #sound design #youtube

I was inspired by the video, and really enjoyed its exploration of a demanding game that’s composed of just a few mechanics that are done really, really well:

The number of inputs are small, but the expression those inputs allow is deceptively expansive. […] Derelict Star’s various areas are all built to explore the way movement systems function and even interact with one another.

I think of user interfaces similarly, and of their need to build a certain consistent vocabulary of names, gestures, interface elements, concepts, and so on. Perhaps in an enterprise app you right click and discover something useful in a menu, and this will teach you about the usefulness of right click menus in general. Maybe pressing ⌥ to get to alternate symbols on your keyboard would inspire you (either consciously or not!) to try holding ⌥ in said menus, only to discover this brings up useful alternative options. Maybe seeing a keyboard shortcut next to one of these options will suggest to do that next time, and so on, and so on.

I really loved this bit in the video that could apply to a lot more software than just videogames:

It took me maybe an hour to do this, but right on the other side is a checkpoint. The game is hard, but it isn’t cruel. It’s designed to challenge you, but it has faith in your ability to complete it.

The narrator uses the term “ludocentrism” to refer to games that ruthlessly prioritize the mechanics and gameplay over narrative, aesthetics, and so on. (“Ludic” meaning “relating to play.”)

Of course, the calculus of what videogames care about will be different than goals of creative software or enterprise software; no one cares about the hero’s journey of the largest number in your Excel spreadsheet. But I think some version of ludocentrism applies to “boring”software as well. My beliefs here are probably something like this:

• you can’t reduce everything to just functionality or just efficiency,
• especially in creative moments of software use,
• and people use software creatively much more often than we suspect, including software not thought as “for creatives.”

#definitions #details #games #youtube

Ha. I was just messing with you. Of course you should alwaysbe worried about fonts. All the time. Typography is beautiful, but fonts are brutal. They will constantly put you to the test, they will find ways to get out of alignment faster than a Zastava Yugo, and they will teach you about corner cases in places you didn’t even realize had edges.

Fonts will break your heart like it’s the month before the prom again, and again, and again.

Or, in Allen Pike’s case, break a heart somewhat literally. Pike wrote a nice quick story of the complexity of what needed to happen to show the heart emoji, and how under a very specific set of conditions – a certain browser, a certain emoji font, a certain emoji within that font – this led to an extreme slowdown.

What’s really interesting is that in order to fix it, Apple can either improve Safari or the font itself, and at the moment of writing, it wasn’t clear what was the right thing to do. (Oh, yeah. Fonts don’t just have bugs. Fonts have many kinds of bugs.)

Another interesting in-between-the-lines thing is that Apple’s emoji are perhaps the only survivor of the original skeuomorphic pre-iOS 7 era. Even today’s emoji party like 2008 never ended – still glossy, still textured, still bitmapped. I’m curious whether somewhere deep inside Apple, there exist exploratory designs for flat, vector versions of emoji that never saw the light of day.

#bugs #skeuomorphism #typography

Screwdriver handles evolved over the decades in response to user needs and usage patterns, with a few clever affordances: some for everyone, some for specific use cases that might not be obvious.

I think by now all the basic onscreen UI elements – input fields, pop-up menus, checkboxes, buttons, top menus, sliders, and so on – have similar richness, as do all the core input devices like a keyboard, a mouse, a trackpad, or a touch screen.

That doesn’t mean that everything is set in stone, that no changes are possible, and that stuff that fell out of favour can ever be taken away – after all, computer usage, input devices, and conventions are evolving much faster than screws at this point – but that one has to be aware of the history so that the changes are intentional, not accidental.

A few select comments from under the video that I found interesting:

The Craftsman handles are also different colors for Phillips and slotted screwdrivers.

The fluted handle was patented. So anyone else wanting to make a screwdriver would have to pay the patent holder. So they tried alternatives to make more money. That is the real reason until the patent expired. Plus if they invented a “better” way and held the patent, others would have to pay THEM.

The Swedish word for screwdriver is “skruvmejsel” with literally translates as “screw chisel.”

#details #real world #youtube

But on top of that, scenes are shot out of sequence, and movies are shot out of sequence. There are pick-ups if you’re lucky, and reshoots when you’re not. About the only time your job will be noticed is if you mess up: cue Superman’s reverse CGI moustache, Josh Trank’s Fantastic Four wig situation, Commando’s damaged-then-pristine Porsche, and so on and so on. (This 7-minute YouTube video is a great walkthrough from an expert.)

Apple famously freezes time on their phones in all the promotional materials to be 9:41am. The specific moment they chose is a celebration of the first iPhone unveiling to be at around that time, but it also makes production easy – while people won’t mind that the time on the screen doesn’t match the current time, or even that it doesn’t seem to advance at a normal rate, they will definitely notice if you happened to splice two screenshots with different time side by side, just because you didn’t anticipate that splice as you were preparing them. So it’s easiest just to avoid this situation altogether.

But what I didn’t realize until today as I was recording the previous post’s screengrab is that 9:41am is also enforced whenever you record your phone’s screen via QuickTime. It’s a peculiar feeling: Start recording, and the time on your phone jumps to 9:41. Yank the USB cord out, and it’s back in sync with the universe:

Oh yeah, the date changes too, for the same reason – to January 9, 2007.

In a time-honored Apple tradition, I can’t decide whether I’m annoyed at it (there seems to be no option to turn it off), or admire it.

#details

There are desktop apps that get flustered if you ⌘+Tab away and back, misplacing focus or closing a dialog box inside. There are iOS apps that fully reset themselves whenever they get swapped out of memory and have to be reloaded.

But Bear, right here, remembers which note you were on, and exactly where you were in that note, even between phone reboots.

Software is transient and malleable, and one of the hard parts is knowing when that’s beneficial and when detrimental. In real life, you can leave a notebook on your desk, open on a certain page, leave a pen pointing to a specific word – and then depart for a two-month trip to Europe. You will find your notebook exactly how you left it. Why shouldn’t software behave this way?

Also, another thought: This is very likely not something users will complain about when broken, or suggest when absent, even if you go out of your way to open yourself for feedback. Just swapping an app out of memory is hard to understand and “repro” (in engineering parlance). There’s a certain design mindset and taste necessary to notice and care, and a certain vision to carry it through.

The lack of direct user feedback doesn’t mean it’s not worth doing. It just means that there are some things that designers and only designers will know how to properly weigh, describe, and prioritize. If you have a few design-minded users that actually send you feedback like this – treasure them. But most likely this will have to come from “inside the house.”

To me, it’s clear that within Shiny Frog (the makers of Bear), there are people who care about this kind of stuff, and leadership that trusts them. Kudos.

#above and beyond #bear #culture #flow #research

This is doubly magical to me. The first part is that this is even possible – that you can straighten the photo in both dimensions after the fact, and save for some parallax nuances the viewer won’t know any better.

For decades, this has been the domain of tilt-shift lenses, but if you ever tried to use one, you know how harrowing of an exercise this is. A tilt-shift lens looks more like a medical device and less like a piece of photography equipment:

The “obvious” way to emulate a tilt-shift lens in software is a bunch of sliders, and Lightroom has those also…

…but that’s still pretty cumbersome in practice, abstracted in a strange ways, like piloting a plane by pulling the linkages connected the flying surfaces: you will admire someone who can do that, but won’t ever want to do it yourself.

Hence the second magical moment: The team created the new interface I showed at the beginning, where you point to things that should be straight directly, and the necessary tilt-shift calculations happen behind the scenes.

Alas, Lightroom didn’t fully stick the landing. The interface is a bit jittery, and missing nice transitions that could help understand what’s going on. But what brought me here was this unpleasant interaction:

What’s wrong with it? If you want to play along, stop here and ponder: How would you improve it? Because this is a classic UI exercise where there are symptoms, and there are problems, and there are principles under the hood of it all.

The first possible improvement: Don’t do a dialog like this. These are ancient and so annoying. Every time I see a centered dialog covering everything, popping up in response to a delicate mouse operation, I want to shout “read the room!” It’s better to drop a little tooltip next to the cursor that automatically disappears: more modern, and more “compatible” with mousing.

Then: Why am I allowed to start and finish an action that the machine already knows won’t go anywhere? Disable the drawing option, put a little “verboten” icon on the mouse pointer, or do something else that will prevent me from drawing a line to begin with.

But that brings us to point three, and how I would approach this as a designer. Because I would – counterintuitively – go the other way and allow the user to draw as many lines as they wanted, and just didn’t permit to commit the entire operation if there were more than four lines on the screen.

Why is that?

It’s the same principle as you see in all the social media composing fields, and in well-trained forms: do not constrain the editing process.

This field is limited to 300 characters, but it’s clever enough to only enforce its limits when you try to post. There is no downside to allowing you more room in the editing process. Maybe you write by constructing a few sentences first and only then combining them into one, maybe you want to see two riffs one below the other to choose the better one, or maybe – this is most likely – you’re not even paying attention and your motor memory is doing the editing for you, instinctively. Use any text editor for just a few months, and cut, copy, and paste, word swapping, and splitting sentences become second-nature gestures – that is, until the UI starts throwing in some arbitrary barriers.

Above in Lightroom, it might actually be easier for me to draw a fifth line and then delete a previous one, instead of doing it in the precise order Lightroom desires, or by dragging an existing line to move it instead of creating a new one.

Maybe an overarching principle would be this: If you are aiming to build something so delightfully direct manipulation as Lightroom did here, you have to fully commit to that stance, even deep in the weeds. Because every time I see a 1990s dialog appear when my fingers are flying fast, I feel like this:

And something tells me others will too.

#flow #interface design #mouse #principles #text editing

Some time ago, Daniel Kennett created a little utility called Keyhole with a singular purpose:

Have you ever been annoyed by your Mac’s media keys triggering a random video in your web browser, doing something else weird, or by them doing… nothing? Even though your music player is right there?

Me too! And so Keyhole was born.

Keyhole intercepts media transport key presses before the operating system gets a hold of them, and promises to do a better job dispatching them to the right place.

This week Kennett added another feature – the app will monitor the repeat setting that apparently occasionally gets out of whack, and fix it for the user.

We could call these kinds of apps “janitor apps.” I know of a concept called cron jobs, but I’m assuming these quiet workers do backend-y things like moving files around, cleaning up databases, pinging servers, and so on. I am less aware of work like Kennett’s that fixes stuff on the UI layer.

Is it strange that I find this kind of an app pretty… noble? Of course, Apple should fix it; perhaps Bugs Apple Loves could even introduce a serious multiplier for “a bug bothers someone so much they fix it for Apple.”

Of note in the last dialog box: “Keyhole has fixed Music’s repeat setting X times.” I think this kind of a counter is pretty brilliant.

#bugs #keyboard

(I believe at least Google today calls this a snackbar.)

The UI pop-up element hosting Google Talk inside Gmail – the very same thing that’s more commonly called a “toast” these days – was originally termed a mole:

The column view in NeXTSTEP was called a browser, but a few years later someone put together a different kind of a browser on that very same machine, and the original term has been sunset – after NeXTSTEP became Mac OS, the view was renamed to “column view”:

These three are off the top of my head. Please send in more!

#history #interface design

I know this won’t have the same effect on you just watching. What happened was that, after I clicked on the Disable button, Lightroom moved the mouse pointer for me.

I don’t think I have ever seen anything like this, and it provoked many thoughts and emotions:

• This feels wrong. If the mouse is the extension of my fingers, and the mouse pointer the extension of the mouse, this is in effect the app grabbing my hand and moving it.
• I did not know this was even possible. I can see how moving the mouse pointer programmatically can be useful in very specific situations (like scrubbing, or accessibility), but… not like this.
• If you do something for the user, won’t that make it harder for them to remember how to do it themselves?
• I’ve seen this kind of a thing many times in my career: Someone genuinely asks “hey, if this is such a huge transgression, why wasn’t it codified somewhere in the style guide?” But to me the challenge is that it’s hard to imagine everything that needs to be preemptively captured and prohibited. I have to imagine this stuff for living, and I literally did not think anyone would just move a mouse pointer like this.

So seeing this now, yeah, I’d bundle this inside the “some interactions are 100% sacred” bucket, alongside focus never being hijacked randomly (especially in the middle of typing), avoiding scrolling anything until I specifically ask, undo and copy/​paste needing utmost protection, and a few more.

In the opposite camp, here’s a fun new project by Neal Agarwal (only worth clicking on a computer with a mouse). This is a situation where it feels perfectly fine for a cursor to be hijacked; as a matter of fact, there is something really interesting about a mouse pointer feeling less like a deity floating above it all, and more like a regular in-game actor.

This reminded me of that time, in the earlier days of Figma, when I prototyped an interaction where you could select someone else’s pointer and press Backspace to delete it:

We didn’t seriously consider it because it felt just too weird, and not that effective in solving “the other person’s cursor is distracting me” problem. But today it feels like it belongs to the same category as the two examples above.

I’ll let you decide if it’s closer to Agarwal’s delight or Lightroom’s terror.

#games #interface design #mouse #onboarding #principles

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.

#bugs #games #process #software evolution #youtube

There’s much to like here – thoughtful grouping and layout, good explanations, more details than expected.

There are some nice interaction moments, for example the hints swapping to reflect the current status:

The fact that the tool allows you to override its single-key shortcuts, which are the hardest to change using third-party keyboard customization apps:

Or, when you want to customize the key visualization, Settings shows a nice preview:

There was even this lil molly guard:

But also just the settings themselves gave me a sort of competence contact high. A few clicks in, and I thought “oh, they do know what they’re talking about.” So many things here were for me, to solve specific problems I encountered.

It all gave me confidence this is the right tool for the job. (Also, perhaps a corollary: has there even been a bad tool with well-designed settings?)

Compare with also-new-to-me settings from Affinity, which I was much less impressed with:

It uses the troubled right-aligned style originating in iOS, the capitalization is clumsy, and the navigation muddy (it feels like in-page links on the web, which are always confusing).

Is this a fair comparison? Not at all. I don’t actually want to say that CleanShot is better and Affinity is worse. This is so very much east coast apples and west coast oranges.

I don’t even want to say settings are always worth designing well in the traditional sense; sometimes the only thing between you and 20 unnecessary options in your app is simply having no surface that could host them. A limited (but never unpleasant!) settings UI might be an intentional design decision.

But there was a nice quote in the Shadow of the Colossus book: “I often find myself exploring simply because it’s beautiful.” I too became a tourist in all of CleanShot’s settings because they were put together so well, and I was so curious what’s behind the next corner. Its creators understood that the best way to get to know what the tool is capable of is to take a stroll through the settings. I think it’s a good case study at how a proper welcome mat doesn’t always have to be a few onboarding tooltips flying spastically around the screen. Sometimes it won’t look like a welcome mat at all.

#above and beyond #onboarding #writing

…but somewhere deep in the underbelly of Settings lives a little nod to the original 1984 Macintosh…

…in form of the tortoise/​hare icons:

#easter eggs #history #mac os

The video has some nice things going on besides specific details and conventions: there is a glimps of an obsolete app with a fascinatingly obtuse interface, a mention of modern standardization developments, and even a little (sad?) story of perfectionism and legacy.

I’m also kind of mesmerized by this shot of what music typesetting used to be:

There is also a short 1936 video showing more of that process. And small contribution from my end – a photo of the Keaton Music Typewriter from a museum in Catalonia:

#history #typography #youtube

I also want to warn you there will be no more positive things I say in this post.

When Cabel Sasser posted this on Bluesky in February…

…I experienced a little existential dread.

Now that I’ve experienced the dialog myself in Photoshop 2026, and a few other dialogs that have been upgraded toward what Adobe calls “modern user interface,” how did it fare?

These are 2025 windows and their 2026 equivalents:

On the surface, it feels like a lateral move. I do not personally find the new design language (Spectrum) attractive, or even particularly “modern.” The gestalt remains off and things are still generally misaligned – they’re just misaligned in net new ways.

But it was digging into the window below that showed all the problems in the still-wet foundations…

…and a lot of them have to do with focus.

1.
The first field is not focused, so you cannot start typing the number after opening this window. You need to immediately move your hand to the mouse.

2.
If you click on any field, the value is not pre-selected, so you cannot start typing a new number then.

A combination of both is rough in practice in repeated use, violating some of the basic things like this classic principle of interaction design:

Principle: Defaults within fields should be easy to “blow away”

When a user activates a field, the current entry should be auto-selected so that pressing Backspace/​Delete or starting to type will eliminate the current entry. Users can click within the field to deselect the whole, dropping the text pointer exactly where the user has clicked. The select-on-entry rule is generally followed today. (Sloppy coding, however, has resulted in the text cursor dropping at various unpredictable locations. )

3.
Clicking on parts of the input field doesn’t bring it into focus even though the hover state promises it. (Discrepancies between hover and focus handling are a horrible new thing I’m starting to see more in recent interfaces.)

4.
Simply backspacing through the field shows a crude error modal and – to add a second injury to the first injury – the dialog removes focus from the field!

5.
Tabbing now goes through “Pixels” menu on the way from Width to Height, making it harder to type width → press Tab → type height → press Enter, in a nice quick keyboard gesture.

I will recognize this is a tricky one, because it exposes a core tension with tabbing: some people use it for comprehensive keyboard access, but others want an accelerator “express train” with only relevant stops. However, macOS already has a “Keyboard navigation” setting for that – you can choose whether tabbing should go through all the controls, or only those you get to type in. Not only does Photoshop ignore that preference, but it’s inconsistent with itself – you can see that you cannot get to Anchor via tabbing anyway!

6.
Clicking on the “relative” checkbox or canvas extension color does not restore focus to last control like it used to.

7–∞.
There are tons of other transgressions. Some are downwind from focus; for example, undoing after moving a slider no longer works, because the ⌘Z keystroke is now swallowed by a UI element that doesn’t know what to do with it. Some are unrelated: Pull-downs are now of the slower kind, pressing ⌥P results in more blinking, and this tooltip below feels so cheap that I’m surprised it’s not a talking point of the current U.S. administration:

I am tired even just noticing all this. (What is that weird clump of pixels on the left of the bottom edge!? Did no one spot it before launch?)

So now what?

I generally avoid such harsh labels on this blog, but: this is awful work.

I’m angry. (Clearly.) We should all be angry in the face of stuff like this. This is how people get fed up with software – because it feels unstable and deteriorates on its own without needing to.

I know I brought up that an existing power user base can be a huge pain in the ass, and I am a decades-old Photoshop power user. But this is different than other examples where the product needs or at least wants to evolve past its core audience or toward a different market. For Photoshop here, nothing I see indicates any change in course or clientele – and yet all of these good moments in UI that used to help me out no longer exist.

Plus, all those transgressions are solved problems. Those issues are not buried in pages of heavily litigated patents, or in seven collective brains of world-class interface designers whose driveways are presently occupied by cash-filled trucks sent over by frontier companies. This isn’t some long lost art that requires archaeologists to decipher. This feels like carelessness and laziness in face of basic UI engineering; in a likely internally-motivated effort to refresh the interface, the team threw an entire nursery worth of babies with the bathwater.

It’s not just about disservice to craft. It’s not even about disrespect for change management, trivialization of institutional memory, and disinvestment in quality assurance. This isn’t only, in Tog’s words above, “sloppy coding.” This is also a failure of imagination. It’s not that hard to picture people spending 8+ hours a day going through these windows for years if not decades to come, and it’s not hard to add and multiply all of these microfrustrations into numbers that should make one pause. With these many paper cuts, you need to start thinking about establishing a blood bank. How can you expect people to use a professional tool effectively if you throw in so many roadblocks?

In an internally-motivated UI refresh like this, you not only need to meet users where they used to be, you also ideally have to give them more to cover for the pains of change. Sometimes that “more” is better storytelling – here, no one even tried to really sell me on the new interface – but ideally “more” means actual felt improvements. I’m not on the team, but it’s not that hard to imagine some of them:

• Change those annoying modals that announce typing errors into something lighter and more modern, like attached tooltips.
• Add more comprehensive equation support so e.g. I could type “660*2” like I can in increasingly more and more apps.
• Announce the invisible shortcuts that already exist, or add a few ones.
• Add a bit of memory/​stickiness to some options (like Use Legacy in the first window), so I don’t have to keep toggling them over and over again.

I started this post talking about a setting, and there is another setting in Photoshop, buried on the last page – you can turn off this “modern user interface” that feels so underbaked the moment you start actually using it. But is that a real solution to anything? Toggle it on and the existential dread comes back: Am I going to miss out on some good stuff? When is the hammer going to drop? It’s not a tax break, it’s only a tax extension.

Even this view above shows so little care, it would ordinarily deserve its own post.

#adobe #change management #details #interface design #popular

Thank you for all your feedback and bug reports in response to my call two weeks ago. Since then, I:

• revamped the image and video pipelines, which should make the blog load a lot faster and CPU/GPU struggle a lot less,
• improved inline video handling on the web, and in (some) RSS readers,
• made transparent videos work in Safari, and figured out how to make even better transparent videos,
• improved Friday newsletters so they have a link to a nice web view, and GIFs hinting at video content (alas, you cannot put videos straight in email),
• and generally made the site work better on older computers and phones.

If you see anything wrong or funny as a result of these changes – or any technical problem otherwise – please let me know (contact info is always in the footer). And, in general, please continue with your thoughts and feedback about content of the stuff I post, too! I’m enjoying hearing from you.

#about unsung

Decades ago, I used to work for a videogame magazine, but those days are long gone, and any videogame I play is a rare and intentional event.

Shadow Of The Colossus, the 2005 title directed by Fumito Ueda, felt so important to get to know that I had to borrow a PlayStation in order to play it, instead of waiting for a conversion (which never came; the game remains a PlayStation exclusive even today).

If you are not familiar with the title, I’m going to say little – the approach taken by the game, as well – and just point you toward the trailer for its remastered edition:

Boss Fight Books has been publishing books about videogames since the early 2010s, and “Shadow of the Colossus” by Nick Suttner is a book number 10 out of 40+.

The rather small and short volume is divided into chapters talking about each level of the game, one by one. But don’t let this discourage you – after all, recaps can be a literary art form. Here, every chapter goes on a side quest to talk about a larger component of the game or its backstory.

Having said that, the writing didn’t fully connect with me. Some of the tangents do not flow well, and the author’s choice to put himself in the book yields mixed results. In good moments, it’s wonderful to see someone’s passion for the game, but at times we’re also subjected to tenuous anecdotes about, for example, author’s beard, or his walks in San Francisco.

But the game! The game is definitely worth knowing more. It’s widely considered a masterpiece, a testament to choosing only a few things and doing them exceedingly well, a celebration of minimalism and deliberation, with so much – from world design to nuances of haptics – intently focused on creating the right ambiance to tell a story.

This might be strange to say, but I have this belief the rules of world building and care about atmosphere apply even to boring enterprise apps with stock UI elements. You’re still creating a universe and its set of principles, figuring out how to walk the user through it all via certain narrative beats, and – ideally! – thinking about all the small design decisions that will contribute – ideally! – to a consistent overarching tone.

The book occasionally peeks under the curtain to reveal design choices and details that could be inspiring to more than game designers: the control scheme, the fluid camera movement, intentional repetition of themes just to have them subverted, or the fascinating concept of “futile interactivity” (giving the player control even if the outcome is predetermined). What is interesting in particular are paths not taken: the initial idea of 48 monsters pared down to 16, or the multiplayer roots abandoned to focus on a linear, single-player experience.

(In a particularly brilliant decision, the creators took some of the unfinished levels and still put them in the game… as ruins.)

Is it a perfect book? No. But I’m glad I read it, and that writing about videogames in this form still exists – for a while, this was called “new games journalism” – and one way or another, it’s good to get closer to this strange beast of an AAA game with an indie game’s soul.

#above and beyond #book #book review #games #review #youtube

Interfaces of rhythm games (like Guitar Hero):

Windows startup sounds, incl. fun hi-def reimagining of their splash screens:

Windows error messages:

If this looks like fun, check out the rest of their work, including Windows 95 mobile and the art of blank VHS tape boxes.

#art #games #windows #youtube

Programmers’ fondness for dark mode was a result of decades of bad display technologies. The early CRTs were so awful, the burn-in risks so real, and the pixels so fuzzy and headache-inducing, that you wanted to see as little screen light up as possible – hence, defaulting to black background for everything computers did.

These challenges were there all the way through the 1980s, really, teaching generations of coders that computers meant light letters on dark backgrounds. Games moved away from being “in space” or “at night” as quickly as they could, text editing and spreadsheets went for paper-like livery soon after that, but programming never meaningfully existed on paper, and so the skeuomorphic pull wasn’t really there.

(Have you ever heard of a term “reverse video”? What’s kind of confusing about it is that its meaning was reversed around that time.)

AV professionals took a different route. They already had CRT calibration, gray walls, and monitor hoods so that light from outside wouldn’t contaminate content colors – and when computer UI started appearing on those CRTs, it was likewise best to keep it as dark and as neutral as possible.

Below are pictures of Avid Composer in 1990, Pixar’s Marionette/​RenderMan in 1995, and the first versions of Lightroom in 2006 where you can see the interface trying to at least gesture toward a dark theme:

Today, things are more flexible. Many people prefer one theme over the other for any of many legitimate reasons, most leave dark theming synced to daylight, and display technology can handle all themes so well that it jumped ahead of our brains, which still have some interesting asymmetries in processing light shapes next to dark ones.

As users celebrated dark mode appearing in popular apps and services in the 2010s, some had to catch up the other way: Apple TV added light mode (for some reason) in 2017, and Affinity apps celebrated new light UI option just earlier this year.

Most programming text editors still default to dark, but allow you to switch; as a software category they were probably the first to fully embrace color theming.

But what led me to writing this post was a delightful discovery today of this setting:

Why, of all apps, would iOS Photos allow you to switch to dark mode, and only while editing to boot?

I think this might be because of the above tradition of pro AV apps, where we learned it’s good for visuals to be surrounded by black; a little nod to its earlier professional roots – similar, perhaps, to the story of the Clear button in calculators.

But I had two more thoughts. First, for all the reasons above, to me at least dark mode still has connotations of “professionalism” and toggling the option makes me feel I’m a bad-ass pro whenever I’m editing a photo. I wonder if others also feel that way, too.

Second, dark mode looks different. Dark UI only when editing means it’s easier to spot whether I’m editing or just browsing, and be ever so slightly better oriented.

(In general, apps today are much more similar-looking, and I’m surprised neither iOS nor Android doesn’t allow you to switch the theme per app, just so it’s easier to know where you are as you move around quickly.)

#colors #dark mode #details #ios

However, at the same time renaming a file – or changing settings like file access – is not undoable. This is in part because we didn’t feel people would understand they could cancel out their rename this way (Safari too used to have “reopen last tab” under ⌘Z, until it reverted to Chrome’s ⌘⇧T), but mostly because you could accidentally undo through a file rename during regular work if you were not careful, without noticing, and that felt like it’d have more profound consequences.

In some ways, it helped me to think of these not as “ineligible for undo” but rather “living outside of time.” The moment a file is renamed, it will always have been named that way. (For the purposes of undo, at least. You can acknowledge anything you want on the version history screen.)

I’m not saying these are universally correct choices – as a matter of fact, some users find undoable selection (at least initially) pretty confusing! – but mostly sharing these as examples of intentional thinking about what deserves undo, and what should be exempt from it and taken care of elsewhere.

#details #flow #interface design #keyboard #undo

I don’t have personal experience with Retcon. I definitely struggled a lot with git’s syntax over the years, and have my own cheatsheet that looks similar to this.

But what I really liked from this page was the elevation of undo to be the North Star. I think it’s very, very well deserved.

To the best of my knowledge, undo in its modern form arrived in 1983 with Apple Lisa – Byte magazine called it a “tremendous security blanket” – and then over the next decade or so blossomed into its current state: an infinite, multi-level, lightning-fast safety hatch that works pretty much everywhere, always there in the bottom-left corner of your keyboard, so second-nature you might not even realize you’re invoking it.

In early apps, before undo arrived, you had to be very careful about what you did and when you saved your work. Later on, undo worked on just one level, so you had to think a lot about how to spend it before things became irreversible.

Today, undo just works. It truly became Back Space: The Next Generation.

But any user-facing “just works” hand wave means a lot of people’s hard and invisible work behind the scenes. So if you’re reading this, and at some point in your career you worked on making undo better, my tip of the hat to you (and send me a message!).

#errors #interface design #maintenance #undo

Here’s the logic of the game:

• If you fall from height, you receive fall damage.
• If you fall from height but you’re in a boat, there’s no fall damage.
• If you fall from height and you’re in a boat, but you fall from a distance of 12, 13, 49, 51, 111, 114, 198, 202, 310 or 315 blocks, there is fall damage and you die.

The first is common in games.

The second is – I believe! – a former bug that was grandfathered in as a design decision: people got used to it, started relying on it, and it became “too big to fix.” The retroactive explanation became that the boat is your shield and takes all the fall damage, which is a very Hollywood action movie way of looking at the world.

So, only the third one is a bug… obviously.

But why those specific numbers? Here’s a 16-minute video by Matt Parker at Stand-up Maths that tries to answer it:

It’s an interesting video because it’s lighter on bug causes discussion, but heavier on math – and the moment you realize those numbers above are not random at all and coalesce into a nice formula, is genuinely a pretty fun moment.

I thought this was interesting, and a little contribution to a larger debate about how hard it is to even agree what a bug really is (which I previously briefly talked about).

#bugs #games #youtube

• Mockdown – works immediately on the web, even on mobile
• Wiretext – works on the web, but desktop only
• Monodraw – a Mac app

I believe these are used by people who prefer intentionally limited visual choices, for low-key diagramming to put in source code, and – increasingly – as an entry point to gen AI.

They’re so interesting from the standpoint of this blog:

• Fun to see a contemporary take on something that peaked between 1970s–1980s – you can look up TUIs and Turbo Vision if you want – but (just like Mario the other day) now with modern sensibilities, performance, web access, mouse and trackpad affordances, and so on.
• It’s interesting simply as an exercise in constraint. I believe constraint practice will become more and more important as computers become more and more capable. It’s already useful to constrain yourself in order to make things easier for you. With the rise of AI, self-constraint will become important to make things harder, as well.
• There is a certain power and longevity of monospace plain text that’s worth celebrating – not just because the file format is portable, but because text editing as interface is so well-known and potent.

Also, ASCII spray in Mockdown is just really fun:

(Caveat: These tools are “ASCII” in a colloquial sense, the same way people use “GIF” to refer to a certain category of looping animations.)

#graphics #text editing

On some technical level, the options made sense: “Abort” would stop whatever you were doing, “Retry” would try to repeat the action, and “Ignore” would proceed as if there was no error. But in the heat of a moment, or seeing it for the first time, this was a puzzling choice to be asked to make. Not only were the words weighted improperly (the seemingly most innocuous action here, “Ignore,” was actually the only one that could do actual lasting damage), but it also wasn’t entirely clear what’s the safe thing to do to get out of the situation.

(The redesign of “Abort, Retry, Ignore” was “Abort, Retry, Fail,” and it wasn’t really a huge improvement.)

Last night, I installed Google Photos on my iPhone, and the first message that greeted me was this:

This is really a matryoshka doll of bad dialog presentation.

First: any buttons in a dialog should be labeled with enough information to keep me going. Here, both have generic labels, so now I need to pay attention.

Second: Even after reading, I have no idea what is the choice I’m making. I see the pathway marked “yes, keep it the way I had it” and, sure – this would be generally what I want from any given computer on any given Sunday. But what’s the actual alternative?

But the third, and most important one, is this: this dialog has no safe escape hatch. By now, in UX design, we established quite a few canonical escape hatches:

• a Cancel button,
• a × close box,
• a “No, thanks” link,
• a press of an Escape key.

But you can’t × this dialog out. The main button seems positive, but it also feels like I’m taking an action with consequences, and I don’t want to deal with that. There is a “No, thanks,” but it doesn’t feel like the other “No, thankses” I have seen – it’s juxtaposed with copy that makes it seem… a dangerous thing to choose.

And this last bit makes it a pretty serious design offense, because you are now messing with foundational stuff. You need to protect those escape hatches for the future; the moment you introduce hesitation into the mix and taint “No, thanks” as a concept, really bad things will start happening all across your product.

In real life, fire doors have to open outwards when pushed with body weight, aircraft stick shakers are impossible to ignore, and anti-lock braking systems do smart things even after your brain turns off its smart parts.

I know seeing a dialog like this would never happen in a moment of true panic, but sometimes I think of the user in their most absent-minded moment: trying to get their kids to hurry up for school, on hold with an annoying cable provider, with a cat looking like it’s about to jump up directly into a running toaster. A dialog on their phone pops up. If that dialog absolutely has to happen, what is the escape hatch it can offer so they can dismiss it safely if they cannot think about it at all?

This Google Photos screen needs a lot more rethinking and rewriting, but in its current incarnation, it desperately needs a clear and trustworthy escape hatch I can tap absentmindedly, just so I can get to my photos.

#errors #google #onboarding #writing

What I liked about it is that it’s wrestling with the idea “How do you improve on something considered perfect?” and touches upon the important area we cover occasionally here on this blog: when is software finished?

There is also another interesting angle. Even though the game requires original game ROMs to work, it’s still in a very, very gray area:

[…] Once you strip it down, this thing is built around Nintendo’s world: the Super Mario Bros. name, the characters, the visual identity, the level concepts, the branding, the whole presentation. And the more ambitious it gets, the riskier it feels. Once a fan project starts offering not just a remake, but extra modes, editor tools, custom-level browsing, ratings, and a growing user-generated content scene, it stops looking like a small tribute and starts looking like something operating in Nintendo’s lane.

(I didn’t expect to see the original Super Mario game to come up so often on this blog – I just added a tag for it – especially since I don’t have any personal reverence for it. But it seems it’s Super Mario and Doom specifically that became timeless pieces of software that keep being resurrected, revisited, and remixed, over and over again.)

#games #piracy #software evolution #super mario bros #youtube

The messing-with-the-user part is, ostensibly, for their benefit. Making something not appear in the usual position, or not behave the usual way, becomes a speed bump, cancels out motor memory, and forces a conscious reaction rather than flying through the interface on autopilot.

The simplest example is dialogs that ask about dangerous actions suspending the “default action happens when you press Enter” behaviour:

(There is a way to continue the dialog on the right using the keyboard alone – but it’s only via ⌘R and not the default, breezy Enter.)

Another version is swapping buttons or showing them in an otherwise unusual order:

But remember when I said “can only happen in onscreen interfaces?” Well. The apotheosis of this very idea, spotted in a New York alley, proves otherwise:

It’s a Hirsch ScramblePad, inconsistent very much by design, a login mechanism where every time the digits get put in a different place.

The idea is meant to help with two problems:

• It makes it harder for someone standing behind to learn your code from just watching your movements, as it abstracts the movements to be one step away. (The strange visual filter is meant to make the viewing angle as narrow as possible, too.)
• It prevents uneven wear and tear of the buttons, which people could use to guess your code:

I understand “ScramblePad” was the original product (here’s the patent with some nice illustrations), and the name got genericized since. Here’s competition, MIWA Random Tenkey – once probably so much more futuristic, today equally quaint:

One can occasionally see more modern versions today:

But back to our beloved screens, where some banking web apps copied the idea:

And even recently, Motorola touted it as a feature on their phones:

I’m not a security expert, so I won’t try to opine how effective those things are. I tried to research whether forcing a password out of motor memory – which these will accomplish – is ultimately better or worse, but a lot of the papers I found were inconclusive. (As always, some of the theoretically good ideas for security bounce off of human limitations and convenience: Forcing someone to remember a password might mean they will write it down somewhere, effectively making things worse.)

#interface design #security

I shared one example previously, and here’s five more.

1.
My bank’s website not only shows me the last payment I made, but also allows me to click to use the same number again:

2.
The app Transit has a nice list of recent destinations just below the main options:

3.
Google Maps promotes recently tapped-on items to be more visible than they would normally be:

4.
CleanShot X offers something I have always wanted from built-in macOS screenshotting – being able to capture with one keystroke the same area as I delineated last time:

5.
Google Pixel allows you to swap the current wallpaper and three previously chosen wallpapers easily:

What unifies all of these is that “recent” doesn’t live in a submenu somewhere, treated as a second-tier pathway. No, in all of these “recent” is embedded in the fabric of normal interactions, side by side with forward-facing options. I believe this is necessary for any sort of feature like this to be truly successful.

That last Google Pixel example also shows that “recent” isn’t only for repeating something faster – here, it becomes more of a “soft setting,” without introducing a lot more complex UI and interactions that a “real” setting might require.

#complexity #definitions #flow #interface design

But you still need to flail your fingers in vaguely realistic ways, so the actors in this (spoiler-free) TikTok share their strategies:

#keyboard

Have you ever seen this problem?

The screenshot on the left is fine. But there is something wrong with the one on the right. In light mode, the shadow is wispy and weird. In dark mode, things are even stranger, and the shadow is almost… a glow?

I stumbled upon this problem occasionally for years now – there are a few screenshots on the blog with this weird problem, even – but it was never feeling like a deal breaker. However, I finally sat down to figure it out today.

Turns out, there are two kinds of approaches to alpha channel/​transparency. The normal one we all know well is called “straight alpha.” But on the right, we were looking at “premultiplied alpha” – something entirely more complicated, where the background is baked into transparency for… reasons. Premultiplied alpha is conceptually – and often literally – dirtier, but it also has benefits: more flexibility, better filtering, sometimes better performance. As far as I understand, premultiplied alpha exists primarily in the world of video and vfx, but occasionally it rears its unconventionally attractive head in our boring static 2D world of screenshots, too.

In my case, I finally figured out this was happening whenever I’ve pasted the screenshot from the clipboard to Photoshop instead of Preview – for some reason, a screenshot then got an alpha channel premultiplied against white background. But I wouldn’t be surprised if it happens to some of you under other conditions, too.

So, “premultiplied alpha.” That’s the useful phrase. What was the other thing?

This is an absolutely hilarious 7-minute video by Captain Disillusion that talks about various challenges with the alpha channel:

Captain Disillusion (or, Alan Melikdjanian) is one of my favourite YouTube educators. His work is mostly debunking fake videos – his most well-known one is about the Cricet bracelet, although my personal fav is one about laminar flow – and they’re just constantly interesting and hilarious at the same time.

Disillusion also occasionally does a more straightforward “let’s talk about some technical aspects of video production” episode which he bundles under a “CD/” umbrella. Here’s a handy list of all of them:

• Intro to the whole series
• Aspect ratio
• Frame rate
• Resolution
• Interlacing (and addendum)
• Color
• Alpha channel
• Shutter speed
• Blur

I am sharing this list because you should watch them all. Most are <10minutes, they are consistently entertaining, and even though none of them are about UX design, there is enough overlap between the two universes that you will come out of it all a lot smarter.

Pragmatically, in my case, I searched for [premultiplied alpha] + [Photoshop] and quickly learned of a new-to-me menu option: Layer > Matting > Remove White Matte. It turns premultiplied alpha back to straight alpha, and fixes the screenshot.

Non-pragmatically? If you want to really understand premultiplied alpha, the last thing I can do is suggest another great internet educator, Bartosz Ciechanowski, who has a more comprehensive interactive web explainer. There will be math. There will also be sliders. You decide.

#graphics #humor #youtube

I moved Keyboard Maestro app to a different folder as it was running. I gather there must be some technical reason for the app to have to be power cycled, so I appreciated this warning, and the thoughtful bit of copywriting: “Continue” is caveated with “not recommended” so that you feel more comfortable choosing “Quit,” usually the less safe choice. I thought it was a good attempt to add the right scent to the strange options at a strange moment.

(This tradition has reportedly been started by a software company Rogue Amoeba, which wrote about it in 2019.)

#errors #got your back #writing

…and I am going out of my way to try various new shortcuts and automations, big and small, just so I can write a helpful article.

In Photoshop, one of the classic dialogs I use a lot when scanning things is brightness + contrast:

It doesn’t come with a keyboard shortcut, so I mnemonically assigned ⌘B (for Brightness) to it. ⌘B is easier than using your mouse to select a menu option, but still tedious in the long run; every time I have to input brightness and contrast numbers, then click on Use Legacy which is not sticky, then realize that enabling Use Legacy inexplicably resets the values I just typed so I have to input them again…

…which really isn’t as much fun 20th time in a row, 20th year in a row.

So imagine my surprise when one day I invoked the dialog, and it came up looking this out of the box:

It somehow remembered the previous settings. How? Why? Was that a new thing? Was that a bug? Did the stars align or did they misalign? Figuring out how to make it do this every time would have save me so much trouble.

I dug deeper and figured it out. On the way to ⌘B, my fingers grazed the ⌥ key. This invoked a “use same settings as last time” option I never knew existed. This option would have been a lifesaver, has been there for god knows how long, and I just discovered it by accident. Moreover, it wasn’t just a feature of this dialog. One can hold ⌥ for many more Photoshop dialogs – a thoughtful system to make repeated tasks faster.

Damn.

This reminds me of something. I am curious if you’ve seen what I’ve witnessed probably ten times by now: once in a while my corner of the internet overflowing with awe when someone shares that on the iPhone, you can hold the spacebar and it functions as cursor control:

Inevitably, tons of people are always amazed and excited, proclaiming this is the best thing since sliced silicon wafers…

…and that always make me a little sad inside. Both this and my ⌥ story feel like failures of onboarding, of software growing with you and sharing its motor-memory nooks and power-usery crannies. If a helpful thing exists, but people don’t know about it, it feels worse than it not existing. Imagine all these interactions made more pleasant, all these hours saved, all these flow states undisturbed.

I want to spend more time on this blog highlighting onboarding and conveyance done well – I just shared a tiny example a few days ago – particularly since this feels to me like an area underinvested in. If you have a story of an app or a service doing this well, I’d love if you could share it with me so I can highlight it and we can learn from it.

#keyboard #onboarding

The answer? They don’t really have a choice:

“[Steven Troughton-Smith:] Review prompts are the difference between a great app getting five positive reviews, and thousands of positive reviews. […]”

You have to play the game as the game stands, and Apple controls the game. And in the game as it stands, apps need 5-star reviews to gain traction in the App Store, perhaps especially so for apps in crowded categories. And for most apps, the only way to achieve that is through prompting. But the right thing to do, for the user experience in the app, is never to prompt for reviews.

I think it’s worth knowing about stuff like this for another reason. Absent understanding or institutional memory, any exception gets normalized and ceases being an exception. If specifically iOS apps have to do this for reasons explained in the post, this is still not an excuse for web apps or websites to indiscriminately pester people with prompts like these, too.

#attention

This pairs nicely with a previous post on Unsung in that it too actively investigates what makes for useful, not just “pretty” color coding.

#coding #colors

raycast://confetti

This is what it does:

Despite it being a confetti cannon and nothing more, I think it goes deeper than stuff like e.g. Asana’s “celebration creatures”, and it deserves recognition for three actually kinda serious reasons:

• You can use it to quickly test whether you’re wiring deeplinks correctly. It’s clever the Raycast team put it at the beginning of the doc page; I think every API or a complex connection method should have a simple and delightful “success scenario” for two reasons: to celebrate you establishing that connection, and to have something so simple it cannot itself be misbehaving (this way you know that if you can’t get confetti to work, you for sure messed up something elsewhere).
• Once you know how to invoke it from far away, it’s also great for testing other things. Sounds can be muted. In JavaScript, console.log() can be too buried if you don’t have a console open or visible, and alert("Test") is kind of depressingly old-school and steals focus. This HUD-like thing feels like a modern way of approaching this: You know you’ll notice it when it fires away, and it will leave no lasting damage. (Okay, fair, it does steal focus too, so that’d be one thing to improve.)
• It has great production value. I hate perhaps all of Google’s search easter eggs because they’re built so extremely cheaply – try searching for “do a barrel roll” or “askew” (and no, I’m not going to dignify them with links because links are my love language). It’s rare and worth celebrating when something that could very well be an internal joke or a test feature for nerds is actually something you want to use because it’s so well-made. (See also: Linear’s internal testing UI.)

#above and beyond #coding #easter eggs #internal ui #raycast

This reminded me that the classic Ctrl+Alt+Del shortcut was initially Ctrl+Alt+Esc. Except, people apparently invoked it a bit too often by accident, so it was split to require two hands for extra safety.

When you look at the keyboard for the original PC, it all makes sense. Esc is at the edge of the main typing block, and in line with all the modifier keys. It would make sense to build a system around this, and it’s interesting to imagine the Esc Kinematic Universe that never happened.

Don’t get me wrong: I think it’s good that it didn’t. ⌘Z or Ctrl+Z are much easier to get to than Shift+Esc, especially in concert with cut/copy/​paste next door – that system introduced by Apple Lisa and Mac teams deserves endless trophies and infinite accolades. (In case you are curious, Windows 1.0 used Delete for Cut, Insert for Paste, and… F2 for Copy.)

But it has always been peculiar to me that Esc isn’t seeing more use. I see Backspace tasked with all sorts of modifier key combinations in various apps, but Esc – equally available on the other side, and even easier to target on some keyboards – is often left alone.

Poetically, given the beginning of this story, it was Mac that grabbed ⌘⌥Esc for force quit:

There is a nice thoughtful design element in that window that’s worth calling out: the hint line the bottom.

Why, of all places, would this window go out of its way to announce its own shortcut after you already figured out how to open it? I think this might be for a similar reason airlines repeat the safety announcements before every takeoff. If your computer goes haywire, if one of your apps starts hogging resources, if the UI slows down so much any action takes forever, it might benefit you if somewhere in the back of your head exists one small bit of information: “ah yeah, I don’t know how I know this, but I think I’m supposed to press ⌘⌥Esc now.”

#errors #history #keyboard #onboarding

The 1950s and 1960s computers were so sluggish that their consoles with blinking lights were not just for show; the operations were slow enough that you could still follow the lights in real time.

This ceased to be true soon afterwards. The microcomputer revolution temporarily reset some computing progress, but by the 1980s and 1990s more and more things were happening too fast for us to keep up.

But here (this above is Paint in Windows 1.0, and you can try for yourself in a browser!) was one example where you could still see an algorithm working hard. It was mesmerizing and educational, and it was a rare example where perhaps you didn’t mind the computer taking its sweet time. Even messing up like I did above – maybe especially messing up – ended up fascinating to watch.

Wikipedia has examples of a few different flood fill algorithms, which are even more interesting:

A few years later, Minesweeper had a very memorable flood fill, too (also available in a web emulator today):

But by now Minesweeper retired from sweeping mines, and today computers are so fast that it’s hard for me to imagine any flood fill being anything else but flash flood…

…except this is what I just saw in Pixelmator on my Mac:

I don’t know if this is a nod toward a classic flood fill, or just a nice unrelated transition. But I found it genuinely delightful, and it’s fast enough that I would imagine it doesn’t bother pros who need to do it often.

Sometimes it’s nice to see a computer working when there’s a good reason; some apps like banking apps even insert artificial, visible delays after crucial operations, just so that the users feel comfortable knowing their important transaction went through.

But sometimes it’s nice to see a computer working for no reason at all.

#above and beyond #graphics #loading states

It’s one of the oldest web design principles. Tim Berners-Lee wrote about it in 1992; if you visit this link right now, it might be the oldest page you will have ever visited.

The gist of it is simple: the mechanics of following a link are not important, and should be replaced by something that can make the link stand on its own. This is important for screen readers, but also for basic scannability: a “click here” label has a lousy scent and requires you to take in the surroundings to understand what it really does. The rule is, in effect, a variant of “show, don’t tell.”

(In modern days, you can also add another transgression: on touch devices one cannot click, but only tap.)

There is a similar rule about button copy design. Button labels, too, should be self-sustainable. Below is a good example (just reading the button lets me understand what I’ll achieve by clicking it), juxtaposed with the bad one (“OK” is so generic you have to read the rest of the window).

Earlier this week, I was passing some train cars on my coffee walk, and saw this bit of UI:

Why are these okay, and “click here” is not? Here’s why, I think: Yes, the ultimate goal is to move a train car, or empty it, or send it on its way. But here, the mechanics matter, too. They’re dangerous. They require preparations. No one says “I’m going to open my laptop and start clicking on links,” but I imagine people say “we have to jack this car” or “we need to lift it.” Even “here” has depth: these are specific tool mounting points. Choosing the wrong “here” will have consequences.

But, going back to the web, avoiding “click here” in strings isn’t always easy. Imagine trying to put a link in the sentence “To change your avatar, visit the profile page.” I’m personally never sure how to linkify it well:

To change your avatar, visit the profile page.
To change your avatar, visit the profile page.
To change your avatar, visit the profile page.

Linking “change your avatar” seems correct since it points to the eventual outcome, but then it leaves the actual destination dangling and unlinked – like putting an accent on a wrong syllable. “Visit the profile page” is better than “click here,” but it’s still not scannable. Linking the entire sentence seems strange and complicated to me, and I also disagree with Tim Berners-Lee, who on the page I liked to above seems to suggest this should be…

To change your avatar, visit the profile page.

…just because this might make a user think there are two separate destinations and actions, and contribute a wrong mental model.

You could, of course, simplify this to “Change your avatar,” but while that would work in a UI string, it wouldn’t within a larger paragraph of text, or a blog post.

#details #flow #popular #web

Now that I published 250 posts since early December, what better way to celebrate than to ask for feedback?

• Do you enjoy specific kinds of content, or missing some topics?
• How could I make the visuals and interactions better?
• Any fun little ideas or bugs or improvements I could make?
• Any feedback about this blog’s information architecture (including the just-added tags), RSS, or the weekly email?

You can reach me via email, on Mastodon, or on Bluesky.

If the very idea stresses you out, I want to give you permission to send me just your bit of feedback without any greetings, or small talk, or “compliment sandwiching.”

Thank you in advance!

#about unsung

I thought I’d share a few of the small design details I am proud of for this small blog!

1.
After years of being annoyed at Slack for mishandling image sizes, it was important for me to show the screenshots (at least the desktop UI) at their 100% precise size, if possible. I think that helps to get a better sense of a scale and feel of things. This was harder than I expected (since I still want images not to grow too wide or too tall), but hopefully works well now.

2.
I wrote some extra code so that if an image has edge transparency or even soft shadows, it will be aligned accounting for all that. I think that feels elegant – especially on a blog that practices asymmetry probably to a fault.

3.
If the images or videos blend too much into the background, they get a lil border to separate them – but only in light or dark mode as needed. This is so that the whole page rhythm holds better together. (Manually assigned so far. Would be curious if one can make this automatic.)

4.
Speaking of dark mode, I almost figured out how to make videos with transparent pixels so that they look good in both dark and light mode. (Chrome only. Still working on it for Safari.)

5
I want autoplay videos (without sound!) so that it’s easier to see interaction design – basically, a modern version of what GIFs used to provide. This has been challenging and required adding some JavaScript, and is still not done! But it’s starting to feel nice.

6.
Given all the quotations I do, I added hanging quotes to text. Wildly, they are still not really supported by CSS (Safari is a sole exception), so that required some manual intervention.

7.
Short lists are (automatically) spaced differently than long lists. I’ve always wanted to try that.

8.
I’m having a blast with the pixel fonts I recreated from PC/GEOS. I keep adjusting the glyphs, adding kerning pairs, etc. It’s fun to keep improving a font as you’re improving its surroundings; I just redrew the @ glyph you can see above!

9.
It’s a bit old-fashioned, but I still like the idea of visited links being styled differently than non-visited links, to help you orient yourself. (Linking feels very important to me.)

#about unsung #details

At Unsung’s 250-postiversary, if I reflect on where this blog has been, and where it might be going, this is what comes to my mind. I didn’t start the project by writing all this down, but I held a lot of this in my head. This feels like a nice moment to capture all this more deliberately, and perhaps some of you might find it interesting.

Goals of Unsung:

• Highlight hard, good, invisible design work that makes things better, but doesn’t often get spotlight.
• Find deeper meaning in craft, past the pretentious platitudes and surface-level delight. (Details matter not just in some abstract “craftsmanship” sense.)
• Help expand what craft means: highlight relations between things, show connections between history and present, talk about things that are hard to describe and impossible to measure.
• Revel in being pragmatic. Share useful things, not just hollow inspiration.
• Be fun to read.
• DIRECTIVE 6: CLASSIFIED_

Higher-level principles for this blog:

• Don’t ever share boring stuff, even if the concepts are good, or out of completeness. If you’re not enjoying reading or watching something, assume the audience won’t either. (You can occasionally salvage something boring by providing a non-boring commentary, but try to use this sparingly.)
• When you share something, always try to add your perspective or connections. At the very least, excerpt the most useful thing. This blog is QT, not RT.
• Find a good balance between positive and negative examples.
• In general, offer variety. The weekly digest should have both depth and breadth. (For the last two points, I made a little dashboard to give me some insight, although the sentiment analysis there right now is pretty worthless.)
• Be opinionated, but also humble and curious. You don’t know everything.
• Be candid, but not cruel. Punch up, not down.
• Avoid ridiculing, “walls of shame,” and so on. Even if the work you share is horrible, turn it into a lesson or two.
• This is not about people, but about work – except in some occasions it might be about people, so be candid when that happens.
• More links is better than fewer. Good linking rewards curiosity and is a form of curation (example 1, 2, 3). However, the post should stand on its own even if one doesn’t follow any of the links.
• Make an effort to showcase work by women, people of color, underrepresented minorities, and so on.
• Visuals are engaging and helpful. Think about them, but do not add gratuitous, irrelevant photos just to meet the quota (example 1, 2, 3).
• The best way to teach something general is to show something specific.

Lower-level principles:

• Credit people by full name.
• For longer videos, offer their duration to make it easy for people to make decisions about when they want to watch them.
• Avoid linking to X and Substack. (It really breaks my heart how much of the design community still supports particularly the former, given all the damage we know X inflicts on society.)
• Don’t use this blog as an example (e.g. by screenshots of itself), as this is generally confusing.

Personal goals:

• Practice writing things that do count in less than thousands of words.
• Do things differently – this blog is authored in Apple Notes, for example, which is kinda weird to a person like me who always writes straight in HTML.
• Have fun and learn working on this (completely custom) blog platform on the side.
• Give back some of what I learned in my career over the years.
• Practice stating my opinions and standing by them.
• Learn new things (about what I’m writing and about publishing on the web); the only way to teach something is to understand it yourself first.

#about unsung

This episode about the Western Electric 500 – the canonical American landline rotary phone – is worth watching by all UX designers. There is no software here, as the phone is entirely electromechanical. But there are a whole lot of details to admire and be inspired by: the shape of the handset, the interface to change the volume, the iconic ring, the balanced and improved rotary dial, the behaviour of the cable, even the weight and balance of the whole device.

It’s not only that phone calls should all sound as good as they did in the 1950s – in my experience FaceTime Audio comes close, sometimes, but it’s so unreliable – it’s that you should try to play with a Western Electric 500 because you want your modern interface to feel like that.

The hosts – David Pierce and Nilay Patel, helped by Tim Wu, author of the excellent The Master Switch – also weave into it an entirely different angle, of how that phone fit into (and reflected) a specific period of American tech history, and how it related to AT&T’s then monopoly, including the phone jack and third-party access we just discussed re: John Deere. Even the discussion whether this is or isn’t a “hall of fame” object is good fodder for thought.

The episode – and the entire show – is also just a really enjoyable watch. If you like this ep, it pairs nicely with the one about the iPhone 4, another phone that transcended its origins through good industrial design, exactly sixty years later.

#ergonomics #history #real world #youtube

But when actually indicating an intention to turn, people started realizing what happens when you have two types of mapping fight each other:

On one hand, the left-turn indicator was on the customary left side. On the other, the light looked like an arrow – and the arrow was pointing to the right.

I don’t know how many people were actually confused by it, but it made for a few spicy pieces with “stupidest turn signal ever” and “most annoying thing” in their titles. The company’s official response was:

Mini has chosen the Union Jack lights to highlight Mini’s British heritage, and has been using them for a while. With regard to the turn indicator light pattern, there should be no trouble at all for a driver to understand, when seeing the full rear of the car, which direction is being indicated.

Mini has not heard any concerns from customers regarding the rear turn indicators, and has in fact received positive feedback about the taillight design.

It didn’t help that one of the worst cars this side of the Cybertruck did something similar in the 1950s:

Drama aside, I did agree with this commenter (emphasis mine):

It doesn’t cause massive confusion, but taillights should cause no confusion for anyone.

I can think of one modern version of a similar issue. If you use the iPad in landscape mode, the volume buttons seem to go “the wrong way”:

Is this anything? Probably not. I imagine it’s better to be consistent and allow motor memory to develop between all the iPad orientations, and throw in the iPhones, too. But if you only ever use your iPad in landscape, this might feel, perhaps, like “the stupidest volume controls ever.”

Oh, and the subsequent Mini revamp in 2024 solved the issue by making the turn signals less like arrows:

#details #popular #real world

It handles file dropping so thoughtfully, it’s worth pausing and recognizing it:

Here’s what’s great about it:

• You can drop the file anywhere. There is no designated small drop area like in some other apps; every last pixel of the window is ready to receive your file, so you can drop without worrying.
• You get a hover state confirming you are safe to drop.
• You can drop the file on other screens, too!

Why is all this important? Because dropping a file into a browser is a notoriously frustrating experience. If the tab doesn’t claim the file, left to its own devices the browser will do anything from replacing the current tab with the contents of the file, through opening a new tab, to… starting to download the file you just dropped and ask you for its new location!

It is frustrating when a failure mode of an action is not just that action failing – already here, repeating a drag is more work than e.g. repeating a keystroke – but also you having to do extra clean-up steps.

Wakamaifondue gets this right, and allowing to drop a file on any screen in particular is very thoughtful. Your cursor holding a file indicates your intentions rather strongly – when you see a person wearing a wedding dress, you don’t think “I wonder what they’re up to today?” – so there should be no need to switch to a certain mode or to navigate to an “import screen” beforehand.

#details #flow #interface design #mouse

I didn’t know about most of these, so I did some googling and created a list for reference:

• Mortal Kombat: Johnny Cage two uppercuts fatality
• Madden NLF ’15: Christian Kirksey reduced to 1′2″ height
• Final Fantasy 6: Sabin suplexing a train
• Tiger Woods PGA Tour ’08: Tiger Woods walking on water
• Hitman 2: Heat-seeking briefcase
• Street Fighter II: Guile’s “handcuffs” glitch
• Super Mario Maker: Weird mushroom Mario

Off the top of my head, I cannot think of any non-videogame software that received a similar “bugs as lore” treatment from people responsible for the bug in the first place.

Microsoft made a blue-screen-of-death screensaver, but it was originally third-party, and kind of a prank? A mean-spirited one? I didn’t find this particularly good.

The likely second-most-famous error message, the fail whale, transcended Twitter and was even referenced in other products…

…but as far as I understand Twitter the company was itself embarrassed by it, and eventually switched the whale to a caterpillar.

(Those two examples aren’t really even bugs in the same category as those in the video, anyway.)

#bugs #easter eggs #games #youtube

Below the actions to close the tab, and close all other tabs, Chrome has a specific version called Close Tabs To The Right:

In After Effects, next to typical save options, there is this – Increment And Save – which saves a file and changes the number at the end to be one notch higher (Project 2 → Project 3, and so on):

I’m mildly fascinated by these strangely specific accelerators.

The one in the camera is genuinely useful. Photo projects are often day-long affairs where you download the photos at the end of workday, but might still keep them on the card just in case. Allowing to quickly delete a day’s worth of photos makes a lot of sense, saving you from having to go through them one by one in an interface not suited for that kind of operation.

Chrome’s “Close Tabs to the Right” takes a bit of figuring out, but I believe it’s meant to make it easy to clean up after a fruitful research session where you kept ⌘-clicking and opening tabs to learn more, and those tabs now fulfilled their purpose. (Curiously, Firefox also has “Close Tabs To Left” which I don’t understand.)

After Effects’s “Increment and Save” is… I don’t know. Maybe it’s cheap? Maybe it’s honest? A proper version history would be nicer, but that’s a tall order. This is simple and, most importantly, reliable. I still often do the “poor man’s version control” elsewhere…

…so this works for me.

It’s always interesting to me to think whether these kinds of oddly-specific examples are nice gestures toward the user, or treating symptoms in lieu of fixing actual problems. Either way, I don’t think an interface can survive too many of these, as their obscurity and weirdness add up and can contaminate the entire UI.

Would love if you sent me more of these kinds of commands from the apps you use!

#complexity #details #flow #interface design

While I am sympathetic to the notion that sound pollution is a thing we need to be concerned with, the choice between silence and sound pollution is a false choice. There’s a lot of those happening these days, probably because we’re so stuck in binary thinking. But as airplanes show us, we can design sounds which aren’t obtrusive, but which are helpful. And when you get yourself out of binary thinking, you can do things like make your most obnoxious apps be silent while your important ones make themselves known, and in ways which are meaningful to you and pleasant to everyone else.

It is an interesting parallel to the post about syntax highlighting from a while back, and one of the posts about cartography design I shared recently; they all explore how you can create a richer space capable of conveying more information without overwhelming people, by being intentional about the design.

#attention #complexity #real world #sound design #youtube

Turn on the zoom gesture from a few weeks ago, and you can see the challenge. The gridlines are ½ logical pixel and 1 physical pixel wide:

This limitation is inherited by most tools: Photoshop, Affinity, xScope, even the built-in Digital Color Meter. It’s not the end of the world, of course, but it can be maddening if you are trying to sample a color from a “half pixel” and the cursor stubbornly skips it no matter how delicately you move. Here it is in Figma:

Of the few tools I tested, only Pixelmator allows to sample at the correct, precise level:

I was curious how would a truly precise cursor feel in general – would there be any disadvantages? – so I built a little simulator that allows a regular arrow cursor to be aligned to “half pixels” or “retina pixels.”

In the process, I discovered that both Chrome and Firefox already receive sub-traditional-pixel measurements for mousing events, so this was even easier to build than I expected. Now, precise targeting in Chrome and Firefox becomes possible:

I don’t personally see any big difference in terms of either upsides or downsides, and I’m curious if you do. iPadOS and its Safari already seem to support the precise mouse pointer, too. That makes me curious: why isn’t it available in macOS? I imagine you could even turn it on by default for apps – or, if you want to be more conservative, make it opt-in.

Pixelmator also shows that the apps can do it without waiting for macOS as the data is already there; they would just need to render the cursor on their own with more precision.

#apple #details #flow #mouse

Deere is one of many companies that practice “VIN-locking,” a practice that comes from the automotive industry (“VIN” stands for “vehicle identification number,” the unique serial number that every automotive manufacturer stamps onto the engine block and, these days, encodes in the car’s onboard computers).

VIN locks began in car-engines. Auto manufacturers started to put cheap microcontrollers into engine components and subcomponents. A mechanic could swap in a new part, but the engine wouldn’t recognize it — and the car wouldn’t drive — until an authorized technician entered an unlock code into a special tool connected to the car’s internal network.

Big Car sold this as a safety measure, to prevent unscrupulous mechanics from installing inferior refurbished or third-party parts in unsuspecting drivers’ cars. But the real goal was eliminating the independent car repair sector, and the third-party parts industry, allowing car manufacturers to monopolize the repair and parts revenues, charging whatever the traffic would bear (literally).

The same tactic was used by John Deere, forcing farmers to hack the tractors they purchased just so they could repair them.

In a decision that bolsters right-to-repair movement, John Deere and farmers reached a settlement that has the company pay $99 million to repay prior inflated repair costs, and requires it to share software required for maintenance and repair with farmers.

Just because I was curious and you might be also, here’s an example of a modern tractor interface:

The story reminded me of an ongoing battle in Poland where a train manufacturer Newag used VIN locking and coupled it with GPS hardcoding in an even more brazen attempt to prevent third-party repair: if a train spent too much time at a location of another train repair company, it’d simply stop running – not by some hardware fault, but by a simple if condition in code.

“This is quite a peculiar part of the story—when SPS was unable to start the trains and almost gave up on their servicing, someone from the workshop typed “polscy hakerzy” (“Polish hackers”) into Google,” the team from Dragon Sector, made up of Jakub Stępniewicz, Sergiusz Bazański, and Michał Kowalczyk, told me in an email. “Dragon Sector popped up and soon after we received an email asking for help.”

The (white-hat) hackers helped unbrick the train, but since European law is stricter on DRM, the case gets murkier. The article above is from 2023, and contains this quote:

Newag said that they will sue us, but we doubt they will - their defense line is really poor and they would have no chance defending it, they probably just want to sound scary in the media.

However, in 2025, the manufacturer proceed to sue the hacker group and the train repair company. As far as I can tell, the case is still in courts.

The three hackers explained their work in this 45-minute conference talk. It’s honestly not the most polished presentation, but it goes into a lot of engrossing details and if the intersection of hacking and trains hardware interests you, check it out! I had fun looking double checking this presented code by punching in the lat/long coordinates into Google Maps and verifying they’re exactly the locations of competitive repair shops:

#conference talk #maintenance #piracy #real world

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

This, too:

#history #process #typography

While both of these services changed a lot since the essays, they are still worth reading. They might be the closest to modern reviews of software as I can think of, and the way the essays are done also teaches us storytelling lessons – from nice visualizations and comparisons, to rich footnotes. There is also a great balance of high-level overview, and then jumping into specifics that reinforce it.

Here’s one example of cool tooling O’Beirne used to make his points more sticky:

I wrote a script that takes monthly screenshots of Google and Apple Maps. And thirteen months later, we now have a year’s worth of images:

The result is informative and mesmerizing:

Among the essays, I’d particularly recommend these:

• The back-and-forth of Google Maps’s Moat and New Apple Maps: Reverse engineering areas of interest, thinking of how the slow changes in visuals lead up to strategy, good visual comparison of competition, and small fascinating anecdotes of places like Parkfield, California. (And a great example of the old adage: don’t get into the business of predicting the future as this will age your writing the most.)
• A Year Of Google Maps & Apple Maps: Evolution and redesign as ways to “increase capacity.”
• Google Maps & Label Readability: A fascinating discovery of “city donuts.”
• What Happens to Google Maps? How cross-device compatibility can mess up maps.

There are also book recommendations and a memorable user story.

#above and beyond #colors #complexity #details #toolmaking #typography #web

This kind of disambiguation delay is everywhere for simple gestures.

Why is there a short wait if you press a button twice in that situation? The double press processing also has to be delayed, because there is a chance it might become a triple press (go to previous track).

Why is there a short wait if you press a button to go to the next track on your car’s steering wheel? It’s a delay of a different kind, but the same principle: the function cannot kick in on press down, because press down and hold mean “fast forward.” So, software has to wait for button up event to go to the next track (which feels a bit slower than button down), or for enough time to pass so we’re certain it’s a button-down hold rather than a slow press. Here, both interactions experience a penalty for coexisting.

The most infamous of those disambiguation delays exists in mobile browsers. Since every double tap can zoom into the page ever since that famous 2007 iPhone presentation, every single tap on a link or elsewhere has to be delayed by about 300ms. This has been a source of contention since it does make the web feel a bit slower, and today browsers suspend double tapping on sites designed for mobile, trading zooming affordances for higher interaction speed – after all, you can still zoom in by pinching. But if you always wondered why older websites tend to be a bit sluggish to interact with, now you know.

Different tradeoffs are possible. In the Finder, clicking on icons isn’t slowed down even though double clicking exists, because selecting an icon is compatible with opening it! So in effect it’s not a choice between a faster A and a slower B – it’s A or A+B.

Even in the iPhone presentation above, you can see the interface highlights the link on double tap, to at least make it feel snappier, at the expense of the highlight being “wrong” and potentially distracting – or even confusing – when you end up double tapping. (You can imagine smartphones pausing on the first remote/​headset button press, too. It feels like it would be compatible with advancing to the next track, but I think it might also feel too “choppy,” too chaotic, in practice.)

Lastly, why is there a short wait if you press a button on your hotel TV to increase the volume? Oh, I think that one is just sluggish for no good reason.

#details #finder #interface design #performance

Computing is filled with all sorts of arbitrary numbers like these. The most famous one was Y2K (99 + 1 = 00 if you only allocate two digits), Pac-Man’s kill screen was number 256, people still bring up the infamous and likely non-existent “640 kilobytes should be enough for everybody” quote, and the Deep Impact space probe died a lonely and undignified death after its timers overflowed the two pairs of bytes given to them.

Here’s a new magic number to remember: macOS Tahoe has, for a while at least, a kill screen of its own – after 49 days, 17 hours, 2 minutes, and 47 seconds (or, 4,294,967,295 milliseconds), one of its time counters overflows and no new network connections can be made, rendering the machine rather useless. The only solution is a reboot. Talk about a deadline!

(Well, new-ish. In perhaps a bit of karmic payback, Windows 95 and 98 once had a similar problem with the exact same threshold of 49.7 days.)

Wikipedia has a nice list of other time storage bugs. The next big one? The problem of the year 2038. The technical fix, as always, is to give the numbers a bit more room to breathe. This is, in a way, kicking the can down the road, but that might be okay since the road is rather long:

Modern systems and software updates address this problem by using signed 64-bit integers, which will take 292 billion years to overflow—approximately 21 times the estimated age of the universe.

However, as always, the technical side won’t be the hard part.

#bugs

It’s a fun (as always) watch, but as a UX designer, it’s also interesting to try to figure out what are the underpinnings of the things Staecker lists as strange from today’s perspective.

I believe that “CE/T” (clearing and totaling) coexisting on one key is a nod to professional accounting use of adding machines where you wouldn’t want to accidentally enter something into the record twice – so totaling also automatically resets the value and prevents you from making a mistake.

I also believe the strange [+=] rule is only because the keypad has to look forward at the same time it is looking back: it needs to serve as a universal computer keypad where [+] and [=] are separate key, but it also needs to pretend to be an adding machine where one key served both purposes.

(You can spot that the back of the box just allows you to swap the [+] key to be something else.)

Overall, the video is a fascinating tale of an “in-betweener” product that was stuck not just in the middle of a transition from physical devices into apps, but also at the intersection of calculators and adding machines (once two very different lines of products), themselves trying to learn from each other. It also serves as a great reminder that skeuomorphism is not just about visuals and sounds, but also behaviours: tearing off the tape, details of specific keys, nuances of rounding.

It’s not a thing of the past, either. In my post about determinism I linked to Apple’s recent travails with the deterministic Clear button (part one, two, and three). A few years ago, Apple also changed the built-in iPhone calculator from its “desktop calculator” roots to a more modern model where you get to input the entire equation before you see the result. But that change had bigger consequences; for example the [=] key could no longer repeat an addition. People complained, and Apple added it back – but the change feels incompatible with the new system and potentially confusing:

Elsewhere, the entire iPhone is an in-betweener, as the keypad coming from calculators is incompatible with the keypad coming from phones.

At this point it seems the calculator keypad will win, but transition has been over a century in the making. Staecker’s video is a good reminder how important, but also hard it is when you try to make these transitions happen faster.

#change management #flow #history #real world #skeuomorphism #youtube

As far as I can tell, no truly huge world-shifting software product has ever existed in only one version (even Flappy Bird had updates). Just about every global software product of longevity grows, changes, adapts, and reacts to other software over time.

So I set myself the task of picking five great works of software. The criteria were simple: How long had it been around? Did people directly interact with it every day? Did people use it to do something meaningful?

I came up with:

• the office suite Microsoft Office,
• the image editor Photoshop,
• the videogame Pac-Man,
• the operating system Unix,
• and the text editor Emacs.

Ford’s criteria felt more interesting than those of the other similar lists:

I propose a different kind of software canon: Not about specific moments in time, or about a specific product, but rather about works of technology that transcend the upgrade cycle, adapting to changing rhythms and new ideas, often over decades.

This – about Unix – also caught my attention:

There’s a sad tendency in most manuals and programming guides to congratulate people simply for thinking. Not here; you’re expected to think. That can be very exciting when you’re used to being patronized, and it’s one of the best things about Unix.

#history #software evolution

But these blink comparators are smart. If you e.g. rotate the photo, the comparison will be with the original also rotated so the pixels still map to each other 1:1 – even if you rotated the photo as the last step in your editing process:

I think this is a brilliant example of understanding the spirit of a feature rather than its letter. A naïve blink comparator would show an unrotated photo, but in this way it would cease being a blink comparator.

#details #interface design #principles

The other game was a simpler case study: Cyberpunk was buggy as hell. Not just the abysmal performance, but also the overall quality. People called it “the Hindenburg of videogames” and made YouTube compilations and listicles of its often hilarious bugs: cars exploding for no reason with perfect comedic timing, intimate body parts protruding through the clothes, and the infamous T poses.

In an unprecedented move, Microsoft slapped a big warning atop Cyberpunk’s app store listing, and Sony pulled it from their store altogether.

But it is 2026 now, and both games redeemed themselves. For years after the launch, the No Man’s Sky team worked hard on adding promised features:

Over a decade on from its initial reveal, No Man’s Sky both manages to remain the same game it was at launch while also bringing almost every single missing feature (and dozens of new surprise ones) into the title – implementing them intelligently and with great consideration for how it will affect the core of the game. They achieved their redemption years ago, yet continue diligently with massive update after massive update.

No other title has done what Hello Games have managed to achieve. And the best part? Every single update, patch and addition to the game was and is 100% free, with no falsified hype or build-up to each update.

Cyberpunk 2077 had a redemptive arc of its own, too, highlighted and contextualized in this 17-minute video from gameranx. Today, both games are rated “very positive” on Steam, and are actually still gaining daily players.

So, wonderful comeback stories, right? Depends on how you look at it. It’s great that both these games ended up being good products, but perhaps not as great that it was all happening in the open.

The videogame industry tried to get creative about it and established an idea of “early access”: being able to purchase an incomplete game earlier, and watch it get better while the publisher receives funding to keep going. But for every Minecraft there is Godus, and for every Kerbal Space Program there is The Day Before. Plus, neither No Man’s Sky nor Cyberpunk launched in early access with attendant caveats and discounts. (By the way, Wikipedia’s entry for early access is worth checking out – it’s so eloquent I’m surprised not to see any warning boxes.)

There seems to be ongoing and perhaps rising frustration with companies releasing software products too early and fixing them in flight, if at all. Already in 1996, Geoff Duncan wrote about his annoyances with that:

What Beta Means Now: […] In many cases – particularly with Mac Internet software – “beta” doesn’t mean anything close to what it used to. We’ve seen programs in public beta that not only contain innumerable known bugs the developers are aware of and plan to fix, but also accumulate major new features through subsequent releases. Similarly, we’ve seen products that change fundamental system and technology requirements during beta – details which should have been etched in stone long before. Beta often means what “alpha” or even “development build” used to mean.

Subsequently, Google and other web-first companies diluted the meaning of beta labels even more.

The trend of premature launches extended to devices, too. About two years ago, AI assistant gizmos from Humane and Rabbit were pilloried by audiences for launching in an effectively unfinished form. Both devices failed in the market; MKBHD’s video reviews of Humane AI Pin and Rabbit R1 remain both entertaining and informative watches.

AI complicates this even further in many ways. I enjoyed Pavel Samsonov’s recent post on his blog Product Picnic analyzing another disastrous launch: Grammarly’s writing advice feature that replicated well-known authors who never agreed for their likenesses to be used this way:

Reading between the lines, Mehotra’s interview paints a picture that I think many tech workers will find familiar: features are conceived, coded, and shipped as quickly as possible. He is happy to admit that the feature was a mistake… in retrospect. But in the moment it actually mattered, critical thinking was swept away by the false urgency of pushing things out.

It is worth reading in full and following the links, too; I watched the mentioned (tense) interview, and was similarly frustrated with the CEO’s lack of accountability or even a hint of an explanation of why the feature was launched to begin with. Key line from Samsonov’s post:

If you don’t know what are you trying to learn when you ship a prototype, do not ship a prototype.

This becomes even more important as the difference between a prototype and a final product is now thinner than a retina pixel. Both No Man’s Sky and Cyberpunk had, at least, well thought through foundations.

I understand that for some people gen AI software building tools is a discovery – perhaps for the first time – of a genuine joy of creation. But there’s also the other, newish side, a sort of “cult of velocity” where people show screens filled with agents coding things as if the world needed every possible app right this second.

Velocity and urgency can be important, but it’s hard to be careful and thoughtful when you’re going really fast; unsurprisingly, some don’t know what to do with that newfound AI-powered speed or realize the importance of thinking about crucial aspects other than time to market. (When digital cameras came around, the barrier to entry for photography was drastically lowered – it was possible to take a lot of photos without worrying about cost or quality. Tons of people took tons of objectively subpar photos; some were the end goal, some were a stepping stone toward more photographic mastery. However, I am not sure I remember people on either side ever bragging “I took over 1,200 photos today!”)

All this could be contrasted with movement of slow software (the name is part of a bigger slow movement although has unfortunate connotations in tech – it’s slow as in “speech,” not slow as in “beer”). Jared White in 2023 defined it as:

• Sustainable software. Architecting and writing code in ways which are easily understandable and maintainable over time, requiring few dependencies and a rate of change that is healthy for the underlying ecosystem.
• Thoughtful software. Working through feature development and making decisions based on what will benefit the userbase over the long term, placing mental and social health as priority over immediate gains or selfish interests.
• Careful software. Seeking to understand the ways software might be used for harm, or itself be harmful by taking attention away from more important concerns in the broader culture.
• Humanist software. Recognizing that most software—at least in application development—is primarily written for humans to understand and reason about with ease across a wide array of skill levels, and that relying on complex code generators or “generative AI” tooling to resolve complexity instead of simply building simpler human-scale tools is an industry dead-end.
• Open software. Looking to established collaborative software movements like open source and the standards bodies responsible for open protocols to inspire how we build and maintain software (regardless of licensing).

I don’t really have a conclusion for this meandering post, as I am not sure a snappy conclusion is possible. Perhaps some of the links above can provide inspiration or food for thought about urgency, reputation, and doing things in the open.

Some patterns I’m noticing are:

• Velocity is never an end goal.
• Velocity is only one of many ingredients of software building.
• It is necessary to think of people who will experience your work-in-progress as it is, not as it might one day be.

#ai #bugs #games #software evolution

Colín is not “in tech,” and the video is of “the king is naked” variety which is very, very refreshing.

Among many good observations, this caught my attention as relating to this blog’s topic:

It’s a little weird to have this almost adversarial relationship with your customer base. They’re not trying to solve a problem customers have. They’re trying to convince people that the product on offer is something more than it clearly is.

What VR is, is a fun parlor trick. What they want VR to be is literal reality.

It does indeed feel Meta’s version of VR/metaverse has always been cargo-culting real world in a particularly awkward fashion, which Colín analyzes deeper.

Too many quotable laugh-out-loud moments, so maybe just this one more:

Down here in the real world, there are really only two things a media technology can be. It can be a solution to a specific discrete informational problem, or it can be an artistic medium. These two things are not mutually exclusive. There is crossover here – like, radio was a military tool before radio plays were ever a thing.

But by the former, I mean you’re literally just making information go faster. You’re reducing the amount of noise between a message and its receiver. Any kind of metaverse is going to be really, really bad at this because you don’t need to look at a weird Pixar version of your coworker in order for them to convey what a deadline is.

#research #software evolution #youtube

It’s a fun listen (perhaps if you skip a bit of a bummer 9-minute beginning), covering four listed things in more details:

• generous mouse paths (especially in menus)
• coyote time for modifier keys
• optical alignments
• tooltip timing details

There were a few interesting things that caught my attention:

• Figma does have “coyote time” in the very interaction the hosts are talking about, perhaps showcasing that the details of the details can make or break them.
• “Should modifier keys be reversible” and “should modifier keys be consistent with one another” are interesting challenges; some more recent graphic tools have changed the long-standing behaviour here, malking modifier keys more “sticky.”
• Wholeheartedly agree with how frustrating it feels that the menu interactions are not yet baked into browsers as primitives. “The fact that the companies keep having to implement it themselves manually is maddening.” It is.
• Good observation that some people associate animations with “feeling premium” (see also: the quote I put in the title).

#details #interface design #podcast

Perhaps I can explain.

There are three main international keyboard layout variants in common use: American (ANSI, with a horizontal Enter), European (ISO, with a vertical Enter), and Japanese (JIS, with a square-ish Enter).

The shape of Enter and the shuffling of the surrounding keys is not the only difference. It’s also that the European layout has historically always had one more key – shoved in between Shift and Z – and the Japanese layout a few more.

But the main challenge is that a keyboard doesn’t have a way to tell the host computer what are its exact keys and where they’re located.

So, pressing the thing next to the left Shift can help Apple understand whether the keyboard is American or Japanese (always Z) or European (something else, but never Z). And pressing the thing next to the right Shift differentiates JIS (where it’s the _ key) from another keyboard (always /).

What I called “primitive” just above is actually clever in its approach. The legend of the key next to left Shift varies per locale (you can compare here), so the system can’t just tell you to press the < > key – and besides, asking the user to find a key that might not exist is a lot more stressful. And, identifying the keyboard by choosing a layout visually wouldn’t work either, since there are a million of layout variations – imagine having a split or a compact keyboard!

But it still is primitive, because it will still open up even if the keyboard you connect isn’t really a typing keyboard…

…or even if it doesn’t have any keys at all. (Some peripherals like credit card readers and two-factor dongles identify as keyboards as they transfer information by sending keystrokes.)

But: Why does it matter? What happens if you select the wrong layout or ignore the dialog?

If you mix up America and Europe, the difference should be largely cosmetic. After all, you still have to choose the keyboard language. People in, say, Germany will likely choose the appropriate locale, and the keys will do the right thing. However, also selecting the correct physical layout will properly display it in a few places, which can be helpful:

Japanese keyboards are more interesting, because they still have an English “mode” and the legends on a lot of the keys in that mode are different than on those on American and European keyboards – yet, the keys when pressed appear exactly the same (have the same “scan codes”) to the connected computer:

So knowing whether the keyboard is “US in the US” or “US in Japan” is important not just to place keys in the right position visually in a few places in macOS, but also for those keys to output what they actually show:

By the way, Apple’s own keyboards do not pop up this dialog. This is because while a keyboard can not do much when connected, it can at least send a vendor and model identification numbers, and Apple knows which of its keyboards sport what physical layout.

Why doesn’t macOS do that for third-party keyboards? They might, for some well-behaving ones; I don’t actually know. Unfortunately, the vendor/​model identification is a wild west and a lot of the keyboards I have identify simply as “unknown,” so building up an all-encompassing keyboard layout database is not really possible.

Either way, I mostly wanted to share why the dialog exists. Mind you, I don’t love it in that its language could be better and at one point it breaks a cardinal rule of reorienting options, which makes it hard to remember “oh yeah, it was the first scary setting that worked before.”

But overall, I thought it is a clever solution to a surprisingly hard problem. Sometimes primitive is better than nothing.

#keyboard #mac os

In short: One of the professional teams in the FPS game Squad built a sophisticated set of scripts that made it easier to use the game for esports tournaments by adding additional UI, useful stats, a floating camera, an extra over-the-shoulder view, and so on. The community embraced the scripts as they genuinely made the spectating much better.

Months later, it turned out that the creators not only hardcoded easier rules for their own team, but even added a pretty comprehensive set of cheating keyboard shortcuts.

The useful esports spectating scripts were, in effect, a trojan horse. A fascinating story, plus an interesting case of psychology of cheating.

#games #youtube

There is a deep stack of technology that makes a modern computer interface respond to a user’s requests. Even something as simple as pressing a key on a keyboard and having the corresponding character appear in a text input box traverses a lengthy, complex gauntlet of steps, from the scan rate of the keyboard, through the OS and framework processing layers, through the graphics card rendering and display refresh rate.

There is reason for this complexity, and yet we feel sad that computer users trying to be productive with these devices are so often left waiting, watching spinners, or even just with the slight but still perceptible sense that their devices simply can’t keep up with them.

We believe fast software empowers users and makes them more productive. We know today’s software often lets users down by being slow, and we want to do better. We hope this material is helpful for you as you work on your own software.

I loved the slow-motion videos comparing what is normally impossible to notice:

Dan Luu has a complementary post digging a bit more into computer hardware latency from the 1970s to now:

I’ve had this nagging feeling that the computers I use today feel slower than the computers I used as a kid. As a rule, I don’t trust this kind of feeling because human perception has been shown to be unreliable in empirical studies, so I carried around a high-speed camera and measured the response latency of devices I’ve run into in the past few months.

I feel both of these essays are fantastic, and important to develop some sense of what are specific numeric thresholds separating fast and slow, also in the context of being able to have an informed conversation with a front-end engineer. (Luu subsequently links to even more articles in the “Other posts on latency measurement” section, if you are curious.)

Otherwise, from my observation, the two most quoted laws of user-facing latency are still Jakob Nielsen’s response time limits, and the Doherty Threshold. But the Jakob Nielsen 100/1000/10000ms rule is from 1993 and as far as I understand is concerned primarily with UX flows: reactions to clicking a button, responses to typing a command, and so on. And the Doherty Threshold is even older. Both are simply not enough, especially not for things related to typing, multitouch, or mousing, where for a great experience you have to go way below 100ms, occasionally even down to single-digit milliseconds.

(My internal yardstick is “10 for touch, 30 for mousing, 50 for typing.” Milliseconds, of course.)

At the end of his essay, Luu writes:

It’s not clear what force could cause a significant improvement in the default experience most users see.

Perhaps one challenge is that these posts are dense and informative, but only appeal to people who care? Maybe latency eradication needs a PR strategy, with a few memorable rules and – perhaps arbitrary, but well-informed – numbers that come with some great names attached? I know in the context of web loading some of the metric names like FCP (First Contentful Paint) broke through at least to some extent, but those still feel more on the nerdy side. Even Nielsen’s otherwise fun 2019 video about response time limits didn’t stick the landing – why focus on slowing down an arbitrary label appearing above the glass when the ping sound was right there for the taking?!

I can’t help but dream of interaction speed’s “enshittification” moment.

#keyboard #mouse #performance #touch

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.

I thought it would be fun to talk about it briefly, because it gives me a chance to show you a really fun device:

This is a blink comparator, an apparatus built for astronomers to easily flip between two images of the night sky, taken at the exact same position some time apart.

It makes it easy to spot a moving asteroid, like in this set of two photos:

Blink comparator was used in 1930 to spot Pluto:

(Pluto is the blinking dot a bit to the top and to the right from to the center – that dot moves to the left in the other frame. The fact that it moved at all made it an object of interest, but it didn’t traverse the sky like an asteroid or space debris would.)

This is why the “spot 10 differences” puzzles are always shown side by side…

…otherwise everything would be much, much easier to spot:

Today, this kind of stuff doesn’t require complex devices, but it’s useful to know the principle.

If you’re comparing a reference design with its implementation, instead of measuring things on both sides it can help to align them in two windows, and then switch between them using ⌘Tab.

If you’re working on an interface for users to see differences between two images – don’t (just) show them side by side, but also allow your users to flip between them this way. And, resist the very natural urge to add any transitions that would seem to be nicer and friendlier; it is sharply switching between images that is the most effective.

#hardware #history #principles #real world

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!

#above and beyond #bugs #internal ui #process

The original theme is “what is an app that you use all the time, and like to use, but is actually a bad app?” but it quickly moves to a more general conversation about good and bad mobile apps.

It’s always interesting to me to see what themes emerge and what other people think is important. Here’s the list where I linked to relevant apps as long as I could find them:

Bad apps:

• Google Messages – dinged for unreliable spam and lack of organization/​filtering
• Notion (on mobile) – hard to orient yourself and some direct manipulation is wonky
• many smart home accessory apps – bad and redundant with Google Home, but have to keep for emergencies
• Netgear Orbi (network router) – specific functionality and bad password recovery
• Hatch (white noise machine for babies) – simple things are hard to discover
• Nest app/Nest Yale Smart Lock – bad integration
• Goodreads – stale

Good apps:

• ButterflyMX (smart building lock app) – reliable
• UDisc (score keeper for disc golf) – good functionality, great in a free version
• New York City ferry
• New York City ticket payment – reliable and has many payment options
• Greenwich, CT and San Francisco parking apps – live activities
• The StoryGraph – cool graphs and stats about your book reading patterns

#above and beyond #podcast #touch #youtube

Independently, Google Docs approached it from a slightly different angle, but landing on a similar interaction – in their version there’s a small visual callout, although you can still press Tab (and then Enter) to accept the suggestion:

I know the Tab key has a lot of jobs – from indenting bullet points to jumping through GUI elements – but in this context this new addition doesn’t seem to be in conflict.

(Should I write a long photoessay about the Tab key, similar to the ones I wrote for Return/​Enter and Fn keys?)

Since we added it, I’ve really loved how it feels. From various typeaheads and autocompletes elsewhere, Tab has a strong “forward movement” energy so it makes conceptual sense, and it’s just really fun to go around and quickly fix your writing this way.

I think a lot about how to make keyboard interactions feel superpower-y: a good keyboard shortcut on a large key, a tight interaction, a blink-of-an-eye velocity – something that’s eminently designed to lodge itself in your motor memory as quickly as possible, as it builds on top of prior motor memory. I’m biased, of course, but I like the “no scope” Figma version more, and it has that feeling to me.

#details #flow #interface design #keyboard #text editing

#easter eggs #humor

Then, at any moment, you can hold Control and swipe with two fingers (or use a scroll wheel) up or down to zoom the entire screen.

I’d also recommend turning off “Smooth images” under “Advanced…” so you see individual pixels better:

Over the years, I found this feature very useful to inspect various misalignments, to check visual details, and occasionally simply to read text that’s too small.

Compared to other ways of zooming, this one has three benefits:

• it’s extremely motor-memory friendly and so my fingers do it without me even thinking
• it’s a system-wide thing, so it will work everywhere
• it’s safe, because it’s something that I call a peek gesture

Peek gestures are fast, but the main benefit is that they’re safe. In some apps, pressing ⌘+ a few times and then ⌘– the matching amount of times doesn’t guarantee you will end up back in the same situation. The window size might change, the scroll position might move, the cursor might end up in a different place. In contrast, the Ctrl gesture is 100% deterministic and reversible; it will always work the same and never mess anything up.

I treasure peek gestures in general. Here are a few other useful (and/or inspiring?) ones:

• previewing things in Finder by pressing (or, for power users, holding) the spacebar

• using ⌘⇧4 with the intention not to take a screenshot, but just to (roughly) measure a distance between two objects, and then pressing Esc to abort

• in tools like Figma and Sketch, using Ctrl+C just to quickly verify the color, and pressing Esc to cancel (rather than clicking to put the color into the clipboard or apply it elsewhere)

• I also previously mentioned Chrome typeahead and macOS menus that had a similar property

#definitions #mac os #tips

The new book by Stewart Brand is tackling a subject that’s important to me. The introduction struck a chord:

The apparent paradox is profound: Maintenance is absolutely necessary and maintenance is optional. It is easy to put off, yet it has to be done. Defer now, regret later. Neglect kills.

What to do? Here’s a suggestion: Soften the paradox, and the misbehavior it encourages, by expanding the term “maintenance” beyond referring only to preventive maintenance to stave off the trauma of repair—brushing the damn teeth, etc. Let “maintenance” mean the whole grand process of keeping a thing going.

Ultimately, alas, the book doesn’t really expand on this suggestion. While the volume feels rich and dense in some ways – illustrations, extra commentary, highlights – its surface area ultimately appears to be rather shallow. Ironically, given the subject matter, it feels like Brand fell prey to a bunch of “sexy” stories, some of them only tangentially related to maintenance.

I will just say it: I wish the author was more woke. The book is very male-coded. The main chosen areas of investigation are: motorcycles! tanks! guns! wars! There are moments towards the end where Elon Musk and Bill Gates are talked about as if it was still 15 years ago and we haven’t actually learned anything since. (No word of Cybertruck, either.)

We know maintenance tends to be unrewarded and forgotten come promotion time. We know that tedious tasks are often assigned to women and people of color while white men go around doing “genius things.” It’s hard to imagine women not being present in a book about maintenance, and yet – and I wish I was joking – the only woman of any significance in the entire book is… The Statue Of Liberty.

That aside, before opening the book, I hoped it would provide me some vocabulary and evolved thinking about maintenance that I could put to use, and there are some moments where it almost approaches what I wanted from it. Here’s a passage:

Powell credits the Israeli military with a mindset that naturally viewed damaged tanks as soon-to-be-repaired tanks, rather than the irredeemable flotsam of battle. The fact that [Israeli] commanders thought in these terms gave purpose and direction to the maintenance-related technical and tactical skill their crews possessed.

This is fascinating. Tell me how? Tell me what was needed to make it happen? But, unfortunately, outside of some basic tenets of “give the rank and file more freedom to do things” and “embrace improvisation,” the book doesn’t seem to offer more.

Elsewhere, there is this quote:

In almost every plant I worked at, QA was seen as a hindrance to hitting productivity metrics. We never got credit for a well-maintained manufacturing capability, but QA almost always got blamed when things went wrong.

…which, again, felt like a fascinating thread to pull on. But instead of digging deeper, this is left hanging without investigation.

The book doesn’t really have a proper ending with synthesis of what came before, and generally meanders a lot – to a point that the table of contents has more “digressions” than actual subjects. It also feels occasionally rambling and occasionally showing off (name-dropping people like Kevin Kelly and Freeman Dyson, or quotes from “beta-tester” readers that mostly serve to paint Brand in a positive light), which takes away from otherwise brisk writing and at times truly excellent storytelling. (The first chapter in particular is fantastic.)

If you want an easy-to-read, breezy, well-typeset book filled with historical anecdotes, and the above caveats do not bother you, this might be a fun read! But I expected more from it.

The one place where the book shines is pointing people toward other books – there are pages that feel more like literature review (done really well!), and the end matter has bibliography and recommended reading with notes. So in that way, while disappointing in and of itself, it could also become an interesting starting off point for more research.

#book #book review #maintenance #review

I liked the details both within the implementation – for example, making sure the kerning is preserved! – but also in the presentation. I particularly enjoyed Schulz making the component demo itself, rather than using prerecorded videos. (I was delighted to discover that even the first large “picture” of the component is actually interactive!)

A small comment to this bit:

Unfortunately, not all browsers expose the selection or accent color of an operating system. For example, if a user would set the accent color in macOS to pink, the special CSS keyword color “Highlight” will still result in a light blue color in Safari. In other browsers like Chrome, the color will match the user preference. But since this is an attack vector for user tracking / fingerprinting, Apple made the right choice to hide the user preference from developers.

From my understanding, this is not necessarily correct. For example, in theory, the purple visited link color can be used for fingerprinting, by building a profile of whether or not I visited one of the hundreds of popular websites, quietly in the background.

The way browsers solve this is to never expose the color programmatically back to JavaScript – if your code asks for a link color, it will be blue regardless of whether the link was visited or not. It seems to me that the Highlight color could be used the same way here. Given that CSS now supports things like color-mix(in srgb, Highlight 20%, white), it would even allow a designer to riff on the color without ever knowing what it is.

#details #frontend #keyboard #search

It’s a 2016 game by Bennett Foddy and AP Thompson that reimagines older existing games as smaller pieces of a new, Super Mario Party-like experience. Two players randomly join one of 300 games – sometimes in medias res – with a small explicit goal that can be accomplished in about ~30 seconds, after which a point is awarded, another game is loaded, and so on.

All of this is done through actual emulation and fast switching of games’s original code:

Regarding the game choices, at the outset, I wanted to curate a list of moments of gameplay that would be meaningful if played for just a short period of time. Sometimes it’s obvious – you can take a moment from a fighting game where both players are low on health, or play a sports game from the start until the first point is scored. So that’s where I started. Over time, I figured out that you could make exciting moments in games that are not otherwise interesting for a competitive duel. For example, in Dodonpachi (a bullet hell game) we take away the player’s guns and challenge them to stay alive in a huge hail of bullets.

For games that were designed as cooperative experiences, I eventually gravitated toward the structure ‘score more points but do not die’, which forces the players to calibrate how much risk they take relative to the other player.

This excerpt is from a 2017 interview of Foddy by Seb Chan from ACMI. There are many interesting moments in that interview, such as the issue of curation:

Multibowl is not a very precise historical curation like you might make for a museum exhibition, where you can only show a couple of dozen things at most. It’s a huge driftnet of games. There is no quality or historical significance standard, and no attempt to balance out the games in terms of nationality or gender. The only curatorial instinct that it follows is to find the most diverse set of game ideas. With each piece distilled down to a randomly-selected 30-second slice, there’s room for an infinite number of them.

In fact, contrary to a museum curation, the point of Multibowl is to have too many games for a single player to see. It’s best when it feels too big to grasp. I think, now that there are 300 games in there, it’s starting to feel that way.

Unfortunately, it is not possible to actually play Multibowl outside of special events, given copyright issues. In addition to general emulation copyright murkiness, Foddy adds, “I don’t think the actual bits of actual games have ever been used as the fabric of a larger game before.”

However, a really fun introduction to Multibowl is another art project from a now-defunct comedy duo Auralnauts, who actually played Multibowl pretending to be Kylo Ren and Bane, to hilarious results:

#art #emulation #games #humor #youtube

The first Macintosh font was designed to be a bold system font with no jagged diagonals, and was originally called “Elefont”. There were going to be lots of fonts, so we were looking for a set of attractive, related names. Andy Hertzfeld and I had met in high school in suburban Philadelphia, so we started naming the other fonts after stops on the Paoli Local commuter train: Overbrook, Merion, Ardmore, and Rosemont. (Ransom was the only one that broke that convention; it was a font of mismatched letters intended to evoke messages from kidnapers made from cut-out letters).

One day Steve Jobs stopped by the software group, as he often did at the end of the day. He frowned as he looked at the font names on a menu. “What are those names?”, he asked, and we explained about the Paoli Local.

“Well”, he said, “cities are OK, but not little cities that nobody’s ever heard of. They ought to be WORLD CLASS cities!”

So that is how Chicago (Elefont), New York, Geneva, London, San Francisco (Ransom), Toronto, and Venice […] got their names.

If you check out the actual Philly stops and witness all their provinciality, you can understand what Jobs was after:

Go to first Macintosh via Infinite Mac, open Infinite HD and MacWrite within, and you can examine the nine eventual fonts in their pixellated, cosmopolitan glory:

The list goes in this order: New York, Geneva, Toronto, Monaco, Chicago, Venice, London, Athens, San Francisco.

But: How about some hard evidence for the original anecdote? Turns out, the March 1984 issue of Popular Computing used pre-release Mac software and printed a screenshot of the names rejected by Jobs:

Since on the facing page we see the output in the same order, coming up with the correct mapping is not hard:

• Cursive → Venice
• Old English → London
• City → Athens
• Ransom → San Francisco
• Overbrook → Toronto
• System → Chicago
• Rosemont → New York
• Ardmore → Geneva
• Merion → Monaco

One has to admire the final order of the Mac fonts that went from dependable and utilitarian at the top, to progressively more weird; this earlier list is all over the place.

In later releases of Mac OS, three other world-city fonts – Boston, Los Angeles, and Cairo – joined the party, so let’s show them here for completeness’s sake:

(Cairo is the classic icon font and in a way a predecessor of modern emoji, with inside jokes like Clarus The Dogcow.)

But that’s not the end of the story of the original Mac fonts. Let’s get back to 1983. On yet another page of the magazine, we see this list from MacPaint:

You can tell this screenshot is even older than the previous one, because it is itself set in an earlier version of Chicago, with a single-storey lowercase “a,” and many letterforms being works in progress. (I talked about the history of Chicago in my 2024 talk about pixel fonts.)

And it is old enough that this isn’t just interim names for surviving fonts – it’s actually quite a few old fonts that didn’t make it to the release day.

Unfortunately, this particular version of Macintosh software remains unknown, but one similar pre-release version of the first Mac software leaked, and so we can take a look at some of these fonts, too:

(You can download a lot of these fonts thanks to the hard work of John Duncan. They are still bitmap fonts and might not work in all the places in modern macOS, but they seem to work in TextEdit at least.)

Here’s what I learned from looking at this list:

• You can definitely see how unpolished some of these fonts are in terms of spacing, letterforms, and available sizes – kudos to the team for holding a high quality bar even though there was little precedent for proportional fonts on home computers at that time.
• Even the fonts that shipped – London (née Old English), Venice (née Cursive), and Chicago (née System) – have had their letterforms tweaked and improved.
• Chicago is not named Elefont, but simply System. Had the System name persisted, this Medium snafu from 2015 would have been even more hilarious.
• The name of the monospaced Elite font is likely inspired by one of the two classic sizes of typewriter fonts: pica (larger) and elite (smaller).
• Cream came all the way from Xerox’s Smalltalk and was the original system font for Macintosh-in-progress, before Susan Kare created Elefont/​Chicago.
• PaintFont was a symbol/​icon font, but distinct from Cairo and emoji in that it seems it was meant to be used only by the app to draw its interface. (Today, SF Symbols serve a similar purpose.)
• Apple originally planned to use Times Roman and Helvetica, but this hasn’t happened presumably because of licensing issues. Only years later, the proper Times and Helvetica fonts were introduced. Here’s a comparison:

But the most interesting thing I haven’t noticed before are two fonts called “Marie Osmond” and “Patti.”

I am reaching outside of my well of knowledge here, but from context clues I’ll assume the latter means Patti LaBelle. And so, pulling on that thread, it’s kind of cool to imagine an alternate universe where the original Mac fonts are neither suburban Philly stations, nor well known cities, but something like this:

#history #mac os #typography

However, the engine did not have any moving vehicles. Instead of adding a new kind of primitive into the game engine, the creators… made the player character itself become the subway car when in motion:

This was done by removing freedom of movement from the player, forcing the character to slide on the floor, and equipping him with… a “metro hat.”

The visuals of people hacking this to use it outside of the subway area are really funny:

Technically, it was not a hat, but a right-arm armor, as you can see from the right hand missing in the above picture.

The FPS genre is filled with all sorts of hacks for hand-held weapons, to compensate for the challenges of depicting things accurately not feeling as great…

…but I have never heard of someone “wearing a train.”

(The title comes from this post.)

#games #hacks

It’s an interesting peek behind the curtain at designing for this particular space, and the many unenviable constraints: lack of data, care for privacy, tension between Mastodon’s power-user early adopters (“they are values-driven, they want control, they’ll tolerate a lot of the clunkiness of the Fediverse”) and “mainstream audience [that] expects polish.”

At some point, design needs to be authoritative, but how do you combine that with wanting the process to be as inclusive as possible? The product itself is a federation of various servers that can exert their own control – so how do you bring it all together under one neat umbrella for the user? (Also a challenge for Android in comparison with iOS.) The mainstream design has certain fashion-y tendencies. How to make sure you don’t lose yourself while chasing them, but also not to stay ossified out of fear of making changes? (Wikipedia, Internet Archive, and other similar places look and behave a certain way, after all, and it’s not usually because of lack of talent to “modernize” them.)

The most interesting thing to me was this:

It’s easy to talk in terms of who to optimize for. Things get harder when you start to articulate who you won’t optimize for, what trade-offs you must make in pursuit of your goal, and who you’re going to risk letting down along the way. What the team needed from me more than anything was not the probabilities, not the usability findings, not the story of who we’re making happy. They needed to hear who will choose to disappoint and why. And I told them that building the best experience on Mastodon means that we’ll solve for the extremes, but we won’t center them. And sure, we do risk frustrating some power users who want absolute control over their profiles, but that risk is necessary to optimize the experience also for browsing users.

When we were working at Figma in 2019 shipping an update to text line height algorithms (moving them from the way print does things to the way web does things), I started an internal document called “The new line height and its discontents,” where myself and the team deliberately wrote out who will be most annoyed about the changes, and why. We listed our arguments, workarounds, even “deal sweeteners” (“but look at this other thing that will get better as a result!”), but we also tried very hard to be candid with ourselves. Some people were not going to be happy no matter what we do or say. Do we know precisely who these people are and are we okay with that? I’d recommend that approach for any change-management project, rather than keeping fingers crossed or toxic positivity.

Joy so far worked on quote posts and new profiles, and I appreciated her ending the talk on a note of recognition for these kinds of projects in these kinds of settings:

I know that we’re building something that will continue to be imperfect, but it doesn’t have to be perfect to make a positive difference in the world.

#change management #conference talk #youtube

…and blossomed on early versions of Mac OS X…

…but where I thought it really shone was the first iPods:

This was perhaps the most fun you could ever have navigating a hierarchy of things; it made sense what left/​right/up/down meant in this universe, to a point you could easily build a mental model of what goes where, even if your viewport was smaller than ever.

It was also a close-to-ideal union of software and hardware, admirable in its simplicity and attention to detail. This is where Apple practiced momentum curves, haptics (via a tiny speaker, doing haptic-like clicks), and handling touch programmatically (only the first iPod had a physically rotating wheel, later replaced by stationary touch-sensitive surfaces) – all necessary to make iPhone’s eventual multi-touch so successful. And, iPhone embraced column views wholesale, for everything from the Music app (obvi), through Notes, to Settings.

Well, sometimes you don’t appreciate something until it’s taken away. Here are settings in the iOS version of Google Maps:

I am not sure why the designers chose to deviate from the standard, replacing a clear Y/X relationship with a more confusing Y/Z-that-looks-very-much-like-Y. They kept the chevrons hinting at the original orientation – and they probably had to, as vertical chevrons have a different connotation, but perhaps this was the warning sign right here not to change things.

I think the principle is, in general: if you’re reinventing something well-established, both of your reasoning and your execution have to be really, really solid. I don’t think this has happened here. (Other Google apps seem to use standard column view model.)

#apple #details #finder #google #interface design #mac os #next

What I liked about it is that the author goes beyond cheap shots and deeper into both storytelling aspects (drawing from his experience)…

Now, as you can tell, the big problem with the design and execution of this video is that the producers failed to recognize the importance of point of view in telling this story. Now, perspective is already very important in any film, but it’s doubly important in a film for which one’s point of view in reality is also the subject. But this failure is present even in some of the more mundane parts of the film like the interviews that Mark does with various meta staff members. Now, as it’s plain to see, these are not real interviews. They’re fully scripted and staged – again, a classic mistake in corporate film. You can even tell that they’re not looking at each other. They’re clearly reading from a teleprompter. Yikes.

Of course, the entire premise of an interview is that two people are speaking candidly. So watching an obviously fake interview can be deeply unsettling as the speakers try to act out natural conversation and inevitably fail. This is why so many people in this video, including Mark, seem to not know what to do with their hands while speaking. It’s because they’ve been told to act naturally in a social situation that does not normally exist.

…and the meaning of these kinds of propaganda-esque announcements:

They are joined by some friends who are calling from Soho to tell them about some cool augmented reality street art that they’ve just discovered. […] And with a wave of his hand, Mark teleports the artwork into his spaceship so that he can appreciate it for himself, thus extracting this street art from any sense of place and context, which is the point of street art. I know this might sound like a nitpick, but I think it’s just worth lingering on the fact that, you know, in this high concept tech demo about how this technology will empower people to appreciate art in new ways. Nobody paused to ask what the social and cultural function of street art actually is.

The entire introduction video comes across as thoughtless and careless – “It’s not a product launch or even a demo. It’s just a cartoon about the world Mark Zuckerberg is telling you that you will one day live in.” – and some of the observations here will be relevant to other things, even in other mediums: UI redesign minisites, the font announcements articles, rebrand unveils, and so on.

I would love similar analyses of Apple’s stuff – not just the most obvious parallel which would be the 1987 Knowledge Navigator vision video, but some of the more recent scripted virtual keynotes, too.

#storytelling #youtube

I believe that the resurgence of https made things harder – if the captive portal doesn’t kick in, no secure traffic can happen – and over time I just started remembering that “captive.apple.com” is a reliable HTTP-only destination to visit.

But I noticed this week that United’s onboard wi-fi network is called “Unitedwifi.com” as a reminder where to go once you are connected, to avoid that problem. I thought this was a nice touch.

#details #got your back #interface design

Designers have been saying this for years. Cameras don’t take pictures, photographers do. Tools don’t make you a better designer. Now the PM world is arriving at the same conclusion.

I am not linking to the post because I hear this argument from time to time, and I want to comment on the general notion.

I think I understand the sentiment behind it: You’re not a designer because you know all the Figma shortcuts. You’re not a perfect typewriter away from The Next Great American Novel. Mastery of a tool is not mastery of the subject matter. And there is definitely a certain amount of performative pretense of an insta photo of a meticulously arranged desk with a bougie keyboard, going at length about the only correct set of presets and plugins, or an idea that “if only you do this one creative habit, a firehose of creativity will follow.”

But I also disagree. Good tools do make you a better designer.

A good tool can make you go faster and, as a result, let you spend more time doing revs and trying new things. A good tool can make you go slower when needed, practicing a connection with the material underneath.

A good tool will prevent you from shooting yourself in a foot, will teach you new things about what you’re doing – and perhaps even about yourself.

A good tool will value your growth, make you reflect on your growing body of work, and push you to try harder.

A good tool can inspire you. A great tool can make you fall in love. A bad tool can make you walk away, and a horrible tool will make you never want to come back.

A good tool will make you seek out more good tools.

Sure, people wrote books on a BlackBerry. Would you want to? Sure, the best camera is the one you have on you. But wouldn’t you prefer that camera to also be the best camera for whatever it is that makes you tick – a great sensor or glass, an amazing build quality, a friendly user interface, a logo that makes you want to step up, or some particular quirk or sentiment that you can’t even explain, but matters a whole lot to you?

I’m told I should be annoyed if someone’s first reaction to seeing a nice photo I made is “what kind of camera do you use?”, as it diminishes my accomplishments as a photographer. But: I chose the camera, and bolted on the appropriate lens, and realized over the years the aperture priority mode and very precise focus area is what makes my brain happy. I went through other cameras before, and learned I didn’t like them and I liked this one. At some point in my life I even ventured out into the frightening underworld of the settings menu, opened a new browser window, and decided “I will now try to understand all of these terms.” It took years, but I did.

The reason I enjoy scanning and processing old documents is because I invested in my tools. I have a little keypad, a bunch of hard-earned Photoshop actions, and some bespoke Keyboard Maestro combos that boss Photoshop around. This little tool universe doesn’t just make me more efficient, but it also makes me have fun.

I’d go even further. The mastery of the subject matter and the mastery of the tool are both important – but they also have to be joined by fluency with tool choices, and deep understanding of the relationships you have with your tools.

No single writing advice book will give you a perfect recipe, but read ten of them and scan twenty more, and you might compile the right mixtape of practical tidbits for your brain, and inspiration for your soul. Likewise, you have to try out a bunch of tools – some bad ones, a few great ones – to understand what you need. Not just for efficiency, but also for enjoyment, and ambition, and flexibility or maybe rigidity, and this sort of unmeasurable feeling of a tool getting you, or a tool made by someone like you.

Maybe it’s the 1960s typewriter you need, or a newfangled e-ink-based writing implement, or maybe you just have to open TextEdit and close everything else. I’m not going to tell you the novel comes out then. But the novel might never come out if you don’t figure out what tool can help get it out of you.

You also have to recognize the telltale signs when you outgrow the tool, or when the tool starts disappointing you. Over the years, I learned that I hate InDesign, but that I hate LaTeX even more. I switched from Apple Notes to SimpleNote in 2012, went back to Notes in 2017, and just this year moved over to Bear. I once cargo-culted Scrivener for writing and ran away screaming, but I also once cargo-culted DevonThink and still use it today, in awe of its clunkiness and old-fashionedness that match my own.

AI tools are still tools. And generative AI will allow you to build more tools for the solitary audience of just you – but, like elsewhere, it will require some understanding what makes for a good tool and what makes for a good tool for you.

Craig Mod wrote recently about using AI to build his own custom tools:

My situation is pretty unique. I’m dealing with multiple bank accounts in multiple countries. Constantly juggling currencies. Money moves between accounts locally and internationally. I freelance as a writer for clients around the world. I do media work — TV and radio. I make money from book sales paid by Random House via my New York agent, and I make money from book sales sold directly from my Shopify store. […] Simply put: It’s a big mess, and no off-the-shelf accounting software does what I need. So after years of pain, I finally sat down last week and started to build my own.

But I bet Mod knew what tool he needed to build based on his experience with tools that didn’t work for him – and software and design in general.

Elsewhere, Sam Henri Gold in a widely-shared essay that is worth a read, about MacBook Neo and the beginning of the tool journey:

He is going to go through System Settings, panel by panel, and adjust everything he can adjust just to see how he likes it. He is going to make a folder called “Projects” with nothing in it. He is going to download Blender because someone on Reddit said it was free, and then stare at the interface for forty-five minutes. He is going to open GarageBand and make something that is not a song. He is going to take screenshots of fonts he likes and put them in a folder called “cool fonts” and not know why. Then he is going to have Blender and GarageBand and Safari and Xcode all open at once, not because he’s working in all of them but because he doesn’t know you’re not supposed to do that, and the machine is going to get hot and slow and he is going to learn what the spinning beachball cursor means. None of this will look, from the outside, like the beginning of anything. But one of those things is going to stick longer than the others. He won’t know which one until later. He’ll just know he keeps opening it.

I am bothered by black-and-white, LinkedIn-ready statements. “Tools don’t make you a better designer” feels like another version of the abused and misunderstood “less is more.”

My camera taught me to be a better photographer. DevonThink told me how to better organize my thoughts. Norton Utilities showed me how to have fun when doing serious things, and Autodesk Animator how to be serious about having fun.

I’m a toolmaker, so perhaps I arrive at this biased. I endured some crappy tools, wrote some okay ones, benefitted from some great ones. I don’t think I would have become a designer without them.

#ai #craig mod #toolmaking

I feel design has a version of that, too. Here’s viewer menu hierarchy in Google Drive:

One should always feel very uneasy about a menu with just one item, like Insert here. Even within the View menu, one could imagine streamlining all the commands to be in one main menu, rather than two tiny submenus (coupled with pretty excessive width that makes for an interaction that feels like walking a tightrope).

These are the menus for a PNG image. It’s entirely possible other file types offer more options and this menu structure earns its keep then, paying off in consistency over a long run – but I tried a few file formats, and the menus all looked similarly sparse.

As a counterpoint, here’s an example I just spotted in the context/​right-click menu in Apple’s Notes:

When you have one device, the three options get appended to the ground floor of the menu. But if you have more than one, they all get ejected into a submenu.

I like this soft consistency of introducing hierarchy only when it’s needed – or in reverse, flattening/​streamlining it as necessary.

I have mixed feelings about this one particular use, however. This menu is already very long (and seemingly abandoned – look at table and checklist and link options), so in this case perhaps a consistent submenu would be overall better. Also, the “Insert from iPhone and iPad” label is long and makes the entire menu slightly wider.

But as a pattern, it’s worth considering. (Just for completeness’s sake, you could also half-streamline by adding a submenu for the iPhone and another one for the iPad. But in this particular case, it’d also likely be a bad idea.)

#details #interface design

Some of the technical details inside are obsolete, but the story might still be fun. (Plus, it seems like at every job I have, I eventually stumble upon a bug that brings back something from the annals of history. Here’s one from 2019.)

#bug deep dives #history #marcin wichary #typography

…and I wanted to share a response by Nikita Prokopov, because he had a great point about those Dropbox Paper placeholders that I didn’t consider:

For me it’s […] confusing placement. Like if somebody writes “Have a nice day” on a door instead of “Push” or “Pull”. I don’t mind seeing “Have a nice day” message somewhere neutral, in a place not occupied by any other function, but not where I expect very specific help.

I was reminded of Prokopov’s comment when I saw this at the airport yesterday:

I remember, eons ago, how impressed I was when one of the Chrome designers was telling me how all of these error pages were specifically designed to feel like liminal spaces and notlike destinations. These were, in a way, placeholder content.

But “Press space to play” feels like a strange thing to put in here. (Previously, the message said “No internet” or “There is no Internet connection.”) I understand that this is Chrome’s popular mascot, but this is still an error page whose purpose is to tell me what’s wrong, rather than serve as an entry point to a minigame.

Also, just a few days ago, I just stumbled upon this fun example of a placeholder collapse – where a temporary text becomes permanent:

If you are curious, this is what it looks like if you don’t forget to set the message. And funnily enough, given where we started, it says “Have a nice day”:

#details #interface design #nikita prokopov #real world

I went to the New York Times to glimpse at four headlines and was greeted with 422 network requests and 49 megabytes of data. […]

Almost all modern news websites are guilty of some variation of anti-user patterns. As a reminder, the NNgroup defines interaction cost as the sum of mental and physical efforts a user must exert to reach their goal. In the physical world, hostile architecture refers to a park bench with spikes that prevent people from sleeping. In the digital world, we can call it a system carefully engineered to extract metrics at the expense of human cognitive load. Let’s also cover some popular user-hostile design choices that have gone mainstream.

Bose has a knack for naming some of these hostile patterns: The Pre-Read Ambush stands for distracting you even before you start reading, Z-Index Warfare is about multiple pop-ups competing with each other, and Viewport Suffocation is about covering so much screen with crap you can barely see the content. You can almost see those names fly by on the massive screens in the final scenes of WarGames:

By the way, I didn’t know that the ad bidding is actually happening on my computer, using my CPU, and clobbering my interface speed:

Before the user finishes reading the headline, the browser is forced to process dozens of concurrent bidding requests to exchanges like Rubicon Project […] and Amazon Ad Systems. While these requests are asynchronous over the network, their payloads are incredibly hostile to the browser’s main thread. To facilitate this, the browser must download, parse and compile megabytes of JS. As a publisher, you shouldn’t run compute cycles to calculate ad yields before rendering the actual journalism.

The essay ends on a call to action:

No individual engineer at the Times decided to make reading miserable. This architecture emerged from a thousand small incentive decisions, each locally rational yet collectively catastrophic.

They built a system that treats your attention as an extractable resource. The most radical thing you can do is refuse to be extracted. Close the tab. Use RSS. Let the bounce rate speak for itself.

Funny you should say that. There is another user-hostile pattern not mentioned in the article, as it happens on the other side; the swiping back gesture on the mobile phone is hijacked to insert a frustrating “Keep on reading” page, rather than getting you where you came from:

It’s there on many sites, from Slate to Ars Technica.

It usually shows cheap, attention-grabbing headlines (in the case of Ars Technica, the Linus Torvalds article was over a decade old!). I originally thought this was just a last-ditch attempt to keep me on the site, but when I asked on social, a reader suggested there is another reason:

It’s an SEO play. If you land on a site because of a Google search and swipe back to Google, it sends a signal to Google that it wasn’t the result you were looking for. So by forcing users to click a link on the page to read more than two paragraphs, it means the user is unable to swipe back to Google and send that negative SEO signal.

Even the bounce rate is not allowed to speak for itself.

#enshittification #web

But screenshots have issues, and I liked how Bear (a note-taking app) brilliantly integrated OCR inside images into its flows. This just worked for regular ⌘F finding without me having to do anything:

The recognized text also appears when you search through notes, and so on. It’s just a great peace of mind that you’re not going to miss on text just because you happened to screenshot it.

Apple operating systems have had detection of text inside images for a while – I know on iOS in particular it sometimes gets in a way of normal gestures – so I thought it was just that, but curiously this doesn’t work as nicely in Apple’s own Notes.

#bear #details #interface design #search

To be fair, I am traveling and haven’t looked for solid evidence or citation that this works for people, but I personally like this approach: in lieu of a separate language selector button, each option here itself is both a language selector and a commit button.

The labels themselves are not the name of the language, but a call to action; I imagine recognizing the one label that means something to you should be easy if the other nine look like gibberish.

And, a thoughtful moment by one exhibit: Not only showing you where you are in the sequence of three videos, but even within the currently-playing video.

(I’m less of a fan of stretched type, though.)

#details #interface design #museum #real world #touch

Here’s Langewiesche’s essay from 2014 about the 2009 Air France Flight 447, where an implementation of fly-by-wire – which means disconnecting the flight stick and attendant levers from immediately controlling flight surfaces via physical linkage, and instead putting motors and software in between – caused a fatal accident, as the pilots’ mental model of the system diverged too far from what was happening:

The [Airbus] A330 is a masterpiece of design, and one of the most foolproof airplanes ever built. How could a brief airspeed indication failure in an uncritical phase of the flight have caused these Air France pilots to get so tangled up? And how could they not have understood that the airplane had stalled? The roots of the problem seem to lie paradoxically in the very same cockpit designs that have helped to make the last few generations of airliners extraordinarily safe and easy to fly.

It’s an interesting read today in the context of robotaxis and self-driving, but also AI changing software writing:

This is another unintended consequence of designing airplanes that anyone can fly: anyone can take you up on the offer. Beyond the degradation of basic skills of people who may once have been competent pilots, the fourth-generation jets have enabled people who probably never had the skills to begin with and should not have been in the cockpit. As a result, the mental makeup of airline pilots has changed. On this there is nearly universal agreement—at Boeing and Airbus, and among accident investigators, regulators, flight-operations managers, instructors, and academics. A different crowd is flying now, and though excellent pilots still work the job, on average the knowledge base has become very thin.

It seems that we are locked into a spiral in which poor human performance begets automation, which worsens human performance, which begets increasing automation.

I was devastated to discover, while writing this post, that Langewiesche died last year. Rest in peace.

#ai #ergonomics #real world

The video talks about Tamron’s lenses which have their own software (independent of the camera), and even their own USB-C port.

In a camera lens equivalent of fly-by-wire, the software allows to fine-tune the behaviour of hardware: what should soft buttons do, should the focus ring be responding in a linear or not, or even in which direction should it rotate. However, there are also more complex behaviours – like time lapses with focus pulls – with an interesting interface that’s definitely not beautiful, but I think still worth checking out for how it uses skeuomorphism.

#hardware #skeuomorphism #youtube

This interesting 9-minute video from Core-A Gaming explains how this can be kind of tricky for fighting games in particular:

Suddenly, a character with a claw on one hand, or a patch on one eye, becomes a more complex situation – without redrawing, the claw or the patch move from one side of the body to another. Then there’s the issue of open stance toward the player, turning left-handed characters into right-handed ones just when they switch to the other side.

3D fighting games can, in theory, fix all of this with more ease, as instead of redrawing hundreds of sprites they can just introduce one change to a model… but they often choose not to. Enter the issues of 2.5D fighters vs. 3D fighters, 2D characters in 3D spaces, and lateralized control schemes.

It’s a small thing that quickly becomes a huge thing.

Here’s an object in Figma with one rounded corner. Notice how the UI always tries to match the rounded corner value based on where it is physically on the screen…

…which makes for a fun demo and feels smart, but: why don’t width and height do the same?

Turns (heh) out that this is a similar set of considerations as those in fighting games: both thinking deep about what is an intrinsic vs. derived property of an object, and what is the least confounding thing to present to the user. Since objects usually have noticeable orientation – text inside, or another visual property – width still feels like width and height like height even if they’re rotated. The same, however, isn’t necessarily true for four rounded corners. Or, perhaps, the remapping of four “physical” corners to four “logical” corners can be more error-prone.

Then, of course, there’s a question of what to do when the object doesn’t have a noticeable orientation. Like with many of the things on this blog, there are no “correct” answers. This too is a small thing that quickly becomes a huge thing.

#details #games #graphics #super mario bros #youtube

If you invoke that function on an email that’s an order receipt, a new option appears:

It’s great to see this clever and thoughtful button which is likely the best option here. But:

• It reshuffles everything else, preventing motor memory from building. At this point, you can no longer rely on “bottom left” to always be “custom date,” and so on with other buttons. (One idea would be to put it at the back but draw attention to it visually, or at least make it span the entire row.)
• It doesn’t show you the inferred date, even though there already is a precedent for doing that – especially important here as the feature seems to be powered by AI, which can get things wrong.
• The icon heavily promotes the AI association, which is not that useful. It would probably be better to show a truck or some other visual signifier of “delivery.”

#details #google #interface design

Presently, only one option is there…

…but at least back in 2012 there were many more:

What does it do? It adds an old-time’y glyph at the end of either left or right panel.

The internet is rife with people perplexed by this option and I cannot deny – I’m one of them. (The title of this post is a reaction of one of the users.) It feels like such a peculiar way to add delight.

You are not limited to the pre-existing (one) flourish, as you can upload your own. Some people add a logo of their production studio, but John Beardsworth found a more creative use:

Alternatively, with a tiny bit of imagination you can exploit an often-forgotten detail of Lightroom’s interface – the “panel end marks”. These decorations at the bottom of Lightroom’s panels have often been derided as a waste of programming time, but in fact they can be made to serve more than their somewhat-trivial purpose. And as you can see in the examples on this page, they can serve as a reminder of star ratings, colour labels and even keyboard shortcuts for flags.

This is a fascinating hack, and an example of William Gibson’s famous “the street finds its own uses for things.” It made me curious why didn’t onscreen interfaces ever evolve to allow you to annotate them easily? You see stuff like this a lot in real life…

…but the Lightroom end mark hack is the only thing that comes to my mind where an onscreen UI got this kind of a treatment – and the feature wasn’t even intended for that use.

#adobe #interface design

It follows that every design presentation is inevitably, at least in part, an exercise in bullshit. The design process always combines the pursuit of functional goals with countless intuitive, even irrational decisions. The functional requirements — the house needs a bathroom, the headlines have to be legible, the toothbrush has to fit in your mouth — are concrete and often measurable. The intuitive decisions, on the other hand, are more or less beyond honest explanation. These might be: I just like to set my headlines in Bodoni, or I just like to make my products blobby, or I just like to cover my buildings in gridded white porcelain panels. In discussing design work with their clients, designers are direct about the functional parts of their solutions and obfuscate like mad about the intuitive parts, having learned early on that telling the simple truth — “I don’t know, I just like it that way” — simply won’t do.

So into this vacuum rushes the bullshit: theories about the symbolic qualities of colors or typefaces; unprovable claims about the historical inevitability of certain shapes, fanciful forced marriages of arbitrary design elements to hard-headed business goals. As [Harry G.] Frankfurt points out, it’s beside the point whether bullshit is true or false: “It is impossible for someone to lie unless he thinks he knows the truth. Producing bullshit requires no such conviction.” There must only be the desire to conceal one’s private intentions in the service of a larger goal: getting your client it to do it the way you like it.

“I don’t know, I just like it that way” is such a tricky part of craft.

#craft #storytelling

The first series was three posters:

I still (mostly) like them. I do believe that software can learn more about conveyance from video games; a lot of first-run experiences and particularly new feature onboarding still feel like a series of random pop-ups floating around the screen without much understanding of me as a user.

I would rewrite these posters, however, and particularly the Fitts’s Law examples: they’re generic and probably not as relevant to today’s applications.

After series one, we also collaboratively started working on series two, but the pandemic put a halt to the effort, and these posters were never finished/​printed. But the two below were perhaps closest to ready, and they seem fun today; I particularly liked the joke on the Hick’s Law one.

Jon Yablonski, the author of “Laws of UX,” made some posters in a similar vein and they’re available for purchase. His are slightly more on the visual side, but I was delighted to discover today that we both chose a rather similar approach to visualizing the Zeigarnik Effect.

(200th blog post here!)

#definitions #principles

The Parc mouse cursor appearance was done (actually by me) because in a 16x16 grid of one-bit pixels (what the Alto at Parc used for a cursor) this gives you a nice arrowhead if you have one side of the arrow vertical and the other angled (along with other things there, I designed and made many of the initial bitmap fonts).

Then it stuck, as so many things in computing do.

And boy, did it stick.

But let’s rewind slightly. The first mouse pointer during the Doug Engelbart’s 1968 Mother Of All Demos was an arrow faced straight up, which was the obvious symmetrical choice:

(You can see two of them, because Engelbart didn’t just invent a mouse – he also thought of a few steps after that, including multiple people collaborating via mice.)

But Kay’s argument was that on a pixelated screen, it’s impossible to do this shape justice, as both slopes of the arrow will be jagged and imprecise. (A second unvoiced argument is that the tip of the arrow needs to be a sharp solitary pixel, but that makes it hard to design a matching tail of the cursor since it limits your options to 1 or 3 or 5 pixels, and the number you want is probably 2.)

Kay’s solution was straightening the left edge rather than the tail, and that shape landed in Xerox Alto in the 1970s:

Interestingly enough, the top facing cursor returned as one of the variants in Xerox Star, the 1981 commercialized version of Alto…

…but Star failed, and Apple’s Lisa in 1983 and Mac in 1984 followed in Alto’s footsteps instead. Then, 1985’s Windows 1.0 grabbed a similar shape – only with inverted colors – and the cursor has looked the same ever since.

That’s not to say there weren’t innovations since (mouse trails useful on slow LCD displays of the 1990s, shake to locate that Apple added in 2015), or the more recent battles with the hand mouse pointer popularized by the web.

But the only substantial attempt at redesigning the mouse pointer that I am aware of came from Apple in 2020, during the introduction of trackpad and mousing to the iPad. The mouse pointer a) was now a circle, b) morphed into other shapes, and c) occasionally morphed into the hovered objects themselves, too:

The 40-minute deep dive video is, today, a fascinating artifact. On one hand, it’s genuinely exciting to see someone take a stab at something that’s been around forever. Evolving some of the physics first tried in Apple TV’s interface feels smart, and the new inertia and magnetism mechanics are fun to think about.

But the high production value and Apple’s detached style robs the video of some authenticity. This is “Capital D Design” and one always has to remain slightly suspicious of highly polished design videos and the inherent propensity for bullshit that comes with the territory. Strip away the budget and the arguments don’t fully coalesce (why would the same principles that made text pointer snap vertically not extend to its horizontal movement?), and one has to wonder about things left unsaid (wouldn’t the pointer transitions be distracting and slow people down?).

Yet, I am speaking with the immense benefit of hindsight. Actually using that edition of the mouse pointer on my iPad didn’t feel like the revolution suggested, and barely even like an evolution. (Seeing Apple TV’s tilting buttons for the first time was a lot more enthralling.) And, Apple ended up undoing a bunch of the changes five years later anyway. The pointer went back to a familiar Alan Kay-esque shape…

…and lost its most advanced morphing abilities:

Watching the 2025 WWDC video mentioning the change (the relevant parts start at 8:40) is another interesting exercise:

2020:

We looked at just bringing the traditional arrow pointer over from the Mac, but that didn’t feel quite right on iPadOS. […] There’s an inconsistency between the precision of the pointer and the precision required by the app. So, while people generally think about the pointer in terms of giving you increased precision compared to touch, in this case, it’s helpful to actually reduce the precision of the pointer to match the user interface.

2025:

Everything on iPad was designed for touch. So the original pointer was circular in shape, to best approximate your finger in both size and accuracy. But under the hood, the pointer is actually capable of being much more precise than your finger. So in iPadOS 26, the pointer is getting a new shape, unlocking its true potential. The new pointer somehow feels more precise and responsive because it always tracks your input directly 1 to 1.

(That “somehow” in the second video is an interesting slip up.)

I hope this doesn’t come across as making fun of the presenters, or even of the to-me-overdesigned 2020 approach. We try things, sometimes they don’t work, and we go back to what worked before.

I just wish Apple opened itself up a bit more; there are limits to the “we’ve always been at war with Eastasia” PR approach they practice in these moments, and I would genuinely be curious what happened here: Did people hate the circular pointer? Was it hard to adopt by app developers? Was it just a random casualty of Liquid Glass’s visual style, or perhaps the person who was the biggest proponent of it simply left Apple? We could all learn from this.

But the most interesting part to me is the resilience of the slanted mouse pointer shape. In a post-retina world, one could imagine a sharp edge at any angle, and yet we’re stuck with Kay’s original sketch – refined to be sure, but still sporting its slightly uncomfortable asymmetry.

The always-excellent Posy covered this in the first 7 minutes of his YouTube video:

But specifically one comment under that video caught my attention:

Honestly, I’ve never thought of the mouse cursor as an arrow, but rather its own shape. My mind was blown when I realized that it was just an arrow the whole time.

…because maybe this is actually the answer. Maybe the mouse pointer went on the same journey floppy disk icon did, and transcended its origins. It’s not an arrow shape anymore. It’s the mouse pointer shape,and it forever will be.

#history #mouse #popular #youtube

This is how you adjust the photo in Photos app in the previous version of iOS:

And this is the same view in the current version:

The difference is in the delayed/​animated falling of the notches.

I don’t think it’s great. It’s “delightful” in a rudimentary and naïve sense, but like sugar, you cannot just add it to your daily diet without consequences. This extra animation serves no functional purpose, and the sugar high wears off quickly. What remains is constant distraction and overstimulation, the feeling of inherent slowness, and maybe even a bit of confusion.

It pairs nicely with the previous post about avoiding complexity and rewarding simplicity. I often see this kind of stuff as related to designer’s experience. Earlier on in your career, you are proud you’ve thought about this extra detail, you’ve figured out how to make this animation work and how to fine-tune the curves, and you’ve learned how to implement it or convince an engineer to get excited about it.

Later in your experience, you are proud you resisted it.

#details #interface design #motion design

What you just learned is that complexity impresses people. The simple answer wasn’t wrong. It just wasn’t interesting enough. And you might carry that lesson with you into your career. […]

It also shows up in design reviews. An engineer proposes a clean, simple approach and gets hit with “shouldn’t we future-proof this?” So they go back and add layers they don’t need yet, abstractions for problems that might never materialize, flexibility for requirements nobody has asked for. Not because the problem demanded it, but because the room expected it.

I nodded to a lot of it. There’s some parallels to design, too. Perhaps in design, “future-proofed” gets replaced by “bespoke” – everyone wants a custom interface with a novel thing that doesn’t exist anywhere else in the app. That feels better. Tailor-made. Special. It’s hard to resist that, and go back to making your UI out of reusable parts, consistent, and boring in all the best possible ways.

This advice about how to talk about simplicity feels eminently universal:

If you’re an engineer, learn that simplicity needs to be made visible. The work doesn’t speak for itself; not because it’s not good, but because most systems aren’t designed to hear it. […] The decision not to build something is a decision, an important one! Document it accordingly. […]

If you’re an engineering leader, this one’s on you more than anyone else. You set the incentives, whether you realize it or not. And the problem is that most promotion criteria are basically designed to reward complexity, even when they don’t intend to. “Impact” gets measured by the size and scope of what someone built, which more often than not matters! But what they avoided should also matter.

One more thing: pay attention to what you celebrate publicly. If every shout-out in your team channel is for the big, complex project, that’s what people will optimize for. Start recognizing the engineer who deleted code. The one who said “we don’t need this yet” and was right.

#complexity

This 2020 post by George Cave is ostensibly about Lego interface panels, but quietly sneaks in some stuff about shape coding and other kinds of coding:

The Lego interface panels seem to have a certain hold on people. Artist Love Hultén recreated some of them in a more human-compatible scale and even made them interactive:

It was fun to see one of the most well-crafted of early arcade games, Tempest, in this kind of a view, with the stud reimagined as a paddle controller:

Just earlier this month, designer Paul Stall announced his project M2x2 (the page itself is beautiful and interesting to visit – I paticularly loved the horizontal galleries):

The M2x2 is a functional homage to the classic Lego computer brick, upscaled and re-imagined as a high-performance workstation. […]

If our tools could look as playful as the things we built as kids, would we approach our work with more joy? The M2x2 is just the beginning of a workspace that feels less like an office and more like a laboratory for breakthroughs.

But both of these are enlarged Lego bricks. Three years ago, James Brown a.k.a. Ancient made an effort to embed an LCD screen in a regular-size Lego brick. It’s a fun 12-minute video of the construction process:

If you are into that kind of stuff, Brown followed it up 2 months later by putting a playable Doom inside a Lego brick:

But the most amazing to me outcome was this video, called “Busy little screens”:

A lot of diversity of the original bricks is gone, but it’s hard to expect Brown to recreate and animate them all. It’s a mesmerizing thing to watch nonetheless; one can almost taste a future where the technology will allow for Lego bricks to be animated, but look exactly as they originally did.

#hardware #principles #real world #youtube