Re: Version numbers and an update from the UX team

>
> Make it a date (2011.08,
> or just 11.08) or a number (6) but don't try to mix them
>

yeah, I came to this conclusion as well.  Also, if we include ship dates in
Aurora, Nightly and Beta, it is kind of neat because you are using a product
that is labeled as being from **the future** (cue planetarium music).

-Alex



On Mon, Aug 22, 2011 at 1:55 PM, Alex Faaborg <[email protected]> wrote:

> It may not have been the central
>> point of your efforts, but it's hard to claim it wasn't the central
>> point of the bug.
>>
>
> yes, by "the bug" I meant purely the one in my head, what the team was
> talking about and the overall usability issue (making it easier to update).
> The literal bug 678775 was all about the version number.  I also didn't read
> bug 678775 until both it and this thread had already accumulated a massive
> number of comments.
>
> Anyway, bug 678775 has been set to invalid, and there are absolutely no
> plans to remove the version number from our UI.
>
> I would like us to perhaps consider a time-based version number sometime in
> the distant future since it maps to something users already understand (and
> also maps well to our release schedule), but that's an entirely separate
> discussion.
>
> -Alex
>
>
>
>
>
> On Mon, Aug 22, 2011 at 9:13 AM, [email protected] <[email protected]>wrote:
>
>> On Aug 20, 3:10 pm, Alex Faaborg <[email protected]> wrote:
>>
>> > -Making the about window primarily designed to achieve the task of
>> checking
>> > "am I up to date" is great
>>
>> This does not necessitate removing the version number.
>>
>> > -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
>>
>> If we're talking about the 5.0.1 situation, we should have rolled the
>> version number on all platforms. Hiding the version number instead is
>> a bizarre baby/bathwater failure.
>>
>> > -Multiple decimal places in version numbers is silly, and is pretty much
>> > only encountered in the realm of software
>>
>> Firefox *is* software. The alternatives I hear are moving towards
>> something like model years (pretty much only encountered in the realm
>> of software) and expiration dates (pretty much only encountered in the
>> realm of food items).
>>
>> > -Version numbers are generally speaking technical jargon, and user
>> > experience designers generally speaking like to try to remove instances
>> of
>> > jargon
>>
>> Sure, but there's always a balance.  Not finding a piece of
>> information where it has always been, and where every operating system
>> Human Interface guide tells you it should be, is a poor user
>> experience. I have a hard time understanding how that loses to the
>> desire to remove jargon.
>>
>> > -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.
>>
>> Under rapid release, the incompatible addon is going to be a prominent
>> feature of users' lives for a while. Normal users, not people who need
>> developer tools. about:support is going to be daunting to them, and is
>> hard to find in the first place. As I said in the other thread, if you
>> truly believe that we should be hiding the version number, it should
>> be the *last* thing we do, *after* version numbers don't matter. They
>> still matter today, so we shouldn't hide them now.
>>
>> > -Under the current model we are headed towards version 47, and that is
>> just
>> > going to sound silly in a world used to seeing small version numbers
>>
>> There are plenty of examples of large version numbers out there, and
>> even more examples of dropping the 'major' number and marching on with
>> the 'minor' number as the prominent version. This is a pretty silly
>> concern, IMO.
>>
>> > == One possible proposed solution (also proposed by many other people
>> > through many channels ==
>> >
>> > We de-jargonify the version number, and make it time based.
>>
>> An abbreviated datestamp like Ubuntu uses would be fine if you're
>> really concerned about the version number getting big. I'm not, but if
>> this scratches the dejargonification itch enough to get you to leave
>> the version number where users expect to find it, then so be it. It's
>> worth noting, however, that Ubuntu uses a 'nickname' very prominently.
>> Most users refer to "Lucid" or "Maverick" rather than "10.04" or
>> "10.10"
>>
>> > 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.
>> >
>> > 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.
>>
>> Oh please no. Do not mix dates and sequence in the main version
>> notation. I'm a user of an open source project that does this, and it
>> confusing and infuriating. Humans read strings that look like dates as
>> dates. (2011.3 just came out? It's August!) Make it a date (2011.08,
>> or just 11.08) or a number (6) but don't try to mix them (2011.3). My
>> opinions about point releases aren't as strong. Ubuntu does sequential
>> point releases (their LTS is currently 10.04.3) but I'd suggest
>> something obviously non-date based that allows for more than one
>> patch. (11.08b or 11.08p2, or maybe 11.08r2)
>>
>> > 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.
>>
>> Then let's leave it there and move on. We should revisit that when
>> incompatible add-ons are a thing of the past. We aren't there yet.
>>
>> >
>> > 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.
>>
>> This is a touchy issue for a bunch of reasons. Moving to an all-
>> upgrade-all-the-time model can pretty easily be misconstrued as "Yes,
>> Firefox is all about user choice, except for whether or not you're
>> going to upgrade." We have a long way to go before the add-on
>> ecosystem has completely caught up with rapid release, which means we
>> will continue to have users that can't upgrade without breaking their
>> daily use case. I'd much rather see effort go into the rather tricky
>> UX problems there, then into digging in our heels over the version
>> number in the about box.
>>
>> > Ironically removing the version number wasn't
>> > even the central point of the bug (which was primarily about further
>> > streamlining the process of checking for updates).
>>
>> That's a tough argument to make, Alex. The bug's summary was "Remove
>> version from About window", which got a 'typo corrected' to "Move the
>> version number from the Firefox -> Help -> About window to the Firefox
>> -> Help -> Troubleshooting window". It may not have been the central
>> point of your efforts, but it's hard to claim it wasn't the central
>> point of the bug.
>>
>>
>> _______________________________________________
>> dev-usability mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-usability
>>
>
>