Re: Version numbers and an update from the UX team

>
> 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
>