Tuesday, May 1st, 2012
Firefox 12 was released last week.
One of the main features the release sports is “totally silent updates,” following Chrome’s path of “web-based version numbers”1 and going out of the way to obscure this information.
It will be interesting to see how this plays itself out.
Firefox 10 took us into the land of “always compatible” extensions2. Now with the obscuration of the act of versions changing, I wonder if the end-user’s experience will start to tend towards a more randomly-broken web browser, and users being confused why the extensions they were using yesterday are suddenly just-not-working today.
These are problems Chrome seemingly never faced, because they don’t have the rich ecosystem of addons that Mozilla does. This isn’t a particularly insightful revelation and I’ve even discussed it previously. I guess I’m still talking about it because I’ve never understood why Mozilla Corporation did it, beyond “because Chrome did it3.”
In any event, I recently got thinking about versioning again because of a conversation I had with a friend last week about version numbers and mobile.
We were chatting about our phones, and I mentioned I recently upgraded to iOS 5.1, having waited a bit to see how the update shook out on my friend’s iDevices.
He replied he’d been waiting for his carrier to roll out updates to “Ice Cream Sandwich.” I asked my friend—a college-level computer science instructor with a master’s degree in the subject—what version that was, and how it was different from… the previous version.
He answered “Oh… I don’t know. 2.3? 2.4?”
(It’s 4.0.x, actually.)
Thinking back to the features I use that were changed and updated in iOS 5.1, I said “Oh. Well… what’s different in the new release? What are you looking forward to?”
“Oh… … I have no idea. It gets stuck less in your teeth than Honey4 and is more satisfying on a cool day?”
The whole conversation was yet another great illustration of the point: not only do version numbers continue to matter… they matter in a marketing context.
They make it easier for your users to talk about your product in meaningful ways.
Obviously, number schemes are easier to test for equality and ordering, but they also can communicate the magnitude of change: an update from iOS 4.x to 5 communicates at a very intuitive cognitive level that the change is bigger than an update from iOS 5.0 to 5.15
These are important aspects when users want to identify, discuss, compare, and contrast features, stability, bugs, and overall usefulness of the products they use and (hopefully!) love.
After it was clear that our conversation about his Android phone simply didn’t have the adjectives necessary to meaningfully discuss, we moved on.
But my confusion remains: I still don’t understand the push (in certain circles?) to make our users’ conversations more difficult than they need to be.
_______________
1 aka “no version numbers”
2 Even if, y’know, the extensions are actually totally unusable on the new version
3 I can hear my mother saying “If Chrome jumped off a bridge…”
4 I think he meant Honeycomb
5 Some may point out that these numbers have sometimes been contorted to serve a business end; it is true this happens all the time; that’s a problem that solves itself when customers get burned by it too much.
strategy, versioning
Preed on Build/Release Engineering | 3 Comments »
V1103
Thursday, August 18th, 2011
I wasn’t going to even bother saying anything, but raccettura’s post goaded me into it.
Let’s put this in some perspective:
Apple—user experience and design queen Apple—is to the right
of Mozilla’s position on this issue! |
Allow me to succinctly cut through all the cacophony on this: version numbers matter1.
They’ve always mattered. And they will continue to matter.
Why?
Because the first question anyone asks when debugging their own software problem or helping someone else: “What version are you using?”
“Latest” (or the even more asinine “infinite!”) is not even in the universe of a useful answer (and there exist a universe of reasons why it may not even be an accurate one, either).
Version numbers help users find the appropriate release notes for the application sitting in front of them.
Version numbers help users search forums and knowledge bases, and be able to correlate others experiencing a similar problem and use the correct instructions for the version they have.
Version numbers make it possible for savvier users to help themselves, by knowing what to put into the bug database when they search.
Version numbers make it possible for users to help developers, being able to effectively communicate when reporting a bug.
Version numbers are what the press refers to, so they can communicate which feature set their review pertains to.
Version numbers are used by organizations and startups to drive PR and user buzz about new features and product families: “We just released version 2.0! You should really check it out!”
Software labeling—version numbers, as consumers know it—has been a core of communication involving the answer to “Which actual bits are running on my CPU?” since… well the beginning of packaged-and-sold software.
Anyone quoting3 “Nobody asks ‘Which version of Facebook are you running?’” is easily dismissible: it’s a great example of the fallacy of false comparison, but it’s not worth responding to4,5.
In Mozilla’s specific case, this versioning consternation induced by their “rapid release” schedule is a direct result of versioning-as-a-concept being a proxy for something—API compatibility—in the Mozilla platform itself.
It’s important to call this out, because it’s necessary to distinguish between “rapid release causes my extensions to break every six weeks”—to users’ annoyance—and the (non-response) response of “Well, version numbers don’t matter anymore.”6
I see the move to obscure the version number to really be about reducing user “upgrade friction” by making the process as opaque and secretive7 as possible. This makes it easier to use Firefox’s user base as a lever to “move the web,” an argument I’ve previously made. This move is a consistent and logical step toward doing just that.
An interesting thought exercise to consider: what would the response be if Microsoft started updating Visual Studio on random intervals, and refused to divulge the version number installed on your machine when you tried to find it. Given that Mozilla bills the Open Web as a platform, and Firefox the tool to interact with and develop against that platform, it’s not a dissimilar example.
In any event, simply saying version numbers don’t matter anymore, and repeating it over and over like a bird you’d feed crackers to, does not suddenly make it a fact of modern software development.
It illustrates a profound lack of understanding of versioning’s (important) function in the best case.
And disingenuousness in the worst.
_______________
1 You’d probably expect a release engineer to say that, given that version numbers and versioning as a process development area has always been a large part of my job2
2 But that’s not why I’m saying it, entirely anyway
3 I should say “repeating the sentiment,” because I can’t find any Google record of anyone (publicly) having said that; the only reference is back to Laura Thomson’s original post, where the quotation is uncited
4 But I will: software which I download and run on my computer is very different than a web application
5 Facebook, Google Apps, and lots of other websites deploy software that’s broken all the time; people generally don’t have to answer “What version is it?” because, there often isn’t a way to meaningfully interact with those companies about issues in their (web-based) applications; you just wait until it’s fixed
6 In fact, this entire discussion about removing the version number from the UI is probably more acrimonious than it otherwise would be, because Mozilla has not, to date, resolved the issues raised by those negatively impacted by their “rapid [fire] release” decision
7 User experience people would probably choose “unobtrusive”
mozilla, versioning
Community, Releng Machinery, mozilla, planetmoz | 15 Comments »
V817