Click timing should be based on intent, not reality | Hacker News Reader

Click timing should be based on intent, not reality

11 pointsEarthLaunch4 comments

What is clickable shouldn't be based on what is on the screen. It should be based on what was on the screen at the time you decided to click.

Scenarios:

1. A notification or whatever appears on screen

2. I see it and move my finger/mouse to click it

3. By the time my finger reaches, it's gone

4. Instead, my click activates the thing below it.

1. I go to click something

2. A clickable notification appears above it right as I click

3. My click lands on the new thing instead of my intent.

Counter: This makes it worse when we know the software we're using and can anticipate what will appear.

View on HN

That sounds like the wrong way to do it. Computers trying to guess intent is what makes many aspects of modern software frustrating to use. Instead computers should make it easier to express your intent.

Mouse cursor moving towards notification? Let it sit there a while longer.

Mouse cursor where notification would appear? Make it appear somewhere else or wait.

iOS does something like this when you tap something really small in a browser. Instead of trying to guess where the tap was supposed to go, it opens a "magnifying glass".

I realized this maybe four years ago. Since then I've just been waiting for the big companies to catch up. But I've literally never seen this mentioned, reading all comments on related stories. I read way more than I write, which is why this didn't get traction. I'm glad.

Since this wasn't upvoted, I'll leave it as a record. It won't matter; someone will make this happen soon, I think. It'll have a fancy name, which I will adopt instantly. Moderately smart companies will be impressed that I've heard of the term.

I hate using my Android phone (especially its web browser) for this very reason. It frustrates me to no end. Sometimes, even when I think that the content is loaded (because the image is static for a few seconds), it's actually not - and tapping on the screen creates a UI event that is parsed a couple seconds later, after the screen scrolls because of a previous scroll that I thought was ignored.

I believe it's built this way because of modularity - the input drivers know nothing about the content of the screen, and once the event is finally registered, it cannot "go back in time" to figure out where the click is supposed to go - it can only send the event and let the user application handle it. The solution, it seems, would require some serious integration of the system with the UI toolkit.

This is one of my biggest wishes for basic UI correctness that I have no hope of ever happening. I woke up to the scope of this problem when I had enough of Android changing the order of clickable notifications in the windowshade. Of all of the things to try to present predictably and logically, this was one of the most important. It seems to me that it would be harder to let notifications rearrange themselves than not. And they didn't care.

This isn't even a new problem, or unique to mobile or dynamic web apps. Ever get an OS dialog box with hotkeys pop up while you're typing and you hit a key that responds to the popup and have no idea what you did? Remember someone sending you an instant message that steals your focus while typing, and you ended up sending them what you were typing?

Things should not move/change/appear AND be interactable at roughly the same time. When things move, they should become unclickable for a bit. When something is made clickable, all efforts should me made not to have it move or change. Browsers and some OS interfaces already do this with the "OK/Save/Run" button not being clickable until after a delay. But it needs to go further. There needs to be a screen flash and an audio cue when this happens so that you know it happened if you're not looking directly at the screen. Motherboard speakers should still be standard, so they can beep even if you have your audio muted.

If you must have both dynamic behavior and interactivity, then when you interact with something that recently changed, you should enter a disambiguation mode to confirm exactly what you intended to do, with buttons that are only active after a delay, and these elements should not move or change other than that.

Unfortunately I think the vast majority of people would see this kind of change as an unacceptable frustration. And the producers of the interface don't seem to care. Look at what happened when Android removed the ability to set ring and notification volume separately. I'm pretty sure they like it this way. Even accidental engagement is engagement for their metrics. It's why youtube rushes to put up the "play next video" button as soon as your original video is done. Or almost done, it feels like sometimes. To catch people who try to pause the video before it ends.

Reply on news.ycombinator.com