I’ve seen several comments all over the place asking why we couldn’t, in Firefox 3, provide an option for users to revert back to the old UI for many things; or, my personal favorite, default to the old UI and make the new UI optional. Today, my goal is to explain why we don’t do this.
I’ll start with the second one since I enjoy it so much. The thing with new software is that users expect something new. If you default to the old UI, your user base is going to wonder what exactly you did in this new release, and why they even bothered upgrading. This only applies to major updates though, as people generally don’t expect anything new out of security updates. This user expectation is why we’ve had some form of visual refresh in almost every major update (at least as long as I’ve been following the project).
Now, why don’t we provide a way to get back to the old UI via a preference (even if it is just a hidden one)? There are actually a number of reasons why this is a bad idea:
- Performance
- Code bloat
- Test coverage
- Feature bloat
Each time you add a preference, you make that code run a bit slower. In many cases the overhead of dealing with preferences can be dealt with more code, but then you end up with a new problem – code bloat.
Code bloat may seem insignificant to an end user, and it probably doesn’t matter too much to them. That is, until you factor in the fact that more code means more that the developers have to worry about. All that extra code means bugs are more likely to be introduced, and new features take longer to add. Extensive test coverage can help prevent the bugs from creeping in, but it won’t help with new features being developed.
Test coverage doesn’t seem like a big deal when it comes to optional features. “Big deal – you just have to have a few more tests for those options,” right? No, not really. In reality, the code better have every combination of options tested to make sure they work well together, otherwise the bug reports and complaints will come flying in. Now, my probability and statistics is a bit fuzzy, so I hope I’m getting this math right. Let’s say you have just four features, each with only two options. There are 24 possible combinations, or 16 possible combinations that you have to test for. You can see how quickly this will blow up once you start adding more features to test for, as well as more options per feature. It gets pretty ridiculous pretty fast.
I leave feature bloat for last because there are people out there that will disagree with me on this being a bad thing. Giving users lots and lots of choices can quickly result in confusion. Having confused users is a bad thing, because it will end up driving them away from your product. As a result, we try to keep things simple, but at the same time make them useful for the majority of people.
All is not lost, however! The beauty of Firefox (and the Mozilla platform in general) is the extensibility of it. Say you don’t like the new download manager UI – it’s pretty easy to create an add-on that uses a totally different UI. I made sure of this when we were doing these changes. It may not be as easy elsewhere in the application, but there is almost always a way to customize it with an add-on. This is what has made Firefox so successful – if you don’t like something that most people are OK with, you can change it. Keep in mind, there are many core features that were first developed as add-ons (like session restore, the new theme for OS X, the download information in the statusbar).