3 ms·

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 distra

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.

meindnoch 1y ago
>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- 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-Ø https://www.discogs.com/artist/31887-Ø
- simoncion 1y ago
  Let's see if surrounding that URL in the URL-surrounding character pair helps the HN linkifier: <https://www.discogs.com/artist/207714-!!! 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.)
  - meindnoch 1y ago
    URLs can contain > too.
    - simoncion 1y ago
      I don't believe that they can, not unencoded. Check out the grammar in the relevant RFC[0], as well as the discussion about URL-unsafe characters in the RFC that's updated by 3986 [1], from which I'll quote below. > Characters can be unsafe for a number of reasons. ... The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text Also note the "APPENDIX" section on page 22 of RFC1738, which provides recommendations for embedding URLs in other contexts (like, suchas, in an essay, email, or internet forum post.) Do you have standards documents that disagree with these IETF ones? If you're using the observed behavior of your browser's address bar as your proof that ">" is valid in a URL, do note that the URL https://news.ycombinator.com/item?id=44826199>hello there might appear to contain a space and the ">" character, but it is actually represented as https://news.ycombinator.com/item?id=44826199%3Ehello%20there behind the scenes. Your web browser is pretty-printing it for you so it looks nicer and is easier to read. [0] <https://datatracker.ietf.org/doc/html/rfc3986#appendix-A https://datatracker.ietf.org/doc/html/rfc3986#appendix-A> [1] <https://datatracker.ietf.org/doc/html/rfc1738#section-2.2 https://datatracker.ietf.org/doc/html/rfc1738#section-2.2>
      - sgammon 1y ago
        Your point about URL encoding defeats your own other point about these characters being safely parsable as surrounding delimiters
        simoncion 1y ago
        No? URLs with the characters ' ' and '>' in them are not valid URLs. Perhaps your web browser does things differently than my Firefox and Chrome instances, but when I copy out that pretty-printed URL from the address bar and paste it, I get the following string: https://news.ycombinator.com/item?id=44826199%3Ehello%20there Though -oddly-, while Chrome's pretty-printer does pretty-print %3E, it fails to pretty-print %20 . Go figure.
- maxbond 1y ago
  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).
extra88 1y ago
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.
- Tade0 1y ago
  That is fine. Do you want it to flicker between keystrokes when you're still typing?
  - extra88 1y ago
    "Flicker" can mean a lot of things, I generally don't have a problem with the list changing while I type.
    - maxbond 1y ago
      Consider some people (the type to enable prefers-reduced-motion) find it very difficult to use a UI that is updating too frequently.
  - account42 1y ago
    Yes. Unless you are pecking at your keyboard your eyes are free to look at the results on the screen and stop typing once you get the result you want. The only thing that's needed is for the results to be stable, i.e. if the top result for "abc" also matches "abcd" then it should also be the top result for "abcd". Unfortunately many search/autocomplete implementations fail at this but that's still a problem even with "debouncing".
    - prmph 1y ago
      Are you really able to scan all the results in a few milliseconds? Even the 10ms in TFA is too low. I personally wouldn't mind (or probably even notice) a delay of 100 ms.
      - account42 1y ago
kazinator 1y ago
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.

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.

meindnoch 1y ago

>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- 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-Ø https://www.discogs.com/artist/31887-Ø

simoncion 1y ago
Let's see if surrounding that URL in the URL-surrounding character pair helps the HN linkifier: <https://www.discogs.com/artist/207714-!!! 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.)
- meindnoch 1y ago
  URLs can contain > too.
  - simoncion 1y ago
    I don't believe that they can, not unencoded. Check out the grammar in the relevant RFC[0], as well as the discussion about URL-unsafe characters in the RFC that's updated by 3986 [1], from which I'll quote below. > Characters can be unsafe for a number of reasons. ... The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text Also note the "APPENDIX" section on page 22 of RFC1738, which provides recommendations for embedding URLs in other contexts (like, suchas, in an essay, email, or internet forum post.) Do you have standards documents that disagree with these IETF ones? If you're using the observed behavior of your browser's address bar as your proof that ">" is valid in a URL, do note that the URL https://news.ycombinator.com/item?id=44826199>hello there might appear to contain a space and the ">" character, but it is actually represented as https://news.ycombinator.com/item?id=44826199%3Ehello%20there behind the scenes. Your web browser is pretty-printing it for you so it looks nicer and is easier to read. [0] <https://datatracker.ietf.org/doc/html/rfc3986#appendix-A https://datatracker.ietf.org/doc/html/rfc3986#appendix-A> [1] <https://datatracker.ietf.org/doc/html/rfc1738#section-2.2 https://datatracker.ietf.org/doc/html/rfc1738#section-2.2>
    - sgammon 1y ago
      Your point about URL encoding defeats your own other point about these characters being safely parsable as surrounding delimiters
      - simoncion 1y ago
        No? URLs with the characters ' ' and '>' in them are not valid URLs. Perhaps your web browser does things differently than my Firefox and Chrome instances, but when I copy out that pretty-printed URL from the address bar and paste it, I get the following string: https://news.ycombinator.com/item?id=44826199%3Ehello%20there Though -oddly-, while Chrome's pretty-printer does pretty-print %3E, it fails to pretty-print %20 . Go figure.
maxbond 1y ago
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).

extra88 1y ago

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.

Tade0 1y ago
That is fine. Do you want it to flicker between keystrokes when you're still typing?
- extra88 1y ago
  "Flicker" can mean a lot of things, I generally don't have a problem with the list changing while I type.
  - maxbond 1y ago
    Consider some people (the type to enable prefers-reduced-motion) find it very difficult to use a UI that is updating too frequently.
- account42 1y ago
  Yes. Unless you are pecking at your keyboard your eyes are free to look at the results on the screen and stop typing once you get the result you want. The only thing that's needed is for the results to be stable, i.e. if the top result for "abc" also matches "abcd" then it should also be the top result for "abcd". Unfortunately many search/autocomplete implementations fail at this but that's still a problem even with "debouncing".
  - prmph 1y ago
    Are you really able to scan all the results in a few milliseconds? Even the 10ms in TFA is too low. I personally wouldn't mind (or probably even notice) a delay of 100 ms.
    - account42 1y ago

kazinator 1y ago

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.