Archives for the month of: March, 2009
« Older Entries

OS X: Bad control choices in Print dialog

March 30, 09 //
0

Once you establish a pattern, stick to it. This one was pointed out by @deeann and @geekosaur, and I had forgotten how awful it really is, I’m so used to it now.

First, Apple decided that the “Save to PDF…” button needed more options, and instead of replacing the command button with a proper drop down menu, they added a glyph to a command button:

03302009210051.jpg

03302009210059.jpg

I really, really hate it when people break standard controls like this, especially OS vendors in global dialogs (and in this case Apple is as much to blame as the usual offender, Microsoft). Predictability is a key tenent of usability: once a user learns how a control behaves, they expect every similar-looking control they encounter to behave that way. This example is particularly bad, as there is a standard control that does exactly what they want.

Full disclosure: I’ve had occasion recently to re-design a drop-down, but it’s for an extraordinarily specific purpose, we’ve styled it very differently from the standard, and use them in enough places (a sort of global-to-System Center) as to establish a pattern. Still, we all agree it’s a gamble and will be tested before it’s released.

Of course, Apple just made a lazy, arbitrary decision and called it a day, something they do too often for my taste.

That’s not the only problem with this dialog. Look at the arrow to the right of the Printer: drop down:

03302009210051.jpg

What do you expect it to do? @geekosaur assumed it was a list of recently used printers. I think that’s an entirely fair assumption. It’s not correct though, as the arrow serves as an expander to reveal more printing options and show a mini-preview:

03302009210115.jpg

So why the hell is it next to the drop-down? The proximity creates an implicit tie between the two controls, even though they are not functionally related at all. Here Microsoft gets it right, using a pattern specifically for expanders (the chevron) and often giving it a label like “More options…” I like them a lot; here’s a particularly good example, from the Vista global Save dialog:

03302009214711.jpg

These are fairly minor, and fairly easy to figure out, but I really expect more from a global, OS dialog, so it graduates to an EPIC FAIL.

Survey: Name the Broken Picture Telephone fail image

March 30, 09 //
2

Twitter’s got the Fail Whale; There’s the Sad Mac. What clever name should this thing get? Leave your suggestion in the comments, and we’ll have a poll with ‘em in a couple days.

03302009204308.jpg

Twitter: Silly error message

March 30, 09 //
0

When does friendly become patronizing? One of the better innovations of the Web 2.0 movement has been to bring a friendlier, more conversational tone to instruction and error message copy. I agree with 37Signals, who make the point in Defensive Design for the Web (which should be mandatory reading for anyone in web UX, btw) that sometimes this colloquial style is inappropriate, and backfires by being patronizing instead of friendly. Here’s a good example I came across the other day:

03262009195450.png

First, Twitter is “stressing out” all the fucking time lately, so while I’m not surprised by this message, I’m irritated by this vague sentiment, which immediately brings to mind some old shitty clip-art of a guy sitting at a desk, chewing a pencil, with a three-foot-tall “In” box (go on, you know the one I mean). Suddenly, I’ve gone from sympathetic to pissy, since the only reason I’m given is a human emotional state applied to a machine.

Better: Be informative, be specific, be honest. How about “Sorry! In order to improve overall performance, we’ve temporarily disabled this feature. Contact support if it’s an emergency.” See? Still friendly, but useful and (most importantly) apologetic.

Save the charming, whimsical tone for the sign up process, when you’re trying to win my business. Fail!

MacHeist: Atrocious, extraneous visuals

March 30, 09 //
0

Apparently, MacHeist is from a planet where they don’t have the phrase “tone it down.” Just look at this:

03262009195401.png

Are your eyes bleeding yet? Mine are. Now, I really like MacHeist; it’s a fun idea, and I’ve bought their bundles (and will probably buy this one). But this design is just so, so terrible I couldn’t help but rag on it. Now, it’s certainly not ugly, but is so overdone, with every possible Mac cliché and whiz-bang useless feature they could cram in. The icons zoom on hover (like a Dock, or something, I guess). The next/back buttons show big icons (since, I guess, the huge grid of icons dominating the page isn’t enough). Elements use shadows and border radii (that, of course, are only coded for WebKit). Everything has a single URL, since the main content area slides in. There’s more, but I can’t stand interacting with the site any more.

The worst part, though? The page comes in at an astounding 2.2 megabytes. I shudder to think what their bandwidth bill is.

Next time around, let’s hope they take the most important OS X UX lesson to heart: less is more. For now, Fail!

Jeopardy!: Brilliantly forgiving input

March 30, 09 //
0

Put on your nostalgia hats. After the spectacular letdown that is the Oregon Trail iPhone game, I decided to figure out how to play the real version I did as a kid. Long story short (too late!), I got a nifty Apple ][ emulator and got it going. I also found a verion of Jeopardy! from 1987 that has one truly great feature: forgiving text entry. As you can see in these examples, it takes into account that a correct answer might take a different format than the database has. My response is on top, the database’s version below in parenthesis:

03302009102956.png

Does it use a heuristic algorithm? I sort of doubt it. I have a feeling there are just hard-coded variations associated with each response. This flexibility surprised me. I’ve learned from painful experience that these sorts of things— even these days— often take the shortcut of comparing the string entered literally, throwing errors for all manner of “mistakes.” I think the classic modern example is a phone number entry field in a web form. Sometimes it wants (XXX) XXX-XXXX, sometimes XXX-XXX-XXXX, and so on.

The right choice in the phone example is to accept any format and convert it into whatever the data storage system on the backend needs, placing the burden on the computer, not the user. After all, this is what machines do best. Humans, not so much.

The Jeopardy illustration provides great fodder for any developer who balks at building smart input processing mechanisms: If they could do it twenty years ago, on a primitive (by modern standards) system, why can’t it be done now?

Forgiving text input: Epic Win.

« Older Entries