Spun

Placement of the “Mark all” links on the WordPress comment moderation page is giving me RSI. I couldn’t interface design my way out of a paper bag, but this one bugs the hell out of me.

I’m the Wicked Witch of the West over on the todo.txt mailing list, smacking down feature request after feature request with “No” and “No” and “quite frankly, no.”

Today I said:

Software can only do so much. Ultimately you want a human at the wheel.

I should have worded it differently. Software can do everything. But you don’t want it to. Software should only do so much.

Being a yes-girl, it’s hard for me to say no to people’s earnest ideas, shared in the spirit of helping others. But Torvalds’ and other great open source developers’ genius was in their ability to pinpoint the good ideas and weed out the bad.

In short, good developers are good editors.

Citing the thesis of The Paradox of Choice, the 37 Signals boys say too many input boxes can paralyze the user to the point of inaction.

Options seem like a nice idea. But each one adds up. Once you realize the evil impact they can have, you start to look at them differently.

They use the embarrassing “Add Event” screen from Yahoo! Calendar as an example of a paralyzing web form, and even though I’ve used Y! Cal for years now, I couldn’t agree more.

My three favorite software interfaces are:

• The Unix command line
• Google’s search box
• Mac OS X’s Quicksilver

And all three have only one input box.

Frederico’s spot-on when he says that Flickr’s frequent error messages are a lot easier to deal with because they seem human:

How many times have you seen Flickr fail? I have seen it happen quite a few times, but something behind the “Flickr is having a massage” message, shown whenever someone tripped on a few cables, keeps me comfortable - it lets me know my photos and those of my friends, are in good hands. It will all be okay, even when something has clearly gone wrong.

I like Flickr’s (and I paraphrase), “Whoah Nelly, hold your clicks! The server’s running HOT right now!” error message which is WAY more effective than “HTTP 500 Internal Server Error.” Just goes to show a little editorial goes a long long way.

Here’s some useful edit-in-place Flickr style DHTML.

Speaking of prototypes, I really dig 37 Signals’ approach: for each web page, on paper, list the page elements needed, group related items together, design each chunk, and then arrange them on the page.

I’m building this thing with some buddies. My current responsibility is the prototype. This thing’s going to use some DHTML and AJAX, and I can envision the screens in my mind, all working in beautiful, usable form, a culmination of all the good interface techniques I’ve seen without all the ones that suck.

So I start to prototype, and I decide I want to totally wow my friends with a nearly-working front end. I’ve only got a few days, mind you - we’re working in 3-day dev cycles. And like an idiot, I wind up getting totally bogged down in writing and debugging Javascript for one little minor piece of functionality that we’ll probably throw out in the end anyway because this is a quick and dirty prototype. End result? Instead of a flashy, nearly-working proto, I had NOTHING to show for all my Javascript screwing around.

Lesson? There is no room for anal perfectionism in rapid prototyping.