These are great points. But I would debate the 100x point a little. And I think there are
some cases where ignoring fast taps is clearly preferable.
I’m specifically thinking about phone notifications that slide in from the top – ie, from an app other than the one you’re using.
So we have two options: ignore taps on these notification banners for ~200ms after the slide-down (risking a ‘failed tap’) or don’t (risking a ‘mis-tap’).
I’d argue these are in different leagues of annoyingness, at least for notification banners, so their relative frequency difference is somewhat beside the point. A ‘failed tap’ is an annoying moment of friction - you have to wait and tap it again, which is jarring. Whereas a ‘mis-tap’ can sometimes force you to drop what you were doing and switch contexts - eg because you have now cleared the notification which would have served as a to-do, or because you’ve now marked someone’s message as read and risk appearing rude if you don’t reply immediately. Or sometimes even worse things than that.
So I would argue that even if it’s 100x less common, an mis-tap can be 1000x worse of an experience. (Take these numbers with a pinch of salt, obviously.)
Also, I’d argue a ‘failed tap’ in a power user workflow is not actually something that gets repeated that many times, as in those situations the user gets to learn (after a few jarring halts) to wait a beat before tapping.
All that said, this is all just theory, and if Apple actually implemented this for iOS notifications then it’s always possible I might change my view after trying it! In practice, I have added these post-rendering interactivity periods to UI elements myself a few times, and have found it always needs to be finely tuned to each case. UI is hard, as you say.
I’m specifically thinking about phone notifications that slide in from the top – ie, from an app other than the one you’re using.
So we have two options: ignore taps on these notification banners for ~200ms after the slide-down (risking a ‘failed tap’) or don’t (risking a ‘mis-tap’).
I’d argue these are in different leagues of annoyingness, at least for notification banners, so their relative frequency difference is somewhat beside the point. A ‘failed tap’ is an annoying moment of friction - you have to wait and tap it again, which is jarring. Whereas a ‘mis-tap’ can sometimes force you to drop what you were doing and switch contexts - eg because you have now cleared the notification which would have served as a to-do, or because you’ve now marked someone’s message as read and risk appearing rude if you don’t reply immediately. Or sometimes even worse things than that.
So I would argue that even if it’s 100x less common, an mis-tap can be 1000x worse of an experience. (Take these numbers with a pinch of salt, obviously.)
Also, I’d argue a ‘failed tap’ in a power user workflow is not actually something that gets repeated that many times, as in those situations the user gets to learn (after a few jarring halts) to wait a beat before tapping.
All that said, this is all just theory, and if Apple actually implemented this for iOS notifications then it’s always possible I might change my view after trying it! In practice, I have added these post-rendering interactivity periods to UI elements myself a few times, and have found it always needs to be finely tuned to each case. UI is hard, as you say.