Closed Bug 689679 Opened 13 years ago Closed 13 years ago

Add What's New page to the Firefox Update Experience

Categories

(Firefox :: General, defect, P1)

Product:
Firefox
Component:
General
Version:
8 Branch
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 10
Tracking Flags:
Tracking Status
firefox7 --- wontfix
firefox8 --- fixed
firefox9 --- fixed

People

(Reporter: lmesa, Assigned: christian)

References

Details

(Whiteboard: [qa!]) 

Re-add the WN page for the Firefox 8 update experience. 

Was removed in 685727 and would like it back.  Ideally this is something from now on that we would be able to easily turn off and on when needed in the future.
Assignee: nobody → clegnitto
See Also: → 685727
Summary: Add What's New page from the Firefox Update Experience → Add What's New page to the Firefox Update Experience
Target Milestone: --- → Firefox 8
Blocks: 689844
(In reply to Laura Mesa [:lmesa] from comment #0)
> Re-add the WN page for the Firefox 8 update experience. 
> 
> Was removed in 685727 and would like it back.  Ideally this is something
> from now on that we would be able to easily turn off and on when needed in
> the future.
Specifically, bug 459972 should provide this.
Priority: -- → P1
Awesome. Now that 459972 is fixed:

Is it possible to show 3.6 upgraders a specific WN page, ideally (http://www.mozilla.org/en-US/firefox/7.0/firstrun/)

If not, we'd just like to show everyone the FR page content for a limited amount of time, but we'll just reuse that page and do some redirects from the web dev side.
First run is only shown when there is no profile. There will be a profile coming from 3.6. You won't be able to do redirects on the web side because a 3.6 -> 7.0/8.0 will look the same as a 7.0/8.0. The only way that would work is for the 8.0 snippets to turn off the whatsnew page, so you would know the only people seeing the whats new page were the ones going from 3.6...but, because 3.6 doesn't support the new snippet attributes I see no real way of supporting what you want.
(In reply to Christian Legnitto [:LegNeato] from comment #3)
> First run is only shown when there is no profile. There will be a profile
> coming from 3.6. You won't be able to do redirects on the web side because a
> 3.6 -> 7.0/8.0 will look the same as a 7.0/8.0. The only way that would work
> is for the 8.0 snippets to turn off the whatsnew page, so you would know the
> only people seeing the whats new page were the ones going from 3.6...but,
> because 3.6 doesn't support the new snippet attributes I see no real way of
> supporting what you want.

Thanks Christian. One way we can meet both needs is to:
-Change the content of the current What's New page (that will be shown to these people) to contain First Run content. URL would be /whatsnew, content will show introductory First Run content. Webdev can make this change. 
-Then after that, change the content on What's New back to the What's New content we're in the process of designing to support the Fx8 launch, since we'll be using the What's New page again after a break during Fx7. 

Essentially time the content based on the types of people who will be seeing this page at a given time. 

Open question to me is the timing around this, as we'd need to "change back" the content before the launch of Fx8 and the 3.6 MU timing is unclear to me.
Hmmm, so we could do that, though I think this might work:

1. Reland the "whatsnew" patch back into Fx8 (what this bug is about)
2. Use the snippets to suppress the what's new page (bug 459972) on 4/5/6/7 -> 8 minor update
3. Offer the MU with the same snippet and/or snippets without the new key

I *think* that will make it so 4/5/6/7 -> 8 won't see the page (Firefox acting on the new snippet key) but 3.6 -> 8 will (default is now to show the page due to #1/this bug and 3.6 doesn't understand the new keys so it won't tell Fx8 to not display the tab).

rs, does that sound sane?
I added what's new back by default (#1 in comment 5, what this bug was about):

http://hg.mozilla.org/mozilla-central/rev/8cd539c42102
http://hg.mozilla.org/releases/mozilla-aurora/rev/851dcf5a6ad1
http://hg.mozilla.org/releases/mozilla-beta/rev/41fe33006ba2
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
qa+ for verification on Firefox 8, 9, and 10. Can we get status flags set for tracking purposes?
Whiteboard: [qa+]
status-firefox7: --- → wontfix
status-firefox8: --- → fixed
status-firefox9: --- → fixed
Target Milestone: Firefox 8 → Firefox 10
(In reply to Christian Legnitto [:LegNeato] from comment #5)
> Hmmm, so we could do that, though I think this might work:
> 
> 1. Reland the "whatsnew" patch back into Fx8 (what this bug is about)
> 2. Use the snippets to suppress the what's new page (bug 459972) on 4/5/6/7
> -> 8 minor update
> 3. Offer the MU with the same snippet and/or snippets without the new key
> 
> I *think* that will make it so 4/5/6/7 -> 8 won't see the page (Firefox
> acting on the new snippet key) but 3.6 -> 8 will (default is now to show the
> page due to #1/this bug and 3.6 doesn't understand the new keys so it won't
> tell Fx8 to not display the tab).
> 
> rs, does that sound sane?
Yes it does.
Great, thanks for the confirmation. Bug 682805 tracks the RelEng changes required to generate snippets with the proper attributes. Bug 459972 had the server-side changes which look to have gone live.
FWIW, everyone knows that we're getting a lot of flack about frequent updates. Part of the silent update effort is to make updates transparent for the user. Unless there is a very compelling reason to show the WNP in FF8 I would suggest that we keep it turned off to demonstrate our commitment to addressing this customer pain point.
Lawrence, I agree with you, but I think we shouldn't switch whatsnew page off until we figure out other ways to show the user how to follow mozilla or his mozilla local community in the social networks. The potential of having users following us on social networks is huge to get people involved or informed.
Thanks Lawrence and Ruben--

There are a lot of pros and cons to weigh here and Chris Lee brought this to my attention yesterday. I'm talking with engagement team leads to see what the best resolution is. Thanks.
Reuben - I agree with what you said. We need to better understand the pros and cons as Laura said in order to make an informed decision.

Laura - Glad you're looking into this. Please let me know if I can be of help.
Someone needs to make a non-engineering decision. I am anointing Marketing. Talk it over with Product and come back with a definitive answer ASAP.

Product marketing made the call previously to hide it in all cases as the "hurt" for mainline outweighed the benefit of talking to those users and helping upgrading 3.6 users. Then, when we went to prompt to 3.6 users it was decided that the opposite was true.

If bug 682805 and bug 459972 (and this one) are fixed we can hide the tab for 4/5/6/7/8+ users (making updates more silent) and show the tab for 3.6 -> 8+ users (telling them about the new features and changes and getting them involved)...a middle ground.

We're reasonably confident we can get them in time, but if we don't we either need to a) live with a what's new tab for everyone or b) wait even longer to start moving 3.6 people to something modern.  We should not delay the 3.6 prompt again. It is my understanding we can't try for the middle ground and stay silent if we don't get it done in a timely manner. Of course, I could be wrong...this isn't my code.

*Nothing* has changed since we had this discussion for Firefox 7. So pick one.

I also want to point out:

1. Showing a what's new page between major versions (the 3.6 -> 4/5/6/7/8+ case) is what we have always done...users expect it and don't have "update rage" on the 3.6 branch

2. Major versions were always noisy for good reason (lots of new features, add-on incompat, large UI changes, etc). Rapid release has not changed this (for the 3.6 -> 4/5/6/7/8+ case)

3. Opening a tab after the update is probably the least intrusive non-silent part of the update experience. Any time spent on this bug by rs, QA, etc is time taken away from other, higher priority work

4. This change means that beta users see a new tab every week (this is no different than betas before bug 685727 landed and our beta audience lived with it)

5. Eventually we'll move beta snippets to the silent stuff server-side as well
>If bug 682805 and bug 459972 (and this one) are fixed we can hide the tab for >4/5/6/7/8+ users (making updates more silent) and show the tab for 3.6 -> 8+ users >(telling them about the new features and changes and getting them involved)...a >middle ground.

This makes perfect sense to me.

>3. Opening a tab after the update is probably the least intrusive non-silent part of >the update experience. Any time spent on this bug by rs, QA, etc is time taken away >from other, higher priority work

AFAIK rs has completed his work here (back in FF4). The remaining work is primarily for releng and QA after a decision is made. I agree that the WNP is on the lower end of the intrusive scale. Users have complained specifically about this issue (saw the complaints on Twitter) and it does require a click to close the page. While this is a smaller silent update win I still think it is a win.
(In reply to Lawrence Mandel [:lmandel] from comment #13)
> Reuben - I agree with what you said. We need to better understand the pros
> and cons as Laura said in order to make an informed decision.

This hasn't changed. The tradeoffs are understood and have been so since Firefox 7 was in beta and the previous decision was made.

Option #1
------------------
* Blank out the what's new URL (bug 685727)
PRO: No tab for 4/5/6/7 -> 8, potentially reducing update rage
PRO: No tab for Firefox Beta users, potentially reducing update rage
CON: Can't turn it on via snippets
CON: No tab for 3.6 -> 8, reducing help/engagement after the upgrade
CON: No tab for 4/5/6/7 -> 8, reducing engagement
CON: No tab for Firefox Beta users, reducing engagement

Option #2
------------------
* Have a what's new URL (this bug)
PRO: Potential to hide what's new tab via snippets for only 4/5/6/7 -> 8
PRO: Tab for 3.6 -> 8, allowing help/engagement after the upgrade
PRO: Tab for Firefox Beta users, increasing engagement
CON: Tab for Firefox Beta users, potentially increasing update rage
CON: Puts bug 682805 and bug 459972 in the critical path for the desired case
CON: 3.6 users will not see a new tab helping them after the upgrade
CON: Tab for 4/5/6/7 -> 8 if bug 682805 and bug 459972 aren't done in time

As I am sure everyone inherently knew, they are basically the inverse of each other except that option #2 leaves open a better possibility (but the fallback could be worse)

Metrics to help make the decision
------------------------------------

1. How much engagement (facebook/twitter/newsletter) do we get from the what's new page?
2. How many 3.6 users saw the what's new page for the Firefox 3.6 -> 4 prompt?
3. How many 3.6 upgraders interacted with the what's new page?
4. How "ragey" does the what's new tab make users?


Ooh, and I forgot to point out this HUGE consideration:

3.6 point releases always showed the what's new tab (option #2). They were around every 5 weeks. So this is one aspect that hasn't changed AT ALL in the rapid release process (though you could argue users are more sensitive to it I guess).

So to me, it looks like we are being overly sensitive and skewering the new release process for something that actually hasn't changed since probably 2.0. I don't think this "issue" is worth the mental energy and churn that has already happened around it and fairly annoyed that we have 6 fewer weeks of 3.6 people being prodded to update to a modern version.
(In reply to Christian Legnitto [:LegNeato] from comment #16)

Very good response. Thanks.

> So to me, it looks like we are being overly sensitive and skewering the new
> release process for something that actually hasn't changed since probably
> 2.0. I don't think this "issue" is worth the mental energy and churn that
> has already happened around it and fairly annoyed that we have 6 fewer weeks
> of 3.6 people being prodded to update to a modern version.

+1
comment #16 +1

I think it is important to note that the bypassing of the UAC dialog (as far as user interaction goes) just removes one click just as removing the what's new page does. I personally think that removal of the UAC dialog is a good thing to do but not much if any more important than removing the what's new page. I am fairly certain that any additional update rage is due to rapid release having around 8 major updates per year which can cause add-on compatibility which requires the user to opt-in to the update compared to 1 major update that often took well over a year.

In summary, I think this is a good thing to do but no more or less important than the bypassing of the UAC dialog for release users and that the big ticket item is getting the add-on compatibility story fixed.
Agree.

Rereading my comment 16 sounded like I was raging a bit (comment rage?) when it wasn't meant to be, apologies. I just wanted to explicitly lay the options and considerations out there.

I'm going to track this for 8beta and reopen it so we know there is outstanding work/a decision to be made.

Now in a holding pattern awaiting Marketing's decision :-)
Status: RESOLVED → REOPENED
tracking-firefox8: --- → +
Resolution: FIXED → ---
Thanks all--I've sent an email to all engagement stakeholders and should have a response to add here late Monday one way or the other. 

Nukeador--I don't want you to think we aren't thinking about the situation for communities because I agree its very important.  We're in a situation where we're trying to do the best for the largest number of people.  I would love to spend some time thinking with you about some alternative ways of community promotion outside the WN page. I'll send you an email so we can get in touch to talk.
(In reply to Christian Legnitto [:LegNeato] from comment #16)
> Metrics to help make the decision
> ------------------------------------
> 
> 1. How much engagement (facebook/twitter/newsletter) do we get from the
> what's new page?

For the record, Spanish locales where we point to the Mozilla Hispano community Facebook page, for example for Firefox 6, we got 11375 new users in the first two weeks after release. After Firefox 6.0.1 release we got 12287 new more users. Since we update the page a few times a week, we're getting a lot of movement from users that want to read about Mozilla in their language ;)
Hi all,

So after speaking with engagement leads, we will not be showing a WN page with the Firefox 8 update, but we will show one with Firefox 9 to support some branding efforts related to quarterly goals.  

In terms of comment 16, I have one question:

Option #2
------------------
* Have a what's new URL (this bug)
PRO: Potential to hide what's new tab via snippets for only 4/5/6/7 -> 8
PRO: Tab for 3.6 -> 8, allowing help/engagement after the upgrade
PRO: Tab for Firefox Beta users, increasing engagement
CON: Tab for Firefox Beta users, potentially increasing update rage
CON: Puts bug 682805 and bug 459972 in the critical path for the desired case
CON: 3.6 users will not see a new tab helping them after the upgrade
CON: Tab for 4/5/6/7 -> 8 if bug 682805 and bug 459972 aren't done in time

In this section one pro says:
"PRO: Tab for 3.6 -> 8, allowing help/engagement after the upgrade" and on con says: "CON: 3.6 users will not see a new tab helping them after the upgrade" which seem to contradict each other. 

If i understand this correctly, the pro is correct, and the con was misplaced?
Status: REOPENED → ASSIGNED
tracking-firefox8: + → ---
Christian? Just wanted to make sure I'm understanding this right.
Ping, Christian?
(In reply to Laura Mesa [:lmesa] from comment #22)
> CON: Puts bug 682805 and bug 459972 in the critical path for the desired case

Nearly done on both. We will suppress what's new for 8.0b5, via a patch on bug 682805.

But note that we've discovered that 8.0bX -> 8.0bY updates don't get a what's new anyway. That's because the milestone doesn't change, being 8.0 for all. We'd have to change the app code if you want that to behave differently (in a new bug!). 4/5/6/7bN -> 8.0bY do have a what's new, and we'll start suppressing it.

> If i understand this correctly, the pro is correct, and the con was
> misplaced?

[Legneato impersonation mode enabled] Yes, I agree.
(In reply to Nick Thomas [:nthomas] from comment #25)
> (In reply to Laura Mesa [:lmesa] from comment #22)
> > CON: Puts bug 682805 and bug 459972 in the critical path for the desired case
> 
> Nearly done on both. We will suppress what's new for 8.0b5, via a patch on
> bug 682805.
> 
> But note that we've discovered that 8.0bX -> 8.0bY updates don't get a
> what's new anyway. That's because the milestone doesn't change, being 8.0
> for all. We'd have to change the app code if you want that to behave
> differently (in a new bug!). 4/5/6/7bN -> 8.0bY do have a what's new, and
> we'll start suppressing it.
The requirement was to add this for releases so this doesn't surprise me though I don't recall the specifics since it has been a long time since I added the code to Firefox. The code that controls this is entirely in browser
http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js#599
That's exactly what I mean, yeah. We have a OVERRIDE_NEW_BUILD_ID case now, when previously the version always changed and we were OVERRIDE_NEW_MSTONE.
Thanks Nick--

So we want to move ahead with option 2 (sounds like almost all the pieces are in place to make that happen). 

Do you need anything else from me?
Maybe just a reminder when 9 comes along to turn it on again.
One question that just came up (and I don't think this effects the plan at all, but just want to triple check):

In Christian's Option 2 (below)

Option #2
------------------
* Have a what's new URL (this bug)
PRO: Potential to hide what's new tab via snippets for only 4/5/6/7 -> 8
PRO: Tab for 3.6 -> 8, allowing help/engagement after the upgrade
PRO: Tab for Firefox Beta users, increasing engagement
CON: Tab for Firefox Beta users, potentially increasing update rage
CON: Puts bug 682805 and bug 459972 in the critical path for the desired case
CON: Tab for 4/5/6/7 -> 8 if bug 682805 and bug 459972 aren't done in time

Assuming bug 682805 and bug 459972 are fixed means that:

1) We will not show a WN page for 4/5/6/7 -> 8
2) We will show a WN page for 3.6->8 users.

Is there any issue if we create a redirect on the webdev side for the 3.6 ->8 WN page so that http://www.mozilla.org/en-US/firefox/8.0/whatsnew/ redirects to http://www.mozilla.org/en-US/firefox/central/ for a period of time? We can them get webdev to remove once we set up the WN page for Fx 9.

The reason we want to do this is that we think the content on the /central/ page is much stronger for the user moving from 3.6 to 8 than the current FR page.
(In reply to Laura Mesa [:lmesa] from comment #30)
> One question that just came up (and I don't think this effects the plan at
> all, but just want to triple check):
> 
> In Christian's Option 2 (below)
> 
> Option #2
> ------------------
> * Have a what's new URL (this bug)
> PRO: Potential to hide what's new tab via snippets for only 4/5/6/7 -> 8
> PRO: Tab for 3.6 -> 8, allowing help/engagement after the upgrade
> PRO: Tab for Firefox Beta users, increasing engagement
> CON: Tab for Firefox Beta users, potentially increasing update rage
> CON: Puts bug 682805 and bug 459972 in the critical path for the desired case
> CON: Tab for 4/5/6/7 -> 8 if bug 682805 and bug 459972 aren't done in time
> 
> Assuming bug 682805 and bug 459972 are fixed means that:
> 
> 1) We will not show a WN page for 4/5/6/7 -> 8
> 2) We will show a WN page for 3.6->8 users.
> 
> Is there any issue if we create a redirect on the webdev side for the 3.6
> ->8 WN page so that http://www.mozilla.org/en-US/firefox/8.0/whatsnew/
> redirects to http://www.mozilla.org/en-US/firefox/central/ for a period of
> time?

Nope.

Closing this as option #2 is what is currently in tree
Status: ASSIGNED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
This was verified for Firefox 8 when the "Silent Update whatsnew" feature was introduced.
Should the WN page be displayed for Firefox 9? What channel should be used to test the updates? 
On beta and betatest WN page is not displayed at update from 7beta to 9 beta; 
3.6.24 updates to 8.0 on beta and betatest channels.
Can someone please reply if What's new page should be displayed for updates to Firefox 9? If it should and further testing is wanted for this, please configure the update paths to verify on a test channel.

Thank you!
Laura (lmesa) has previously said that we would have a What's New for Fx9, but that change has not been made to the update config yet. Please open a bug in mozilla.org::Release Engineering if you would like to do that.

NB: Even with a change, updates from 9.0 beta to the latest 9.0 beta won't show what's new (see comments #25-27).
Blocks: 706488
(In reply to Nick Thomas [:nthomas] from comment #34)
> Laura (lmesa) has previously said that we would have a What's New for Fx9,
> but that change has not been made to the update config yet. Please open a
> bug in mozilla.org::Release Engineering if you would like to do that.
> 
Just filed https://bugzilla.mozilla.org/show_bug.cgi?id=706488
Considering comment #31, comment #34 and the fact that the "Silent Update: What's new page" feature was landed and verified in Firefox 8, I mark this as VERIFIED and move the QA work to bug #706488.
Status: RESOLVED → VERIFIED
Whiteboard: [qa+] → [qa!]
You need to log in before you can comment on or make changes to this bug.