One thing I was (and still am) worried about when it comes to my recent big interactive essay is that by showing all these classic desktop examples, the whole thing might appear old-fashioned, relevant only to a bygone era.

Yet, the challenges it shows are universal. Here’s something I just spotted. This is how you rotate an image on an iPhone and on a Nothing Phone:

It’s a pretty standard control – tap once to rotate counterclockwise, tap a second time to do it again, etc. – with a helpful transition of the photo’s orientation so that you don’t lose yours.

Now, I’m going to exaggerate the problem a bit and tap 90-degree rotation quickly eight times. Eight times should result in what engineers call a “no op” – the image rotating twice in full, and ending up where it started. That indeed happens on the iPhone:

But it’s a different story on the Nothing Phone/​Android:

iPhone will remember and buffer the taps, so that the second, pending rotation will happen as soon as the first is done. The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating.

Why does it matter?

I often keep thinking about the framework of situational disability, stating that disability is not just something that happens to a few people and no one else. No, pretty much everyone will occasionally encounter a situation that will make them effectively disabled, and this is why accessibility matters much more than many of us assume:

I think similarly about casual and non-casual use. Photo-taking on phones is typically casual. Phone cameras are typically very good at detecting the photo orientation – but get confused when you’re pointing down. Now, as an example, if you had to take photos of a bunch of landscape documents, you might end up having to rotate dozens of photos, one by one. And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you.

This is, I suppose, “situational power user-ness.” Given a long enough timeframe – or, in this case, a large enough population – even a casual interface like phone photo editing (or, GarageBand) will meet someone who will have no choice but to treat it more seriously and expect more from it.

By the way, buffering the taps is not the only answer. You can also stop/​accelerate the animation after an interrupting tap, and it seems the iPhone does that as well. But the rule is: never force the user to wait for the animation to finish.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Why am I thinking about it all this week?

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

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

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

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

When home computers were new, there was this enduring myth of “killer poke.” POKE was a pretty low-level BASIC command that allowed you to write any number to any place in the memory, as there was no memory protection. From that developed a set of myths of the right magical pairs of numbers that could be input and cause permanent damage to the hardware of the computer, shared in nerd circles almost like campfire stories.

Wikipedia has a pretty dry set of those. The most exciting one there is annotated with [citation needed], and the message seems to be: by the 1980s, this was no longer possible. Even in the earlier version of this idea, Halt and Catch Fire, the “catch fire” was an exaggeration. Before then? Sure, I bet some user actions could damage the computer, but computers themselves, with their high-voltage vector CRTs, electromechanical parts, and even liquid mercury tanks early on, were not that hard to damage.

Unsurprisingly, there are more modern versions of “killer poke,” too. At this point, the best they can do is crash or hang your operating system, but they are still chased, and coveted, and mysterious.

This 10-minute 2021 video from Mrwhosetheboss is a fun story of a wallpaper that could crash your Android OS. I’m not going to spoil the surprise, but it’s not what I expected – although the moment you see the wallpaper in question, you might figure it out.

It’s a fun video, and of that good kind that actually teaches you something.