Redesigning the country selector
baymard.com
baymard.com
For those of us in Canada, typing "ca" should probably rank countries that start with the "ca" prefix first, followed by countries that have a word that starts with "ca", finally followed by countries that just happen to contain "ca".
I don't see much use in showing "United States" as the first match for a user who has typed "c" and "a".
The same problem exists for the prefix: "uni". The list in that case is:
United States
United Kingdom
Réunion
Tanzania, United Republic of
Tunisia
United Arab Emirates
United States Minor Outlying IslandsThere is no reason why the auto-complete cannot have something like this:
<option value="DE">DE</option>
<option value="DE">Germany</option>
<option value="DE">Deutschland</option>Another is that that can be confusing. Suppose I want to enter a country whose spelling/native name I am not sure of, and after a few characters, four options remain, three of which are correct, but I do not know that. That can cause a needless google to find out, say, the difference between Liberia, Libya, and Libië.
Germany (Deutschland)
or if you're on a German site and type "germa", it should return Deutschland (Germany)
The default/preferred language should be the same as the language of the website, and it should tell the user why it's returning a value that's different than what they're typing.I would say: test it and see.
http://skookum.com/blog/re-thinking-the-state-dropdown-with-...
http://www.reddit.com/r/Design/comments/h37gb/rethinking_the...
My blog post links to jsbin sample source so feel free
to optimize it with all of your proposed fixes.
http://jsbin.com/oxifa3/18/Same for Russia - you get Aruba, Nauru and Burundi higher in the list.
So here is my non-PC suggestion: rate countries by population or GDP per capita, so countries where your customers are more likely to be from will be closer to the top and thus easily accessible with fewer keystrokes.
Instead, just order the matches like so:
1. Everything that matches at the first word 2. Everything that matches at the start of some word 3. Everything that matches at a non-start position within a word
Granted, in this scheme Cameroon will still show up before Canada, but you don't have to look anywhere near as hard to find it. I doubt anyone would notice/care about your "non-PC rating scheme", but I do know it would be a much bigger pain in the ass to maintain.
As for "too complicated" - I am not suggesting to extract GDP or population data in Javascript. But in static HTML on server side you may add additional "weight" attribute to each option, the way alternative spellings are added (look at the HTML source). And then you may manage these weights externally.
We're thinking of taking a similar approach to the way we display matching city names in an autocomplete input box. We have data on which matches are larger cities and we may hide some search results when there is a broad match based on the difference in size between the city matches.
For example, if you type in "Vancouver", there is a much higher likelihood you mean "Vancouver, BC" than "Vancouver, WA" due to the significant difference in the sizes of the cities and their "importance". In traditional lists, both would be listed with Vancouver, BC on top. We're thinking of hiding "Vancouver, WA" unless the user continues to refine their input to "Vancouver, W" then "Vancouver, WA" becomes the most relevant result.
Something similar could be applied here. Type in "Ca" and Canada should be the option shown until you add a "m" to make "Cam" then you will most likely show both Cambodia and Cameroon if their relative importance is too close to pick a clear top match.
Assuming the majority of your website's users come from a few countries, the simple solution is to have those countries on the top of the list, followed by the rest of the country in alphabetical order.
If Afghanistan is on the top of your list, you'll probably doing something wrong (unless you're UN or something agency like that).
I.e. instead of typing "can" for canada, would you type "ada" or something similarly fuzzy?
I personally type "can", and if Canada is not the first result I consider it's usability inferior to a standard drop-down.
This example may not be ideal since this country selection has both "Congo" and "Congo, Democratic Republic of" in its data set, but the principle can probably be applied elsewhere.
That is to say in your example, the parent wasn't questioning whether the code should support 'Congo', but whether it should support 'ong', for example.
Basically it should work like Command-T in Textmate (or the vim plugin based off of it). So if there's a Congo and a Republic of Congo in your potentials, then typing "con" should list Congo first as being a more likely result (even though in this case it may not be).
In this demo, when I type "ca" the first three results are "United States, American Samoa, and Antartica". I would argue that this is less intuitive to the user than a simple alphabetical dropdown.
You wouldn't start typing "ca" if you wanted the US, so it's not very useful to include it.
Type I, click Ireland (seven or so down).
This: Type I - Ireland not shown.
This is less usable to me than the usual country selector as a result.
Yes, I'm being nitpicky, but all the JS doesn't cover up that it's slower to find my country.
I'd actually much prefer a country selected that was based on geography with a Mac OS X dock-like magnification so I can choose my country easily.
Geopolitical sensitivity about precise borders forced Microsoft to switch off the region-highlighting feature.
(Info: http://blogs.msdn.com/b/oldnewthing/archive/2003/08/22/54679...)
Also, the user may not always be picking their own country and it may be unreasonable to ask the average user to find, say, San Marino on a world map. While you could of course restrict the use of a map-style picker to only the users-own cases, it would be nice to have a somewhat standard picker for all occasions.
That's fine if you're in a medium-sized country like the UK. But think of the consequences for the San Marinans, the Andorrans and the Liechtensteinians, who would have to go five levels of zoom in order just to find their country.
1. Yes, sites should remember your personal preferences that you've already set.
2. When setting those preferences, pre-filling based on ip would work in 99.9% of locations. A standard selector can handle everyone else.
In the first case, a country selector allows a user to select a country as a component of their shipping address, a user profile, etc. The input method described in the aforementioned article suits that case decently; however, it's not immediately intuitive that a user can access some of its touted conveniences (such as the selection of a country by its short name), and in most cases, a user will not frequently return to the same country input field (i.e. they'll set up a saved shipping address ONCE, or set their home country on a social profile ONCE) which removes the possible avenue of training the user to expect the pattern.
In this case, the best possible user experience can be given by leveraging geo-location (either by using the JS API, or any of the myriad IP-based solutions) and making intelligent suggestions to the user. For example: If I'm a user, and I am required to enter my shipping information (including country) on a checkout page, the page's best GUESS as to where I am should be displayed first, and the user should be allowed to change that assumption quickly. For example, you might show the user a drop-down box with the page's best guess selected by the default, surrounded by nearby countries (depending upon geo-location accuracy). Secondly, flag icons actually have quite a bit of value -- many people think visually, first, and will be looking for their flag's colors. Even if the icons are minuscule, they're still incredibly helpful.
The second use case which I want to present is that in which a company (such as Range Rover) presents a page allowing you to select which localized version of their site you wish to visit. In Range Rover's case, this is a massive list of countries, with their respective flags. Let's be honest: part of the reason this page exists for most companies is because they wish to demonstrate how significant their global reach is, or the expenditure required to translate the site. On Range Rover's site, the US (my homeland) is buried deep on the bottom left-hand side -- to make this more usable, they could leverage the same geo-location technique discussed above, and simply provide visual differentiation between my home country, and the other countries! Everyone's goals are achieved here; usability is increased, the "global" feeling is imparted, and the business douches who insisted upon a massive list of countries in the first place are sated!
The guys who wrote this article don't understand what's possible with current technology, and therefore cannot successfully design for it.
It seems to me they are just selling their $78 report on checkout usability.
Endless debate may follow this question: WHICH name should it use? If used in the USA, I'm expecting to settle on Germany and Ivory Coast for the above examples, but would be surprised if residents thereof didn't object. United States is obvious, but much of the world knows it as Les États-Unis (which was NOT recognized), and America is a very popular if unofficial/improper variant (which BTW drives some "hey, we're in America too!" Canadians batty). Methinks the final name used should be what citizens thereof call home, but understand it would confuse much of the general rabble.
And I agree that matching "us" to "Australia" at all is pointless.
After that just tally a daily table of "INSERT INTO country_order (count,country) FROM (SELECT count(*),country from users)" and then do: "SELECT country FROM (((SELECT TOP 10 count,country FROM country_order order by count) UNION (SELECT 0 as count, country from country_order)) GROUP BY country) ORDER BY sum(count), country"
That should produce a country listing where the TOP 10 countries are ordered by their use and the rest are sorted alphabetically. The SQL might not be perfect but you get the idea.
The linked implementation only lists Taiwan as "Taiwan, Province of China". I could see this being interpreted in many different ways, with either side being insulted. (Maybe that's best.)
It seems the dropdown here is just a harmless tech demo based on ISO, but this is such a common mistake. Even the rails/country_select thingie on GitHub has the same trap included. Use it and you are bound to make Taiwanese users unhappy, which already happened to Facebook, Twitter, Google Maps, ...
Then there is the expected rhythm of filling in the form as city,state,zip so putting zip first throws people off. I did a form once where we put the country above city/state/zip so we could do the wording for those more appropriately (e.g., switch to "postal code") and even that was annoying to many testers.
The only problem with this is that, while all ZIP codes have canonical names, some also have additional allowed names that users may identify closely with. So, if you auto-complete the canonical name, the user may think that you've made a mistake.
"The Postal Service designates one _default_ place name for each ZIP code... Additional place names may be recognized as _acceptable_ for a certain ZIP code."
This means that someone may continue to write their address as Smalltown, EG, 12345, when technically it is Bigtown, EG, 12345. Of course, this would not be the case with zip+4, which like the UK postal code system, identifies a much smaller grouping of addresses.
[1] http://en.wikipedia.org/wiki/ZIP_code#ZIP_codes_and_previous...
Of course, humans care about this stuff more than you can imagine. There was a minor kerfuffle in the Buffalo area a few years ago when a woman bought a house in Lancaster (an upscale suburb) only to find that the default placename for her zip code was Depew (a working-class suburb). She somehow managed to get someone at the newspaper to write a story about her plight, which included a note that her copy of Gourmet Magazine came late because she insisted on putting "Lancaster" in the city name. I'm not sure why that would affect anything unless she was also deliberately giving them the wrong zip code though.
In any standard dropdown list, just press a button and it scrolls to the first word starting with it. Press again, etc, and it cycles.
Fuzzy string search is a good algo and all, but does not make a good country selector. Everyone knows first letter of a country, so keep it simple. And, see SublimeText for an excellent example of fuzzy string searching.
We've now changed it so the first letters of the country name are ranked higher (e.g. typing "Ca" now returns "Canada" at the top instead of "American Samoa", and "In" returns "India" instead of "United States", and so on) as many of you have suggested.
Thanks for the feedback.
PS: The Smashing Magazine article describing the handling of typos, multiple spelling sequences, synonyms and prioritization can be found here: http://uxdesign.smashingmagazine.com/2011/11/10/redesigning-...
When typing "america ..." the United States does not show up in the list.
Yet "United States of America" is the, or one of the official/common names of the United States, according to https://en.wikipedia.org/wiki/United_states and https://www.cia.gov/library/publications/the-world-factbook/...
I like the interface, but it has a few quirks as pointed out in the other comments, and the database behind it could probably use some additions.
Also, if it's for shipping, you can often work out the country by the address, and perhaps just show the matches.
E.g. Do you mean Someplace, X or Someplace Y in a drop down.
The article often gets omitted in drop down menus so people can find it if they search by alphabet (and advanced users can press the first character to jump to it quickly). With this plugin that would no longer be needed.
This totally breaks that expected behavior for me. Maybe it should, maybe "it's time" for that.
I suppose I can get similar behavior with this by typing "ada".
I think this could be easily fixed by having the drop down menu pop up when you click in the input field (before you have typed anything).
http://harvesthq.github.com/chosen/
I'm sorry but progressive enhancement of a select tag into an autocomplete element isn't quite news worthy.
Type: united states
Leave the field, it works
Type: united states of america
Leave the field, it resets
on the technical side, it should just match the starting letters, instead of all letters in the name
It's OK though -- most country selectors include BV, since they lazily use ISO3166-1 as a canonical list of countries when in fact it just defines country codes.
When you embark on a redesign, it's usually a good idea to start by revisiting your content.
Sorry, you failed terribly. Feel free to try again.