Considerations Involved in IP-based Geolocation and User Language Detection

By Cody in Constructive Criticism, Design, Usability

I’m going to revisit the UPS homepage—one more time—that I already discussed in Improving the UPS Homepage by Remembering Fitt’s Law and It’s 2010—Use Clickable Labels on Checkboxes. Despite the the sparseness of this particular page, there is a third thing here that I think could improve the user experience significantly and reduce a barrier to entry to the site (and concomitantly, potential premature user abandonment).

I think it would be very useful to pre-populate the dropdown based on the user’s IP-based geolocation and browser language settings (the Accept-Language header). Why pre-populate instead of automatically redirecting? Zak Wilson and Ivan Stojic have argued that IP-based geolocation should not be used in web apps because it causes more problems than it solves. I don’t fully agree—those users are in the long tail and for the majority of users I would be willing to bet geolocation gets it right. The annoyance caused to the few users who travel extensively or are behind corporate firewalls isn’t really enough to outweigh the benefit conferred to the average non-English speaker who goes to google.com and yet sees the site in what’s probably their language.

All the same, Zak and Ivan are correct that the Accept-Language header is a better piece of information to use first. Given the potential for even that to be incorrectly set, and the fact that UPS has already decided to deploy an interstitial, I think it makes sense to at least pre-populate the dropdown with a best guess.

However, it’s quite possible that UPS has considered this feature and determined that visitor satisfaction counterintuitively goes down as a result. Why? Because given that the site can obviously figure out the correct setting for most users, they may be annoyed that they were presented with an interstitial page in the first place. The average user probably isn’t aware that their language settings can be automatically determined, and so presenting them with an uninitialized dropdown hides this fact.

Again, this possibility only underscores the necessity of A/B testing. Much like other complex dynamic systems with many inputs and outputs—weather, nonlinear electric circuits, molecular biology—it is difficult to predict the ultimate outcome of seemingly innocuous or superficially beneficial changes when users are involved. It would be great if someone from UPS could comment on this page and discuss the considerations involved while designing it.

Using CSS Selectors Instead of XPath As the Default Locator Strategy in Selenium

By Cody in Rails, Software Development

We use Selenium to run in-browser acceptance tests in all our Rails apps via the Selenium on Rails plugin. With early versions of Selenium you had to use verbose and clunky XPath locators to reference DOM elements in the tests, such as:

//div[@class='content']/div[@class='sidebar']/a

For a while now, though, the cssQuery library has been integrated into Selenium Core, allowing you to use CSS selectors instead. For example, the above XPath locator could be written with CSS selectors as:

css=.content .sidebar a

In addition to being shorter, the Selenium documentation itself points out that most experienced users recommend CSS locators because they’re faster for the Javascript engine to parse, which means faster tests.

Making CSS Locators the Default

While the CSS locators themselves are great, it’s a minor annoyance of mine that they’re not the default locating strategy. As a result, every locator has to be prepended with css=. If you want to change this, apply the following patch to selenium-core/scripts/selenium-browserbot.js:

@@ -1107,7 +1107,7 @@
         if (locator.startsWith('document.')) {
             return this.locateElementByDomTraversal(locator, inDocument, inWindow);
         }
-        return this.locateElementByIdentifier(locator, inDocument, inWindow);
+        return this.locateElementByCss(locator, inDocument);
     };
 }

change_selenium_default_locator.patch

4 Kilobytes

Minor Annoyances With CSS Locators

The only thing that I don’t like with CSS locators is that indexing specific sibling elements is more verbose—it must be done with nth-child():

.content .sidebar:nth-child(1) a

With XPath you can use a simple pair of brackets:

//div[@class='content']/div[@class='sidebar'][1]/a

It would be really nice if CSS selectors had the same bracket-style indexing syntax as XPath. (Of course, this is a limitation of CSS itself, not Selenium.)

In addition, nth-child() is a little more brittle in that it isn’t constrained to the current selection scope. For example, assume you have markup like so:

<div class="content">
  <div class="something_else">…</div>
  <div class="sidebar">…</div>
</div>

There is now a non-sidebar sibling <div> appearing before the sidebar <div>. In this case, there will be no element that matches .sidebar:nth-child(1)—the sidebar is matched by .sidebar:nth-child(2). This means that adding additional unrelated markup to your page can break your tests if you’re using CSS locators. If you were using the XPath locators in this case, the indexing of the element in question would remain constant because the index doesn’t refer to children, but to elements matching that specific XPath. (If you added additional sidebar <div>’s the XPath would break as well, but all the same it’s still less brittle.)

One final point to note is that there’s also a bug in the cssQuery library that prevents nth-child() from working correctly—it’s Selenium bug #698. Unfortunately, the patch posted on the bug does not fix the problem for me. Instead, you have to resort to suffixing any nth-child() selector with a child or sibling combinator like so:

.content .sidebar:nth-child(1) > a

Despite these minor wrinkles, I find that the CSS locators used with Selenium are less verbose in general and lead to faster running tests.

It’s 2010—Use Clickable Labels on Checkboxes

By Cody in Constructive Criticism, Design, Usability

Returning to the UPS homepage I discussed in last week’s post Improving the UPS Homepage by Remembering Fitt’s Law, another problem concerns the checkbox. I’m really dismayed that it’s 2010 now and we therefore live in the future, but we’re still seeing sites not using <label> elements with checkboxes. And indeed, that is the case here—the ‘Remember this location’ label associated with the checkbox on this page is not clickable. This was also pointed out by Patrick McElhaney in a comment on the previous post.

This is another instance of where Fitt’s law applies—the tiny checkbox is a small target area for clicking, and so it makes sense to enlarge it by making the label clickable as a proxy for the checkbox itself. In desktop software on all major platforms (OS X, Linux, and Windows) the label of a checkbox behaves in just that way, and is always clickable.

I should note that, of course, on such a large site as UPS’s the changes I’ve been suggesting would have to be backed up by some A/B testing to ensure they achieve the desired effect and do not have any unintended consequences. Of course, too, UPS may be so big and critical to its customers that they would not abandon the site no matter the magnitude of its interface shortcomings. I would be willing to bet, though, that the changes would improve visitor satisfaction if not reduce abandonment, and any site can stand to increase the satisfaction of its users.

Stay tuned for one more critique of this page in an upcoming post!

Improving the UPS Homepage by Remembering Fitt’s Law

By Cody in Constructive Criticism, Design, Usability

Upon navigating to the UPS homepage for the first time, you as the visitor are presented with an interstitial page asking you to choose your country and language so that you can be redirected to a localized version of the site. These interstitial pages are quite common for companies which have global operations and customers in many countries.

In the case of UPS this page is generally very understated and well-designed. One way in which it could be improved, though, is by increasing the size of the button. Fitt’s law states that the clickability of a target is a function of the target’s size. The button here is 17×18 pixels—an area of 306 pixels. That’s only 0.0236% of the screen on my 1440×900 display—two ten-thousandths of the available pixels. There’s not much else on this page taking up any space, so there’s plenty of real estate to make this change.

Critically, pages like these are barriers that potentially keep visitors from continuing further into your site. They are simply one more hurdle the user must jump over before doing what they want to do on your site. Presenting visitors with a very small (and therefore difficult to click) button is one additional thing that could lead to premature abandonment. It could be the straw that breaks the camel’s back. There’s a tradeoff between making buttons microscopically small and comically large, and I think this button could definitely be enlarged to minimize the effect of the hurdle of an interstitial page.

What do you think? What else could be improved here? Stay tuned for a couple more posts about this page.

Getting on Your Users’ Side

By Cody in Information Design, Nice Touch, Usability

The first thing I looked for when I went to Hulu’s page for The Soup was the list of full episodes—someone had told me about a particular episode and I wanted to check it out. Scrolling down the page, though, I found only clips. My immediate reaction to discovering this fact was childish but came directly from my gut: I was pissed off. I wanted to see an episode of The Soup, I wanted to see it now, and now Hulu was standing in my way instead of making it easy for me like watching television online should be. Annoyed, I began to click away elsewhere while silently saying to myself, ‘I don’t care about their licensing predicaments and the intricacies of television broadcast rights—why can’t Hulu just get its act together and get this show so I can watch it?’

But then I noticed the little notice under the show banner.

It says, ‘Full episodes of The Soup are not available for online streaming at this time. We’ll continue to request them on our users’ behalf.‘ With those two little sentences, Hulu completely reversed the snap negative judgment I had hefted on the site. To the user, those sentences make it clear that not only is Hulu aware that this show is missing full episodes, but that they seem just as dissatisfied with the situation as I do. And what’s more, they’re working hard to change the situation.

The wording ‘on our user’s behalf’ is absolutely perfect for the intended effect. It made me feel like Hulu was on my side.

Users are unforgiving, and they’ll blame everything connected to your site on you even when those things are out of your control. So when something is out of your control, show the user you’re on their side. When you can’t give your users everything they want, commiserating goes a long way towards making them happy anyways.

Hulu goes a lot further than simply dumping boilerplate into this notice box. Many shows have descriptions of how many episodes are available for streaming at once, and when new episodes of the show will return if the show is on a hiatus.