Change is Expensive

Firefox Button

One of the statements that keeps getting thrown around in the discussion about the Firefox rapid release process is that because the releases are every six weeks, there isn’t really enough time for any major changes. This statement is patently false, and there’s an easy way to prove that – the Firefox button.

The Firefox button was a huge change for Firefox 4. I would wager it cost (or will cost) companies across the world tens of thousands of dollars (or more) in rewriting of support scripts, redoing of screen shots and actual support calls.

Let’s assume for just a minute that the switch to the Firefox button had been done within the context of the rapid release cycle. How would it have happened? Could it have been phased in? Could it somehow have been done across multiple releases? No. The answer is that between two “minor” releases, the change would have simply been made. What’s the takeaway?

Whether or not a change is major or minor has nothing to do with time. It only has to do with the change.

So how do you mitigate a situation like this? I’m glad you ask. You do what Microsoft did and provide a Group Policy (or preference) to turn on the menu bar by default. This allows the browser to be deployed without taking this change. I received quite a few emails when Firefox 4 was released with folks asking this specific question. I had to tell them that there was simply no easy way to do it in Firefox without writing an extension. I considered adding it into the CCK Wizard, but simply haven’t had time.

We’ll finish with a story. Last week my wife finally bit the bullet and upgraded from Firefox 3.6 to Firefox 4/5. She’s technical and has been using web browsers for 10+ years. Her first comment? “Where did my menu go?” I said, “Everything is in the Firefox button now.” She said, “I want my menu back.” So I showed her how to get rid of the Firefox button and go back to the old menu.

You’re messing with 10+ years of muscle memory here. Change is hard. And expensive.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

16 thoughts on “Change is Expensive

  1. And while you provide one claim for going back to the old menu – I can provide examples from users (barely technical types) I support who just wanted to know where some commands moved to (principally Print) and didn’t much care about the change. Some people are more resistant to change than others – I’d argue that the more technically minded someone gets the more resistant they become, at least for things that are in their direct workflow.

    Not sure your story supports your point – since you’re conflating corporate use cases of potentially needing to delay taking a change – at least I hope its delay and not an expectation to support it forever – for support reasons and a home user preference.

    Implementing the Firefox Menu was for consistency with Windows 7 where more applications include such things – not a whim of the UI team. It will be interesting to see how “major” UI work gets handled in the context of rapid-releases – though at the same time the pressure to produce something strikingly different is much less when you release so often as opposed to once a year or longer.

    • No, my story was more anecdotal.

      The point I was trying to make is that when these types of changes are made, they have more far reaching effects than people realize.

      When you’ve trained thousands of people to do something a certain way, and then you change that method, there’s a cost. Microsoft understands that cost and provides ways to maintain the old way and move to the new way independent of the browser version.

      I understand why the change was made. I think the lack of a simple preference to maintain the old way was a huge oversight.

      This is why the Enterprise Working Group is important – it makes developers aware of things that probably never occurred to them.

      • Yes, but the rapid release process will probably shape the ways we design, implement, and message user-visible changes. Look at the way Chrome’s UI has evolved in the past twelve months, for example. There are lots of ways that UI development can adapt to better fit into “minor” automatic releases every six weeks.

      • yes, but in cases like the menu structure we will try to group them all together into one change. So that single minor release is (in terms of UI change) effectively a major release.

        • also to clarify relative to Matt’s comment, anything that is more of an evolution (like the introduction of a new feature, or an otherwise aesthetic change) we can streamline into the next rapid release.

  2. >One of the statements that keeps getting thrown around in the discussion about the Firefox rapid release process is that because the releases are every six weeks, there isn’t really enough time for any major changes.

    Another reason this is false is because major changes can (and do) take place on project branches, which will only land on mozilla central when they are roughly complete.

  3. Actually, the one that irritated me most on first using FF4 was the disappearance of the bookmarks toolbar. It’s a feature I’ve relied on for a long time for one-click access to commonly used sites and a handful of bookmarklets, and while I found that it could be re-enabled trivially enough, it’s absence by default perhaps doesn’t bode well for it long-term…

    • In response to your concern Simon, I share it. The Bookmark Toolbar is now perceived as ‘cruft’, even though there’s no equivalent alternative. The idea of making it an add-on was banded about but I’m not sure anything ever came of it.

      It’s still here which suggests that perhaps the (vocal) complaints I put forward were considered. There is/was a bug about it but I’m at work so I don’t have the time to find it.

  4. I like how you try to refute something I happen to defend that is that the rapid release cycle delays (not forbids, so don’t go strawman please!!!) major changes with a major change that was implemented on a release that took 1.1 years to come out. Nice.

    You want to understand why rapid release cycles delay innovation and evolution in Firefox? (No, I won’t say look at Chrome, though you can, and you will understand) Because there is less time for a feature to land every time the landing window appears, it’s not as likely that things will get fixed if some sudden unexpected problems appear, so the feature will be dropped and delayed until the next release. Except MEANWHILE everyone’s worried about testing the new features that actually don’t have unexpected problems and that will tend to be minor features or changes (because those are the ones that are less problematic) and when the time comes for the new landing window, likelier than not the problems will still not be fixed in time.

    Effectively, we’ve changed from a months long beta stage into a week. Seriously, what do you expect to do in such a timeframe?

    Where’s the account manager? Nowhere.
    Where’s the profile manager? Nowhere.
    Where’s the fully implemented doorhangers? Nowhere.
    Where’s the fully implemented in-content UI? Nowhere.
    Where’s the redesigned preferences screen? Nowhere.
    Where’s the home tab? Nowhere.
    Where’s the target URL display? Jumping all around the place.

    And all this while we’re getting stuff like impossibility to drag a tab without focusing it, impossibility to close them without focusing them above a certain whatchmacallit. Nitpicking of the buttons. Nitpicking of panorama… Because that’s easy to do. They are easy bugs to fix, and that’s what we’ll be getting from now on. Sure, we’ll also get major changes, but they’ll take much longer to see the light of stable.

    Care to refute this?

  5. “Change is hard, and expensive”.

    Have you ever asked yourself if change is always a good thing or a step forward, or are you disallowed to ask yourself this question due to economical idea(l)s ?

    The only thing that grows with time is the date on the calendar, some people expect any “bigger” date is a bigger succes and a better thing as if they bathed you guys in this “ideal”.

  6. I agree that Change for Change sake is not necessarily always a good thing. I remind my teams often, “Just because we can, doesn’t mean we should.” That’s applicable whenever someone shows me a new knob, widget, feature/function “improvement” and then wants to deploy it across the enterprise. I challenge them with, “What business problem are you trying to solve and how will this new feature advance that goal?” If they can answer that question with more than “because its cool”, then we can enter into a conversation on how to best design an innovative solution. I don’t want to squelch innovation, I want to direct innovative thinking toward problems that matter.