Autocomplete Selections Should Confirm with User

One UX issue that I run into more often than I’d like: when you type in a text box and a list or drop down appears and you tap on it immediately, only to learn that between the milliseconds that your brain executed the tap and your fingers touched the screen a new item replaced your intended target.

Sometimes this is a more benign environment where you are searching for something and after you type a few letters what you want appears, but you managed to type another letter and the results are changed due to network delay.

I don’t want to stray from the topic; however, I must point out that I’ve seen this behavior pervasively in advertising. I first noticed it back in the early 2010s when using Meebo probably just before Google acquired it. You’d go to type a message in response to one someone sent and, surprise!, the spot where you were about to tap to focus the input box became an ad, pushing the input box higher in the interface. It seemed too well timed to be just a coincidence. Today I see this exact kind of behavior with Amazon, though it seems they are starting to transition to just making every result an ad so no need to trick you into clicking. Sadly I’ve even seen this with DuckDuckGo, eroding my trust in that company¹. What I can’t fathom is how the engineers behind these platforms let it happen. They must know what they are doing. Or, if you are a fraud investigator and search on Amazon and accidentally click one of these ads do you say to yourself, “Haha! I was fooled again!” The advertisers meanwhile don’t seem to care either, because revenue > cost of marketing?

Transitioning back to the crux of my post: there’s no technical reason for this! If you are planning to asynchronously return some kind of result in addition to your server-side result, it’s obvious that you can put a placeholder in your template. The contents of the placeholder can be up to your imagination: “Our valued sponsors have a result just for you.” It may be more effective to humanize the results than just treating the user as a sucker. “Got you, fool! Now pay me $8.”

Another way to deal with this, in the case of results in apps with search/dropdown combos without monetization incentives, is to calculate the time it takes between the last result populated and the newly invalidated list. In fact, use the same UX exploit that seemed to be happening with Meebo but display a dialog asking the user if they meant the previous result, current result, or something else. That this would only happen in circumstances where there was incongruity between the user’s input and the lagged result means it would be infrequent. Empirically it doesn’t happen often, but when it does it can be obnoxious and cause more grief than a simple confirmation dialog box.

Version 0.95