Applauding Decision

Designing “Mute”

I didn’t comment on the latest Apple-du-jour controversy, this one surrounding the mute switch on the iPhone. (I always wonder if it had been a BlackBerry whether anyone would have paid attention.) Frankly, Marco Arment said exactly what I would have said. Good design means trade-offs and settings mean indecision. Sometimes that indecision is appropriate but we can’t, as developers, punt on every trade-off.

When I write software there are millions of small and large trade-offs. Everything from where to put a button to whether to include a feature. I hate trade-offs like the mute switch because I hate “except” features. You know: it mutes except… I think it is hard for customers to remember the except clause and know when to apply it. And it’s even worse when you add an “if” statement. IF the setting is A then the mute mutes everything and if the setting is B then it is mutes everything except. That just doesn’t work. So as a designer and developer, I must make the decision. Did Apple make the right one? As Marco points out in this week’s podcast, it hasn’t been an issue for 4.5 years so they must have.

Speaking of Marco’s podcast this week, he also commented about leaving out features that just don’t fit into the product correctly. I’ve done the same thing with powerOne. The most requested feature is folders for organizing templates. But every time I revisit the feature I can’t figure out a logical way to make it work successfully. Sure, I can slap folder support in but it doesn’t feel right to me. I’ve implemented a handful of variations and still don’t like it. So I don’t include it until it feels natural and the logical way for powerOne to organize its calculations.

Bottom line: every decision made when designing software is a trade-off. Making the right ones is the hard part. And that’s why we get paid the big bucks!