While this has a nice UI, it suffers from a ranking system that fails to weight prefixes correctly.
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 Islands
That seams as a minor mistake compared to not be able to type the name of the country in my native language. I guess that is not so obvious to the native English speaking users but it's the required feature if you are considering usability improvement as a goal of redesign.
A reason for not doing that is that it looks ugly to show multiple options for the same country.
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ë.
It would be confusing to the user to give three separate options for the same country and expect them to know they are the same. What it should do is if you type "deuts", it should return
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.
That's not good enough to explain why United Kingdom (or "the united kingdom of greAt britAin And northern ireland") sits up near the top when you type in 'A'. Who the hell formally refers to the UK with any word starting with 'A'? Anyone claiming to be from 'Albion' in a web form is just intentionally being difficult...
Precisely, I can't think of any situation where a user would search for a substring of a single word in the country name. If there is some edge-case where the first letter or so can be omitted that should be handled with the alternate-spellings feature.
Perhaps adding a geo-ip look up to help weight the results would make this better? None the less this is a huge improvement then a drop-down with every known country.
Double Edged Sword. While many times I am interested in the country I am in, in many cases, I'm getting info for the next country I am going to. It's frustrating to have to change a default box from where I am to where I want to go, or even not notice that it's set wrong. The real question is: how many people do I annoy compared to how many people are helped? If I help most people, and don't annoy my best customers, then that's a great idea. If my site is used by folks to find out info about countries other than their own, then it might turn out to be a bust.
It depends on your OS. On some you can type and have it pick the best match, on others 'C' goes to the first C, then 'A' would go to the first A. C+C goes to the second C.
Can anyone explain why 'United States' could possibly be an autocomplete result for 'CA'? I am staring at United States and just can't see a 'C' anywhere... have I totally lost it?
Funny enough, I already proposed the same problem and solution with a blog post and sample code for "Re-thinking the State Dropdown with Autocompletion" back in May. Same issues applied, but there was at least some feedback on reddit and optional changes.
My main complaint about old country pickers and this one is non-prioritization of countries in the list. Yes, I understand that this may be a sensitive issue, but how much likely your customer is going to be from Canada than from Cameroon. Or if I start typing 'CA' in this selector, I get American Samoa and Antarctica before Canada! Let alone my old acquaintances Cambodia and Cameroon.
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.
I think that's making it too hard. Where is this information coming from? How do you update it?
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.
Compromise is the key. Use the idea, but keep it simple. Just pick a fixed list of relatively more likely countries, say the top 20 as defined by the G20. This extends and improves the traditional country selector which gives special status to 1 country (the USA) rather than 20. If you think a list of 20 needs to be more dynamic, why is it okay for the legacy list of 1 to be static ?
This is a good suggestion - I believe prefix match should weigh more than partial infix match.
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.
I believe prefix match should weigh more than infix match... except for countries that start with an article (The Philippines, The Netherlands) where infix match works better. The Netherlands is now number 11 on the list after typing "Ne".
Population/GDP would be a good starting point, then it'd be nice to adjust weighting automatically over time based on where the site's visitors are coming from (geolocation and previous choices).
Isn't that why we're here? I see no reason why this isn't possible (and as fast and scalable as it might be imagined) given the right serendipity of technology. Now that I think about it, weighting it for a set of countries say on a scale of 0-3 should be fairly easy and would probably fit into the :sort option provided after some tweaking.
I tend to agree with the sentiment that prioritization makes the list work better for the 80% of users but may make it seem less intuitive for the 20% that don't live in your prioritized group.
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.
I might be wrong, but I think the only place that suggestion would be considered "non-PC" is North America.
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).
It may not be common, but I don't think it is an unreasonable thing to expect. Think of a country such as the Democratic Republic of Congo -- I'm not entirely certain, but I'd imagine it is common for someone to simply start typing "Congo" while still expecting the result to be available.
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.
I think the parent was more interested in whether someone would use a string of letters within a word in the name, as opposed to just starting a word somewhere in the name.
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.
I agree. Let me put it a little differently. I think that the order of the letters and how soon they appear in the list of potentials should impact the ranking of the results.
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.
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.
with a Mac OS X dock-like magnification so I can choose my country easily
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.
Ta-da-m! This is the first question any usability/UI/whatever designer should ask: "Can software do this for users automatically?". Only then the designer should think of the visual appearence and interaction.
Doesn't work if you're traveling abroad. I hate getting country-specific versions of a site even after logging in with my US credentials. It should remember that I'm from the US.
Throwing an autocomplete at something is NOT always an upgrade. I've spent quite a bit of time thinking about country selectors, and I'll present my solution for two separate use cases here.
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.
Yes, glad to see at least a fragment of multiple naming is recognized. Started entering Deutschland and it settled on Germany. Entering Ivory Coast gave Côte d'Ivoire. The same should happen for all countries where the country's name for itself differs from a popular version.
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.
Why don't country selectors use the free IP databases to pre-fill the country? It would reduce 90% of user input.
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.)
If 'Hong Kong' can stand on its own in the ISO list, I really can't see the PRC being insulted by calling 'Taiwan', well, 'Taiwan'.
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, ...
The PRC claims Taiwan as an integral part of China. But Hong Kong is a 'special administrative region', i.e. an autonomous jurisdiction for which China essentially took over as the colonial power.
Most likely because they got the country information from the ISO standards (or from some other source rooted in those standards), which list the country name that way.
On a similar note, I've always found it kind of amusing/frustrating that forms in the US make you fill out city, state, and zip code, when in fact the zip code indicates a specific city and state. I realize that's a huge database of geolocation data to keep as part of the program, but I wonder if there could be some kind of lookup that goes on behind the scenes and fills in the city and state if the response is quick enough (and allows the user to fill it in manually if it doesn't).
Zip codes can and do cross both state and city boundaries in some cases. That's not true of zip+4 but most people don't know their extra 4 digits.
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 database is not huge at all, fewer than 10k entries, each of which is a key-value pair. It's bigger than I'd want to include in a client-side Javascript file, but it's certainly small enough to keep on your server.
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.
In the UK it's quite common for forms to ask you to type in your postcode and they then ask you to select your address. Because the postcode is very dense (your house number/postcode is unique), this makes address entry very easy.
Until you live at an address not in most people's postcode database. If you're lucky, you get to enter your address in manually. If you're unlucky, you're up for a phone call or total rejection - a few times I've had to collect parcels from neighbours.
I had that experience recently; being told on the phone to a utility company "Sorry, but that address does not exist." to which I replied "I'm sure it does because I'm standing in it right now."
Rather than trying to convince them, make it into a Data Protection issue. If a company stores personal information on you, and you tell them it's wrong, then they legally have to correct it. So just tell them (in writing) that your address is X, Y, Z and if they don't change it, then they are breaking the law.
The mapping zip codes to city is not strictly 1:1. I don't have a better source for this, but the description in Wikipedia states:
"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.
Hmm, but if I understand correctly how this all works, even if you vote and pay taxes in Smalltown, if Bigtown is the default placename for 12345, the post office will still happily deliver mail to your address even if the envelope says "Bigtown, EG 12345" on it.
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.
Sorry to say - but it sucks. Completely irrelevant results, strange sort order.
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.
Update 13 Nov:
As many commenters have noted the sorting logic on the original demo wasn't all that "logical".
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.
Nice one. Scrolling down the endless list of options in a form is pretty cumbersome. I like the fact that you can type in common abbreviations for countries as well ('de' for Germany, etc).
nice idea, but the graceful degradation also needs extra work if usability is the goal. On Opera Mini, for example, it's a text box. The javascript will round-trip to the server, taking several seconds. I'd much much prefer the dropdown. Out of context, i'd not even know what to type into what appears to be just a text field. You could consider this a usability flaw in Opera Mini, but it means a usage drop for many mobile browsers for sure.
I like this. However, I'm wondering if including all the common and local names of a country would become too cumbersome during implementation over time.
While it's better than traditional country selector, I think there are some possible improvements here. I started typing Ger (as in Germany), and first suggestion was Algeria - wouldn't it better to sort them by popularity/language version of my browser/ip geolocalization, instead of repeating old mistake of putting stuff in alphabetic order?
I still don't see how this is any more useful than just using the default auto-complete with your standard country list. The data I've measured shows that selecting your country is not often a pain point.
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.
A minor improvement suggestion: countries can now start with their proper article like "The Philippines" and "The Netherlands".
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.
Well, I don't think this "works". We are conditioned to think that lists are sorted in alphabetical order. When I key in first few letters of a country, I expect to jump to that country's name directly. But with this redesign, I ended up typing more letters to "fine tune" auto-complete's suggestion!
Most Canadians I know are used to hitting 'c' three times. It skips you past Cameroon and Cambodia and selects Canada. I suspect people from other countries behave similarly?
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".
Something that always bothers me about "Select redesigns" is that scrolling does not work like it should. If you move your mouse outside of the div/whatever, it'll scroll the page instead of the select. A regular select will keep scrolling until it reaches the end, then it'll scroll the page.
How about popping up a world map, letting the user tap the country, and if that's unclear give a list of local countries? Or putting a map button next to the field for such augmentation of typed entries?
Exactly my thought. Chosen has the advantage of working moo tools, jquery or prototype. There's also a drupal plugin. It doesn't have alternate spellings support, but that should be really simple to add.
Whilst some country endonyms appear to work (Deutchland, Hrvatska, Suomi), non-latin endonyms (日本,Россия) fail, some even when romanised. This isn't an easy thing to solve when many countries have multiple de facto or de jure languages.
A different approach I've tried before is to perform a lookup on the visitor's IP address, and then to auto-select the country that we think they might be from. If we get it wrong, they can always select another country the usual way.
A few issues. Typing "ire" lists Ireland last with 2 entries not even starting with "ire" above it. That's kind of annoying. More importantly "Ireland" refers to the island, as opposed to the country which is the Republic of Ireland.
Feedback I didn't find in the comments: when you blur the field without actually picking something from the list, it resets even if there is only one option. Examples:
I want someone to take this alternative values approach to the occupation selector. They seem to vary just enough that you have to read the full list to find the one that fits best.
In addition to fixing the sorting as other people have mentioned here, it would be great if you made the return and tab keys choose the topmost completion.
you have to keep user experience in mind...everyone is used to scrolling down to find the country...if you throw this in, half your users will get frustrated not knowing what to do.
on the technical side, it should just match the starting letters, instead of all letters in the name
Not to mention Bouvet Island -- an uninhabited volcano in the Antarctic covered by glaciers. If you try to land there, the Norwegian navy will fire on you as it's a "nature preserve".
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.
Lolz. They implemented a simple autocomplete plugin and call it a redesign? It's not necessarily faster for a mouse user because it requires keyboard entry.
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: