Re: Removing Firefox Version Number

On 08/15/2011 11:52 AM, Tyler Downer wrote:
> Asa, would you mind clearly, and with supporting data, tests, metrics,
> show What problem this is addressing, Who is affected by it, What our
> goal is (long-term and short-term, and not generic terms like "getting
> rid of versions") and How this solution addresses the problem better
> than the solutions we already have in place.

I'll try to answer some of this, at least the parts I understand.  I'm a 
Mozilla employee but not a member of the UX or Product Management teams. 
  I can't talk for those teams, but I can give my own opinions, and my 
own understanding of what they've explained previously.

First, let me describe a similar situation:

Before I started working on Firefox full-time, I worked at Amazon.com. 
Amazon's process is a lot like the new Chrome/Firefox release cycle.  My 
team deployed a new version of our site every four weeks, with a 
staggered process where new versions first spent time on our dev and 
staging channels before going out to the production site.

Each bit of software deployed to the site gets a new version number 
every time it was rebuilt.  Many packages had versions in the hundreds 
or thousands.  Of course, our customers never knew or cared about the 
version numbers.

Now, a hypothetical question:

If someone proposed adding a version number to our web site and 
publishing it where customers could see it, would this be a good idea? 
My answer is no.  Some of our corporate customers might have liked it; 
they spent time filing support tickets, and liked to have the maximum 
amount of data about everything we did.  But ultimately it would have 
led to more questions than it answered, would cause customers to notice 
updates that didn't really affect them (and wouldn't be noticed 
otherwise), and would have been mostly useless because customers 
couldn't choose which version was deployed to which channel anyway.

Many people in this newsgroup have correctly pointed out differences 
between a web site and a client-side application.  But Chrome and 
Firefox have both started moving to a model where many of the same 
reasons apply.  Except for the rare user who has a good reason to run 
old insecure software, all users should be on one of the supported 
channels and cannot choose which version is deployed to that channel. 
Normal users are not affected by what number appears in the UA string, 
and shouldn't have to care.  In a hypothetical world where the version 
number had never been displayed to users to begin with, suddenly adding 
it would generate more questions than it answered.

I hope that explains some of the goals and reasons behind this decision. 
  Does that mean I agree with the decision?  I'm not sure.

We're not in my hypothetical world.  Here in the real world, many users 
do expect client-side software to have version numbers, and to find the 
number in a particular place.  By proposing a change like this, we may 
have the opposite of the intended effect:  We are focusing *more* 
attention on the version number, and making the transition to rapid 
release *less* seamless.

Now, I do think this controversy is a bit overblown.  Normal users never 
or rarely look at the About box, so whether we change it or not, the 
real impact on users is mostly zero.  But for users who do look in the 
About box for the version (and this thread provides many reasons they 
will continue to do this) changing it may cause more awareness and 
anxiety about versions and the release cycle than if we just left it 
unchanged.

For contrast, look at Chrome which has been doing rapid releases for 
over a year, and has successfully removed versions from their press 
releases and web sites, and to a large extent from their users' 
awareness.  But they still have a version number in their About box. 
Chrome users often note that the version number is still easy to find 
when you need it, but you normally never need it.  That seems like the 
perfect balance to me.