Batching add-on updates...
Justin Dolske
One common complaint about Firefox is that it "updates too often". It
has been suggested that users may actually be complaining about frequent
*add-on* updates, and not Firefox security updates.
The thought struck me that we could help mitigate this by batching
add-on updates so they occur less frequently. As a simple example, have
AMO defer advertising updates until the first Wednesday after the update
is approved. Consider a user with lots of frequently-updated extensions
installed -- instead of experiencing an update nearly daily, they would
then see just a single, weekly batch of updates.
I can think of a few potential issues:
* Add-on security updates should still have the ability to be pushed
more frequently. So, let's assume this would not apply to security
updates (and that add-on authors have a way to tag updates as such).
Manually doing a "check for updates" should also bypass batching, and we
could have a pref for users who don't want batching.
* Add-on authors will probably not be thrilled about waiting another
week for their users to be updated (especially after waiting, in some
cases, multiple weeks for their update to be reviewed/approved). But I
think this is a win for users, who I'm more concerned about.
* The batching could just be done by the browser, which would let us do
things like only deferring the update only if the user has already
installed an update within the last few days. This would help for
add-ons not hosted on AMO.
* Silent / unprompted add-on updates may be an even better solution, if
we're planning on doing that anyway (are we?). Batching would be
something we could do in the short-term, though.
Thoughts?
Justin
Jesper Kristensen
Silent updates would be great, but less radical changes may also work,
like allowing the user to accept an update and then allow him to do
something else while the update downloads and installs instead of
forcing him to sit and look at the download progress bar.
The most annoying thing about the dialog is when using public wifi:
"before you can log on to the internet, you must either download these
updates or choose not to update these addons at all".
Jorge Villalobos
I prefer the silent update solution.
Delaying updates for as long as a week is too much for authors; they
already have to wait a very long time to see their updates pushed. Also,
policing the urgency flag would require more work from the editor team.
We have our hands full already, and the upcoming release of 3.6 is not
going to help.
I wonder how many updates are too many for users. I have several add-ons
installed, and I don't think I get notified for updates more than once a
week. I'd like to see what the real impact of this change would be
before considering implementing it.
- Jorge Villalobos
John J. Barton
> [Followups to mozilla.dev.apps.firefox]
>
> One common complaint about Firefox is that it "updates too often". It
> has been suggested that users may actually be complaining about frequent
> *add-on* updates, and not Firefox security updates.
>
> * Silent / unprompted add-on updates may be an even better solution, if
> we're planning on doing that anyway (are we?). Batching would be
> something we could do in the short-term, though.
>
> Thoughts?
Another variation: silently download the updates but don't silently
apply them. Just put a "star" on the Tools or similar. A small tooltip
there says
You have 3 new updates ready.
[ Great, restart and update now! ]
[ Update when I restart my Firefox ]
[ Don't update, I'm old fashioned ]
It's not modal, it smallish, it just comes up quietly and you dismiss it.
Also, batching could be just twice the current lag, greatly reducing the
frequency without much impact on roll out.
jjb
David McRitchie
That would make it very difficult to tell which extensions are to blame
when something fails. If you really think that is what people would
like put it as an option as when to update right into
Tool -> Options -> Advanced -> Update
If an extension is bad I'd like to know which one by when something
failed rather than have a whole bunch installed at one time.
I'd like to see a log of extension, version, timestamp for installed, in
fact I'd also like to see installed timestamp as a column in
"Troubleshooting Information" in 3.6.
Philip Chee
> * Add-on authors will probably not be thrilled about waiting another
> week for their users to be updated (especially after waiting, in some
> cases, multiple weeks for their update to be reviewed/approved). But I
> think this is a win for users, who I'm more concerned about.
I agree. However I should point out that at least one extension authors
revenue model (NoScript) depends on near daily updates - users are
directed to a "what's new landing page" with lots of display advertisements.
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.
[ ]The Electric Chair Choice: Regular or Extra Crispy?
* TagZilla 0.066.6
Alan Baxter
>On Wed, 21 Oct 2009 13:08:33 -0700, Justin Dolske wrote:
>
>> * Add-on authors will probably not be thrilled about waiting another
>> week for their users to be updated (especially after waiting, in some
>> cases, multiple weeks for their update to be reviewed/approved). But I
>> think this is a win for users, who I'm more concerned about.
>
>I agree. However I should point out that at least one extension authors
>revenue model (NoScript) depends on near daily updates - users are
>directed to a "what's new landing page" with lots of display advertisements.
>
>Phil
I believe your information is out-of-date, Philip. In response to
user feedback, the developer releases updates which bundle bug fixes,
false-positive fixes, and additional functionality about once a week.
Only three times in the past month, as a matter of fact. Since most
of the additional functionality addresses web browsing
vulnerabilities, I can imagine the developer would consider any
changes released to AMO as best applied in a timely manner, rather
than being delayed for up to an additional week.
I also see no evidence that the developer's revenue model depends on
the "what's new landing page". I think that's an assumption on your
part. Your post sounds slanderous to me.
WildcatRay
I read this thread with a sense of irony. The Update Notifier
extension (https://addons.mozilla.org/en-US/firefox/addon/2098 and
http://www.longfocus.com/firefox/updatenotifier/) would appear to
address much of the concerns discussed. It replicates the update
notification that used to be a part of Firefox before it was Firefox.
Update Notifier functions (brief & incomplete):
Notifies user of available add-on updates
On hover, lists the available add-on updates
Enables user to download and install the the add-on updates without
having to open the Add-on Mgr.
Provides a restart menu item to finish the installation of add-on
updates
Provides a Check for (available dd-on) updates menu item so the user
can manually check for any available add-on updates
Mike Beltzner
> The thought struck me that we could help mitigate this by batching
> add-on updates so they occur less frequently. As a simple example,
> have AMO defer advertising updates until the first Wednesday after
> the update is approved. Consider a user with lots of frequently-
> updated extensions installed -- instead of experiencing an update
> nearly daily, they would then see just a single, weekly batch of
> updates.
This seems like a simple server-side change that we could make without
requiring in-product changes. My feeling is that the best approach is
still to have Add-on updates act more like product updates, as
expressed in https://bugzilla.mozilla.org/show_bug.cgi?id=511529
> I can think of a few potential issues:
>
> * Add-on security updates should still have the ability to be pushed
> more frequently. So, let's assume this would not apply to security
> updates (and that add-on authors have a way to tag updates as such).
> Manually doing a "check for updates" should also bypass batching,
> and we could have a pref for users who don't want batching.
As Jorge said, I do worry about the additional burden this puts on an
already overloaded review queue system. Not sure I have a better
solution, though. OTOH, how often are Add-on updates issued for
critical security issues?
> * Add-on authors will probably not be thrilled about waiting another
> week for their users to be updated (especially after waiting, in
> some cases, multiple weeks for their update to be reviewed/
> approved). But I think this is a win for users, who I'm more
> concerned about.
I agree; someone else on the thread mentioned that they didn't think
that it was a problem, but we know that it is. When a user clicks on
their browsing icon, they mean to browse the web, not spend time
answering questions about updates. Especially when I suspect that 99%
of the time the answer to those questions is "yes, update." (I wonder
if we can gather some data on that from the AMO guys)
> * The batching could just be done by the browser, which would let us
> do things like only deferring the update only if the user has
> already installed an update within the last few days. This would
> help for add-ons not hosted on AMO.
Again a good idea, perhaps even better than the server side one,
though it requires product side changes. My initial attraction to your
idea was the simplicity and relative ease of deployment.
> * Silent / unprompted add-on updates may be an even better solution,
> if we're planning on doing that anyway (are we?). Batching would be
> something we could do in the short-term, though.
We should be. The bug I reference above is one part of it, other parts
(no bugs on file that I know of) would be:
- ability to apply an Add-on update while the browser is running
(even if it only takes effect on restart, means that the user doesn't
have to sit through the install process)
- changing the default behaviour to always accept add-ons, not to ask
cheers,
mike
Mike Beltzner
> Another variation: silently download the updates but don't silently
> apply them. Just put a "star" on the Tools or similar. A small
> tooltip there says
We actually used to employ this mechanism (for application updates, at
least) and it was affectionately known as the "christmas tree" due to
how the particular icon looked. It had one problem: nobody noticed it,
nobody clicked on it. There are better designs we can have, and
Faaborg is looking into ways of managing all manner of "application-to-
user" communication (for Add-on updates, application updates, user
rights communication, etc)
I much prefer solutions where we take the management decision tasks
out of the hands of users, and only resort to prompting or
notification when there has been undue delay (ie: a user hasn't
restarted their browser in 72 or more hours and is putting themselves
at risk)
> Also, batching could be just twice the current lag, greatly reducing
> the frequency without much impact on roll out.
Well, I think having at most one update for Add-ons a week would be a
good start into the problem.
cheers,
mike
CAFxX
> * Silent / unprompted add-on updates may be an even better solution, if
> we're planning on doing that anyway (are we?). Batching would be
> something we could do in the short-term, though.
Justin Dolske
> The thought struck me that we could help mitigate this by batching
> add-on updates so they occur less frequently.
Thanks for the feedback, sounds like something to consider doing. I've
filed bug 524387.
Justin
Daniel Veditz
We could effectively do this right now by changing the
extension.update.interval pref from one day to seven. That even
preserves the "manual check for updates" behavior you wanted, but loses
in the security update case (which we currently can't distinguish anyway).
Doing it this way would also require some adjustments to add-on stats so
it doesn't look like eveyone's usage dropped 85%.
-Dan
bando?ers
mague.
But really now, how hard is it to click through and choose to update
your add-ons later?
I sometimes am slightly annoyed by the add-on update wait when the
connection is slow, but if I am really in a hurry I just skip it, and
even if I forget to check for updates it'll come back to haunt me soon
enough. The rest of the time I want things as updated/hopefully bug
free as possible.
Burt Henry
Steve Urbach
<drago...@NOTmindspring.com>
wrote:
block quote
You Like Malware?
block quote end
I must; I'm using Windows.
Jesper Kristensen escribi�:
> Justin Dolske skrev:
>> [Followups to mozilla.dev.apps.firefox]
>>
>> One common complaint about Firefox is that it "updates too often". It
>> has been suggested that users may actually be complaining about
>> frequent *add-on* updates, and not Firefox security updates.
Probably, but more and more menu/setup blote is a prob for me. This is
more of a lazy-user's gripe, and involves a bureaucratic solution as
opposed to an actual software enhancement; the more I think about it,
no thanks.
>>
>> The thought struck me that we could help mitigate this by batching
>> add-on updates so they occur less frequently. As a simple example,
>> have AMO defer advertising updates until the first Wednesday after the
>> update is approved. Consider a user with lots of frequently-updated
>> extensions installed -- instead of experiencing an update nearly
>> daily, they would then see just a single, weekly batch of updates.
Mitigate, maybe, for some, but how about the guy who really wants one or
more of his extensions working at its newest and best, but has to wait
through a much longer down-load on that Wed. morning, or the next time
he or she goes on-line
. I say, as a choice, OK., but why bother?
>>
>> I can think of a few potential issues:
>>
>> * Add-on security updates should still have the ability to be pushed
>> more frequently. So, let's assume this would not apply to security
And what if security and function can be fixed at the same time? someone
might even wait a couple of more days to put the sec. update out there
so that they could get the rest of the new ver on-line on say a
Thursday afternoon? instead of waiting another six days for the next
"firefox Wednesday" yuck! sounds like a micro shwagg "patch Tuesday" boo!
>> updates (and that add-on authors have a way to tag updates as such).
>> Manually doing a "check for updates" should also bypass batching, and
>> we could have a pref for users who don't want batching.
>>
>> * Add-on authors will probably not be thrilled about waiting another
>> week for their users to be updated (especially after waiting, in some
>> cases, multiple weeks for their update to be reviewed/approved). But I
Me too, but it just is not that big of a deal/I don't believe I am
wasting my time replying to this, but then again if it was made the new
default, not optional...
>> think this is a win for users, who I'm more concerned about.
>>
>> * The batching could just be done by the browser, which would let us
>> do things like only deferring the update only if the user has already
>> installed an update within the last few days. This would help for
>> add-ons not hosted on AMO.
>>
>> * Silent / unprompted add-on updates may be an even better solution,
>>
No, even worse, as for example I am blind, and there are sometimes
accessibility issues that make me want to reject an update, or at least
check it out when I have the time.
Once again as an option, not so bad, but for the new FF user it is just
another thing to have to decide when installing....But anyway thanks for
thinking about this.
I 've got it! Let someone come up with a FF extension that can be
programed to down-load updates at the whim of the user. That's it bucky.
if we're planning on doing that anyway (are we?). Batching would be
>> something we could do in the short-term, though.
>>
>> Thoughts?
>>
>> Justin
>
> Silent updates would be great, but less radical changes may also work,
> like allowing the user to accept an update and then allow him to do
> something else while the update downloads and installs instead of
> forcing him to sit and look at the download progress bar.
>
> The most annoying thing about the dialog is when using public wifi:
> "before you can log on to the internet, you must either download these
> updates or choose not to update these addons at all".
So what/ you can update manually later. Background extension updates is
a good enough idea, but to get any advantage you'd need to delay final
installation until you are ready to restart your browser.
Burt Henry
Standing On the moon; where talk is cheap and vision's true...
bando?ers
Burt Henry
John J. Barton escribi�:
> Justin Dolske wrote:
>> [Followups to mozilla.dev.apps.firefox]
>>
>> One common complaint about Firefox is that it "updates too often". It
>> has been suggested that users may actually be complaining about
>> frequent *add-on* updates, and not Firefox security updates.
> ......ng we could do in the short-term, though.
bando?ers
what happens in the end.
Alan Baxter escribi�:
> Philip Chee <phili...@gmail.com> wrote:
>> On Wed, 21 Oct 2009 13:08:33 -0700, Justin Dolske wrote:
>>
>>> * Add-on authors will probably not be thrilled about waiting another
>>> week for their users to be updated (especially after waiting, in some
>>> cases, multiple weeks for their update to be reviewed/approved). But I
>>> think this is a win for users, who I'm more concerned about.
>> I agree. However I should point out that at least one extension authors
>> revenue model (NoScript) depends on near daily updates - users are
>> directed to a "what's new landing page" with lots of display advertisements.
>>
>> Phil
>
> I believe your information is out-of-date, Philip. In response to
> user feedback, the developer releases updates which bundle bug fixes,
> false-positive fixes, and additional functionality about once a week.
Don't know the extension personally, but why could what sounds much like
a virus def update be handled silently in the background most of the
time with real function updates being much less frequent?
> Only three times in the past month, as a matter of fact. Since most
> of the additional functionality addresses web browsing
> vulnerabilities, I can imagine the developer would consider any
> changes released to AMO as best applied in a timely manner, rather
> than being delayed for up to an additional week.
Dunno, but I am thinking of something like addblock+...
>
> I also see no evidence that the developer's revenue model depends on
> the "what's new landing page". I think that's an assumption on your
> part. Your post sounds slanderous to me.
A "what's new" landing page isn't evil in my mind, and can be easily
clicked away. I would think add revenue might be important to the
developer, but anyway the word is liable not slander as it is written,
not spoken. (or as my tenth grade Eng. teacher said "liable is slander
on paper."
Cheers,
Burt H.
"I feel sorry for people who don't drink. Because when they wake up
in the morning, they know that's as good as they're gonna feel all
day." - Frank Sinatra