Re: Version numbers and an update from the UX team

On 8/22/2011 1:50 PM, Sailfish wrote:
> My bloviated meandering follows what Gervase Markham graced us with on
> 8/22/2011 6:42 AM:
>> On 20/08/11 23:10, Alex Faaborg wrote:
>>> == I personally believe the following things are true ==
>>>
>>> -Making the about window primarily designed to achieve the task of
>>> checking
>>> "am I up to date" is great
>>
>> I agree.
>>
>>> -Some technical users are reacting in a jaded way to large version bumps
>>> like 5, 6 and 7 because it took us several years for both 3 or 4, the
>>> sudden
>>> change in interval comes off as cheating even though that wasn't the
>>> intention (just need to get changes out faster to further progress on
>>> the
>>> Web)
>>
>> I think that a vague understanding of version numbers ("first number is
>> a big change, second number a small change") is much more widespread
>> than you think. This isn't quite the same as our previous technical
>> definition ("major number change == breaking things; minor == less or no
>> breakage) but it mapped reasonably. Now, it maps very badly, and this
>> confuses people.
>>
>> Given the arbitrariness of version numbering from a geek point of view,
>> I still have no idea why we didn't decide to increment the major number
>> once per year, and the second number for all the other releases in a
>> year.
>>
>> It's a short step from that idea to "2011.4", etc. - but I think that
>> still causes cognitive dissonance, because version 2011 of a product
>> seems weird. Even Ubuntu knocked off the first two digits to get the
>> numbers down into a sane range.
>>
>>> -If a user reads that 7.0.1 was released and they don't see this in the
>>> dialog box, they will be confused if we claim 7.0 is the most up to date
>>> version
>>
>> But removing the version number from the About dialog has the potential
>> to cause all sorts of other press-report-related confusion as well, some
>> scenarios of which people have explained in this thread.
>>
>>> -Multiple decimal places in version numbers is silly, and is pretty much
>>> only encountered in the realm of software
>>
>> "Silly" is a value judgement :-) They aren't decimal places, they are
>> separators - like the dots in a domain name.
>>
>>> -Version numbers are generally speaking technical jargon, and user
>>> experience designers generally speaking like to try to remove
>>> instances of
>>> jargon
>>
>> On the contrary, they are unique identifiers. Humans understand unique
>> identifiers with multiple parts. "23-06-2001". "14:33:17". "17 1st Ave,
>> San Francisco, CA". Understanding that this is software version "4.1.3",
>> and that "5.2.7" is a later version and "3.0.0" is an earlier one, is
>> not beyond the wit of most mortals.
>>
>>> -Some technical users really want to see the version number in an
>>> easy way
>>> for legitimate reasons (web developers, extension developers, IT, etc.)
>>> these people are a minority, but like the people who need to access view
>>> source or developer tools, they are also important. Since they are
>>> building
>>> stuff you could even argue that they are very disproportionately
>>> important
>>
>> And because they are people that, just at the moment, we don't want to
>> annoy any more than we have already. And they are drivers of Firefox
>> adoption among family and friends, and are the people who make sure
>> websites support us well.
>>
>>> == One possible proposed solution (also proposed by many other people
>>> through many channels ==
>>>
>>> We de-jargonify the version number, and make it time based.
>>>
>>> Format is 2011.1, 2011.2, etc. We refer to point releases simply as
>>> "a patch
>>> to 2011.7", and we avoid press statements that include multiple decimal
>>> places to limit all around user confusion.
>>
>> If we could switch to 11.1 instead, that would be much better - as you
>> say, big numbers feel weird. But we need to do it quick, before or when
>> mozilla-central goes to 11.
>>
>>> We refer to the versions as "the fourth release of 2012" as a long
>>> form in
>>> some public statements, instead of 2012.4, to further de-jargonify it
>>> and
>>> make it human readable, but they are otherwise the same thing.
>>
>> I'm not sure I have much confidence that the press will use the long
>> form over the short form.
>>
>>> Overall keeping the version number around in the about dialog doesn't
>>> really
>>> diminish the work to make the dialog primarily about confirming that
>>> you are
>>> running the newest version (or that you need to apply an update), and
>>> that
>>> is from my perspective the larger UI win here.
>>
>> Amen, brother!
>>
>>> == Why so much emotion? ==
>>>
>>> I think the reason this debate became so emotional is that some
>>> people want
>>> to change client side software to behave like the Web (where the user
>>> has no
>>> control over version), and some people simply aren't comfortable with
>>> that
>>> model.
>>
>> I think that's a very pertinent insight. And we need to decide what to
>> do about it, and how we can make them more comfortable. If knowing the
>> version number gives people a feeling of control, we need to take that
>> into account.
>>
> Just another data point, I can't recall the last time I ever looked (or
> cared to) look for an IE version number. Part of the reason is that I
> think that they've been very successful at announcing their latest
> releases in terms of version (e.g. IE6, ... , IE9) and that they have a
> relatively long release cycle (I'm ignoring the downside effects of this
> since it's not germane to the point I'm attempting to make.)
> Furthermore, if one does happen to find the version number this what
> they get, "Version: 9.0.8112.16421 and Update Versions:
> 9.0.2(KB2559049)" or something to that effect.
>
> My point being is that the version methodology being used there is quite
> mystifying, they're not using the seemingly accepted method of
> Version.Release.Maintenance (V.R.M.) and even muddy it more by having an
> ancillary "Update" number that who knows what that means. It is one of
> the most jargonized versioning schemes I've seen but somehow the
> installed users don't seem to have a problem with it (at least not that
> I've seen.) My take on this is what many have stated in that the ones
> mostly concerned about version numbers are Enterprise clients and power
> users. A small, yet very important, slice of the Mozilla install base.
> And, the ones most easily able to find out where the version number has
> been moved.
>
> With that being said, I'm ambivalent on whether it should still remain
> in the About screen since I'm a proponent of it being better placed in
> the about:support screen.
>

Just a few minutes ago, a user asked about how to leave feedback since 
mozilla.feedback is no longer available.  My first question was what 
version of FF was he using, because this feature has changed over the 
past few versions, and I needed to know in order to tell him where to 
find the feedback feature.  Now, if we could ASSUME that every user 
updates every time an update is released, this wouldn't be a problem, 
BUT THEY DON'T.  So, if he comes back and says he can't find the version 
number because it is no longer in the About dialog (if this change is 
made), then I have wasted some time, and further have to explain how to 
find the version number, then I can know where to tell him to look for 
the feature he needs.