Ivory is a Mastodon client, and their account switcher has a few interesting mechanics.
The standard one is that you can tap on your avatar, and get a menu in response:
But you can also drag down on the avatar, and get a different reaction:
This, I believe, is meant to be a slightly faster way. The settings option is gone to simplify, and the whole thing looks and feels more… gestural, in lack of a better word.
But I think it also serves one more purpose. The moment I saw this, I thought to myself “I wonder if I could just swipe on the icon itself?” and, lo and behold, this is actually possible:
Why does it matter?
I think for some power users of social media – perhaps people doing it professionally – you switch accounts all the time, and investing in this interaction being fast and smooth is important.
This whole small interaction system feels similar to switching apps on a Mac. You can choose an app in your dock with a mouse (the slow, but well-lit way). You can then learn to use ⌘⇥ and hold ⌘ to get to it quicker from a temporary menu. Eventually, you will also start tapping ⌘⇥ quickly, skipping any visible UI surface altogether.
There is also something great in seeing an interface that grows with you, or one where you can say “I wonder if…” based on your prior interactions and expectations, and the interface actually rewarding you for that thought.
Phones grow big and their top edges inch closer and closer toward the horizon. Over time, iOS and apps moved some of the important surfaces to the bottom (for better or worse – I still struggle with seeing results and completions appearing above inputs), and the well-designed Reachability gesture helps, too.
Still, the iOS web browser called Quiche Browser chose to tackle the problem, not the symptoms. It offers “Comfort Mode,” where you can ask it to move down the top edge of a bunch of surfaces closer to your fingers:
On top of that, true to the spirit of the app which revels in power-user customization, Quiche Browser allows you to decide precisely where the top should go in order to accommodate different people’s hands, and it even offers to do so per surface:
These are the affected surfaces with the option off and on:
The author, Greg de J., expanded on that on Threads:
While designing Comfort Mode in Quiche Browser, a tricky problem I had to be thoughtful about:
When you hold your phone in your right hand, favorite icons in the top left are harder to reach than ones on the right.
Search suggestions don’t have this problem, since they span the width of the screen.
That’s why favorites need to sit slightly lower than search suggestions, and why Comfort Mode lets you position both independently, so they all stay easy to reach one-handed.
It’s an interesting idea and I wonder if it’s seeing a lot of use.
The only design thought I had was: could the top space be filled or stylized so that this looks more intentional, rather than a potential rendering bug? Reachability does a good job of making it feel physical and adding a little arrow:
Then again, given my job, my brain might be perfectly primed to see rendering errors everywhere.
Safari broke tap to top for tabs (say it three times fast), and Bear added two-fingers gestures. Ivory – a Mastodon client for iOS – tries a different approach in a slightly different setting.
The normal tap to top gesture works as expected, but tapping the top again returns you back where you were before:
I believe this is meant to be a small gesture of help if you tap to top accidentally, yet I am not entirely sure it’s effective. Would you, in a moment of panic, decide to do the same thing again, after years where every other gesture like this in the entire system taught you those taps are idempotent?
It gets a little bit worse, too. There is another established standard of going to the top – tap the selected tab again. This works across the entire operating system, too. But Ivory changes it, requiring you to tap twice, not once:
I don’t have access to the combined feedback of Ivory’s users, but I am much less of a fan of this than of Bear’s approach, as it doesn’t feel like it comes together as a system.
At the bottom of the screen, the interface teaches you that you have to tap one more time than usual, likely putting in your fingers the idea that you just have to tap many times, especially if you never figure out it’s a double tap and not two taps that trigger the interaction.
But then, at the top, this is how the interface reacts like this when you do exactly the same thing:
It feels like a system that’s well-intentioned, but inconsistent not just with the rest of iOS, but also with itself.
I praised the note-taking app Bear before for its memory; the app would always remember your last-visited note and the precise place within it, even if it had every right to forget it.
But there is a general problem here: memory that kicks in when not expected can be frustrating, as you have to undo its results and “reset to normal.” For Bear that’s not a problem, though, right? The whole iOS has a nice “tap near the top to scroll to the top” gesture that would work here as well, making it easy to recover if you return to the note where you last happened to type.
Except, with any writing app, the very bottom is as valid of a destination as the very top.
Bear designers understood it and tried to solve it in a new way, by adding two gestures: a two-finger swipe up takes you to the very top, and a two-finger swipe down to the very bottom:
It doesn’t quite work as well as I hoped – for some reason, it scrolls way too far down, and does feel a bit sticky mechanically.
It’s also, like any complex gesture, not very discoverable. But here’s where Bear tries to help, by… adding even more gestures atop these two. There is a two-finger swipe left or right for jumping back and forward in history…
…and even a two-finger tap to reveal a navigation menu.
That last one feels like overkill to me, but there is something interesting about the app building an entire little universe of compatible gestures – “Come here for all your navigation needs!” – knowing that it increases the chances users will develop a habit of learning and using them. (The gestures also work whether you’re in view or edit mode.)
I am curious, though: Would allowing to tap somewhere near the bottom edge not work as the “obvious” solution to get all the way down?
From Marton Barcza at TechAltar, a good 12-minute video analyzing what went wrong with the famed Live Tiles that Microsoft was pushing throughout most of the 2010s:
Now, among Windows Phone fans the pervasive opinion is that Live Tiles have failed because Microsoft did a poor job with them, which I think is at least partially true – after all, even many key Microsoft apps like Skype had broken Live Tiles half the time, the Windows 10 start menu was filled by Microsoft with Live Tiles that were clearly just animated ads rather than showing you something actually useful, and the company of course never built out any of their advanced interactive concepts either.
But while all of that might be true, the fact that every major company has walked away from this idea and nobody else has picked it up since, means that there probably are more fundamental problems with this idea. And I can think of three distinct ones:
user experience,
form factors,
and horizontal integration.
Barcza goes on to talk about some specific interactions and problems, and arrives at the conclusion that Live Tiles ended up at this unpleasant intersection where they’re tried to be icons, widgets, and notifications all at once, not doing a particularly great job at either task. That, and there were also challenges with the design primarily being mobile-first, and struggling surviving a jump to a large screen. (Live Tiles were abandoned in 2017, at which point desktop Windows reverted back to what it was before, and the mobile/tablet lines were altogether disbanded.)
What I found interesting in watching this today is that it feels Apple has made some similar mistakes in their Liquid Glass approach and wider platform unification desires (see: macOS Settings). Both these and Live Tiles attempted to create A System Of Systems, and both ended up occasionally feeling like they awkwardly crowbarred some wider concepts into places where they didn’t truly belong.
If it helps with your further research, I understand Live Tiles were part of a bigger UI effort called Metro and started in earnest with Windows Phone.
A typical use of Safari means two groups of sites: a regular set on the right, and “private” pages on the left (this is what Chrome calls “incognito mode”):
As expected, you can tap on either label, and switch to the relevant group with ease:
It also feels like you could slide it – and you can, except…
…you immediately encounter a Scroll Lock problem. You are not dragging the pill – you are dragging what’s underneath the pill. To switch, you have to go the other way:
You can immediately intuit some inherent unpleasant complexity of the whole system – not just in it “going the wrong way,” but also in how it creates room and then contracts it, in two separate steps, after you’re done.
The reason is that you can actually have more site groups than just the initial two. You can even drag to where the new site group would be, and create it this way:
I normally welcome these kinds of accelerators. But here, this feels overdesigned and confusing, as if someone drugged the tab instead of dragging it. The very same natural gesture – a left swipe – that should feel safe and send you to Private, will now put you in a scary new full-screen/keyboard-out flow you almost never need.
Why this relates to system design is that on/off toggles in iOS were recently redesigned to resemble oblong pills:
Those do respond to dragging as you’d expect:
Along the same lines, on the springboard pagination pill, dragging to the right means the next page:
And so now the system is schizophrenic and identical-looking design primitives mean the opposite things. It’s as if the computer itself kept randomly pressing Scroll Lock for you, preventing you from developing a solid understanding of the system first, and motor memory second.
I think the mistakes made here were twofold. First, the design overoptimized for two unnecessary things: people actually using site groups (not common), and ease of use in creating site groups (not important). My slightly cynical hypothesis is that this design presented really well in demos, which sometimes can derail a project. A more cynical theory is that this led to “accidental discoverability” that made the site group metrics look better.
Second, and more important part: This particular design received an exception that it didn’t deserve. No one noticed the systemic challenge of similar UI elements doing opposite things, or people who did were not effective in pushing back. The metrics for new feature discovery are easy; the metrics for user confusion or frustration do not usually exist.
This is how interaction systems slowly fall apart. As I mentioned in the first part, it is likely that Safari’s exception will now be treated as “blessed,” and start spreading further. Given enough time, more and more pills will go in whatever direction they want when dragged – and people will learn not to trust any of them.
I know the feature is actually called “tab groups” but I called it “site groups” intentionally, because otherwise it’s a tabbed control controlling tab groups, and things get confusing really quickly. Also, thank you to Martin Hoffman for initiating this post.
The calculator app has been preinstalled on iPhones ever since their debut in 2007. For the longest time it hasn’t been anything more than a standard four-function calculator with a decades-old feature set. If you’re not careful, however, you can mess up even that.
Ten years into iPhone’s history, iOS 11 introduced a problem just like the Nothing Phone rotation – quickly tapping on keys would show them as responding, but the actual action wouldn’t be registered. Michael Tsai’s aggregator’s first entry has a video from Stephen Heaps:
It shows typing 1+2+3+4 where iOS forgets one press of +, resulting in 1+23+4 = 28. Many more people posted about it afterwards, and showed various other examples.
It is oddly enthralling to see a computer fail at basic math. But what’s particularly historically interesting and perhaps even more embarrassing for Apple is the absolutely rich history of solving this kind of a problem.
Calculators evolved alongside typewriters as the earliest devices with button-like (as opposed to piano-like) keyboards. But the stakes were different.
Imagine a badly constructed typewriter and all the ways it can disappoint you: the letter might be faint if you press the key lightly or puncture the paper if you press it too hard, the output might be misaligned, or the typebars will jam in some way, forcing you to go again.
A typewriter has to work hard to divvy up a blank, analog piece of paper into a reliable, pleasant-looking grid via escapements, ratchets, and so on. But a calculator’s work to convince the analog world to be digital was much more important. After all, it’s not likely that the typewriter key you pressed will output the wrong letter – but on a badly constructed calculator, a light press of 5 could absolutely output 4, or 6, or 4.5.
And, while the typewriters only take your words verbatim, the calculator’s job is precisely to create new numbers out of the numbers you type. An imprecise mechanism can mess up that math. A jam could perform a partial or nondeterministic calculation. Adding 1 to 999,999 and the force necessary for the resulting cascading carry could break a device in the middle of work.
On top of all that, languages have a built-in redundancy. Evn if yuo mak many typoes, th sentece can stil be understod. But all numbers basically look alike. A calculator could make a mistake when it comes to a number that is absolutely vital for your payroll, for engineering, or for navigation – and you would never spot it.
Understanding all this, many calculator makers even already in the 19th century spent a wild amount of effort convincing people not just that their devices were helpful, and fast, and easy to use, but also that they could be trusted. Buttons were carefully weighted. Comptometers came with a locking mechanism. If a machine felt something didn’t go right, it would stop working and require a hard reset. The message was: “You can trust me, because I won’t ever show you bad math, and I’ll stop myself before I will ever lie to you.” Charles Babbage was so confident in his Difference Engine that he welcomed people to try to mess with its mechanical wheels in the middle of the calculation, convinced that even a sabotaged machine won’t ever make a mistake.
Just like with the Selectric decades later, those things were solved by people who cared, in the much harsher mechanical conditions.
Of course, I don’t expect everybody at Apple core iOS team to be a calculator UI historian (although it would be nice for at least one person on the team to be one!). It is embarrassing that no one on the team had enough imagination to realize that making a button respond to a quick press during animation, but not register it would cause all sorts of serious trouble. (The bug was fixed in iOS 11.2 by removing the animations, and subsequently the animations were brought back without the original problem in iOS 11.3.)
But maybe the bigger embarrassment is that Apple didn’t have a battery of tests to run on top of the UI at various speeds, mimicking fingers of what must be millions of people using the calculator app. That, too, has been a standard procedure for decades.
Those tests seemed missing in 2017. I hope 2+3+4 years later that’s no longer the case.
I have never been particularly fond of “shake to undo” on the iPhone. It’s not a pleasant gesture to perform, I feel like typically I don’t have strong enough of a grip on my iPhone to invoke it without fear, and the gesture often undertriggers, requiring an even harder and more cumbersome shake, etc. etc. (One thing I never want to undo is my screen’s pristine surface by having it meet the sidewalk.)
I am aware that many years ago, iOS introduced an alternative: a three-finger swipe. But I feel like Apple flubbed that, also – three fingers are hard to plop onto a small screen, and while regular going back navigation means swiping from left to right, undo is inexplicably a three-finger right-to-left swipe. I mean, okay, it’s explicable – it’s the movement of the cursor before and after the typing is undone. But to my brain that feels less strong than the other association, and undo is not always about typing.
I also see many people not knowing about this alternative and I must not be the only person struggling, since I see more and more apps throw in the towel and put undo and redo as on-screen actions:
Curiously, I even spotted Gmail on desktop doing that recently:
It’s all a welcome improvement under the circumstances, but those are literally all over the place – imagine if on a laptop, each app had a different key shortcut for undo. (We’ve had that, in the 1980s. The 1980s Nostalgia Industrial Complex doesn’t want you to know about stuff like that.)
Anyway, some time ago I promised more onboarding content, and here’s a little thing that happened to me recently. The inciting incident is that I accidentally shook my iPad, and then I saw this:
Wait, does it mean there is yet another, third undo shortcut?
I swiped through the carousel to see these:
None of these feel particularly pleasant to use – although they are nicer on the iPad than on the iPhone – but I started playing with them, and I discovered a fourth entry point. Just a single three-finger tap shows a new-to-me onscreen editing menu, sort of the equivalent of the Edit menu on the desktop:
This works on the iPhone and the iPad, and since then that’s the one thing I did remember and I find using. So, to summarize:
shake to undo – unpleasant
double tap with three fingers to undo – unpleasant
a three-finger swipe to undo – unpleasant, confusing direction
single tap with three fingers to show a menu, then tap to undo – less unpleasant, but stuck with me
Yeah, even this still doesn’t feel great. But it’s there in a (no pun intended) pinch.
So, is this a success story for onboarding? I think not quite. It all started with an accidental iPad shake, after all, and the gesture I ended up using I also discovered accidentally. But to be fair, I also did learn something, and I think there are some bones of the right solution in here somewhere. Onboarding and in-product education generally feel so bad that even this rickety encounter can be counted as a small victory.
One thing I was (and still am) worried about when it comes to my recent big interactive essay is that by showing all these classic desktop examples, the whole thing might appear old-fashioned, relevant only to a bygone era.
Yet, the challenges it shows are universal. Here’s something I just spotted. This is how you rotate an image on an iPhone and on a Nothing Phone:
It’s a pretty standard control – tap once to rotate counterclockwise, tap a second time to do it again, etc. – with a helpful transition of the photo’s orientation so that you don’t lose yours.
Now, I’m going to exaggerate the problem a bit and tap 90-degree rotation quickly eight times. Eight times should result in what engineers call a “no op” – the image rotating twice in full, and ending up where it started. That indeed happens on the iPhone:
But it’s a different story on the Nothing Phone/Android:
iPhone will remember and buffer the taps, so that the second, pending rotation will happen as soon as the first is done. The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating.
Why does it matter?
I often keep thinking about the framework of situational disability, stating that disability is not just something that happens to a few people and no one else. No, pretty much everyone will occasionally encounter a situation that will make them effectively disabled, and this is why accessibility matters much more than many of us assume:
I think similarly about casual and non-casual use. Photo-taking on phones is typically casual. Phone cameras are typically very good at detecting the photo orientation – but get confused when you’re pointing down. Now, as an example, if you had to take photos of a bunch of landscape documents, you might end up having to rotate dozens of photos, one by one. And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you.
This is, I suppose, “situational power user-ness.” Given a long enough timeframe – or, in this case, a large enough population – even a casual interface like phone photo editing (or, GarageBand) will meet someone who will have no choice but to treat it more seriously and expect more from it.
By the way, buffering the taps is not the only answer. You can also stop/accelerate the animation after an interrupting tap, and it seems the iPhone does that as well. But the rule is: never force the user to wait for the animation to finish.
A nice moment in the iOS emoji keyboard – after selecting an emoji from the grid, its name shows up for a second:
I have small reservations here, as reusing a placeholder like this trips up my “this is cheap” alarm. But otherwise I like that this – just like keyboard shortcuts in menus or tooltips – ambiently teaches you the alternative representation of the emoji that you can use later to get to it faster.
(Another way of looking at it: This is a tooltip in a place where tooltips cannot exist.)
I recently stumbled upon this 20-minute YouTube video by iSongs of someone recreating Eminem’s “Lose Yourself” in GarageBand on their iPhone:
Like the previous video, I believe this is so tight as it was previously rehearsed/prepared, which makes for an interesting watch if you even just check out a fragment of the video.
I can’t speak for the verisimilitude/quality of the composition, but it was fascinating to witness because The. UI. Just. Kept. Coming. I had no idea Garage Band is so fully-featured on the iPhone, and that there is so much going on!
Maybe my fascination is this: it’s amazing that “power users” come in various shapes and forms. Would I recommend using the iPhone to do this? Not really. Is it cool that this is possible, for people who might not have access to other platforms? Yeah.
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.
I have a confession to make. I prefer Apple TV’s 2015 remote:
The remote was universally ridiculed for its “which way is up?” problem – too much vertical symmetry which didn’t give your hand enough cues to know whether you’re picking it up the right way or the wrong way.
Apple tried a half-measure first; in 2017 they broke the symmetry by making the MENU button slightly distinct in visual and tactile ways. Hindsight is 4K, but I don’t think it had a chance of working – the tactile cues were too subtle, and the visual ones do not matter when you’re not looking:
So Apple overshot – the subsequent 2021 edition was a full-measure-and-then-a-half:
The remote shrank the touch surface but otherwise drastically increased the volume, and added four arrows, two new buttons, and a strange iPod-inspired clock wheel interaction on top. And to me it started feeling a bit complicated, inching toward the very TV remotes that earlier designs ridiculed. (It also wasn’t as pleasant to touch, as the buttons feel a bit rougher.)
But the reason I like the 2015 remote is primarily because it introduced one of my favourite gestures in recent history: tap to see progress.
It’s hard to describe how wonderfully light this interaction feels every time I use it. You just tap anywhere on the remote’s top half, you see where you are in the video via a subtle UI, and then wait a few second for it to disappear. After this, doing the same in every other player – YouTube, Netflix, HBO Max, anything on a Mac or even the iPhone – feels clunky and heavy. In many of them, you can’t even see were you are without stopping the video!
It gets better. Tap for the second time, and the elapsed time gets replaced by current time, and the remaining time by what the clock will say whenever you’re done watching. I thought this is delightful and clever, sneaking in clock functionality without showing it all the time.
There is also this really nice gestural separation. When you watch the video, taps and swipes are safe. Anything that is “destructive” – that is, causes the video to stop, or rewind, or fast forward, is on the “click” layer: press stronger on the center to pause, or on either side to move forward or back.
What I’m describing feels mechanically similar to other input devices, but the devil is in the details. On smartphones, everything is a tap, so you don’t really get anything lighter. On a Mac, tap as a gesture could only be available for people who opt in to press to click on their trackpad (like I do) – but the fact that tap is the default for clicking, means that can never realistically happen.
The Apple TV tap feels conceptually like Mac’s hover instead, but so much more pleasant and elegant and simple. (I want to prototype tap on a Mac as a lightweight “explainer,” showing tooltips there instead of on hover.)
To be fair, the tap gesture still exists in the still-current 2021 Apple TV remote, too – but the tap area is much smaller.
And just in case you were curious, these are the first two editions: the 2005 remote – shipped with the iMac, predating Apple TV – and the 2010 remote. (I’m referring to model years, because Apple’s own names are so confusing.)
I don’t have access to Apple’s user feedback, but I guess that Apple’s 2021 design was likely the very right thing to do. But looking at four-and-a-half of these models side by side, I am still in the 2015’s minimalistic, unusual, innovative corner.
Two great posts about interaction latency on the hardware and software side. First is from Ink & Switch:
There is a deep stack of technology that makes a modern computer interface respond to a user’s requests. Even something as simple as pressing a key on a keyboard and having the corresponding character appear in a text input box traverses a lengthy, complex gauntlet of steps, from the scan rate of the keyboard, through the OS and framework processing layers, through the graphics card rendering and display refresh rate.
There is reason for this complexity, and yet we feel sad that computer users trying to be productive with these devices are so often left waiting, watching spinners, or even just with the slight but still perceptible sense that their devices simply can’t keep up with them.
We believe fast software empowers users and makes them more productive. We know today’s software often lets users down by being slow, and we want to do better. We hope this material is helpful for you as you work on your own software.
I loved the slow-motion videos comparing what is normally impossible to notice:
I’ve had this nagging feeling that the computers I use today feel slower than the computers I used as a kid. As a rule, I don’t trust this kind of feeling because human perception has been shown to be unreliable in empirical studies, so I carried around a high-speed camera and measured the response latency of devices I’ve run into in the past few months.
I feel both of these essays are fantastic, and important to develop some sense of what are specific numeric thresholds separating fast and slow, also in the context of being able to have an informed conversation with a front-end engineer. (Luu subsequently links to even more articles in the “Other posts on latency measurement” section, if you are curious.)
Otherwise, from my observation, the two most quoted laws of user-facing latency are still Jakob Nielsen’s response time limits, and the Doherty Threshold. But the Jakob Nielsen 100/1000/10000ms rule is from 1993 and as far as I understand is concerned primarily with UX flows: reactions to clicking a button, responses to typing a command, and so on. And the Doherty Threshold is even older. Both are simply not enough, especially not for things related to typing, multitouch, or mousing, where for a great experience you have to go way below 100ms, occasionally even down to single-digit milliseconds.
(My internal yardstick is “10 for touch, 30 for mousing, 50 for typing.” Milliseconds, of course.)
At the end of his essay, Luu writes:
It’s not clear what force could cause a significant improvement in the default experience most users see.
Perhaps one challenge is that these posts are dense and informative, but only appeal to people who care? Maybe latency eradication needs a PR strategy, with a few memorable rules and – perhaps arbitrary, but well-informed – numbers that come with some great names attached? I know in the context of web loading some of the metric names like FCP (First Contentful Paint) broke through at least to some extent, but those still feel more on the nerdy side. Even Nielsen’s otherwise fun 2019 video about response time limits didn’t stick the landing – why focus on slowing down an arbitrary label appearing above the glass when the ping sound was right there for the taking?!
I can’t help but dream of interaction speed’s “enshittification” moment.
This 25-minute segment on MKBHD’s Waveform podcast (video or audio, segment starts at 40:21) is from November 2024, and is a nice counterpart to the post about favourite well-made apps and sites.
The original theme is “what is an app that you use all the time, and like to use, but is actually a bad app?” but it quickly moves to a more general conversation about good and bad mobile apps.
It’s always interesting to me to see what themes emerge and what other people think is important. Here’s the list where I linked to relevant apps as long as I could find them:
Bad apps:
Google Messages – dinged for unreliable spam and lack of organization/filtering
Notion (on mobile) – hard to orient yourself and some direct manipulation is wonky
many smart home accessory apps – bad and redundant with Google Home, but have to keep for emergencies
Netgear Orbi (network router) – specific functionality and bad password recovery
Hatch (white noise machine for babies) – simple things are hard to discover
To be fair, I am traveling and haven’t looked for solid evidence or citation that this works for people, but I personally like this approach: in lieu of a separate language selector button, each option here itself is both a language selector and a commit button.
The labels themselves are not the name of the language, but a call to action; I imagine recognizing the one label that means something to you should be easy if the other nine look like gibberish.
And, a thoughtful moment by one exhibit: Not only showing you where you are in the sequence of three videos, but even within the currently-playing video.
This iPhone UI for dark/light theme is doing something clever:
Ostensibly, there are two modes here:
automatic, for when you want the theme to match the time of day
manual, for when you want to keep one of the themes forever
But check out what happens when I am in automatic mode, but toggle the theme by hand anyway:
More rigid or less thoughtful interfaces would either disable manual changes when you’re in automatic mode, or understand a manual theme switch to mean “I want to turn off automatic.”
But here, iOS is quietly putting me in a temporary hybrid mode: a manual theme override until the theme catches up with what automatic mode would do, at which point it snaps back (I’m resisting very hard calling this rubber banding) to automatic mode.
What I think is clever is that this isn’t presented as a third mode – which could be more confusing than helpful – but the design simply reuses the existing Options field to set the expectations.
One has to be careful designing in shades of gray; once you enter the space you really have to commit to it and see it through. My go-to analogy is symmetry vs. asymmetry. Symmetry in visual design is usually easier and safer. If you venture into asymmetry you have to make an effort to make it work. The highs of asymmetry will be higher than anything symmetry can provide, but getting to those highs can be arduous and sometimes might even be impossible.
I thought this particular example was really nicely done and the team found a great balance. (I think Apple’s previous shade of gray – “Disconnecting Nearby Wi-Fi Until Tomorrow” – ended up slightly less successful.)
The year is 1981. Your IBM PC is equipped with a tragic speaker that sounds awful for anything except occasional beeps. (Those beeps sound awful, too.)
You can’t afford a sound card and besides, sound cards for your PC have not been invented yet. You can’t even afford a floppy drive, so you’re one of the rare people who actually uses an audio cassette player as a storage device – a technique usually reserved for more primitive machines that have half the bits your new PC does.
But there’s a silver lining. Your cassette player has a little relay that controls its motor. You can engage and disengage the relay at will.
So, someone figured out that toggling the relay kind of sounds like a metronome. Like percussion. It’s a hack, but in the sonic landscape inhabited solely by your sorry speaker, it’s a breath of fresh air (scroll to 7:26 if you don’t land there automatically):
The year is 2026. Your computer itself is the size of an audio cassette, fits in your pocket, has better storage, graphics, sound, pretty much everything compared to a 1981 PC. It even has a special haptic motor. Except, that motor can only be controlled by native apps, and there is no official API to do it from a browser.
But there’s a silver lining. Tapping any checkbox on a site generates a haptic pulse. And that apparently works even if the checkbox is hidden and if thecomputer is doing the tapping.
I love these kinds of hacks, and I wonder what’s going to happen to this one. Will it fly under a radar, or will some websites start abusing it? If so, will Safari clamp it down, or will it actually give people a proper API for haptics?
For a few months now, when re-running search queries in Bluesky’s iOS app, I ended up occasionally arriving on the wrong search, and it happened enough that I started suspecting something’s afoot. (Ahand?)
So I opened the app on my Mac via iPhone Mirroring, and started clicking testing carefully. This is what I saw:
Turns out there was something wrong there – the touch targets are so vertically lopsided you’ll often end up tapping the item below by accident.
This is a nice way iOS Safari behaves the moment you tap one of the font size buttons – it immediately ejects all the other chrome:
After Liquid Glass specifically, we seem to be going through an interesting re-evaluation of whether “the content is the king; it should feel expansive and UI should get out of the way at all costs,” so seductive as a principle, is ultimately the right approach. Liquid Glass-sporting operating systems have so many contrast and blending and distraction issues that I wonder if they alone are radicalizing people, making them appreciate traditional rigid toolbars with solid backgrounds and fortified borders.
But here? Here letting contents shine and putting the UI atop feels like the absolutely right thing to do, since you are redesigning your reading experience.
Contrast this with Books:
It’s not even that the crossfaded transitions feel awkward. It’s mostly that the interface takes up so much room that the content preview slice becomes almost claustrophobic. And it’s even weirder when you tap the Customize button, and whatever was visible gets inexplicably replaced by a pop-up with… largely the same content anyway.
How will the entire page feel? For that you have to use your imagination – or keep tapping back and forth.
If you choose to remove the app names from the springboard, a small thing Apple could do would be to show the app name in the long-press menu here. Otherwise, I found it feels really easy to forget the name over time! (It would be a small riff on this disambiguation detail.)
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!)
The first iPhone famously introduced the soft keyboard, which could change its shape depending on the need. Sometimes it would mean becoming a keypad (for numeric entries), and sometimes something subtler, like introducing a “.com” key to the bottom row, or adding a new column of keys and making the keys a bit more narrow for a few languages that need that.
Bear (the note-taking app) does something interesting: after a button press, it replaces the onscreen QWERTY keyboard with a “funpad” or a “function keypad” (like StreamDeck or Figma Creator Micro). This achieves a similar result to a scrolling toolbar above the keyboard (see: Apple Notes), but in a different way. I haven’t seen anything like this before, and I think it’s really clever and it has worked well for me in practice.
(It also cleverly closes itself upon some actions like introducing a divider, but stays put for bolding, indentation, etc.)
