zarro boogs found

I run into this in Bugzilla from time to time, where people don’t understand why I don’t want to take code for an alternate UI/feature (pref-driven of course). There’s arguments about code size “its only 12 lines” or “its a hidden pref, users won’t be confused by it” which are often both not the case. The politics of inclusion in OSS are bad in many places, where a well-written patch is hard to dismiss, especially if it doesn’t affect default operation. Aside from code maintenance/QA issues (more codepaths to maintain/test) there’s a failure in design if you have two polarized methods to get a result. Even more so if you have multiple distinct UI setups depending on a pref.

As an example, lets use the Firefox download manager and how it evolved over time. Starting with Seamonkey, there was a choice between IE-style progress dialogs and a single window download manager. The manager wasn’t especially nice/usable, and hung around until you closed it. It also didn’t do a few other things that people wanted out of it. Phoenix 0.5 had a download sidebar as an option instead of the manager, which was even less functional than the dialogs, so few people used it. With Firebird 0.7 Ben came up with a single download interface, a new download manager with various privacy options and the ability to close on download completion, and it wouldn’t open until a short delay (to avoid the “Your download is finished” popup effect). There was a lot of negative feedback, initially, to the loss of the IE-style dialogs. However, the change stuck, and incremental improvement has meant that most users are ultimately happy/okay with the combined solution.

By combining the best of both worlds, and working to refine the idea, we ended up with a single implementation to maintain, which I think is better than any of the three implementations we had before. Being forced to make a solution work for a wider audience, instead of splitting our users, allowed us to refine a concept that was relatively stagnant. The end result, while obviously not everyone’s cup of tea, is a better solution for more users than any of the old solutions, resulting in a better initial experience for users.

This is why adding hidden preference X to do Y to solve Z is a problem. It removes the impetus to fix the problem that Z presents for the about:config-deficient. If we can come up with an alternate solution, on by default, that eliminates or at least mitigates Z for all users, then we provide a better experience for all users, not just those fortunate/saavy enough to find out about the hidden pref.