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.
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).
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.
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.
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.
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).
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 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.
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 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.
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?
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
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.
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...
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.
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.
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.
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.
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.)
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.
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.
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.
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 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.
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".
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 ?
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).
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.
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.
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.
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.
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.
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!
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.
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.
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.
135 comments
[ 2.7 ms ] story [ 249 ms ] threadEndless 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.
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.
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.
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.
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.
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 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.
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:
I would say: test it and see.
There is no reason why the auto-complete cannot have something like this:
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ë.
http://skookum.com/blog/re-thinking-the-state-dropdown-with-...
http://www.reddit.com/r/Design/comments/h37gb/rethinking_the...
http://jsbin.com/oxifa3/18/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, ...
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.
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).
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.
http://en.wikipedia.org/wiki/ISO_3166-1
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.
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.
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.
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).
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.
http://harvesthq.github.com/chosen/
I'm sorry but progressive enhancement of a select tag into an autocomplete element isn't quite news worthy.
And I agree that matching "us" to "Australia" at all is pointless.