Re: Removing Firefox Version Number

I know top-posting is usually bad, but there are exceptions. I'll be 
very very brief.

fzammetti, I could summarize your post (with which I totally agree) as 
follows: The Firefox UX team has not demonstrated to users' satisfaction 
what is of such paramount importance as to require going simultaneously
	- against ux-control
	- against ux-discovery
	- against ux-consistency
and I'm intentionally using three bugzilla.mozilla.org keywords to 
describe it.

On 15/08/11 23:28, fzammetti wrote:
> I actually do understand the rationale behind what is being suggested
> by Alex and supported by Asa.  Part of me even agrees with it... but a
> much larger part doesn't.  Most importantly, I believe it to be based
> on a flawed premise, and I won't be the first to say it in this
> thread: hosted software is fundamentally different than locally-
> installed software and trying to make them similar is a flawed thing
> to do.
>
> What version of GMail am I running?  It doesn't matter, I agree, and
> even if I knew there's not a thing I could do about it.  That last bit
> is the key!  The software host is responsible and in control of that
> entirely, there's no way for me to effect a version change.  With
> installed software however, that's simply not the case.  Whether its a
> bad idea or not is an entirely different point, but the fact is I can
> back-rev my browser, or any other locally-installed software, any time
> I wish (assuming I can still find the installer floating around).  I
> may even NEED to: anyone experienced in software development knows
> that no matter how perfect the development methodology may be,
> regression breakages happen.  This is even more true for software that
> is a runtime for other software, as a browser essentially is, since
> there's many more subtle ways things can get broken and no way to
> fully regression test it anyway.  If a browser upgrade causes my
> bank's web site to not work, even if its ultimately the fault of the
> bank for not coding "properly" somehow, in the short-term it doesn't
> matter, I need to back-rev if access to that site is critical, as a
> bank web site may well be for many people these days.  I don't even
> need to invoke the "enterprise argument" here, which carries even more
> weight in this regard in terms of needing to ensuring proper
> functionality of webapps to maintain business continuity.
>
> Trying to base a decision like this on a flawed comparison leads to a
> false dichotomy.  Hosted software, it can be argued, makes version
> numbers irrelevant because it's out of the users' control, but for
> locally-installed software that is obviously not true... and I know I
> for one always turn off forced upgrades in all software that has that
> capability, even though in most cases I simply upgrade more or less
> automatically anyway (I certainly do with Firefox for example)... the
> fact that I'm still in control makes a world of difference.  Likewise,
> having the control to go backward is necessary, whether its a good
> idea or not (Asa says it never is, my bank web site not working
> illustrates otherwise).
>
> Speaking as someone who spends a large part of my professional day on
> UX design concerns I can tell you the notion of discoverability and
> consistency are of paramount importance in the overall user experience
> to how effective they are with a piece of software.  They should be
> able to quickly and easily discover functionality and information in
> software in a logical manner even if they've never experience that
> aspect of it before.  Going to the About box of a piece of software to
> get the version number quite obviously falls in that category based on
> nothing more than accepted convention.  Likewise, the fact that this
> is considered a standard on most systems today and in most software
> means the consistency will be apparent to the user and therefore
> better usability-wise.  Saying they now need to go to a
> troubleshooting page instead is introducing a change for a highly
> debatable benefit, and arguably the downside outweighs any benefit.
>
> Like most of you, my mother always asked the hypothetical "if all your
> friends were jumping off a bridge, would you jump too?" and while the
> answer is most usually "no, of course not!", if we were all jumping
> into a pool of $100 dollar bills then our answer would change in a
> hurry, wouldn't it?!  The point being, if everyone else is doing
> something that is good, then yeah, doing the same thing ain't a bad
> idea :)
>
> If you want to work on a fully-hosted version of Firefox, then hey,
> I'd change my tune entirely... showing version numbers would no longer
> have any meaning because I'd never be able to change it myself.  If
> you want to truly force upgrades all the time without the possibility,
> aside from hackish things, of going backward or skipping an upgrade,
> then version numbers don't matter... and that's maybe my biggest worry
> with this.  This sets the stage for saying all users will be forced to
> always be on the most current version regardless of what they want or
> need.  The whole dropping of support for anything but the latest
> version thing, it could be said, was the first shot in that war and
> this dropping of version numbers could be seen as the second, with the
> inevitable third being removal of the option to turn off forced
> upgrades.  As a developer I generally approve of everyone being
> current... aside from the regression breakages I mentioned before,
> which could make my life hell if I get bit by them.  As an end-user
> though, the bank site example is all the justification I need to say
> it'd be a bad idea.  Now, I realize no one is making that argument
> here... but it's the implied "yet" that follows that statement that
> worries me.  Removing the version number from the About box makes that
> change all the more easy to justify and implement.
>
> You know, I've seen some reasonable compromises posted in this
> thread... why aren't they being given some consideration?  The simple
> adding of a "click here for more detailed info" on the About page
> seems to me like a great solution that'll make everyone happy.  Why
> wouldn't that answer get the nod?  Unfortunately, the only answer I
> can come up with is a conspiracy theory: implementing the "bug" fix as
> Alex and Asa want leads to that "forced upgrade" future I outlined.  I
> don't want to get all X-Files here, but it's not much of a leap.
>
> Let me close with a simple question... Asa, is this something that is
> GOING to happen regardless of what anyone says, or is there real
> debate to be had about it?  To me, the answer to that question would
> say considerably more about the future of Firefox than whether this
> single change is implemented or not.
>
> Take care,
> Frank
>
> --
> Frank W. Zammetti
> Author of "Practical Palm Pre webOS Projects"
>    and "Practical Ext JS Projects with Gears"
>    and "Practical Dojo Projects"
>    and "Practical DWR 2 Projects"
>    and "Practical JavaScript, DOM Scripting and Ajax Projects"
>    and "Practical Ajax Projects with Java Technology"
>    For info on these books and a lot more: zammetti.com

Best regards,
Tony.
-- 
"A wizard cannot do everything; a fact most magicians are reticent to
admit, let alone discuss with prospective clients.  Still, the fact
remains that there are certain objects, and people, that are, for one
reason or another, completely immune to any direct magical spell.  It
is for this group of beings that the magician learns the subtleties of
using indirect spells.  It also does no harm, in dealing with these
matters, to carry a large club near your person at all times."
		-- The Teachings of Ebenezum, Volume VIII