The relationship between keyboard manufacturers and standards bodies in various countries is so complex I barely understand a snippet of it.

The most famous example must be the 1990s PowerBooks, which had a beige variant for Germany and Germany only, to conform with local laws that prescribed and enforced specific color and contrast combinations for keyboards, in order to avoid glare and attendant ergonomic problems for terminal operators in the decades before. (It wasn’t just Apple. ThinkPads did the same.)

(I know. Jump scare!)

But you’ll understand that what caught more of my attention was an obscure variant of keyboards for (parts of?) Canada in the late 1990s and early 2000s.

The white 2003 keyboard might be my favourite of Apple’s keyboard design, instantly recognizable in either the American version (more words), or the European one (more symbols):

There was also the Japanese JIS standard keyboard, which famously kept Control where older terminals had it – to, no doubt, delight of Japan’s programmers:

These are the three well-known layout standards. The one for Canada followed Europe, but only to a point. The layout was the same, but the symbols weren’t:

Here’s an alternate view of the European and Canadian keyboards, and you can see that the latter one introduces different, unique symbols for Ctrl, Alt, Tab, Caps Lock…

…and even goes as far as Esc. (The Esc symbol is roughly the same you see worldwide, but for some reason, Apple always shied away from putting it on even symbol-friendly keyboards – even though frustratingly it’s being used in macOS menus in all the locales.)

The story repeats itself in the middle of the keyboard. Here are, again, the US and European editions…

Canada, with its abundance of icons, makes Europe feel like America:

Even the arrows are different – here’s America vs. Canada:

Even the Enter arrow – here’s Europe vs. Canada:

And numeric Enter/​Return gets a different shape, too:

I don’t really know what is the full story here. I imagine the government exerted some pressure and Apple relented, creating a unique set of keyboards with some really ugly icons.

I know the previous two models were affected also – here’s AppleDesign keyboard from the second half of the 1990s:

You can see all the same symbols…

…and even the extra glyph for Num Lock I imagine was prescribed for the PC side, too:

And, closer to the present, I have seen examples of the first metal keyboard from the late 2000s, too. But I don’t believe these symbols are used today. Even in their heyday, I’m not sure whether they were sold in the whole of Canada, or just its French-speaking portion – if you know, please share.

It’s my understanding this is called the CSA or ACNOR keyboard. And, like before, these symbols are in Unicode – ⇬⇭⎆⎈⇱⇲⎗⎘ – looking just as gorgeous.

That was me being sarcastic. I can imagine the pain inside Apple of someone having to put the ugly symbols coming from above, alongside otherwise generally thoughtful and refined typography. Sure, Apple did good here compared to other keyboard makers, but still, it must have hurt. This is what makes these keyboards so interesting to me.

---

But there’s one more symbol that might be interesting to talk about, and perhaps you already spotted it above. It’s here, on the Japanese keyboard:

This time around no standard was involved; I believe that the pencil on the Control key is solely Apple’s invention.

What is it for, and why was it there just in Japan? Typing in Japanese might be among the most complex, requiring switching between a few writing systems – katakana, hiragana, kanji, and also Western letters – as fluently as possible. To help with that, Apple used a system called Kotoeri, and added a new alternative symbol for Control that was also present onscreen, in the relevant typing menus:

The system was there in the waning years of classic Mac OS and early years of Mac OS X.

Just like with the Canadian symbols, I don’t fully know what happened to Kotoeri. I’m reading that it was gone from Mac OS X by 2014 – but even already in the years before, Apple removed the slightly pixellated symbol from their keyboards, and switched back to a standard ⌃ Control symbol in the UI.

Of course, if in the 1990s it was people in Japan who had to switch between various keyboards all time, today, thanks to emoji, it is everyone. If the Kotoeri pencil reminds you of something, Apple came back to the same well more recently with the 🌐/Fn key – but I already wrote how much I hate that.

Make Some Noise is one of many fantastic improv comedy shows on Dropout. I noticed one of the ongoing themes is “tech gone bad,” so I compiled a short list below. I just find these really funny.

Video call with shitty wifi:

Logging in with 30-factor authentication:

A cutscene in a video game that’s glitching out:

In case you’re curious, the improv actors are: Zac Oyama, Josh Ruben, and (occasionally) Brennan Lee Mulligan.

If you’re a Dropout member, these are the original, slightly longer landscape videos inside their respective episodes: wifi, 30-factor, game.

I linked to palette cycling before, and I was just reminded of palette cycling art by Mark Ferrari, who back in the 1990s made 30+ landscapes that looked like this:

They have been collected on this webpage some 15 years ago, and I’m linking to it in part because it’s also a great explainer of how palette cycling works – you can see the colors move around, you can point to one to see it frozen, and you can see multiple cycles running in parallel, compare palette ranges between different environmental conditions, and turn on a “blended” technique that feels clever and I didn’t realize existed.

The page was made by Joe Huckaby, who wrote a little intro:

Mark J. Ferrari […] invented his own unique ways of using color cycling for envrironmental effects that you really have to see to believe. These include rain, snow, ocean waves, moving fog, clouds, smoke, waterfalls, streams, lakes, and more. And all these effects are achieved without any layers or alpha channels – just one single flat image with one 256 color palette.

The launch was also accompanied by an interview with Ferrari, which is an interesting read – in part because it shows the work was even more elaborate than all of the above:

These versions of the scene are all the same piece of art ‘shifted’ to different palettes, and, in some cases, using additional ‘baked in’ overlays, (such as rain or the lighted windows at night). But those overlays are all ‘baked in’ to the same layer of the same piece of art that appears in any other ‘day-time’ or clear weather iterations, and are all deriving their color and motion from the same palette as the rest of the picture in that state.

While [the page above] finally allows us all to watch these images color cycle online, many of the scenes posted were actually ‘built’ to do much more than merely animate. By fading the one piece of art through whole sets of palettes, sometimes also using a very sparse set of ‘baked in’ overlays, a number of these scenes can go seamlessly through the 24 hour light cycle, and even change weather conditions ‘naturally’ and seamlessly in real time as you watch. I am not just talking about changing the brightness or color scheme of these pictures either. In the images built for it, over the course of ‘sunrise and morning,’ ‘morning to afternoon’ or ‘evening and sunset,’ light and shadow will actually gradually change angle, climb down the sides of things, move across lawns, up cliffs or building walls, as changing light does in life – all just by fading through palette series designed to make those things happen without altering or adding anything at all to the single layer of 8-bit pixel art.

Ferrari also suggests an interesting analog to palette cycling, which I quoted in the title.

Bonus: Ferrari’s animated landscapes were made for a new-age’y personal organizer app called Seize The Day, and on top of the above preservation effort, there is also this independent, extremely retro page from a fan of the app who loved it so much she decided to keep the app itself alive, too.

Three nice moments in Buttondown’s (pretty comprehensive) release notes:

• There is a filter and tags to search more easily.
• Blog entries are linked throughout, complete with cover images – it’s a nice way to distinguish small changes from big improvements.

• The fixes are attributed to specific people. (This part doesn’t appear on mobile.) Particularly nice to see support for more than one person collaborating on a fix – I’ve had fun memories working at various companies of pairing up with someone else to debug a particularly tricky problem.

Fighting games require rather precise timing: the action is frenetic, the inputs rapid, and the outcomes can be determined by what players do down to – sometimes – individual one-sixtieth-of-a-second frames.

This is fine when you play locally, but gets infinitely more tricky the moment you attempt to kick someone’s more remote ass:

Information sent to your opponent may be delayed, arrive out of order, or become lost entirely depending on dozens of factors, including the physical distance to your opponent, if you’re on a WiFi connection, and whether your roommate is watching Netflix.

The part of the game responsible for dealing with networking is called netcode, and the classic solution to the lag problem has been delay-based netcode with a sort of lowest common denominator approach: if your opponent has a “ping” of 50ms, your actions will also be delayed by 50ms, to ensure fairness.

It’s not that hard to imagine many problems with this idea. Lag comes and goes but the game doesn’t smooth it out, the play feels like jello with even an okay connection, and the game occasionally freezes, waiting for a suddenly dropped connection to resume, not knowing what to do in absence of information.

That’s why within the last decade, what gained popularity is a new kind of netcode called rollback netcode, which operates by… lightly predicting the future. Most of the time, within a reasonable lag, the game will feel as fast as a local game to both players – and even when the optimistic prediction doesn’t match what eventually happens in reality and the code has to roll it back, visibly, in front of a player, the change might be too small to notice and only rarely it’ll result in rubber banding.

Core-A Gaming has a great video about specifics of rollback netcode:

It covers a lot of stuff, including nuances like drift and design decisions that game makers might want to incorporate to soften rollback netcode’s most annoying side effects. (Also, the guitar playing bit at 0:22 is absolutely brilliant.)

The video is largely based on an earlier essay by Infil, which has even more details (audio!) and which I excerpted above.

---

It’s not just videogames. When Apple announced in 2019 that they reduced the latency when using their iPad Pencil from 20ms to 9ms, they didn’t hide that they had to peek into the future as well:

The specifics were, as far as I know, never revealed. But the fact that some of the input events the app receives are not actually real is official and documented:

It takes time for UIKit to generate and deliver touch events to your app, and it takes time for your app to process those events and render the results. In fact, it takes enough time that there can be a visible lag between the movements of a person’s finger or Apple Pencil and the rendered results. To minimize the perceived latency between touch input and rendered content, you can incorporate predicted touches into your event handling.

In fighting games, the most accurate prediction is a trivial “whatever buttons and controls the player holds on the current frame are likely the same they will hold on the next frame,” but for other games – and for Apple’s Pencil – slightly more advanced prediction might be necessary:

---

It feels disappointing that no matter what we do, there might be no way to reduce latency below a certain threshold without cheating.

But if there’s any consolation, it’s that cheating seems to be the only answer, and that has been the case long before computers came aboard. There are many documented ways our brains have their own netcode to cover for various lags occurring within our bodies. There’s the stopped-clock illusion, the cutaneous rabbit effect, the color phi phenomenon, and – most relevant for today, even though it has the most boring name – the flash-lag effect, documented on this nice page by Michael Bach:

The flashing lines are shown exactly at the same time and angle as the rotating line, but it certainly doesn’t appear to be the case. Just like fighting games and Apple Pencil do, our brains predict and extrapolate the movement of the moving line so that our other senses can intercept it at the right moment. The go-to example of why it’s needed is that you wouldn’t otherwise ever be able to catch a ball thrown your way – but I imagine it might be useful in a street fight, as well.

For a lotmore technical aspects of rollback netcode, check out this long conference presentation from GDC.

The Game UI Database is a website that covers the interfaces of almost 2,000 games via over 75,000 screenshots.

It has meticulous information architecture, so you can jump into specific sections, for example:

• Game difficulty settings
• Game UI settings menus
• Modals and pop-ups
• Loading screens
• HUDs
• Minimaps

Even if games and productivity software seem worlds apart – the creator of the site, Edd Coates, calls himself “UI artist,” which is not a title I’ve ever seen in my line of work – I’ve long thought games do some things better, and these can be an inspiration.

The database was started by Coates a few years ago. This launch article on Mashable has this interesting passage:

The site is relatively short on context, with only the collections of screenshots gathered under different tags for visitors to go on. […]

That’s the site working as intended. As Coates explained: “It’s useful for designers to identify recurring and pre-established patterns in successful titles when building their own interfaces.” Added context isn’t necessary because the contrasting approaches evident in each image is the whole point.

Needless to say – I mean, you know this after spending 12 seconds on this blog – I disagree. But it seems the author does too, since he’s working on a book called The Game UI Bible, to be released in the first half of 2027:

I recognize the volume is pricey and last time I was excited about a book, it turned out to be quite a disaster. The Game UI Bible book also touts a lot of interviews with UI artists, and I find these to be a mixed bag in practice; it’s really hard to interview people in a way that yields something interesting.

But still, I am excited again – and if you’re not, the Game UI Database is worth checking out.

The title of the post comes from a different blog post about the database.

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.

Anthony Hobday is a product designer and I like his approach of cataloging and sharing references on his website. Here are some choice pages:

• Uncommon, but useful design terms
• Notes on software quality and What is good craftspersonship?
• Notes on visual design and Visual design rules you can safely follow
• How interface changes with frequency of use
• Every interaction design concept and Every visual design concept
• Various interface design classifications
• Notes on design books

I admire this kind of rigorous practice, and if you’re doing that on your own, please consider sharing it with others, too! (And please consider letting me know.)

As a reader, I find these fun to go through, as they light up different parts of my brain than most of other design resources.

I probably missed some on the list above, so check out the entire site. (For example, Hobday also has a list of lightly categorized bookmarks and quotes about design.)

I added a new reference tag to capture resources like these.

Any Mac app that has to ask for system permissions has its work cut out for it. In a previous post I showed “the MacCharlie method,” which looked like this:

DaisyDisk, a disk cleanup app, does something different.

First of all, I like that the app icon is animating here to indicate it’s movable. It’s a version of “jiggle mode” and while it would be frustrating to see it in a common UI surface (our brains our wired to be distracted by movement, especially in the periphery), this is a tab that you only click into to fix this:

But something even more interesting happens. The moment you start dragging the icon, the app actually spawns System Settings, positions them close, and even opens them at the right pane… so you can just drag the icon over:

I don’t believe I have ever seen anything like it before. This feels a bit aggressive, but I think it is… good?

I now wonder, however, why do the instructions still tell me to do it by hand. What if they just had a wiggly icon saying, “start dragging it, and we’ll open Settings for you,” with only some fallback or manual option if wanted?

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:

Ivory is a Mastodon client, and their account switcher has a few interesting mechanics.

The standard one is that you can tap on your avatar, and get a menu in response:

But you can also drag down on the avatar, and get a different reaction:

This, I believe, is meant to be a slightly faster way. The settings option is gone to simplify, and the whole thing looks and feels more… gestural, in lack of a better word.

But I think it also serves one more purpose. The moment I saw this, I thought to myself “I wonder if I could just swipe on the icon itself?” and, lo and behold, this is actually possible:

Why does it matter?

I think for some power users of social media – perhaps people doing it professionally – you switch accounts all the time, and investing in this interaction being fast and smooth is important.

This whole small interaction system feels similar to switching apps on a Mac. You can choose an app in your dock with a mouse (the slow, but well-lit way). You can then learn to use ⌘⇥ and hold ⌘ to get to it quicker from a temporary menu. Eventually, you will also start tapping ⌘⇥ quickly, skipping any visible UI surface altogether.

There is also something great in seeing an interface that grows with you, or one where you can say “I wonder if…” based on your prior interactions and expectations, and the interface actually rewarding you for that thought.

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.

This is a meta post about this very blog. If that’s not interesting to you, skip to the next one!

A few people recently asked about my writing and publication process, so this post is for anyone who’s interested in that.

The process

My present goal is posting every day, and at least eleven posts a week. This is arbitrary and will change; I’m making sure I’m enjoying it, and paying attention to burnout.

I have at this point hundreds of unfinished posts, or snippets of posts, or just two-three-four-word ideas. I try to jot them down whenever they pop into my head. Here’s a lil sample:

How I choose to publish something on a given day is a bit of a mystery even to myself. I generally try to listen to what inspires me. I’m always excited when a blog post or a YouTube video arrives that makes me want to share it on the spot. The original idea for Unsung was to do only this kind of stuff, but that doesn’t happen as often.

Sometimes, it’s your emails or messages that prompt a post (thanks!). Sometimes, I try to be strategic about “if I want to post about Y, it’d be good to first have posted about X” – for example, I needed to write about menu secrets before writing about Move Item Here). But I try not to overthink it; once you start considering all the dependencies, it really becomes an escape room.

I sometimes mark items with [NEXT] or [SHOULD] or [READY] or [EASY] – this is not markup, these are just words to help orient myself – but it’s kind of a mess.

I made a dashboard to help me steer clear of blind alleys over time. Some patterns I’m trying to avoid: writing just from me instead of linking to other things, or relying too much on YouTube videos. Recently I noticed I wrote a lot about keyboards and old things, so I added a few charts to monitor these patterns, too.

I try to do both of these at once:

• Recognize that something I wrote or explored ended up not that interesting, and stop the presses. But I don’t delete these posts – maybe a better story or a more interesting take will save them in the future:

• Get something out there even if I don’t feel it’s perfect, just to keep the momentum.

This “pull stuff that’s boring/​push stuff out anyway” seesaw feels hard to navigate, but I think it’s important to practice and pretty universal to creative process.

Lastly, I occasionally look at the stats of the weekly digests to see how I’m doing, but mostly they serve as celebration – yet another week of stuff in the books.

Infrastructure

It’s really hard to say why I find things motivating, or how I know something is interesting, or even how I do my research – these feel personal or come from having thought about this kind of stuff for decades now. It’s really hard to give advice here. (“I’m an immigrant which often comes with a particular work ethic” or “my parents were not as supportive as they should be when I was growing up, so I try harder” are not particularly… actionable.)

But one advice I will give: I invested a lot in infrastructure of the blog, so I can focus on writing, and I don’t get exhausted by menial production tasks (except those I like).

For example, I have my own little markup language in Notes, so for example I can say [device frame:nothing phone] and the dragged image or video get automatically framed without me doing anything else, so I can focus on writing.

Here are some other tags in my markup – I’ll let you figure out what they do. (I have to use different brackets here so they don’t get interpreted!)

{side by side}
{border on dark}
{border on light}
{force retina}
{no height limit}
{thumbnail}
{secret}

I also wrote a little app that’s a wrapper around imagemagick and ffmpeg to allow me to quickly deal with image and video production as this is the least pleasant part of the job:

Having my own blog backend and frontend can be frustrating, but it also allows me to slowly improve things, which is important to me. I have a long to-do list of things that I want to do better, and I slowly chip away when inspiration strikes (or, when people report bugs). I want to try 120fps and P3 videos, more interactive elements, better information architecture, nicer visualization of keyboard and touch events. I have tons of bugs to fix.

I recognize this flipflopping from previous projects – when I work on presentations, I sometimes switch over just to “making slides pretty” and this keeps me excited and still helps me figure out what I want to say, but in a roundabout way – and learned how important it is for me. I love that I get to improve a surface for my writing alongside doing the writing. I think it’s really cool this is even possible.

Speaking of writing

I write in Apple Notes, mostly on my Mac (but occasionally on my iPhone on the go). This is an example of a published post in its natural habitat:

My general writing process is very messy – I start with specific ideas or links or even phrases and drop them in, and then I write around it. It always feels 20% done all the way until it’s 100% done; at this point I’m used to this curve.

Here’s an example of a post I’m not working on actively, but kept adding to over the last weeks:

As I flesh a post out, I use a lot of TKs for future phrases and also to denote assets (images and videos) needed, and occasionally put to-do items in there, too.

Each note can also have a “graveyeard” section where I can keep random thoughts and that section doesn’t make it to the blog. I like keeping it in as a sort of artifact of messiness of the creative process. Here is it in a recently published note:

At some point during writing, I throw it over from Notes to the blog to see how it actually feels. I usually do it too early, intentionally. The writing in Apple Notes looks rough and the assets are always sized strangely; seeing the note how it will actually look gives me momentum. It also engages a different part of my brain, as I can more seriously think of how the images or videos help to tell the story.

What else?

I occasionally revisit my goals and principles, but they’re mostly in my head.

Once I decide to finish writing something, I try not to have more than 2–3 items in that state.

I do not use AI in any way for writing; I am very protective of this thing I worked on for most of my life. If I use AI for research, it’s for simple Google-like questions, the answers to which I never fully trust.

Tools

I write in Apple Notes, which I fell out of love with for actual note-taking. I code in Nova, although I struggle with some of its bugs and design decisions. I record screen with either native recording or CleanShot. I edit photos and videos with my little tool and command line, but I still occasionally reach out for Photoshop, which I’m not happy about.

Anything else you’re curious about? Let me know!

Unless you’re reading via RSS, welcome to Unsung’s new livery!

I dreaded even attempting the redesign, but as I was adding full-text search to the blog, I realized the previous simple frame couldn’t accommodate it – no matter what I did, the search felt bolted on. I suppressed my PM side, decided to scope creep, and the 500th postiversary provided a good arbitrary deadline. (This is post №492, so hopefully I’m not jinxing it.)

One trick helped me. I decided to start the redesign coworking from a friend’s startup in a cool Chicago building, for the first time ever, hoping that the new surroundings will inspire me. It worked!

Functionality

The main impetus for the redesign was to recognize the blog’s growing body of work and make Unsung more evergreen, and something one could revisit in the future as a resource. Here’s what I did:

• There is now a “Random post” link – I’m hoping it becomes a delightful little way to poke around.
• There is also a search that can help you find an older post or navigate the site in a different way.
• The sitemap shows all the tags, now with light commentary.
• Posts that are in a series are now connected through navigation:

I also added a way to follow and comment on the blog posts on Mastodon and Bluesky, on top of existing RSS and weekly email digest.

Visuals and interactions

The first edition of Unsung was the default Montaigne styling (just so I could focus on writing and establishing a routine), and the second edition borrowed a lot from the design of my main site, Aresluna:

For this first proper design of Unsung, I wanted something more distinct, something that wouldn’t feel too “computer retro,” and something that steered clear of the preeminent AI aesthetic.

The fonts I chose:

• The body font is David J. Ross’s Warbler,
• The sans serif working hard (and occasionally having fun) is David J. Ross’s Bild,
• The logo font that you will see pop-up occasionally elsewhere is Neonoir by Phospho Type foundry, with some modifications.

The color – well, didn’t you see me yearning for something evergreen above?

Just kidding. I liked this factory green in a few places I spotted it recently, and I thought it felt appropriate, and beautiful in its own pedestrian way.

A lot of the design tenets of Unsung are still the same as before: no rounded corners, no shadows, no blurs, and a general distrust of symmetry. Plus, there are now a few more uneven surfaces.

I could write some bs about how the sharp edges vis-à-vis the flowing neon text (and the neon-inspired icons I designed) represent the tension between craft and manufacture…

…but, I don’t know. A lot of this design stuff is rattling around in different parts of the brain and doesn’t bubble up to the surface where words live. It just felt to me the contrast was fun.

Personal goals

Because yeah, in addition to all the explicit and implicit goals, I also wanted to have a bit of fun and learn new things, and add a bit of delight, which hopefully you will spot here and there.

I hope it makes both reading and navigating the blog more enjoyable.

Thank you to Naz Hamid and David J. Ross for their help with the redesign.

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.

I don’t think anyone particularly enjoys typesetting in monospace.

Regular text is okay – at least as okay as it can be:

Right aligning is also fine, as long as you don’t mind counting spaces, but centering already gets tricky, as you don’t have a half space to make things truly even:

And full justification is where things get particularly weird. The spaces are just too large, and cannot be distributed evenly, creating a really unpleasant feeling:

The solution used in typesetting elsewhere is hyphenation, but in monospace hyphenation also feels unpleasant, with the hyphens drawing too much attention to themselves (and subsequently messing up copy and paste):

This is why you don’t see full justification in text files very often.

But there is one more option. You can rewrite the text to choose only words that precisely add up to the line length to avoid any double spaces.

This is exactly what rs1n did in the late 1990s for his guide to Super Metroid:

It’s astonishing, as it goes like this on for 17,000 more words, each right margin perfectly ending on a letter, no twin spaces in sight.

The author lightly covers in the FAQ at the bottom:

What program did you use to justify the text?

None. I just chose words carefully so that everything lined up on the right hand side. Everything was done with an ASCII editor.

I’m sharing this mostly as a curiosity; some rewrites for physical books are par the course to avoid widows and orphans, but you don’t see them as much in onscreen writing.

At the same time, who among us didn’t nod in recognition at least, having once spent hours massaging a button UI string or a tooltip just to get it to fit under the certain width in a densely packed interface?

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.

A Mastodon post by computer scientist David Chisnall has a very Unsung opener:

I have used vim since around 2000. I have written five books, a PhD thesis, a few dozen papers and over 150 articles with it. At this point, my higher brain functions are not engaged at all when I use a bunch of common vim commands, they just happen. Documents I wrote with anything else have random :w in the middle.

Chisnall goes on to talk about one specific vim feature:

Persistent undo is one of my favourite features of vim. […]

I don’t often need the persistent undo. But on the few occasions when I have needed it, it’s been invaluable: ooops, I deleted something from this file, maybe last week and one reboot ago, what was it? Undo until I find it, copy it, paste it into the current version. Or, a bit more commonly: I had this working, then I tidied it up ready to commit, now it isn’t working, what did I do?

Vim has kept this working across major version upgrades over a period of about 20 years. I don’t even think about it, it’s just part of Raskin’s First Law: A program may not harm a user’s data or, through inaction, allow a user’s data to come to harm. If vim or the computer crash, or if I close a file and come back to it six months later, my undo history is still there.

NeoVim is a fork of vim (in news for other reasons):

So I tried NeoVim when it was quite new. Vim that you are familiar with, but better? Great!

The first thing I noticed in NeoVim was that undo didn’t work. I tried opening the file in vim and undo didn’t work there either.

Neovim had changed the format of the undo files. It hadn’t upgraded the old one. It hadn’t used a different name for its undo files. It had just noticed the existence of a vim undo file, deleted it (losing all of the data in it) and replaced it with one that vim couldn’t read.

I raised an issue about this and was told that the persistent undo format was unstable and users should not rely on data being preserved in a feature explicitly called persistent undo. It had changed once and would probably change again.

And that ended my experience with NeoVim. The authors showed immediately that they absolutely could not be trusted with any of my data. Breaking persistent undo is something I could forgive as a bug, but the attitude that just because something is a persistent file on your filesystem that contains data that you might want is no reason for their program not to delete it meant they had no concept of a duty of care to their users.

I liked this post (which I quoted almost in its entirety), because it covers a few important things:

• I have never heard of the persistent undo like that, and it seems kind of amazing.
• People do remember when software loses their hard work or disrespects them.
• I can see how “It had changed once and would probably change again” can be such a powerful feeling.

I also loved it for the appearance of Raskin’s First Law. Jef Raskin, of Macintosh and Canon Cat fame, put together the three laws in his 2000 book The Humane Interface, and they go as follows:

• A computer shall not harm your work or, through inaction, allow your work to come to harm.
• A computer shall not waste your time or require you to do more work than is strictly necessary.
• An interface is humane if it is responsive to human needs and considerate of human frailties.

It was a very important and formative book for me to encounter as a young designer. I have no idea how these laws haven’t made it to Unsung before today.

It is a testament to how much things have changed in competitive NES Tetris – a game released the same month the Berlin Wall fell – that this hour-long documentary by Summoning Salt that talks about the 2018 Tetris Championship covers the previous revolution in a play technique:

I don’t watch a lot of sports, but I think this is a sport movie: a battle between the classic DAS players – DAS stands for Delayed Auto Shift and means that the player just holds the left or right pad and have the piece slide on its own – and the new-at-the-time technique of hypertapping, which allowed to move the piece to the side faster, but was really demanding on the player’s hands.

It’s gripping at times – wait until the moment when a DAS player runs with a dangerous move called “quick tap” – but also surprisingly touching at the very end.

(If you are interested, the newer playing technique that was invented in the 2020s, and even more effective than hypertapping, is rolling.)

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.

Ilya Birman on his blog talks about interfaces that unnecessarily slow people down, in a series of two posts.

In the first one, titled “Let me click,” Birman shows a few places that force the user to go through a roundabout series of clicks, instead of taking a direct route:

In Aegea’s comment settings, there is a “send by email” checkbox with an email-address field associated with it. If the checkbox is unchecked, there is no point filling in the field: the address is not needed for anything else. If the checkbox is checked while the address is blank, the system cannot send anything as it does not know the address. In short, these controls are interconnected.

Logically you could disable the input altogether if the checkbox is unchecked — there is no point filling it in anyway. But that is irritating. What if I want to enter the address and then turn on the checkbox? It would be even worse not to let me turn off the checkbox when the address is filled in. I want to turn it off — let me click!

In a follow-up, Birman talks about a specific example from the podcast app Overcast, whose creators faced with a tricky systemic challenge:

For any podcast, you can set how many episodes to keep downloaded on the device. Say you set the limit to three, then stop listening to a podcast regularly: the next three episodes download, and after that it stops downloading them — why waste the space? […]

[But,] what if someone manually asks to download an episode when they already have three downloaded? You can’t just immediately delete it to keep things tidy. […]

Finally, Marco’s wife Tiff suggests a solution to all the problems: just don’t let users download more episodes, she said, and show them a message, roughly: “Your episode limit is three, but this would be the fourth, denied”.

Marco liked the solution. I didn’t. Sure, it solves Marco’s problems, but not the user’s.

I haven’t seen the Overcast block in action, but all of Birman’s examples across both blog posts rang true to me. Motor memory wants what it wants, and stops for no one.

I wanted to add two things from my end.

1.

Birman presents this as “Let me click,” but I wanted to offer two alternative/​complementary principles that helped me before:

• Let me do things in any order. Here’s Google Home app, where I can change the temperature and the time for holding – but if I change the time first, it frustratingly resets when I subsequently change the temperature. It forces one specific order in an interface that suggests any order is okay:

• The current action has the most momentum. The user is right there, active, tapping on things, wanting to get stuff done. If Overcast indeed throws a “your episode limit is three” message, then it forces the user to remember how to get to the settings and change it. The momentum is lost. The decisions of past me should not be as important as the decisions of present me.

2.

I agree with all the examples given by Birman, but things can be stranger, and sometimes letting people click or do things in any order can make the interface harder to understand.

In Figma, each text box dimensions could be set to be completely automatic (automatic width and height – used for short labels), with only specific width (and automatic height – used for paragraphs of text), or with manual width and height (used for graphic elements):

You can also see that in text boxes where width or height are automatic, the fields for those values are grayed out, and cannot be changed. In order to change them, you have to switch to a particular mode first, which makes the relevant fields active. This is to help people understand how those things relate to one another in a pretty tricky space, but it effectively means sometimes Figma won’t let you click, and will force you to do this in one specific order.

But this is only in those fields – you can always grab the object on the canvas and resize it, and it will switch to manual on its own, respecting the drag’s momentum:

The inconsistency here is intentional. I’m not saying these are the right choices, and we indeed heard from some users frustrated that they cannot click easily when they already understand the system (unfortunately, I am aware of no good affordance for “breaking” a disabled field in modern GUIs, like a molly guard). I mostly wanted to share that these things can be hard, and the balance between “let me click” and “not being able to click can be helpful in understanding the system” tricky to achieve.

I keep thinking of the story from a decade ago when someone’s phone rang at the front row of a New York Philharmonic’s concert, prompting an actual performance halt, and anger from both the conductor and the audience. The ashamed patron’s eventual explanation was: “I turned the phone to silent, but I also had an alarm set up.”

Let’s assume this is actually true (in people’s reports, the phone rang the marimba ringtone, which isn’t standard for alarm – but people’s recollections are routinely flaky, too). This, I think, is a perfect example of “let me click” in action. You can set an alarm for a certain time, and you can subsequently turn the phone to silent. You can also do it in the opposite order. You just gave your phone two inconsistent instructions, and the phone logic decided in either case the alarm will win.

I can’t think of an easy interface solution here. It feels correct for the order to not matter here. It’s hard to imagine disallowing you switching to silent mode with any alarms on, since the silent mode also affects calls. It’s also hard for me to imagine any effective UI warnings at any given moment in the process. (Besides, back in the day, iPhone used to give you a gentle one via a little alarm icon visible in the top bar.)

The silent mode and the alarms are, as Birman put it, interconnected – but their connection is ultimately tricky to explain to the user.

I believe every modern operating system allows you to set the key repeat rate and the delay before first repeat:

By default, on a Mac, the initial delay is 500ms, and the key repeat rate 1000ms. You can adjust both:

• Initial delay goes from 250ms, to as long as 2s.
• Repeat rate goes from 2000ms (once every two seconds) all the way to a whopping 33ms (30 times a second).

On a PC, the shortest values are exactly the same, but Windows 11 only allows up to 405ms between key presses, and 1000ms of initial delay.

My suggestion is to make them both as short as possible for testing.

Why would that be helpful? There are two reasons.

First, it’s good to test whether your keystrokes behave well when repeated. Occasionally you might want your interface to suppress repeating, or do something special if the key is held longer.

Second, it’s a good test not just of repeating, but also of a user pressing keys really fast. It’s very important for the UI to never make you wait for any animations or transition, and a lightning fast 30fps repeat rate is a good way to stress test your system this way.

Here’s me holding the Tab key in Figma at a standard key repeat speed:

It’s nice to see those transitions help you orient yourself as you’re thrown around the canvas. But look at what happens when I do the exact same thing with the key repeat cranked up:

The transitions are now slowing the UI so much that you can no longer see any canvas movement – the canvas only catches up when I release the Tab key.

The smooth movement assumed a certain minimum key rate, and perhaps wasn’t tested with a faster one.

There are of course ways about it, like speeding up the interactions, suppressing the transition smartly, or introducing a custom repeat rate if needed – I talked about it a bit in my essay about designing fast keyboard interfaces.

Here’s an example of an interface that suspends transitions at a fast keyboard rate and responds in real time:

This looks very chaotic especially since you’re not in a driver seat, but this interface is at least honest and doesn’t make the user wait. And it might not be pure madness – you would be surprised how fast people’s brains and fingers can react.

But first, you have to be aware of the problem, and I think setting up those key repeat values as short/​fast as possible will help you find more of those kinds of issues.

(And you might choose to keep those high speeds anyway in regular use, like I do.)