There are two distinct flavors of speedrunning:

• completing a game as fast as possible through feats of extraordinary mastery, timing, and precision,
• completing a game as fast as possible by finding all sorts of bugs and exploits in the game (commonly known as “glitches”) that allow the player to find eerie shortcuts between areas without having to play them.

Watching the first one feels like watching the Olympics. The second one is absolutely incomprehensible without someone narrating over and explaining things.

This video by Marblr is such narration and explanation of a particular glitch in Portal that significantly shortened a few speedrunning moments:

It’s an hour-long video, and I think it’s a really well-made one, and one you can learn a lot from.

The video has some nice history of strafing – similar in some way to Scroll Lock – and motor memory accommodations. It also shows the source code of Portal to explain things. This is fun on its own, but on top of that, Marblr layers some really cool visualizations – watching how one value “infected” by infinity proceeds to infects the others is riveting.

Even the levels and their geometry are presented in a really beautiful and informative way, too:

I’m still not fully onboard with this branch of speedrunning – if the entry point to your effort is changing mouse sensitivity to an abnormally high value, or if you have to pick a very specific version of the game that just happens not to have patched the glitch you care about, then perhaps things have gotten too esoteric and maybe even academic? But at the very least we get videos like this one – or one I linked to in May – going under the hood of software in some particularly enthralling ways.

I know, I know. I’m supposed to say iPod’s click wheel, or the Western Electric 500 rotary dial, or maybe the first Nest.

But, have you ever played Super Sprint?

It was Super Sprint that had the first amazing rotary controller I’ve ever used, and the whole cabinet design told you the game was very well aware of that.

Super Sprint was a 1986 arcade game from Atari that was, in a nutshell: four cars (at least one computer-controlled), eight tracks, fast races.

You might think that those wheels functioned similarly to a regular car steering wheel, but not really – they were much easier to spin, and needed to travel further to rotate the car. You wouldn’t steer delicately, but rather the opposite: you needed to throw the wheel violently in one direction, and then, at the perfect moment, stop it on a dime:

So the huge wheels were not realistic. Neither were the cars. They accelerated rapidly – the gas pedal was your only other control – and had a ridiculous amount of understeer.

Don’t let the size and intensity of the interface fool you, though: this was a very precise operation. The game was tight – Rollercoaster Tycoon tight or Excel 97 tight, a whole decade before them. In the world awash with slow computers, Super Sprint lived up to its name, laughing latency and delays in their faces. It’s hard for me, even today, to imagine something faster or tighter – and for even my contemporary work, it’s good to remember things can feel this way. And, on top of all that? Better-than-usual sound design, higher-than-usual resolution, shortcuts to reward really good players, and a bunch of great details and easter eggs.

Super Sprint wasn’t Atari’s first attempt here – it was preceded by Sprint 2, Sprint 4, Sprint 8, and Sprint One – and you could tell. It was designed and coded by Kelly Turner and Robert Weatherby, polished as hell, and might have been the first interface between the person, the hardware, and the software that really inspired me. It was almost as much fun to watch three good players compete, as it was to play yourself. But when I played it, it’s possible these were my first – please excuse me here – motor memories.

Atari used the same wheel for other games, famous and obscure, but this was where it met its match in software. I can show that to you, but experiencing it is impossible from afar. Even perfect emulation can’t do it justice – there has simply never been a home controller that approached it. (I mean, the whole cabinet weighed 400 pounds!)

But if you are ever in an old-school-themed arcade, look out for Super Sprint (locations), or its two-player cousin Championship Sprint (locations) – and give it a turn or two.

A few nice moments that caught my attention in Marek Minor’s case study of designing icons for Cursor.

The diagonals for “cancel/​wrong” icons are always backslashes, and all the “positive” icons are always slashes:

There is a system that provides 1-to-1-and-only-1 mapping between a concept and an icon:

The point of the table is that each “What’s the icon for [X]?” has exactly one answer, and keeps having exactly one answer as the product grows. Without it, a set slowly develops two icons for the same idea, and at that point it stops being a system.

And, on the page itself, a few nice blink-comparator-like vehicles with subtle text animations:

Many years ago, I put together a quick proposal of what I called “responsive text” for social proof:

I think you get the idea – instead of dumb truncation, the underlying code could prepare a few strings conveying the information with different levels of specificity, and then the UI could choose the longest one that could still fit.

This idea can apply in a few places. Here, in Figma, one of the menu items switches to a more “compact” string that uses four-letter abbreviations and skips “weight” altogether – but only because there isn’t room for a verbose treatment. You can also compare it with the original, naïve truncation:

Recently, I spotted Jake Archibald, developer working on Firefox, propose something in a similar vein – responsive code:

I think this is a lot more clever and a lot more important. Mobile phones are everywhere. Wrapping code like regular text without understanding it makes it basically impenetrable, but preserving long lines and introducing horizontal scrolling is also frustrating – just in a different way, forcing you to hold more stuff in your head:

I can see Archibald’s solution be very helpful here if used well – and not just on mobile – and perhaps could inspire other kinds of solutions for similar problems (have you ever tried to read any table on Wikipedia on your phone?).

An interesting take from a screen annotation app ScreenBrush – instead of a standard “don’t show again” checkbox modifying a button, it shows two buttons as a fork in a road:

I am not sure I have ever seen it laid out like this before, and I am not sure if it’s good, as it does force a user to make a choice where a choice might not be necessary. In case you are curious, Esc (or click away) is the equivalent to “Got it,” and Enter does nothing at all, which makes the interface somewhat incongruous – the “Don’t show again” button is positioned as a primary command, but takes more effort to invoke.

But what is interesting to me in particular was seeing it next to all of these “Maybe later” buttons that litter user interfaces these days. People seem to generally despise those, and it is refreshing to see a modern UI with a button string that doesn’t hesitate.

A nice moment in iOS – even if you delete an app, you might still be on the hook for its subscription, so the operating system shows this right after deletion:

(Context for the screenshot: I’m only uninstalling Quiche Browser to reinstall it and get back to the pristine onboarding for the previous post.)

Speaking of cut in File Explorer, Will McGugan, creator of the writing editor Ishmael, proposes doing the same thing for text editing – that is, leaving ghost text behind:

I call it “Ghost Cut”, and it works like this: pressing Ctrl+X fades the selected text and makes it inert—you can’t click on the cut text and the cursor just kind of leaps over it, but it is still present in the document. Nothing is placed in the clipboard at this point and there is nothing to undo. If you decide you don’t want to paste then hitting Escape will restore the text to its active editable state.

I do not think this is a good idea. It seems like McGugan proposes somewhat arbitrary reasons that cut and paste are “broken,” and to me the proposal fails even within his own framework: for example, it still doesn’t avoid the reflow, but moves it to the other side, making paste feel unstable (the included JavaScript playground feels disorienting to use). I think it also is at odds with the editor’s own about page, which talks about distraction and simplicity – and yet, what’s introduced here is a host of complex new things: a new visual state for cut text (that looks like AI autocomplete), some new logic to avoid moving into the cut text (which will also prevent easy selection adjustments), likely new confusion around undo, and a necessary new Esc gesture to get rid of a cut you decided not to pursue.

But! There is something interesting in seeing this ghost text, and specific critique aside, it is fun to see experiments like these, with interactive explainers, poking at long-established interactions. Just yesterday, a second one appeared: an interesting new way to extend selection upwards – similar to double and triple clicking on text, but via the keyboard. This is the power of prototyping: sometimes seeing an idea you disagree with is the only thing that can unlock a different solution in your head.

Let’s go back to cut and paste, though. You will notice that what’s listed as a precedent is not File Explorer, but Excel. It also doesn’t immediately remove selected cells on cut, but leave them in a temporary “possibly getting moved or removed” state first, only to have them disappear after paste:

Why is that? I believe out of a similar principle, but a distinct reason that File Explorer too opts to leave a cut ghost behind. The stakes are higher in a different sense: cells refer to other cells. Were the removed cells to disappear immediately, you might witness the rest of the spreadsheet error out or show zeroes, as its formulas start pointing to emptiness.

And it’s a good principle to generally avoid frightening your users.

Here’s an example from Numbers, which doesn’t do ghosting, making cut a bad choice to do a simple move, as it doesn’t even recover after paste:

Dragging and dropping files with your mouse in the Finder is nice, but there are many moments you wanna reach for the keyboard instead. Finder supports that. You dragged the file to a wrong place by accident? ⌘Z can undo it in a jiffy. You already have the right windows open? ⌘C and ⌘V can start a copy faster than the fastest of mouse gestures. And for cutting, there’s always…

…well, no, there isn’t. To the best of my knowledge, the Cut item in the menu never lights up around files or folders; you simply cannot ⌘X or cut in the Finder.

I think I understand the reasoning here. Of the Fantastic Four that is ⌘ZXCV, it’s ⌘X that is the truly dangerous one. Putting something in a clipboard is always a balancing act – a moment of inattention, and ⌘X turns into Delete. We generally accept it for text because the stakes are not very high, and text undo is basically too cheap to meter. Even then, occasionally, disaster strikes.

For files, the stakes are quite a bit higher. The creators of the File Explorer in Windows knew all that – yet, Cut still works there:

The way this is done is that the file isn’t immediately removed and put on the clipboard. No, only the intention of cut is registered – one half of the handshake, if you will – but the file stays put and nothing happens until the deal gets closed via a subsequent paste.

Or, almost nothing. There is a signal that ⌘X took effect – the cut files turn slightly transparent to indicate they put on their shoes and they’re ready to go. But if you don’t finish the paste, they become solid again the moment you cut something else, or when you restart the computer. (I wouldn’t be surprised if there’s a timeout, too, although I couldn’t verify that.)

I am not sure why macOS doesn’t do it the same way, particularly since they have a half-finished state designed already, for copying larger selections:

This feels like a strange omission I don’t fully understand, particularly given that it was vintage Mac OS that put the ⌘XCV combination on the map:

What’s even stranger is that the Finder has a command to move files – but an unusual one, buried inside the secret area in one of the menus, as an ⌥ alt to Paste:

It works. By putting the action on the other side, it avoids the “file floating in outer space” challenge, too. But it’s so undiscoverable that even though Move Item Here was introduced in 2011, I only learned about it a month ago as I started researching this more – and even though I know about it now, it still feels profoundly alien, being on the wrong side of the cut/​paste continental divide.

In a reversal of typical state of things, it feels to me is that it was Mac that did a simple/​cheap thing, and Windows that spent extra effort to dress it up into clothes of an existing Cut for reasons of familiarity, consistency, and better experience. Sure, a keyboard way to move files like Move Item Here is somewhat valuable, but nowhere near as valuable as a traditional cut, put under ⌘X ahead of ⌘V, working the same as everywhere else for years, even for decades, as one of the first denizens of motor memories all around the world.

Phones grow big and their top edges inch closer and closer toward the horizon. Over time, iOS and apps moved some of the important surfaces to the bottom (for better or worse – I still struggle with seeing results and completions appearing above inputs), and the well-designed Reachability gesture helps, too.

Still, the iOS web browser called Quiche Browser chose to tackle the problem, not the symptoms. It offers “Comfort Mode,” where you can ask it to move down the top edge of a bunch of surfaces closer to your fingers:

On top of that, true to the spirit of the app which revels in power-user customization, Quiche Browser allows you to decide precisely where the top should go in order to accommodate different people’s hands, and it even offers to do so per surface:

These are the affected surfaces with the option off and on:

The author, Greg de J., expanded on that on Threads:

While designing Comfort Mode in Quiche Browser, a tricky problem I had to be thoughtful about:

When you hold your phone in your right hand, favorite icons in the top left are harder to reach than ones on the right.

Search suggestions don’t have this problem, since they span the width of the screen.

That’s why favorites need to sit slightly lower than search suggestions, and why Comfort Mode lets you position both independently, so they all stay easy to reach one-handed.

It’s an interesting idea and I wonder if it’s seeing a lot of use.

The only design thought I had was: could the top space be filled or stylized so that this looks more intentional, rather than a potential rendering bug? Reachability does a good job of making it feel physical and adding a little arrow:

Then again, given my job, my brain might be perfectly primed to see rendering errors everywhere.

I’m curious if you know of this pattern that existed for as long as I remember.

On a Mac, you can hold an ⌥ key (Option) whenever any menu is open, and often see more powerful, advanced, or faster variants of existing commands, helpful for a power user. Here’s Audio Hijack and Forklift:

This is not limited to just ⌥. Here in Chrome’s increasingly impenetrable View menu, ⇧ (Shift) works the same way:

And in the Finder’s File menu, both ⇧ and ⌥, and even the rare ⌃ (Ctrl) get to play:

This feels like a nice, thoughtful extension of the command system. It’s clever, too – the key to reveal secret things is the same key you would use for their shortcuts, so you can make the connection either cerebrally or in your fingers.

There are menus that treat it slightly differently, though. Here in Finder and Safari, you can see commands themselves changing when you press ⌥, no shortcut in sight:

(By the way, a nice touch in the entire system: Once the menu gets wider to accommodate longer strings, it doesn’t shrink on key release.)

And in other places, the modifier key only reveals an alternative shortcut for the same command:

I have mixed feelings about this feature.

On one hand, it has felt like dying art for a while now. Apple has never invested in the discoverability here, which I think kneecapped it. As far as I know, there is no hint these exist, and no way to see all of these options easily by clicking something on the screen. Even if you know the alternate name and you search for it, it doesn’t always reveal the key to press to see it natively:

It’s not as much fun to keep pressing all the modifier keys in every menu to find out what might be hiding in there. I wonder if an alternate version where any modifier key reveals all would be better? (And more compatible with commands without modifiers changing anyway.)

On the other hand, I really want this to spread its wings. In theory, the feature makes it possible to build up good motor memory habits, and understand some of the modifier key patterns: ⇧ often means “more,” and ⌥ (ironically) often means “alternate” (try ⌥ while selecting text on a Mac if you haven’t ever done it). It is also a clever way to accommodate power users without blowing up the menus for everyone else.

And, once in a while, I have a truly glorious moment – like what happened to me last year.

I scan a lot of documents, and merge them into PDFs using a database application called DevonThink. The process usually goes like this: I drag individual page files, select them, right click, and choose Merge:

But at the end of that process, I am left with the extra original files I no longer need, so I have to select these, and then delete them:

Not a big deal, but any “not a big deal” becomes a big deal if you have to do it dozens of times a month.

Yet, only after years of doing it this way, I had a thought. More precisely, my fingers had a thought. Surely, more people must be facing this issue? So, on a lark, I pressed ⌥ with the menu open, and saw this:

The precise option I needed was there all along, with a perfect label, hiding exactly in a place and under a key combination that was the first thing my fingers naturally tried.

I smiled so much. It’s a really great feeling when you’re rewarded for learning a pattern, when your motor memory does the job for you, and when you sense you’re on the same wavelength as software’s creators. Someone was there ahead of me and cleaned up this rare path for me.

After two more serious posts in this series, I wanted to stop somewhere a bit more lighthearted and inconsequential.

“Here’a a fun thing you can try,” begins this 13-minute video from Retro Game Mechanics Explained:

The premise of the parlor trick the video describes is a bit convoluted:

• Get your Nintendo Entertainment system, put in the Mario cartridge, and power it on,
• without powering it off, grab the cartridge and replace it with the Tennis cartridge,
• start the game, wait until the music stops, then move around for a bit,
• take that cartridge out and put Mario back in,
• press A+Start and you will see that you will start at a random “invalid” level that doesn’t exist, which should not be possible.

I’ll let you watch the video for a nice explanation, but this I think is a good example of the Swiss Cheese model:

• A+Start is real feature that allows you to continue the new game at the last level you finished (as opposed to Start, which always goes to Level 1).
• The NES allows you to take the cartridges out and put them back in while the machine is under power.
• The creators of Mario decided to make the game reset itself on every game over, and differentiate between cold boot and warm boot in a specific way.
• Tennis doesn’t wipe the memory on start.
• Tennis happens to change the memory in a very particular way that ends up being accidentally “compatible” with Mario.
• The Mario game doesn’t sanitize the level number on entry, so you can start on an invalid/​broken level.

Just like before, the absence of just one of these Swiss Cheese holes would prevent the bug from happening. But the holes line up perfectly.

I found this whole thing kind of fun and delightful, and I actually understood why the creators of Mario decided to reset the game (with a small exception) on every game over – it’s brutal but elegant, and something I found myself wishing was easier to do during various projects I worked on in the last few decades.

Of course, there might be an argument that this is such a highly manufactured scenario (how did anyone even find that out to begin with!?), and of limited value, particularly if you end up at a random level anyway. We will pull on that thread in a future post, because the story doesn’t end here. People who spend time hacking old games go way further than this.

It seems sometimes that browsing the web these days is just constant closing of pop-ups and banners, and ignoring those that cannot be closed:

• old school modals and in-page ads,
• Substack-style “subscribe to my newsletter”on-scroll pop-ups,
• cookie banners and popovers,
• (relatively new) VERIFY YOU ARE HUMAN, HUMAN_ interstitials.

Yeah, it is somewhat unfair to bundle the cookie banners into this list, but stripped down to the user experience, they are a nuisance – the road to hell is paved with tiny, slow close boxes.

Nick Heer at Pixel Envy did the lord’s work of writing a succinct summary of recent efforts to fix this experience, and significant energy expended to derail those efforts.

At the core of it is the Kill the Cookie Banner initiative, which might be somewhat unfortunate naming; while companies like Meta want to get rid of the cookie banners altogether to avoid having to ask the user for any permission (automatic opt in to data collection), the initiative goes the other way, killing the banner but not its plumbing. It proposes an uber cookie banner inside the browser settings that the user could set up once in a “fire-and-forget” way, and all the sites would have to obey automatically without showing any annoying UI themselves.

The site also does a nice job explaining the problem and, if you are in Europe, offers a take action page.

I often link to John Gruber’s Daring Fireball posts with a nod, but this time around I want to offer an opposing point of view. About a month ago, Gruber linked to a Markdown editor written by Sean Malseed in 2026 for the early 1980s Macs, and commented:

I absolutely love that this exists. I don’t like the actual app at all. I guess “full screen” mode is the point of some “distraction free” editors, but I for one would never look twice at a Mac app that didn’t use windows. Full-screen mode just wasn’t a thing back then, except for games. ArtfulType is not a Mac-assed 1984 Mac app.

I posit: It doesn’t have to be. It’s not 1984, after all.

I actually really loved the creator of ArtfulType bringing back a few pieces from the future into the past: the fullscreen/​distraction-free editing, the dark mode menu bar, the shy scrollbar. Those anachronisms felt exciting to me. They made me wonder: What if dark mode was invented decades earlier? What if Mac had a different windowing mechanism? What if we could do it all over again?

I recently linked to Sopwith, which felt interesting in the same way, and I thought I would expand on this and share a few favorite examples of similar projects that inspired me in recent years.

Playdate

Confession: I’m not a fan of Teenage Engineering. I find their products well-put mechanically, but lacking in thought and soul, a certain apotheosis of “capital D Design” that feels as incomplete as it is masturbatory. (Rabbit R1 was a perfect example, consumed by gimmicks and strange design decisions.)

Good news is that Playdate is not a Teenage Engineering project, and that it was actually initiated by the software company Panic, which gave it copious amounts of thoughtfulness and care. Playdate is a 2022 handheld game console, and a fun little device that’s intentionally anachronistic. Its design picks the best parts of each decade: the gadget excitement from the 1980s, the onscreen aesthetics of the 1990s, the social internet of the 2000s, the explosion of indie games from the 2010s, all wrapped in contemporary build quality.

Playdate is partly made out of metal and pleasant to hold and touch in a way no vintage gadgets ever were – this is where Teenage Engineering does deserve a credit – but sports an old-fashioned monochromatic display that seems to be harking back to the darkest years of the first Gameboy… which is very, very deliberate:

I love the black and white, 400 by 240 pixel Playdate screen. I kind of like don’t want to design in anything else anymore,” says [Panic designer] Neven [Mrgan]. “It is so freeing for me, personally, to not think about the color and not think too much about, like, even things like line weight and whatnot. ”

The quote is from a long read about the Playdate’s inception (also available as a well-made podcast ep), which is worth checking out.

Playdate’s games are equally spread across time as if in a horrible time travel accident – some with simple mechanics utilizing the gimmick of a crank, others with much more modern or artful sensibilities. Many, confusingly, with both. Some also come packaged in a novel system of seasons, where the games drip onto your machine at a pre-determined rate, meant to mimic surprises and serendipities one could encounter in record and software stores of yore.

PICO-8

I’ve been profoundly inspired by this talk by Joseph White, explaining his “fantasy console” called PICO-8, introduced in 2015:

PICO-8 is Playdate abstracted away. It flips the world order on its head – emulators are known to emulate existing hardware, but what if they emulated imaginary ones? Why not imagine a gaming console that was never made?

The wild part of this approach is that it automatically gets rid of a lot of unnecessary nostalgia, focusing instead on crafting “hardware” and software precisely calibrated to achieve things White wanted them to achieve.

PICO-8 has a puny 128×128 resolution that makes Playdate feel like IMAX (although with very deliberate 16 colors), and many other constraints that would feel ridiculous even 30 years ago. They are, once again, brought back from the past intentionally – chiefly, to avoid “design fatigue.”

At the same time, PICO-8 doesn’t revel in the past – it also comes with built-in suite of tools, and support for modern keyboard and mouse for development. Its cartridges are not only a single file to allow easy distribution on the web or otherwise – they’re also literally baked into PNG files so the spreading can be even easier.

From a 2016 AV Club article:

White’s software chimera works because he understands where nostalgia ends and the needs of modern development begin. PICO-8’s idiom, for example, is a custom subset of Lua, an easy-to-approach language likely familiar to many game programmers, whether they script emulators or use the free 2D engine LÖVE. Though PICO-8 initially ran BASIC to stay true to its ’80s pedigree, White switched because “Lua has a small footprint and is portable and quite fast. I think any language could have worked though, as long as it allowed the user to mess about in an unstructured way without worrying about programming style.” PICO-8 Lua feels snappy and sensible. There are just enough functions to get up and running quickly without the bulky overhead of complex libraries or object-oriented syntax. Need to draw a sprite? Provide an index and two coordinates. A circle? Coordinates, radius and color. It’s fast and friendly for programming beginners.

The conference talk above and the design of PICO-8 are dripping with intentionality; even the startup chime is meant to evoke a feeling. At some point White went as far as to consider whether his console would glitch nicely if its software was buggy, and then mentions “I designed a [more advanced] PICO-16 just to remind myself to not make that” – a really interesting technique to help him zero in on what he really wanted.

White also expressly states “I value design over content,” which is another thing his project has in common with Playdate.

PICO-8 saw all sorts of software developed for it since 2015 that you can all play online – from the absolute platforming classic Celeste, to a series of unofficial “demakes” like WarCraft III, complex games like SlipWays, or even tools like PicoCAD. The hardware is confusingly powerful enough for Poom (a clone of Doom) to exist, but then there’s also tons of delightful tweetcarts, cartridges whose code used to fit inside a single tweet.

Infinite Mac

PICO-8 started as an emulator for an imaginary thing. Infinite Mac, despite emulating really well-known Macs from the 1980s and 1990s, can also inspire in its imagination.

Made by Mihai Parparita in 2022, Infinite Mac is all about focusing on the right details. Emulators of vintage Macs existed before and, as a matter of fact, Infinite Mac uses those very emulators under the hood. But the glue that holds them together is Infinite Mac’s real and wonderful contribution.

If you’ve ever used an emulator, you know they are usually incredibly unpleasant to set up. You have to find a ROM that fell off of a back of a truck, set up the drives and the media inside, and fight with the poorly-designed settings and a UI that often feels like an afterthought, with the whole thing often feeling more rickety than the very 40-year-old machine it’s trying to approximate.

Infinite Mac awaits you in the browser, literally two clicks away counting this one (there is no step three!). It doesn’t show all the possible options, but curates the most useful machines instead.

The emulation is precise but Infinite Mac also – and this is my favourite thing – breaks the fourth wall in some truly useful ways. You can drag a file into the emulator and it just does the right thing with it. You also set up a magical folder that connects to the host machine both ways, in a way that was simply impossible to do back in the day.

There’s also a CD drawer underneath, and a wonderfully seamless integration with Macintosh Garden’s library of vintage software.

It’s the same story as with Playdate and PICO-8: a lot of intentionality and effort and cherrypicking so you get the best of an earlier experience without the worst of it. Pick a Mac, and use it without worry; Infinite Mac keeps the Macs both faster and more reliable than they used to be. (In a beautiful repudiation of modern software practices, I have heard of people who launch Infinite Mac to write in old word processors not just because they’re simpler, but also because they’re faster than the modern native apps.)

Parparita occasionally writes about the project on his blog; those entries are rather technical, but sometimes also highlight various design considerations (I particularly enjoyed the NeXTSTEP entry).

Epilogue

I was at the Vintage Computer Festival West recently, and for the first time I noticed how many young people were there. This got me excited. It’s one thing to revisit those old machines just to relive your own years of (likely imagined) glory, but yet another to see people see them as inspiration: to encounter computers that were simpler, unencumbered, unenshittified, and with software you could understand, remix, and own.

I hope some of those people find inspiration in the past without succumbing to it as a whole, pushing and pulling on it like the creators of Playdate, PICO-8, and Infinite Mac did.

I think that kind of push and pull is important, especially today. I don’t love using Google Sheets, but my favourite spreadsheet is not Excel 97, either. My favourite spreadsheet is some hypothetical anachronistic version of Excel 97 that also has modern high-dpi typography, and a ⌘K command palette, and today’s trackpad gestures, and support for AVIF and HEIC.

Of course, there is immense value in studying the past just so we know what was already made or just explored, what is worth being aware of, and what could deserve remixing. But it’s not great to get stuck in history.

When you venture out to do some time travelling, you get the booklet with all the rules: don’t interact with another version of you, don’t flirt with your mother, definitely steer away from any butterflies. I love that these projects, and others like them, ignore all those rules.

The title of the post comes from the Playdate’s making of essay.

I mentioned Atari’s Pong recently, a game often considered to be the first videogame ever. It wasn’t, and as a matter of fact, it was a clone of one of the games from the first home console Magnavox Odyssey, released earlier in 1972:

This is a 34-minute video by FrameRater walking through the console and all of its strange games:

I found it a very interesting case study. The Odyssey had a version of Pong before Pong – but it also had many other games that could be charitably described as “Pongs in disguise.”

It all feels very, very convoluted for such a simple concept. You have to insert the right cart, tape an overlay to your TV of a certain size (the roll of tape is included), and understand the complex and poorly written instructions in the manual. Then, during the play time, you’d have to master the very strange controllers (left dial – horizontal movement, right dial – vertical movement), often do a lot of work that the console didn’t do (keeping track of collisions, or even scoring!), and deal will all sorts of accessories in the real world, like included cards, dice, stickers, and so on.

You can admire the scope of this all – when life gives you Pong, you make a pongolade – but it all feels so clunky and convoluted, which the video catalogs in detail. But, in hindsight, it doesn’t matter if the included Pong (here, called Table Tennis) is good, right?

Reader, Table Tennis wasn’t good at all. It wasn’t just the strange controllers, but also the really weird logic where you could twist the ball already in flight:

Only looking at this made me realize, some 50+ years too late, the true power of Pong.

Pong didn’t bother with many games, with complicated rules, with the breadth of it all. It just did one thing really, really well.

For the Odyssey, it seemed like a lot of games were about mastering the controller. For Pong, it was only ever about mastering the game. The interface was simple: you have one dial, so rotate it. The game was fun to play, with its logic both challenging and predictable. The instructions were sparse and barely needed anyway. There was automatic scoring, which Odyssey didn’t have. There were also sounds – turns out, people really liked sounds.

The Odyssey was clearly an in-betweener, a complicated hybrid device weighed down by its well-intentioned maximalism. Pong was simple, attractive, optimized to the bone. I feel that it offers universal lessons, feeling eerily similar to iPod’s release in 2001 – focusing on just the few things that mattered, and doing them really, really well.

One of the small things I added to Medium in early 2016 was a change to the favicon:

It came from an observation about the writing process. When writing on Medium, you are likely to have a bunch of Medium tabs open with other posts, yours or otherwise, for reference… but you usually only have one tab you’re writing in. Why not make it extra visible so that you can easily come back to it?

But there was a second, more emotional reason. Writing is hard. Many people never touch the “New story” button, on Medium or otherwise. I wanted the writers to feel extra amazing, with the interface itself giving them a nod of recognition. (Visually, the hollow draft icon was also meant to be a “scaffolding” of the published story icon.)

I’d love to hear more about websites or web apps that are using favicons in a particularly useful or delightful fashion. If you have examples, I would appreciate a note!

If you haven’t played Kern Type yet, you’re in for a treat – released by Mark MacKay in 2011, it’s a delightful browser game that teaches you the art and the math of text kerning:

If you have played it, you’re still in for a treat, as MacKay under the Method of Action label released a few similar games since:

• The Boolean Game (2019)
• The Bézier Game (2014)
• Color: A Color Matching Game (2012)
• ShapeType: A Letter Shaping Game (2011)

They’re interesting not just because you can explore the feel of visual, typographical, and color craft by play – but also because they’re also really nicely made explainers. Here, you can learn things, but also learn about making things that teach things.

For example, I liked the thoughtful onboarding, animations, and sound design of The Boolean Game, the keyboard navigation in Kern Type, and this general idea present in a few games that it’s fun to learn by fixing slightly broken things, rather than starting from scratch.

As far as I can tell, MacKay also occasionally revisits the older games, so Kern Type today might feel much better than when you played it last. MacKay also vibecoded a quick aspect ratio game, and is thinking of a new game to teach text editing, which excites me to no end.

I added a new tag to Unsung, #explainer, to cover explainers and playgrounds like these.

A fascinating 11-minute video by Modern Vintage Gamer about the PC videogame piracy in the 1990s:

This is a “no honor among thieves” story about a few groups racing to pirate and release one of the most important videogames in history: 1996’s Quake.

There is a lot of interesting vernacular here: leetspeak, nfo files, cracktros, ASCII art, BBSes, IRC, a bunch of slang, and even specific font styles. At the same time there is also some unexpected bureaucracy – apparently videogame pirates had sort of a governing body, which perhaps was also somewhat corrupt?

In 2018, Tom Cruise and Christopher McQuarrie teamed up to make a short PSA about the dangers of frame rate interpolation, a.k.a. the soap opera effect:

It’s a strangely boring video from the men known for exciting filmmaking, but it captures a fascinating debate. TL; DR of their argument: Home TVs have an option to take a typical 24fps movie and create interim frames to make it feel like a 60fps production. It’s often on by default, but you should turn it off.

What’s interesting is that 60 or more fps is indeed in some ways objectively better: you see smoother movement, and you can notice more. Once you start paying attention, any whip pan or drastic movement in the cinematic 24fps appears very choppy…

…and, of course, that is completely missing the point. The argument for 24fps is that it’s simply cinema’s vernacular, right next to anamorphic lenses with their blue lens flares and vertical stretching. The movies are not about conveying information, but they are about conveying a certain feel. (And also, about tradition.)

I’m mentioning this because I spotted a similar battle happening when it comes to scrolling.

Go to any page in Vivaldi and hold a down arrow key for a while. That scrolls through the page, moving it in chunks, reacting immediately to the initial key press and then the synthesized autorepeat presses:

Firefox listens to the keys the same way, but it “upgrades” the choppiness to a 60fps movement by interpolating it:

And Safari does something different altogether – it approaches it more like a game physics engine would. It only listens to ↓ down (when it turns on the scrolling “motor”) and then ↓ up (when it turns it off):

This has an interesting effect: the movement is smoother than even Firefox’s – that’s because it doesn’t try to straighten something choppy, but it is itself smooth, by nature.

At the same time, this approach feels a bit loose, like driving an old 1960s car. It also takes away any control of speed; Safari pages always scroll at this rate, no matter your keyboard settings. (Arguably, however, control via the key repeat rate that other browsers respect is also an illusion, as it affects typing as well. Would you ever change it just to control the scroll speed?)

Of course, the analogy to frame interpolation doesn’t really make sense. Safari is not a soap opera, Firefox is not a smooth motion effect on your TV, and Vivaldi is not a cinematic experience. In contrast with movies and television, I don’t think there are any expectations or tradition here.

In this particular context, I believe Firefox and particularly Safari are better because this is about conveying information, and smoother scrolling does help your eyes and your brain connect all the little befores with all the little afters.

But I am sharing it mostly as a reminder that a keyboard is really just a button board by a different name. And sometimes it’s good to look at a key hold, and decide:

• is this a sequence of pulsating key presses,
• or is it a button being held down and then released up?

An interesting mechanism in YouTube I just learned of.

If you right click once, you get their context menu:

If you right click again, you get the native browser menu:

This is clunky and not discoverable, but I can see YouTube team’s bind here. As far as I know, it is not possible to extend browser’s native right click menu (even with user’s consent), or invoke it in some other way (so that, for example, they could have an entry point to the native menu in their menu).

At the same time it does feel like the correct use of a right click menu, to host quick functions like Miniplayer or Copy Video URL At Current Time or Copy Embed Code – and, you can also see how Chrome’s own menu has a lot of cruft in it.

In a way, this might be what is often called a “progressive enhancement.” It is better than blocking the native menu altogether, and I cannot think of any smarter alternative given the constraints. But it is clunky, as things often are when websites venture out to become web apps.

Have you ever seen this?

The best way to predict the future is t̷o̶ ì̴͇n̵͓̆v̶̝̕ȇ̷̝͈̩͊̇̾̄̂̀̈̔̀͛͋͆̓͒͘͝ͅn̸̦̙̣̤͓̜̼͙̲͔̺͚̮̬͆̇̇͐̇̽̒̎t̵̮͎̃̒͒̋̂̏̒̀̿͌͗̄͑̀̀͒̈̚͠͝ ȋ̸̧̛̭̠͈̰̰̦̹̥̜̖̈̂̀̽̿̋̊́̇̍̓̆̉̄̄̊͊̒̎͋̂̒̍̽̄͝ͅt̶̨̢̺̱̻̭̣͉͕̥͚̯͍̣͕͔̬̥͔̘̼͌̉̀̄̊̆͛̽̍̐̔̐̀̾̋̆͒̏̏̋͋̽͗̌͋͗.̸̧̨̧̡̢̪͙̦͙̝̜̦̞̳̤͖̟͍̮͖̘̙̳͉̳̲̲͉̠͎̽̍̓̒̅̿͂͑̎͊̋͒̈́̅̈́̆̽̒͛͐͛̉̀̈́̈̉̏̏̋̒͘͝͝͝

In the lore of the web, this kind of a strange glitchy text is known as Zalgo:

Zalgo is a meme where a popular picture/​comic is edited in a way that “corrupts” it, producing scary results. The term “Zalgo” refers to the being apparently responsible for the corruption, whose name is uttered by its victims in an eldritch manner.

I’ll let you read up on that at the above link if you are curious, but what’s interesting for us here is that… Zalgo is text. You can grab the line above. You can copy and paste it. You can even try to edit it. But… what is that, and why is it possible to construct text this way?

In Unicode, ä is a completely independent character from ą, and they are both completely unrelated to a – any type designer treats them as a variant of the same base letter, but there’s nothing preventing them from making them look very, very different.

But now think of the Vietnamese language, which has six tones mapping to six accent characters, and many of them can be combined into pairs:

This gives us 104 accented letters, and 30 doubly accented letters, just for this one language.

Sure, you can imagine adding all of them as independent characters, but at some point another idea appears on the table: What if we just allowed a system where you can add an accent to any letter?

Instead of outputting ä as one letter, you could output a followed by ̈  , which then would be recombined by the rendering logic into ä. And to get two accents, output a and then ́   and   ͆  , to get á͆.

Now, the zero-one-infinity rule says that once you open the door to two, you might as well allow three or even more. Add to it the fact that some accents go under the letter, and here you go: perfect conditions for the Zalgo meme that just creatively stacks up accents one after another – not for communication, but solely for aesthetics.

Today, there are a whopping 122 combining diacritical marks used in all sorts of occasions, and Zalgo generators know about them all. A fun thing to try in one of them is to let it do its thing, and then keep pressing Backspace:

Now you might ask, why do separate characters exist for ä and ą then? Why isn’t every accent combining? Two things: history (some pre-combined accented characters existed for as long as movable type was around) and complexity (combining accents are harder to process, to display, to edit, and even to design). There were many debates around this – you can open the History box on the above Wikipedia page and pore over the old documents to learn. (As a matter of fact, today all Vietnamese letters exist as precombined characters, too.)

A few bits that might be useful to know:

• Zalgo is a good reminder that while it’s hard to contain text, you can at least crop it – often you might see things like these, where in some places Zalgo is allowed to roam free, and in others the text is clipped so three or more accents fall outside of the clipped area.

• Eagle-eyed among you might have noticed above that ä and á͆ look different. As far as I understand, if the combination of a letter and accents isn’t supported by the current font, the entire combination falls back to a different font, rather than picking bits and pieces from different fonts.
• There are even more combining characters, and emoji use a similar system to add skin tone modifiers, gender, or turn a woman next to a fire truck into a female firefighter.

Lastly, I found this warning on the very Fandom page that explained Zalgo amusing:

Do not post Zalgo text in the discussion area or anywhere else on the wiki. Doing so will subject you to a ban.

Every warning tells a story; it seemed like more people were perhaps infatuated with the glitchy text than expected.

Nice recent addition to Gmail – a little warning if you’re replying to a thread you were BCC’ed on.

Please note that I’m not necessarily endorsing the execution details, as I consider Gmail kind of a clunky operation overall. You can’t swat the message away with a swipe, the wrong quotation mark is used, and I’m perplexed about the location of this message – something tells me it was really cheap to do it this way rather than put it close to the recipient field, to help you understand the relation.

But still, I appreciate something shining at least a bit of light at the complex relations between To, CC, and BCC.

I spotted this kind of a keyboard shortcut pattern the other day. Here it is in Photoshop:

Here it is in DevonThink:

And here in Linear:

Those “ordinal” keyboard shortcuts feel nice and orderly, and look so elegant, too. But beware! The moment you’ll want to introduce a new option, or even reorder the ones you have, you’ll be in trouble: Either you preserve people’s motor memories, and then the elegant ordering immediately goes to hell – or you will have to change an existing shortcut to something new, and frustrate your users. Might be best to be really confident in your selection being forever locked before attempting this.

But then there’s a similar treatment here in Linear:

Or here in Raycast (when you hold ⌘):

Or here in Ghostty:

Those three look like the same idea, but they worry me less.

Why? Because these shortcuts more clearly point to a position rather than a thing. Here, the mechanics of the UI themselves convey that people, commands, or tabs are going to be moving around. Of course, some will get used to “1 means assigning to Marcin,” or “⌘3 means the Unsung tab” – the same way we get used to “second item on the Recent list” or “at the top of the third search result page,” if they start repeating as a pattern – but at least it feels to me that the interface here is more honest about what it can promise.

I often think about this, by the way: Not what the interface conveys in the moment, but what it promises in the long run.

For all these times we talked about Super Mario, we never covered another important game, Doom.

Here’s a 17-minute video from decino explaining how the Doom monsters move and attack the player (the “AI” in the old sense of the word):

What’s really fun about this video is how it uses annotated source code (in contrast to Super Mario, the Doom source code was officially released and open sourced), and particularly how it tasks the engine with explaining itself, setting sometimes elaborate stages just to show a principle or an algorithm – an absolutely perfect example of “show, don’t tell.”

decino has tons more of these kinds of videos (click on Popular!), distinguishable by their yellow covers, if you want to pick another aspect of Doom that interests you.

I like learning new things, and I like learning new old things. I was looking at Apple Human Interface Guidelines from 1987 and this passage caught my attention:

The most common use of double-clicking is as a shortcut way to perform an action. For example, clicking twice on an icon is a faster way to open it than clicking once to select it, then choosing Open from the File menu; clicking twice on a word to select it is faster than dragging through it.

I knew that double click an icon was a shortcut to the first action (typically Open), but I never really thought of double-clicking a word as a faster way to drag across to select it – even though, in hindsight, it makes perfect sense.

Another vintage thing I learned of recently from a coworker is this, also covered in the 1987 HIG:

If the user begins a double-click sequence, but then drags the mouse between the mouse- down and the mouse-up of the second click, the selection becomes a range of words rather than a single word.

This doesn’t feel (to me) like a very pleasant gesture to perform repeatedly, but what feels nice about it is that it automatically snaps the selection to the endings of the words:

Part of me would prefer this to be the default behaviour when selecting more than 3 words, or so, so you could be less precise.

Anyway. The double clicking to perform default action applies to a lot of lists of things. Here are some examples from Scrivener, Word, and Lightroom – you can double click on each of these items to proceed, without having to select and click the button:

But sometimes the creators of such dialogs forget. Here’s Screen Sharing in MacOS, and a notification in Chrome where only the slow path is available – double clicking on items doesn’t do anything:

The tricky part about not being a good citizen of a shared user interface is that those omissions aren’t just local to your app – they can ruin the gesture in other places, as people’s fingers learn to distrust it in not just your app, but in general.

(The quote in the title is from Apple Macintosh User’s Handbook.)

The Touch Bar arrived in 2016 seemingly already pre-doomed, on a generation of machines that had a “we’ve run out of ideas” smell all around them. The arrow keys were reshaped, the keyboard got a slimming down, and even the beloved MagSafe wasn’t, in fact, safe. All of these changes would prove unpopular and get reverted in time, and the axe would eventually come for the Touch Bar, too.

With an enormous benefit of hindsight, a decade after its arrival, and on the (rumored) eve of fully multitouch MacBooks, I wanted to look critically at the Touch Bar in more detail. I put a spicy title above this post, and while I’m not sure I can answer it in the affirmative, I feel I got surprisingly close to that.

What did the Touch Bar do?

The Touch Bar replaced the top row of the keyboard with a narrow touch screen and a Touch ID surface/​button on the right.

The touch screen provided a constant virtual Esc key on the left, and the remainder could become one of a few things:

• app controls – whatever the app wanted (either buttons or more interactive surfaces):

• control strip – roughly the same as what function keys do today by default (brightness, transport controls, volume):

• a hybrid mode of smaller app controls on the left, and expandable control strip on the right:

• F1–F12 keys:

• a few smaller modes, like showing spaces, quick actions, or emoji:

• small submodes where only the middle of the Touch Bar would be taken over:

The Verge has a five-minute video that shows a lot of this stuff nicely.

Functionality

Touch Bar arrived with a hybrid of functionality for casual and pro users – some built into the macOS itself, and some coming from specific Apple-owned apps.

A few apps offered basically a subset of their toolbars (although often without customization), with an occasional submenu, like digging deeper into font options or choosing a color adjustment. Some apps like Safari and Photo would invest in tiny previews of objects.

Particularly demo-friendly were sliders for volume and brightness, and those in specific apps – playback in QuickTime, or swiping through the photo gallery, clearly inspired by similar controls on the iPhone. Even though Touch Bar was referred to as “multitouch,” it really only supported tapping and horizontal swiping, with just the latter being something classic function keys clearly couldn’t do.

A simple but effective was also an arrow pointing to Touch ID authorization and payments – a small example of software proprioception – which Apple even included as a GIF in their press release:

But there were also some strange moments, the strategy feeling a bit like “let’s throw a lot of stuff at this and see what sticks” (then again, it worked for the first Apple Watch!):

• Any system dialog would show its buttons repeated in the Touch Bar. This felt puzzling to me, as those were already served well by both mouse interactions and keyboard (Esc/​Enter).

• It was nice that you could drag the volume or brightness control, but then the slider would be disconnected from your finger and the volume would also appear in the old HUD on the screen, altogether feeling like different parts of the system weren’t aware of each other.

• Xcode offered a button to comment out the current line or selection, which must have felt almost insulting to programmers – is there anyone who’d prefer that over the ⌘/ key combination?

Lastly, for the first edition, the IA felt complex:

• Word completion was in the middle of the bar, but the emoji entry point was on the left.
• There were many kinds of chevrons (at least three!), and the action didn’t fully match their arrows – some of the chevrons indeed made the controls expand in an expected direction, but some instead drilled deeper and took half of the bar, and others took over the whole thing. (On top of that, some controls had regular horizontal scrolling.)

• Some controls that looked like regular buttons expanded on tap, too, so in effect it was never truly clear what a control would do when touched.
• The close boxes were sometimes on the left, and sometimes on the right of the buttons.

Settings

Strangely for such a high-profile feature, the Touch Bar settings arrived sprinkled in between older keyboard options, rather than in a separate Touch Bar tab that could help you understand the whole system easier, and also perhaps offer nice previews of what was possible.

Apple’s penchant to brand even small things also backfired a little bit – customizing the Touch Bar required facing strange phrases like Quick Actions, App Controls, and Control Strip (this is where the usually non-nostalgic Apple reused a classic name, rather than naming it System Controls to mirror App Controls).

On the other hand, the Customize Control Strip interaction here was an absolute highlight, providing a magical-feeling bridge between the world of the Touch Bar and the heavens above it – this was perhaps the best-designed part of the whole system:

(That kind of customization was also available in some, but not all of the apps that supported the Touch Bar.)

By the way, Apple seems to have learned the settings lesson since 2016, or even overlearned; the action button introduced to the iPhone in 2023 came with a lavish new interface:

First public reactions and the evolution

Back in 2016, the Touch Bar arrived to muted optimism (“not great, perhaps promising, looking forward to season two and three”), mixed with loud frustration from seemingly every single person who relied on the physical Esc key.

Touch Bar was only revisited once, in 2019; this slight update reintroduced a mechanical Esc key, and felt slightly faster in use.

There were no other hardware improvements, and I believe zero software changes from Apple’s side during the whole lifetime of the feature. Some third-party apps added Touch Bar support in the first few years, but even then the verdict seemed somewhat reserved:

Most Final Cut Pro power users will be so used to using keyboard shortcuts for the editing functions they use regularly that they may not find the Touch Bar any quicker for simple editing and playback, but the sheer number of context-dependent settings means it’s likely to prove its value eventually.

The Touch Bar never made it to non-Pro MacBooks or other computers, and started being phased out altogether five years after its arrival. Perplexingly and for reasons we might never know, the project was “maintenanced” almost as soon as it launched, and it wasn’t immediately removed perhaps only to save face.

Haptics and ergonomics

Touch Bar felt unpleasant to fingers.

People’s ire around the Esc key was mostly in how “dead” it felt next to the other keys, which was especially important for something further in the periphery, used as an escape hatch or as a core interaction by programmers. (The key was also slightly offset, likely only to preserve symmetry vis-à-vis Touch ID on the other side.)

I bet that the unavoidable and constant comparison of the feel of the Touch Bar buttons to the real keys just below was what made the whole thing feel worse than it was, and I’ve always wondered if haptics could have helped here. What if a light touch offered gentle haptic feedback similar to feeling the “ridges” of the keys without pressing them, and a deeper press offered a proper haptic tap?

Already in 2016, Apple had similar tech in the trackpad underneath. I bet I’m underestimating how hard or expensive it would be to repurpose it, but: the iPods never had true haptic feedback, yet even in the first model they arrived with a little speaker that emitted haptic-like sounds on actions. It was surprisingly effective, and I was curious why Apple didn’t do the same thing here.

On top of that, while the row of function keys above is fun for an occasional press, it doesn’t ergonomically seem as great in prolonged use. Reaching up to the Touch Bar is more effort than reaching for the trackpad, whether you put it below or to the side – there’s a reason keyboards grow wider but they rarely grow taller. In The Verge video above, you can see the reviewer use a Touch Bar button as a modifier key while interacting with the trackpad below, and it feels unpleasant just watching that happen:

On top of that, the Touch Bar surface sat lower than the surface of the keys, which made it ever so slightly less pleasant to use – it didn’t only feel like it was above the keys, but also behind them.

There were other rough edges that added up:

• The Touch Bar would go to sleep eagerly (after only 60+15 seconds), hiding all its controls and forcing you to tap it or press a key to wake it up.
• The quality of the animations was not the same as on the other touch devices or the Apple TV.

• While the Touch Bar itself was fast enough to support smooth scrolling, there was also some (I think intentional) delay when pressing the Fn key and some Touch Bar controls, plus a general slight, but perceivable latency on every touch.
• Speaking of scrolling, it was uneven: in Calendar, you could use momentum scrolling but the calendar didn’t update in real time, and stopping the momentum by tapping anywhere like on the iPhone actually selected a different month:

• Often the only way to escape a submode was to press a close box on the left, which was unpleasant given the position of your hand; there was no thoughtful shortcut, like double tapping an option, to exit faster.

Size

Using the Touch Bar was being constantly aware of its small size: The previews were tiny, your fingers overlapped content all the time, and scrolling only happened in the horizontal plane. (And you had to keep your finger in a straight line instead of a slight arc – not a natural gesture.)

Expanding the Control Strip required tapping on a very small chevron; there were tons of those tiny chevrons elsewhere, too, narrow and hard to press without haptic feedback. It made the interface feel fiddly, a strange compromise from a company that thoughtfully established and enforced the “44 pixels” minimum size for touch targets with the first iPhone. (The chevrons were exactly half of the recommended minimal physical width of any touch target on the 2007 iPhone – 3.5mm instead of 7mm.)

Many spaces felt tight in other ways, too. Craig Federighi’s keynote demo showing Safari previews was claustrophobic with just five tabs:

When using any typing surface, the Touch Bar would get divided into three areas: app controls, suggested words, and control strip on the right:

In other apps, some areas were scrollable, but there was no room for a scrollbar. Using the Touch Bar in any meaningful capacity felt like constantly guessing what’s movable and what isn’t, and constantly resizing tiny virtual windows, except without any pleasant resizing mechanics from Apple’s larger screens. Here, the emoji pane UI is doing some really clever things to help traverse hundreds of emoji, yet it still feels not enough:

The interactions in photo editing and a few other places felt so cramped and convoluted that I wonder why anyone would choose them over the spaciousness and precision of the screen above.

I wonder if the limited height also created other downstream effects. For example, drilling down did a (slow) fadeout/​fade in effect, instead of scrolling down and up to help you understand the hierarchy – and showing the chevron pointing in that direction, too. I am guessing that was because the movement would suggest you can swipe up and down, and there simply wasn’t enough room for that gesture to feel good.

Using the Touch Bar, I kept thinking of the wonderful customization feature I mentioned that cleverly fused the Touch Bar with the screen above, and also a similar interaction from a 1980s Xerox machine (where pressing the key below More would show other options):

Could this have worked for other Touch Bar interactions to create more room, or would it become frustrating as your fingers would naturally want to tap the bottom of the screen? There is a small thoughtful integration like this in text editing, where the Touch Bar seems to be aware that while your fingers are downstairs, you might be looking up:

But then, in the same place, choosing a color is not integrated the same way:

All in all, the Touch Bar was new I/O sandwiched between an old O and an even older I, and it didn’t seem like all the relationships here were fully figured out.

Could Touch Bar just grow larger? Asus Zenbook Pro showed the endgame of this idea – it enabled some new interesting things, but threw in tons of more challenges like a missing trackpad, or deciding what to put on each surface:

I wouldn’t expect Touch Bar to go nearly as far, but I was curious to see it grow a little bit vertically to alleviate some of the pains.

Customization and infrastructure

Apple bet the Touch Bar house on individual app built-in support and a few core interactions. But I wonder in hindsight if the answer was user customization.

On that front, the Touch Bar exposed Apple’s underinvestment in the actions infrastructure. Keyboard customization in macOS has already felt ancient in 2016 and did not improve since, and Shortcuts app didn’t even exist then. This was Apple’s chance to provide a gentler Keyboard Maestro-like experience for the masses, but the Touch Bar didn’t allow you to plop in even a few function keys alongside the new features – the only option for that was the old-fashioned mode with F1–F12 with none of the benefits of the Touch Bar (you couldn’t even change the labels!), and also without haptics.

Sure, there was a gesture in this direction with Quick Actions, but those felt extremely underbaked; in my explorations with Automator and Touch Bar, I encountered some truly confusing settings and flows and could never make it work fully. Here, I had to go to a faraway System Preferences pane, and see various Quick Actions that were not talking to one another:

In a better setup, it would be possible to assign any key or action or menu command to any ground-floor Touch Bar button; something like SF Symbols (formalized in 2019) could provide all the necessary icons. Or, one could imagine some delightful integrated interactions like this one that would make it easy and pleasant to make the Touch Bar feel personally useful.

Or, how about sparklines or other tiny widgets that’d quickly show visual status, of the kind pro users like to put in the menu bar already, and easily pluggable to data sources (see the very recent TerminalWidget)? Or a left/​right slide gesture, buttons, or a keyboard combination to swap between Touch Bar “spaces”?

How about learning what commands you use most often that don’t have keyboard shortcuts, per app, and suggesting them as the first five buttons on the Touch Bar?

Could the Touch Bar have been saved?

Today, it often feels like the Touch Bar chose revolution in the moments the right answer was evolution, and evolution in places that called for a revolution. With hindsight, after seeing projects like Stream Deck and Flux Keyboard capture people’s attention, maybe it could have worked this way:

• First version arrives with a physical Esc or at least “sound-based haptics,” and allows you to do more things via much nicer settings software: easy assigning of buttons to system actions, and icons so you no longer have to remember whether it was F3 or F7 doing your thing. Don’t treat the Touch Bar as repudiation of function keys, but as their enhancement. On top of that, add some easy-to-put-together widgetlets and sparklines. This is Pro hardware, and these feel like pro features.
• Staying tighter, focused, and reigning in some more complex interactions would help, too (problem: they look so good in videos!). Instead of boiling the ocean and recreating a lot of the existing GUI in a cramped space, focus on just one–two great interactions per app. Finder: Show the Quick Actions that were already customizable and not as easy to access in some views! Emoji: Paginate instead of scroll, but do a really clever pagination that highlights the power of a parallax swipe gesture that can only exist here. System: Add immediate screenshotting by default.
• If this worked, subsequent versions would add haptics, perhaps increase the size, and go mainstream from pro users to regular users, learning all the useful lessons along the way (also from third-party apps like Pock).

But I’m not sure. Touch is fun but there is, ultimately, a ceiling on value you can squeeze out of a small touch strip, and a floor on complexity of yet another input/​output device.

And there was always an elephant in the hardware room – many pro users are likely to use computers on desks with separate keyboards, which puts the Touch Bar either too far away or makes it altogether inaccessible. In the decade since, Apple hasn’t even solved this for Touch ID, the only part of the Touch Bar that didn’t get sacrificed to the angry IBM 3270 terminal gods.

Would the Touch Bar have worked as a standalone device? Could it ever become good enough for you to want to pay for it twice?

Perhaps not. But had Apple improved the keyboard and action customization software for the Touch Bar, only to see it crash and burn, we could at least still keep the software.

Following (or, preceding) the previous post…

1.

Old computers loved 8×8 fonts and they also loved 8×8 graphics.

Since for many of those computers the graphics were displayed side by side without any gaps, the fonts had to waste a precious pixel or two to create some breathing room between the characters. But there was a benefit to this arrangement – you could seamlessly combine two or more tiles into something bigger.

You could see that already in built-in graphics for a late 1970s computer Ohio Scientific Challenger 1P: a lot of single-character graphics of houses, tanks, planes, and people – but also some that only made sense fused together, forming submarines, warships, or the U.S.S. Enterprise:

A later computer called Atari ST had an Atari logo spread across two characters, and an easter egg – a 16×16 face of “Bob”.

And Apple II’s character set allowed to combine a few glyphs into a running man, a folder, or a scrollbar:

Arcade videogames did the same. Pac-Man’s maze was assembled out of solitary 8×8 characters, but Pac-Man and his frenemies were large, clocking in at 16×16:

You can even spot a fascinating technique above. The ghost could cleanly fit in a 2×2 grid, but instead it’s offset vertically and takes up a 2×3 slot. Why? Just so the eyes and the “skirt” could move independently without a combinatorial explosion of tiles needed:

2.

Not long ago, we looked at various installation graphics for Mac OS X apps. Those creatively used a new feature of Finder: a way to specify a background image.

The Finder before Mac OS X, from 1984 to the late 1990s, didn’t have that feature, and yet you could occasionally see something like this:

How was it done? By splitting the graphics into many 32×32 icons, and then positioning them carefully inside the window.

The icons weren’t proxies of apps or even images. They were just there. The last ingredient was names composed of only whitespace, and it all started looking like one unbroken huge image… except when you invoked the Clean Up function, which proceeded to ruin the whole thing in a particularly delightful fashion:

3.

Ever since its launch in 2014, Slack allowed anyone at any workplace to create custom, shared emoji, and starting a year later, people could also use them in their reactions.

Those proved to be very popular, and many books could be written about how custom emoji reflect a given organization’s culture.

Many emoji could also be output side by side, and Slack chose not to put any space between them:

I think by now you know where this is going.

People started splicing bigger images into smaller emoji, first by hand…

…then with limited automation, and then via fully automated tools with names like slack-big-emoji or slack-emoji-enlarger:

As in every other version of this technique, assembling the tiles the proper way is part of the challenge. The one above looks like this:

:tjp3-000::tjp3-001::tjp3-002::tjp3-003::tjp3-004::tjp3-005::tjp3-006::tjp3-007::tjp3-008::tjp3-009::tjp3-010::tjp3-011::tjp3-012::tjp3-013::tjp3-014::tjp3-015::tjp3-016::tjp3-017::tjp3-018::tjp3-019:
:tjp3-020::tjp3-021::tjp3-022::tjp3-023::tjp3-024::tjp3-025::tjp3-026::tjp3-027::tjp3-028::tjp3-029::tjp3-030::tjp3-031::tjp3-032::tjp3-033::tjp3-034::tjp3-035::tjp3-036::tjp3-037::tjp3-038::tjp3-039:
:tjp3-040::tjp3-041::tjp3-042::tjp3-043::tjp3-044::tjp3-045::tjp3-046::tjp3-047::tjp3-048::tjp3-049::tjp3-050::tjp3-051::tjp3-052::tjp3-053::tjp3-054::tjp3-055::tjp3-056::tjp3-057::tjp3-058::tjp3-059:
:tjp3-060::tjp3-061::tjp3-062::tjp3-063::tjp3-064::tjp3-065::tjp3-066::tjp3-067::tjp3-068::tjp3-069::tjp3-070::tjp3-071::tjp3-072::tjp3-073::tjp3-074::tjp3-075::tjp3-076::tjp3-077::tjp3-078::tjp3-079:
:tjp3-080::tjp3-081::tjp3-082::tjp3-083::tjp3-084::tjp3-085::tjp3-086::tjp3-087::tjp3-088::tjp3-089::tjp3-090::tjp3-091::tjp3-092::tjp3-093::tjp3-094::tjp3-095::tjp3-096::tjp3-097::tjp3-098::tjp3-099:
:tjp3-100::tjp3-101::tjp3-102::tjp3-103::tjp3-104::tjp3-105::tjp3-106::tjp3-107::tjp3-108::tjp3-109::tjp3-110::tjp3-111::tjp3-112::tjp3-113::tjp3-114::tjp3-115::tjp3-116::tjp3-117::tjp3-118::tjp3-119:
:tjp3-120::tjp3-121::tjp3-122::tjp3-123::tjp3-124::tjp3-125::tjp3-126::tjp3-127::tjp3-128::tjp3-129::tjp3-130::tjp3-131::tjp3-132::tjp3-133::tjp3-134::tjp3-135::tjp3-136::tjp3-137::tjp3-138::tjp3-139:
:tjp3-140::tjp3-141::tjp3-142::tjp3-143::tjp3-144::tjp3-145::tjp3-146::tjp3-147::tjp3-148::tjp3-149::tjp3-150::tjp3-151::tjp3-152::tjp3-153::tjp3-154::tjp3-155::tjp3-156::tjp3-157::tjp3-158::tjp3-159:
:tjp3-160::tjp3-161::tjp3-162::tjp3-163::tjp3-164::tjp3-165::tjp3-166::tjp3-167::tjp3-168::tjp3-169::tjp3-170::tjp3-171::tjp3-172::tjp3-173::tjp3-174::tjp3-175::tjp3-176::tjp3-177::tjp3-178::tjp3-179:
:tjp3-180::tjp3-181::tjp3-182::tjp3-183::tjp3-184::tjp3-185::tjp3-186::tjp3-187::tjp3-188::tjp3-189::tjp3-190::tjp3-191::tjp3-192::tjp3-193::tjp3-194::tjp3-195::tjp3-196::tjp3-197::tjp3-198::tjp3-199:

What’s the point, you might ask, if Slack also allows to share images?

I am not certain there is one. Sure, you can write around a tiled image in a way you cannot around a regular image, and you don’t get any chrome. But the real rationale here is, simply, the love of the game.

But this is why I love the details of history. You never know when an old detail chooses to come back to life again. Sometimes it will be a fun hack to try, but once in a while, it might be the only solution to a gnarly problem.

Thank you to Andrew Yaros for teaching me about tiling in classic Mac OS.

A really well-produced 27-minute video from Super Splash Wave about 8-bit and 16-bit pixel art:

What I liked about the video is that it doesn’t just revel in nostalgia, but goes deeper into some techniques and trends and details in the videogame graphics of the 1980s and the 1990s: palette limitations, palette animation, sizes of objects, dithering, parallax, small ventures into 3D, etc.

It was also great to see specific changes and evolution of what from the distance of 2026 might seem like one monolithic era. The very first games used rigid grids and the assets were generally done by engineers themselves. Then, the work was split between artists doing the visuals, and engineers implementing then. Only after that, closer collaboration between engineering and artists allowed truly spectacular effects to take place, mirroring what we’ve seen in UX design when designers and front-end engineers work closely together.

Safari broke tap to top for tabs (say it three times fast), and Bear added two-fingers gestures. Ivory – a Mastodon client for iOS – tries a different approach in a slightly different setting.

The normal tap to top gesture works as expected, but tapping the top again returns you back where you were before:

I believe this is meant to be a small gesture of help if you tap to top accidentally, yet I am not entirely sure it’s effective. Would you, in a moment of panic, decide to do the same thing again, after years where every other gesture like this in the entire system taught you those taps are idempotent?

It gets a little bit worse, too. There is another established standard of going to the top – tap the selected tab again. This works across the entire operating system, too. But Ivory changes it, requiring you to tap twice, not once:

I don’t have access to the combined feedback of Ivory’s users, but I am much less of a fan of this than of Bear’s approach, as it doesn’t feel like it comes together as a system.

At the bottom of the screen, the interface teaches you that you have to tap one more time than usual, likely putting in your fingers the idea that you just have to tap many times, especially if you never figure out it’s a double tap and not two taps that trigger the interaction.

But then, at the top, this is how the interface reacts like this when you do exactly the same thing:

It feels like a system that’s well-intentioned, but inconsistent not just with the rest of iOS, but also with itself.

I just learned something fun this weekend. The seminal videogame Pong from 1972 looked like this:

But there was a problem. Here’s Al Alcorn, the designer/​engineer of the machine:

The paddles on the original Pong didn’t go all the way to the top. There was a defect in the [circuit] – I used a very simple circuit, I had to, to make the paddles, but they didn’t go to the top.

This meant that there could be situation where the ball sneaks up past the paddle at the very top of the screen, and the player cannot do anything to stop it.

You can see it in this video:

But Alcorn decided not to change that:

I could have fixed it, but it turned out to be important, because if you get two good players they could just volley and play the game forever. And the game has to end in about three or four minutes otherwise it’s a failure as a game. So that gap at the top, again – a feature. So that was sort of a happy accident.

“Happy” primarily in the context of the industry – the goal of an arcade game was, after all, to bring in quarters, and this here was the unexpected equivalent of the zero in a casino roulette game. But I wonder if some of this bugginess/​randomness also helped the game feel challenging and surprising, even for skilled players.