This is something that seemingly none of the big platforms or companies get right. Not Twitter, not Microsoft, not Firefox, not Apple, not a single one of them.
Seemingly they missed the lesson web developers learned ten years ago that you can't change content that the user is currently looking at without any interaction done, unless that's to be expected from the user.
But auto-loading items in a list is somehow still difficult for these companies to get right. Once you're done typing your query in the window's start menu, apple's "quick launcher thing" or twitter's search widget, it takes X seconds for the query to actually finish, so while you're hovering the menu, it changes content from underneath and the thing you wanted to click on, has been switched to something else.
I'm starting to wonder if this is on purpose, as seemingly no one is getting this right, but I don't understand what metric they are optimizing for (incorrectly) to believing that this behavior is correct.
I type the first letter. Firefox displays 10 options. I think they are bookmarks and recent google searches containing the letter. The ordering kinda corresponds to how recently or how often I used them, but it is not exactly that, for example the link I choose almost always somehow remains at the 2nd place. Whatever.
I type the second letter. Again, Firefox displays 10 options, bookmarks and recent google searches that contain the substring. At that moment, the link I want to click is quite often displayed somewhere. So I move my mouse...
...but a fraction of second later, Firefox loads "things it thinks I might want to search" (probably popular search results by other people that start with those two letters I typed) and inserts them into positions 2 - 5, moving the other search results below them...
...and just as I am pressing my mouse button, the link below my mouse cursor is replaced by google search for something completely irrelevant.
Aaaaargh!
(I wonder whether it is an accident, or on purpose, that the most frequently used link goes to the 2nd place, not the 1st one, so it gets replaced by an irrelevant google search. I suspect it probably increases some metric somewhere, and is probably interpreted as a good thing.)
I get this on iPhone search. I see what I want and go tap it, but it changes at the last second and I end up opening the wrong thing. And now I’ve trained the AI on the wrong thing just to make things worse.
> Seemingly they missed the lesson web developers learned ten years ago that you can't change content that the user is currently looking at without any interaction done, unless that's to be expected from the user.
Did web developers learn this lesson? Because I still see this literally every day on the web.
My guess: the web developers who learned that lesson 10 years ago are now outnumbered and outvoted by the developers and designers who don't have enough experience to do interaction design well. Neophytes will pretty much always outnumber experts, and the neophytes can only be counted on to adhere to a handful of the most popular design guidelines.
> you can't change content that the user is currently looking at without any interaction done, unless that's to be expected from the user
I think it’a more realistic to say that there has to be some latency bound in any user interaction. Clearly the result of any action is not instantaneous. Search boxes are tricky because the user isn’t sure what side effect typing an additional character will have - it could not refine the search or get a whole new set of results. If it’s not indicated to the user when the operation completes, then they can assume the former and then click at a bad time.
This is certainly one of the most frustrating things in modern UIs, although I’m not sure what it’s called I feel like it’s common enough for someone to have coined a name by this point. There are a few ways I can think of to deal with it:
1. Have very close to 0 latency. Clearly not always doable.
2. When in the process of searching, indicate to the user that the results aren’t fresh and new ones are coming - grey out the current options for instance.
3. Analyze how long the new results have been shown for and treat very short durations differently. If the new results have been up for 2ms, it’s not possible for that to be your desired intention.
That would not be sufficient even with a mouse: sometimes, I start moving my mouse and then click on the result that has already moved before I even started moving the mouse, but the whole interaction takes less than one second so I don't have the time to react to the update.
Graying out the results while the new one are coming can also be annoying: if the result that I am looking for is here and the new results are slow to come, I would be frustrated to be unable to click on it.
The whole situation is annoying but I don't know of a good solution and therefore I can't blame people who don't get this right.
A possible solution: Human reaction time is on the order of something like 215ms, if the change happened less than 100ms ago or so, the user probably wanted the previous result as opposed to the current one. Add a additional dialog to confirm?
This was one of the approaches I thought of but I wanted to know if this is a "solved" problem or whether there are some prevailing best practices by people who have spent time researching the various approaches
Apparently it seems like one of those "can't believe it's 2020 and we can't solve X" types of problems
Even worse: not considering exact matches when autocompleting. I’m looking at you, JIRA.
My name is Stephen. My username in my company JIRA is `stephen`. It is simply not possible for coworkers to reference my own name in many fields due to autocomplete behavior. Every other employee named Stephen (or user with `stephen` prefixing their username) is presented, but mine is unavailable.
Oh absolutely. I'd also add in that if I type "jor" then your autocomplete shouldn't say "nobody by that name, there's a jörgen but they clearly can't be talking about them so I won't return that at all".
IMO it should be solved at browser level. Basically browser should remember which pixel corresponds to which HTML element at any given timestamp. So when you click, it should check whether that div was located at this pixel 1 second ago. If it was not there, just ignore that click.
Until then it should be solved at application level.
Sure, this is just rough description. Probably it's better to just send a different event, so conventional websites won't react to it, but you can handle it if you want.
I've thought about this a bit and I think one way I might do it is freeze the list once a user has typed something, even as better results are coming in. Once they type a new letter you can redo the search with the better results, and users will do that anyways if they don't see their results in that list.
I thought it was always me and I was being too cynical but on mobile web, half of the times, I am scrolling and stop to click on media/link in the tweet and freaking add shows up and I end up clicking on that. May be it's just my device but annoying as hell UX.
When I tap on the result, there is invariably something else at the tap location
What's the terminology for this? Flash of ephemeral search result?
Are there any good ways of avoiding this problem?