Apology from Jono about that blog post

[Jono Xia]

Everybody: I'm sorry. I'm REALLY REALLY sorry.

I never meant to cause harm to the Mozilla mission. I never imagined the
post I wrote (http://evilbrainjono.net/blog?permalink=1094) would go
viral or get the kind of reaction it has gotten.

When I wrote the post, I hoped it would be constructive criticism, but
it seems to have turned into the other kind. Of course, the internet
being what it is, I was naiive to think what I wrote would stay confined
to my blog audience. I wish I could go back in time and undo posting it,
or friends-lock it, or at least give it a title that was less likely to
be turned into flame-bait. I wish I had chosen my words more carefully.

I've learned a lot in the last few days about the uncontrollable beast
that is internet fame. I realized that most of the sites re-blogging it
haven't even read what I wrote; they didn't bother to get my name right
or my employment status or former job title. There's nothing I wrote
that hasn't been said by lots of people before, inside and outside
Mozilla; the only reason this got picked up by so many gossip websites
was because editors thought "Firefox dev Jono DiCarlo says Firefox
suxx" would make irresistable link-bait, facts be damned. Never mind
that I'm not (never was) a Firefox dev, that my name isn't DiCarlo, and
I don't think Firefox suxx!

The main point I wanted to make, which got lost in all the noise, is
about the difference between the developer perspective and the user
perspective, and about how developers (everywhere, not just at Mozilla)
should give more weight to the pain that updates inflict on users before
pushing them out. I stand by that point. I just wish I had made it more
clearly and less angrily.

I also believe Mozilla has been doing the right thing and gradually
correcting most of the mistakes of the rapid release process, and that
since Firefox 13 or so, updates have actually been pretty good -- as I
said at the end of my post, and in my follow-up post. Unfortunately I
didn't emphasize that part of my message enough.

The last few days have been agonizing. When I saw that Mozilla had to
write a press release to control the PR damage from my post, I was
heartbroken. Believe me, if I ever wanted one of my posts to go viral
and get read widely, it wouldn't have been that one.

Please share this message with anyone in Mozilla who has been hurt by my
actions.

TL;DR - I didn't mean for this to happen, I'm just bad at the internet.
Sorry, everyone.

--Jono

[David Bruant]

Le 13/07/2012 16:20, Jono Xia a écrit :
> Everybody: I'm sorry. I'm REALLY REALLY sorry.

I wish to express that you have nothing to appologize for.
You wrote a blog post. The blog post was a personal statement. Nothing
was offensive is any fashion to anyone. Maybe there were some
hyperboles, maybe some inacuracies, maybe some statements were of the
realm of feelings rather than facts. That's the definition of a
blogpost, right?

Moving forward, it's interesting to see the reactions it has triggered.
There is a lot to be learnt from the reactions and a lot to be learnt
from how Firefox is being perceived.
I see very positively that following your blogpost, we get to read how
people percieve Firefox and that Mozilla gets an occasion to answer in
an official Press Release about some concerns that were true but aren't
any longer since recently (namely silent updates and compatible add-ons
by default).

I'm glad your blogpost made such waves if the end result is a broader
highlight of some recent Firefox improvements.

David

[Robert Kaiser]

Jono Xia schrieb:

> I've learned a lot in the last few days about the uncontrollable beast
> that is internet fame. I realized that most of the sites re-blogging it
> haven't even read what I wrote; they didn't bother to get my name right
> or my employment status or former job title. There's nothing I wrote
> that hasn't been said by lots of people before, inside and outside
> Mozilla; the only reason this got picked up by so many gossip websites
> was because editors thought "Firefox dev Jono DiCarlo says Firefox
> suxx" would make irresistable link-bait, facts be damned. Never mind
> that I'm not (never was) a Firefox dev, that my name isn't DiCarlo, and
> I don't think Firefox suxx!

Yes, that's what "journalism" seems to have become for many: take a few
words and make up new "facts" around them that make an interesting
story. Do no care if any of it is true.
Unfortunately, this time the few words were from you and the story they
made out of them was hurting our image. But the next time, it'll be
others. Unfortunately, it almost always is about hurting some project,
often really good ones. In the end, bad news sell better than good news,
I guess. :(

> I also believe Mozilla has been doing the right thing and gradually
> correcting most of the mistakes of the rapid release process, and that
> since Firefox 13 or so, updates have actually been pretty good -- as I
> said at the end of my post, and in my follow-up post. Unfortunately I
> didn't emphasize that part of my message enough.

The last paragraph of you post just wasn't interesting enough for the
press, as it wasn't a story. "Mozillian says Firefox sucks" was, even
though it was a clear mis-interpretation.

(That said, "we suck" was a running gag on IRC in Netscape times and
used for all cases where our code ended up doing unexpected things. And
we, even me as a volunteer contributor, had a lot of fun with that.)

> TL;DR - I didn't mean for this to happen, I'm just bad at the internet.

Now, there I don't believe you. You've never in the last years been "bad
at the internet". You just miscalculated its effect. Happens to all of
us (or at least to many), in different sizes. ;-)

You for sure continue to be welcome as a Mozillian, and I hope to see
you around in some form in the future!

Robert Kaiser

[PhillipJones]

Why do you want to apologize for speaking the truth. The big wheels at
Mozilla will never change. Unless people like you who have some
influence and clout tell the truth. The don't listen to their customers
and big business that had been using FireFox are leaving in droves to
other browsers. Upgrades should only come once every three to six
months. Would give people time enough to get use to and get comfortable
with the new features.
This putting out updates every other day is maddness.

The object is not to emulate Chrome. Chrome is a piece a junk and I hate
using it. a web browser should what its supposed to. But the object is
not to look so much like a another brands that users get the two confused.
However unless people like you speak up and speak you mind, it will fall
on deaf ears.

--
Phillip M. Jones, C.E.T. "If it's Fixed, Don't Break it"
http://www.phillipmjones.net mailto:pjo...@kimbanet.com

[Asa Dotzler]

On 7/13/2012 4:02 PM, PhillipJones wrote:
> The object is not to emulate Chrome.

You are correct. That is not the object and that has never been a goal
put forward by anyone involved with Firefox product direction.

- A

[Philip Chee]

It's true that that has never been an explicit goal, but you can't deny
that there has been a lot of chrome envy informing decisions on the
direction that Firefox should go.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Henri Sivonen]

On Sat, Jul 14, 2012 at 6:56 AM, Philip Chee <phili...@gmail.com> wrote:
> On Fri, 13 Jul 2012 16:39:20 -0700, Asa Dotzler wrote:
>> On 7/13/2012 4:02 PM, PhillipJones wrote:
>> > The object is not to emulate Chrome.
>>
>> You are correct. That is not the object and that has never been a goal
>> put forward by anyone involved with Firefox product direction.
>
> It's true that that has never been an explicit goal, but you can't deny
> that there has been a lot of chrome envy informing decisions on the
> direction that Firefox should go.

Actually, I think the biggest thing that went wrong with Rapid Release
was the failure to imitate Chrome even more *up front*. Chrome had a
superb silent update system from day one--even before they started
releasing every six weeks. And when Chrome introduced extensions, the
API did not expose a random parts of engine internals. In contrast,
the Firefox Silent Update program was still in the definition phase
long after we had already started shipping rapidly and the stable
JetPack API lived on the extension side rather than on the Firefox
side when rapid releases started rolling out (dunno where the stable
API lives now).

Even though update silence has now been fixed on Windows (but AFAIK
not fully on Mac) and in that sense this is water under the bridge
(although the word of mouth does not appear to have picked up the fact
that on Windows it's water under the bridge), in order to do better in
the future, I think it would be worthwhile to consider what kind of
cognitive biases led to such a focus on the upsides (which are
significant) of rapid release to such a degree that rapid releases
were able to start reaching end users without the critical
prerequisites in place.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[L. David Baron]

On Saturday 2012-07-14 15:30 +0300, Henri Sivonen wrote:
> Actually, I think the biggest thing that went wrong with Rapid Release
> was the failure to imitate Chrome even more *up front*. Chrome had a
> superb silent update system from day one--even before they started
> releasing every six weeks. And when Chrome introduced extensions, the

But even before rapid release, we were shipping updates to our users
every six weeks (with some requiring followup updates to fix
regressions); it's just most of those updates were security updates.
(Though I guess we didn't stick to the six week cadence as
precisely. I think it was still the goal.)

But we were still notifying our users of updates just as often.

So I agree that building a less intrusive update system is a good
thing, but I don't see how it's related to rapid release.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

[chris hofmann]

Yes, we're shipping the same number of releases per year, but
one of the problems is that under the previous release system
we were shipping about 1 or 2 releases per year with significant
regressions that resulted in the need to follow up with a quick
replacement release.

Nearly every one of the releases in the last 15 months have required
a quick X.01 follow up release for a variety of different reasons;
but the net effect is that we broke a significant number of users
in significant ways when the bits were put on the wire.

Part of this is that we haven't hit the targets for beta and aurora
populations which would allow us to surface regressions faster
and get them fixed before shipping to the larger population.
Work is underway to help fix that, but still not to our original target
levels.

In general, users don't like to be annoyed. A small part of the
annoyance comes from frequent update dialogs, but a larger
part of the annoyance comes from breaking addons, breaking
websites, breaking plugins, and introducing crash problems.
Until we find ways to get those things under control we won't
solve this problem.

Spreading the releases out on a longer cycle, of say 1 per quarter,
would result in breaking users about 50% less. That's the fastest,
easiest, and biggest immediate impact thing to try if we are trying
to design a release system that works for users.

-chofmann

[Philip Chee]

Yes but those updates were security updates which meant:
1. No change in UI (try retraining your muscle memory every six weeks if
the pedal positions in your car kept changing as often).

One small change in UI isn't fatal. But it's the fatal drip drip drip of
small UI changes every six weeks. Eventually this pushes many users over
the edge.

2. No (or almost none) addons broken.

Many users don't use addons at all. But for those that do, there are
people who abslouely depend on certain extensions for their
productivity. Breaking those extensions causes a lot of stress in those
people. I know users who have done a personal calculus and decided that
uninterrupted productivity is more important than security updates and
have resolved to take the calculated risk of avoiding updates until
absolutely necessary.

[Henri Sivonen]

On Sat, Jul 14, 2012 at 5:46 PM, L. David Baron <dba...@dbaron.org> wrote:
> But even before rapid release, we were shipping updates to our users
> every six weeks (with some requiring followup updates to fix
> regressions); it's just most of those updates were security updates.
> (Though I guess we didn't stick to the six week cadence as
> precisely. I think it was still the goal.)
>
> But we were still notifying our users of updates just as often.

The old point releases virtually never drew user attention to add-on
issues (either true incompatibilities or assumed incompatibilities
based on metadata).

So even if the old point releases were just as frequent as rapid
releases and as frequent in UAC prompts (unless migration from XP to
Windows 7 in the same time frame counts as UAC frequency increase
across the userbase prior to the Maintenance Service), there was a
substantial difference in how they appeared to the user such that
rapid Firefox releases were more intrusive-looking than old Firefox
point releases while Chrome releases were less intrusive-looking.

Part of the intrusiveness comes from the basic problem that
pre-JetPack add-ons touch implementation details in ways that don't go
well with rapid changes to the implementation details. That's a
problem that could not have been fixed before hand and continues to be
unfixable as we continue to pay the "technical debt" in Gecko.
However, intrusiveness that came from reacting to metadata created
ahead of knowledge of true compatibility issues and intrusiveness that
came from not having the stable JetPack API living in Firefox were
things that, in hindsight, could have been addressed (to the extent of
putting the JetPack API onto the Firefox side the way Chrome, Opera
and Safari handle their analogous APIs--not in the sense of waiting
for the JetPack API to become broad enough to cater for all
extensions) along with removing notifications from the update process
before letting to Rapid Releases reach end uses.

[Henri Sivonen]

On Sat, Jul 14, 2012 at 6:26 PM, chris hofmann <chof...@meer.net> wrote:
> In general, users don't like to be annoyed. A small part of the
> annoyance comes from frequent update dialogs, but a larger
> part of the annoyance comes from breaking addons, breaking
> websites, breaking plugins, and introducing crash problems.
> Until we find ways to get those things under control we won't
> solve this problem.

Do you have insight into how and why we are breaking Web sites these
days compared to the old days?

[Alan Milnes (GP)]

On 13 July 2012 15:20, Jono Xia <jo...@fastmail.fm> wrote:
> Everybody: I'm sorry. I'm REALLY REALLY sorry.

You shouldn't be - your post was absolutely spot on, that's why it
genereated the interest it did!

Alan

[Jeff Griffiths]

On 12-07-14 5:30 AM, Henri Sivonen wrote:
...

> and the stable
> JetPack API lived on the extension side rather than on the Firefox
> side when rapid releases started rolling out (dunno where the stable
> API lives now).

The Jetpack APIs are still on the extensions side ( eg packed in the xpi
) but there is a goal to land Jetpack in mozilla-central, and the first
bit is already in, in the form of the CommonJS loader. It isn't used by
anything and has zero impact currently, but it is a beach-head.

Jeff

[Nicholas Nethercote]

On Sun, Jul 15, 2012 at 1:50 AM, Philip Chee <phili...@gmail.com> wrote:
>
> Yes but those updates were security updates which meant:
> 1. No change in UI

> 2. No (or almost none) addons broken.

My gut feeling (I have no real data) is that (2) was by far the
biggest problem -- bigger than (1), bigger than changing the meaning
of version numbers, bigger than complaints about copying Chrome, etc.

As for why (2) wasn't anticipated to be a problem? Maybe we were
overly optimistic about add-on authors being timely with making a
trivial change every 6 weeks?

Nick

[Robert Kaiser]

L. David Baron schrieb:

> But even before rapid release, we were shipping updates to our users
> every six weeks

Every four weeks actually. We slowed the pace of regular updates with
rapid release. ;-)

Robert Kaiser

[Robert Kaiser]

Nicholas Nethercote schrieb:

> On Sun, Jul 15, 2012 at 1:50 AM, Philip Chee <phili...@gmail.com> wrote:
>>
>> Yes but those updates were security updates which meant:
>> 1. No change in UI
>> 2. No (or almost none) addons broken.
>
> My gut feeling (I have no real data) is that (2) was by far the
> biggest problem -- bigger than (1), bigger than changing the meaning
> of version numbers, bigger than complaints about copying Chrome, etc.

Yes, I have not heard any complaints about UI changes in rapid releases.
All UI change complaints I heard were about the changes we shipped in
Firefox 4, which was before rapid release. And actually, that makes an
argument right against with Philip said: People complain if there is one
huge change at once, they complains less or not at all if there's mall
changes every 6 weeks. At least it feels that way.

> As for why (2) wasn't anticipated to be a problem? Maybe we were
> overly optimistic about add-on authors being timely with making a
> trivial change every 6 weeks?

We completely underestimated the non-AMO add-ons. We were pretty
confident we could deal with add-on problems because we could just
update compatibility on AMO, and we were pretty good at that. We didn't
realize how many non-AMO add-ons are out there and how much a problem
they produce because we can't just bump their compat.

Robert Kaiser

[Chris Hofmann]

On 7/14/12 12:12 PM, Henri Sivonen wrote:
> On Sat, Jul 14, 2012 at 6:26 PM, chris hofmann <chof...@meer.net> wrote:
>> In general, users don't like to be annoyed. A small part of the
>> annoyance comes from frequent update dialogs, but a larger
>> part of the annoyance comes from breaking addons, breaking
>> websites, breaking plugins, and introducing crash problems.
>> Until we find ways to get those things under control we won't
>> solve this problem.
> Do you have insight into how and why we are breaking Web sites these
> days compared to the old days?
>

I'm not sure that we are braking sites in new ways, we are just doing it
more often. We "break sites" when plugin incompatibilities cause
the sites not to work. We broke sites when we went to a two digit
version number in the UA. We broke sites when we deprecated features
like global storage and others. And we break sites when we inject
unintended side effects trying to make improvements.

Just quickly scanning release notes and regression keyword bugs
that made there way to tracking status over the 15 months turns up
a pretty large list that would be an interesting study.
I put together a short sample of somen examples below.

My sense of all this comes from channel meetings and some of the triage
that happens there.

Alex has been interested in gather some data on regressions to figure
out when they happen, when the are detected, and when they are fixed
in the aurora, beta or after ship cycle but gathering that data is a
complicated and time consuming exercise.

Knowing what number and pct. of total regressions are getting addressed
after a release has been shipped might help to tune and engineer the
release cycle to a more optimum interval. I think this is important,
but that wasn't my main point. My main point was to try and do
something simple reduce the frequency by which we break users.

-----

*Bug 736731* <https://bugzilla.mozilla.org/show_bug.cgi?id=736731>
-Hotmail no longer auto-updates (due to "globalStorage" removal in fx13
fix on the hot mail side took until -- 2012-06-27

regession from 10 *Bug 713305*
<https://bugzilla.mozilla.org/show_bug.cgi?id=713305> - WebGL no longer
triggers discrete graphics mode on dual GPU MacBook, affecting content
performance

*Bug 734530* <https://bugzilla.mozilla.org/show_bug.cgi?id=734530>
-Facebook comment box disables spell check
Note that we've broken this in 10, and 11 has already been shipped with
this bug.


#


Windows Messenger did not load in Hotmail, and the Hotmail
inbox did not auto-update (764546
<https://bugzilla.mozilla.org/show_bug.cgi?id=764546>, fixed
in 13.0.1)

#


#


Hebrew text sometimes rendered incorrectly (756850
<https://bugzilla.mozilla.org/show_bug.cgi?id=756850>, fixed
in 13.0.1)

#


Flash 11.3 sometimes caused a crash on quit (747683
<https://bugzilla.mozilla.org/show_bug.cgi?id=747683>, fixed
in 13.0.1)

#


Java applets sometimes caused text input to become
unresponsive (bug 718939
<https://bugzilla.mozilla.org/show_bug.cgi?id=718939>)

#


2 digit version number in UA break sites that have poor
sniffing algorithms

Silverlight video may not play on some Macintosh hardware (715396
<https://bugzilla.mozilla.org/show_bug.cgi?id=715396>)

*Bug 697647* <https://bugzilla.mozilla.org/show_bug.cgi?id=697647>
-flicker on html5/webm video

*Bug 679090* <https://bugzilla.mozilla.org/show_bug.cgi?id=679090> -IPv6
sites broken in Firefox 7

an issue with gov.uk websites (see bug 669792
<https://bugzilla.mozilla.org/show_bug.cgi?id=669792>)

[Alex Keybl]

> Nearly every one of the releases in the last 15 months have required
> a quick X.01 follow up release for a variety of different reasons;
> but the net effect is that we broke a significant number of users
> in significant ways when the bits were put on the wire.

Not to jinx it (especially with some security conferences coming up), but I just want to point out that only one of the last three releases has actually required a .0.1. Also, many of the post-4.0 dot releases were driven by external changes/issues, which can't be blamed on the rapid release process.

Basically, unplanned dot releases are just meant to make the user experience better for our users, and many of the primary drivers aren't in-product regressions. Even still, we're improving our own processes with each release and will continue to do so in the future.

-Alex

On Jul 14, 2012, at 8:26 AM, chris hofmann wrote:

> On 7/14/12 7:46 AM, L. David Baron wrote:
>> On Saturday 2012-07-14 15:30 +0300, Henri Sivonen wrote:
>>> Actually, I think the biggest thing that went wrong with Rapid Release
>>> was the failure to imitate Chrome even more *up front*. Chrome had a
>>> superb silent update system from day one--even before they started
>>> releasing every six weeks. And when Chrome introduced extensions, the

>> But even before rapid release, we were shipping updates to our users

>> every six weeks (with some requiring followup updates to fix
>> regressions); it's just most of those updates were security updates.
>> (Though I guess we didn't stick to the six week cadence as
>> precisely. I think it was still the goal.)
>>
>> But we were still notifying our users of updates just as often.
>>

>> So I agree that building a less intrusive update system is a good
>> thing, but I don't see how it's related to rapid release.
>>
>> -David
>>

> Yes, we're shipping the same number of releases per year, but
> one of the problems is that under the previous release system
> we were shipping about 1 or 2 releases per year with significant
> regressions that resulted in the need to follow up with a quick
> replacement release.
>
> Nearly every one of the releases in the last 15 months have required
> a quick X.01 follow up release for a variety of different reasons;
> but the net effect is that we broke a significant number of users
> in significant ways when the bits were put on the wire.
>
> Part of this is that we haven't hit the targets for beta and aurora
> populations which would allow us to surface regressions faster
> and get them fixed before shipping to the larger population.
> Work is underway to help fix that, but still not to our original target
> levels.
>

> In general, users don't like to be annoyed. A small part of the
> annoyance comes from frequent update dialogs, but a larger
> part of the annoyance comes from breaking addons, breaking
> websites, breaking plugins, and introducing crash problems.
> Until we find ways to get those things under control we won't
> solve this problem.
>

> Spreading the releases out on a longer cycle, of say 1 per quarter,
> would result in breaking users about 50% less. That's the fastest,
> easiest, and biggest immediate impact thing to try if we are trying
> to design a release system that works for users.
>
> -chofmann
>

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

[Stuart Cook]

On 16/07/12 12:39 AM, Robert Kaiser wrote:
> Yes, I have not heard any complaints about UI changes in rapid releases.
> All UI change complaints I heard were about the changes we shipped in
> Firefox 4, which was before rapid release. And actually, that makes an
> argument right against with Philip said: People complain if there is one
> huge change at once, they complains less or not at all if there's mall
> changes every 6 weeks. At least it feels that way.

Really? Most UI changes bring some level of negative feedback and angry
forum posts asking how to undo the changes, and there have been plenty
of those changes since 4. Sometimes there's a fix or workaround and
sometimes there isn't. Feathers are being rustled here.

I can't say whether big-bang changes would be better or worse than a
steady stream of small ones, since they both have their pros and cons.

[PhillipJones]

See this article nd you devlopers read ever line of every page:

http://www.computerworld.com/s/article/9229204/Ex_Mozilla_worker_rails_against_developers_love_of_constant_change_frequent_updates?taxonomyId=211&pageNumber=1

The article writer is say in their part (not quoted) excatly what user
have been saying all along.

[Daniel Veditz]

On 7/14/12 12:12 PM, Henri Sivonen wrote:
> Do you have insight into how and why we are breaking Web sites these
> days compared to the old days?

It's probably about the same but more spread out. In the old days
two separate changes might have broken site A and site B, and when
you upgrade you'd say "Augh! This Firefox update broke my sites!".
Spread out we might break site A one release and site B the next
release giving the user twice as many chances to register the
impression that Firefox updates "always break things". Same changes,
same breakage, different impact.

-Dan Veditz

[Nicholas Nethercote]

On Mon, Jul 16, 2012 at 6:15 AM, Stuart Cook <scook0+...@gmail.com> wrote:
>
> Really? Most UI changes bring some level of negative feedback and angry
> forum posts asking how to undo the changes, and there have been plenty of
> those changes since 4. Sometimes there's a fix or workaround and sometimes
> there isn't. Feathers are being rustled here.

Can you give examples? I'm genuinely having trouble thinking of any,
but perhaps my tolerance for UI changes is higher than average.

Nick

[Benjamin Smedberg]

On 7/16/2012 7:17 PM, Nicholas Nethercote wrote:
> On Mon, Jul 16, 2012 at 6:15 AM, Stuart Cook <scook0+...@gmail.com> wrote:

>> Really? Most UI changes bring some level of negative feedback and angry
>> forum posts asking how to undo the changes, and there have been plenty of
>> those changes since 4. Sometimes there's a fix or workaround and sometimes
>> there isn't. Feathers are being rustled here.

> Can you give examples? I'm genuinely having trouble thinking of any,
> but perhaps my tolerance for UI changes is higher than average.

The new-tab page comes to mind; I personally found it incredibly
distracting and couldn't figure out how to turn it off until I asked in
dev-apps-firefox, when somebody pointed me to that little dialer button
on the upper right which turns it off.

--BDS

[Jorge Villalobos]

+1

Other smaller changes include the removal of the protocol from the URL
bar (can be reverted in about:config), the background color for image
display (can be changed with an add-on, not sure if there's a pref now)
and the upcoming changes to the identity box (not configurable AFAIK).

Jorge

[Jorge Villalobos]

On 7/16/12 5:19 PM, Benjamin Smedberg wrote:

[Stuart Cook]

On Tue, Jul 17, 2012 at 9:17 AM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
> Can you give examples? I'm genuinely having trouble thinking of any,
> but perhaps my tolerance for UI changes is higher than average.

Here are some that I've seen complaints about, or in some cases
stumbled over myself:

- Dancing/autohiding forward button
- Removal of the workaround that made the forward button stop moving
- Greying out non-domain parts of the current URL
- Removing http:// from the address bar
- Removing the site identity block & coloured encryption indicator
- Removing favicons from the URL bar
- Inline URL autocomplete
- Smooth scrolling by default
- Speed dial on the new tab page
- Not reloading tabs when the browser restarts
- Removal of the tab list drop-down
- Showing images centred on a grey textured background
- Removing the UI for disabling tabs-on-top
- New window animations on OS X
- Changing the "missing" favicon from a document to a dashed box

About half of these are configurable, if you know which about:config
preferences to alter.

[Panos Astithas]

So, basically, for every change ever made to the UI, someone will complain.
Hardly jaw-dropping, but I can understand wanting to please everyone.

In that same line of thought, can you point out which UI changes generated
no complaints whatsoever? That might help us figure out what kind of UI
evolution we are allowed to do, without stepping on toes.

Or realize that it simply comes with the territory.

[David Bruant]

Le 17/07/2012 04:56, Stuart Cook a écrit :
> (...)
> - Inline URL autocomplete
A friend of mine (who is not technical, so potentially representative of
a lot of other non-techincal people) chose to stay on Safari for one reason:
To go to facebook, on Safari, you just need to type 'f' and inline URL
autocomplete does the rest of the job (and you need to validate).
Meanwhile for Firefox (up until recently) to go to facebook, it would
take 'f' + down key (to select facebook) + validate.

My friend was choosing to stay on a browser, because it would take 2
keystokes instead of 3. True story.
Inline autocomplete is a feature that was expected.

David

[David Bruant]

Now things are pretty stable in Facebook UI, but at some point, Facebook
was doing major UI changes quite often. It generated a lot of
complaints. Now, Facebook provides help with noticeable UI changes and
I'm sure it helps people.
Maybe on UI update, Firefox could say something like "this has changed
in your UI", "this is new" and explain how to understand the changes
assuming the user knew the previous interface.

If I changed where your house is without telling you, you'd be pissed
when coming back and not finding your house. If I told you beforehand
and explained where it is now (and maybe even explain why I changed
where it is), you would probably be less annoyed.

David

[Stuart Cook]

On 17/07/12 5:24 PM, Panos Astithas wrote:
> So, basically, for every change ever made to the UI, someone will complain.
> Hardly jaw-dropping, but I can understand wanting to please everyone.
>
> In that same line of thought, can you point out which UI changes generated
> no complaints whatsoever? That might help us figure out what kind of UI
> evolution we are allowed to do, without stepping on toes.
>
> Or realize that it simply comes with the territory.

This does seem to be the prevailing attitude, but I think it's dangerous.

It's easy to fall into the trap of thinking that users will complain
about anything, and that it's therefore safe to ignore all of those
complaints.

In any case, I was mostly trying to refute the notion that people don't
get upset by smaller UI changes.

[Justin Dolske]

On 7/17/12 12:45 AM, David Bruant wrote:

> If I changed where your house is without telling you, you'd be pissed
> when coming back and not finding your house. If I told you beforehand
> and explained where it is now (and maybe even explain why I changed
> where it is), you would probably be less annoyed.

This probably isn't a very good analogy. :-)

Justin

[David Bruant]

That's a terrible analogy, I have to admit :-)
My point was that unexpected change is annoying, we all agree on that.
But helping people transitionning from what they know to what we wish
they knew would be a major improvement toward making people understand
the change they are being imposed.
And I'm not saying "imposed" lightly, because for most users, it's
really how it's felt.

Panos Astithas :

> So, basically, for every change ever made to the UI, someone will complain.

It's probably true for any change to anything. But the amount of
acceptance differs based on how the change is presented.
I'll try another very different analogy:
Recently, France has changed of President. Some people complain about
it. But largely, François Hollande is accepted as the new President
(even by those who complain). The reason is that the change was preceded
by a country-wide election. Having been involved in the decision of the
change, French people largely accept the new President.
However, if we learned from the news that there is a new President,
people won't accept it, because it's presented in a way that makes the
change unacceptable.

Of course, every single Firefox UI decision cannot be voted on. What
works to choose a new President in one country doesn't for a software
used by 500 million people all over the world
But there is definitely room for improvement to introduce the change in
a less intrusive way, to make it more easily accepted and not felt
imposed. From Stuart list:

"Showing images centred on a grey textured background"

The first time a user is being "imposed" this choice, a little
notification thing saying "To enable a better reability, from now on,
images and videos will be shown centered on a grey background instead of
at the top-left corner in a white background" could be prompted.
It helps the user understand that a change did happen. It's not a virus,
it's not something they have done (besides accepting the update), it's
not their fault, it's just an improvement.
A lot of people do not use computers often. They are afraid of what the
news tell them about hackers and virus. Every change may be the sign of
a threat.

What I said doesn't work for every example, but I just took 5 minutes to
come up with a solution for one case. I'll let UI/UX experts find better
solutions to make all upcoming changes more friendly.

David

[Reuben Morais]

On Jul 17, 2012, at 8:02 PM, David Bruant wrote:
> From Stuart list:

> "Showing images centred on a grey textured background"

> The first time a user is being "imposed" this choice, a little
> notification thing saying "To enable a better reability, from now on,
> images and videos will be shown centered on a grey background instead of
> at the top-left corner in a white background" could be prompted.
> It helps the user understand that a change did happen. It's not a virus,
> it's not something they have done (besides accepting the update), it's
> not their fault, it's just an improvement.

+1, and it'd be even more interesting if we also asked whether the user likes the new behavior with very simple Yes/No buttons, and then sent that feedback to input.m.o or some other dashboard. That way we can look at user response for every UI change that is noticeable enough to deserve the explanatory doorhang dialog or whatever UI we decide to use. That should help in the decision of how to introduce future UI changes.

-- reuben

[Philip Chee]

You have decorated your basement den to your liking. You have your hifi
over there, your wide screen TV over there and your carpet over here.
Every six weeks someone breaks into your house and rearranges
everything. Sometimes they hide your remote under a cushion somewhere
and you spend six weeks looking for it. Then the next day someone
rearranges your den again.

And you still can't find your remote^Wsend-link-to/statusbar/etc.

[Chris Ilias]

On 12-07-17 3:45 AM, David Bruant wrote:
> Now, Facebook provides help with noticeable UI changes and
> I'm sure it helps people.
> Maybe on UI update, Firefox could say something like "this has changed
> in your UI", "this is new" and explain how to understand the changes
> assuming the user knew the previous interface.

I agree. I suggested the same thing back in August.
<http://markmail.org/message/kb6e4ldrnhysczy3>

In addition, the firstrun (or whatsnew) page could be more helpful.
Here's a screenshot after updating Firefox:
<http://ilias.ca/screenshots/fx-whatsnewpage.png>. The whatsnew page
does not tell me a thing about what's new. It's basically an
advertisement for mobile. Not only would a user be upset about Mozilla
basically taking of the home page (temporarily) with an ad, but the user
isn't made aware of the great improvements.

Something similar to
<https://support.mozilla.org/en-US/kb/common-questions-after-upgrading-firefox-36>
would be much more helpful.

[Alex Cockell]

On 18/07/2012 03:35, dev-planni...@lists.mozilla.org wrote:
> Re: Apology from Jono about that blog post

"+1, and it'd be even more interesting if we also asked whether the user likes the new behavior with very simple Yes/No buttons, and then sent that feedback to input.m.o or some other dashboard. That way we can look at user response for every UI change that is noticeable enough to deserve the explanatory doorhang dialog or whatever UI we decide to use. That should help in the decision of how to introduce future UI changes."

What you could also do is take a leaf from the Community MAemo team (Nokia N900), and offer a toggle for some of the major UI changes - where they can be toggled - and bring it onto an Advanced tab in Edit/Prefs or Tools/Options... rather than risking the non-technical user breaking Firefox by going into "about..." what was that page? Never heard of it myself - and I'd be scared about going in there.

Alex Cockell - just another end-user who relies on Firefox not being broken.

[Gervase Markham]

On 17/07/12 00:19, Benjamin Smedberg wrote:
> The new-tab page comes to mind; I personally found it incredibly
> distracting and couldn't figure out how to turn it off until I asked in
> dev-apps-firefox, when somebody pointed me to that little dialer button
> on the upper right which turns it off.

Wow! Thanks! :-)

Yes, that is not the world's most intuitive icon.

Gerv

[Henri Sivonen]

On Wed, Jul 18, 2012 at 3:37 AM, Reuben Morais <reuben...@gmail.com> wrote:
> On Jul 17, 2012, at 8:02 PM, David Bruant wrote:
>> From Stuart list:

>> "Showing images centred on a grey textured background"

>> The first time a user is being "imposed" this choice, a little
>> notification thing saying "To enable a better reability, from now on,
>> images and videos will be shown centered on a grey background instead of
>> at the top-left corner in a white background" could be prompted.
>> It helps the user understand that a change did happen. It's not a virus,
>> it's not something they have done (besides accepting the update), it's
>> not their fault, it's just an improvement.
>

> +1, and it'd be even more interesting if we also asked whether the user likes the new behavior with very simple Yes/No buttons

This sort of thing would be the opposite of making updates silent and
unobtrusive.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Mike Hommey]

On Wed, Jul 18, 2012 at 01:36:14PM +0300, Henri Sivonen wrote:
> On Wed, Jul 18, 2012 at 3:37 AM, Reuben Morais <reuben...@gmail.com> wrote:
> > On Jul 17, 2012, at 8:02 PM, David Bruant wrote:
> >> From Stuart list:

> >> "Showing images centred on a grey textured background"

> >> The first time a user is being "imposed" this choice, a little
> >> notification thing saying "To enable a better reability, from now on,
> >> images and videos will be shown centered on a grey background instead of
> >> at the top-left corner in a white background" could be prompted.
> >> It helps the user understand that a change did happen. It's not a virus,
> >> it's not something they have done (besides accepting the update), it's
> >> not their fault, it's just an improvement.
> >
> > +1, and it'd be even more interesting if we also asked whether the user likes the new behavior with very simple Yes/No buttons
>
> This sort of thing would be the opposite of making updates silent and
> unobtrusive.

Agreed. Another way would be to do opt-in UI changes: after an upgrade,
the UI stays what it was before the upgrade, but users can opt-in the
improvements. I hear that's what chrome does.

Mike

[Reuben Morais]

On Jul 18, 2012, at 7:36 AM, Henri Sivonen wrote:
> On Wed, Jul 18, 2012 at 3:37 AM, Reuben Morais <reuben...@gmail.com> wrote:
>> On Jul 17, 2012, at 8:02 PM, David Bruant wrote:
>>> From Stuart list:

>>> "Showing images centred on a grey textured background"

>>> The first time a user is being "imposed" this choice, a little
>>> notification thing saying "To enable a better reability, from now on,
>>> images and videos will be shown centered on a grey background instead of
>>> at the top-left corner in a white background" could be prompted.
>>> It helps the user understand that a change did happen. It's not a virus,
>>> it's not something they have done (besides accepting the update), it's
>>> not their fault, it's just an improvement.
>>
>> +1, and it'd be even more interesting if we also asked whether the user likes the new behavior with very simple Yes/No buttons
>
> This sort of thing would be the opposite of making updates silent and
> unobtrusive.

That's my point – maybe we're doing UI changes *too* silently, and underestimating how obtrusive they are to users.
We can freeze the UI, hide every change between a pref, or try to teach users what's going on with their browser as of the latest restart.
The approval buttons I suggested should be as minimal as possible, something like dimmed thumbs up and thumbs down buttons in the corner of the explanatory dialog.

-- reuben

[Robert Kaiser]

David Bruant schrieb:

> Of course, every single Firefox UI decision cannot be voted on.

If we want it to be a good product, none can. Design by committee always
leads to bad design, as it will be made of nothing but compromises.

Robert Kaiser

[PhillipJones]

In other words developers know better what Users want than users do.

--
Phillip M. Jones, C.E.T. "If it's Fixed, Don't Break it"
http://www.phillipmjones.net mailto:pjo...@kimbanet.com