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.
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.
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.
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.
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.
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:
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).
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!)
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.
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.
The logic is relatively sound, you're describing what will happen when used.
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 button is a bad UX example, because it is rather a switch with two indicators - now it is on, and turn it the other side/way to turn off.
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.
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.
The most confusing toggle I've seen is the "Listen for debug connections" in intellij [0,1]. It shows the current status instead of the action you would be performing. You have to click the "Hang up" icon[0] to START listening and and "Connect" icon[1] to STOP listening.
In their defense that's how most UI toggles[2] 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.
Interesting enough I actually agree in principle with arsenico and ken. The debug button example is a weird corner case. On pretty much every smart phone you click a green call button to make a call and click a red disconnect button to disconnect. The debug button is consistent with other toggle buttons while being the reverse of a common convention. It may have been less confusing if it was a grayed out phone when off and green when connected.
I think the problem is that the "Listen for debug connections" button doesn't look like a toggle (a slider that will move back and forth). If it looks like a toggle, then showing the current state is good because the button design is saying that it will toggle away from that current state, but if it's not a toggle, the user understands button icons as signifying what will happen.
> 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.
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.
Yes it's a bad thing not because of the action, but because of the representation.
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 think the representation's fine (but I'm a fan of skeuomorphism...), as long as I don't have to physically drag :) Clicking on or tapping one side or the other is fine by me.
As I mentioned in my comment: even on a touchscreen, not once have I actually flicked it instead of just tapping it. It just ain't intuitive. Not on an iPhone, not on an iPad, not on an Android or Windows Phone or Palm or Blackberry or Newton or Lord knows what else.
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.
I think that's making assumptions about user attention that aren't valid. The user is not looking for all ways to do something; they are looking for the first way that satisfies their intention.
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.
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.
It's why I always recommend against non-native controls by default, whether on the web or desktop/mobile - even if you're particularly observant about your platform (and most devs aren't), there's probably still a bunch of little things like these that you'll miss and won't implement, and that people actually use daily.
And not only that, but unless you're observant about literally every platform on which your app will run, you are bound to break something, whether subtly or majorly.
I thought it wasn't working, but apparently on FF you have to do it really fast. Take a second between key presses and it'll just revert to the old behaviour. Talk about being shitty to people with poorer motor control or who need to hunt and peck.
Mine is the country search box that Google uses in some places, where typing G brings up all countries that include the letter G, but in alphabetical order. Meaning “Afghanistan“ is on top, so I type “Ge“, which results in “Algeria“ being first. It’s so infuriating and makes no sense at all. Why would someone looking for Algeria search for Ge? Who on earth thought this is how people searched for their country anywhere?
Oh, also experienced this on some sites, where you can see they plugged in translation to come after the sql queries are done, so the 'sort by' happens before the strings get replaced.
You can just mash N 5 times... (6 if there is a Nevis although I feel like that’s some weird hold out of colonialism that is specific to kiwi sites and I cannot find an example of a drop down containing it)
"PM" is strategic ambiguity -- it's actually a benefit that it can mean either, because a product manager at one company might be called a project manager at another, and vice-versa. And don't forget "program manager" as a third variant.
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".
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!
To internalize something is to make it come naturally without reminding yourself about it every time. Practice, reading material on those topics (books like “The Design of Everyday Things”, “Notes on Graphic Design and Visual Communication”) help.
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.
> 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.
But familiar = intuitive. You are just splitting hairs. Obviously what’s intuitive is intuitive largely because it’s familiar (mixed in with a bit of psychology and perception) but that’s not really an issue at all.
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.
That’s not really how humans work and not really how brains work.
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.
I disagree - I think the importance of the distinction is that familiar interfaces work better than new, novel interfaces that supposedly tap into some deeper human psycology.
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.)
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.
I think Amazon would have benefited from better UI for particular parts of their platform and achieved better growth.
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.
Both the UI and UX of amazon's web store are terrible. The reason people buy from amazon is price, breadth of selection, and speed of delivery, not the wonderful shopping experience.
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.
They are two sides to the same coin but they are definitely different - think of an application with a good UI, now imagine if the business rules around doing things in the application were suddenly made convoluted - that's UX
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
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.
I understand what you're saying, but this anecdote just confirms to me that Amazon's UI has the correct focus.
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.
Searching is very important factor. For simple things i can search in amazon but if i have to drill down like laptop, computer parts, mobiles its practically useless. Which then makes me check their competitor which is a huge fail. Now you have sponsored ads between search which don't respect the search filter. I am actually buying more in flipkart these days then amazon.
Could you give me an example of this? My impression as a user is that it's not changed very much at all for years. This is the web UI by the way. Both on Amazon.com and AWS.
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.
Amazon has changed massively over the years. Check out the Wayback Machine. (Sadly looking at the checkout itself that way isn’t really an option.)
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.
Ah, very interesting example thanks. We're back to definitions of UI and UX and the overlap between the two :-)
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.
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.
I wonder if these rules are really that universal when you consider the UX and needs of different sectors such as banking, aviation or governmental for that matter.
Plus there's always that economic trade-off of filling the consumer's windows with ads, bloat and Pavlovian purchase incentives. (Yes, I'm looking at you Booking.com)
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.
https://github.com/google/robotstxt/blob/bacd8ba94b6d066ff6c...
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).
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
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.
References:
1 https://www.youtube.com/watch?v=lju6IIteg9Q
2 https://www.washington.edu/news/2010/04/01/what-if-all-softw...
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[2] 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.
[0] https://www.jetbrains.com/help/img/idea/2019.2/php.icons.deb...
[1] https://www.jetbrains.com/help/img/idea/2019.2/php.icons.deb...
[2] https://www.jqueryscript.net/images/jQuery-Plugin-For-Slidin...
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.
https://news.ycombinator.com/item?id=20737877
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".
https://ux.stackexchange.com/questions/1318
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.
Screenshot: https://i.imgur.com/QBqZdRml.png
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[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.
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
Plus there's always that economic trade-off of filling the consumer's windows with ads, bloat and Pavlovian purchase incentives. (Yes, I'm looking at you Booking.com)