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?
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.
> 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.
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.
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.
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).
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.
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).
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.
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).
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.
It's best to have some note next to it describing the current state ("enabled" / "disabled").
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.
Look at it from a different perspective - say you have a TV remote with two separate buttons to turn it on and off. They will be labeled after what they do and that makes total sense. Then someone says "hey, only one of these is usable at any point" and merges them into one button with magically changeable text. Should the text say what the button does or what state the TV is currently in?
A TV remote is also a bad UX example, because you can actually see that the TV is on or off by looking at the TV itself, and then use the button to perform the desired action.
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.
In their defense that's how most UI toggles work but they are using a 'phone' metaphor and it's implemented backwards from how you would usually expect a phone call UI to work.
This comment being right next to this one shows the joy of designing UIs:
> I never understood why one would make a control show the state that it isn't in.
UI is hard indeed.
It's blue when on, gray when off. The tooltip describes the completely opposite state to the one that's currently active.
The icon is the same in both state, the color means nothing (since when the blue means on?), tooltip is wrong. Bah.
Wait, that's a bad thing? I can only imagine how pissed off I'd be when using an interface that insisted on me using my mouse to click and drag a switch to turn it "on" or "off" instead of, you know, just clicking. I don't even do the left/right swipe thing on mobile, either; way more convenient to just tap instead of drag.
It is an attempt at communicating state and action at the some time, but I think disconnecting look and behavior is a mistake. Don't use a skeuomorphic slider to represent a push button switch, especially if selling the realism of a touch interface is the goal.
I guess it goes back to my other post about "intuitive" not actually being a real thing, and the actual factor being "what you're used to".
I mean it's fine for physical things to avoid it, as you probably don't want to manufacture 200 different power on buttons for your TV.
But in software, I like UI's using text much more than the icon/graphics using ones.
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!
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.
Specifically in the case of the add playlist example given on the article, having it both at the bottom of the playlist list and the header of the playlist section does not detract from either one, but just satisfy different user journeys to get there.
I think you're certainly right when the UI gets crowded -- the MS Office ribbon comes to mind; too many buttons to do formatting including dropdowns that do the same thing as other buttons makes it hard to find related functionality -- "why can I bold and italic here, but not strikethrough here?" because strikethrough was relegated to a submenu somewhere.
What adds insult to injury is that Nevis isn't even a country, it's part of the Federation of Saint Kitts and Nevis.
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.
I need to find those, because I keep getting the ones that go Namibia > East Timor > Wake Island when I try that.
It could be a case of custom controls being poorly implemented.
So much find searching for Deutschland under G. Seems to happen quite a bit.
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.
All three titles tell you nothing about what the job is at a specific company, because every company defines them a little (or a lot) differently. Hence: "PM".
First principles include knowing that you communicate with the user through interface, being intentional, having an overall vision, being consistent.
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.
 Including consistency in evolution across product lifetime.
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 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.
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.
> I don't believe there is any such thing as intuitive interfaces, only familiar interfaces.
You read so much about "intuitive" UI/UX design. It's in the article's title, after all. All based to some degree on what interactions come naturally to humans. I don't think much does come naturally beyond a very basic level, and after that it's purely to do with familiarity. So rather than focusing on some hypothetical universal intuition, focus on what your target audience is familiar with.
Rigid adherence to guidelines isn’t a good idea, obviously, and there aren’t any universal truths and all of that is good to know but at first it doesn’t really get you anywhere, besides being obvious.
Whenever human brains are involved it gets complex and no hard and fast rules exist.
Intuitive = it's new to you, but it's function is based on something you know and lesrning this requires very little of you.
Nothing is technically intuitive and in that regard I do agree with you but I think you are missing the forest for the trees. Everything humans ever do happens within a certain context. There is no fleeing that. And you can call interfaces respecting that context familiar but it also wouldn’t be wrong to call that intuitive.
In that way the distinction you are making up is a very gradual and almost completely meaningless one.
I’m not married to keeping on using the word “intuitive” but I do think it’s also not wrong to use it and especially shouldn’t be followed up by pithy, meaningless (= don’t tell you anything new) dismissals because of that word use.
for example, using the scrollbars in the browser chrome provided by the operating system are better than hiding them and implemnting some custom "intuitive" scrolling mechanism.
In my opinion, the use of the work "intuitive" in UI design is a misnomer, when the designer actually means "subjective to me the designer"
The intuitiveness of an interface is an empirical question. Whether it works or not is not some subjective fact.
The Venn Diagramm for “intuitive” definitely includes “familiar”, it’s just a more generic term where other factors except familiarity can also play a role.
Do you have any examples of someone pushing for something completely novel and unfamiliar under the banner of intuitiveness? That seems like something that doesn’t happen.
Your viewpoint on this just seems wholly weird and just doesn’t ring true at all. People abusing the term “intuitive” doesn’t make it useless.
(Plus, just for a moment going back to the article: This article does not argue for custom scroll bars or anything even remotely similar to that.)
Is this intuitive UX?
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.
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.
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.
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.
They're great for point of sale, terrible for product discovery as a direct result of the UI. That's fine for most products where you can research what you want to buy then purchase on Amazon anyway (because free 1/2-day shipping), but it means services like Prime Video are terrible to use compared to Hulu/Netflix.
Which is a shame, since I think their originals and content library is really solid. It's just impossible for you to discover it without a huge ad campaign.
Trying to differentiate UI and UX in the context of a web app makes no sense. Both are two sides of the same coin. In your own comment, you couldn't even come to a conclusion as to where one ends and the other begins!
This is the hallmark of a buzzword. When a phrase like UX comes to describe everything and nothing at the same time it ceases to have meaning.
Good UI seems to be a "know it when I see it" but I'm not convinced a good UX exists yet (or even could exist?) otherwise all applications would use the same methodology
For instance, how is Prime 2-day shipping not considered part of the purchasing experience?
Every interaction you have with a business in any capacity is an "experience." How then, can you have employees who are tasked with everything? Conversely, by definition, isn't everybody in the company then a UX person?
UX is everything and nothing depending on the agenda of the person using the term. It's a buzzword.
As long as you can very quickly and easily buy on Amazon because it's cheaper and perhaps other reasons like the delivery story, returns story, customer services story etc are all better, then the UI in service of the UX is doing its job really well.
They're not (necessarily) optimising for you searching for products or finding more detail about products, they're optimising for you buying the products. They very likely care zero if you did the former elsewhere, because why would it affect them if you did or not, you still bought with them.
They use dark patterns, sure, but don’t confuse useable UI with beautiful UI.
If I'm wrong, fair enough. Need to change my model!
> don’t confuse useable UI with beautiful UI.
Perhaps I didn't get this across clearly enough, but I definitely don't. It's actually the main point I'm trying to make. Beautiful UI serves a certain type of UX which most products don't need. What most products need is boring, functional, useable design that just works, Amazon being a good example of this.
Only one example of thinking outside the box that’s relatively new on Amazon is putting your delivery address right there in the main navigation and giving you the opportunity to change it.
This kind of upfront communication allows them to keep the checkout process itself extremely light and effortless which to me seems to be pretty much the focus of everything they do.
That example you gave, whilst obviously literally an update of the UI, I would punt as being more a UX change, actually. The reason is that the point of it is what you say - to reduce friction of the checkout flow by not forcing you to wait until you do that to change your address, but letting you do it ahead of time so that next time you check out, you're just a couple of clicks away from hitting the 'pay' button - as opposed to leaving functionality the same and just making things look nicer.
Obviously this change is physically implemented as a UI change, but my question would be did the nav bar's design, position on the screen, etc, change? No - it was a flow change implemented within the existing UI design metaphors.
What I'm more alluding to with UI changes is changing those designs and metaphors, with the hope of making the UX 'nicer' as a result. This only works if nicer UI is nicer UX. In Amazon's case that's not true, so they stick with the same server-rendered pages, buttons, navbar, form fields, etc etc that they've had forever. They make flow changes within that UI though, of course, to facilitate better UX.
- 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