The audience is a mixture of European and American. What's the standard in this case, Metric or Imperial?
I will allow users to switch.
Tell me more
×
User Experience Stack Exchange is a question and answer site for
user experience researchers and experts. It's 100% free, no registration required.
|
|
|||||||||
|
|
If it's a desktop application, then you'll be able to pick up the units settings from the OS. These are set at install time, so require no user interaction, which is perfect. If it's a webapp you can get the language information from the language-accept header which will generally tell you the country as well as the language. For example language-accept header with en/US would clearly indicate American. I'm not sure whether a Spanish speaking American would show up as es/US, but I imagine they might. So you might want to accept anything ending /US as indicating American. Pretty much anything else would be metric. (The UK is a special case, where the younger generation (<40ish) use metric, but the older use imperial (>50). I'd go with metric unless its a mapping app, in which case I'd go imperial!). Most of the time these will give you an accurate answer, but occasionally you might find you can't get meaningful information, in which case I'd default either to whichever is the larger fraction of your audience. The logic here is that picking the larger audience you annoy the fewest people. But if your audiences are roughly the same same size and you have a brand that is heavily associated with either the US or Europe go with whatever is the standard there. The logic here is that Americans will be less surprised to see metres in the interface if they perceive your company as European, and visa versa. Clearly the switch you're adding is important though. These two fallbacks should not typically be needed though, the locale should be available in almost all cases. If it's a web app you might want to log locales for a while to check that though. |
|||||
|
|
If it's a desktop app, Peter is right: grab it from the OS preferences. However, if it's a webapp, don't depend on language. Depend on GeoIP solutions instead. While the Geolocation API would be quite heavyweight and unreliable on a desktop browser, also interrupting user flow ("This application wants to know your location. Allow/Deny?"), GeoIP is fine. IPs are hopelessly inadequate to get actual location information, but they're assigned on a per-continent basis, so for that it's safe. As for roaming (US users traveling abroad), iOS maps switches to yards and miles if I go to the UK (even the old style maps). In some cases, this is benefical, as road signs will be in miles, and locals will speak about yards, for me, it's disturbing as I have no solid idea on what a 'yard' means, I'm a continental European. I'd grab the first setting from IP, store it in a cookie, and if the user changes this setting anytime later, store it in a cookie as well: this way, the unit is felt "persistent", as it is changed only on user request - if a US resident traveling abroad switches to metric, and forgets to switch back to imperial coming home, I guess they'll know the reason. |
|||||||||||||||
|
|
If this is a webapp, try detecting locale. If a solution for this does not exist, I'd try detecting user location and basing it on that. (Geolocation api) |
|||||
|
