9 ms·

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, b

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.

maxwell 15y ago
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).
- fmota 15y ago
  This is way too complicated.
  - marquis 15y ago
    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.
- megablast 15y ago
  Cool, go for it.
awj 15y ago
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.
- maaku 15y ago
  Doesn't mean you can't sub-sort within those categories.
- mynegation 15y ago
  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.
  - speleding 15y ago
    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".
- billforsternz 15y ago
  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 ?
nandemo 15y ago
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).
calbear81 15y ago
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.
fedd 15y ago
when I enter russ it shows me Brunei Darussalam first. I guess it's politics! ;)

maxwell 15y ago

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).

fmota 15y ago
This is way too complicated.
- marquis 15y ago
  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.
megablast 15y ago
Cool, go for it.

awj 15y ago

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.

maaku 15y ago
Doesn't mean you can't sub-sort within those categories.
mynegation 15y ago
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.
- speleding 15y ago
  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".
billforsternz 15y ago
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 ?

nandemo 15y ago

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).

calbear81 15y ago

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.

fedd 15y ago

when I enter russ it shows me Brunei Darussalam first. I guess it's politics! ;)