After the last few blog posts [1], [2], [3] explaining details of some gotchas, here are a few mechanical ideas which might help. I’m not sure which, if any, make sense to try, but wanted to point out some new options we have available to us now after infrastructure improvements over the last year, and would love to hear what people thought.
1) Make major update available on the day of a release but only visible to users on latest dot release who do manual “check for updates”.
To take a concrete example, this would mean on the day of the FF3.5 release, that any user on the latest FF3.0.x release would be able to “check for updates” and immediately major update to FF3.5. Explicitly only users who were on the latest FF3.0.x and who actively “check for updates” would get this offer. Any users who are on older FF3.0 releases who do “check for update” would be updated to the latest FF3.0.x release.
This new option is only possible because of pre-release work done by both RelEng and QA, to verify that major update from FF3.0.n->FF3.5rc goes smoothly before the FF3.5 release, and an enhancement to AUS by
morgamic. We first practiced this in the lead up to the FF2->FF3.0 release, and were able to do major update much faster and smoother as a result, but the FF3.5 release will be first time we do this live on release day. Why is doing this on release day so important?
- Better mindshare: Mozilla typically gets more attention/blogs/press coverage on major release days. Making the most of this momentum in user mindshare by having major updates available and waiting for users who want them seems useful.
- Better experience for existing users: During the FF3.0 release, we saw an abnormally high spike in number of people doing manual “check for updates” on release day. We also saw a drop in FF2 users and an increase in FF3 users long before we released our first FF2->FF3 major update. One theory was that FF2 users saw press coverage about the new FF3.0 release, did “check for updates”, saw “no update available” so then manually downloaded FF3 and do a pave-over install. We can make the upgrade experience for our existing users better by letting any existing user who does “check for updates” get the major update, instead of having to manually download + pave-over manual install.
- Safer: A user on older FF2 who did check for updates would first get the update to FF2.0.0.20, and if they do “check for updates” again, would get the FF3.0 update. What we’d like to avoid is having users on old FF2.x doing paveover installs of FF3.0, and potentially discovering unknown migration bugs that we have not tested for. Having users follow a tested migration path seems safer.
- This would *not* do major update offers to idle users, only to users who explicitly take manual steps seeking out new release. This addresses worries about a) too much load on mirrors on release day and b) users upgrading to something that has some critical bug we don’t know about yet.
2) Every time we do a dot-release on new release line, make a new major update offer available to the older release line.
This approach basically views each major update offer as a new “security release” for the EOL’d older product line. For example, if we did this today, it would mean that whenever we release a new FF3.0.7, we would also release a new FF2.0.0.20->FF3.0.7 major update offer… and later when we release a new FF3.0.8, we also release a new FF2.0.0.20->FF3.0.8 major update offer.
- this would mean that users on the older FF2.0 release will be prompted to major update as often as users on FF3.0.x are prompted for new security releases. If there are concerns about update fatigue, we could make this major update offer always be visible to users who do a manual “check for update”, and only chose to make this major update offer visible to idle users at certain times.
- this would mean users who skipped over a major update offer previously (see earlier blog for details) would have improved odds of seeing *any* major update offer.
- mechanically, we could do this new major update offer at the same time as the actual new dot release, but I think it makes more sense to wait a few days just to make sure there are no respins/zerodays.
3) Offer major update for multiple dot releases
Historically, we only provide major update offers from latest dot release because:
- it has the most users
- they are already shown to care about updating and
- thats all we had time to generate and test updates for.
However, mechanically now that we have streamlined the process, we can now also cherry pick some other dot-releases to provide major update offers for at the same time. For example, we could provide major updates
for the top three most populated dot releases (today that is FF2.0.0.20, FF2.0.0.18 and FF2.0.0.14) at the same time. However, some concerns are:
- this takes some extra work in RelEng, and has more significant testing load on QA, so how often this is even possible depends on other work at the time.
- the users still on FF2.0.0.14, FF2.0.0.18 have already said “no” to minor updates for FF2.0.0.19, then FF2.0.0.20, so its not clear how many would accept a major update offer.
4) Change the major update dialog
Changes to the update system are always scary, and slow to roll out, because we have to wait an entire product release cycle. However, while they are kinda beyond the scope of this blog post, I wanted to raise two suggestions here:
Right now, when a user gets a major update offer, and clicks “Later”, that actually means “no and don’t ask me again until you create a new different major update offer”. What if we changed the client updater as follows:- Rename the “Later” button to “Not this time”; no change in functionality
- Add a new “Ask me again when I next start/exit” button, which would find what major update offer was available on next start/exit of browser, and re-prompt the user.
- or maybe simpler to change the “Later” button functionality to ask user again on next start/exit, and not add a 4th button?
- In a recent brainstorming session with beltzner one Friday night, another possible enhancement was to track when the user sees a major update offer, and don’t re-prompt that user for another major update offer within ‘n’ days of the last major update offer that user saw. This would help address the user skipping over major updates, and also prevent user-update-fatigue concerns.
Hopefully those scenarios all make sense. There’s been a lot of behind-the-scenes plumbing improvements over the last 18months, so hopefully these blog posts help raise awareness for some new options that are now mechanically possible.
UPDATE: Added dialog box screenshot, along with suggestion of changing functionality of existing “Later” button. John 10mar2009
I like this, especially the increased coverage of old dot releases. I would just say, and I’m sure you’ve considered it, that if it’s possible to notify users on a non-supported old release that the upgrade process is going to be two-step (to make sure that all data is migrated safely, etc) that will save a lot of confusion and probably frustration. (I wanted to upgrade to 3 not 2! what’s going on? how do I upgrade?)
Obviously a double-upgrade is kindof lousy because of the fact that you have to restart Fx, and restarts (especially with lots of tabs) aren’t exactly the speediest operation, so the fewer the number of people that have to do that, the better.
With regards to the “How many people would accept the MU offer,” slightly more than half (subjectively) of the people that I’ve upgraded didn’t know that they were on an old release. The fact that “Later” means “Possibly never” or “Extremely Rarely” is not what people from a microsoft background are used to 🙂 Gently prompting every 6 weeks or so is probably completely acceptable and even a good idea, in my book.
I’m sorry to nag.. but we expect people to be able to download 3.x and install it regardless of what point release of 2.0.0.x they have. QA doesn’t test every point release migration path for that, why can’t we extend the same minimal compatibility to these users rather than cherry picking particular point releases?
If we wanted to be more upfront with the users, I guess we could build some sort of wrapper installer that told the user what they are potentially in for, and maybe even offer them the choice of upgradding to the latest point release for them, run that version (to do whatever migration is needed) and then upgrade to the major. At least that streamlines the process for them.
I thought the “Later” button meant “ask me again in X hours”, whereas the “Never” (renamed “No thanks”) button meant “don’t ask me again for this particular Major Update offer”. Am I way off here? Do you talk about adding a fourth button to the major update dialog?
I really like 1 and 2, not so sure about 3 (esp. due to the last point you make here yourself) – and 4 might be useful but might need some more careful UE thinking.
It seems the main problem is that you can’t do a 2.(any)->3.(latest) upgrade, because of possible migration issues since testing all upgrade paths would be a huge task. But couldn’t you, instead of having a lot of upgrade paths, lead the users on a upgrade hiway? That is, a user on any old major version (1.x or 2.x) would first be upgraded along that major version (possibly to 1.(latest) or 2.(latest)) until a major upgrade was possible and then upgraded on that branch, etc.
To the users this would be advertised as a upgrade to the latest version (perhaps users would be allowed to choose what major version they would like to end at — with the latest being the defualt — if they have some particular objection to the latest major version). All the upgrades would be combined into one UI with one common progress bar. This would mean that the tested upgrade machinery would be used, but to the user it would look as one upgrade.
Then any version (minor or major) larger than the user current could be advertised to the user, so users on old versions wouldn’t ever stop receiving those pesky upgrade dialogs.
The increased download size might be a issue, but then make it easy to have the download happen in the background. For example, when a upgrade is available you start downloading in the background and just popup a yellow bar in the top of the screen (the kind we by now are trained to ignore) saying that you have done so and giving some — not to easy to accidentally hit — way of stopping it.
If the load on mirrors starts to become a issue, wouldn’t it become time to look at using something like bittorrent in the browser to help out via web seeding.
Lastly, couldn’t the upgrade dialogs be contained in a “system addon” (that couldn’t be removed or could easily be restored) so they would be upgraded independently of the browser, so you are not continusly a cycle behind? It seems to me that the upgrade checker/dialogs/advertising/offer doesn’t need to be deep inside the browser.
It should be possible on the AUS side to offer both a major and minor update at the same time (in the same update.xml), any reason not to do that and then change the client so the user is offered a choice between major and minor update?
[…] AndersH asked an important question in comments to my last post., which deserved a proper response, hence this blog post. Thanks AndersH, sorry, I should have been more clear. […]
Hey AndersH, I like your separate updater idea. What comes to mind is a lot of software does have this separation of update service. Like Apple’s Software Update, which alot of us hate. And I think Adobe has one too. But ours could be better, we already have updater.exe (which got a brand new icon that I don’t like, the old one was better) and currently I don’t know what happens if I try to open updater.exe with Firefox open or closed, but could we have it open standalone and ask if we want to update Firefox.
I think though that we could add a ‘Check for Firefox updates’ shortcut in the user’s Mozilla Firefox start menu folder, even though some users never look there. Also I’m not a fan of the downloading a update in the background while surfing, this makes the user think the browser is slow while they’re surfing forgetting they are doing a background update. It seems to only benefit 56k users. I’d rather an in your face immediate download of an update happened for users with a fast connection.
And there’s a enhanced Firefox desktop icon that’s been created a few years ago, that I think should be used by default in Firefox. Where a user can simply choose Safe Mode, Crash Reports, Check for Updates, etc just by right clicking the desktop icon. Currently, I think we only have “Browse the Internet” & “Firefox Options”.
It’s called a desktop namespace shortcut:
https://bugzilla.mozilla.org/show_bug.cgi?id=264889
Although I think we should tie in Check for Updates, Crash Reports, and Profile manager choices on the menu.
Bah… I misspoke to John and switched the purpose of the Later button with the purpose of the Never button.
I created the namespace icon for Firefox, etc. years ago and as it stands it is not something I would provide in an official release as I stated in the bug.
With effort it is possible to separate the update check from the browser as is other apps have done. The binary that actually applies the updates is completely separate though it is launched by Firefox… this gives us a lot of assurance that it isn’t doing bad things since it never touches the net.
As for the problem with being one update behind being solved by separating the update process completely from Firefox I’m not convinced this is the only or best way to fix that. As a matter of fact for Windows if we implemented MSI’s we could use the MSI update facility which also allows non-admin users to update as long as the same cert is used.