Hacker News Reader

Comment by dsego | Hacker News Reader

> Long dropdowns are ridiculous to navigate.

But why, why, why? Why can't native dropdowns have an integrated search? Are we stuck in some sort of native UI limbo? Why aren't OS and browser developers doing anything about it. Why can't we have more advanced controls without div-soups and js galore?

With just a little bit of intelligence we could have controls that adapt to the offered choices: for example if < N show radio buttons, else show a dropdown, if too many - show a search box with auto-complete. Why is this so difficult?

View on HN

The worst part is that most native GUIs support editable combo boxes. I think they were common even before the web existed.

I don't understand why they weren't available in html forms since day one. Using the edit field as a search field would be a slight deviation but nothing that couldn't be solved with a bit of JS. At least the rendering could be fully native.

Also worth noting that native drop down boxes usually have a crude search feature: type they beginning of what you are searching fast enough.

This has frustrated me the most about when I was getting into web development. I would look it up, and thought surely even Bootstrap or modern HTML supports this? Nope, I gotta sort through hackish approaches instead of having a native solution.

> type they beginning of what you are searching fast enough.

Obnoxious that if you take too long you have to start over. Arguably browsers could add searching in a non-intrusive way that wont require additional code. Gnome 3 does this in a few places.

Native dropdowns do have integrated search, you just start typing, but it has very poor UX.

It used to be worse, if you used to type "Eng" then you'd find yourself at "Gabon" not "England" but that was fixed 5-10 years ago so as long as you keep typing it'll keep searching.

But there's no UX, so there's no discoverability to that feature.

I am aware of this feature, but it doesn't do fuzzy search, right? Also, I can't do it on my phone, the virtual keyboard doesn't show up.

Pet peeve: On macOS, dropdowns let you type to jump to the right item. But hitting space resets the search. So in a form with a "state" field, to select "New York" you can't type "new<space>y" to jump to it. You have to type "new", then hit the down arrow three times to get past New Hampshire, New Jersey and New Mexico.

Bad UX that for it to be space imho, it should be backspace that triggers it.

I'm a fast typer: a single backspace should not undo all keystrokes so far, only the last character should be deleted from my search. Better yet: show me what i'm typing using a pop-up textfield. Windows native ui also gets this wrong.

> But why, why, why? Why can't native dropdowns have an integrated search?

Search filtering requires UX/biz logic:

- Do you search only the beginning of the string or look for contained substrings?

- How do you prioritize results: whole-word matches or position of the substring?

- Do you highlight/bold the matching portion of the string?

- Spaces: ignore or include? Or search all results to see if spaces are relevant and if so, then use them...?

> With just a little bit of intelligence we could have controls that adapt to the offered choices: for example if < N show radio buttons, else show a dropdown, if too many - show a search box with auto-complete. Why is this so difficult?

You'd have the overhead of a search component just to show a couple of radio buttons.

Additionally: do you allow for words to be spelled incorrectly? People fat-finger things all the time, more so on mobile devices. Many pieces of software have this to some degree, see robots.txt as an example:

https://github.com/google/robotstxt/blob/bacd8ba94b6d066ff6c...

> Search filtering requires UX/biz logic:

I don't buy that some specific biz/ux logic is ever needed for a list of textual entries. We're not talking about a general search engine here. I imagine a simple heuristic could cover most of the cases (eg whatever c-f does). Also, the control can have additional params passed in to configure it differently when needed. Stuff like hightlight/bold (and even the matching rules) are imho either configurable or a system-specific implementation detail - like how macos dropdowns center on the selected item, or how on mobile a dropdown shows a modal scrolling interface, and so on.

>- - - -

Delegation. A control has simple defaults but may consult you if you provide a specific method. You don’t have to describe a complex behavior of say NSTableView beforehand, you just set yourself as its delegate and then decide at beforedraw-time which rows will be group rows, how to patch cell’s colors and fonts, etc. It is a very good part of desktop ui design. Web controls never delegate anything beyond trivial onaction=f(event).

There is an HTML control called <datalist> that is a dropdown with integrated search:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

That's interesting and works in all browsers. Not very discoverable though, looks like an ordinary text box... and behaves like one, I can select an option and then edit it. So, more like a list of suggestions and not specific options to choose from.

Initialisation order, narrow demand and documentation difficulties, in my case. I wrote and discarded that class for Qt.

It had tricky setup issues: Qt might need to test <N and commit to the result before the final N was known.

It made documentation more difficult, since application screenshots would vary more.

And finally, its niche was narrow. It only works if the number of items isn't known and varies across the threshold and the application developers don't have strong opinions about what to use.

This is something that macOS does well. You can search through the entire tree of options in drop-down menus for that program. This is definitely something I've missed after leaving the Apple ecosystem.

For those who haven't used macOS, here's a video of what this looks like in action: https://www.youtube.com/watch?v=anUt0Kw8C28 (full disclosure: not my video, no affiliation with the video poster).

This is like desktop Safari still not having native date/time pickers. Drives me insane that we still have to install datepicker libraries when the native ones in every other browser are just fine (if not better!)

For example, this horrific page to pick a bus destination: http://www.ak-split.hr/en/departures-from-split

The dropdown sort of works on desktop where you can start typing and the dropdown will change the selection. But this is a very exact search, no fuzzy lookup.

On my android phone however, there is no typing, the keyboard doesn't show up and you can only flick scroll the list, which is a really subpar experience.

>Why can't native dropdowns have an integrated search?

At least in Firefox, the normal <select> combobox does search by prefix matching the values of <option> tags as you type.

However it's pretty hard -nigh impossible?- to make a good globally generic search widget. Different datasets warrant widely differing matching rules (prefix matching vs. any place matching vs. any word matching; OR search vs AND search; case sensitivity; i18n concerns; non-alphanumeric characters).

Prefix search in dropdown boxes is one of those small UX features that every self-respecting desktop UI kit has had since the antiquity, long before the term "UX" was even a thing. It is also something that's missing in almost all naive web-based custom dropdown components.

However, its discoverability is almost nonexistent, and it's rather awkward to use because you don't see what you're actually typing. How fast should I type before the builtin timeout erases the buffer? How do I know if I made a typo? Does backspace work? And so on. Blind typing and trying to second-guess the logic behind the feature is not very fun.

I don't understand this line of reasoning. I am sure we have text search figured out by now, any sane matching heuristic can be used.

The solution lies beyond ... Prefab by Fogarty & Dixon.

References:

1 https://www.youtube.com/watch?v=lju6IIteg9Q

2 https://www.washington.edu/news/2010/04/01/what-if-all-softw...

Reply on news.ycombinator.com