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.

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

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!

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.

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.

Of course, Apple’s Human Interface Guidelines for Resizing and Zooming Windows explain that the zoom button isn’t actually supposed to expand the window to fill the screen, but toggle the window between a standard application-defined size and a user-defined size. Regardless of what the human interface guidelines say, though, I still don’t like what it does, and I’m apparently not the only person. There are hundreds of pages asking how to fix it.

In case you’re wondering, the bookmarklet is:

I simply put the bookmarklet first in my bookmark bar, which lets me maximize Safari by hitting ⌘1. I didn’t write this little snippet of Javascript, but I can’t remember where I found it and there are versions of it all over the Web.

So, back to the real story. Upon further investigation, I determined that the bookmarklet only works when the Safari window contains a single tab. If the window has more than one tab, the bookmarklet doesn’t work. I wasn’t the only one who noticed this bug, as I found the post Safari 4 breaks bookmarklets? on This Is the Green Room.

I figured the problem would be fixed when the final version of Safari 4 was released, but when that happened this past week, the problem remained. Googling a bit, I found WebKit bug 24218, which notes that the Javascript window.moveTo and resizeTo methods do not work in Safari windows with more than one tab.

Since the bug was marked unconfirmed and didn’t have any activity on it for months, I decided to download the WebKit source and try to track down the cause of the problem. I checked out the WebKit code and built it according to the instructions. After digging a bit and setting some breakpoints, I figured out that the following method in WebCore/page/DOMWindow.cpp implements window.moveTo in the Javascript engine:

This method basically does some adjustments with the screen and window rectangles, and then finally invokes Chrome::setWindowRect to perform the actual move of the window. Stepping through the method when clicking the bookmarklet with one and two tabs showed that all the rectangle calculations were resulting in the same values regardless of the number of tabs. The invocation of setWindowRect simply wasn’t moving the window when there was more than one tab.

After a bit of indirection through some other classes, Chrome::setWindowRect calls WebChromeClient::setWindowRect in mac/WebCoreSupport/WebChromeClient.mm:

This method basically translates the rectangle coordinates between the scale used by the window and the WebView itself, and then sends setFrame:windowRect: to WebUIDelegate. This delegate is the bridge between WebKit’s Javascript engine and the actual Cocoa browser window (I think), and WebKit is passing it the correct coordinates to move the window. WebUIDelegate, though, simply doesn’t move the window as it should when there is more than one tab, which leads me to believe the bug is in Safari itself, not WebKit.

I updated the WebKit bug and filed a new bug for Safari on Radar. I thought for a moment that this behavior might actually be intentional, to prevent pages from resizing the browser window via Javascript when there are other open tabs that would be affected. But since the bookmarklet works in Safari 3, I tend to doubt this new behavior is by design as it would break a lot of existing Javascript. Scripts embedded in an actual page are similarly unable to move or resize the window when there’s more than one tab open, so the problem doesn’t have anything to do with the Javascript being in a bookmarklet.

But, as with all principles, careful application is key, and limits are a sticky subject. Are your limits unexpected? Are they advertised, explained, or easily understood when discovered? What happens when a limit is hit? Is the limit purely a technical one? How much work is saved by placing a limit on something, and do you run the risk of raising user ire by enforcing it? What will you tell your users is the reason for the limitation if they ask? Are you trying to follow a trend of behavior, or set one?

Twitter

Twitter limits posts to 140 characters, and largely because of that limitation the platform is the biggest thing since sliced Facebook. Brevity is the cornerstone of Twitter; as a result, URL-shortening services have become a necessity to pack as much into a tweet as possible. You can only follow 2000 people on the service, which helps the servers that run Twitter and is a number that no user would be able to realistically keep track of anyway. And, for some reason, only only 162 pages of archived tweets are available — likely another technical limitation designed to reduce load on the historically unreliable Twitter architecture.

Twitter is a great example of an idea successfully based on limits, and the limits it enforces are not conspicuous enough to be annoying. On the other hand, Twitter’s limits on API usage have irked some deveopers, and when features sometimes disappear in the name of keeping the site live under heavy stress, users are understandably surprised, confused, even angry. As Twitter is iterated upon, these issues should become less and less prevalent, and the expectations of its limits will be fulfilled more consistently.

Muxtape

The late great Muxtape was all about limitations. Each user was limited to a single mix, and each mix was limited to no more than twelve tracks. This kept things from getting indulgent, and doubtlessly saved disk space. On the flip side, users were also limited to only twelve ‘favorite’ mixes to save on their profiles. As a frequent Muxtape user, I found this limitation made it difficult to keep track of more than that number of mixes, which presented a problem — I wanted to maintain a list of both friends’ mixes and mixes I wanted to save for later listening. It never kept me from using the site, and it may have been changed in the future, but it was a little annoying.

Take It to the Limit!

The key is to make sure your limitations never restrict exploration and excitement, but instead focus on creating those emotions in your users. For new users, exploring a site’s purpose can be intimidating and, potentially, a waste of time. If you can condense the message and narrow the feature set, your product will be much easier to understand, and thus easier to participate in. Once a user is in, however, don’t let them stop at accumulating reasons to revisit the site, or telling friends. Keep things as sticky as possible.

Helpful Limits

• Your site doesn’t need all of the features it could have. If a problem has already been solved, don’t replicate — incorporate or eliminate.
• Would your site’s content (user-generated or otherwise) be more compelling if limits were applied to it? What if you only had a sentence to explain each page? What if users’ bios could only be six words long? Restrictions can often provide the frameworks in which participation and creativity truly thrive. Read Peter Bregman’s Why Doing Things Half Right Gives You the Best Results for an idea of what can happen when users are presented with too many choices.

Hopefully Limitless

• Users should be able to have as many friends, favorites, and other “collectibles” as they need. If all that data storage is costing you too much to keep it free, make people pay to up their limits. It works for Flickr, and there are a lot of people who would pay for Twitter too.
• Explain your limitations upfront, and go easy on users that reach or try to break them.
• Limits should look like limits, not like errors or something unfinished.

So?

Limits and their potential consequences are a helpful structure in which to evaluate the features of your site and every facet of its design — both the system and the interface. Keep limits in mind as you’re building, and you may end up launching ahead of schedule, saving yourself time and your users the time of figuring out the ins and outs of your site’s feature-set.

I’ll leave you with some questions. Which of your favorite services employ limits, and how does it make things easier or more difficult? Is limiting favorites is a mistake? Is there something positive to be said for a limitation that users won’t like?

I am a contributor to Wikipedia, and I speak Japanese. To indicate that fact to people that visit my user page, there’s a box that lists the languages I speak and just how well. (This box, technically called a ‘userbox’, sometimes abbreviated ‘UBX’, is part of the Babel project, and was the first userbox template on Wikipedia. Since its inception, badges for every conceivable attribute have emerged.)

I don’t understand this box. What’s going on here?

The numbers don’t mean anything

The numbers are somehow meant to signify your proficiency at each particular language, but they are basically meaningless. The questions immediately raised are:

• Is 2 is a high number or low number?
• The range into which a number falls is unclear. Two out of what? Of five? Of ten? Of six hundred quadro-billion?
• There’s no way to tell the particular language skills actually signified by each number. What’s the difference between a ja-2 and a ja-3? Is it a difference in vocabulary size, conversational ability, etc.?

Furthermore, the scale isn’t limited to just numbers — there’s a ja-N for native speakers. Even more confusingly, I speak English natively, but the template Babel box posted for native English speakers uses only en, not en-N. (Incidentally, there’s also an en-N category). The system is totally inconsistent.

If you read the fine print, it turns out a lower number indicates a lower level of proficiency. There are many different metrics one could use for language proficiency (or any sort of skill, for that matter), and among them both high or low numbers could be used to indicate expertise or accumulated experience. You can be a first-class pilot (a low number) or a Level 64 Gaming-Warlock (a high number). Incidentally, the Babel box numbers are roughly based on the ILR scale, in which a lower number indicates lower proficiency. Contrast this with the Japanese Language Proficiency Test, where a lower number indicates higher proficiency.

The point is, the nature of the metric being used here needs to be made obvious by showing the bounds of the metric and the significance of each bound.

The explanatory text is unhelpful

The Japanese sentence next to the ja-2 box explains that I’m a medium-level speaker, but only people who read Japanese can understand that. (And what does speaking have anything to do with it, anyways? This is a website concerned with reading and writing.)

The design of the box is lacking

• Why is it titled ‘Wikipedia:Babel’?
• Is there any rhyme or reason to the color scheme?
• What does it mean to ‘Search user languages’?
• It’s aesthetically boring at best, ugly at worst.
• The syntax for creating userboxes is needlessly confusing.

It turns out that investigating the ‘medium-level’ link hidden in the explanatory Japanese sentence in my Babel userbox reveals yet another badge:

Confoundingly, this badge is a different color and is more explanatory, but it’s hidden away in the Babel userbox documentation pages. It doesn’t really even make sense as a badge in that context. I give up.

Why is it such a mess?

Clearly, the Babel userbox needs work. I chose to focus on this tiny little aspect of the site, but it’s indicative of a much wider swathe of design and usability flaws on the site in general. But why is this the case? Some insight into Wikipedia’s defects may be found in two places: Google and open-source software.

Those who find success in Google’s infamously minimal “non-design” point to its ability to sink into the background and make way for the important stuff — search results, emails, etc. Likewise, Wikipedia is about articles. Only the power-user needs to worry about things like revisions, categories, templates, and profile customizations such as the Babel userbox. The article (and editing it) are the strong idea, and Wikipedia has the momentum of quality, quantity, and notoriety, which, like Google’s search engine and email service, are enough to get beyond what’s lacking in the interface.

Open source software is plagued by poor usability. As an open-source software project, MediaWiki suffers from many usability problems. This is compounded by the fact that Wikipedia, the encyclopedia built upon it, is itself open to anyone. And those anyones are often experts, but not in the field of design or information architecture. Thus, amateur and suboptimal design is the standard.

innovative: featuring new methods; advanced and original.
novel: new or unusual in an interesting way.

I was spurred to write this commentary after seeing a Tumbl’d photo of a creative bathroom arrangement by serial entrepreneur and innovator Jakob Lodwick. Here’s the photo, for reference:

While I find the arrangement of the toilet paper dispenser interesting, and love that there are people like Jakob out there willing to publish this sort of thing when they discover it, I take issue with it being called “innovation.” The bathroom does feature “new methods” (or at least one), and, hey, it’s plenty original, but does it fulfill the third requirement? Is it sufficiently advanced?

I call foul. It’s interesting that the toilet paper dispenser is screwed into the chair, but at the same time it’s a waste of a chair, arguably one of the most functionally perfect inventions in human history. There would perhaps be merit to this if it were posited as an art piece with some message behind the configuration, but that doesn’t seem to be the case here. I think it would make much more sense to put the basket on the floor, keep the roll in its usual place — at arm’s length on the wall — and then have an extra chair to use. From a functional design standpoint, it seems more like a misstep than innovation to me. As it stands, the chair is impaired for other uses and the toilet paper dispenser can now be accidentally removed from the bathroom.

I don’t mean in any way to single out Jakob or indict his creativity. In fact, I’m not so certain the post wasn’t entirely tongue-in-cheek. Rather, his photo-and-single-big-word post prompted me to write something I’d been meaning to articulate for a while. I think in the slightly feverish atmosphere surrounding the software and web development community nowadays, there is a tendency to get a little too excited about things before they’ve either been properly examined or vetted by history.

Novelty is a good thing, and I’d hate to live in a world without it. In fact, a lot of innovation — I’d even wager the vast majority of innovation — comes from experimenting with novel ideas. But novelty is not innovation on its own, no more than simply experimenting with food, machinery, or art (regardless of your credentials) is innovative on its own. The same goes for software. It’s the reason things that momentarily enthrall us eventually fade: many of them are just novel. The things that stick, on the other hand — the wheel, the chair, rock music, Craigslist, the MP3, and the Post-It (literally) — those are innovative.