tewha.net

I picked up a nice, shiny 24″ iMac on Friday from Simply Computing in Langley for my employer to replace my elderly Core Solo mini. Monday, Apple refreshed the model. I realized I didn’t actually mind at all, but it seemed it might be worth a quick email:

I was just wondering if you guys have some sort of “Apple dropped my model the next business day!” policy. I’m not going to lie here — I’m actually satisfied with the old model, I just thought since the timing was so perfect it was worth a two sentence email.

The result? A $200 in-store credit. Which, bluntly, was more than I ever expected. I didn’t have to lie for it, which is good because I wouldn’t have done so. All I had to do is ask.

Thanks, Simply. That was a classy move. I really respect these guys. They’re honest, practical, and not out to screw anyone.

Allen Pike posted on the silliness of Yes/No and OK/Cancel a few days ago. Today, I saw the best example ever of poorly-named buttons. This is pretty typical of installers, sadly.

See, the problem here is not so much the buttons as the question. It’s true that people rarely read the question, but this is probably one of the cases where you can make it simple enough that they would.

“Stop installing?”
“Yes” “No”

But wait: Why has the user clicked this button? How likely is it that a user really wants to stop the installer completely, as opposed to being unhappy with a choice they made?

“Stop install without finishing?”
“Quit Installer” “Start Over” “Keep Going”

As an aside, decide on your terminology and stick with it. In the above, we have cancel and abort. Abort’s real world meaning is potentially a painful reminder to users. This never should have entered the software developer’s lexicon as an acceptable user term. Standardize on stop when an action can’t be rolled back and cancel when it can.

Posted without comment, because what could I add that would make this funnier?

A coworker posted on Firefox 3 and Mac addicts, and mentioned:

Other than background windows looking like foreground windows, all of his issues are either extreme power-user features (AppleScript support), things that are easily arguable (clicking on the URL bar selecting the URL), or things that Firefox could quickly steal from Safari and should make everyone happy (submenus with additional history items in the History menu.)

I started this as a comment there, but I wanted to expand it more. Now I know what he meant, but I don’t like the word “arguable” in that sentence. He suggested “subjective,” but I think that makes it worse.

Interfaces are thought out or not. Interfaces can be made simpler or more complicated, in one aspect or another. Often simplifying one aspect will make another more complicated. But interface design is neither arguable nor subjective. Instead, the effectiveness of an interface is something much simpler: measured or not.

In user interface design, the impact of an interface can be measured across your prospective user base. It may not be practical for you to do so¹, but it can be done. That means it’s not subjective. Don’t write something off as “arguable” — if it matters, determine the truth.

This is not to say you can determine the perfect interface by measuring, but you can determine the superior of two interface designs.

If it’s something your users will feel strongly about and there’s significant disagreement, make it an option, but that should be reserved for cases where it’s really important to the user. But that’s tangental: User preference for interface varying for a particular user doesn’t mean interface design is subjective. And I think a good first pass is to default to least astonishment — which in today’s world, will mean consistency with the spirit of the platform you’re targeting.

1. In fact, this is probably the rule rather than the exception. [↩]

Good post in 37signals’ Signal vs. Noise today that Communication usually fails, except by accident:

Osmo Wiio is a Finnish researcher of human communication. He has studied, among other things, readability of texts, organizations and communication within them, and the general theory of communication. His laws of communication are the human communications equivalent of Murphy’s Laws.

I don’t have much to add to this, except that it’s mildly depressing, because it’s probably true.

A Wikipedia article on Unusual software bugs. Imagine how relieved you’ll feel next time you chase a bug in your software for hours only to find it was an input data that what you’ve discovered has a name: a Stotle. Also describes Heisenbugs, Bohrbugs, Mandelbugs, Schroedinbugs, Phase of the moon bugs, Statistical bugs and the Ghost in the code.

I know the site looks like crap! I’m working on it. It just took longer than I realized it would to restore functionality after a series of blunders on my part.

In the meantime, the RSS feed continues to work very nicely.

When an application crashes in Mac OS X, there’s a dialog box that appears to inform you of it. It mentions that no other applications are affected. This irritates me every time I see it. Honestly, I thought they’d remove this before 10.0 went final. It meant for a nice “Oooh, ahhh!” moment at WWDC in 1998 or so, given a crowd of Mac OS developers, but has been meaningless ever since. This is expected behavior in a modern operating system!

(Hi-lighting added.)

This is from Xcode’s Interface Builder. I’ve never seen a more polite assertion failure. It even asks if it’s okay to crash. You don’t see that very often. And keep in mind this is for a tool used by software developers. What’s our excuse when developing software for regular users?

And yes, I’m going to choose Crash. They asked politely enough.

Now that Internet Jackass day is over, I can share my favourite April foolery. From the April 1, 2004 edition of TidBITS: iChat AV 2.2 Public Beta Adds MSN Support. I read this one in isolation from the rest of their April Fools edition, and it was subtle. I spent a few minutes looking for the beta before deciding it had been withdrawn. It took me months to realize it was all a joke.