I am hoping it becomes a fun reference to browse, or something just enjoyable to play with. I made the interface feel very differently on desktop and mobile, and I hope both are fun. (There’s also a simple list if not.)
I wish, just like with a regular bookshelf, you could open any book and check it out – but that’s tricky for many reasons. (I did at least scan some of the covers that weren’t available on the web.)
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, just 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.
In a recent post, Jim Nielsen used the term “bulldozing of an interface”:
I’ve found this to be true a lot as of late. Lots of tiny details that were meticulously crafted over years with specific rationales tied to real-world use cases, all completely bulldozed in a giant refactor.
I liked that term and description, but I didn’t expect I’d put it to use so soon. Unfortunately, mere months after praising CleanShot’s settings, the new version 5 update bulldozed them into something much worse.
Let me show you first. In the following screenshots, version 4 design is followed by its version 5 equivalent.
Quick recording settings:
General:
Recording:
Advanced:
The other panels follow the same pattern. (The screenshots are from macOS Sequoia, but I checked in Tahoe, and things are not materially different there.)
I was taken aback by this – a feeling exacerbated by the fact that the quick settings on a dark background looked even worse – so I shared an early reaction with CleanShot’s support team, and asked how to downgrade to version 4, which luckily remains possible. The support team member said that they actually liked the previous settings themselves, but conveyed they shipped the redesign in order to feel more consistent with the operating system, and more modern.
I followed up with a longer response, which I’m sharing below. I am hoping this can be valuable to others facing a similar situation in the future, or give some specific observations to latch onto – for me, it allowed to put in words the feelings I’ve had about the Ventura Settings redesign that were rattling in my brain since 2022:
Hi,
I don’t think you have to follow the OS if its own designers are making bad decisions – I gather it’s even our responsibility as designers not to – and we know they are bad, if only from how people reacted to the macOS Ventura System Settings redesign.
Here are the problems I see that CleanShot 5 settings now inherit from Apple:
The two-pane settings layout was originally designed for the first iPhone with its 320px screen width. macOS Settings stretches it to 460px, and in your app you went with 550px. As a result, the settings panes start registering, gestalt-wise, as “left column first, right column second” rather than “first option first, second option second, etc.” This requires eyes to dart around a lot more, as the labels are disconnected from their controls. The shading and lines help, but they’re just a crutch – and they also reduce density. In version 4, your eyes could follow the solitary center spine with more ease.
The second column is right-aligned, which makes visual processing harder – not just because it further separates the label from the control, but also right alignment is harder to process in a left-to-right language. (In the previous layout, sure, the labels were right aligned, but they were still near the common spine. Plus, the labels are short and simpler visually than Ventura-style right-aligned UI controls.) This also creates attendant problems, like Options… buttons being on the “wrong side,” or Options… and Choose… buttons needing to be in inconsistent positions.
In version 5, every panel looks much more alike. This doesn’t feel like helpful consistency, as it makes it harder to recognize where you are. Version 4 had a nice variety of silhouettes that felt cohesive as a whole, but still allowed for shape coding to help you orient yourself. We’re all pattern matchers, and varying shapes enter our brains on a deeper level, freeing us from having to consciously process the environment (or even read labels) over and over again, slowing us down.
Ventura’s settings design does not really allow for radio buttons and struggles with sliders, forcing pop-up buttons for every one-of-many option, which further reduces shape coding, but also is worse for orientation as you can’t see everything – if you just want to find an option like “Plain color” in Wallpaper, it’s no longer immediately visible. You might never, as a matter of fact, learn it’s there. CleanShot 4 really nicely knew when to choose radio buttons and when to reach for pop-up buttons, depending on the importance of the control. (A smaller, but similar argument could be made for subtabs and streamlined checkboxes, both used to a good effect in 4, but missing in 5.)
The new layout is also less usable as you can no longer click on long labels next to switches to toggle them, which was possible with checkboxes. The pop-up buttons are more narrow, too. This means you have to be a lot more precise in clicking, which adds up over time.
The previous layout had a nice consistent feeling of “things that are actionable and I can click on are white, everything else is gray.” It was yet another way that aided in scannability and orientation. In the new system, pull-down menus look like (inactive) labels.
The switches themselves have visibility and contrast problems. This might be particularly prominent in my setup with graphite as the accent color, but I believe it’s not unique to that. I continue seeing feedback from people who are always confused about “reading” the switches, whose both states look similar to one another. (The checkbox’s shape doesn’t have that problem.)
It’s not too late to undo this. This reminds me of city planning in the 1970s, when enchanted by the notions of modernism we remade city downtowns to be all identical-looking, clad in concrete, and surrounded by freeways. We look at it with shame and regret today, realizing we made previously alive places basically inhospitable.
You could still keep the modern left nav – that indeed didn’t age well, as screens are wider today – and perhaps left align the version 4 labels to make the gestalt hold better. It’s definitely more work, which I sympathize with; it’s hard when the operating system cedes its responsibilities to provide good design patterns. But you had something really wonderful before, crafted and signposted with care, both a great welcome mat for new CleanShot users and – important here more than for many other apps! – fantastic in repeated use.
(I know this is kind of an intense reply and I hope it doesn’t arrive feeling like concentrated condescension. Part of it is that I am x-posting it to my blog, as I believe it might be helpful for other designers.)
Completely unrelated to software, but sometimes stepping outside is what’s needed to develop perspective and find creative solutions – this is Practical Engineering’s video about the many electrical plugs and sockets in America:
There are a lot more socket kinds than I expected, and sprinkled in between are some useful observations about system design, change management, power users, backwards compatibility, and consistency vs. inconsistency – in my head, that last part puts this video right next to the previous post in my brain, even if they seem nothing alike.
Just as there is a ticking bomb built into cut/⌘X – if you cut something, and then cut something else again without a paste in between, you overwrite the clipboard without any way to bring it back – there is another one that awaits you when you use undo/⌘Z.
Here’s a typical undo chain, illustrated using Photoshop’s classic interface. You can do things, then undo into the past with ⌘Z to your heart’s content, then zipline back to the present via redo’s ⌘⇧Z:
But if you go far into the undo history and do something then – accidentally or intentionally – poof! Your entire undo stack, no matter how precious and storied it was, evaporates in an instant:
And it’s not even Back To The Future II rules where you can at least go back to the original separation moment and still get the better future for free…
…no, the entire original undo stack is gone.
The most popular solution for the cut problem, inasmuch as it really needs one, is a clipboard manager. Clipboard managers only move forward in time and record everything passing through the clipboard, so even if you override it with a careless cut or copy, you can ask the clipboard manager to resurrect the contents.
The most popular solution for the undo problem is something conceptually very similar – version history. It also always marches forward. Do something new? You’ll see a new version history entry. Undo it? New version history entry. Redo? New version history entry. Both the clipboard manager and version history are like paper ledgers, hostile to erasers and shredders, addicted to additivity.
(Mixing both universes, Figma’s version history will allow you to copy something from its past entry. But, naturally, you won’t be able to cut from it.)
I like this conceptual distinction, and you can see it in places outside of undo, too. Any browser has a tactical back/forward button staring you in the face, and a strategic history log hiding deeper inside. Linux offers up/down arrow keys for tactical recall, and history for the ledger:
It all feels like the correct proportionality – the simple thing comes with a quick UI, the heavier thing with an interface that matches its heaviness. This is why I got a bit nervous hearing about persistent undo, because undo is meant to be more like a fruit fly, like stockpiling things on your undersized cafeteria tray, knowing the journey to the table won’t last very long. Undo’s interface is not compatible with longevity.
But even for version history, the devil’s in the execution. Many tools don’t offer version history, and others add to it only at seemingly random intervals. Chrome’s back/forward buttons are wonderful, but its history UI is a hot mess: slow, and with only an infinite scroll when it comes to exploration. Figma’s version history doesn’t make it as clear as it could (sorry, my bad, I never got around to fixing it) that restoring an older entry is not rewinding back to it like undo, but using ledger rules – so it might not feel as safe in use:
But I also wanted to go back to Photoshop and show you something interesting. One of the history settings offers “non-linear history”:
Turn it on, and a fascinating thing happens: There is no poof. Undo behaves more like a ledger, always marching forward:
It is an interesting idea. In practice, it’s confusing – time is not meant to work this way. But I feel this was really close to a nice solution that could be enabled for everyone: preserve the discarded branch, but keep it off of ⌘Z and only show it in the visual UI so you can get back to it this way, perhaps presenting it slightly off the main axis, perhaps, I don’t know, looking something like this:
Okay, technically the future collapse is *exactly* like Back To The Future II, but given you’re the only actor in the universe, you still have to recreate the future all by yourself. See, now I’m starting to sound like Primer.
A fun lil convention from the financial app YNAB’s release notes page – there is always a headlining feature with a hero shot and a long description, but the smaller improvements are still listed as “pocket change”:
Designer Reimar Servas goes further than the usual Border Radius Discourse and thinks about the deeper but often ignored questions of border radii as a system, and about the consequences of such a system that go beyond visuals:
[…] These redesign efforts suggest ignorance of a fundamental problem: rounded forms have a smaller surface area than angular ones. Used as containers, they reduce usable space.
This is fine on most touch-based UIs since they typically feature simple layouts with only a few controls and plenty of white space. Such spacious designs help our fingertips, which demand larger touch areas. A mouse pointer, by contrast, can target much smaller elements.
Professional desktop software — think 3D modelling, video editing, or music production — is often packed with small controls. On these complex interfaces (and the operating systems that host them) screen estate is precious, even on large screens. Heavily rounded elements don’t work well here.
I liked this simple, but powerful visual:
Servas adds:
Apple is well aware that principles from pointer-based UIs rarely translate well to touch interfaces. After all, they spearheaded the evolution of touch UIs and introduced multi-touch interactions like pinch-to-zoom to consumer electronics — formerly only seen in science fiction or obscure research projects . Yet they’re now rolling out single unified design language across watches, phones, desktop computers, and XR goggles.
The piece was written just before the arrival of Golden Gate, which undoes some of Tahoe’s damage. Yet, I remain worried about the rumoured touch MacBook. I consider adding touch to macOS an unsolvable challenge, unless you happen to be okay with compromising on precision and density. I’m not.
Here are a few nice and interesting design decisions I spotted on various websites in the last months.
The pinball repair forum Pinside shows specifically how much time has passed between posts. This is great for orientation and especially when catching up or revisiting – history always gets flattened, and this gives the original story a much more truthful cadence:
In a post from Reimar Servas I mentioned yesterday, you can see generous linking through the writing…
…but also a nice “link summary” at the bottom. I like this because I think this accommodates both people who branch out in the moment, and people who might prefer to read in full, and then explore. Also, it’s just easier to click all of the links if they’re laid out like this:
In the same space, Frank Tisellano provides these interesting callouts. They feel perhaps a little too eager, but I perhaps the eagerness is intentional: they build on how browsers show the URL on hover in the corner as a hint:
I liked kottke.org’s annotation when something is a gift link (here to the New York Times):
In 1996, Street Fighter Alpha 2 was ported onto Super Nintendo Entertainment System, a 1990 machine on its way out and not really up to the task of running such a modern game.
The team put up a hell of a job, involving adding a custom compression chip, with the game being much better than anyone expected – but still suffering from a big flaw, which was a momentum-breaking 3-second freeze at the beginning of every battle.
Turns out, the problem wasn’t the compression chip, but sound effects – and the fix to complelty remove the delay relatively trivial in hindsight. A community member named gizaha posted a patch to the game in 2020, and its description can send shivers down your spine:
Disable some waste sample loads
Sounds good.
Tweaked audio engine for faster start of loading
Alright, fair enough, perhaps the game was rushed to market and some light optimizations skipped.
Faster audio load, upload 2 bytes at the time instead of 1
Oops.
Also in 2020, people set their sights on another 1990s game, Super Mario 64.
For years, if not decades, this has been accepted as fact: Bowser’s sub is just too big and too goofy for the N64 to draw consistently. But what if I told you it didn’t have to be?
Nintendo just… forgot to turn on a C compiler optimization feature before shipping the game. The result wasn’t as egregious as random 3-second freezes, but still gave people much lower framerate on certain levels:
However, Giannakis followed up on that, and discovered the story wasn’t as simple. The optimization in question was still itself evolving at the time, and had known issues when Super Mario 64 was being developed. As easy as it is to turn it on in 2020, all polished and tested, it was a different story in 1996:
The video actually compares the versions visually, and even investigates other optimizations.
But it all pales in comparison to this 2024 video by Kaze Emanuar, who says “hey, guys, you have been looking at the wrong place the entire time” – as a matter of fact, it wasn’t the optimizations that Nintendo didn’t turn on that made the game slower. It was the optimizations they added:
The video is kind of intense, but I feel you can learn a few really interesting things from it:
how you show the debug information matters,
there is such a thing as a “performance lottery,”
naïve efforts to optimize can be heavier than not doing anything at all,
it’s best to optimize for maximizing minimum frame rate, rather than average frame rate.
It’s a fascinating watch, suggesting framerate increases of up to 50% on the original hardware, with just software changes.
Both the Street Fighter 2 Alpha and Super Mario 64 efforts also portray a terrifying notion: imagine your code being hyperanalyzed by a group of people 25–30 years later, pointing at your flaws.
Apple has developed an unexpected workaround to prevent the iPhone 18 Pro Max from being hit by shipping restrictions on big batteries. There’s a “battery-firmware solution” in place on the new iPhones, according to Apple’s support page, which keeps capacity below the 20Wh limit for single-cell batteries set by international shipping regulations — but this firmware lock automatically removes itself when the device is booted up for the first time. […]
If the user needs to send off their phone for repair or resale, the charging limitation can be restored using the “Prepare to Ship” feature, which caps charging to 80 percent for 14 days.
This is interesting, and reminds me of a category that should be present on Unsung more often – software fixing the sins of hardware.
The Max variant of the 737 was redesigned to allow larger, more efficient engines, but this made it less predictable, which the company decided to paper over in software:
The airframe, the hardware, should get it right the first time and not need a lot of added bells and whistles to fly predictably. This has been an aviation canon from the day the Wright brothers first flew at Kitty Hawk.
Apparently the 737 Max pitched up a bit too much for comfort on power application as well as at already-high angles of attack. It violated that most ancient of aviation canons and probably violated the certification criteria of the U.S. Federal Aviation Administration. But instead of going back to the drawing board and getting the airframe hardware right (more on that below), Boeing relied on something called the “Maneuvering Characteristics Augmentation System,” or MCAS.
Boeing’s solution to its hardware problem was software.
This feels like an interesting extension to the fly-by-wire story of Air France Flight 447, where Boeing seemed to be on the other side of the fence to the Airbus. Perhaps no more:
[…] It seems that with the 737 Max, Boeing has changed philosophies about human/machine interaction as quietly as they’ve changed their aircraft operating manuals.
Travis argues that people building the software did not fully understand the shift, and particularly didn’t really understand how pilots fly the airplane during more challenging moments:
Those lines of code were no doubt created by people at the direction of managers. Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world as much as the people who are down on the factory floor, riveting wings on, designing control yokes, and fitting landing gears. Those people have decades of institutional memory about what has worked in the past and what has not worked. Software people do not.
The real reason? Money.
MCAS is certainly much less expensive than extensively modifying the airframe to accommodate the larger engines. […] What’s worse, those changes could be extensive enough to require not only that the FAA recertify the 737 but that Boeing build an entirely new aircraft. Now we’re talking real money, both for the manufacturer as well as the manufacturer’s customers.
That’s because the major selling point of the 737 Max is that it is just a 737, and any pilot who has flown other 737s can fly a 737 Max without expensive training, without recertification, without another type of rating. Airlines—Southwest is a prominent example—tend to go for one “standard” airplane. They want to have one airplane that all their pilots can fly because that makes both pilots and airplanes fungible, maximizing flexibility and minimizing costs.
It all comes down to money, and in this case, MCAS was the way for both Boeing and its customers to keep the money flowing in the right direction. The necessity to insist that the 737 Max was no different in flying characteristics, no different in systems, from any other 737 was the key to the 737 Max’s fleet fungibility. That’s probably also the reason why the documentation about the MCAS system was kept on the down-low.
Put in a change with too much visibility, particularly a change to the aircraft’s operating handbook or to pilot training, and someone—probably a pilot—would have piped up and said, “Hey. This doesn’t look like a 737 anymore.” And then the money would flow the wrong way.
There are some harsh words toward the entire software industry toward the end. This feels directionally accurate to me, and resonated even before the arrival of generative AI:
I believe the relative ease—not to mention the lack of tangible cost—of software updates has created a cultural laziness within the software engineering community. Moreover, because more and more of the hardware that we create is monitored and controlled by software, that cultural laziness is now creeping into hardware engineering—like building airliners. Less thought is now given to getting a design correct and simple up front because it’s so easy to fix what you didn’t get right later.
