Archive for the 'Usability' Category

Take Me Chrome, Where I Belong…

Published
by
Anders
on September 2, 2008
in Desktop Software, Firefox, Google, Microsoft and Usability
. 0 Comments

When you first encounter something that has been designed just right - the iPhone, Gmail, the Swedish cheese knife and now Google Chrome, you always find yourself wondering what you were thinking using all those other crappy products (I can’t imagine, for example, going back to a regular cell phone, or using an old-skool email client.) And now, after having only played around with Google’s new and long-awaited browser, I knew immediately that it was a keeper. And it’s not just because of all the widely discussed features like separate processes for each tab, and an overall much more modern system architecture. Maybe what I love most is what is not there, which is very much in line with that greatest of design maxims:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint Exupéry

Chrome certainly makes that idea manifest. And sure, maybe somethings were taken away that I’d want, like the ability to have a color theme different from the a-bit-too-dark Bloogle blue, or access to all my favorite FireFox add-ons. Oh, and somewhat ironically, I do miss my Google toolbar, particularly the autofill feature. But I expect that will all come in time.

On the lighter side, I just love how Microsoft came out with a statement today saying they weren’t worried about Chrome competing with IE8 - the only thing preventing that from happening is the default install base on Windows PCs - if IE weren’t installed by default on so many machines, their market share would fade away so fast - IE feels like an old jalopy compared to FireFox, and I hate to say this, but FireFox, while still an amazing browser, just feels slow and tired compared to Chrome (though maybe I should give it some time and open up a gazillion tabs and get umpteen applications running and see if Chrome’s garbage collection really is as great as they sat it is) - and one reason it hurts to say that is because so much of what makes Chrome great is thanks to the sweat and hard work and dedication of the people over at Mozilla - Google even made of point saying so in their super cool comic strip about the new browser. I love how they call it a ‘book’ - hey Googlers, did you know that there also are these books out there with, like, text and stuff :)

Firefox 3 - Back Button UI Annoyance

Published
by
Anders
on June 11, 2008
in Firefox, Usability and User Interface
. 16 Comments

I’m currently using Firefox 3 RC2 FireFox 3 and absolutely loving it - I love the new tags feature, the overall faster browsing experience, everything…

Well, almost. One thing that I find quite strange is the location of the control for jumping back several pages:

Firefox Back Button - actual

I remember the first time I needed to go back several pages and saw this and sort of looked at it like “hmm, seems like you can jump ahead several pages, but how do I jump back several pages?” But after clicking on the little control, it turns out that to go back several pages at once, you click on the control next to the forward link:

Firefox back button clicking on multi page control

Unintuitive indeed. Would it not make sense to have this control be next to the back button, maybe something like this?

My version of the Firefox back button

Here, the location of the control maps to our mental model of where we want to go, as in backwards.

Favicon Usability (or, please let me use them as buttons)

Published
by
Anders
on June 2, 2008
in Google, Usability and User Interface
. 0 Comments

Over the weekend, I think, Google updated their favicon (or shortcut icon) …

New Google Favicon with lower-case g

First off, I was pretty confused when I saw this, since seeing that g out of context doesn’t remind me at all of the Google brand. The old favicon was much better:

Old Google Favicon

While that lowercase g could be pretty much anything, it’s hard to confuse this with anything other than Google. But worse, and this was the case with their previous favicons as well, they have the same favicon for several different services, such as search, maps, and news.  So why is this a big deal (or a small-big deal)?  Well, I use favicons as buttons in my bookmarks toolbar…

Example of how I use favicons as buttons

This is a great way to conserve space.  The only requirement is that the people who are designing the website are thinking about how favicons might be used.  (Ok, in addition to the requirement of having a favicon in the first place.) Maybe what I’m doing is a bit unusual - basically turning favicons into buttons by removing the text description, but it seems to make sense, no?  So, if you happen to be someone who designs favicons or has any say about it, if you’re working on a suite of services, don’t use the same favicon for all of them.  Even if users aren’t being nerdy like me, it still makes it easier to target the right app if it has distinct visual mark or brand.

Yet another example of the cost of bad email usability

Published
by
Anders
on May 22, 2008
in Email and Usability
. 4 Comments

Just got an email from Wimbledon Live containing the following

Dear Anders,

As a previous Wimbledon LIVE customer we are contacting you about your preferences. If you would like to be notified about the 2008 Wimbledon LIVE service, please take the following steps to update your preferences:

1) Go to www.wimbledon.org/LIVE.
2) Click “My Account/Login” on the left navigation bar.
3) Login with your email address and password.
4) Click “Change preferences”.
5) Check the box to sign up for the “MediaZone mailing list”.
6) Click “Save changes”.

We thank you for your continued interest in Wimbledon LIVE.

Sincerely,
MediaZone

I’m not sure whether to laugh or cry. I feel so sorry for the people who run the Wimbledon Live site, who are stuck with this horribly inept solution to something that should be very simple, such as

As a previous Wimbledon LIVE customer we are contacting you about your preferences. Please click on the link below if you would like to be notified about the 2008 Wimbledon LIVE service.

[here, there would be a link the user can click on which takes them to a web page where they can click on a button to confirm their preference - in other words, take the user directly to the last step above]

So what is the cost of those 5 extra unnecessary steps? Probably that a lot of people, such as myself, couldn’t be bothered to deal with them, which in turn means that less people will be notified about the 2008 service, which in turn means lost business.

This is just such a great example of designing without thinking holistically. In other words, just looking at the design of the individual web page or whatever as if it were its own little island, when the reality is that its part of a larger flow, a larger context.

On the brighter side, really looking forward to Wimbledon as always - though I don’t think he’ll do it, would be incredible if Federer pulled of six in a row.

Toilet Usability - 6 Reasons Why the New NYC Public Toilets are Doomed

Published
by
Anders
on January 11, 2008
in New York City and Usability
. 6 Comments

Deputy Mayor of New York City Dan Doctoroff (who will almost certainly never use this toilet himself) today announced, with great fanfare, new public toilets to be installed in locations throughout the city. The idea of public restrooms is all good and well, and frankly it’s pretty embarrassing that this is being announced in 2008 and not, say, 1908. But no matter, when reading the description of the new toilets, there are just so many IMO terrible design choices that were made that I have to wonder if any kind of prototyping/usability testing was completed. I just can’t imagine these toilets being a success and these are some reasons why:

1 - They look like prison toilets

The new public pay toilet in Madison Square Park (Photo: Mary Altaffer/Associated Press)

There is a very strong association between a stainless steel toilet attached to the wall with no seat and what you might find in a prison cell. In fact, when I first saw a picture of the toilet, I thought that it was a picture of exactly that. The idea of a prison toilet has a pretty negative association, as in “citizens of New York are so uncivilized and prone to destruction of property that we have to take the same approach to designing a toilet for them as we would for prison inmates.” Sad indeed.

2 - I would never sit on a public steel toilet without a seat (even if it supposedly had been cleaned)

The reason for this is not only about logic, but also that I would just find it weird. And wouldn’t the toilet also get very hot in the summertime and very cold in the wintertime? Why couldn’t they at least have a plastic top on the toilet that can’t be lifted?

3 - The door to the toilet remains open for 20 to 30 seconds after entering

Like the NYT article says, this will

possibly be the longest and most awkward 20 to 30 seconds of a person’s day. The door slips open like an elevator, but then it stays open, to accommodate those who need extra time getting in. Meanwhile, men and women in suits walk past. It is very difficult to look inconspicuous in a bathroom on a sidewalk in New York with the door open. There is just nothing to do but stand there. And the delay will not please those who are in distress.

So here I am, really needing to go. With most every other toilet I’ve ever encountered, I can close the door behind me as soon as I enter. But here I am supposed to just stand there looking stupid with people walking by? The fact that certain disabled individuals may need more time is all good and well, but they should be able to keep the door open rather than creating awkwardness and discomfort for everyone else. Truly moronic IMO.

4 - The door to the toilet opens automatically after 15 minutes

Interestingly, this second ‘feature’ is in complete contradiction to the door remaining open on entry. What if I am a disabled person who needs more time? I would be publicly humiliated. And, frankly, even if I technically would be able to finish my business in that amount of time, I just don’t like the idea of this time limit hanging over me. And this isn’t just about disabled people, what about older people who need more time? Or parents with their kids? Very very bad, IMO.

5 - The toilets are only open from 8am to 8pm

If these toilets supposedly are completely automated, why in the world can they not be available 24/7? After all, the time when I think a lot of people would want to use something like this is when everything else is closed.

6 - The toilet will use 14 gallons of water per use

This is according the NYT City Room Blog. Keeping in mind that the EPA’s recommendation of water use for a single flush is around 1.5 gallons, this is absolutely egregious. To be clear, the 14 gallons are used to hose down the toilet between each person who has used it. This kind of water waste is IMO just not environmentally ethical, and reason enough for me to avoid it.

Usability testing of books

Published
by
Anders
on October 11, 2007
in Books and Usability
. 4 Comments

I’ve done a lot of usability testing in my day, but today I participated in one that was different from anything I’ve done before. Rather than testing the usability of a website, we were testing the usability of a book. This, by the way, was a test conducted by Liz Danzico, the editor of Rosenfeld Media, and it all came about because of her post about the test on her blog.

What was most interesting about participating in this was that I found myself looking at something—a book—that I’ve used for pretty much long as I’ve been around (after all, before I even knew what the word ‘Book’ meant or what a book was, my mother was probably, surely, reading bedtime stories to me - Mom? You are of course reading my blog, yes? Could you maybe post a comment to confirm?), and yet here I was looking at it as if I’d never seen it before, as if this were a completely new website somebody placed before me on a monitor and asked ’so, what do you think?’ I handled the ‘prototype book’ that Liz carefully presented to me, leafing through it a bit, looking at the table of contents, the index, the back cover.

In a nutshell, I found myself feeling very strongly that contemporary book designers can learn a thing or two from information architects, the people who organize information on websites. Seems weird doesn’t it? After all, book designers have been designing books for hundreds and hundreds of years, so you’d think they’ve pretty much got it all down pat. Not so, at least in my opinion. Similarly to how the web is transforming the music industry, it appears that books are equally susceptible to the impact of the web. No, no, I’m not talking about the paperless office or some futuristic hoopla about how the web spells the end of the book. I’m talking about how the way that we use the web, the way that we move from one page to another, the way that we have come to expect information to be organized on a web page, or in a website as whole, consciously or otherwise, is affecting how we think about and read books.

As a case in point, I mentioned to Liz that I would expect something akin to a ‘Getting Started’ section in the book, and the reason I wanted that, of course, is because it’s something I’ve come to expect in online help documentation (as well as in product-specific websites.) This, of course, would be for how-to books, and not for a more theoretical text.

Additionally, I’d expect a very tight integration between the book (keeping in mind that this is a book for computer professionals) and a companion website for the book. I would assume that I could go to the companion site and find additional content, similarly to what one might find on a DVD in addition to the movie, and of course things like errata (which already is quite common.)

Taking this a bit further, I would like to see a discussion forum, where the book essentially is the hub of a community that can congregate online to share their thoughts. And what would really bring the book-web connection home would be the presence of a wiki, where maybe the author sort of continues writing their book, possibly in response to comments made on the discussion board, or maybe uses the wiki as a live beta of a forthcoming future edition of the book. I guess the overall idea is that the web would function as an organic, living extension of the original work.

Napoleon, usability pioneer

Published
by
Anders
on November 7, 2005
in Usability
. Closed

At a very fundamental level, user experience is about communication—between the user and the system, between content and objective. And with new sites constantly popping out of the woodwork, user experience is more and more becoming a one-shot deal. You either communicate and deliver what the user was looking for the first time around or they’re off to the next site (which they almost inevitably came across via Google or maybe Yahoo!, which means they were taken directly to the page related to this search and not to the site’s homepage, which maybe provides a nice overview of the site—if your design doesn’t assume that users will jump directly to lower level pages without ever seeing your homepage, you are not designing for The Web That Google Made…) You’ve probably got something like 30 seconds to make your content/objective connection. That means your message needs to be crystal clear to the lowest common denominator user. Of course, it won’t be for every user, but the hope is that it will be for a sufficiently high percentage of users. Now, let’s imagine that you had to get your message through to all your users every time, and that not getting that message through could mean life or death. Ok, I plead guilty to suddenly switching gears to talking about a mission-critical system, but I’ve always found that UX design for the web has so much that it can learn from systems in which there is no room for mistakes. For all the praise given to people like Don Norman and Jakob Nielsen, it’s easy to forget that just because the term ‘usability’ only has been around for, what, a couple decades, user-friendly design has been around for about as long as there has been a need for stuff to be user-friendly, which brings us to emperor and part-time usability pioneer Napoleon Bonaparte.

The emperor needed to get his war strategy missives out to his troops not only fast but reliably, meaning that he needed to ensure that the message he sent—as he understood it—was also the message that was received. Not an easy task back in the day before instant messaging and email, when delivering a message might take days or weeks. If the message was not fully understood by it’s recipient, well, there just wouldn’t be any time to send back a follow-up question. You’ve got your orders and you better know what they mean. So Napoleon came up with a nothing-less-than-brilliant solution to his mission-critical message problem. Knowing the officers receiving his missives might be farm boys brought up quickly through the ranks and of, well, let’s say, questionable intellect (at least when it comes to war strategy.) Regardless, he simply had no idea who the recipient of his message might be (not much unlike sending messages through the Web) and therefore had to assume the worst. So, what better solution than do a bit of message prototyping before sending out it out, yes? Armed with his usability instincts, Napoleon went out among his troops and grabbed the most dense farm boy soldier he could find, promoted him to Lieutenant on the spot and made him part of his personal guard. Then, whenever he needed to send a message to his troops, the emperor would have it written up, presented to his Lieutenant, whom he would then ask to explain the message back to him in his own words. If Lieutenant Knucklehead could understand and explain it back to him, he figured that even the most dense of his officers out in the field would be able to get it. Last time I checked (except for that whole Russian winter thing), Napoleon’s usability testing model worked out pretty well. Aside from the obviously elitist aspects of this approach, there is still much to be learned from the Napoleon School of Usability Testing. His was the ultra-efficient shotgun model of usability testing, in which you test and iterate with one edge case user. It’s simple and it’s fast. On a certain level, it’s not so much about ensuring the user-friendliness of your content, but rather just getting a perspective that is as diametrically opposed to your own as possible, to react to something that may make complete sense to you. And that is really at the core of what we’re doing when presenting concepts to users—using them as a vehicle for stepping outside our own thinking, and into the messily subjective realm of usability testing, helping us to see flaws in our design that we maybe simply were not capable of seeing.

Bagging grocerices and software feature bloat

Published
by
Anders
on August 21, 2005
in Microsoft and Usability
. Closed

So I’m standing in the checkout line at Whole Foods on Union Square in New York City, where they’ve basically got long lines from open until close, and then I finally get to the always-friendly cashier, who rings up my groceries, and then proceeds to bag them. Having lived much of my life in Europe, it’s always struck me as unfortunate that, in most U.S. supermarkets, cashiers or someone assisting them, will provide grocery bags and bag your groceries for you, while in Europe (at least in Stockholm, Berlin, and Brussells), you will almost certainly have to bag your own groceries, as well as either bring your own bag, or pay extra for supermarkets bags. I think the reasons for this difference is likely tied to all kinds of cultural, sociological, and market factors, but, ultimately, I think customers are done a disservice by being provided this extra “free” service. Aside from coming home to discover that your canned preserves were placed on top of your bananas, having cashiers do the bagging actually slows down lines, which means more cashiers or assistants need to be hired, which means more overhead. And then, of course, there is the environmental side to the equation—by requiring customers to bag their own groceries and charging them for supermarket bags, you encourage that they bring their own bags (this is very common in Stockholm.) I usually bring my own bag when I go to Whole Foods, and even at this generally progressive establishment, I often get a confused look by the cashiers who often are not quite sure what to do with this alien variable that has been inserted into their process.

In the world of user experience design, I would call the cashier-bags-groceries feature an example of feature bloat. One of the more notoriously feature-bloated applications is MS Word. While users of this app may not be familiar with this term, they have almost certainly experienced its detriments, which basically takes the form of wading through all kinds of features you either never use or don’t really understand (when did you last do a mail merge?) to get to the 10% or so of the features that you use all the time. The origin of feature bloat are slightly less complex than the cashiers doing the bagging in supermarkets, but may be driven by similar forces. They mostly have to do with justifying a new version of the application every few years. Just like software marketers need new exciting-sounding features that they can splash across their ads, supermarkets need to sell convenience, which often can take the shape of giving customers things they never really asked for but which it is expected will help selling the product. And this really is at the core of the issue giving users stuff they never really explicitly asked for (Do you really think a customer in a supermarket just one day refused to bag their own groceries, and so supermarket owners were forced to start bagging them? Ok, I jest, but you get my point.) In the world of software development, every design decision implies some form of trade-off; you get one thing, you are likely giving up something else. By giving users features they haven’t explicitly asked for, they may need to either cut corners elsewhere or completely forego features that may be more important to them. In MS Word, most users just want to write whatever they need to write and print it or email it or whatever and be done with it; in supermarkets, customers just want to get their groceries and get out of there. Aware of this issue, Microsoft has in recent versions begun to for the first time reduce the number of features in MS Word; some U.S. supermarkets have actually also begun to (inadvertently?) also address the issue by having self-serve checkouts (there is one at the Kmart at Astor Place in NYC), which require customers to bag their own groceries, but is also churning up a host of new user experience issues relating to the touch screens and other devices used when doing a self-serve checkout, but I’ll save that for another posting…

Feature dependency and context of use

Published
by
Anders
on August 6, 2005
in Industrial Design and Usability
. 0 Comments

Imagine buying a new (and expensive) car and discovering that the car will only run if the air conditioning is turned on. You take the car back to the dealer and ask them to fix the problem. But to your surprise, the dealer informs you that that this is how the car has been designed. This seemingly surreal analogy is not too far off the mark from my experience purchasing (and later returning) the Bose Quiet Comfort 2 Headphones. I received the headphones and was immediately impressed by their compact and light design. I plugged them into my notebook and fired up iTunes. Unfortunately, all I got was silence. No music. I called customer support to report the problem and was informed, to my surprise and great dismay, that the only way to be able to hear music is if the noise canceling is turned on. This is not good, since the noise canceling requires a battery and is sometimes so good that a person can be standing next to you talking fairly loudly and you can’t hear a thing. (Ironically, the insulation of the headphones is so good that you almost don’t even need to turn on the noise canceling for the headphones to reduce noise.) So why is this bad? Well, recalling the car analogy, just as driving is the primary function of a car, listening (I think) is the primary function of headphones (not to be confused with the earmuffs you might see people wearing at a noisy construction site.) Just as air conditioning is a secondary feature in a car (you can have a car without air-conditioning, but not vice versa), so noise canceling is a secondary function of headphones. But wait a minute, you say, isn’t the primary function of these headphones to cancel out noise? Possibly, but that still doesn’t justify any kind of dependency between these features. Listening to music should not require having noise canceling turned on - there is no logical dependency between these features – instead, the dependency has very unfortunately been manufactured into the design. And in reality it’s probably a legacy problem (for those who think that computer systems hold a monopoly on being hampered by bad design due to legacy issues, take heed) – the Bose QC2 are the offspring of industrial grade headsets Bose designed for US Military helicopter pilots, to shut out the extremely loud noise of the chopper engines and allow the pilot to hear what was being said in their headphone intercom units. Going the way of the Humvee all purpose military vehicle sold to civilians as the Hummer, Bose discovered a market for these headsets among business travelers sick of the drone of jet engines on passenger planes, and the Bose QC1 (bulkier than the QC2 and with a separate noise canceling box) was born. I’m guessing that the original military headsets were drawing power for both the noise canceling and the intercom from the same source, and when the civilian version was designed, this was maybe not even considered as something needing to be addressed. Would the noise-canceling/audio dependency issue not have been uncovered with some simple usability testing with civilian users? Or did Bose decide that all the rigorous testing that inevitably had been required for the headphones to pass muster in the military was sufficient, and that the (supposedly) lesser needs of civilians meant that no further testing was necessary? This, perhaps, is at the core of the issue: civilian use is obviously a completely different context from military use, which means all bets are off as to whether the design intended for the original context will be valid in the new one.

Selecting user-friendly domain names

Published
by
Anders
on July 30, 2005
in Usability
. Closed

When graphic designers are developing logos, one common test of the quality of the logo design is to fax it and see what the faxed version looks like. Faxes flatten colors, make tiny print hard to read, and just generally put the logo to the test of withstanding less than optimal conditions. Domain names need to be able to withstand equally sub-optimal conditions. Whenever I see domain names that are hard to pronounce or include hyphens or use words for which there are several spellings or sound different from how they are spelled, like storycorps.net, a wonderful effort at documenting American oral history, I wonder if those deciding on a domain name ever did a fax test, like imagining that you need to verbally communicate the domain name, perhaps over the phone, or maybe at a cocktail party, or some other context that is less than optimal for communicating domain name. Would you need to spell it for them? Would you need to explain that there is a hyphen between the words? Or like the good people at Story Corps, would you need to use up precious seconds of radio ad time to spell out your domain name, because when you say the domain name, it really sounds like “storycore”? So what to do - after all, Story Corps can’t really be expected to change the name of the organization (though I would argue that in this webified age, thinking about the domain name of your organization should be a critical factor when coming up with a name) - what they could (and did) do, like Google has done, is to register expected alternate or incorrect spelling of your domain name (try going to gooogle.com, for example, or try going to capitolone.com, which will take you to capitalone.com), so Story Corps, knowing that even if they spelled out the domain name, storycorp.net, were smart enough to register storycore.net. In this case, they were lucky enough that the alternate spelling was not already taken. But then you’ve got domain names like real-estate.com. When giving someone this domain name over the phone, you have to call it “real hyphen estate dot com” which doesn’t quite roll off the tongue that easily. And should you forget to mention the hyphen, well, then the person you’re talking to will end up at the competitor site realestate.com. In my view, real-estate.com is actually inferior to a name like realestateonline.com, which is longer but easier to say. Shorter is not always better, not even when it comes to domain names…