I've read somewhere (can't remember/find where) an article about web usability describing when to use drop downs and when to use autocomplete fields.
Basically, the article says that the human brain cannot store more then the last five options presented to choose.
For example, in a profile form, where there is your current occupation, and the system gives you a bunch of options, when you read the sixth options, your brain can't remember the first one anymore. This example is a great place to use an autocomplete field, where the user types something that he thinks that would be his occupation and then select the better from the few options filtered.
I would like to hear your opinion about this subject.
When should I use a drop-down and when I should use a Autocomplete field?
For a limited list, don't use an autocomplete edit box or combobox, but use a listbox where all values are visible all at once. For limited lists, especially with static content of up to about 8 items, this takes up real estate, but presents the user with a better immediate overview.
For less than 5 items a radiogroup or checkbox group (multiple selections) may also be better.
For lists whose content is dynamic, like a list of contacts, a (scrolling) listbox or combobox are appropriate because you never know how many items will be in the list. To keep it manageable, you will need to allow for some kind of filtering and/or autocomplete.
Autocomplete usually suffers from the fact that what the users types needs to match a string from the beginning. I hate those except for when they are used to complete a value based on what I typed in that (type of) field before. E.g. what browsers nowadays offer when filling out online forms.
Allowing a user to start typing in a combobox usually suffers the same drawback. But admittedly it doesn't need to if the filtering is based on "like %abc%" instead of "starts with abc"
When dealing with lists that can have many similar items, I really like the way GMail's "To" field handles it. You start typing any part of someone's name or e-mail address and GMail will drop down a list presenting all the contacts whose name or e-mail address contains the characters you have typed so far anywhere within them. Using the up and down keys changes the selection in the dropped down list (without affecting what you have typed) and pressing enter adds the currently selected item to the "To" field. By far the best user experience I have had so far when having to select something from a list.
Haven't found any components yet that can do this, but it's not too hard to "fake" by combining an edit box and a listbox that drops down when you start typing and has its contents is filtered based on what has been typed so far.
I would use 2 criteria,
1) How long is the list, if the list contains 5 elements you better use a combobox as it will be easier for the user (better UX)
2) In case the list is long, how easy for the user to remember the prefix of what he/she is looking for... if it's not easy, using autocomplete is irrelevant..
I'd say it depends on the diversity in the list, and the familiarity with the list items.
If for example the list contained over 5 car brands (list items I'm familiar with), no problem.
If on the other hand the list has over 5 last names, it could take me some more time before I'd make a selection.
You should probably just try out both options and trust your gut on which you find easier to use.
Here's the opposite approach:
The worst time to use an auto-complete box is when you have a finite and relatively small set of options, and the user doesn't know the range of valid options. For example, if you're selling used cars and you have a mixed bag of brands, simply listing the brands in a combobox is more efficient and easier to browse than an auto-complete method.
Being able to remember the last 5 options is most likely irrelevant unless you have a giant list of options and are requiring the user to select the most relevant item.
An alternative approach is to use both. I believe Dojo has a widget that acts as both a combobox and an auto-complete field. You can either choose to start typing and it will narrow down the possible options, or you can interact with it with your mouse and browse it like a combobox.
I usually look at how big the list is going to be. If there are going to be more than 15 options then it just seems easier to find if they can just start typing.
The other circumstance for me is when there is an other option and they can free type it. This essentially eliminates the need for two controls since you can combine in one.
The main difference has nothing to do with usability but more to do with what defines the acceptable inputs.
You normally use a ComboBox when you have a predefined list of acceptable inputs (e.g. an Enum or list of occupations).
An auto-complete field is best used when there are many known inputs BUT custom input is accepted as well. The user will become frustrated if they type "Programmer" in as their occupation but it wasn't one of the pre-defined, acceptable inputs, and they are given a message that their input is not valid.
Keep in mind that ComboBoxes do allow you to type in them to select the first matching option. Some types of ComboBoxes (depending on the UI framework you are using) even allow free-form text fields at the top or side of the field to search or add to the list.
Of coarse the best way to determine what YOUR user will prefer is testing: A/B, field, user, etc.
Hope this helps you solve your dilemma!
Related
I'm implementing a native iOS application, which provides a feature to search for articles using keywords and several search filters such as author, year, publisher etc. Each of these search filters has several options such as 2014, 2013, and 2012 for the year filter, or Academe Research Journals, Annex Publishers, and Elmer Press for the publisher filter. Each of these options has a BOOL stating whether the option is selected or not. I need an object that wraps the search keywords and search filters so that I can send it to the server, which is responsible for the search operation.
Which data structure should I use to represent these search filters in the wrapper class?
Something like XML comes to mind:
<year>2014</year>
<publisher>Annex Publishers</publisher>
Although I find it rather bulky. I'd probably prefer something like:
year=2014|publisher=Annex Publishers
You'll need to escape = and | appearing in the field names or values, but this is easy to do.
This could just be a single string sent across.
In terms of actual data structures, you could have a map of field name to value, only containing entries where the option is selected. Or you could have a class containing pointers / references for each field, set to null if the option is not selected.
Another totally different consideration is to use an enumerated type, i.e. mapping each possible value to an integer, typically resulting in less memory used and faster (and possibly more robust) code, depending on how exactly this is done.
You could map it as follows, for example:
Academe Research Journals 0
Annex Publishers 1
Elmer Press 2
Then, rather than sending "Annex Publishers" as publisher, you could just send 1.
year=2014|publisher=1
The extension for multiple possible values for a field can be done in various ways, but it's fairly easy to do:
<year>2014</year>
<year>2013</year>
<publisher>Annex Publishers</publisher>
Or:
year=2014,2013|publisher=Annex Publishers
Our application displays tons of valuable information to our users in a table. We have a filtering capablity that is based on boolean/logic searches. Even after coaching, users still tend to not understand how to use filters because AND OR > >= etc are foreign to them. This filter is easy for programmers since it is easily translated into code. Any examples on how this can be made more user-friendly and less prone to error?
In the past, when I needed to solve this problem, I presented the users with a list of items (in one or more columns), and gave them a single text box to type text into. I would then match the text against the text in the columns, and collapse the list (removing records that do not match) as they type.
This approach reminds users of Google. Everyone knows how to Google.
If you don't like the idea of presenting a large list of all items initially, you can show an empty results pane first, and display results after a search is typed in.
Convert operators to plain English text and ask them to select from it.
For eg: To
Show me all Books whose author is [text field] and the price is [less than/greater than] [text field]
[less than/greater than] is a dropdown list
[text field] is an input box
The resulting text after the user has filled in all the fields should result in plain simple English
Eg: Show me all books whose author is Stephen King and the price is less than 10 $
I used this in an app of mine when I used to freelance and the users loved it.
Using some nifty UI programming you can give options to expand the filter to n levels.
In web applications, telerik had a good idea with their grid, you should be able to do that in desktop applications too.
you can provide some preset filters for the most common queries to that table - if that's possible with the application you are using
you can provide a "count instead of display" mechanism so the user sees how many rows he/she will potentially retrieve
you can provide them a Wiki page with some examples online
you can give them a QBE tool
hope that helps
good luck MikeD
In my experience you are simply not going to get end users to understand the difference between AND and OR conditions. Therefore I build my filters so that ANDing or ORing is built in. In general, my logic is as follows:
Criteria for different fields are ANDed together to restrict results.
Multiple values for the same field are effectively ORed together and then ANDed onto the criteria for other fields. I generally detect input into a single field of comma-separated lists (translated to IN ()), dash-separated ranges (translated to BETWEEN), wildcard values (translated to LIKE), and any combination (for example Customer ID: 1-10, 50, 52).
I find that most users intuitively understand this system.
Of course, from time to time a different interface with some degree of ORing is required and in those cases I generally have a section of the search user interface in a panel or group box labelled "Any of these is true".
I have recently been working on this problem. My solution is to be more descriptive, to use words instead of symbols and to change the words where it allows for a more readable layout. To illustrate, imagine the filter expression:
Breed == "Spaniel" AND (Age == 2 OR Colour == "White")
Certain linear Query builders might write this:
( And/Or Field Operator Value
[ ] [Breed] [=] [Spaniel]
[1] [AND] [Age] [=] [2]
[1] [OR] [Colour] [=] [White]
Or a hierarchical one may display this as:
AND
[Breed] [Is Equal To] [Spaniel]
OR
[Age] [Is Equal To] [Spaniel]
[Colour] [Is Equal To] [White]
Both of which might be readable to a developer but not so readable to the layperson.
My solution is more like:
Show ALL records where
[Breed] [Is Equal To] [Spaniel]
Show ANY records where
[Age] [Is Equal To] [Spaniel]
[Colour] [Is Equal To] [White]
So borrowing from the hierarchical approach but changing the AND and OR to an ALL or ANY. This means it can be read from top to bottom a little more easily.
I think Django's built-in admin interface has a very intuitive UI for filters.
There's a simple screenshot in the docs but there's a lot more you can do, especially when filtering on dates.
You might want to take a closer look at Django's admin interface to see if you can apply some of their tricks to your case.
I would think something similar to MS Access Query generator. You may also want to have good context sensitive help system that will guide first time users.
Theresa Neil illustrated several approaches for building complex rule interfaces (AKA predicate clauses) in the iTunes Solves the Nested Clause Dillema post. Some good examples there. I really like the way Apple does it in iTunes (although, I don't use iTunes).
First of all, I finally made this a wiki, but I believe a "simple," straightforward answer is highly desirable, especially since the result would define a unified IDE behavior for everyone. More on the simple later.
In the past, I've blogged about what it means to have a well-behaved member selection drop down. If you haven't read it, do so now. :)
Visual Studio 2010 adds new features to the IntelliSense selection process that makes things ... not so easy. I believe there's great power we can harness from these features, but without a clean set of governing rules it's going to be very difficult.
Before you answer, remember this: The rules should allow someone "in tune" with the system to take advantage of the IntelliSense power with fewer keystrokes and less time than other solutions provide. This is not just about what you're used to - If you use a system as long and frequently as I do, relearning the patterns is trivial next to the time it saves to have a great algorithm behind it.
Here are the controllable axes:
Filtering: A "full" list contains every identifier or keyword allowed at the current location, without regard for the partially typed text the cursor is within.
Sorting: We (at least Visual Studio users) are used to the member selection drop down being sorted in alphabetical order. Other possibilities are partial sorting by some notion "relevance," etc.
Selection: Based on the currently typed text, we have the ability to select one item as the "best match." Selection states are:
No item selected
Passive selection: one item outlined, but pressing ., <space> or similar won't fill it in without using an arrow key to make it:
Active selection: one item selected, and unless Esc or an arrow key is pressed, a . or <space>, etc will auto-complete the item.
My previous set of rules restricted the manipulation to the selection axis. They took into account:
Characters typed as matched against list items with a StartsWith operation (prefix matching), with variants for whether the match was case-sensitive.
Previous completions that started with the same set of characters.
The following are additionally available and potentially useful, but not all have to be used:
CamelCase matches or underscore_separation ("us"): Long, expressive identifiers? Not a problem.
Substring matches: long prefixes hindering your selection speed? Not a problem.
Information available in the summary text, where available: I lean against this but I must admit it's come in handy in the Firefox address bar, so you never know.
The rules you write should address the axes (in bold above) in order. In my previous posts on the subject, the rules were very simple, but the additional considerations will likely make this a bit more complicated.
Filtering
Sorting
Selection
Just one addition or remark ...
IntelliSense should adapt to the context. In the case of Visual Studio, places where only subtypes of a specific type or interface may be used, the dropdown list should filter by these.
IList list = new (Drop down all the types implementing IList) - not all possible types!
Very simple question: should a dropdown list be used to populate state abbreviations? From my experience, I think most e-commerce sites do this so I would expect that it's acceptable. However, Jakob Nielsen has something to say about this.
I think I disagree; I use the tab key then type the first letter of my state. Heck, even if it wasn't the first entry, I've done this enough times, I would hit the letter repeatedly and get to what I need. I never need the scroll wheel or mouse.
Is there any additional concrete guidance out there on this particular question?
I think this will become less of an issue now that most modern browsers scroll the drop down lists based on each consecutive letter you type, not just reading the first letter as they once did. So, If you type N-Y, the drop down list will scroll directly to NY and you do not have to hit N a bunch of times.
Since a state is a two letter abbreviation, I wouldn't put a drop downlist, I would put a textbox, but I would validate it using AJAX or Javascript to warn the user about an error, right after he entered something wrong.
DropDown / Auto-completion (in my opinion) is useful when the data to enter is longer / more error-prone.
If you insist on using auto-completion or dropdown, you should put long state names, not just the abbrev.
I don't know about concrete guidance, but one alternative I would consider is using an autocomplete text box that forces you to choose from one of the available choices. I agree that a 50-item drop down list is too long and using autocomplete with enforced choice accomplishes the same purpose -- consistent data -- and has the advantage that it is much easier for the user to navigate. If you don't want to limit the choices to just US states you could drop the enforced choice and just let the autocomplete work as a suggestion with the user being able to enter free-form input.
EDIT: As #Martin suggests, I would probably have the autocomplete show the full state name, even if it only entered the abbreviation. This would solve issues of people getting the abbreviation wrong as well, though you could do the same thing in a drop down -- display the name with the abbreviation as the value.
I was going to post NYSystemsAnalyst's answer, but he beat me. I will instead add a caveat... If you use a dropdown list, it must be complete. Do not forget the obvious DC, or the less common but plausible PR or AE/AA/AP, or the rather improbable but still valid AS, FM, MH, MP, PW, and VI.
The official list
I think it depends on if you are asking a user to enter their own address or someone else's address (ship to address). Everyone knows their own state abbreviation, but may know all the state abbreviations.
So for entering your own address a textbox is the quickest and easiest way, but if you are asking the user to potentially enter someone else's address a drop down is probably best.
Of course, if you site has a combination of both types of address, you want your UI to be consistent and use the drop down for both. Also, if you are using a drop down, I would suggest using the state abbreviation and name (AZ - Arizona) when the drop down is expanded (but just show the abbreviation when it is collapsed).
I'm willing to bet that half the users of online e-commerce sites don't know the abbreviations for the states. Think if you're shipping a gift to someone and you can't remember whether its MS, MO or MI. Dropdowns are fine.
I've never had an issue with state drop down boxes (and this is from someone routinely at the bottom in West Virginia). I've gotten into the habit of just tabbing and pressing W and then it will either recognize the "E" and give me the correct state, or it will not recognize the "E" and then I have to hit the down key once or twice (depending on sort order) to get the proper state.
So all in all I am looking at 5 key presses max to get to my state. I don't think it's that bad.
How about a textbox with validation, and a drop-down list if the state abbreviation is invalid?
I've long thought (but never practiced for some reason) that a dropdown menu that is dynamically generated and only contains one item, should automatically select that item. This would opposed to the typical approach that I've observed where a blank entry is made at the top and you still have to interact with the menu to make the single available selection.
An example is when I login to my online banking and select "View Paper Statements". I've only got one account so the next step in the process is to present me with a dropdown where I have to select that single account to proceed. In this case, by implementing the solution above, it would take one less click to select the account and proceed to viewing it. Even better in this case would be to eliminate the dropdown menu step altogether and go right to the statement.
Can you think of a case where auto-select of a single item would produce undesirable results?
Can you think of a case where auto-select of a single item would produce undesirable results?
Yes - any case where the user has the option not to select any option.
In your bank account example, pre-selecting the only value makes sense. But if you have e.g. some kind of form where users can provide voluntary information, they will need the possiblity to leave that field blank or otherwise give a possible incorrect answer.
So it really should depend on the nature of the data in that dropdown whether pre-selection is a good idea or not.
I completely agree, in the case you describe. But there are times where you want to force the user to make a selection actively -- e.g., when the value of the field is somehow optional or additive.
In your case, without selecting an account, there's probably no useful way to proceed, so automatic selection does make sense. But for example, an application I'm working on allows the user to specify a number of descriptive fields (movie metadata, basically -- title, release year, genre, etc.), many of which are optional, and some of them are represented by drop-down menus. Allowing the user to leave the default selection blank lets him tell us, effectively, "I don't want to use this field," so we leave it blank, and the data remains clean.
Just one example, although you're right -- in your case, I can see how that'd be annoying. :)
If there is truly only one possibility you shouldn't ask a user to decide between Option A. (Bad grammar to illustrate the point)
If the field can be left blank, it's not an option with a single answer. Instead you have a choice between Option A "meaningful data" and Option B "".
Iif list has blank option but the form does not allow that to be blank, it's a choice between Option A. (Bad grammar to illustrate the point)
Sometimes you want the user to explicitly select an option, even when it's the only option. If the option is selected automatically, the user may never even realise it, even though they may not be happy with the result.
For example, I'm reviewing my savings account on my internet bank site. Then I go to set up a payment. As it happens, I'm not allowed to make payments from my savings account, so the payment form automatically selects my only other account. If I don't notice this then I will end up making the payment from my other account when I was expecting to use my savings account. If I had known, I wouldn't have made the payment at all.
Perhaps this is slightly contrived. But unless you can be certain that the user will be happy with the (only) choice, you should ensure that they choose it explicitly.
I agree. If there's only one item in the dropdown and it's required that the user select something, then just default to the single item. I can't think of any negative effects of this (but I'm certainly not a UI expert)
What I like to do in this instance depends on a few factors.
If the dropdown is a required field and ends up with only one item due to dynamic generation, I try to avoid displaying it as a dropdown entirely. I end up showing it as an uneditable text field instead (or not displaying it at all if it isn't necessary). Why make it even look like it's a choice when it isn't?
If the dropdown is not required, then it makes total sense to display a blank choice in addition to the single value.
If it's REQ and there's a single record/value .. I'd try and change the control to a Display field rather than the Drop Down.