Enable Float Alignment
I originally published this on February 20, 2007 on the Obvious (1.0) blog.
So, you’ve got a feature idea for your personal content product that’s going to make everything better for everyone. As a for instance, let’s say it automatically converts quotes (“) to smart quotes (“). You build, test and release it and eagerly await to receive praise from your users.
The first comment you see is from someone who says “I hate these ugly quote marks! Why did you screw with my text! I quit!”
So now you have a new feature to code called the “Disable Smart Quotes (Yes/No)” setting.
How much leeway do you have to change behavior without introducing an opt-out setting? How do you weigh your responsibility to unhappy users against a desire to design for the better? And can you avoid a nightmarish collection of obscure settings that don’t mean anything to 90% of your user base?
It’s a really tough call and I’ve frequently advocated building the opt-out setting. As an example, we built a shiny new rich-text editor in Blogger that did all sorts of fancy things. Unfortunately, it also did some things to the post output that folks found unexpected. In fact it completely broke a number of uses of Blogger where people were taking the raw post content and plugging it into another site.
After reading a number of agonizing anti-testimonials, I felt we had to introduce a way to suppress the undesired output. Sadly, we couldn’t even come up with a name that made sense for this “feature” so this is what we ended up with:
Not very awesome. But it was a better option that “Did our feature break your stuff?”
Perhaps as a result of Enable Float Alignment, I now feel designers should be a little more firm in creating just the experience they feel is best overall. This makes especially good sense when your product is young and the unanticipated uses and edge cases are more limited in number and in type.
This isn’t an excuse to go around making dumb changes in behavior. But I’ve found that folks will adapt and that change sometimes seems more disruptive when initially introduced.
In the worst case scenario, you end up losing users if you don’t include an opt-out. But introducing those (yes/no) settings, while hopefully cheap in effort, also carry a cost over time. In the case of EFA, we had to build it a 2nd time when we created the new version of Blogger. You’ve also introduced the possibility of interaction bugs with new features down the line. More importantly, every time a user goes into your settings, they need to parse an increasing number of niche options thereby distracting them from whatever task they wanted to achieve.
I feel the better option is to thoroughly consider how your change in behavior is going to affect the different types of users you support. And introduce opt-out settings sparingly, if at all.