?

Log in

No account? Create an account

t3knomanser's Fustian Deposits

User Momentum

How Random Babbling Becomes Corporate Policy

run the fuck away

Mad science gone horribly, horribly wrong(or right).

User Momentum

Previous Entry Share Next Entry
run the fuck away
The new version of Firefox is providing an object lesson on user momentum.

Momentum is mass * velocity. Velocity, as you might recall from high school physics, is a "vector" quantity. That means it has a magnitude and a direction (if you're driving the speed limit, your speed is 55 miles per hour; your velocity is 55 miles per hour due north).

User momentum is user-base size (mass) * workflow (velocity). Firefox, as an application, has a fairly large user base. This user base is biased towards more technical minded types, people who know their way around a computer (let's face it- your average luser is going to just use IE). A technical user is the kind that tends to develop a consistent workflow.

The "AwesomeBar" haters are those kinds of users. They've developed a specific way of working (direction) and gone far down that path (magnitude). They're a subset of the overall Firefox user-base, but big enough, with enough magnitude on their workflow that they've got a lot of momentum.

Newton's First Law tells us that "an object in motion tends to stay in motion unless acted upon by an outside force"; e.g. momentum can only be changed by force. How does one apply force in this case? Well, Mozilla hit the nail on the head: they took away the old address bar behavior entirely. There's no legacy setting, no way to disable the behavior (without disabling all address bar behavior). That's force.

And Newton's Third Law tells us that "for every action there is an equal and opposite reaction". The reaction, in this case, is backlash. "This sucks, I'm going back to FF2." "Mozilla's driving users like me away." Hundreds of angry postings in hundreds of blogs rattle their "I'm dropping Firefox" sabers.

Now, imagine if you will, a train moving down the tracks. You stand on the tracks and attempt to apply force and stop the train. Obviously, you're going to lose: the change in force you have to apply must exceed the momentum of the train (mass * velocity). You can't stop a train. But you can stop a rolling bowling ball. Or a thrown football.

The important question here is: does Mozilla have enough force to counteract the user momentum? Is Mozilla stopping a train, a bowling ball, or a frisbee? In this case, I think it's a frisbee. I think the largest mass of the users (myself included) look at this AwesomeBar and think about how we can work it into our workflow. Either the direction of our workflow isn't too far from what the AwesomeBar tries to do, or the magnitude of our workflow isn't so great. We're willing to change. A subset of the total user base has a great deal of momentum, and there are only two options to deal with them: you apply force to bring them in line (remove legacy compatibility) or you cut them loose so they don't drag your project behind them.

At any rate, after work today, I'm probably going to put together "Remy's Laws of User Motion" to better explain how user behavior can be managed using physics as a metaphor.
  • I just set the drop down list to zero so I don't see it. It's a half-fix.
    • I actually really like the AwesomeBar. I spent about ten minutes touching up my bookmarks with tags, and now I can get pretty much any address I routinely use with a few keystrokes.

      It's really just a matter of changing habits slightly. I don't miss having to use the first few letters of the URL where I can use a meaningful tag instead.
      • That feature's not so bad. I'm referring to its auto populating the list with anything from your history and how it takes up so much room by showing not only the url but also the "title" it has cached. That's the irritating part for me.
  • This is brilliant. For the record, I actually use the dropdown feature of the address bar in Firefox 2 on occasion, so I doubt the AwesomeBar will get up my nose much at all. But then, I'm not really what I consider a power-user -- I've tweaked Firefox with the extensions I find useful, and it makes me happy. ^_^ I have no driving need to get under the bonnet; since it ain't broke, I don't feel the need to fix it, just customize the hell out of it.

    (Speaking of extensions, that's the one thing that's been keeping me from getting 3 right away -- will the ones I use work with it? I think most of them are already functional with Firefox 3, but I may still wait a day or so before dl-ing and installing it.)
    • I'd wait a few days. I'm using some unsupported hacks to force my extensions to run even though they're not 100% compatible. At this point, most of the big ones are compatible, but I don't know which ones you're using. In the Add-Ons screen, you can get to the homepage for each extension, and that should give you an idea.
      • Only two of mine are not working -- "copy as plaintext", which is minor but oh so terribly useful, and "tabbrowser preferences" which is really driving me crazy that it's missing.
  • AwesomeBar hater here.

    I got to this post through a Google search for how to disable the AwesomeBar. I thought I'd let you know my reaction. And here it is:

    I'm amazed and appalled by the attitude you and the Firefox devs exhibit on this issue.

    We AwesomeBar haters aren't trying to ruin the party for all of you out there who like the AwefulBar (and I recognize that you guys are probably the majority). We're not trying to get the AwefulBar removed, we're not even trying to get it disabled by default. All we are asking for is to have an option -- hide it away in about:config for all I care -- to turn the damn thing off and go back to the de-facto standard behavior.

    Instead, all we get is this patronizing attitude from you and your likes: "you apply force to bring them in line [...] or you cut them loose [...] user behavior can be managed [...]". This attitude is fanning the flames. It's my behavior you want to manage here, and you will understand I am somewhat upset at the premise.

    Where does this machoism come from? I just can't for the life of me see why you would want to "manage" our "user behavior" instead of letting us work the way we want to. Even if it's because, yes, we are fixed in our habits. They're my habits and I like being fixed in them just fine, thank you. I can't see why it would be so painful for AwesomeBar fans to have the 10 lines of code that are necessary to bring back the old behavior as an option (according to Mozilla forums) reinstated. If enough users want it, why not give it to them instead of going on with this massive re-education campaign?

    It's a storm in a teacup, I know; in a few days someone will come up with an extension that disables Awefulbar completely, or there will be a custom build of Firefox. Still, as a long-time donator to the Mozilla Foundation, I am profoundly offended by your post, which implies that I am somehow a less worthy user than you, to such a degree that I need to have my browsing habits forcibly "managed".

    Yours (staying with FF2 for now ;-)),
    Satin
    • Re: AwesomeBar hater here.

      "It's my behavior you want to manage here, and you will understand I am somewhat upset at the premise."

      All interactions between a dev and a user involve managing user behavior. Any time there's a feature change in an application (like adding, say, a spell checker to Firefox) you're managing user behavior. Even if the users are overwhelmingly pleased by the change, you're managing user behavior.

      "instead of letting us work the way we want to"

      It's about deciding what you're going to support. An organization like Mozilla does not have unlimited developer resources. I'm dubious about that "10 lines of code" claim- if it's true, that's a bad sign about the underlying structure of Firefox. Even if it's true now, it certainly won't stay true moving into future versions.

      First, you have to establish the UI for managing your browser bar preferences. Which tab of the preferences window does the switch go on? What's the caption? Are we going to have a switch, or could we get away with just making it one of those about:config switches? In that case, what's the name going to be? Now, how are we going to use that switch in code? What we don't want is a lot of if (legacyBarSwitch == true) because that's bad code and hard to maintain. We'd probably want to use the state design pattern, which means we either need to make a new object or one of our existing state objects. How do we regress that in the code? What's the test plan going to be? What about extensions- what happens when someone has the LegacyBar on, and they install an extension that is meant to interact with the AwesomeBar- what's the proper behavior in that case? What about key security features that depend on the AwesomeBar's UI widgets, like EV-SSL certificates? The quick access bookmark manager? What are the security risks (every design decision has security risks that must be managed)?

      It is not just ten lines of code.

      From the standpoint of a developer, you're requesting a feature. FF3 pushed with a featureset, and you want an additional feature. You don't want an old feature- the LegacyBar was never part of FF3- you want a new feature. So now, Mozilla has to answer the question: given our future plans for Firefox, given our design model for all of the new features (LegacyBar pretty much makes tagging your bookmarks and the star button next to useless, since the whole point of using those is to get links to show up in your AwesomeBar), given the resources we have available, given the user demand, is this feature worth adding?

      Apparently, the decision is: "NO".

      "I am profoundly offended by your post, which implies that I am somehow a less worthy user than you"

      I'll point out that you probably aren't the target audience of this post. For background, I'm a developer. I work for a large company doing in-house software, and one big part of my job is managing user behavior. That is to say, deciding what features they get and why and who can access them. When we change a user's business process (even when it simplifies their work, reduces costs, improves auditing standards) there's resistance. In this case, I was using Mozilla's work (something that's publicly recognizable and can be discussed in a public forum) to illustrate things I've noticed about changing software for users in my work (which I can't really discuss in this forum).

      The point is, at any time a developer releases a changed product, they have to deal with the user response. I'm trying to put together a framework for understanding: why users respond to changes, how to predict the response, how to respond to negative feedback.

      When I'm talking about managing user behavior that's what I'm talking about. It's not worth it for Mozilla to support a small group of users even if they have a high attachment to their workflow. Mozilla is a big enough application with a massive enough user base that any minority, even one with a great deal of momentum, can't (and shouldn't) drive decisions about featuresets.

      Which brings me back to my conclusion: you apply force (refuse to add a feature) and wait for the users to develop new habits or leave your user base.
      • Re: AwesomeBar hater here.

        (Anonymous)
        "It is not just ten lines of code."

        Actually, the FF3 algorithm uses the old one, with one change. Then adds more stuff (Bookmarks and so on) and intermingles the results. The one change is searching the entire URL and title/description for what's being typed, rather than just the beginning of the URL.

        If it was well-written, I can see it being added with just 10 lines of code. Possibly even less.
        • Re: AwesomeBar hater here.

          I doubt it. You need code to manage the preference option, code to detect and decide what state you're in, code to manage extension behavior, style behavior. Now, add in testing, maintenance, regression, future code branching and suddenly this doesn't seem nearly as trivial as you make it.

          Could the feature be added with ten lines of code? Probably. Could it be added in a user friendly, supportable fashion that also supports future plans for address bar improvements with ten lines of code? Almost certainly not.
Powered by LiveJournal.com