Hiding inside this page on “user-driven UI” by Brad Woods are two useful things.

The first is the concept of “zone of proximal development.” The idea, as I understand it, is that possible tasks you face span a few categories:

• stuff you already know how to do,
• stuff you can learn to do on your own,
• stuff you can learn to do with assistance (e.g. from a teacher),
• stuff you simply cannot do or imagine doing.

The space between these things is a zone. A good book or a teacher would help you navigate the zone, by giving you tasks hard enough that they will expand the zone, or even teach you how to expand it on your own – but not too hard so that you give up in failure and frustration.

Woods argues that this doesn’t just apply to traditional classroom teaching, but also software, where the role of the teacher is taken by things like:

• onboarding walkthroughs,
• progressive disclosure,
• tooltips,
• help menus.

The second thing was this quote by Anthony Hobday, who made a few appearances on this blog:

• Simple product is released
• Lots of people use it every day
• More features are added
• It’s now complicated
• But most people learned the basics when it was simple, so they don’t notice that it got complicated.

I think this is brilliant and spot on. I always knew the creators of an app would have a problem of not seeing complexity creep in, but this made me consider that the app’s early users might also be biased the same way, and not exert much pressure.

If you are familiar with an app, armed with your desire paths and motor memory, you have a lot of capacity to just ignore new menu items, new panels, and new complexity – provided it doesn’t get in your way. New AI option? Turn it off. New tab? Never click on it. New alternate way of doing things? Just continue with the old way.

But as a new user, you don’t have that history, or that experience-backed confidence that a bunch of stuff can simply be ignored as it’s not crucial to everyday operation. Add to this the industry’s perverse incentives that often present new additions as the most important ones, and it’s much harder to make a sense of it all as a newcomer. And all the while, the creators and existing users might not see the problems you do.

On his fascinating and long-running Windows dev blog The Old New Thing, Raymond Chen writes about the story of scrollbar right-click menus:

Windows 2000 added a right-click menu to the scroll bar. This menu gave you four options that matched existing mouse operations, two operations that matched existing keyboard operations, and a new operation.

The interesting new one is “Scroll Here”: You can right-click directly on the spot you want to scroll to, and then pick “Scroll Here”. This is much more convenient if you want to scroll a long distance, since you don’t have to grab the scroll bar thumb and then drag it all the way to where you want to go. You can just focus on where you want to go and not where you are coming from.

I used this context menu a lot when I needed to jump long distances. […] An even-more-hidden shortcut was added at the same time: Holding Shift while clicking on the scroll bar jumps the thumb directly to the spot where you clicked. ¶ I didn’t know about this shortcut until recently.

The menu looked like this, for what it’s worth:

(An equivalent function also exists on a Mac, except there it’s hiding under ⌥, and not ⇧.)

Chen covers a few interesting things in his post, including the challenge of new frameworks losing hard-won UI affordances of their predecessors. But what caught my attention was something else I’ve thought about occasionally: why are menus so averse to mousing shortcuts?

For example, you can imagine a browser link menu showing a few simple click gestures:

Or, this tapback details shortcut in the right click menu in Messages:

Or this for masking in Keynote when you right click an object:

You could even imagine announcing simple gestures, like ⌥+dragging to duplicate, or ⌘+dragging for a quick modeless move:

Item menus would also work, not just right click menus (and yeah, ⌥-opening is a real Finder feature!):

And you could even imagine integration with the hold-a-modifier-key interaction:

I am curious why we’ve never gone in that direction. I haven’t seen anything like this, and I can imagine some counterarguments:

• “The symbols might be confusing.” I am not sure. Here, I used a few temporary SF Symbols that have some challenges (the double click in particular feels clunky), but I could imagine a talented icon designer taking it all for a spin, and arriving at a clean and elegant visual vocabulary.
• “It’s too specific. It will only work for right click/​context menus.” Yeah, I see this challenge. The mouse gestures and shortcuts require the mouse cursor to be at a specific position – the noun to the menu item’s verb – which only context menus provide. When you look at one of the menu commands I invented – Move Icon – there is a lingering question: what would that command do if I selected it? But on the other hand, I also see this visual gestural vocabulary growing to be useful in other places: hint text, tooltips, documentation.
• “Power users don’t need onboarding.”

This last one I feel passionate about, and this is where we can go back to where we started. If Chen, having written about Windows in detail for decades, didn’t know about this keyboard shortcut, what chance do we have?

I believe onboarding should be universal and ongoing. There is always a new thing to learn somewhere regardless of one’s proficiency; you don’t ascend some sort of a Mountain Of Poweruserness, get a certificate, and proclaim your learning complete. Plus, proficiency is usually localized: no one is fully an expert in every aspect of even one app, let alone all of them. If Chen were to see something like this back in the day, it could have helped him – and I imagine others, too:

I’m curious if you have seen any app attempting anything like it. If you did, please reach out.

From its earliest days, Macs established an interesting convention – whenever you press a keyboard shortcut to an action that’s somewhere in the app menu, the matching top menu label blinks quickly.

Here, I am pressing ⌘A (Edit > Select All), followed by ⌘+ (Format > Font > Bigger), and then ⌘B (Format > Font > Bold):

I believe this is meant to help you connect those things better. While you might not need a map to an action that you already know a shortcut for, it might be helpful to tell you where to find other actions like it.

I imagine it also helps whenever you press a wrong shortcut – or the right shortcut under the wrong circumstances – and you want to deduce what happened or what was meant to happen. Knowing roughly where a command “lives” makes it easier to open the menu and look for it, even if you might still have to dig through all the submenus.

Recently, I spotted the programming editor Nova use a parallel technique. In its command palette, commands show their keyboard shortcuts, but if they’re hiding in submenus – also their menu path:

I am not sure how effective either of these techniques is, and both can feel a bit… busy. But they also appear thoughtful – we’re all spatial creatures, and I imagine helping you visualize a map of the entire system of commands can make it easier for you to feel at home.

A nice moment I spotted in Asana – you can quickly record your name pronunciation (the video below does not have sound):

As someone who has “How to pronounce my name” in the footer of his website, it’s much appreciated!

The result appears as a simple icon next to your name:

For discoverability, if you spot this speaker icon on someone else’s profile yet, it shouldn’t be that hard to connect it to the microphone on your own profile that allows you to record:

Contra the previous post, just spotted this “Same settings, new look!” callout in Firefox, on a page I have never visited before, talking about a feature I have never used:

I mentioned this once – when you get someplace new, everything is new. This redesign announcement’s conditions were engineered poorly, because they didn’t even consider people who didn’t use the feature before the redesign.

I keep thinking of the very old computers from the 1940s, 1950s, and even 1960s, where the challenge wasn’t what to do with the computer, but with keeping the computer running. There was a machine called JOHNNIAC which gained a nickname “pneumoniac” because it refused to work on a warm day. On many other computers, there was a daily ritual of finding which of the vacuum tubes blew up and had to be replaced. Some teams had a literal downtime tax; they knew and communicated in advance that 40% of the days the machine would not be up to the task, consumed by tweaks and repairs to bring it just to the state of being ready to do work.

When I look at those kinds of pop-ups and callouts, I think how we’re unwillingly recreating the very same conditions. I deeply believe people are exhausted not just by changes in software, but also constant questions, pop-ups, unnecessary notifications, “STOP 2 END,” “tell us what you think,” emails to unsubscribe from, unsubscribes that don’t work the first time, and so on.

Software should not require the user to occasionally click on buttons just to keep it running.

Perhaps ironically given the subject matter, I found this 34-minute video by Razbuten a bit intense, but I would still recommend it to people who work on onboarding, settings, etc.:

In the video, the author tries to answer the question: how to make any given game a challenge, given there is no universal standard of difficulty and every player arrives at a game not just with different skillset, but also likely different goals.

There are many techniques a game can use to adapt to the player – a simple upfront difficulty selector, complex difficulty settings, a training level, adaptive difficulty, accessibility/​assist modes – but there are no easy answers. Each method comes with pros and cons, and perhaps the very notion that a game should adapt to the user is flawed; some players might find it more rewarding to have to step up to the game instead.

In the video, Razbuten covers a lot of examples really well. I’m not going to say any of this maps 1:1 to productivity software as goals of games are very different than goals of apps… but even though I have never played any of the games mentioned, the examples made me think. After all, some of the psychology of mastery will be the same between these two realms. (I bet there were at least some of you who saw the previous post about LaTeX and thought “this looks hard and fascinating – I’m going in,” and others took a note to never approach it.)

A nice, but unpolished onboarding callout directing people towards a more useful shortcut, in Google Docs. I’m holding arrow keys without ⇧ here first, then with ⇧:

To improve it, I would add some sort of small celebratory “completed!” state, and auto-hide it afterwards; right now, it seems that it hides on a delay, likely regardless of what happens.

(Testing onboarding is hard because once it’s invoked it disappears forever. If you are worried about onboarding experiences in a place you work, please insist on easy toggles to bring it back for testing. And no, one-size-fits-all “reset onboarding” is too crude; ideally you can reset each specific one easily through a simple UI.)

Thank you to Ezra Spier for the tip.

I gasped when I first saw Lightroom do this:

I know this won’t have the same effect on you just watching. What happened was that, after I clicked on the Disable button, Lightroom moved the mouse pointer for me.

I don’t think I have ever seen anything like this, and it provoked many thoughts and emotions:

• This feels wrong. If the mouse is the extension of my fingers, and the mouse pointer the extension of the mouse, this is in effect the app grabbing my hand and moving it.
• I did not know this was even possible. I can see how moving the mouse pointer programmatically can be useful in very specific situations (like scrubbing, or accessibility), but… not like this.
• If you do something for the user, won’t that make it harder for them to remember how to do it themselves?
• I’ve seen this kind of a thing many times in my career: Someone genuinely asks “hey, if this is such a huge transgression, why wasn’t it codified somewhere in the style guide?” But to me the challenge is that it’s hard to imagine everything that needs to be preemptively captured and prohibited. I have to imagine this stuff for living, and I literally did not think anyone would just move a mouse pointer like this.

So seeing this now, yeah, I’d bundle this inside the “some interactions are 100% sacred” bucket, alongside focus never being hijacked randomly (especially in the middle of typing), avoiding scrolling anything until I specifically ask, undo and copy/​paste needing utmost protection, and a few more.

In the opposite camp, here’s a fun new project by Neal Agarwal (only worth clicking on a computer with a mouse). This is a situation where it feels perfectly fine for a cursor to be hijacked; as a matter of fact, there is something really interesting about a mouse pointer feeling less like a deity floating above it all, and more like a regular in-game actor.

This reminded me of that time, in the earlier days of Figma, when I prototyped an interaction where you could select someone else’s pointer and press Backspace to delete it:

We didn’t seriously consider it because it felt just too weird, and not that effective in solving “the other person’s cursor is distracting me” problem. But today it feels like it belongs to the same category as the two examples above.

I’ll let you decide if it’s closer to Agarwal’s delight or Lightroom’s terror.

If there was one go-to example of an impenetrable error message in the 1980s, it must have been this – popping up, for example, if your disk drive was dirty:

On some technical level, the options made sense: “Abort” would stop whatever you were doing, “Retry” would try to repeat the action, and “Ignore” would proceed as if there was no error. But in the heat of a moment, or seeing it for the first time, this was a puzzling choice to be asked to make. Not only were the words weighted improperly (the seemingly most innocuous action here, “Ignore,” was actually the only one that could do actual lasting damage), but it also wasn’t entirely clear what’s the safe thing to do to get out of the situation.

(The redesign of “Abort, Retry, Ignore” was “Abort, Retry, Fail,” and it wasn’t really a huge improvement.)

Last night, I installed Google Photos on my iPhone, and the first message that greeted me was this:

This is really a matryoshka doll of bad dialog presentation.

First: any buttons in a dialog should be labeled with enough information to keep me going. Here, both have generic labels, so now I need to pay attention.

Second: Even after reading, I have no idea what is the choice I’m making. I see the pathway marked “yes, keep it the way I had it” and, sure – this would be generally what I want from any given computer on any given Sunday. But what’s the actual alternative?

But the third, and most important one, is this: this dialog has no safe escape hatch. By now, in UX design, we established quite a few canonical escape hatches:

• a Cancel button,
• a × close box,
• a “No, thanks” link,
• a press of an Escape key.

But you can’t × this dialog out. The main button seems positive, but it also feels like I’m taking an action with consequences, and I don’t want to deal with that. There is a “No, thanks,” but it doesn’t feel like the other “No, thankses” I have seen – it’s juxtaposed with copy that makes it seem… a dangerous thing to choose.

And this last bit makes it a pretty serious design offense, because you are now messing with foundational stuff. You need to protect those escape hatches for the future; the moment you introduce hesitation into the mix and taint “No, thanks” as a concept, really bad things will start happening all across your product.

In real life, fire doors have to open outwards when pushed with body weight, aircraft stick shakers are impossible to ignore, and anti-lock braking systems do smart things even after your brain turns off its smart parts.

I know seeing a dialog like this would never happen in a moment of true panic, but sometimes I think of the user in their most absent-minded moment: trying to get their kids to hurry up for school, on hold with an annoying cable provider, with a cat looking like it’s about to jump up directly into a running toaster. A dialog on their phone pops up. If that dialog absolutely has to happen, what is the escape hatch it can offer so they can dismiss it safely if they cannot think about it at all?

This Google Photos screen needs a lot more rethinking and rewriting, but in its current incarnation, it desperately needs a clear and trustworthy escape hatch I can tap absentmindedly, just so I can get to my photos.

Did you catch one interesting bit in the last post? The undo shortcut in Paint and other apps in Windows 1.0 used to be Shift+Esc:

This reminded me that the classic Ctrl+Alt+Del shortcut was initially Ctrl+Alt+Esc. Except, people apparently invoked it a bit too often by accident, so it was split to require two hands for extra safety.

When you look at the keyboard for the original PC, it all makes sense. Esc is at the edge of the main typing block, and in line with all the modifier keys. It would make sense to build a system around this, and it’s interesting to imagine the Esc Kinematic Universe that never happened.

Don’t get me wrong: I think it’s good that it didn’t. ⌘Z or Ctrl+Z are much easier to get to than Shift+Esc, especially in concert with cut/​copy/paste next door – that system introduced by Apple Lisa and Mac teams deserves endless trophies and infinite accolades. (In case you are curious, Windows 1.0 used Delete for Cut, Insert for Paste, and… F2 for Copy.)

But it has always been peculiar to me that Esc isn’t seeing more use. I see Backspace tasked with all sorts of modifier key combinations in various apps, but Esc – equally available on the other side, and even easier to target on some keyboards – is often left alone.

Poetically, given the beginning of this story, it was Mac that grabbed ⌘⌥Esc for force quit:

There is a nice thoughtful design element in that window that’s worth calling out: the hint line the bottom.

Why, of all places, would this window go out of its way to announce its own shortcut after you already figured out how to open it? I think this might be for a similar reason airlines repeat the safety announcements before every takeoff. If your computer goes haywire, if one of your apps starts hogging resources, if the UI slows down so much any action takes forever, it might benefit you if somewhere in the back of your head exists one small bit of information: “ah yeah, I don’t know how I know this, but I think I’m supposed to press ⌘⌥Esc now.”

I was surprised at this little thing that appeared in my Chrome Canary this morning.

It is rare to see an interface clean up after itself this way. This flew by quickly and wasn’t communicated very well, but I believe this changed my new tab page from this…

…to this:

Now, I said “surprised” and not “delighted” not just because the implementation felt a bit rough. I am also suspicious of the motivations, as Google’s sister iOS app played very fast and loose with this surface, literally moving the search bar from under my thumb in order to create room for features I would never use and could never remove. I suspect this is a preparation for something else that would take the place.

But until that day comes, this was an interesting gesture, and it’s really welcome to see a new tab harking back to the simplicity of Google from days past.