Comment by Tade0
6 months ago
> One important difference is that if you have unlimited amounts of low latency and processing power, you can do a full search for each keystroke,
But you don't want that, as it's useless. Until the user actually finished typing, they're going to have more results than they can meaningfully use - especially that the majority will be irrelevant and just get in the way of real results.
The signal in between is actually, really not useful - at least not on first try when the user is not aware what's in the data source and how can they hack the search query to get their results with minimal input.
No one wants to see results for the letter "a", no one wants their database processing that search, and updating the UI while you're typing can be really distracting.
>No one wants to see results for the letter "a"
Don't make assumptions about what the user may or may not want to search for.
E.g. in my music collection I have albums from both !!! [1] and Ø [2]. I've encountered software that "helpfully" prevented me from searching for these artists, because the developers thought that surely noone would search for such terms.
_______
[1] https://www.discogs.com/artist/207714-!!! ← See? The HN link highlighter also thinks that URLs cannot end with !!!.
[2] https://www.discogs.com/artist/31887-Ø
No, you should definitely exercise good judgement in delivering a good UI to the user that doesn't lock up if they happen to type very quickly. But it is context dependent, and sometimes you will want to show them results for "a", sure. "No one" was rhetorical.
In your example, the developers have exercised poor judgment by making a brittle assumption about the data. That's bad. But there is no UX without some model of the user. Making assumptions about user's rate of perception is much safer (in a web app context, it would be a different story in a competitive esports game).
Let's see if surrounding that URL in the URL-surrounding character pair helps the HN linkifier:
<https://www.discogs.com/artist/207714-!!!>
Edit: It does. So, this would be yet another of the squillion-ish examples to support the advice "Please, for the love of god, always enclose your URLs in '<>'.". (And if you're writing a general-purpose URL linkifier, PLEASE just assume that everything between those characters IS part of the URL, rather than assuming you know better than the user.)
4 replies →
As a user, I often do want a list to start from a single letter. In a browser address bar, it could start showing items Amazon, Apple, etc.
That is fine. Do you want it to flicker between keystrokes when you're still typing?
6 replies →
I don't care if there are results for the letter "a", if they are instant.
Don't become unresponsive after one key to search for results. If the search impacts responsiveness, you need to have a hold-off time before kicking it off so that a longer prefix/infix can be gathered which will reduce the search space and improve its relevance.
> as it's useless
Be that as it may, the performance side of it becomes irrelevant. The UI responds to the user's keystrokes instantly, and when they type what they had intended to type, the search suggestions are there.
Switch debouncing does not become irrelevant with unlimited computing power.