Here’s another nice detail. If you press and hold ⌘⇥, you will eventually stop at the end. (You can then press ⌘⇧⇥ or ⌘` to go in the other direction.)
However, if you are already at the end, pressing ⌘⇥ again wraps around to the beginning:
The issue of whether to wrap around or not is more universal; you can see it in many lists, ⌘F, and so on. On one hand, it’s nice to have a solid deterministic stopping end that you can rely on, especially since sometimes the last item on the list is special (“See more items…”). On the other hand, going all the way back from the end can be frustrating, too, especially on a Mac that does really strange things with Home/End/PgUp/PgDn keys.
I thought the hybrid approach that ⌘⇥ is doing here was clever, and might be applicable elsewhere.
This is what happens when you go to the homepage of Gemini and start typing quickly:
Mechanically, I think this is React or some other framework setting focus again with some delay, but the end result is… rather disturbing.
While the technical solution would be to fix the problem or at least do not set focus again if already set, I wonder what’s the real challenge here. I imagine it might be that the testing process (if any) assumes using the mouse or trackpad first. In this case, moving the hand to the keyboard to start typing gives the interaction just enough delay to miss the second, unnecessary focus.
I think a good assumption to have for all common interactions is that for some users, fingers are already on the keyboard and things can happen so much faster than you expect.
Not accounting for that, the creators of this flow inadvertently broke one of the cardinal rules. We talked about it in the context of mouse pointers before, but it applies as well to text: don’t move my cursor for me.
There is nothing quite so frustrating as a persistent user interface papercut. You know it’s there, but you keep running into it because the moment you start thinking about what you’re doing instead of how you’re doing it, that knowledge slides away until BAM you run into it again.
I think this is really nicely put and highlights about why it’s very important to care about this kind of stuff.
If you forgo a standard interaction out of carelessness, a bug, bad systems thinking, or for other reasons, you’re not just making your users frustrated by something not working. You’re also at risk of making them frustrated atthemselves, assuming they can change what their fingers do easily, not fully knowing that a) this is motor memory, not just regular conscious actions (and any memory is hard to “update” intentionally), and b) motor memory is separated from regular, declarative memory, and not possible to reason with using the same techniques.
(As an example, it’s very hard when keyboard shortcuts or mouse gestures disagree between apps, because while you consciously might know which app you’re in, that’s not necessarily true of your fingers.)
Waider continues with an example:
The canonical example of this, for me, is Microsoft apps on macOS: even now, decades after Microsoft started producing macOS versions of their apps, they insist on largely disregarding the native UI idioms in favour of their own. Current pet hate is that if I’m commenting on a document, the Ctrl-A/Ctrl-E actions do not work, and boy howdy do I use those constantly.
My recent example is that even though I wrote about Safari overriding the natural “scroll to top/bottom” tap gesture on their tabs – so I am aware of it in my declarative memory, I know Safari designers messed it up, and I know exactly what to do and not do – my fingers still occasionally tap to scroll in Safari anyway.
Every once in a while, I stumble upon a long thread in a random corner of the internet where someone discovers Paste And Match Style, and everyone erupts in applause. “Yeah, it’s a life saver.” “I use it all the time.”“I can’t believe this isn’t the default!”
Then, inevitably someone chimes in: “Oh yeah? I can show you how to make it the default.” And they explain how to wire ⌘V to use Paste And Match Style.
And I always get worried seeing that.
I believe this is the core problem people are bothered by before discovering PAMS – when you copy and paste from another doc, you inherit its style/visual appearance:
And Paste And Match Style, well, does what it promises:
This feels nice. So, what’s the problem? The problem is that PAMS is drunk with power and flattens everything on its way:
That includes:
emphasis by italics or bolding
links
bulleted and numbered lists
strike-through text
headlines
None of these are “style.” This is actual information that should not be removed. If you wire PAMS as your main ⌘V shortcut, or even if you use it occasionally, you might remove valuable data from text you’re moving around, without even noticing.
(And if you do notice, the frustrating irony is that recreating the information lost in transit – for example, re-linking things one by one – is often more work than fixing the style would be.)
If you are designing an app that handles rich text, here’s what I have seen others do:
Do not have styles to begin with. If you use Notion, Dropbox Paper, Medium, or anything that relies on Markdown, they give you no way to customize fonts, colors, letter spacing, and so on, so regular superliteral Paste has a limited blast radius and works well:
Have a very strong center of gravity toward the default style. Apple Notes does this well. Use Notes for years, paste into it from all over the world, and you might never realize it allows you to change fonts and colors. Its default Paste removes style, but it doesn’t remove any valuable information like links or bullet points.
Notes also introduces a shortcutless Paste And Retain Style as a third option after a “semantic” paste (which keeps data and removes style) and PAMS (which removes everything), for those who really want to paste extremely literally:
Word has Paste And Match Formatting that seems to be what Notes does by default, but it’s not the default:
Help users understand the options they have more. For example, Word offers a little post-paste menu. I don’t personally love (it doesn’t have a preview + it doesn’t remember my preference + the options are scary), but it uses better-than-default language like Keep Text Only, and it protects people from the harrowing backrooms of its own Paste Special:
Have some contextual rules – for example Figma does things differently depending on whether you paste into a new text box (preserve style), or a text box that’s already filled (match formatting).
(If you’re seeing some other apps doing something interesting, please let me know!)
Doing the right thing won’t be easy. Books have been written about the illusion of the difference between “stylistic” and “semantic.” People use bolding for either. Others treat headlines as visual style, right aligning means something different in English than it does in Arabic, you might still have to normalize indentations, and so on.
But I believe it’s necessary to put in the effort to make regular Paste work as well as humanly possible, rather than relying on people to know about the far-from-perfect ticking time bomb that is PAMS.
The theme: What does it take to build interfaces that truly allow for fast operation – and why that matters.
If you like the interactive details posts here on Unsung, the essay is kind of a concentrated dose of all that. You can technically read it on the phone, but it’s so much better on a computer (or a big tablet). It has ~40 interactive playgrounds, and sounds, and a glossary, and all sorts of fun stuff I’m doing for the first time.
I wanted to share some things I learned over the years, and nod toward mostly anonymous creators of UX inventions I’ve long admired. I also thought it could be interesting to make interfaces appear as machinery – you’ll see what I mean.
You might have seen Bret Victor’s 55-minute Inventing On Principle talk soon after he gave it in 2012. If not, you should check it out. If you did, you should check it out again and see how it makes you feel today:
It is about interactions but in the service of something grander, which (if I’m doing my job well) you might recognize as Unsung’s core theme.
Victor – a designer, researcher, and computing historian – gave a few other talks in the few years since, and I thought a little guide might be helpful:
Drawing Dynamic Visualizations (35 mins) is specifically about information visualization, chiefly a demo of the “Illustrator, but programmatic” tool showed briefly in the above talk. There’s also a bit more theory.
Similarly, Stop Drawing Dead Fish (53 mins) is a demonstration of a different programmatic tool to make animations.
I love this blend of theory and practice, inspiration and pragmatism, high- and low-level. The tools look surprisingly professional for research projects, but underlying their microinteractions is a deep philosophical stance. It all reminds me a bit of Jef Raskin and Doug Engelbart.
Victor’s last talk of this era is Seeing Spaces (15 mins) from 2015, serving as a sort of introduction of him moving toward computing in physical spaces. As far as I understand, Victor has been spending time on Dynamicland since, which is definitely more physical computing, but also a lot more academic and scrappy, and as such out of range for this blog.
(His website is worth checking out, especially if you’re not in the mood for talks and would like to get to know his work in a different way.)
It’s an impressive list that garnered universally positive reactions, but I have one observation:
“Fast” and variants thereof appear on this list 59 times.
“Reliable” and similar words appear 22 times.
It’s true that everything could be faster and a whole many things should. Speed is paramount to great user experience. Speed is also more than just speed; there are nonlinear aspects when latency or delays cross invisible thresholds that can drastically change app usage for the better.
But in my experience, much more often the things that frustrate me about using Apple’s products are not issues of speed, but issues of reliability:
I don’t need faster network connectivity in Finder, but I struggle with computers not appearing, a pizza cursor that occasionally just dies spinning, or randomly being thrown to the root of the networking volume.
I don’t need AirDrop to be faster. I just want it to connect reliably every single time, give me consistent and understandable UI feedback, and stop forgetting I’m not just “everyone” when sending stuff to myself.
I don’t need Messages to be faster. I need them to just, you know, not haphazardly stop syncing across computers on occasion.
It’s not just me. 15 out of 17 bugs listed on the Bugs Apple Loves site are about reliability. None seem to be directly about speed, although more on that in a second. Or, here’s a recent list from Ilya Birman – different issues, but a similar shape.
I’m going to say it: Speed is an easier problem. Not easier in an engineering sense; I’ve seen an engineer try to carve ten milliseconds out a busy computer’s schedule, and in that moment, one must truly imagine Sisyphus happy. But it’s easier as a problem: it often comes with a lot of pre-built telemetry, plus a clear goal of “here’s Xms and X now needs to be smaller.”
Reliability is much harder, more difficult to debug, reproduce, agree on metrics for, even find ownership of – just generally fuzzy around the edges, and less obviously thrilling as a challenge. It needs more champions and structures.
I know a simple marketing slide is not meant to be an accurate representation of Apple’s efforts. I wasn’t at WWDC so perhaps the vibe in the room was different than what this slide represents. Yet, the slide exists and I’m allowed to judge it.
(And yeah, I know in some cases speed and reliability are correlated. After all, if you have a timeout, making something finish faster and do so before the timeout will turn it from unreliable to reliable. But hey, I wasn’t the one choosing the words on the slide.)
I just… I would be a lot more excited if the 3:1 ratio of fast-to-reliable on that slide went the other way.
In game development, there is this strange effect known as “tunneling.” It happens when you do collision detection. Imagine a simple situation where every time you move a cube, you also test whether it touches the wall – and if it does, you make it bounce off of it.
This works great, but if you move and detect the collision less frequently, something weird can happen:
Here, the movement was so coarse that there was no point at which the cube touched the wall, so the collision wasn’t detected, and the cube passed cleanly through… as if it made a tunnel.
The easy answer seems to be “well, run the collision detection more often then,” but… how often? And what if the entire game engine runs off of computer’s frame rate, which you are not in control of it at all? All in all, it’s not a trivial challenge, although various techniques exist to remedy it.
We talked before about another challenge with frame rate dependence. They’re not limited to games; for interfaces that are based on physics, they will rear their ugly head, too. But tunnelling happens in simpler UI situations as well. Here’s an example from Photoshop – I’m holding a button and if I drag slowly, each item will be toggled. But when I start moving fast…
Fortunately, the remedy here is much easier than in the complex world of videogame physics: just remember the last one touched, and toggle everything in between that and the current one.
Pointer input isn’t continuous. The browser reports the pointer’s position as a series of discrete samples, and when you move fast, those samples can land far apart. Flick your wrist and two consecutive pointer events might be a hundred pixels from each other, with three small shapes sitting untouched in the gap between them.
A naive eraser asks “what’s under the pointer right now?” on every pointer event. At slow speeds that works fine. At high speeds it tunnels straight through anything that happens to fall between two samples, which is exactly when people use the eraser most aggressively: big, fast, careless swipes to clear a region.
Here’s Ruiz’s example of the eraser in FigJam, with heavy tunneling:
And here’s one in his drawing tool:
You can click through to learn more and see the algorithms, but either way it’s worth remembering: if it applies to your interactions, think about the “flyover states” and make sure to make things deterministic, regardless of whether the mouse is a tortoise, or a hare.
And, I liked Ruiz’s sentiment at the end:
[…] The decision to test segments instead of points is the difference between an eraser you can trust at speed and one that mysteriously leaves survivors behind. Users will never notice it working, and that’s the point.
In 2021 and 2022, product manager Steven Sinofsky wrote a…
…first-person account of what I saw at the PC revolution from the perspective of joining Microsoft as a newly hired software design engineer fresh from graduate school working on developer tools, through my time as a program manager and ultimately leading Office, and then moving to Windows, and everything in between.
The first part covers the challenge of the team in 2007, taking stock of Office after almost 25 years of its evolution. (Number of toolbars in 1983: one. Number of toolbars in 2003: 31.) The second part shows great screenshots of all the Office versions from 1.0 until then, and the remaining four cover the Ribbon redesign process.
Regardless of how you feel about Microsoft Office today, and whether you consider the Ribbon interface a success, it’s a perfect weekend read as it covers universal challenges of software complexity and change management.
It’s such a potent series I’m sure we’ll come back to it. It covers a lot, including – in the first part – wrestling with a definition of bloat or complexity, which in the context of Office was less about the number of functions available, and more about mastery:
[…] In practice, bloat comes from the fact […] that Office does so many things that customers just assume the product can do whatever they need it to do. Despite that fact, customers have no idea how to make the product do what they need. This feeling of helplessness that leads to frustration. […]
Bloat is owning a product that you cannot master.
This below is a great observation about the perils of an idea of a “simple mode,” which Sinofsky argues is always a leaky abstraction:
We tried reducing bloat by hiding features […], but that only added to the mystery of the product. Mac, Windows, and Office all went through periods of “simple means fewer” and tried mechanisms such as short menus, simple mode, or adaptive toolbars. But that frustrated or confused people. No one really wanted to use a simple mode and there was always one command missing that was needed, so simple mode became a complicated way to do that one thing that made someone’s work unique.
It was great to see this argument for a broad definition of a bug, as it slides exactly into my post from a while back:
Ages ago in ancient Microsoft history there was a debate on the original apps team about what it means for something to be a bug. Is it a crash? Is it data loss? Is it a typo in an error message and so on? Out of that was created a notion of bug severity, a measure for how serious a bug might be from losing all data all the way to simple cosmetic issues. However, when it came to talking about bugs with product support or ultimately customers the definition of a bug was very simple “a bug is any time the software does not do what a customer expects”. This definition created a discipline of documenting everything reported about the product and always making sure every issue was looked at, even if a code change did not result. The key lesson was how helpful an expansive definition was.
There are also observations and research about how users “debug” the product to make it achieve something they know is possible, but they don’t know how:
We called the futzing document debugging, and it created a frustration that the product was powerful yet overwhelming. People believed a specific result was achievable but getting from point A to B seemed impossible or unlearnable.
And some about the challenges of figuring out what features people use:
[…] Most people didn’t know or care what buttons they clicked on or menus they chose so long as it was working for them—and that meant when asked, “Did you use X?” most people couldn’t recall. To a skeptical press or IT manager (and they all were) that meant unused features.
I should stop quoting and let you read in peace. But, check this out. Lisa wasn’t the only one having linguistic fun:
Early keyboard shortcuts were simple, like using Ins(ert) key to copy text from the scrap (clipboard).
The otherwise excellent note-taking app Bear has an interesting bug that’s worth talking about while it’s still here.
When you’re around to-do items, you can press ⌘. (period) to toggle any task complete or incomplete. It’s actually a really fun shortcut in practice:
But when you have a larger selection with a mixed state (some checkmarks are on, others off), this is what happens:
This feels like an obvious thing to implement, and this is also where the code itself wants to go when left alone.
But this is not great. The rule is: When you have a mixed state, changing it should collapse (or: normalize) the entire selection to one state or the other, rather than perform individual inversion. Try ⌘B in your text editor on partially bolded text, and you can see that collapse in action:
It feels strange to recommend that, particularly as it seems like it loses data. So, what gives?
The first argument is “do not make the user jump through hoops” or maybe “respect a large selection.” If, as a user, I want to actually make sure all my tasks are done, the shortcut not being idempotent means that I now have to go through tasks one by one, and that’s a lot of work – especially since we’re talking about text selection, which is famously unpleasant.
The second reason is that even the UI layer has an opinion here. In the above bolding example, Pages collapsing the selection to bold when you press the B toggle, makes the toggle UI behave exactly as it normally would with a simple selection:
Elsewhere, in Figma, typing a number on top of a “mixed” state changes all the properties of relevant objects to that number:
Imagine how awful it would feel mechanically in both the above examples if your action would still leave the text in the “mixed” state. It would simply appear like the UI broke, since the change didn’t fully “stick” – kind of like those tiny hated moments when you close the door, but it doesn’t latch on and reopens on its own, or when you engage the turn signal stalk, but it refuses to stay put and snaps right back.
There is also one last reason. It’s the simplest one that I sometimes have to remind myself to put in my head before I jump too deep into the mechanics, or details, or technical nuances. Let’s say the toggles invert individually on a large selection. Who would ever benefit from it behaving this way?
In Figma, when choosing a font, you can filter down a list of fonts from “all” to specific categories or e.g. only fonts present in the current file.
But when you type into the search field, the search cuts across all fonts again, ignoring the applied filter. The search effectively lives outside the filter.
In Keyboard Maestro, when adding an action, you can click in the nav to filter down to a specific category. And when you search, the current filter remains active, so you search inside the filter.
Which one is better?
I don’t have a universal rule here, because it will depend both on the UI treatment, and the specific filters and searches people do.
But I think here, my recommendation for Keyboard Maestro here would be to do the same thing as Figma does. I designed that flow in Figma, so I might be biased, but my reasons are:
There aren’t really a lot of options in each category, so you don’t benefit a lot from double filtering.
But the most important thing: For both Figma and Keyboard Maestro, the text field might smell like a text filter and as such expected to be multiplexed with the category filter, but I think this field is actually something else: It’s quick keyboard access, like ⌘F or Spotlight or Raycast. And if you think about it this way, it’s important for it to be deterministic – I can always type “Output Sans,” no matter what state am I in, and get to the font.
On that last note, I find it’s good to look around what you’ve designed once in a while and consider not what the UI set out to be, but what it became – there might be more examples of that around you.
To me, “tap anywhere at the top to scroll to the beginning” is an amazing and underappreciated mobile gesture:
It not only provides an alternative to desktop‘s Home and ⌘↑ keys, but the student laps the teacher here; it’s actually better than every way to scroll to the top on desktop (do you like pressing ⌘↑? do you even have a Home key?), and it’s an icing on a cake of a regular flick to throw the page to the top already being pretty nice.
Tap to return to top is also distinctively mobile in that it allows you to tap just anywhere near the top edge that’s not already a tap target; as far as I can observe, traditional GUIs detest being imprecise in this way, always asking you to click on something specific (although window moving on macOS in the post-title-bar era is also starting to feel similar).
The iPhone gesture seemed to work so well that, over the years, more patterns started borrowing from it. In Bluesky and tons of other apps, you can tap on any tab with scrollable content a second time to scroll all the way to the top. (Again, something that’s hard to imagine on desktop, where you pretty much almost never think of clicking on an already-selected item.)
It’s not just the top, either. In Podcasts, tapping Home goes back to the left:
And in Photos, to the bottom:
To me, the whole “tap to return to the beginning” gesture universe feels ascended to be the core property of the interface. In that way, it is similar to scrolling, undo, copy/paste, arrow keys moving the text cursor, and so on, all inducted to the National Register Of Historic Gestures.
Why? Because these gestures can only blossom if they work consistently, everywhere. You need to start trusting them so much they slide into your subconsciousness. Breaking the gesture in one place will make it less trustworthy in other places, too, ejecting it from motor memory back to the level of deliberate effort, and therefore making it a lot less usable. “Does this thing work here or not?” is a death knell of flow.
The fact that tapping on tabs is idempotent means there’s also no penalty; if you’re already at the beginning but are not sure, tapping it mindlessly won’t hurt or send you back somewhere else.
This is all great. And this is why I’m unhappy Safari started mucking with it.
Safari has tabs at the bottom – starting with two (regular set and “private” set), although you can add more. Above is a long list of site cards, with newest at the bottom. It’s exactly the same situation as in Photos, and yet tapping on either tab doesn’t restore the scroll position. Instead, it opens the settings dialog:
And, tapping around the buttons does nothing.
I would imagine Safari is a pretty important app used by many people, and so this feels like a bad place to introduce an inconsistency that could have a more serious consequences of un-teaching people about tap to scroll to top in the long run.
The funny thing is that the solution is already there: you can tap ··· in the upper left corner to get to the same functionality. The long press on the tab also opens the same menu.
Messing with a “tap to go back to the beginning” system gesture like this means to me the design team doesn’t fully share the understanding of the value of their own creation, or maybe that stewards of the gesture system are not vigilant… or perhaps the awareness is there, but the caretakers aren’t recognized, rewarded, or empowered enough.
It’s similar to the “no, thanks” example I shared before, a possible worrisome tragedy of the UX commons in the making if the respective teams do not change course. Because, wedging that sort of an exception in – even if you have a great set of reasons in the moment – creates a precedent. Inevitably, from my experience, the next team that will want to override scroll to top, or misuse “No, thanks,” will now require less of a justification.
Software engineer Ajitem Sahasrabuddhe recently wrote a 6-post series called “Iron Core” about airline ticketing infrastructure. The entire series is probably too software engineer-y for us, but the third part has some interesting info about a particular 1960s user interface called “cryptic mode”:
Cryptic mode was born from a hard constraint: teletype terminals in the 1960s billed by the character transmitted. Every keystroke cost money. A command that took 50 characters instead of 10 cost five times as much. Commands were compressed to the absolute minimum.
The result is a domain-specific language whose syntax was shaped entirely by economics. AN for Availability Next. SS for Sell Segment. NM for Name. ER for End and Retrieve. No vowels wasted. No words spelled out.
Apparently the official name is “native mode,” but it gained its nickname because… well, see for yourself.
Asking the system for “Availability for Next flight” for February 8, from Nagpur to Delhi, is just 13 characters:
AN08FEBNAGDEL
And the system responds in an equally mysterious way:
** AMADEUS AVAILABILITY - AN ** NAG DEL SU 08FEB 0000
1 AI 416 Z9 C9 D9 Y9 B9 NAG DEL 0840 1030 32A 0
2 AI 416 M9 H9 K9 Q9 T9 NAG DEL 0840 1030 32A 0
3 6E 5317 S9 T9 W9 V9 Q9 NAG DEL 0840 0755 32A 0
With time these commands became wrapped inside more approachable interfaces and GUIs. But they exist under the hood and…
Many experienced travel agents still use it today alongside, and sometimes instead of, web-based agent interfaces such as Amadeus Selling Platform Connect. For a trained operator working a booking-heavy workflow, it is faster than the equivalent graphical interface for the same sequence of operations.
Except today, you get to choose. At the beginning, when “online” didn’t imply internet, and registration computers looked like this, you didn’t have a choice: this was the language you had to fluently write and read.
In his latest video, Shelby from Tech Tangents unpacked, installed, and put to use a truly forgotten product: IBM 3119, one of the first consumer flatbed scanners.
The setup was a small nightmare, needing a rare hardware card installed in a specific computer, an ultra-particular combination of two operating systems working in lockstep, and even some careful memory balancing.
Even after all that, a 300dpi page scanner in the late 1980s was still a force to be reckoned with. It’s hard to remember how enormous scanned files were compared to anything else then, even on a black-and-white scanner like this one. The video shows a simple 90-degree image rotation in highest quality requiring over 9 hours, and I believe it.
But deep inside the video, at precisely 19:31, for only ten seconds, something appears that is absolutely worth celebrating. The nascent scanner software has a “curves” feature that allows you to redraw the shades of gray to capture shadows, highlights, and midtones exactly how you want them. Today, the feature would look something like this, with a real-time preview:
There would be absolutely no way to do something like this in the late 1980s, when just rotating an image is an overnight operation, right? And yet:
How was this accomplished? Absolutely brilliantly. Remember the palette swapping technique? Here, the entire screen’s palette is 256 shades of gray. It’s a very particular kind of a linear palette, and so you can easily take that line and… well, turn it into a curve. Since palette swapping happens on the graphic card, it takes as little as one frame of time, allowing for it to react to mouse movements as they happen.
This must have been mind blowing to experience in the moment. Sure, it’s only a preview, and actually applying curves to the image would take many minut—
No. This is a wrong frame of mind. Here’s my hot take: There are moments in software where the preview is more important than the feature following it. That’s because the preview making things faster isn’t just the difference between finishing something sooner or later. It’s a difference of doing something or not doing it at all. Would you even attempt to use curves if each adjustment took minutes or hours, especially in a land without undo?
I love this preview that hints at what the future will be. I like this clever use of extremely limited technology and tight collaboration between engineering and design. It must have been nice to be in the room whenever someone had the flash of insight to use palette swapping this way.
I want to show you something glorious. This is Bear, the note taking app:
There are desktop apps that get flustered if you ⌘+Tab away and back, misplacing focus or closing a dialog box inside. There are iOS apps that fully reset themselves whenever they get swapped out of memory and have to be reloaded.
But Bear, right here, remembers which note you were on, and exactly where you were in that note, even between phone reboots.
Software is transient and malleable, and one of the hard parts is knowing when that’s beneficial and when detrimental. In real life, you can leave a notebook on your desk, open on a certain page, leave a pen pointing to a specific word – and then depart for a two-month trip to Europe. You will find your notebook exactly how you left it. Why shouldn’t software behave this way?
Also, another thought: This is very likely not something users will complain about when broken, or suggest when absent, even if you go out of your way to open yourself for feedback. Just swapping an app out of memory is hard to understand and “repro” (in engineering parlance). There’s a certain design mindset and taste necessary to notice and care, and a certain vision to carry it through.
The lack of direct user feedback doesn’t mean it’s not worth doing. It just means that there are some things that designers and only designers will know how to properly weigh, describe, and prioritize. If you have a few design-minded users that actually send you feedback like this – treasure them. But most likely this will have to come from “inside the house.”
To me, it’s clear that within Shiny Frog (the makers of Bear), there are people who care about this kind of stuff, and leadership that trusts them. Kudos.
This is perhaps my favourite feature in Lightroom. You press ⇧T, you draw a few lines, and presto – your photo is now even:
This is doubly magical to me. The first part is that this is even possible – that you can straighten the photo in both dimensions after the fact, and save for some parallax nuances the viewer won’t know any better.
For decades, this has been the domain of tilt-shift lenses, but if you ever tried to use one, you know how harrowing of an exercise this is. A tilt-shift lens looks more like a medical device and less like a piece of photography equipment:
The “obvious” way to emulate a tilt-shift lens in software is a bunch of sliders, and Lightroom has those also…
…but that’s still pretty cumbersome in practice, abstracted in a strange ways, like piloting a plane by pulling the linkages connected the flying surfaces: you will admire someone who can do that, but won’t ever want to do it yourself.
Hence the second magical moment: The team created the new interface I showed at the beginning, where you point to things that should be straight directly, and the necessary tilt-shift calculations happen behind the scenes.
Alas, Lightroom didn’t fully stick the landing. The interface is a bit jittery, and missing nice transitions that could help understand what’s going on. But what brought me here was this unpleasant interaction:
What’s wrong with it? If you want to play along, stop here and ponder: How would you improve it? Because this is a classic UI exercise where there are symptoms, and there are problems, and there are principles under the hood of it all.
The first possible improvement: Don’t do a dialog like this. These are ancient and so annoying. Every time I see a centered dialog covering everything, popping up in response to a delicate mouse operation, I want to shout “read the room!” It’s better to drop a little tooltip next to the cursor that automatically disappears: more modern, and more “compatible” with mousing.
Then: Why am I allowed to start and finish an action that the machine already knows won’t go anywhere? Disable the drawing option, put a little “verboten” icon on the mouse pointer, or do something else that will prevent me from drawing a line to begin with.
But that brings us to point three, and how I would approach this as a designer. Because I would – counterintuitively – go the other way and allow the user to draw as many lines as they wanted, and just didn’t permit to commit the entire operation if there were more than four lines on the screen.
Why is that?
It’s the same principle as you see in all the social media composing fields, and in well-trained forms: do not constrain the editing process.
This field is limited to 300 characters, but it’s clever enough to only enforce its limits when you try to post. There is no downside to allowing you more room in the editing process. Maybe you write by constructing a few sentences first and only then combining them into one, maybe you want to see two riffs one below the other to choose the better one, or maybe – this is most likely – you’re not even paying attention and your motor memory is doing the editing for you, instinctively. Use any text editor for just a few months, and cut, copy, and paste, word swapping, and splitting sentences become second-nature gestures – that is, until the UI starts throwing in some arbitrary barriers.
Above in Lightroom, it might actually be easier for me to draw a fifth line and then delete a previous one, instead of doing it in the precise order Lightroom desires, or by dragging an existing line to move it instead of creating a new one.
Maybe an overarching principle would be this: If you are aiming to build something so delightfully direct manipulation as Lightroom did here, you have to fully commit to that stance, even deep in the weeds. Because every time I see a 1990s dialog appear when my fingers are flying fast, I feel like this:
To follow up from yesterday’s post, in Figma, object selection actually goes onto the undo stack. This is because in a professional tool with objects in multiple levels of hierarchy, it might take a while to construct a selection to work on – and since selection is always just one accidental click away from being completely cleared, undoable selection is extra protection.
However, at the same time renaming a file – or changing settings like file access – is not undoable. This is in part because we didn’t feel people would understand they could cancel out their rename this way (Safari too used to have “reopen last tab” under ⌘Z, until it reverted to Chrome’s ⌘⇧T), but mostly because you could accidentally undo through a file rename during regular work if you were not careful, without noticing, and that felt like it’d have more profound consequences.
In some ways, it helped me to think of these not as “ineligible for undo” but rather “living outside of time.” The moment a file is renamed, it will always have been named that way. (For the purposes of undo, at least. You can acknowledge anything you want on the version history screen.)
I’m not saying these are universally correct choices – as a matter of fact, some users find undoable selection (at least initially) pretty confusing! – but mostly sharing these as examples of intentional thinking about what deserves undo, and what should be exempt from it and taken care of elsewhere.
I am a huge fan of all sorts of “recent” features in software; I think they’re extremely helpful in removing tedium, and thoroughly undervalued. A lot of our work is repetitive, even if it’s sad to admit.
1.
My bank’s website not only shows me the last payment I made, but also allows me to click to use the same number again:
2.
The app Transit has a nice list of recent destinations just below the main options:
3.
Google Maps promotes recently tapped-on items to be more visible than they would normally be:
4. CleanShot X offers something I have always wanted from built-in macOS screenshotting – being able to capture with one keystroke the same area as I delineated last time:
5.
Google Pixel allows you to swap the current wallpaper and three previously chosen wallpapers easily:
What unifies all of these is that “recent” doesn’t live in a submenu somewhere, treated as a second-tier pathway. No, in all of these “recent” is embedded in the fabric of normal interactions, side by side with forward-facing options. I believe this is necessary for any sort of feature like this to be truly successful.
That last Google Pixel example also shows that “recent” isn’t only for repeating something faster – here, it becomes more of a “soft setting,” without introducing a lot more complex UI and interactions that a “real” setting might require.
The gist of it is simple: the mechanics of following a link are not important, and should be replaced by something that can make the link stand on its own. This is important for screen readers, but also for basic scannability: a “click here” label has a lousy scent and requires you to take in the surroundings to understand what it really does. The rule is, in effect, a variant of “show, don’t tell.”
(In modern days, you can also add another transgression: on touch devices one cannot click, but only tap.)
There is a similar rule about button copy design. Button labels, too, should be self-sustainable. Below is a good example (just reading the button lets me understand what I’ll achieve by clicking it), juxtaposed with the bad one (“OK” is so generic you have to read the rest of the window).
Earlier this week, I was passing some train cars on my coffee walk, and saw this bit of UI:
Why are these okay, and “click here” is not? Here’s why, I think: Yes, the ultimate goal is to move a train car, or empty it, or send it on its way. But here, the mechanics matter, too. They’re dangerous. They require preparations. No one says “I’m going to open my laptop and start clicking on links,” but I imagine people say “we have to jack this car” or “we need to lift it.” Even “here” has depth: these are specific tool mounting points. Choosing the wrong “here” will have consequences.
But, going back to the web, avoiding “click here” in strings isn’t always easy. Imagine trying to put a link in the sentence “To change your avatar, visit the profile page.” I’m personally never sure how to linkify it well:
To change your avatar, visit the profile page.
To change your avatar, visit the profile page. To change your avatar, visit the profile page.
Linking “change your avatar” seems correct since it points to the eventual outcome, but then it leaves the actual destination dangling and unlinked – like putting an accent on a wrong syllable. “Visit the profile page” is better than “click here,” but it’s still not scannable. Linking the entire sentence seems strange and complicated to me, and I also disagree with Tim Berners-Lee, who on the page I liked to above seems to suggest this should be…
To change your avatar, visit the profile page.
…just because this might make a user think there are two separate destinations and actions, and contribute a wrong mental model.
You could, of course, simplify this to “Change your avatar,” but while that would work in a UI string, it wouldn’t within a larger paragraph of text, or a blog post.
Wakamaifondue is a web tool to inspect font contents, and it starts by you dropping a font file (.ttf, .otf, or .woff) into a browser.
It handles file dropping so thoughtfully, it’s worth pausing and recognizing it:
Here’s what’s great about it:
You can drop the file anywhere. There is no designated small drop area like in some other apps; every last pixel of the window is ready to receive your file, so you can drop without worrying.
You get a hover state confirming you are safe to drop.
You can drop the file on other screens, too!
Why is all this important? Because dropping a file into a browser is a notoriously frustrating experience. If the tab doesn’t claim the file, left to its own devices the browser will do anything from replacing the current tab with the contents of the file, through opening a new tab, to… starting to download the file you just dropped and ask you for its new location!
It is frustrating when a failure mode of an action is not just that action failing – already here, repeating a drag is more work than e.g. repeating a keystroke – but also you having to do extra clean-up steps.
Wakamaifondue gets this right, and allowing to drop a file on any screen in particular is very thoughtful. Your cursor holding a file indicates your intentions rather strongly – when you see a person wearing a wedding dress, you don’t think “I wonder what they’re up to today?” – so there should be no need to switch to a certain mode or to navigate to an “import screen” beforehand.
Right next to the generic function to delete photos by going through them one by one, my camera has a specific version – Delete All With This Date:
Below the actions to close the tab, and close all other tabs, Chrome has a specific version called Close Tabs To The Right:
In After Effects, next to typical save options, there is this – Increment And Save – which saves a file and changes the number at the end to be one notch higher (Project 2 → Project 3, and so on):
I’m mildly fascinated by these strangely specific accelerators.
The one in the camera is genuinely useful. Photo projects are often day-long affairs where you download the photos at the end of workday, but might still keep them on the card just in case. Allowing to quickly delete a day’s worth of photos makes a lot of sense, saving you from having to go through them one by one in an interface not suited for that kind of operation.
Chrome’s “Close Tabs to the Right” takes a bit of figuring out, but I believe it’s meant to make it easy to clean up after a fruitful research session where you kept ⌘-clicking and opening tabs to learn more, and those tabs now fulfilled their purpose. (Curiously, Firefox also has “Close Tabs To Left” which I don’t understand.)
After Effects’s “Increment and Save” is… I don’t know. Maybe it’s cheap? Maybe it’s honest? A proper version history would be nicer, but that’s a tall order. This is simple and, most importantly, reliable. I still often do the “poor man’s version control” elsewhere…
…so this works for me.
It’s always interesting to me to think whether these kinds of oddly-specific examples are nice gestures toward the user, or treating symptoms in lieu of fixing actual problems. Either way, I don’t think an interface can survive too many of these, as their obscurity and weirdness add up and can contaminate the entire UI.
Would love if you sent me more of these kinds of commands from the apps you use!
One of the casualties of Apple’s otherwise brilliantly executed transition to retina pixels has been the mouse pointer, which remains aligned to what “traditional pixels” used to be, rather than the retina/physical/smaller pixels.
Turn on the zoom gesture from a few weeks ago, and you can see the challenge. The gridlines are ½ logical pixel and 1 physical pixel wide:
This limitation is inherited by most tools: Photoshop, Affinity, xScope, even the built-in Digital Color Meter. It’s not the end of the world, of course, but it can be maddening if you are trying to sample a color from a “half pixel” and the cursor stubbornly skips it no matter how delicately you move. Here it is in Figma:
Of the few tools I tested, only Pixelmator allows to sample at the correct, precise level:
I was curious how would a truly precise cursor feel in general – would there be any disadvantages? – so I built a little simulator that allows a regular arrow cursor to be aligned to “half pixels” or “retina pixels.”
In the process, I discovered that both Chrome and Firefox already receive sub-traditional-pixel measurements for mousing events, so this was even easier to build than I expected. Now, precise targeting in Chrome and Firefox becomes possible:
I don’t personally see any big difference in terms of either upsides or downsides, and I’m curious if you do. iPadOS and its Safari already seem to support the precise mouse pointer, too. That makes me curious: why isn’t it available in macOS? I imagine you could even turn it on by default for apps – or, if you want to be more conservative, make it opt-in.
Pixelmator also shows that the apps can do it without waiting for macOS as the data is already there; they would just need to render the cursor on their own with more precision.
It’s a fun (as always) watch, but as a UX designer, it’s also interesting to try to figure out what are the underpinnings of the things Staecker lists as strange from today’s perspective.
I believe that “CE/T” (clearing and totaling) coexisting on one key is a nod to professional accounting use of adding machines where you wouldn’t want to accidentally enter something into the record twice – so totaling also automatically resets the value and prevents you from making a mistake.
I also believe the strange [+=] rule is only because the keypad has to look forward at the same time it is looking back: it needs to serve as a universal computer keypad where [+] and [=] are separate key, but it also needs to pretend to be an adding machine where one key served both purposes.
(You can spot that the back of the box just allows you to swap the [+] key to be something else.)
Overall, the video is a fascinating tale of an “in-betweener” product that was stuck not just in the middle of a transition from physical devices into apps, but also at the intersection of calculators and adding machines (once two very different lines of products), themselves trying to learn from each other. It also serves as a great reminder that skeuomorphism is not just about visuals and sounds, but also behaviours: tearing off the tape, details of specific keys, nuances of rounding.
It’s not a thing of the past, either. In my post about determinism I linked to Apple’s recent travails with the deterministic Clear button (part one, two, and three). A few years ago, Apple also changed the built-in iPhone calculator from its “desktop calculator” roots to a more modern model where you get to input the entire equation before you see the result. But that change had bigger consequences; for example the [=] key could no longer repeat an addition. People complained, and Apple added it back – but the change feels incompatible with the new system and potentially confusing:
Elsewhere, the entire iPhone is an in-betweener, as the keypad coming from calculators is incompatible with the keypad coming from phones.
At this point it seems the calculator keypad will win, but transition has been over a century in the making. Staecker’s video is a good reminder how important, but also hard it is when you try to make these transitions happen faster.
A few years ago, I suggested adding a new interaction to Figma. If your text cursor was on a misspelled word (anywhere inside, or the edges), you could press Tab to quickly accept the suggested correction, without even seeing it:
Independently, Google Docs approached it from a slightly different angle, but landing on a similar interaction – in their version there’s a small visual callout, although you can still press Tab (and then Enter) to accept the suggestion:
I know the Tab key has a lot of jobs – from indenting bullet points to jumping through GUI elements – but in this context this new addition doesn’t seem to be in conflict.
(Should I write a long photoessay about the Tab key, similar to the ones I wrote for Return/Enter and Fn keys?)
Since we added it, I’ve really loved how it feels. From various typeaheads and autocompletes elsewhere, Tab has a strong “forward movement” energy so it makes conceptual sense, and it’s just really fun to go around and quickly fix your writing this way.
I think a lot about how to make keyboard interactions feel superpower-y: a good keyboard shortcut on a large key, a tight interaction, a blink-of-an-eye velocity – something that’s eminently designed to lodge itself in your motor memory as quickly as possible, as it builds on top of prior motor memory. I’m biased, of course, but I like the “no scope” Figma version more, and it has that feeling to me.
Recently, spelunking in the preferences of Photoshop 2025, I found this extremely curious thing:
To transcribe:
Focus mode limits the appearance of certain optional user interface messages so that you can use Photoshop with fewer interruptions.
With this option enabled:
The Welcome screen will not include “what’s new” feature descriptions
Blue in-product alerts promoting discovery and use of certain features will be suppressed
What’s New will not auto start when Photoshop is launched
The color mode preference will be auto set to “Neutral Color Mode”
The three first options should be self explanatory. Neutral Color Mode is sort of the “graphite” option of Photoshop’s UI where the (already rare?) accented blue elements become white instead.
As much as I’ll always applaud a piece of software working on annoying you less, this is all so very strange. I don’t mean that the last option seems unrelated, and the first and third one kind of mutually exclusive… but just the very idea of shoving it in as an opt-in in the last tab of settings, under “technology previews”, and asking people for feedback feels peculiar to me.
Not to spoil the outcome, but even this “technology preview” is completely gone in the updated Photoshop 2026. I wonder if this is fallout from a mangled launch (even for those few who I imagined turned it on, the option didn’t live up to its promise), but also perhaps a political fight inside Adobe between product and growth teams? I bet we’ll never know.
I do not personally have a grand unified theory of how to explain things or announce features in products because it’s so situational, and I understand that especially Photoshop given its age might be the hardest difficulty level. I’d personally prefer to receive announcements of new features over email so I can read them at my leisure, and with each new thing or change linked to a playground that would allow me to experience it in the best way – but I can’t say with any certainty that this would work for everyone.
But I would expect people on the Photoshop team to have more experience here, and this focus mode approach just feels a bit… naïve to me. My two warm takes: 1. People aren’t generally as frustrated with how features are announced, but with what features are. 2. Why wouldn’t everyone deserve the gift of focus?
⌘T is a very important shortcut in Slack. It allows you to quickly talk to someone just by typing in their name. I use it probably dozens, if not hundreds of times a day.
⌘T is right next to ⌘R, which reloads Slack. Occasionally, on the way to ⌘T, my fingers graze ⌘R. Fingers being fingers, I immediately realize something went wrong and wince, and within a second or two I witness Slack completely reloading. It’s not a big deal – no data is lost, and the reload is only 5 to 10 seconds, but when you move fast, it feels like eternity.
⌘O is a very important shortcut in Finder. It opens the selected file in the correct app. I use it probably dozens, if not hundreds of times a day.
⌘O is right next to ⌘P, which prints the file I’m pointing to. Curiously, and in contrast with most apps, the print function is not gated in any way by a confirmation dialog box, or an intermediate print settings window.
So, occasionally, on the way to ⌘O, my fingers graze ⌘P. Fingers being fingers, I immediately realize something went wrong and wince, and within a few seconds, the lights in my old apartment dim for a second. Then, far away, I hear the recognizable sound of my laser printer spitting out a page.
Gamers used to deride Windows key for automatically ejecting them from the game to the desktop, before an option to disable it started appearing in gaming keyboards. (Some of the professional gaming leagues were very strict about how a player could use their keyboard.)
Similarly, professional Excel champions and players started physically removing keys: In Excel, F1 (right next to an often-used F2) opens the help dialog and slows you down.
I served as a judge for the ModelOff Financial Modeling Championships in NYC twice. On my first visit, I was watching contestant Martijn Reekers work in Excel. He was constantly pressing F2 and Esc with his left hand. His right hand was on the arrow keys, swiftly moving from cell to cell. F2 puts the cell in Edit mode so you can see the formula in the cell. Esc exits Edit mode and shows you the number. Martijn would press F2 and Esc at least three times every second.
But here is the funny part: What dangerous key is between F2 and Esc? F1.
If you accidentally press F1, you will have a 10-second delay while Excel loads online Help. If you are analyzing three cells a second, a 10-second delay would be a disaster. You might as well go to lunch. So, Martijn had pried the F1 key from his keyboard so he would never accidentally press it.
I enjoyed this essay that presents prying off the key as a rite of passage:
Removing the F1 key from the equation is just the beginning. By embracing the keyboard-centric approach, you have the opportunity to become an Excel Wizard!! Okay, maybe that’s not a technical term, but it perfectly captures the essence of those who navigate Excel solely using the keyboard.
And I particularly liked this tongue-in-cheek answer telling people they could construct their own homemade molly guard to protect against “fat-fingering”:
Here’s an alternative snippet that can be used:
Use bits of plastic or cardboard to make a tiny box that fits around your F1 key.
Affix this box with duct tape, so that the F1 key is guarded.
Fool-proof, works on any key, and can easily be reversed if needed!
Obviously, none of this can help me with my ⌘R and ⌘P woes, so, two final thoughts:
If your app has a well-trafficked shortcut, it’s worth thinking of the shortcuts immediately adjacent to that one. Could they cause any inadvertent damage or confusion?
Apps and operating systems should very easily allow you to unset a keyboard shortcut, in addition to setting or changing it. (Unfortunately, this is not as common as it should be.)
This video from Marblr about adding fall damage to Overwatch is really intense – 45 minutes of length and a lot of footage of frantic gameplay – but really informative, too.
It’s a great case study of how something seemingly really simple – deducting health from the player as they fall from height – can be a complicated thing to figure out in all the detail.
I never played Overwatch and rarely play videogames anymore, but many of the lessons here more universal for any sort of UI and system design:
You will have to introduce tactical inconsistencies for the system to feel consistent, but be careful as there might be a point those inconsistencies start to outweigh the whole thing.
Wanna learn how you and others feel about something? Overcrank it to make the feelings come out more easily. (And to find bugs.)
There will always be tensions between what the data says and how you feel about something. (I was surprised how often the word “intuitive” entered the picture.)
Also, it’s just a really well-made video, filled with little presentation and storytelling details that elevate it. I wish more videos like this existed for UI mechanics.
But maybe the most important takeway? You don’t have to choose between rigor and fun. You can have both.
I just stumbled upon a nice little power-user innovation in Chrome’s Web Inspector.
In Safari, and previously in Chrome, when editing CSS properties, you’d get a usual editing typeahead for the property name, and then the same on the other side for the property value.
In newer versions of Chrome, the typeahead menu works as before on the right side. However, the menu on the left side also includes the right side.
I think this is really clever in this context – not just to speed you up, but also to aid understanding. Just like the inert mouse up and down in the previous post could serve as a safe “peek” into the values, this new interaction can quickly allow you to explore the CSS space if you are curious, or if you only lightly remember part of the name, or even just one of the values.
This blog is authored in Apple Notes, and some time ago Notes added quick linking via typing >>, and that has a similar effect: The interactions are so nimble and precise that it is very easy to link to something, but a nice side effect is that it also feels very welcoming just to type a few letters to remind yourself of a title of an article, and then cancel out.
The downside of the Chrome change is, well, more stuff matching, but I think the audience for this UI is going to be okay with that.
I know we’re probably collectively a bit tired talking about macOS Tahoe, but I just noticed something that I think is a good example of how small details can ladder up to bigger things.
This is macOS Sequoia (the pre-Tahoe release) and a typical pop-up button:
One clever thing macOS has been doing since basically the dawn of GUIs is that upon clicking on a button like this, the currently selected row will be in the same place as before you clicked. (As opposed to, for example, the entire menu appearing below like it would from a top menu bar.)
This has interesting and often underappreciated consequences. It allows you to orient yourself quicker since you don’t have to find the selected option again. And, it saves you movement overall: the next or previous option will always be at the absolutely shortest possible distance. (Of course, the approach also has some challenges,for example if the button is positioned close to the top or bottom of the screen.)
There’s another clever thing that happens throughout macOS: All the menus work using a classic click-to-open and click-to-select sequence, but they are also usable via the slightly more advanced, but faster mousedown-drag-mouseup gesture.
These building blocks work together and mean that selecting the next option can be as simple as a little flick of a mouse.
Now, check out macOS Tahoe (current release):
You will notice that iCloud Drive, upon clicking, is now misaligned both horizontally and vertically.
On the surface, this feels just like a visual blemish – slighly embarrassing, but without much consequence. But check out what happens if you hold your mouse button at a certain position, and then release it without moving:
The stability of macOS’s interface and the thoughtful set of aforementioned rules allowed for an emergent fast behaviour: mouse down and up meant you could “peek” into a menu safely, or you could change your mind right after seeing what’s inside. In a bigger sense, it created a certain trust between you and the operating system: it’s worth learning those gestures, as they will be rewarded.
In Tahoe, some of that learned behaviour – by the way, I see it in all of these buttons, not just this one – will now work against you. Now, you can accidentally change an option without intending to do so.
Is it a big deal? No, not really. This likely – hopefully! – simply fell through the cracks in a rush to get Liquid Glass out the door, rather than no one being there to care, or no one understanding that all these gestures add up in aggregate, creating a GUI that feels fast, trustworthy, and catering to your motor memory in a way that elevates your experiences with the interface in the long run.
But I’d feel better if it wasn’t almost half a year since the release, and if we hadn’t already seen other things exactly like it.
Mac allows you to assign keyboard shorcuts to menu items, but the interface is clunky – you have to select the app even if you just came from it, and then type in the menu item name by hand without any assistance:
Other tools, like Keyboard Maestro, do something similar. You either have to type it again, or you can point to it, but in a replica of the menu of the app shown in a very different style and orientation:
But this week I learned of another app, KeyCue, that approaches this differently. You simply point to the menu item and hold the desired key for a while:
Okay, this is not a universal endorsement. The feature works clunkily, and KeyCue as a whole is way too comfortable adding itself to login items without asking.
But as far as singular interactions go, this is great and eye-opening. It made me realize that the previous things I’ve shown – System Settings, Keyboard Maestro – are really not GUIs, and they don’t practice direct manipulation. They’re still partially command line interfaces dressed up in GUI clothing.
We kind of lightly made fun of Jony Ive going angelic on “staying true to the material” and things being “beautifully, unapologetically plastic.” And there is, of course, value in command line and those kinds of approaches. But this part of KeyCue at least is unapologetically a graphical user interface, and it is nice to still be surprised in this space.
I keep thinking about this very good 11-minute Not Just Bikes video about traffic calming. In it, a simple argument is made: the posted speed limit of any given street or road doesn’t really matter. What matters is how the street feels. Generously wide and separated lanes, sparse traffic lights, and the road being straight past the horizon will make you unconsciously speed up. Reducing the posted speed limit or adding flashing YOUR SPEED signs won’t help:
The truth is that many drivers will not slow down because of signs or speed limits. They’ll slow down either because they don’t feel safe, or because they’re afraid of damaging their car.
The only answer is redesigning the street for the desired speed limit – narrowing the lanes or joining them, creating choke points and speed bumps, adding posts and planting trees close to the road, and even adding visual cues like “dragon’s teeth.”
One of the great thing about driving in the Netherlands is that it’s rarely necessary to look at the speed limit. The road design takes care of that for you.
There is an app I use a lot called Forklift, a suped up Finder, with one of its functions being syncing files to a remote server.
In its version 3, the syncing window looked like this:
This is a pretty straightforward and dependable function – and I’ve depended on it for years.
I recently updated to version 4 to check it out, particularly since it promised faster syncing. But I was thrown aback by how it randomly deteriorated:
It’s not that there seem to be some UI challenges: the new icons make it harder to understand hierarchy, and one of the switches starts with “Don’t” in contravence of rules of avoiding double negatives.
No, the worst part is this:
This is a new temporary state that meant to help me understand the details of what’s changing.
On the surface, it’s a thoughtful thing. But it’s done in the worst possible way for this kind of a power-user interface: It’s very slow to invoke and slow to cancel. I often activate it by accident – it makes large swaths of UI a minefield where you can no longer rest your cursor safely. It also changes the hierarchy of the output in a way that’s confusing – and it even animates the text wrapping in a distracting way. Then, if you press Esc instinctively to get rid of whatever happens, the window closes altogether.
It’s a “delightful,” luscious transition that is completely out of place. I think this is how many people misunderstand craft – that it’s only about “high polish” without any thought underneath. Here, the effort was spent on executing something that couldn’t be saved this way and needed a more serious rethink. It seems like its creators forgot who’s using the app and for what, and embarked on accidental UI calming.
There are other challenges along the same lines, both downgrades from version 3:
when the app analyzes the differences, I can no longer press the Sync button and walk away
even when the button becomes active, I can no longer press Enter to activate it – I have to use the mouse
In version 3, I could invoke Sync, immediately press Enter, and get on my merry way, with syncing continuing in the background. It was exactly what I wanted. Version 4 slows me down by requiring me to pay constant attention to the interface: it matters where I rest my mouse, it matters when I click the button, it matters what input device I use to commit.
It’s okay to think of friction and sometimes transitions are indeed very helpful for UI calming to avoid drastic movements or accidental activations. But here, this isn’t great at all; the creators of Forklift promised me faster syncing and achieved the opposite.
I have been enthralled with this tiny feature in Google Sheets called “Show edit history,” which premiered in 2019:
Mind you, it’s not unconditional love. The execution feels a bit clunky, showing the edit values in a pop-up rather than in situ, with formatting that feels too heavy, and an awkward “No more edit history” state rather than just disabling the button.
But! Just its very presence here is delightful. Version history is often this huge, comprehensive, perhaps disorienting mode you enter that by design deals with the entire file. It always feels like a longer trip:
But edit history reimagines the feature from the perspective of the cell. You can just peek inside, quickly and effortlessly. Right click menu, a few arrows, I learned what I needed, and I barely even moved my hand. It’s a perfect example of the rule “to make something feel faster, make it smaller.” It’s like picking your newspaper at your doorstep in your pajamas rather than having to dress up to go to the newspaper store.
(…he said, dating himself and perhaps also thinking of The Sopranos for some reason.)
This kind of reimagining of something that already exists (see: undo send in Gmail) can be really hard, and I don’t even imagine Google Sheets was the first with this idea – but for me seeing this remix was eye-opening, and it inspires me to this day.
One of the ways I like to do development is to build something, click around a ton, make tweaks, click around more, more tweaks, more clicks, etc., until I finally consider it done.
The clicking around a ton is the important part. If it’s a page transition, that means going back and forth a ton. Click, back button. Click, right-click context menu, “Back”. Click, in-app navigation to go back (if there is one). Click, keyboard shortcut to go back. Over and over and over. You get the idea.
It’s kind of a QA tactic in a sense, just click around and try to break stuff. But I like to think of it as being more akin to woodworking. You have a plank of wood and you run it through the belt sander to get all the big, coarse stuff smoothed down. Then you pull out the hand sander, sand a spot, run your hand over it, feel for splinters, sand it some more, over and over until you’re satisfied with the result.
This is a clever metaphor and I wish I thought of this before. What follows is a specific story of finding a few dead pixels in between related interface elements, which is an absolutely perfect example of something with non-linear frustration: It might not register at all on the first try, but it will bother you 1,000-fold on the 20th go.
I was just on Internet Archive earlier today, uploading some documents I scanned this weekend. Their UI is… how would I put this… let’s just say Internet Archive makes Teams feel like Linear. (I love Internet Archive and their work and mission, but let’s be honest here.)
Yet, I found something marvelous. Whoever put the upload form UI together knew there will be people like me who’ll be filling out 20 of these forms one right after another. So they made sure every pixel in their form is clickable to edit the nearest field. And I mean, every pixel.
Whoever you are, you have my nod of recognition. In at least this one respect, it’s clear someone spent a lot of time with the sander.
This is of course competence porn, made even better by the dry Polish lektor-like delivery. But it’s also a puzzle. I watched this so many times. There are so many great UI lessons in here:
You can absolutely put graphics inside a textbox
Sparklines rule
Slider is still the best UI element in history
Previews don’t have to feel like training wheels
Synchronizing sounds to visuals is so powerful (see: turn signals on a car dashboard)
I found myself thinking about how you’d design something that feels real-time, but also needs to be resilient against typos, and has a distinct “commit” moment (which is what I think those yellow flashes are); some of the best moments in the video are the quick fixes that aren’t narrated.
Ultimately, this also shows how powerful and underrated plain text can be as interface. It’s a bit like designing straight in CSS, operating at the weird intersection of motor memory, creativity, and abstraction. (Is there a CSS editor that feels more like this?)
On top of all of this, the act of building the track this way is also how the finished track would sound like. Amazing stuff.
Remember all these jokes that went like this?
[God looking at a pug dog for the first time] What the hell did you humans do with my bad ass wolf I gave you?
Imagine sitting the creators of the typewriter in front of YouTube and having them watch this video.
Let’s say you are in Reeder (an RSS reader for iOS), looking at the list of posts, and already from the title you know you don’t care, and you want to mark it as read.
You can tap to see it and then swipe back the moment it shows. This is the slow path.
There is a faster path. Reeder enables you to slide right or left on the item. You get nice haptic feedback, and many apps support this kind of an interaction.
But there is an even faster path.
You can tap to see it and immediately swipe back. Your thumb is already there on the left anyway, and the distance is a lot shorter now.
Like every advanced gesture this takes a bit of practice, but I noticed I started doing it instinctively, without even thinking.
This happening required two small design details: The original slide transition to be interruptible at any moment, and the app to support swatting/draging the incoming item away even if my finger was nowhere near it. Both are clever, and both feel very welcome, because they enabled this emerging (to me) behaviour that made going through the list snappy without me even realizing.
This might be a good modus operandi: Think of the slow interaction. Think of its fast version. Then, think some more.
Nicely done, Reeder team. (Or, if this is a default iOS behaviour, nicely done, Apple!)
A 16-minute video from Ahoy from last year about Chris Sawyer, creator of Transport Tycoon and Rollercoaster Tycoon games from the late 1990s.
The video focuses more on the economics of the industry and some technical details, but what’s interesting to me was how tight those two games felt in terms of UI. They have a shared custom GUI, they are assembly-coded, and they felt perhaps like the last instance of a graphical user interface where it felt there was nothing standing between you and the pixels.
I know those are games and not productivity apps, but they can be inspiring for those, too. You can download OpenTTD, which is a modern recreation of Transport Tycoon Deluxe that doesn’t require emulation, and it still captures the snappy and tight feeling very well.
I’m thinking about it in particular because the web took a lot of that away. The web loves latency and loose interactions and reflow and temporary fonts and CSS leaks and text sticking out of the box and many other papercuts. It’s nice to be reminded of the world where things were closer to the metal, and how that felt as a user.
One of my favourite recently-noticed little patterns is this one thoughtful accelerant in iOS Photos.
If you want to add a photo to an album, you normally have to choose from a list of albums:
However, once you do that one time, a new menu option appears. It’s effectively “Add again quickly to the album you just chose” (Fiałka is the name of my cat):
That skips the album selection altogether. It’s always only just one album you used more recently, so it’s relatively simple… but so helpful. You often, after all, want to add more stuff to the same album, and it saves you choosing the same album over and over again.
This is great because it flattens the option space to zero options, which mirrors how we all think when we’re focused. It’s tunnel vision exactly when you want it.
I have always been a fan of both “repeat”-type actions and smart “recent”s, and consider them a truly underappreciated secret weapon. Those little savings really add up over time – in saved time, in less tedium, and in avoided mistakes. (Imagine not only having to choose the same album for 30th time in a row, but also… making a mistake doing that and tapping on a wrong one! Then the frustration very quickly compounds, as you have to recover from something that felt completely avoidable.)
I always respect designers of interfaces that invest in functions like these. There is also an anti-corollary to this, which is: if there’s only one option, consider not even asking. Slack seems to excel (derogatory) here:
The second one is somewhat defensible since it’s a settings dialog you enter at your own will, although the active “Re-generate answer” when I haven’t done anything (and nothing can be done) feels overbuilt.
But the first of these always appears on a way to other settings (like adding emoji), and it’s even worse than the Remember me? examples because it repeatedly stops you for absolutely no reason at all.
One of the frustrating patterns for me is a dialog box that doesn’t offer “skip it next time” option, or even just defaults to remembering.
My go-to examples? Apple’s Remote Desktop which always throws this thing up on connection:
And this in Photoshop upon saving a PNG file, which has been there forever:
I never change these options. These are flow-killers; trees have grown to maturity as I have spent collective hours in those dialogs over the years/decades, even though they serve no purpose for me.
(The worst part might be if you forget this dialog waits, and move on to do other things, and the operation you thought was completed never actually finishes.)
When I first learned about this book from Jacob Geller’s video just months ago, I thought this was another example in the vein of The Power Broker – a perfectly Marcin-coded book that somehow escaped me knowing about it for decades.
“Pilgrim” is from 1983, and is a story of a pianist discovering the classic videogame Breakout, and trying to perfect his own gameplay.
I love so many stories of videogame mastery, because at times they feel the closest we got to Doug Engelbart’s dream of incredibly effective machine operation somewhere deep below the threshold of consciousness: You and the computer becoming one, eyes and fingers forming feedback loops so perfect they cease to be noticeable.
Here I am alone in a pitch-black hotel room, a middle-aged man with some time to kill, getting ready to check out some jazz clubs in Greenwich Village, in possession of an early cretinous offering from a gold rush grab bag of tuby thingies coming our way from hundreds of decision-making puzzle peddlers throughout the new electric “entertainment” industry. And now instead of playing the game it‘s packaged up to be, I‘ve gotten into more or less occupying myself by outlining invisible triangles across the screen of a TV doodling machine. What am I doing?
Unfortunately, as you can maybe already sense, the book is an overwritten, ponderous, and pretentious mess. “Beach reading, it ain’t,” quipped a Kill Screen reviewer in 2013. But there are some interesting parts in it.
Before, the piano was the quintessential human instrument. Of all things exterior to the body, in its every detail it most enables our digital capacities to sequence delicate actions. Pushing the hand to its anatomical limit, it forces the development of strength and independence of movement for fourth and fifth fingers, for no other tool or task so deeply needed. This piano invites hands to fully live up to the huge amount of brain matter with which they participate, more there for them than any other body part. At this gnetically predestined instrument we thoroughly encircle ourselves within the finest capabilities of the organ.
Then a typewriter, speeding the process whereby speech becomes visible, the extraordinary keyboard for sequencing and articulating perhaps awaiting a still truer sounding board, strings, and tuning, a still more suited canvas for thought.
Then TV.
This arrives at page 26. Alas, it’s kind of downhill from here.
The author visits Atari (imagine that!) to learn that the programmer of Breakout doesn’t really understand what makes Breakout so alluring. The game perhaps lucked in to being so imminently playable, and then replayable.
I’m interested in designing for mastery. We should not rely on luck that separated a classic like Breakoutfrom a hundred other games from that era that felt awful to play and were immediately forgotten.
Sure, Sudnow definitely takes Breakout way too seriously:
Maybe I can remember the five shots by putting pieces of tape on the TV cabinet to mark each paddle destination, I say to myself, even though it seems that would undercut true learning. It’s bad practice to learn the piano by writing the names of the notes on the keys, much better not to use a code, to grasp the layout of things by their own looks and feel. And I can’t carry Scotch tape to a Breakout tournament.
But in a way: why wouldn’t you?
In fact it’s already happening. I’ve found myself playing with the cursor on my word processor just for the hell of it, seeing if I could track it across screen and get it to stop at every comma in the text.
The word processor (or any other app you use often) operating at the speed of fingers unlocks superpowers, and then some.
There’s one experience in particular at the word processor that gets me downright angry at times. There’s no more of that room for finger breathing while you awaited a carriage’s return. You reach the end of a processed line of text and if your word becomes too long for the margin while there’s still alloted space to get it underway, it splits in the midst of your articulation and your voice instantaneously reappears six inches to the left, a quarter of an inch lower. The computer can’t know what you’re about to write, not yet, not a word or even a letter in advance, has to wait and merely calculate how things are going in order to then “decide” where to put the sound. ¶ Before, you felt a big word welling up, hit the carriage return, lifted off from the keyboard just a bit, reorganized your grasp, and dug back into the improvisation with a renewed rhythmic mobilization to continue. And some of the things you found to say, you found because you said them that way.
This was a fascinating tidbit, this reflection on how small interactions can change the nature of creative process.
If this book was cut to 20% of its size, those fascinating tidbits would stand out more, and the book would still be of value today.
But despite this complaint, I miss people writing about using computers this way. Such a big chunk of my struggle with computers today is fighting with it because I expect a better connection between my fingers and what’s happening onscreen.
I wish more designers understood how important that is.
Google Maps is dying a tragic, public death by a thousand cuts of slowness. Google has added animations all over Google Maps. They are nice individually, but in aggregate they are very slow. Google Maps used to be a fast, focused tool. It’s now quite bovine. If you push the wrong button, it moos. Clunky, you could say. Overly complex. Unnecessarily layered. Perhaps it’s trying to do too much? To back out of certain modes — directions, for example — a user may have to tap four or five different areas and endure as many slow animations.
Funnily enough, I feel that way about Apple Maps. I abandoned it since small things felt heavy, mired in superfluous swipey animations that felt like driving a 1960s car. Luckily, this was at the time Google Maps redesign its tiles to match Apple’s, so I got what I wanted to begin with, although in a slightly shady way.
I miss Sublime Text and might take it again for a spin (VS Code and Atom felt slow, Nova is delightful but also struggles in performance, even on simple things).
