This just in: the bigger a target is, the easier it is to hit. Hats off to whoever designed this box for Trader Joe’s! I’m sure it speeds things up for both their cashiers and customers by providing a huge target for the price scanners. This is a perfect use of otherwise-wasted space.

I’m curious to see if they update the rest of their packaging in the future. The top box is a new product (at least at my local Trader Joe’s), while the maple pecan granola on the bottom has been around for a while.

Related posts

• (none)

← wtf!

The letterforms are ambiguous, the font is a distressed/grunge face that leaves orphaned blobs that might be part of letters, might be periods, and might just be random blobs. You can switch to an audio CAPTCHA, which is someone reading numbers that you type in instead of the picture of text. Great. Except that the weird background noise they put in to prevent automated speech recognition mangles the speech into unintelligibility.

After about four failed attempts with the audio and over twenty with the image, I give up.

To add insult to injury, the only reason I was creating an account in the first place is because I wanted to install an "experimental" add-on for Firefox, and you have to be registered to do that:

Why do I have to login to install an experimental add-on?

The add-on site requires that users login to install experimental add-ons as a reminder that you are about to undertake a risk step. [source]

1) Bullshit. You can give me a reminder without me being logged in if you want to. Really, I swear it’s true!

2) By a) making me register for no good reason and b) making the registration process difficult or impossible to complete, everybody loses:

I lose, because I can’t install the useful-looking software I wanted.

The plugin developer loses because I could be providing bug reports and feedback for the in-progress software, if I were able to install it.

The Mozilla Foundation loses because even though their "reason" for making me register is bogus and seems like an attempt to inflate their user numbers, I was willing to do it anyway. They lose a conversion, which they’re probably pretty desperate for given just how lame their justification is.

Conclusion: there’s no reason I should be frustrated at having my time wasted with a broken system (that I shouldn’t really have had to deal with in the first place), without the software, instead of using it—to everyone’s benefit.

Lessons from this experience:

• Test your application. If the goal is to make something understandable by humans and not by machines, make sure it’s understandable by humans.
• Don’t make people jump through unnecessary hoops, like registering for no good reason.
• If you’re going to anyway, make the hoop-jumping process as quick & painless as possible. For example, if you’re going to make someone register, collect the bare minimum of information that you need (not want). If you don’t piss them off, you’ll probably have other chances to get this info; if you do, you won’t get anything.

Related posts

• Jakob Nielsen answers "how little do users read"?
• Drag-and-drop download
• Naming Downloadable Files
• Keyboard shortcut conflict: iChat vs browsers
• Adam Darowski on URLs as UI

Two mints in one!

Related posts

• mozilla.org’s human-proof CAPTCHAs
• Jakob Nielsen answers "how little do users read"?
• Naming Downloadable Files
• Keyboard shortcut conflict: iChat vs browsers
• Adam Darowski on URLs as UI

Summary:
On the average Web page, users have time to read at most 28% of the words during an average visit; 20% is more likely.

We’ve known since our first studies of how users read on the Web that they typically don’t read very much. Scanning text is an extremely common behavior for higher-literacy users; our recent eyetracking studies further validate this finding.

The only thing we’ve been missing is a mathematical formula to quantify exactly how much (or how little) people read online. Now, thanks to new data, we have this as well.

Continue reading at useit.com

Related posts

• mozilla.org’s human-proof CAPTCHAs
• Drag-and-drop download
• Naming Downloadable Files
• Keyboard shortcut conflict: iChat vs browsers
• Adam Darowski on URLs as UI

In every major browser I’m aware of, Command-L highlights the address bar so you can type in the URL of a site, which I do constantly. Command-L, Command-L, Command-L, all day long. Apple’s iChat IM client has an annoying conflict: Command-L signs you out. This is a problem if you’re switching rapidly between browser and IM (which at least I do frequently) and think your browser is in the foreground but it’s really iChat, you hit Command-L and get logged out.

Apple could be right to expect people to pay more attention, but this happens regularly to almost everyone I know who uses iChat, so at least in my experience, it’s a widespread problem.

Proposed solution: change the Log Out of AIM keyboard shortcut.

Related posts

• Naming Downloadable Files
• mozilla.org’s human-proof CAPTCHAs
• Jakob Nielsen answers "how little do users read"?
• Drag-and-drop download
• Adam Darowski on URLs as UI

Let’s put ourselves in the user’s shoes. We’ve downloaded something from a web site, either because we know we’ll want to refer to it later without going back to the site (user manual, spec sheet, receipt, etc.), or because it’s the only way the site has provided to access or manipulate the information (”download this form, fill it out, and fax it to us”). Either way, we’ve saved the file locally and will need it later.

Let’s say we’ve downloaded the spec sheet for Harman’s GLOSS FB Al inkjet photo paper (which is amazing, BTW), while researching which paper to buy. We decide it looks good, place an order, and wait. Now it’s a few days later, the paper has been delivered, and we want to look at the spec sheet to see if there are any special settings we need to use before we start printing. So we go to the folder we saved it to to look for it.

Summary so far: The manufacturer has provided the information we need in a format that’s convenient for offline viewing, both on-screen and in print. It was pretty easy to find on their web site. They didn’t make us register or pay to get it. We have it. Things are looking good so far!

But, now that we want to look at it, we have a problem: we can’t find it! Why? Because the name of the PDF file they thoughtfully provided is—seriously—2007622163739169.pdf. Huh? I doubt the name even means anything to anyone at Harman. I know there’s nothing about it that tells us what it is. The best we can hope for here is to view the folder contents by date, try to remember when we downloaded it, and start opening files that were created in that window of time until we find the right one; or do a slow search on file contents, hoping it was generated in such a way that our search term can be found.

Another example is WordPress, a popular blogging package. They have since fixed the problem, but it used to be that when you downloaded the software, you got a file called latest.tar.gz (or latest.zip, depending on which format you chose). Latest what? We have to unzip the file and look in the folder it created to find out. And we’re in big trouble if we want to know what version we’re looking at, because we’d have to open and read through a bunch of PHP files (computer code that’s unreadable to most people) to find out. We might stumble upon the version.php file, but it would probably be by sheer dumb luck as it’s tucked away in a sub-folder called wp-includes.

This is the user experience equivalent of Punk’d. A scenario of helpfulness and customer support is laid out: the information provider has a web site, has the reference material (and in a standard format), doesn’t make us jump through hoops to get it… and then yanks the rug out when the chips are down. Why go to the trouble of producing and providing information that’s useful to your customers, only to make it effectively inaccessible when they actually need it?

In some ways, this is worse than not providing the information at all. By going there, an expectation is created that the user will be able to easily access it when they need it. Creating the expectation and then failing to meet it is likely to frustrate and anger users much more than not creating it at all. It’s probably better to stick to having the info available only as a web page, which is an expectation that can be met: the user can go to the site and find what what they need. It’s not as useful as doing it right, but it’s a better user experience overall.

We’re not stuck with the 8.3 file naming restrictions of DOS. We can have mixed case letters, word separators, and even spaces where appropriate!

WordPress’ latest.zip can follow the naming convention standard for open source projects (and it now does), which is app_name-version.extension. wordpress-2.5.zip actually tells us what we’re looking at! There are no spaces, which is a good thing here: it’s easier to deal with files in a CLI shell (like on a web server) if there aren’t any.

But since the PDF is almost certainly going to be stored on a computer with a graphical interface, spaces are ok, and the useless 2007622163739169.pdf can become Harman GLOSS FB Al Tech Info.pdf. To really bring it home, a version number could be added: Harman GLOSS FB Al Tech Info-v1.2.pdf, or Harman GLOSS FB Al Tech Info - 2008-01.pdf. Now the user not only has the info they need, but they can find and use it, and can find out if they’ve got the current version.

That last 0.001% of effort it takes to name the file properly can be the difference between the user having a bad and frustrating experience associated with a company or product, and a good one. Seems well worth the 5–10 seconds to me.

Related posts

• mozilla.org’s human-proof CAPTCHAs
• Keyboard shortcut conflict: iChat vs browsers
• Jakob Nielsen answers "how little do users read"?
• Drag-and-drop download
• Adam Darowski on URLs as UI

I was just thinking about this yesterday when I was looking at Flickr with a “non-power-user” friend, trying to find an old picture in someone’s photostream. I watched them go from page to page, clicking 3 ahead, as it’s the most Flickr will let you skip from the middle of a big stream. When I told them they could type any page number they wanted (up to the last page, of course, whose number is displayed on every page) into the address bar to skip by larger chunks, they took to it right away.

http://flickr.com/photos/username/page10
^^

Good URL design is useful for lots of people, not just geeks power-users.

Related posts

• Naming Downloadable Files
• mozilla.org’s human-proof CAPTCHAs
• Keyboard shortcut conflict: iChat vs browsers
• Jakob Nielsen answers "how little do users read"?
• Drag-and-drop download

These two possible interpretations are opposites in terms of the effect on the clothes. One will leave them wetter and the other drier, and short of running it each way and timing it with a stopwatch, there’s no way to tell which is right.

(There’s also a third, which is both: it could spin the clothes faster for a shorter amount of time, removing the same amount of water on either setting, maybe using more energy to get it done faster… but I’m not going there.)

(Again, sorry for the crappy phonecam pic.)

Related posts

• Ambiguous Letterforms Yield N-word

This is a poster for a show for Vanilla Fudge. The bubbly, melty type seems appropriate for a 1960s psychedelic rock band… until I try to actually read the words.

“Fudge” is clear enough, but to my eyes, the “V” in “Vanilla” looks a lot like a “Y”, and the “L”s look like “G”s. Given the surrounding letters, that’s a bad combination.

(Sorry for the crappy phonecam pic.)

Related posts

• Ambigous Spin Cycle Selector Switch

As with any system, there are a few nits I could pick with the otherwise-sweet user experience, but there are two things so far that I feel are serious mistakes:

The first is the on-screen keyboard. There’s a sensor in the phone that does neat stuff like rotating photos and web pages and zooming them to fill the screen depending on whether you’re holding the phone in portrait (vertical) or landscape (horizontal) orientations, and switching to the Cover Flow view when you’re browsing music in the iPod section. (Most current digital cameras have this feature, too.) This is awesome. However, its application to the keyboard is spotty.

In the SMS and Mail applications, it’s only available in the narrower and smaller portrait orientation. If you’re filling out a form on a web page and the keyboard is already on screen, turning the phone doesn’t change the page or the keyboard. Having the landscape keyboard available at all times would allow the buttons to remain in their bigger form, thus improving typing accuracy and speed, and not lock you into an orientation once the keyboard is up.

The other is the take-the-picture button for the built-in camera. The button is on the screen and the lens is on the back of the phone. This means that if you want to take a picture with you in it, you have to line your finger up and hover it over the right place on the front, turn the phone around so you can no longer see it, and hope you hit the right spot. This is harder than it sounds, because the button is pretty small.

I see two possible solutions to this. The first thing that comes to mind is making the button bigger. This would make it easier to hit, but you’d be left with two sub-optimal choices. You could make the button almost as big as the entire screen and label it as such where the shutter button is now, but that might make it too big and lead to accidental triggering. The other is to make it not quite so big, but that would require an overlay to delineate the target area, which would get in the way of the on-screen live preview when you’re using the camera normally. (The phone has no way of telling if you’re in front of or in back of it, and having a separate mode seems like an unnecessarily complicated kludge.)

A better way would be to use one of the phone’s five physical buttons. While the desire to have each of them produce a single and unambiguous result, regardless of context, is a good one, this problem is annoying enough that I think it warrants breaking that guideline in this one instance. The Home and Screen Off (or whatever it’s called on the top) buttons need to be able to do their jobs all the time, so they’re off-limits. The Ringer switch is small, slide- rather than push-actuated, and requires some force to move, so it wouldn’t work well. But the Volume Up and Volume Down switches are both contextually and physically appropriate: they’re unlikely to be useful when you’re taking a picture, and are in a decent location on the side for both left- and right-handed operation without obstructing the lens, and since Up and Down are both controlled by one connected, push-activated rocker, the target is both large and findable by touch. And it would work the same regardless of which side of the camera you’re on. It’s not perfect, because nothing happens when you press the middle of the button, but it seems like the best solution given the constraints.

I’d love to know the reasoning behind the decisions to make these two the way they are. The camera’s shutter button seems like something that could have fallen through the cracks, but the lack of keyboard rotation seems more deliberate. Is there something I haven’t considered?

Related posts

• (none)