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?
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.
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.
> 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.
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!)
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).
OTOH, I never know when the switch is on. Coloring it doesn't help me much, because I'm not sure it the color means current state or the one it will get after clicking. It's like with the collapse button: does ^ mean it's currently collapsed, or that clicking it will collapse some list (state vs action).
It's best to have some note next to it describing the current state ("enabled" / "disabled").
Apple is very consistent with this: the visual display always indicates the current state.
Other operating systems and third-party applications are not always consistent, even some big popular ones. 1Password used a "locked padlock" icon to both mean "it's locked" and "it's not locked (click here to lock it)", for the first 12 years. (They never fixed it, though with 1Password 7 they strangely removed the lock button entirely.)
Maybe it's because I grew up using Apple computers, but I never understood why one would make a control show the state that it isn't in.
Aaaargh this one gets me every time. Any interface made out of on/off toggles needs some really clear signalling to say which way is on and which is off.
Also an honourable mention goes to touchscreen widgets that look like a left/right slidey switch but are activated by a tap and not a drag.
One thing I don't see very often but is intensely useful is that you don't always have to make a choice. The "Add Playlist" example is a case of "why not both?" -- have it at the bottom of the list, have it in the header of the list, sure, throw one in the menu as well. The user journeys can be either "I came here to add a playlist", "Hey, here are playlists, I should make one", and "Oh, they don't have the playlist I want, I'll make one", and all of those end up in different places. The Material-style "+" in the corner is in my mind almost always the worst case -- if everyone did it, then it wouldn't be so bad, but it's a thing you never think to look for with an unfamiliar UI.
I like the discussion of "Poisson" options; thinking about the distribution of inputs is an important factor. For location/country dropdowns, I find it frustrating that often my country, the "United States of America" is put at the top of the dropdown for convenience, but if you miss that and start to scroll down, it does not appear in the "U" section of the dropdown. Just put it in both!
The "Add Playlist" example is a case of "why not both?"
One potential answer is that while two possible actions may be obviously equivalent to the designer, that is not necessarily obvious to the user. It's a classic usability problem: the designer tries to be helpful but in reality there is now a confusing variety of similar-looking ways forward, and then the user gets analysis paralysis and gives up. The mistake is often compounded by having equivalent things look slightly different, for example using different types of controls, or using slightly different terminology or phrasing.
The more buttons, the less visibility per button. One (clear) button in the right place beats two separate buttons, when other buttons are taken into account.
God I hate country drop-downs, especially ones that don't have search functionality, double hate them on mobile. Yep, a normal drop-down will let me move down the options by pressing a key - I'm a Kiwi, so N for New Zealand, but that just moves me to Namibia, then I've got to carefully scroll to locate my country in between Nevis and Nicaragua.
What adds insult to injury is that Nevis isn't even a country, it's part of the Federation of Saint Kitts and Nevis.
It's always terrible. If nothing else, am I in "Britain", "England", "Great Britain", "United Kingdom", "The United Kingdom" or some obscure different variant, sometimes the entry is at the top of the list, sometimes sorted, sometimes random. Every list seems somehow different.
One thin that people miss for dropdowns is that you can actually type N..E..W.. and it will select New Zealand. Most browsers implement some sort of combo counter for it, such that the entry resets after a while too.
I do agree that search boxes are better in general, and especially so for things that are not standardised such as country or airport 3-letter codes. But it's not the end of the world, even for date inputs you can just type 1984 and it'll select it for you.
EDIT: It does not change the fact that mobile dropdown implementations are horrendous.
Pieces like this might give an illusion that by following the listed rules you’ll achieve “intuitive UX” (sic). I believe they could be useful if you already have the first principles somewhat internalized, but otherwise are likely to be a dangerous distraction.
First principles include knowing that you communicate with the user through interface, being intentional, having an overall vision, being consistent[0].
People’s expectations as to exact UI layout and behavior can vary a lot, depending on their background and previous experience (for example, on macOS I personally often look for things & shortcuts in menu bar first instead of scouting app’s interface). However, people are not stupid, they learn.
[0] Including consistency in evolution across product lifetime.
As a total newbie to UX (I used to be a middleware/back-end developer :-P), I read this article differently. The article mentioned a list of things NOT to do which has its own uses. Let me give you some context:
I currently work as a PM at a startup. We don't really have a UI/UX guy since the last full-stack dev quit.
By avoiding a lot of these issues in the first place, I , as the PM can ensure that my customers don't get pissed off because my team mates have built a solid product (code quality, functionality, stability etc) but with glaring UX howlers :-). Via negativa FTW!
I'm surprised the date text inputs part didn't mention anything about the date format, which is something I've seen users frequently confused over, especially the US format of mm/dd/yy which is different than what most of the rest of the world uses.
It's been said that "the only intuitive user interface ever created was the nipple", but even then it can take hours or days for an infant to figure out how to use a nipple.
I don't believe there is any such thing as intuitive interfaces, only familiar interfaces. So learn what your users are familiar with, and build around that.
The best way I've heard it put, is that good UX isn't automatically knowing what to do the first time you interface with something. It's doing it once and then it feeling intuitive every time after.
I’m not sure what you are trying to say here and how it relates to the article.
It’s a pithy quote but it’s also sort of pointless since all of culture is like that. To a certain extent intuitive = familiar and that’s not even weird or surprising.
This write up seems quite decent, but it just boils down to some basic stuff. Like putting a button near a new feature and choosing the right tool for selection. Which are both really valid points.
The thing I really miss in this article is accessibility. For some visually impaired users it can be beneficial to use a dropdown instead of some visual markers, which can be distracting and unusable for some.
Also the text and arrows explaining the 'design mistakes' are quite tiny, have insufficient contrast and thus do not make for a good visual experience.
A very misleading title to this article but a couple of great reminders. One thing that is somewhat missing is to always remind yourself to remove blockers of any kind for users. The easier it is to use your product, the better experience users will have.
I still can't believe it how these kinds of things are not OBVIOUS to ALL UI and UX designers out there! This resources should be drilled into every UX/I designer's head. It's amazing how much pain and frustration can be avoided by following such simple rules. I imagine a kitten being squished in a blender alive every time I see checkboxes used as radio buttons... or people avoiding to use radios and toggles where they make clear sense...
The hell with material design and all the other fads, learn these basics first please and don't screw them up!
I generally agree with dropdowns being overused, but this seems too much to me:
> Picking a date from dropdowns is the worst. If I ever do this, then I’ve really failed as a UX designer.
Really? On a laptop, native dropdowns use keyboard input as search, so using tab (granted, not everyone knows this) I can generally enter my age almost as if I was writing it.
On mobile, scrolling through the iOS dropdown control is fine, more comfortable than typing. Scrolling 30 options back to enter my age is the worst part, and getting worse every year, but it isn't that bad.
Yeah, I pretty much disagree with the author when it comes to something like inputing your birthday. For something like hotel stays or airplane tickets, it does make sense to show a full calendar to give a sense of the range between two dates, but for inputing a birthday I'll take the "9 taps" required to fill out the three fields on mobile. I think it's going to end up faster than alternating between tapping to select a field and typing to enter the value.
This has nothing to do with the “UX” of your application. Sure, you may frustrate users if you don’t follow these rules. However, users will never use the thing you’re building if doesn’t meet their needs.
My favourite example of the definitions and distinctions between UI and UX is Amazon.
Their UI hasn't really changed in years, but their UX has, a lot. Do you think they would have seen the same amount of growth if they'd focused on improving the UI of their site, rather than the UX of their service?
It's not that UI is unimportant. On the contrary, I personally think it's very important, but only in as much as it serves the UX. This for instance means that a company like Apple has to invest a lot more in evolving and improving their UI. It's fundamental to their UX of beautiful, useable devices. In a sense the UI is the UX, so they're tied together very closely. For most companies/products that isn't the case though. Most are more like Amazon.
To Amazon, the UI just needs to be functional, and get the user through to making a purchase as quickly and with as little hassle as possible. That's why they've stuck with essentially the same design and layout for years - customers know it, and it just works. Any changes making it fancier or prettier would be, at least in the short term, detrimental to the UX.
What's wrong with GNOME? I've been using it for years, I think it's by far the most consistent and logically laid out desktop environment on Linux. In fact I think it's more usable than Windows, which is impressive for it being such a small project.
I've always understood it to be that 'type-ahead' is a category that includes both autocomplete and autosuggest. Those two are subtly but importantly different. As 'suggested' by the name, autosuggest acts somewhat like a recommendation engine. It takes the characters that have already been typed, and uses those to search for potentially related keywords, etc., even if those don't match the literal characters the user has typed. Autocomplete, meanwhile, is a 'dumb' tool that enables things like tab-complete. Both are considered flavors of type-ahead.
[+] [-] dsego|6 years ago|reply
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?
[+] [-] GuB-42|6 years ago|reply
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.
[+] [-] XJ6|6 years ago|reply
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.
[+] [-] radley|6 years ago|reply
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.
[+] [-] symlinkk|6 years ago|reply
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
[+] [-] Arnt|6 years ago|reply
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.
[+] [-] charlesdaniels|6 years ago|reply
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).
[+] [-] WD-42|6 years ago|reply
[+] [-] dsego|6 years ago|reply
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.
[+] [-] dexen|6 years ago|reply
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).
[+] [-] nunb|6 years ago|reply
References:
1 https://www.youtube.com/watch?v=lju6IIteg9Q
2 https://www.washington.edu/news/2010/04/01/what-if-all-softw...
[+] [-] megous|6 years ago|reply
It's best to have some note next to it describing the current state ("enabled" / "disabled").
[+] [-] ken|6 years ago|reply
Other operating systems and third-party applications are not always consistent, even some big popular ones. 1Password used a "locked padlock" icon to both mean "it's locked" and "it's not locked (click here to lock it)", for the first 12 years. (They never fixed it, though with 1Password 7 they strangely removed the lock button entirely.)
Maybe it's because I grew up using Apple computers, but I never understood why one would make a control show the state that it isn't in.
[+] [-] taneq|6 years ago|reply
Also an honourable mention goes to touchscreen widgets that look like a left/right slidey switch but are activated by a tap and not a drag.
[+] [-] jonahx|6 years ago|reply
https://ux.stackexchange.com/questions/1318
[+] [-] 4mitkumar|6 years ago|reply
[+] [-] andrewla|6 years ago|reply
I like the discussion of "Poisson" options; thinking about the distribution of inputs is an important factor. For location/country dropdowns, I find it frustrating that often my country, the "United States of America" is put at the top of the dropdown for convenience, but if you miss that and start to scroll down, it does not appear in the "U" section of the dropdown. Just put it in both!
[+] [-] Silhouette|6 years ago|reply
One potential answer is that while two possible actions may be obviously equivalent to the designer, that is not necessarily obvious to the user. It's a classic usability problem: the designer tries to be helpful but in reality there is now a confusing variety of similar-looking ways forward, and then the user gets analysis paralysis and gives up. The mistake is often compounded by having equivalent things look slightly different, for example using different types of controls, or using slightly different terminology or phrasing.
[+] [-] spiderfarmer|6 years ago|reply
[+] [-] EdwardDiego|6 years ago|reply
What adds insult to injury is that Nevis isn't even a country, it's part of the Federation of Saint Kitts and Nevis.
[+] [-] misnome|6 years ago|reply
[+] [-] grenoire|6 years ago|reply
I do agree that search boxes are better in general, and especially so for things that are not standardised such as country or airport 3-letter codes. But it's not the end of the world, even for date inputs you can just type 1984 and it'll select it for you.
EDIT: It does not change the fact that mobile dropdown implementations are horrendous.
[+] [-] koonsolo|6 years ago|reply
[+] [-] mrunkel|6 years ago|reply
So much find searching for Deutschland under G. Seems to happen quite a bit.
[+] [-] arendtio|6 years ago|reply
I wish fewer people would use the PM abbreviation. You never know if it means 'Product Manager' or 'Project Manager' and have to consult the context.
[+] [-] goblin89|6 years ago|reply
First principles include knowing that you communicate with the user through interface, being intentional, having an overall vision, being consistent[0].
People’s expectations as to exact UI layout and behavior can vary a lot, depending on their background and previous experience (for example, on macOS I personally often look for things & shortcuts in menu bar first instead of scouting app’s interface). However, people are not stupid, they learn.
[0] Including consistency in evolution across product lifetime.
[+] [-] vmurthy|6 years ago|reply
I currently work as a PM at a startup. We don't really have a UI/UX guy since the last full-stack dev quit. By avoiding a lot of these issues in the first place, I , as the PM can ensure that my customers don't get pissed off because my team mates have built a solid product (code quality, functionality, stability etc) but with glaring UX howlers :-). Via negativa FTW!
[+] [-] roguesherlock|6 years ago|reply
[+] [-] aschmid|6 years ago|reply
[+] [-] taneq|6 years ago|reply
I don't believe there is any such thing as intuitive interfaces, only familiar interfaces. So learn what your users are familiar with, and build around that.
[+] [-] wallawe|6 years ago|reply
[+] [-] dsego|6 years ago|reply
[+] [-] arrrg|6 years ago|reply
It’s a pithy quote but it’s also sort of pointless since all of culture is like that. To a certain extent intuitive = familiar and that’s not even weird or surprising.
[+] [-] elbrian|6 years ago|reply
Is this intuitive UX?
[+] [-] alex3305|6 years ago|reply
The thing I really miss in this article is accessibility. For some visually impaired users it can be beneficial to use a dropdown instead of some visual markers, which can be distracting and unusable for some.
Also the text and arrows explaining the 'design mistakes' are quite tiny, have insufficient contrast and thus do not make for a good visual experience.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] guylepage3|6 years ago|reply
[+] [-] duxup|6 years ago|reply
It's understandable as there is a playlist(s) view, playlist content view, album view, song view ... and so on.
I never know what the back button or any click will do for me.
[+] [-] nnq|6 years ago|reply
The hell with material design and all the other fads, learn these basics first please and don't screw them up!
[+] [-] ikurei|6 years ago|reply
I generally agree with dropdowns being overused, but this seems too much to me:
> Picking a date from dropdowns is the worst. If I ever do this, then I’ve really failed as a UX designer.
Really? On a laptop, native dropdowns use keyboard input as search, so using tab (granted, not everyone knows this) I can generally enter my age almost as if I was writing it.
On mobile, scrolling through the iOS dropdown control is fine, more comfortable than typing. Scrolling 30 options back to enter my age is the worst part, and getting worse every year, but it isn't that bad.
[+] [-] baddox|6 years ago|reply
[+] [-] hizxy|6 years ago|reply
[+] [-] davnicwil|6 years ago|reply
Their UI hasn't really changed in years, but their UX has, a lot. Do you think they would have seen the same amount of growth if they'd focused on improving the UI of their site, rather than the UX of their service?
It's not that UI is unimportant. On the contrary, I personally think it's very important, but only in as much as it serves the UX. This for instance means that a company like Apple has to invest a lot more in evolving and improving their UI. It's fundamental to their UX of beautiful, useable devices. In a sense the UI is the UX, so they're tied together very closely. For most companies/products that isn't the case though. Most are more like Amazon.
To Amazon, the UI just needs to be functional, and get the user through to making a purchase as quickly and with as little hassle as possible. That's why they've stuck with essentially the same design and layout for years - customers know it, and it just works. Any changes making it fancier or prettier would be, at least in the short term, detrimental to the UX.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] dsego|6 years ago|reply
[+] [-] symlinkk|6 years ago|reply
[+] [-] majortennis|6 years ago|reply
[+] [-] Gene_Parmesan|6 years ago|reply
[+] [-] radley|6 years ago|reply
- place the "add" button at the end of lists
- if you're still using dropdowns like it's 1997, stop
- make your call to action obvious
- examples help sell your product