Removing Interface ElementsShould You Ask The User Or Their Browser?

Advertisement

The history of the Internet has been a steady march towards websites that are richer, bigger and more interactive. As websites have become more robust, we — as designers and developers — have often placed the burden on our users to make more decisions, each of which distracts them from their wants and needs.

8348989885_e6ed96e478 (1)1
Image source: Johan Larsson2.

However, by using a combination of technical solutions and some careful decision-making on our part, we can often remove interface barriers for our users. It’s common for websites to automatically determine whether the user is on a mobile device (although responsive design has made this less relevant in many cases, and browser detection techniques are not without criticism3).

More often than not, though, we’re still asking users to provide their localization information: their language, timezone and country. We can use a combination of techniques to minimize that burden on the user, too. Let’s dig into our bag of tricks and look at how we can handle localization without interrupting the user’s focus.

Language

The most common way of detecting the user’s language is with the Accept-Language HTTP header. There is also a JavaScript property, window.navigator.language, which serves a similar purpose, but may be less reliable — particularly cross-browser. Both methods rely on the user having their preferred language set in their operating system, so always provide an option for users to select an alternate language.

Country or Region

A lot of attention has been paid to HTML5 geolocation4 recently, and it’s a great thing to have in our tool belt. It’s a generally reliable way to get the user’s current location — provided they are using a modern browser and opt in to providing it to you.

If you’re simply looking for what country a user is located in or what continent they’re on, IP-based geolocation services such as MaxMind5 and IpInfoDB6 (among many others) are a great bet. These solutions are implemented server-side, which may be preferable because the user isn’t required to load up a page and opt in to HTML5 geolocation only to be forwarded on to a new page.

Although IP-based geolocation still generally applies to mobile devices, HTML5 geolocation is widely available on these devices, and may be more reliable — particularly if the user is roaming.

Timezone

JavaScript provides us with Date.getTimezoneOffset(), which returns the difference between UTC and the user’s local time in minutes. However, there are some edge cases to handle (particularly around Daylight Savings Time), so I strongly recommend using a library such as jsTimezoneDetect7 for reliability and ease of use.

Should We Ask The User?

When deciding whether I need a user-facing interface element for a particular setting, I ask myself three questions:

  1. Can I make a confident determination using a technical solution?
  2. Can I decide on an intelligent default?
  3. What are the consequences of guessing wrong?

That last consideration is the most important. If we guess the wrong timezone for a user, is that worse than asking them up front for that information? It depends.

If you’re using the timezone to send a daily email digest, the consequences of being incorrect are probably minor, and it’s likely a worthwhile trade-off. What if we were using the timezone to set the period of time when a user could bid on an item? That’s a different story entirely; the implications of getting that wrong are far more dire, and we shouldn’t rely on behind-the-scenes magic.

Whenever you’re making any assumption on behalf of the user, consider whether it makes sense to provide a way for them to choose a different option than the one you’ve selected for them.

Case Study: UPS

How does this all work in practice? We’ll discuss one (very) common mistake, and one possible solution. If you buy or sell much online, you’re probably familiar with UPS8. Let’s look at a huge opportunity for improvement, not only for UPS, but for thousands of other websites as well.

What It Does Wrong

Before you do anything on UPS’ website, you’re forced to pick your country and language from a big ugly drop-down list. This means that before finding a UPS Store location, tracking a package or scheduling a pickup, you’re faced with a question — without any explanation whatsoever of why UPS needs an answer.

UPS9
Locale selection on UPS’ website

I don’t have any insider knowledge of UPS or its website, but common sense would suggest that it must be seeing at least some users drop off at that page. Blocking a user from viewing the website without selecting a locale isn’t consistent with either the user’s goal (tracking or shipping a package, in most cases) or the company’s goal (increasing revenue by shipping packages or promoting related services). So, what do we do instead?

How To Fix It

There are plenty of better ways to handle this situation. We could ask for the user’s country only when absolutely necessary (such as when calculating a shipping rate). But the locale (e.g. “United States – English”) also contains the language preference, so non-English-speaking visitors might have a difficult time navigating the website in that scenario. UPS could certainly do plenty to make the list more usable10, but it might not need to do these things at all.

Let’s go back to the basics: our goal is to reliably determine the visitor’s country and language preference. Luckily, we can do both of these things without even prompting the user.

For the country, we can use IP-based geolocation. This technique is imprecise but generally accurate, which is fine for our purposes: we’re looking for a country, here, not a street address.

The language would often be determined by the country, particularly in the case of UPS (which offers only a single language for most countries). In case the user’s locale has multiple common languages, we could use the HTTP Accept-Language header to default the user to their preferred language. Voila!

After11
We’ve (hopefully) directed the user to the correct version of the website without distracting them from their original goal.

Now, rather than interjecting a distracting page, we’ll add a message to the top of the home page letting the user know that we’ve directed them to the appropriate website, and giving them an opportunity to change the language and country in the unlikely event that our determination was wrong for some reason or in case their preference is different from their current location.

Now, the vast majority of users will never have to think about their locale and can get right down to business, while any users who prefer a different locale would still be empowered to make that selection.

Proceed With Caution

So, we should all run out and start using these and similar techniques on all of our websites, right? Not necessarily.

As with anything else, there are trade-offs. Will guessing the country confuse users or feel like an invasion of privacy? Do your users frequently use your application while travelling?

No two websites are the same, and the most important thing you can do is to get into the mindset of your users through research, analytics and interviews. As designers, we’re used to being conscientious while we’re adding interface elements; we need to be even more careful when removing them.

Wrapping Up

Adding more checkboxes, drop-down menus and radio buttons to a website is the easiest thing in the world. The technical implementation is straightforward, and the UX trade-offs are well defined.

Putting in the extra work to remove interface elements is sometimes thankless. But creating experiences in which users are only asked relevant information at relevant times makes for happy users, and happy users lead to happy designers.

More Reading

(al)

Footnotes

  1. 1 http://www.flickr.com/photos/johanl/8348989885
  2. 2 http://www.flickr.com/photos/johanl/8348989885
  3. 3 http://blog.adrianroselli.com/2011/10/detecting-mobile-devices.html
  4. 4 http://dev.w3.org/geo/api/spec-source.html
  5. 5 http://dev.maxmind.com/geoip/geolite
  6. 6 http://ipinfodb.com/ip_location_api.php
  7. 7 https://bitbucket.org/pellepim/jstimezonedetect
  8. 8 http://www.ups.com/
  9. 9 http://www.ups.com/
  10. 10 http://www.smashingmagazine.com/2011/11/10/redesigning-the-country-selector/
  11. 11 http://www.smashingmagazine.com/wp-content/uploads/2013/01/after_cropped_sized.png
  12. 12 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4
  13. 13 http://www.w3.org/International/questions/qa-accept-lang-locales.en.php
  14. 14 https://developer.mozilla.org/en-US/docs/DOM/window.navigator.language
  15. 15 http://diveintohtml5.info/geolocation.html
  16. 16 http://freegeoip.net/static/index.html

↑ Back to topShare on Twitter

Nathan is in charge of pixel herding at Stride. He's a little too into bacon, and often refers to himself in the second or third person while writing short biographical snippets. Unsurprisingly, he's on Twitter.

Advertising
  1. 1

    How does this change in a mobile browser? Screen real estate is more limited. Users are more likely to be at a different time zone, different country, etc than they might on their PC or a strange PC. Thoughts?

    0
    • 2

      How would it matter? If I am in Budapest on a business trip and need to send something back to Toronto, I will still most likely need UPS Hungary rather than UPS Canada. In fact, I would say this is the most expected response from the website: giving the default country as the one the user is currently in.

      0
  2. 3

    I would simply only put the message on the local content. For example, entering a tracking number shouldn’t matter only the promo stuff in the middle really.

    This is the thing with big companies these days, the internet is global and they need to understand it

    0
  3. 4

    Interesting article, but you forgot to mention anything about proxies; IP-based techniques should always be implemented with the possibility in mind that users could be behind a proxy.

    0
    • 5

      Great point — that’s absolutely a concern. That’s why it’s always important to provide a fallback option.

      If your site is likely to have an unusually high percentage of users that are on proxies or VPNs, IP-based options probably aren’t a good fit.

      0
      • 6

        Good post Nathan. In the midst of reading about IP geolocation I though “but what if the user doesn’t want *this* country?” – but you went ahead and proposed backup option.

        With that in mind, this should provide people who use VPNs an option to select their locale of preference if the default is not the one they want. I have worked on a very large website that used that exact system: IP detection. It worked for millions of customers and the only people I know who spoofed their IPs were the ones working on the website and testing it.

        0
        • 7

          I really appreciate the feedback, and am especially encouraged to hear you’ve used this technique successfully on such a large site.

          One thing I should have mentioned which will be obvious to most people is that if someone has opted in to a setting, you should probably track that with a cookie.

          0
          • 8

            Just to add another perspective – we had client wanting a medium-sized web app that limited posting on a map via the users current country. We used Geolocation first then IP sniffed anyone that didn’t allow us permission (we then allowed them to drop a pin anywhere in that country), so these technologies can also be used for validation as well as removing interface elements (we obviously ran into the proxy issue, but not enough in our case to worry about).

            0
  4. 9

    Hey – long time reader first time commenter here.

    As usual with Smashing I really like this post. However, one comment on using UPS for the example. I’m suspicious of:

    “common sense would suggest that it must be seeing at least some users drop off at that page”

    UPS is not a site where participation is optional. If you are there to send or track a package, it’s because you have to send or track a package. Any extra user annoyance won’t lose you as failure is not an option. My personal analogy is dealing with major telecoms. There’s a cellphone provider whose website is preposterously awful – they are obviously putting all their money into keeping their pay-as-you-go network up. I pay my bills on line when I can and I am used to their website crashing, not loading, freezing. But I still go back. There’s a surcharge to pay in person. Any other website would have lost me long ago but I’m generally very happy with their (lack of) plan so their awful website hasn’t lost my business.

    A vast majority of sites are not in this position and would do you well to implement the usability streamlining outlined above. I’d, of course, prefer it if my telecom would get it together as well but they’ve rightly calculated that web access isn’t a core part of their business. With UPS it may be but I doubt there’s a case of a surfer thinking “I’m annoyed at entering my ZIP so I’ll pay more with FedEx”.

    Just my two cents while avoiding work. Keep up the great posts!

    0
    • 10

      Great point. In the event of shipping as opposed to tracking, you do have a few options (FedEx, USPS), but not many. FedEx does the exact same thing as UPS with the location selector, while USPS doesn’t for obvious reasons.

      0
  5. 11

    I, for one, do not like being greeted by a whole interface written in the language of the country I’m currently residing in, when I’m expecting English as a default. If I can’t find a way to change the language within 10-20 seconds, my opinion of the service/product lowers substantially, and if I can’t find it at all it goes out the window. I’m Dutch but I prefer English working with computers/technology. When using things with Dutch language set it feels like watching a western movie in German (“Henden hogh, Johnson!”, the dubbing effect). It just doesn’t make sense, and pronouncing technical terms in my first language is just a grueling experience for the most part.

    I think the Dutch aren’t a very nationalistic (besides the orange soccer supporters army ..) people, and so it should be. Doing everything in your own language leaves you with a narrow minded view of the world.

    0
  6. 12

    Great article, i agree that we can lessen the burden by making our websites give smarter default settings base from users info is generally a great idea, but isn’t it we should be asking the user first, if they wish to share their location? especially when using the browsers geolocation capabilities (or did we assume the users wouldn’t care?)

    0
    • 13

      For the matter of HTML5 geolocation the user would have to approve our request to read their location in the first place in order for us to even access it.
      IP location-guessing is as general as can be, I’d assume that it wouldn’t be a problem for the major part of the userbase of a site, especially since this technique has been around quite a long time and major popular websites use it (e.g. YouTube).

      0
  7. 14

    This reminds me of a talk that I watched a while back that proposed future browsers should handle a lot more of the common interface tasks of websites, e.g. social sharing, main navigation menus etc. Unfortunately I can’t for the life of me remember who or where the talk was (if anyone recognises it please let me know!).

    0
  8. 15

    As someone who lives in Belgium the preset language options are usually horrid. For those of you not aware of our situation: in Belgium there are three main languages: Dutch, French and German. The thing is that my operating system is set to English (it’s just easier for computer lingo and trying to find OS fixes online) and that for some reason I always get the French version of a website (rather than the Dutch one).

    Presetting stuff can be cool when successful, but just like autocorrect on input: even if you only get 1% wrong, it leaves a worse impression than the 99% you get right.

    0
  9. 17

    Hi Nathan,
    Nice Article. Thanks for sharing. Developers are solely responsible to find the need the need of each users about, what they want.

    http://onlyforamericans.blogspot.in

    0
  10. 18

    Language does not equal location. My neighbor is bi-lingual and has his browser set to Spanish. IP does not always equal location. I use OpenDNS at a nearby WiFI hotspot, and despite being in Austin, TX a lot of IP lookups insist I went all the way to the West Coast for my latte.

    As for the UPS example – I am on the site to either ship a package or track a package. The problem isn’t the language. The problem is 75% of the screen is dedicated to try to get me to play a Facebook game. That is so many kinds of wrong for a business site like UPS.

    Use the geo-sniffing tools to preselect in a drop-down list, okay. But there are SO many other areas to improve on. Take a look at the country list on any site you work with or have responsibility for. If you are missing the Isle of Man but include Bouvet Island or US Minor Outlying Islands, you probably have some lower-hanging fruit. That you can ship to “Korea, Democratic Peoples Republic of” or “South Georgia and South Sandwich Islands”

    0
  11. 19

    There is a big problem: Lets give an easy example: I am working for an important client for a few month and his business is completely different from mine; at least I am not interested in his stuff but have the knowledge to do a good job.
    After this time – having all the benefits from google looking my interests in their search machine – looking amazoon, what I tried to find – getting newsletters from companies I had to sign in to get free stuff for my client…I am fixed to something specific that I would never choose – and at least I have no possibility to break free…
    As smashing generates most time the same comments that are only right in the smashing designers worlds context ;) , its the same with all other stuff and the ability to explore new and exiting parts of the internet, gets determined.

    To come back to the time-zone and language; very basic things. I understand and write German much better then English (sorry) but at least I never would read a Google-translated english website. So its really disturbing, that Google asks me all the time, if I want to get it translated? … the same with you tube. I am able to choose a country version if I want, but sorry, I do not want to be auto-dedected, and in an international world I am indeed often in an situation that I stay far away from the place, i will be tomorrow. And Internet should allow me to come in as an foreigner or as an resident. At least thats the benefit…

    Looking to much to what we think is the interest of the user leads in the wrong direction.

    0
  12. 20

    Nice Article.

    We also used to have a localization problem at my company website. I got the task of “make easy for users” and “make it always work”…
    I solved it by using three steps (with fallback to next step if the step is not available):
    1) Is user logged-in (if so, what language has he/she defined)
    2) Has user been to the website and defined a language preference on the website (cookie based)
    3) What URL is used (my company uses .nl .de .co.uk .be .fr and so on – but are all the same website)

    I thought this would give the user most control. No “automatic language detection”. This also solves the problem Niels Matthijs has in Belgium. (where browser and ip detection doesn’t work)

    0
  13. 21

    If You Ask it, You Get it

    0
  14. 22

    Almost everybody who does geolocation-based language detection gets it wrong for western Switzerland. The local language here is French. Relatively few people read German. Yet nearly every site which does geolocation instantly decides to show me a German language page.

    Some give me a choice for something like “Swizerland (French)” or better “Suisse (français)” or worse “Schweiz (Franzosisch)”. However there are a number of sites which absolutely refuse to serve content in English and still accept that I’m in Switzerland. It’s hugely annoying.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top