I was reading the comments thread on Slashdot about the new Firefox UI design. One comment referenced a mozilla bug, “418864 - Bookmark contextual dialog is not resizable.”
One comment reads: “I think it’s a poor design not to provide the user an option to [..] revert things back to the way it was before in older Firefox version.”
Regardless of whether or not the bug itself is worth fixing or not, I think this specific sentiment is actually dangerous. I’ve noticed a growing amount of it in the discussion threads surrounding Firefox UI design.
It’s dangerous because it means for every new feature or modification to the UI, the cost doubles to include a legacy code path. Over time, the effect of this is that the codebase bloats without bound, beyond the capabilities of your testing staff and quality slips. It’s dangerous because this raises the opportunity cost to explore new UI designs. As a result things change less.
What has made Chrome successful I think in UI design is that we have pushed hard to retain a consistent core vision that the team at large understands but where the design is done by a smaller core group. Glen mentioned to me once that his theory is that the more people you add to a design process the slower it becomes and the less productive output you yield. This might seem at odds with Mozilla’s “inclusive” approach to software development but I’ll just note that in the early days of Firefox the team was much smaller, and as a result could make rapid progress. There were times when various elements within the community wanted something and the answer was simply “no” - no option for the old way, no promise to support it via extensions. If you can make it work, good for you. But that’s the cost of progress.
These days, Mozilla has some talented visual designers contributing to it. The challenge for them will be to give them the creative autonomy and the ability to say “no” so that the UX aspect of the project not to get mired in quicksand.
