I mentioned placeholders before in the context of Dropbox Paper…

…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 not like 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”:

A meandering and messy, but otherwise an absolutely worthwhile essay from Shubham Bose about the bloat and hostile behaviours on news sites:

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.

I feel like social media and recently the slate of AI-powered “tell me what’s here” features continue to show us the power and longevity of screenshots. After all, nothing beats a more or less approachable shortcut and a file format that works literally everywhere.

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.

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.)

Speaking of fly-by-wire… William Langewiesche is one of my favourite technical writers. He finds a way to explain complex aviation aspects really well, and then add a certain amount of beauty and poetry on top of that. His style was a big influence on my book, and I like him so much I once compiled links to his writing so that others could find it more easily.

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.

This 9-minute video from PetaPixel probably won’t make much sense for non-photographers, but there is something refreshing about this idea that there are still places where adding software is seen as positive:

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.

It is common knowledge that Luigi is just a palette-swapped Mario, and that the characters facing left are the same characters as those facing right, only rendered mirrored.

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.

This is a typical iOS Gmail dialog that allows you to snooze an email so it resurfaces later:

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.”

The search for the strangest Adobe setting continues in Lightroom, where the first option in the Interface section is… end marks:

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.

I linked to this opaquely on Thursday, but it deserves its own entry. Michael Bierut’s 2005 essay called “On (design) bullshit” is one of my favourite design essays:

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.

During my first year at Figma, I designed and printed a run of posters for the office titled “Design is more.” The idea was to highlight that UX design is more than people expect, and connected in interesting ways to other domains. Today, they feel like a spiritual predecessor to this blog.

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!)

I had no idea it was Alan Kay himself who was responsible for the mouse pointer’s distinctive shape. In 2020, James Hill-Khurana emailed him and got this answer:

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.

I think about some aspects of interface design as sugar.

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.

A smart post by Matheus Lima at his Terrible Software blog:

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.

One of my favourite genres is “I’m going to teach you something secretly while you’re having fun.”

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.

Night mode is a mode inside the iOS camera app where the app takes a longer-exposure photo in low-light conditions, but “stabilizes” it programmatically, to achieve something similar to holding a camera on a tripod for the same amount of time.

I noticed a little detail that might be new to iOS 26: the night mode icon will now show you how many seconds it expects you’ll have to hold it, ahead of pressing the shutter button.

This is me turning the light on and off in the hotel room. The icon is in the upper right corner:

It’s hard for me to know how useful this is in practice, but the gesture seems nice. What I like about it, too, is density. By my calculation, this is 10-point type, smaller even than the battery percentage at about 12. (The standard interface elements usually go for 15–17.) Retina displays allow you to add text this small and have it still be legible.

You can tell the story of Mac OS via the story of its settings, and the same is likely true of Photoshop.

Recently, spelunking in the preferences of Photoshop 2025, I found this extremely curious thing:

To transcribe:

Focus mode limits the appearance of certain optional user interface messages so that you can use Photoshop with fewer interruptions.

With this option enabled:

• The Welcome screen will not include “what’s new” feature descriptions
• Blue in-product alerts promoting discovery and use of certain features will be suppressed
• What’s New will not auto start when Photoshop is launched
• The color mode preference will be auto set to “Neutral Color Mode”

The three first options should be self explanatory. Neutral Color Mode is sort of the “graphite” option of Photoshop’s UI where the (already rare?) accented blue elements become white instead.

As much as I’ll always applaud a piece of software working on annoying you less, this is all so very strange. I don’t mean that the last option seems unrelated, and the first and third one kind of mutually exclusive… but just the very idea of shoving it in as an opt-in in the last tab of settings, under “technology previews”, and asking people for feedback feels peculiar to me.

Not to spoil the outcome, but even this “technology preview” is completely gone in the updated Photoshop 2026. I wonder if this is fallout from a mangled launch (even for those few who I imagined turned it on, the option didn’t live up to its promise), but also perhaps a political fight inside Adobe between product and growth teams? I bet we’ll never know.

I do not personally have a grand unified theory of how to explain things or announce features in products because it’s so situational, and I understand that especially Photoshop given its age might be the hardest difficulty level. I’d personally prefer to receive announcements of new features over email so I can read them at my leisure, and with each new thing or change linked to a playground that would allow me to experience it in the best way – but I can’t say with any certainty that this would work for everyone.

But I would expect people on the Photoshop team to have more experience here, and this focus mode approach just feels a bit… naïve to me. My two warm takes: 1. People aren’t generally as frustrated with how features are announced, but with what features are. 2. Why wouldn’t everyone deserve the gift of focus?

I mentioned before how the old-fashioned pixels on CRT screens have little in common with pixels of today. The old pixels were huge, imprecise, blending with each other, and requiring a very different design approach.

Some years ago, the always-excellent Tech Connections also had a great video about how in the era of analog television, pixels didn’t even exist.

But earlier this month, MattKC published a fun 8-minute video arguing that for early video games it wasn’t just pixels that were imprecise. It was also colors.

What was Mario’s original reference palette? Which shade of blue is the correct one? Turns out… there isn’t one.

Come to learn some details about how the American NTSC TV standard (“Never The Same Color”) worked, stay for a cruel twist about PAL, its European equivalent.

In the video linked in the previous post, one of the hosts mentions at one point:

The biggest rebuttal is that the greatest audio engine of all time, the one baked into all Apple products, has 16 volume steps. And no one has ever been like, “My iPhone doesn’t have enough granularity to the volume.”

But of course they have. And the solution is easy: on both the iPhone and Mac you can grab one of the many volume sliders and immediately get a lot more precision:

(Can’t help but notice this volume control has a nice set of notches, too!)

But if I told you that you can actually also increase the precision from 16 to 64 stops using the volume up/down keys, would you know how to do it?

Occam’s Razor: it must be a modifier key. So let’s go through them all.

Pressing ⌥ and brightness up/down opens the Displays settings pane, and consequently, pressing ⌥ and any of the three volume keys gives you the Sound settings pane. (This convention, however, isn’t followed for other keys. ⌥ and Mission Control only opens top level of Settings, and ⌥ and other function keys like Spotlight, Dictation, or media transport doesn’t do anything. My guess is that someone simply forgot about this over time which is a pity, because one of the best ways to teach people about a power-user shortcut is to make it as transferrable as possible, to allow motor memory to blossom.)

So ⌥ is out. ⌃ and brightness keys changes the brightness on the external display, and even though that doesn’t really apply to volume, it’s safe to stay away.

⇧ + volume keys reverses the meaning of this toggle below, making ping sounds if the toggle is off, or suppressing them if the toggle is on. This is nice.

That only leaves Fn/Globe which already reverses top-row keys into function keys, and ⌘. But ⌘ is inert. Instead, the combination to add precision is ⌥ + ⇧ + volume keys. (Same with brightness, which can be useful e.g. on a very dark plane.)

I don’t understand this, and I wonder what is the reason it got this way. Modifier keys are generally tricky, but this doesn’t follow any of the go-to rules I would try in this situation:

• Reuse an existing convention for consistency: I don’t think anywhere else ⌥⇧ means “precision.”
• Follow naturally from existing UI building blocks: ⌥ and ⇧ do different things and this is not an intuitive combination of what they do independently.
• Use mnemonics: This doesn’t feel like it’s doing that at all.
• Failing everything else, make it pleasant to press: ⌥ and ⇧ is possibly the least ergonomic two-modifier-key combination.

This shortcut has another problem, which is that it is the only two-modifier-key option here. If you don’t use it often, you might only remember it as “two modifier keys” without further detail, which actually ends up being 10 possible combinations of keys! So if you’re like me, you always awkwardly button mash a bunch of them before rediscovering ⌥⇧.

My recommendation for a small tweak here?

• ⇧ and brightness/​volume: Secondary display/Add pings (both are most important; Shift is nice to press and the “default” modifier key).
• ⌃ and brightness/​volume: Add extra precision (as that gives you more control).
• ⌥ and brightness/​volume/other keys: Open the relevant Settings pane.

Obviously, I might not have all the information that led to the current situation (and it’s possible I don’t even understand it fully), plus changing any long-existing shortcuts is hard. But as above, ⌥⇧ is so peculiar, and it also misses out on the last important consideration: I don’t think anyone would ever discover it by mistake or out of curiosity.

MKBHD’s Waveform podcast (audio or video) sometimes has a fun “Did they even test this?” section. This week, for the first 12 minutes, the team was ranting about various volume controls – a meandering conversation that I also found just very enjoyable.

The cited answer to “why do a lot of car volume controls max out at 38?” is in a 2021 article from Car And Driver:

But then some research revealed that about 20 years ago, Chrysler decided to try to find the perfect volume interval, one that would result in meaningful difference in sound level without going too far. After much experimentation, they decided that 38 discrete volume settings provided the perfect amount of adjustability—not too fine, not too coarse. So the decree went out across the company that all stereos should go to 38.

However, no citation is given, and I couldn’t find any more information about it.

The one thing the group missed in their discussion is “why even show a number”? I think it helps people in remembering their preference, especially if they share a car with someone else. Remembering that “my volume number is 17” can be helpful, even if it feels a bit clunky.

When volume controls were physical, I believe if they didn’t have a number, they at least had a certain amount of notches so you could remember the nearest notch you liked:

Keynote is an app that could use something like that. At this very moment, I am trying to unify the volume of various clips across slides for an upcoming presentation, and having to use environmental cues like “between Edit Movie below and the rewind button above”:

I have been at times frustrated by cute placeholder text in places, most notably Dropbox Paper, which still puts them in a just-created doc…

…and in new to-do items:

This bothered me for two reasons.

First was a potential tone mismatch. What if you are writing a layoffs announcement, a project cancellation doc, or something personal and heartfelt? At Medium back in the day, at some point we added a fun celebratory dialog after publishing that said something like “Now, shout it out from the rooftops!” We took it down very quickly as people made us realize Medium is used to write many kinds of things we didn’t anticipate, and in those situations the cutesy message really failed to read the room.

But the other half of my frustration with Paper was that it felt like the app was making itself too comfortable in my space, in effect shouting all over my inner voice and distracting me. I felt like any app giving you a creative canvas should back off of that canvas unless it’s explicitly invited to participate.

Turns out, I can now attach something tangible to that discomfort. From Scientific American earlier this week (emphasis mine):

The researchers asked participants to fill in an online survey with questions about hot-button social and political issues. Some were prompted with an AI autocomplete answer that was deliberately biased toward one side of the issue. For example, participants who were asked whether they agreed that the death penalty should be legal might receive an AI suggestion that disagreed.

Across all the different topics in the survey, participants who saw the AI autocomplete prompts reported attitudes that were more in line with the AI’s position—including people who didn’t use the AI’s suggested text at all. Overall, the study participants who saw the biased AI text shifted their positions toward those espoused by the AI.

Interestingly, the people in the study didn’t tend to think the AI autocomplete suggestions were biased or to notice that they had changed their own thinking on an issue in the course of the study.

The quoted study shows an example…

…and elaborates on how adding warnings didn’t really help:

The Warning and Debrief messages failed to significantly reduce the attitude shift, which is concerning because they were also inspired by those used in real AI applications. AI tools such as ChatGPT show brief and general statements about AI’s propensity to hallucinate false information (e.g., “ChatGPT is AI and can make mistakes. Check important info.”), similar to the messages used in our interventions.

I know on this blog I often focus on the mechanics of interactions, but the job of every designer is to think of more than that. I keep coming back to both pull-to-refresh and infinite scroll mechanics. Both can be put to good use and feel “delightful,” but both started being abused so much that it led to their respective creators disowning them.

Nice, clear, simple copy in ClarisWorks from 1997:

No “Maybe later.” No “Not now.” Thirteen characters. Now, Later, Never.

(Can’t help but notice that Esc and ⌘. – the classic Mac’s equivalent of Esc – still map to Later, however. Also, this breaks the rule of button copy being fully comprehensible without having to read the surrounding strings first, perhaps most well-known as the “avoid «click here»” rule. Never Register/​Register Later/​Register Now would solve that problem, but wouldn’t look so neat.)

One of my favorite bits of trivia about the 1983 movie WarGames is that all the computer typing scenes have been faked in a clever way: The actors (many of whom might have never typed before, as home computers were only slowly becoming popular) were allowed to press any key they wanted, but the interface would still proceed as if the correct letter was typed.

This allowed the computer to respond to keystrokes, making it all feel real, but also reduced the burden on actors to type things properly – and also make it easier for proper sight lines to happen, as the actors didn’t have to constantly look at the keyboard.

WarGames used it really well, showing all sorts of face reflections in the CRT screens, as if people literally talked to the machines, which must have been hell to film:

I have never seen this demoed or mentioned outside of the anecdote. However, yesterday, Cathode Ray Dude released an excellent video about the challenges of filming computer screens. The whole video is worth watching, although at this point mostly off-topic for this blog. But starting at 1:32 and ending around 1:37, there’s an actual demo of a similar piece of auto-typing software used in the 1996 movie Scream:

You might think this is just a piece of old-computer trivia, but I’ve actually used that in at least two of my talks, for some of the similar reasons! I run most of my talks from HTML/CSS/JS; it’s nice for the audience to see things being typed and responding properly to (audible, and occasionally visible) key presses – but it’s also nice as a speaker not to worry about messing things up under pressure.

For extra realism, make sure Backspace goes back in the script – you might occasionally press it instinctively – and for extra extra verisimilitude, actually bake in a typo or two into the predefined sequence. (And an escape hatch if you actually change your mind and want to go manual.)

Then, of course, there’s a classic 2011 piece of software called HackerTyper. Did someone already marry this idea with an LLM? Seems like a logical next step.

I know some of you are all whispering “he’s posting all of these hour-long YouTube videos, when am I supposed to find time to watch them”? I hear you loud and clear and I’m going to make it better…

…by sharing this four-plus-hour long YouTube video by Jenny Nicholson from May 2024 – just so those other videos will feel short in comparison:

Seriously, though, this is an extremely enjoyable deep dive into Disney’s failed Galactic Starcruiser hotel.

I don’t know much about Disney, but it was engrossing as half of the failures were actually software-related: from the flawed UI in various spaces in the hotel and screen-laden space windows in the rooms, to poor integration with physical elements of the scenery, an “immersive” interactive game that felt untested plus gave you poor feedback, and the general trends of laziness and cheapness that could never fully be remedied by the performers going above and beyond.

What Nicholson does a lot is trying to debug what actually happened to make her experience so miserable, and it’s really refreshing to see debugging in a different context than I usually see it.

There are fun things you can do in software when it is aware of the dimensions and features of its hardware.

iPhone does a cute Siri animation that emanates precisely from the side button:

A bunch of Android phones visualize the charge flowing to the phone from the USB port…

…and even the whole concept of iPhone’s Dynamic Island is software cleverly camouflaging missing pixels as a background of a carefully designed, ever morphing pill.

But this idea has value beyond fun visuals. iPhone telling you where exactly to tap twice for confirming payment helps you do that without fumbling with your phone to locate the side button:

Same with the iPad pointing to the otherwise invisible camera when it cannot see you:

Even the maligned Touch Bar also did something similar for its fingerprint reader:

The rule here would be, perhaps, a version of “show, don’t tell.” We could call it “point to, don’t describe.” (Describing what to do means cognitive effort to read the words and understand them. An arrow pointing to something should be easier to process.)

You could even argue the cute MagSafe animation is not entirely superfluous, as over time it helps you internalize the position of the otherwise invisible magnets on the other side of your phone:

In a similar way, as it moved away from the home button, iPhone X introduced light bars at two edges of the screen – one very aware of the notch – as swiping affordances:

And under-the-screen fingerprint readers basically need a software/​hardware collab to function:

One of my favourite versions of this kind of integration is from much earlier, where various computers helped you map the “soft” function keys to their actual functions, which varied per app…

…and the famous Model M keyboard moving its keys to the top row helped PC software do stuff like this more easily:

(And now I’m going to ruin this magical moment by telling you the cheap ATM machine that you hate does the same thing.)

The last example I can think of (but please send me your nominations!) is the much more sophisticated and subtle way Apple’s device simulator incorporates awareness of the screen’s physical size and awareness of the dimensions of the simulated device. Here’s me using the iPhone Simulator on my 27″ Apple display. If I choose the Physical Size zoom option, it matches the dimensions of my phone precisely. The way I know this is not an accident is that it remains perfectly sized if I change the density of the whole UI in the settings.

Why am I thinking about it all this week?

The new MacBook Neo was released with two USB-C ports. Only one of the ports is USB 3, suitable for connecting a display, an SSD, and so on. The other port’s speeds are lower, appropriate only for low-throughput devices like keyboards and mice.

To Apple’s credit, macOS helps you understand the limitations – since the ports look the same and the USB-C cables are a hot mess, I think it is correct and welcome to try to remedy this in software. It looks like this, appearing in the upper right corner like all the other notifications:

I think this is nice! But it’s also just words. It feels a bit cheap. macOS knows exactly where the ports are, and could have thrown a little warning in the lower left corner of the screen, complete with an onscreen animation of swapping the plug to the other port – similar to what “double clicking to pay” does, so you wouldn’t have to look to the side to locate the socket first.

“Point to, don’t describe” – this feels like a perfect opportunity for it.

I enjoy little lists like these, and the presentation here is also delightful. From a design engineer Jakub Krehel, Details that make interfaces feel better. A few of these stood out to me:

Make your animations interruptible. […] Users often change their intent mid-interaction. For example, a user may open a dropdown menu and decide they want to do something else before the animation finishes.

Yes. Never make the user wait for your animation to finish, unless the animation itself is meant to cause friction and slow the user down (which is very rare).

Make exit animations subtle. Exit animations usually work better when they’re more subtle than enter animations.

I love asymmetric transitions. My go-to analogy for this is “in real life, you don’t open the door the same way you close it.”

Add outline to images. A visual tweak I use a lot is adding a 1px black or white (depending on the mode) outline with 10% opacity to images.

This is very nice and (both literally and figuratively) sharp. In some contexts, I bet you could even try to go for 0.5px.

(If you liked this page, it’s worth checking out Krehel’s other explainers, for example about gradients or drag gestures.)

In my head, some bugs belong to categories that feel important, and yet remain hard to define and quantify: embarrassing bugs, dumb bugs, flow killers.

Somewhere in the hard-to-explain space is another tricky category: UI decisions that feel cheap.

The examples of cheapness that come to my mind readily will, I bet, be different for each one of you reading this:

• using emoji instead of iconography
• using text and typography instead of graphic design elements as UI (except in terminal/​text-based interfaces)
• excessive centering
• obvious misalignments and overflows
• accidentally mismatched fonts and unspecified fallback fonts
• reflow and bad loading states that do not match the eventual UI
• selectable user interface element that betray “bad webiness” of the UI
• typos

But my absolute #1 go-to example is definitely this:

Computers could pluralize nouns basically for free already in the 1970s, and sure, there are objective arguments of why this is bad, but there’s also this: I wince so hard every time I see something like this.

I think it’s important for every designer to notice when they wince, and teach others how to wince and notice, too.

(I stole the brilliant title from this short post by Joe Leech in 2018, in which Leech uses the word “lazy” rather than “cheap” – they’re related!)

Many of you have probably heard the repeated story of the first Moon landing in 1969 almost getting undone by a bunch of onboard computer glitches:

There could not be a worse time in the flight to have computer problems. At, the time the press gleefully reported how Armstrong seized manual control from a crippled and failing onboard computer and managed to heroically and single-handedly land the spaceship on the surface of the Moon against all odds.

Robert Wills argues against this narrative in this 2020 talk, wanting to shine a spotlight away from Neil Armstrong and toward people who designed the software (among them Margaret Hamilton), and the mission control’s Steve Bales, who made a decision not to abort the launch as the 1201 and 1202 errors were piling up.

The argument: the computer was working as intended, it fixed itself over and over again owing to its clever software, and it actually helped Buzz Aldrin understand (at least subconsciously) what led to the seemingly random and distracting computer errors.

The above is more of a traditional talk than the videos I usually share – a bit more technical, taking up an entire hour, and with generic slides – but it’s buoyed by Wills’s enthusiasm and knowledge.

Besides, it’s lunar landing! Did you know about DSKY and its fascinating keyboard and UI? Did you know the spacecraft’s window was part of the interface, too? Or that its software was woven into the hardware? Or that the Apollo 11 had a… guillotine in it?

Unaddressed in the talk, but also important:

An unsung hero of the decision not to abort the landing is Richard Koos, a NASA simulation supervisor who […] 11 days before the launch of Apollo 11, put the team of controllers including Bales […] through a simulation that intentionally triggered a 1201 alarm. […] Unable to figure out what the 1201 was, Bales aborted that simulated landing. He and Flight Director Gene Kranz were dressed down for it by Koos, who put the team through four more hours of training the next day specifically on program alarms. When the 1202 and 1201 alarms occurred during the actual landing, Garman, Bales, and even Duke recognized them immediately.

Fortune favors the prepared.

This iPhone UI for dark/​light theme is doing something clever:

Ostensibly, there are two modes here:

• automatic, for when you want the theme to match the time of day
• manual, for when you want to keep one of the themes forever

But check out what happens when I am in automatic mode, but toggle the theme by hand anyway:

More rigid or less thoughtful interfaces would either disable manual changes when you’re in automatic mode, or understand a manual theme switch to mean “I want to turn off automatic.”

But here, iOS is quietly putting me in a temporary hybrid mode: a manual theme override until the theme catches up with what automatic mode would do, at which point it snaps back (I’m resisting very hard calling this rubber banding) to automatic mode.

What I think is clever is that this isn’t presented as a third mode – which could be more confusing than helpful – but the design simply reuses the existing Options field to set the expectations.

One has to be careful designing in shades of gray; once you enter the space you really have to commit to it and see it through. My go-to analogy is symmetry vs. asymmetry. Symmetry in visual design is usually easier and safer. If you venture into asymmetry you have to make an effort to make it work. The highs of asymmetry will be higher than anything symmetry can provide, but getting to those highs can be arduous and sometimes might even be impossible.

I thought this particular example was really nicely done and the team found a great balance. (I think Apple’s previous shade of gray – “Disconnecting Nearby Wi-Fi Until Tomorrow” – ended up slightly less successful.)

I just published a new photoessay about the history of the Fn key, and particularly what Apple has been doing with it recently.

Do we need yet another person crashing out about Apple’s design decisions? Am I doing it only because it’s fashionable to be on Apple Design Hate Train these days? I’ll be honest: I don’t know.

But I have been bothered by Apple’s approach to this aspect of its keyboard design for a while, because it starts breaking what I think is really important in using a computer well: keyboard shortcuts.

I hope it’s also a fun visual history of the most tricky of modern modifier keys.

(And if you like it, I linked to a few of my other keyboard essays in the footer.)

RuneScape is a popular MMORPG that reached its peak popularity in the late 2000s.

In the game, combat – colloquially known as PvP, or player vs. player – is limited to a specific map area (called the Wilderness) and otherwise people’s houses.

On 6/6/6 (sic!) a bug in RuneScape made it possible for a few players to start killing others outside of designated areas, without them being able to defend themselves. One of these players, Durial321, gained a lot of notoriety:

A player called Cursed You had invited some friends to his in-game house once he had maxed his construction skill, but decided to eject them all from the premises. Things turned sour, however, as a group of players marked as PvP in the house didn’t lose this PvP flag when ejected, allowing them to storm through Falador and massacre whoever they pleased. The most notorious of these players was named Durial321.

This event went down in internet infamy and meant that many players lost their items when killed as well as the banning of those involved.

I don’t have any context of RuneScape and I found it really funny to learn about this event from different retellings of the story.

This wiki entry reads almost as journalism:

Several others were able to use this glitch, but Durial321 abused it the most. His rampage lasted for about an hour, starting at Rimmington, where the house party was, then proceeding to Falador and subsequently Edgeville. At Edgeville, he gave Voodoolegion the green partyhat, who never gave it back to him. Soon after, he finally encountered a Jagex Moderator, Mod Murdoch, who disconnected him and locked his account. Durial321 was later permanently banned from RuneScape. In a 2006 interview, he said that player killing outside of the Wilderness was exciting, although he felt bad for the players who lost their belongings.

The 2006 incident later became known as the Falador Massacre.

(The tone is even more funny if you actually read the interview.)

There is also this more modern retelling that feels like scary story time by the campfire:

Reactions from players were initially kind of incredulous. Plenty of people were shocked and found the whole incident quite funny. Durial had essentially broken the game, after all. Some players wanted to be like him, whipping strangers to death and taking their items. But soon, as more players started hearing about what had happened and seeing the video, the mood shifted. Players wanted Durial321 hung, drawn and quartered, with his head displayed on a pike outside Lumbridge Castle.

You can witness the event PC Gamer called “one of the best all-time MMO bugs” by yourself since there is video capture of the Falador Massacre taken by one of the witnesses. At least to me, it’s rather incomprehensible.

Fear not, however, because there are many (!) documentaries. This recent one is reportedly the best one and also goes into the technical details:

Without spoiling too much, the bug was a classic Swiss cheese situation involving a new untested item, a race condition, peculiar timing, and a player with an unusually high uptime and a whole lotta luck.

I’ve learned recently that “rubber banding” can mean at least three different things in the context of UI/UX design:

• whatever happens at the edges of your scroll container when you’re using elastic scrolling, which started on the first iPhone and have spread more widely since
• in videogames, balancing the difficulty in real-time so that inexperienced players stand a chance and good players are not bored (a classic example in any racing game is computer-controlled cars slowing down if they are running too far ahead, as if held by a rubber band, to give you a chance to catch up)
• in multiplayer experiences (mostly videogames, too), the experience of snapping back and forth (example) during gameplay when your connection speed is low and the game has to reconcile your predicted position with your real one

Each one is interesting in its own way. (Each one is also controversial, although for a different reason!) But what I understand they all have in common is – well, obviously – the specific mechanics of rubber banding.

I imagine many reading this are familiar with basic interpolation between A and B using curves like ease in, ease out, and so on. But in gaming and I think increasingly in UI design, that’s not enough. When coding stuff related to movement – imagine dragging an elastic scrolling view near its edge – the challenges compound:

• the object might already be in motion
• its destination might also be in motion
• the load or framerate can vary, so calculations have to take that into account

With that in mind, I found these two videos helpful and informative:

• an 8-minute video by SimonDev
• a 50-minute talk by Freya Holmér (with a 10 minute Q&A session you can skip)

The videos together start with basic lerp (linear interpolation), then move to lerp smoothing, and then arrive at frame-independent lerp smoothing. There’s light math/​physics here, but that’s to be expected, as all these experiences are meant to feel like real-life objects would.

I found especially lerp smoothing where you feed a lerp into itself particularly conceptually beautiful.

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

The author says:

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

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

I mentioned VisiCalc not long ago and Lotus 1-2-3 just this week. Yesterday, a new issue of Stone Tools came out, nicely tying the story together.

Stone Tools is a project by Christopher Drum where he grabs old productivity apps, spools up the correct emulator, and writes a review from today’s perspective. I like the emulation part – Drum even provides specific instructions so you could do it, too – and the fact he’s actually putting the tools through their paces.

Anyway, Drum reviewed VisiCalc a few months ago, and Lotus 1-2-3 yesterday.

The reviews can probably be a bit intense if you are unfamiliar with the territory, but you will be rewarded with a lot more detail than just casual understanding of these apps. Reading about VisiCalc first and 1-2-3 second really drives home how “VisiCalc walked so 1-2-3 could run” and it’s fun to see the beginnings of spreadsheet conventions that we take for granted today, for example $ absolute addressing:

In VisiCalc I’m prompted for a “relative or fixed?” decision for every cell reference in every target cell. Replicate a formula with 5 cell references across a column of 100 cells and be ready to answer 5 x 100 prompts. Unfortunate and unavoidable.

Like always, one can find inspiration in surprising places. In the review of Lotus 1-2-3, there’s this interesting tidbit:

The more I encounter [the horizontal menu-bar], the more I wonder if we gave up on it too soon. This could be “blogger overly immersed in their subject matter” brain, but I’m growing to oftentimes prefer two-line horizontal menus over modern GUI menus. […]

It also provides something GUI menus don’t: an immediate explanation of a menu item before committing its action to the document. If a menu item is not a sub-menu, line two describes it. It’s easy to audit features in an unknown program.

I have just been pondering that maybe we moved away from status bars and question mark (Windows)/balloon (Mac) help too soon – pretty much everything these days relies on tooltips – and this slotted right into that.

Anyway. Drum seems to be having fun with the project, and I appreciate that. There are little custom visuals and jokes in every post. Also, as an example, you can download an absolutely delightful recreation of VisiCalc called PicoCalc and run it on your Mac. I have never expected a spreadsheet to be so cute:

And it’s not just most well-known tools. What astonished me in the review of Scala Multimedia in January is how absolutely gorgeous the software (which I’ve never seen before) looked:

This ain’t Windows 3.1; just that palette alone is worth bringing back.

Not going to excerpt more, but there is a lot more. Check out Stone Tools and the 13 programs reviewed so far!

⌘T is a very important shortcut in Slack. It allows you to quickly talk to someone just by typing in their name. I use it probably dozens, if not hundreds of times a day.

⌘T is right next to ⌘R, which reloads Slack. Occasionally, on the way to ⌘T, my fingers graze ⌘R. Fingers being fingers, I immediately realize something went wrong and wince, and within a second or two I witness Slack completely reloading. It’s not a big deal – no data is lost, and the reload is only 5 to 10 seconds, but when you move fast, it feels like eternity.

⌘O is a very important shortcut in Finder. It opens the selected file in the correct app. I use it probably dozens, if not hundreds of times a day.

⌘O is right next to ⌘P, which prints the file I’m pointing to. Curiously, and in contrast with most apps, the print function is not gated in any way by a confirmation dialog box, or an intermediate print settings window.

So, occasionally, on the way to ⌘O, my fingers graze ⌘P. Fingers being fingers, I immediately realize something went wrong and wince, and within a few seconds, the lights in my old apartment dim for a second. Then, far away, I hear the recognizable sound of my laser printer spitting out a page.

Gamers used to deride Windows key for automatically ejecting them from the game to the desktop, before an option to disable it started appearing in gaming keyboards. (Some of the professional gaming leagues were very strict about how a player could use their keyboard.)

Similarly, professional Excel champions and players started physically removing keys: In Excel, F1 (right next to an often-used F2) opens the help dialog and slows you down.

I served as a judge for the ModelOff Financial Modeling Championships in NYC twice. On my first visit, I was watching contestant Martijn Reekers work in Excel. He was constantly pressing F2 and Esc with his left hand. His right hand was on the arrow keys, swiftly moving from cell to cell. F2 puts the cell in Edit mode so you can see the formula in the cell. Esc exits Edit mode and shows you the number. Martijn would press F2 and Esc at least three times every second.

But here is the funny part: What dangerous key is between F2 and Esc? F1.

If you accidentally press F1, you will have a 10-second delay while Excel loads online Help. If you are analyzing three cells a second, a 10-second delay would be a disaster. You might as well go to lunch. So, Martijn had pried the F1 key from his keyboard so he would never accidentally press it.

I enjoyed this essay that presents prying off the key as a rite of passage:

Removing the F1 key from the equation is just the beginning. By embracing the keyboard-centric approach, you have the opportunity to become an Excel Wizard!! Okay, maybe that’s not a technical term, but it perfectly captures the essence of those who navigate Excel solely using the keyboard.

And I particularly liked this tongue-in-cheek answer telling people they could construct their own homemade molly guard to protect against “fat-fingering”:

Here’s an alternative snippet that can be used:

• Use bits of plastic or cardboard to make a tiny box that fits around your F1 key.
• Affix this box with duct tape, so that the F1 key is guarded.
• Fool-proof, works on any key, and can easily be reversed if needed!

Obviously, none of this can help me with my ⌘R and ⌘P woes, so, two final thoughts:

• If your app has a well-trafficked shortcut, it’s worth thinking of the shortcuts immediately adjacent to that one. Could they cause any inadvertent damage or confusion?
• Apps and operating systems should very easily allow you to unset a keyboard shortcut, in addition to setting or changing it. (Unfortunately, this is not as common as it should be.)

This video from Marblr about adding fall damage to Overwatch is really intense – 45 minutes of length and a lot of footage of frantic gameplay – but really informative, too.

It’s a great case study of how something seemingly really simple – deducting health from the player as they fall from height – can be a complicated thing to figure out in all the detail.

I never played Overwatch and rarely play videogames anymore, but many of the lessons here more universal for any sort of UI and system design:

• You will have to introduce tactical inconsistencies for the system to feel consistent, but be careful as there might be a point those inconsistencies start to outweigh the whole thing.
• Wanna learn how you and others feel about something? Overcrank it to make the feelings come out more easily. (And to find bugs.)
• There will always be tensions between what the data says and how you feel about something. (I was surprised how often the word “intuitive” entered the picture.)

Also, it’s just a really well-made video, filled with little presentation and storytelling details that elevate it. I wish more videos like this existed for UI mechanics.

But maybe the most important takeway? You don’t have to choose between rigor and fun. You can have both.

It’s hard to imagine it now, but during iPhone’s first year, no emoji were available at all. It took four years until 2011’s iOS 5 gave everyone an emoji keyboard.

But in between 2008 and 2011, there existed a peculiar interregnum where emoji were only available on Japanese iPhones. The situation had to be carefully explained and caveated:

Eventually, an enterprising developer realized that emoji outside Japan was as easy as toggling a UI-less preference with a great name KeyboardEmojiEverywhere, hiding inside the innards of the iPhone:

Except, “easy” is in the eye of the beholder. This was still a few too many hoops to jump for an average iPhone user. So, developers figured out that there could be an app for that: the above preference incantation wrapped inside an application with an easy UI, and put in the burgeoning App Store.

The interesting part is that Apple initially fought some of these efforts, by rejecting a Freemoji app and likely a few others. (Not sure if this was about emoji specifically, or more principally about losing control.)

The developers had to get sneaky, and started hiding emoji enablers inside other apps. A $0.99 “RSS reader for a Chinese Macintosh news site” called FrostyPlace unlocked emoji by “simply pok[ing] around in it for a minute or so by tapping in and out of an article and playing with the two buttons at the bottom of its screen. That part is important, so be sure to do some genuine tapping.”

Then there was the free Spell Number (you can still see its old App Store page), where punching in a certain secret number would give you the same.

The author called it an “easter egg” and even wrote candidly at the end of instructions that “you can also delete Spell Number if you don’t want it, the setting will still be here.” (The number also had to change from 9876543.21 to 91929394.59 at some point, perhaps to evade… something?)

Eventually, Apple seemingly gave up – Ars Technica has a fun interview from 2009 from someone who renamed their app from Typing Genius to “Typing Genius – Get Emoji” and got away with it:

Ars: As the screenshot at the start of this post shows, you haven’t been shy about advertising the Emoji support over at App Store. Are you worried that adding Emoji to your application might have negative consequences? Are you worried about Apple pulling it from App Store?

Fung: I’m obviously taking a risk here by advertising Emoji directly on iTunes. That being said, I’m not the first. Worst case scenario, I’ll update the application with Emoji support removed. I’m hoping that Apple will turn a blind eye to this because I can’t see any harm done in allowing users to use Emoji.

Not quite “I am ready to do some time for the good cause,” but close enough.

Yet, it still took until 2011 for emoji support to be universally available with iOS 5, and even then you had to enable the keyboard in settings.

I like this little story of a mysterious latent cool new thing hiding inside your device, a thing that you could unlock only if you followed some seemingly nefarious instructions that never fully made sense but that actually worked.

An interesting tidbit: At least early on in 2008, for emoji to work both the sender and the recipient had to follow the instructions. So the toggle wasn’t just about adding a keyboard, but also enabling the decoding and rendering. (And complicating things further, iPhone’s Japanese keyboard had emoticons, and that keyboard was widely available without any hacks. The difference between emoji and emoticons was not obvious to many people, leading to a lot of extra confusion.)

Lastly, a fun sidebar: I asked about all this an old internet buddy, Steven Troughton-Smith, whom I remembered back from my GUIdebook days, and who still routinely posts fun hacks and discoveries about Apple platforms on Mastodon. I thought “Steven might remember that story; he seems like the kind of person who’d at least know how to find an answer.” Turns out, my hunch was better than I thought: Steven was the enterprising developer who actually discovered how to give emoji to any iPhone, all the way back in 2008.

I just stumbled upon a nice little power-user innovation in Chrome’s Web Inspector.

In Safari, and previously in Chrome, when editing CSS properties, you’d get a usual editing typeahead for the property name, and then the same on the other side for the property value.

In newer versions of Chrome, the typeahead menu works as before on the right side. However, the menu on the left side also includes the right side.

I think this is really clever in this context – not just to speed you up, but also to aid understanding. Just like the inert mouse up and down in the previous post could serve as a safe “peek” into the values, this new interaction can quickly allow you to explore the CSS space if you are curious, or if you only lightly remember part of the name, or even just one of the values.

This blog is authored in Apple Notes, and some time ago Notes added quick linking via typing >>, and that has a similar effect: The interactions are so nimble and precise that it is very easy to link to something, but a nice side effect is that it also feels very welcoming just to type a few letters to remind yourself of a title of an article, and then cancel out.

The downside of the Chrome change is, well, more stuff matching, but I think the audience for this UI is going to be okay with that.

I know we’re probably collectively a bit tired talking about macOS Tahoe, but I just noticed something that I think is a good example of how small details can ladder up to bigger things.

This is macOS Sequoia (the pre-Tahoe release) and a typical pop-up button:

One clever thing macOS has been doing since basically the dawn of GUIs is that upon clicking on a button like this, the currently selected row will be in the same place as before you clicked. (As opposed to, for example, the entire menu appearing below like it would from a top menu bar.)

This has interesting and often underappreciated consequences. It allows you to orient yourself quicker since you don’t have to find the selected option again. And, it saves you movement overall: the next or previous option will always be at the absolutely shortest possible distance. (Of course, the approach also has some challenges, for example if the button is positioned close to the top or bottom of the screen.)

There’s another clever thing that happens throughout macOS: All the menus work using a classic click-to-open and click-to-select sequence, but they are also usable via the slightly more advanced, but faster mousedown-drag-mouseup gesture.

These building blocks work together and mean that selecting the next option can be as simple as a little flick of a mouse.

Now, check out macOS Tahoe (current release):

You will notice that iCloud Drive, upon clicking, is now misaligned both horizontally and vertically.

On the surface, this feels just like a visual blemish – slighly embarrassing, but without much consequence. But check out what happens if you hold your mouse button at a certain position, and then release it without moving:

The stability of macOS’s interface and the thoughtful set of aforementioned rules allowed for an emergent fast behaviour: mouse down and up meant you could “peek” into a menu safely, or you could change your mind right after seeing what’s inside. In a bigger sense, it created a certain trust between you and the operating system: it’s worth learning those gestures, as they will be rewarded.

In Tahoe, some of that learned behaviour – by the way, I see it in all of these buttons, not just this one – will now work against you. Now, you can accidentally change an option without intending to do so.

Is it a big deal? No, not really. This likely – hopefully! – simply fell through the cracks in a rush to get Liquid Glass out the door, rather than no one being there to care, or no one understanding that all these gestures add up in aggregate, creating a GUI that feels fast, trustworthy, and catering to your motor memory in a way that elevates your experiences with the interface in the long run.

But I’d feel better if it wasn’t almost half a year since the release, and if we hadn’t already seen other things exactly like it.

The year is 1981. Your IBM PC is equipped with a tragic speaker that sounds awful for anything except occasional beeps. (Those beeps sound awful, too.)

You can’t afford a sound card and besides, sound cards for your PC have not been invented yet. You can’t even afford a floppy drive, so you’re one of the rare people who actually uses an audio cassette player as a storage device – a technique usually reserved for more primitive machines that have half the bits your new PC does.

But there’s a silver lining. Your cassette player has a little relay that controls its motor. You can engage and disengage the relay at will.

So, someone figured out that toggling the relay kind of sounds like a metronome. Like percussion. It’s a hack, but in the sonic landscape inhabited solely by your sorry speaker, it’s a breath of fresh air (scroll to 7:26 if you don’t land there automatically):

The year is 2026. Your computer itself is the size of an audio cassette, fits in your pocket, has better storage, graphics, sound, pretty much everything compared to a 1981 PC. It even has a special haptic motor. Except, that motor can only be controlled by native apps, and there is no official API to do it from a browser.

But there’s a silver lining. Tapping any checkbox on a site generates a haptic pulse. And that apparently works even if the checkbox is hidden and if the computer is doing the tapping.

So, someone figured out a way to use that to build a library that gives websites powers to provide haptic feedback. It’s a hack, but damn if it’s not one someone took to its logical conclusion.

I love these kinds of hacks, and I wonder what’s going to happen to this one. Will it fly under a radar, or will some websites start abusing it? If so, will Safari clamp it down, or will it actually give people a proper API for haptics?

This blog is about craft, but sometimes the answer to craft is not skill or taste or awareness or effort, but it’s creating conditions for craft to flourish. Workday looks like Workday, and your banking app looks like your banking app, not because there aren’t enough designers and engineers around that know how to do it better.

This is a thoughtful post by Anil Dash about Apple’s recent announcement of introducing video podcasting, warning how the conditions set up right now will lead to enshittification, and proposing changes:

This will also start to impact content. You don’t hear podcasters saying “unalive” or censoring normal words because there is no algorithm that skews the distribution of their content. The promotional graphics for their shows are often downright boring, and don’t feature the hosts making weird faces like on YouTube thumbnails, because they haven’t been optimized to within an inch of their lives in hopes of getting 12-year-olds to click on them instead of Mr. Beast — because they’re not trying to chase algorithmic amplification.

It’s worth reading even if you don’t care much about podcasts.

One of the most mysterious keys on the PC keyboard has always been Scroll Lock, joining Caps Lock and Num Lock to create the instantly recognizable LED triumvirate:

Scroll Lock was reportedly specifically added for spreadsheets, and it solved a very specific problem: before mice and trackpads, and before fast graphic cards, moving through a spreadsheet was a nightmare. Just like Caps Lock flipped the meaning of letter keys, and Num Lock that of the numeric keypad keys, Scroll Lock attempted to fix scrolling by changing the nature of the arrow keys.

This is normal arrow key usage in Lotus 1-2-3, doing what you’d expect, if likely a bit slower:

And this is Lotus 1-2-3 with Scroll Lock enabled. Here, the arrows do not move the cursor, but move the spreadsheet:

(You can play with it yourself!)

In time, scrollbars helped with the problem, then mice with wheels solved it in one direction, and then trackpads in both. (Although even though my 2025 Windows laptop doesn’t have a Scroll Lock key, its onscreen keyboard does, and the key still works in Excel.)

But, I grew to believe that UI problems never fully die, and often come back dressed up in new clothes.

This is the TV app on my Apple TV, doing movement as you’d expect:

But Netflix a while back picked a different approach – scrolling almost as if Scroll Lock was on:

More recently, I saw that approach spread to HBO Max and YouTube apps as well:

Is this good? To me personally, the Scroll Lock-esque approach feels strange and claustrophobic. I see the (hypothetical) value of keeping the selection in one place, but the downsides are more pronounced: things feel lopsided, going back in this universe is flying blind, and the system creates strange situations at the edges, where Scroll Lock struggled as well.

And yet, given I just dated myself by reminiscing Lotus 1-2-3, I’m curious how it feels to others.

I realized recently that I conflated two similar user-interface comedy skits.

This one is from Sean Wing from 2023:

And this older one is from Tim and Eric Awesome Show, Great Job!, from 2009:

Speaking of Tim and Eric, this one was also funny and ostensibly on topic for this blog!

(And re: previous post – I had to cut a new version of University font with the Ü glyph just for TAARGÜS in the title.)

From May last year, a 21-minute video by Linus Boman about font piracy, specifically during the era of personal computing and early internet:

The nuances of what separates font piracy from non-pirated revivals or general inspiration are too much even for me, but I liked how the video moved on from the obvious and cheap “haha, you wouldn’t pirate a font” story to cover a few of the more complex issues with panache.

My small contribution to the discourse is that I just scanned an interesting booklet from 1979 called Typeface Analogue, which catalogs various names different phototypesetting manufacturers used for their “replica” fonts – a sort of a translation table between once-relevant parallel type ecosystems.

Some are pretty uninspired: CS for Century Schoolbook, OP for Optima, Eurostyle for Eurostile, and so on. Others are more interesting: a version of Palatino called Patina, American Classic becoming Colonial, or Futura renamed to Twentieth Century. Absolute fav? Helvetica becoming Megaron.

The display fonts you see on this blog are my vector conversion and slight improvement (kerning pairs!) over a bitmap PC/GEOS font called University, which itself was inspired by the original Macintosh’s Geneva. Inspired or downright stolen? You decide:

Those terms confused me back in the day, and occasionally they still do, so I thought it might be nice to write it all out. This is how I understand them:

• deterministic: whenever you do something, it gives you identical results as any previous or next time you do it
• idempotent: if you do something twice, or thrice, or more times, it will be the same as doing it once

Or, in short:

• deterministic: same every first time
• idempotent: same every next time

This might be confusing. Outside of LLMs, computers are supposed to be deterministic, no? They’re famously bad at random numbers; if you memorize a pattern, you can beat Pac-Man every single time.

But “deterministic” in UI design might mean something more specific. Let’s take pressing ⌘B to bold, for example:

Every time you press ⌘B on an identical selection, it will behave the same. But, pressing ⌘B doesn’t guarantee something will get bold. If it already is bold, the command will reverse its meaning. In this sense, ⌘B is non-deterministic.

It’s not hard to imagine a determistic version of bolding. Make ⌘B bold the text, and make another shortcut – say, ⌘U – unbold it. This way, you can always press either and be absolutely confident you will get a predetermined result without worrying about anything else. It’s a boon for motor memory, but it is more complex to explain, and it adds more UI surface.

There is also another, more interesting way: you can make ⌘B always bold first, and unbold second. This way, your fingers can remember ⌘B is for bolding, and ⌘BB is for unbolding. But this also gets tricky: for already fully bolded text, it might seem the feature is broken, because the first keystroke does nothing!

Only the second of these three approaches is idempotent, meaning you can invoke it many times and it will always give the same result:

• ⌘B toggles bolding from current state: non-deterministic, non-idempotent
• ⌘B bolds, ⌘U unbolds: deterministic, idempotent
• ⌘B toggles bolding, always starts from bold: deterministic, non-idempotent

One of my favorite idempotent concepts is the Clear key present on many calculators, and still on some larger Mac keyboards.

The idea behind Clear is simple. Let’s say you’re a professional keypad user – maybe an accountant? – typing in numbers for hours a day. You just made a mistake. Pressing Backspace will remove the last digit, but are you sure you only made a mistake on that last digit? What if your fingers brushed another key and you typed in two digits by accident?

Instead of using the non-idempotent Backspace key where you’d have to look at the screen to confirm, it’s easier just to press the idempotent Clear which will always remove the entire number, and then start from scratch without even having to look anywhere (as gamers would say, “no scope!”).

And, for people who are moving fast, it feels safe just to press the shortcut or a button instinctively, for ease of their mind, even if nothing has to be done. Some people might choose to press it a few times, just in case. The Esc key often has that property – isn’t it just nice to slam Esc many times? – and Jeff Jarvis in his 2014 essay talked about another shortcut that felt that way:

Since I don’t need ⌘S anymore, I can now appreciate how much it had become a part of my ritual of writing and even of thinking. I used to hit ⌘S not just as data insurance — hell, I’d often hit it after having not made a single change in my text since the last time I’d hit it. I hit ⌘S as a break, a psychic, semiotic semicolon. It gave me a moment to search for the right word, to plan the structure of where I would go next, to commit to what I’d written, or to wonder whether I had the courage to erase what I’d written and try again.

(In Figma, where ⌘S wasn’t necessary, we used to show this – but we only showed it once every fortnight, since some people would press the shortcut instinctively like Jarvis, and find the message distracting and maybe even patronizing.)

All of these options have pros and cons. The beauty of determinism and idempotence is that they free you from paying attention. I always get a bit nervous when someone tells me that in their country, you can press the elevator button again to unset it. Even if you don’t make a button a toggle, visually disabling it or showing a message (“Nothing to delete!”) when it has nothing to do could feel like a friendly gesture toward newcomers, but its non-idempotence will grate people who know what they’re doing. Determinism and idempotence are good for motor memory to develop, but – just like the above bolding example – might be initially more confusing.

The approaches can coexist; browsers give you ⌘⌥←→ to move between tabs (non-deterministic, non-idempotent) and ⌘1/2/3 to switch to a specific tab (deterministic, idempotent). Some places even offer a choice. In macOS, you can say whether you want clicking on a scrollbar chute to be deterministic or not:

…although usual choice-giving caveats should apply.

I think it’s good to think about those things, especially for interfaces used professionally. Magical things happen if you can trust your fingers and sometimes, if you worry too much about novice users, that might make it hard for pro users to emerge.

As a former ISP employee I occasionally like dipping my toes into some networking stuff, and this 25-minute video from The Serial Port is a good retelling of the day in 2014 when one of internet’s important routing tables crossed a threshold of 512K, which caused all sorts of trouble:

What I appreciate about The Serial Port is that they always seem to actually test the vintage hardware or rebuild the old software they’re commenting on, and this time was no exception: they grabbed a classic unsung hero of ISPs, a Cisco Catalyst 6500-series router, and then recreated “The 512K Day” in their studio.

This was a nice comment under the video:

Have absolutely no knowledge about networking, but watched this video as if a thriller movie. Thanks for opening my world of tech to networking.

Yeah, the video is kind of nerdy and intense, but maybe you’ll enjoy it; even a classic aging piece of hardware with an arbitrary ticking-bomb limit deserves some respect.

Also, the funniest comment:

I had a 2.4k day a couple days ago when I realized Farm Sim 22 only allows a max of 2400 bales. Couldn’t load into my saved game. Had to go into items.xml and temp remove a hundred bales.

I read Erika Hall’s Just Enough Research. I’m not going review the entire book as it feels a bit off-topic for this blog, but the chapter about surveys had me nodding my head so much I’d love to excerpt a few things:

The questions can be asked in person or over the phone, or distributed on paper or collected online. The proliferation of online survey platforms has made it possible for anyone to create a survey in minutes.

This is not a good thing.

Surveys are the most dangerous research tool — misunderstood and misused. They frequently blend qualitative and quantitative questions; at their worst, surveys combine the potential pitfalls of both. […]

If you ever think to yourself, “Well, a survey isn’t really the right way to make this critical decision, but the CEO really wants to run one. What’s the worst that can happen?”

Brexit.

Hall highlights that surveys are much harder to debug than other methods:

It’s much harder to write a good survey than to conduct good qualitative user research—something like the difference between building an instrument for remote sensing and sticking your head out the window to see what the weather is like. Given a decently representative (and properly screened) research participant, you could sit down, shut up, turn on the recorder, and get useful data just by letting them talk. But if you write bad survey questions, you get bad data at scale with no chance of recovery. It doesn’t matter how many answers you get if they don’t provide a useful representation of reality. […] Surveys are the most difficult research method of all.

[…] Bad code will have bugs. A bad interface design will fail a usability test. A bad user interview is as obvious as it is uncomfortable. […] A bad survey won’t tell you it’s bad.

And that they might be seductive because they feel like hard data:

Designers often find themselves up against the idea that survey data is better and more reliable than qualitative research just because the number of people it is possible to survey is so much larger than the number of people you can realistically observe or interview. [… But] unless you are very careful with how you sample, you can end up with a lot of bad, biased data that is totally meaningless and opaque.

There’s also this hilarious bit:

Managers love NPS because it was designed to be loveable by managers. It’s simple and concrete and involves fancy consultant math, which makes it seems special. But is this metric as broadly applicable and powerful as it claims to be?

Nah.

NPS is not a research tool. I shouldn’t even be talking about NPS in a research book.

The entire book is worth a read, with a lot more to offer than the pithy quotes I excerpted above. I really liked its pragmatic approach to research that understands the realities of the industry.

Mac allows you to assign keyboard shorcuts to menu items, but the interface is clunky – you have to select the app even if you just came from it, and then type in the menu item name by hand without any assistance:

Other tools, like Keyboard Maestro, do something similar. You either have to type it again, or you can point to it, but in a replica of the menu of the app shown in a very different style and orientation:

But this week I learned of another app, KeyCue, that approaches this differently. You simply point to the menu item and hold the desired key for a while:

Okay, this is not a universal endorsement. The feature works clunkily, and KeyCue as a whole is way too comfortable adding itself to login items without asking.

But as far as singular interactions go, this is great and eye-opening. It made me realize that the previous things I’ve shown – System Settings, Keyboard Maestro – are really not GUIs, and they don’t practice direct manipulation. They’re still partially command line interfaces dressed up in GUI clothing.

We kind of lightly made fun of Jony Ive going angelic on “staying true to the material” and things being “beautifully, unapologetically plastic.” And there is, of course, value in command line and those kinds of approaches. But this part of KeyCue at least is unapologetically a graphical user interface, and it is nice to still be surprised in this space.

Before computer graphics, movies relied on matte paintings to extend or flesh out the background. This is perhaps my favourite matte painting, from the end credits of Die Hard 2:

Turns out, videogames do something similar, except the result is called a skybox, since it has to encompass the player from all sides. It’s another way to use cheap trickery to pretend the world is larger than it is.

This 9-minute video by 3kliksphilip shows a few more advanced skybox tricks from Counter Strike games using the Source engine:

I particularly liked two discoveries:

• In real world, you wouldn’t style backfacing parts, because the player will never be allowed to see from the other side. Here, you don’t even have to render them.
• Modern skyboxes have layers and layers of deceptions: more realistic 3D buildings closer to you, and completely flat bitmaps far away. It almost feels like each skybox contains the history of skybox technology that preceded it.

On the other hand, seeing clouds as flat bitmaps was really disappointing.

Beagle Bros was a 1980s software company making apps for Apple II that is still remembered fondly for their personality.

The company had a hobbyist slant, selling various small tools and collections with fun names like Beagle Bag (in the “Indoor Sports” collection) and DOS Boss and Utility City – similar perhaps to Norton Utilities on the PC side, but with a lot more fun and charisma. This is one of their loading screens, also showing both their recognizable logo and their endearing quirkiness:

The fun and well-photographed interview in Softalk in 1983 starts like this:

How do you understand a man who has three clocks on his wall, showing the time in three different cities-San Diego, Fresno, and Seattle-all, of course, showing the same time (″If anything changes in those cities, we’ll know about it”)?

…and has images like these:

Beagle Bros catalogs and manuals were filled with old-timey woodcut illustrations repurposed to tell jokes:

(I find the anachronistic combination of hedcuts and dot matrix printer typography particularly fascinating.)

Some of their software was more serious; Beagle Bros released many useful tools and even text editing and presentation apps. They also made practical posters:

But other stuff…? It was just goofing off:

How does this relate to craft and quality?

There is this interesting question about how much product and marketing and vibes and lore correlate. Did we forgive Sierra On-Line the numerous flaws of their games because we liked the company? Do we love Panic because we like what they do, or because of how they do it? Did Google put doodles on its homepage to distract people from more nefarious things, or because it just felt like a fun way to celebrate things? Is there such a thing as pure selflessness? What is the nature of free will?

Those are, perhaps, topics for future posts.

But Beagle Bros must have been doing something right if there is still a living, elaborate catalog of their works online, 40+ years later. Jeff Atwood also argued in 2015 that it was more than just fun – or that “fun” itself can give back in great ways:

Here were a bunch of goofballs writing terrible AppleSoft BASIC code like me, but doing it for a living – and clearly having fun in the process. Apparently, the best way to create fun programs for users is to make sure you had fun writing them in the first place.

But more than that, they taught me how much more fun it was to learn by playing with an interactive, dynamic program instead of passively reading about concepts in a book. […]

One of the programs on these Beagle Bros floppies, and I can’t for the life of me remember which one, or in what context this happened, printed the following on the screen: “One day, all books will be interactive and animated.”

I thought, wow. That’s it. That’s what these floppies were trying to be! Interactive, animated textbooks that taught you about programming and the Apple II! Incredible.

Steven Frank, the co-founder of Panic, wrote this in 1999, with similar themes:

You never knew exactly what you were going to get. I remember one program listing printed on the side of a bird that, when run, produced a series of wild chirping noises from the Apple’s speaker. And this was from a program that was only five to ten lines long. As a neophyte BASIC programmer myself, I was stunned and amazed. How could you make something this cool with this small amount of code? […]

Beagle Bros’ tools were fantastic. They literally let you do the (allegedly) impossible, like change the names of operating system commands. And they always packed the disks full with extra stuff. Demos of their other products, and strange graphics hacks that existed for no reason other than the fact that they were cool, and because there was spare room on the disk. Beagle Bros. had a lot to do with why I ever wanted to learn programming in the first place. […]

I’ll never forget the book. […] The book was a huge compilation of all around interesting stuff. Weird Apple II tricks that were pointless, but endlessly fascinating. Like the fact that there were extra offscreen pixels of lo-res graphics memory that you could write to, that never got displayed. Or how to put “impossible” inverted or flashing characters into your disk directory listing. Or how to modify system error messages. Not very useful, but really fun to know and really, really cool to mess with. My dad was convinced I was going to somehow break the computer with all this hacking, but a simple reboot always fixed everything.

(I swear I did think of Panic above as a spiritual successor to Beagle Bros without knowing that their work literally inspired one of the Panic’s founders!)

Frank’s essay provoked more emails, and this excerpt caught my attention:

The subtlety: They had utilities which would produced formatted Basic listings and they would give example output of these utlities in their ads and catalogs. It was quite a while before I realized that most of those examples were not program excerpts, but complete programs which of course contained the Beagle Bros signature weirdness. And then there were the seemingly innocent hex dumps. My favorite was from the cover of one of their catalogs, which had a classic picture of this fellow sitting in a chair. On the floor next to him is a handbag with a piece of tractor paper sticking out. On the paper is a hex dump: 48 45 4C 50 21 20 and so on, which are ASCII codes that spell out the message: “HELP! GET ME OUT! I’M TRAPPED IN HERE!----SOPHIE”

Toward the end of the prolific 1980s, Beagle Beos tried to strike it big by making an integrated office suite:

After the work the company had done on AppleWorks 3.0, Simonsen felt ready to jump into the Macintosh market with a “Mac AppleWorks” of their own – they called it Beagle Works. Unfortunately, other companies – giants in the Mac market such as Microsoft, Claris, and Symantec – had the same idea. Their resources were far greater than Beagle Bros had imagined, and the race was costly.

The gamble killed the company. It’s likely that the changing software market would anyway.

But the years before seem to still inspire some people. Check out the Beagle Bros Repository – the homepage is a bit confusing (I think it prominently shows last-updated or last-added things for some reason?), but just use the nav at the top. Maybe it will inspire you, too.