Andy Brett

“Freedom to Tinker” is not only an apt title for a great blog; it is also an overarching theme that spans many of the thoughts that have been occupying my spare brain cycles over the past few weeks.

Freedom to tinker can be a wonderful, empowering thing. It’s at the root of every invention, every new business, every mashup (no matter how puerile). It’s at the root of the open source software that I’ve come to embrace more and more recently.

In other words: it’s fun to futz. But not only is it fun - it’s also important and valuable. Robert Pirsig paints a protagonist in Zen and the Art of Motorcycle Maintenance who stands in stark contrast to the other characters in the book because of his ability and, more importantly, desire to understand every last ball bearing in his trusted machine. The trait is timelessly invaluable.

Letting the end users of a product tinker with it has a downside though. Facebook took a huge amount of flak from its users for their most recent changes, but as TechCrunch points out, they should probably just ignore it. “When you listen to your users, you get vanilla, feature creep, boring.” The Getting Real crowd would have similar things to say (about user feedback, not necessarily the UI design).

However, the tinkerers are probably not the ones sitting around whining about the new design. They are the ones building applications to interact with Facebook’s API, or building the next Facebook entirely. It’s important to engage these tinkerers and power users, for entirely selfish reasons. When you listen to your users, you get vanilla. When you listen to your power users, you get the App Store. Not only that, but you get an entire App Store’s-worth of developers who are interacting with your product instead of building a competitor.

Web browsers are another example. In theory, it’s great and completely reasonable to say that people should be able to tweak their browsers, choose different browsers based on their personal preferences and needs, write their own if they are so inclined and able. But it makes life very hard if you’re publishing content and have to worry about how it’s going to show up in 18 different settings. Even if you agree that you should make sure it’s minimally functional everywhere, it’s a giant hassle and takes a lot of the, well, fun out of content creation.

Sometimes it is a legitimate design decision to force a browser choice (or other choices) on the user - for example, the iPhone only allowing Safari. In some ways, it can be just as fun to have an implementation hidden and unavailable to you as a user - this is at the root (and is unfortunately a tradeoff) of the “it just works” approach.

Of course, mentioning browser wars leads directly to the idea of standardization. I won’t delve too deeply into that topic here, but I did have a particular quote stick with me from Stephen D. Crocker’s op- ed in the Times a couple weeks ago, on the early days of the Internet:

Instead of authority-based decision-making, we relied on a process we called “rough consensus and running code.” Everyone was welcome to propose ideas, and if enough people liked it and used it, the design became a standard.

So when is it best to practice strict enforcement of standards, versus letting users play around and “roll their own”? Or is that even the right dichotomy?