some points from a predominantly business user

All of the quoted text are from Asa Dotzler over the course of the
entire thread.  They're from the same person, about the same product,
and seem to be quite consistent.  The ones below are those with which
I have issues.


>We're moving to a more Web-like convention where it's simply not important what version you're using as long as it's the latest version.

If a users calls their helpdesk (for a web-based application), the
first questions after verifying their identify are: OS version,
browser type, and browser version.  (more on this below)

>The justification is simple. We're removing the Firefox version number from all of the common user-visible locations because we don't believe that users need to know what version they're on.

IFF every browser version behaves identically, which they don't.

>We're ending version numbers because they're not meaningful to users (except in troubleshooting situations.)

So, the only time it's important, it's not there.

>People using Firefox do need to have confidence that they're on the latest version, though,...

No, they need to be sure they're on the approved version, and the
developers aren't part of the approval process.

>than giving her a number she can compare with some other number on a website somewhere to figure out if she's on the latest version.

She doesn't make the comparison, she simply provides it to her support
staff.  They KNOW which version of Firefox it the latest approved
version, and they also know which is the latest version that "works"
and consequently, the oldest version for which it DOESN'T work.

>We're intentionally breaking with convention here because we've moved to an unconventional release model where conventional versioning and version branding are no longer applicable.

So you're going to drop the version number and you're going to drop
'Firefox' and 'Mozilla' as well?

>This is the part that needs to be eliminated. Users should not feel the need to compare a number in the About dialog with a number they found on the web somewhere.

Yes and no.  No, they should not be checking the web, they should be
checking their internal support site.  The one that says "the
currently authorized version of __software__ is __yy__" with a
shortcut to the 'how to get fired/request non-standard software'
page.  Actually, under normal circumstances, the user doesn't even
need to know if it's Opera, Chrome, Internet Explorer, Firefox or
Safari.   When it doesn't work, then that informtion is in the top
three.

>You get automatic updates with Firefox unless you've disabled that feature which you absolutely should not unless you're trying to get exploited.

I finally see the problem.  You and the development teams think that
instant/auto update solves everything.  In reality, it only solves the
developer's 'how to get the new version deployed' problem.  If you're
looking at getting Firefox out of the business environment, I think
this will help.  As an administrator, the last thing I need is another
auto-updating application that changes where a simple user clicks, to
read off their browser version to their support staff.  If you want to
get away from being Identified as Mozilla Firefox, start a gradual
blending of the UI colors to those of IE or Chrome.  Better yet, you
could make the colors random (with fixed contrast, or not) every time
it's launched.

> When version has no actionable meaning to the user, it not only doesn't help, it adds confusion.

See my point above about identical behavior by browser versions which
is impossible if you fix any bugs.

> We're not going to change the format, that's just rearranging deck chairs on the titanic, we're going to obsolete the entire feature of version numbers.

I think a better analogy would have been to use the seats in a movie
theatre instead of deck chairs on a large ship, the kind that are
imprinted with words like 'aft lower pool lounge' or 'main observation
deck, row 2'.

> If Firefox needs updates, it will simply update.

No, it won't, because the PCI DSS (and all IT support groups where
I've worked) demand control over changes, including bugfix udpates.

>We are moving to a release model that makes version numbers meaningless and unactionable for consumers.

Well, as long as javascript (or whatever) can still get the full
version info using the same call, you won't break the entire web,
automatically, at once.  Also, version numbers have meaning and are
actionable (see my tech support comments) for more than consumers.


First of all, I've been in IT administration since 1988, and a
computer user since 1975.  Good examples of bad UI changes are:
Windows XP to Windows Vista, and Firefox 3.6 to Firefox 4.  Good
examples of good UI changes are not memorable, because they were
seamless.  I've just opened every application on my computer, and with
the exception of Dell QuickSet for Windows XP, every application has
help->about that contains the version number.  Quickset has a task-
tray menu item About.

I've worked with some developers who's business cards read: John
Smith, Ph.D.(5), M.S.(8),B.S.(14)   Those aren't a footnotes, they're
quantities.  I've also work with users at the other end of the
spectrum who, when the light burned out on their on/off switch, they
called to report that they couldn't turn their computer on.   The only
way to support such a diverse userbase is consistency.  Or if not
consistency, then predictability.  No matter the application, telling
the user to click, in the top menu, Help and then About gets the
information you're after.  If it's not on the top and on the right, at
least its on the top.

As for your rapid release schedule.  Why?  Just code it well the first
time, please.  I don't want to use up my monthly bandwidth allocation
downloading patches (which aren't really patches, they're
replacements) from Microsoft, CentOS, Mozilla, Google, Adobe, Juniper,
Cisco, and so on.   All it demonstrates is not that you all work
really fast, but that you write sloppy code and then distribute it.
As an example, I failed to turn in a compiler project because of the
240 cases, a single case failed to generate the appropriate results.
If I had just inserted a comment like "this case will be fixed in the
next release" I would probably have ended up writing buggy software.
My point is, if it's broken, don't release it. I don't care if you
miss getting it in the monthly release. In fact, I don't care if it
ever ends up in the finished product because it didn't work properly.

I would like to make a suggestion.   Remove the Help->Troubleshooting
menu item and rename the existing Help->About "version" to
"Troubleshoot Now" link where the link will display the version number
on mouseover.