1004734 - Create "What's new!" notification on browser update

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Some users may interested to know about the new features that show up in each version of Firefox and so having a "What's new" page pop up when the browser is updated could be useful.

In its most simplest form, this can take the form of a prompt - "Would you like to see what's new in Firefox?" - that opens the changelist in a new tab, or a native UI widget. In more complex solutions, we can provide a new-version tour (similar to our first-run tour), those this may not be feasible due to engineering effort.

Note this may also help (and save the time of) users who may be confused by misplaced UI elements, removed features, etc.

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Ian, Finkle requested you be needinfo'd. :)

Comment 2

[Ian Barlow (:ibarlow)]

Thanks for filing this, Mike. We're in the midst of designs for this, we'll post some sketches soon.

Comment 3

[Aaron Train [:aaronmt]]

Re: if it will be an actual accessible page, are we past the point of concern re: browser startup performance with loading content?

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Aaron Train [:aaronmt] from comment #3)
> Re: if it will be an actual accessible page, are we past the point of
> concern re: browser startup performance with loading content?

I think you mean to say: With the Gecko taking a non-trivial amount of time to load, maybe any What's New should be a native Android popup.

Comment 5

[Aaron Train [:aaronmt]]

Yes (otherwise then we could create the wanted custom home-page settings).

Comment 6

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Mentioned this on IRC but haven't left a comment here so:

This was actually something I considered when designing the newer "First Run" experience so I made it block that meta to get this bug tracked.

Comment 7

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Anthony, any thoughts on mocks for this or are we waiting on user studies?

I'm thinking this could be a good mentored bug.

Comment 8

[:Margaret Leibovic]

I also worry about the performance of showing a normal webpage on startup, so I think we should try to do something here with native UI.

If we are building this as part of the browser, one concern I have is localization, since we don't usually know what we want to market as new in a given release until it's already off of Nightly.

As a first approach (and something we could actually do today), we could create a snippet that points to a "What's new" webpage. The main challenge here would be maintaining that page on each update.

Maybe a hybrid approach could be a piece of native UI that we can populate with content pulled from the network, similar to snippets. Although this might also not work well for something we want to show during startup.

Comment 9

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to :Margaret Leibovic from comment #8)
> As a first approach (and something we could actually do today), we could
> create a snippet that points to a "What's new" webpage. The main challenge
> here would be maintaining that page on each update.

I filed bug 1166800.

> Maybe a hybrid approach could be a piece of native UI that we can populate
> with content pulled from the network, similar to snippets. Although this
> might also not work well for something we want to show during startup.

We could also parse the remote content (e.g. JSON) and display it in native UI.

Comment 10

[:Margaret Leibovic]

(In reply to Michael Comella (:mcomella) from comment #9)

> > Maybe a hybrid approach could be a piece of native UI that we can populate
> > with content pulled from the network, similar to snippets. Although this
> > might also not work well for something we want to show during startup.
> 
> We could also parse the remote content (e.g. JSON) and display it in native
> UI.

Yeah, that's the approach I would like to take (that's what we do with snippets). But if we need to download this JSON, there's still some potential for delay before we can show something to the user.

Comment 11

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to :Margaret Leibovic from comment #10)
> Yeah, that's the approach I would like to take (that's what we do with
> snippets). But if we need to download this JSON, there's still some
> potential for delay before we can show something to the user.

We can download the JSON the first time the user opens Firefox and display it the second time - I don't think most users will notice the discrepency since the update since I assume most users auto-update apps. If we want to make this more involved, we can also download the JSON in a Service.

As a side note, we should consider whether we want to show "What's new" when 1) Firefox is clicked and 2) an external link is opened.

Comment 12

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Michael Comella (:mcomella) from comment #7)
> Anthony, any thoughts on mocks for this or are we waiting on user studies?
> 
> I'm thinking this could be a good mentored bug.

Right now, Chenxia and I are working on the next steps to a "First Run". I plan to re use a lot of the UI from there though so I can throw something together.

Comment 13

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Idea: Could we potentially have a "about:whatsnew" tab open for users that just updated? then, we could list out what's new in there and they could have a sense/context of how to get back to it. This might have the added benefit of being web-based as well compared to putting it in the First Run slides...

Or, we could put a section in About:firefox and show this page in a new tab on startup (after user updates)

Comment 14

[Barbara Bermes [:barbara] - NI please!]

Cleaning up the onboarding meta, would you agree that this bug is more a general idea to keep the user informed about the updates but is not necessarily related to the first app run.

The way I understand first app run is the event you trigger after you've downloaded the app but not after it has been updated on your device.

Comment 15

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Barbara Bermes [:bbermes] from comment #14)
> Cleaning up the onboarding meta, would you agree that this bug is more a
> general idea to keep the user informed about the updates but is not
> necessarily related to the first app run.

I agree.

Comment 16

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

iOS Firefox is moving forward with showing a SUMO page in a new tab as per bug 1240832.

Instead of just loading a new tab. I like the idea of showing a notification first. Perhaps this is something we can test if other people are unsure but I think we can first prompt the user with a notification that then opens our SUMO page in a new tab for them. 

This way, there's no anxiety around "where did this tab come from?".

Here's what I'm thinking for copy:

+--------------------------------------------+
|                                            |
|  +-+  Firefox is up to date                |
|  +-+  Find out what's new in this version  |
|                                            |
+--------------------------------------------+

NI-ing Matej to see if he has thoughts

Comment 17

[:Margaret Leibovic]

I think we should put this notification behind a switchboard flag. Then we can decide for a given release whether we want to show this or not, and we can also do a staged rollout. Hell, if we enable a new feature with switchboard, we could even show the user a notification about it at the same time.

Comment 18

[Barbara Bermes [:barbara] - NI please!]

All good ideas.

However, we should still keep track of experiments and go through a process of what constitutes an experiment i.e. following the template from the Growth team.

The UX idea seems logic and simple and I like that we trying leverage things that iOS is doing.

Comment 19

[Matej Novak [:matej]]

(In reply to Anthony Lam (:antlam) from comment #16)
> iOS Firefox is moving forward with showing a SUMO page in a new tab as per
> bug 1240832.
> 
> Instead of just loading a new tab. I like the idea of showing a notification
> first. Perhaps this is something we can test if other people are unsure but
> I think we can first prompt the user with a notification that then opens our
> SUMO page in a new tab for them. 
> 
> This way, there's no anxiety around "where did this tab come from?".
> 
> Here's what I'm thinking for copy:
> 
> +--------------------------------------------+
> |                                            |
> |  +-+  Firefox is up to date                |
> |  +-+  Find out what's new in this version  |
> |                                            |
> +--------------------------------------------+
> 
> NI-ing Matej to see if he has thoughts

Copy looks good to me, though I've CC'd a few other people who may have thoughts about this as we start to work on the onboarding project this quarter.

Comment 20

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Roland, since you and Joni wrote the page for iOS, would you guys be able to do one for Android? I think that's the next action item here.

Comment 21

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Also NI-ing Joni here since she did work on bug 1240832 as well!

Joni, could we set up a google doc and a placeholder link as well? This will be for Android.

Comment 22

[Joni Chan]

Anthony, sure, we can set up a placeholder link. Should we have a separate article for each new version? Or should we just have one article that we update for each release?

Comment 23

[:Margaret Leibovic]

We could dynamically format the link to include the version number. Can SUMO support handling that to create different articles for each update?

I think it would be better to have a new URL for each update, to avoid confusion with old clients pointing to a URL that's now updated to include newer features.

Comment 24

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Margaret's suggestion ^ makes sense :)

Is that what we did for iOS as well?

Comment 25

[Joni Chan]

For iOS, we are creating a new article+link for each release. 

For Android, we can use conditional markup to show different content for each release (this doesn't work on iOS). In this case, we'd only need on URL: https://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/new-android

Or we can use brand new URLs for each article. Which release are we starting with? We can use the link above but add the version number to it (e.g. https://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/new-android-46)

Comment 26

[:Margaret Leibovic]

(In reply to Joni Savage ("need info" me) from comment #25)
> For iOS, we are creating a new article+link for each release. 
> 
> For Android, we can use conditional markup to show different content for
> each release (this doesn't work on iOS). In this case, we'd only need on
> URL: https://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/new-android

If we can avoid changing the URL in the product, we should. So I think we should go with this one.

> Or we can use brand new URLs for each article. Which release are we starting
> with? We can use the link above but add the version number to it (e.g.
> https://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/new-android-46)

Not this one.

Thanks, Joni!

Comment 27

[:Margaret Leibovic]

Mike, are you interested in picking this up? Seems like we have all the information we need to whip up a patch.

Comment 28

[:Margaret Leibovic]

Zoink!

Comment 29

[:Margaret Leibovic]

Would we want to wait for the user to launch the browser before we do this? Or should we show this as soon as the app is updated?

I started working on a patch that uses a BroadcastReceiver to listen for when the app is updated, but if we create a notification there, it will happen before the user interacts with the app.

One complicated bit about this approach is that I don't think we would automatically be able to use Switchbaord with this, since we currently initialize Switchboard in BrowserApp's onCreate method. I'll have to look into how the Switchboard config caching works... maybe this would actually work fine?

Comment 30

[Barbara Bermes [:barbara] - NI please!]

I assumed this would be a panel that links to a SUMO page inside the app, therefore it should be part of the step when the user opens the app after update.

Comment 31

[Barbara Bermes [:barbara] - NI please!]

Apologies, so system notification it is -- from an engagement perspective, I feel it's nice to do this on app update, however we need to estimate how often we would show this? Probably not on each update to not
a) annoy people
b) develop fatigue to the user

Comment 32

[:Margaret Leibovic]

(In reply to Barbara Bermes [:barbara] from comment #31)
> Apologies, so system notification it is -- from an engagement perspective, I
> feel it's nice to do this on app update, however we need to estimate how
> often we would show this? Probably not on each update to not
> a) annoy people
> b) develop fatigue to the user

I agree. I want to put this behind a switchboard flag so we can control this on a per-release basis.

I did do a test to verify I can use switchboard from within this BroadcastReceiver. It will use the cached version of the switchboard config, but as long as the user has launched the app since we changed the config, that shouldn't be a problem. Worst case, if a user hasn't used the app in a long time, they won't get a notification. Although maybe that's a case where we would actually want someone to see a notification... we can work to refine this once we get the basics in place.

Comment 33

[:Margaret Leibovic]

Attachment: MozReview Request: Bug 1004734 - Create system notification on browser update. r=liuche,mfinkle

Review commit: https://reviewboard.mozilla.org/r/36397/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/36397/

Comment 34

[:Margaret Leibovic]

Asking mfinkle to review the UI telemetry probes I put in here.

I'll work on a PR for the switchboard repo to add this experiment, although this is something we wouldn't want to turn on for Nightly, since it would appear every day.

We'll have to do some serious testing to make sure that the version number control for Switchboard actually works, so that we can control this for specific users.

I think we could land an experiment name that's turned off for all users for now. We could turn this on for a fraction of beta users once this hits beta, targeting only a specific version. We won't want this to appear on every beta update, so we would need to make sure Switchboard allows us to target very specific version numbers, e.g. 47.0b1 (the first beta).

Comment 35

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 8723189 [details]
MozReview Request: Bug 1004734 - Create system notification on browser update. r=liuche,mfinkle

https://reviewboard.mozilla.org/r/36397/#review33097

::: mobile/android/base/java/org/mozilla/gecko/Tabs.java:824
(Diff revision 1)
> +            Telemetry.sendUIEvent(TelemetryContract.Event.LOAD_URL, TelemetryContract.Method.NOTIFICATION,

What are we tracking here? I bet we already use a LOAD_URL on this code path. We don't want to double count.

We probably don't need anything here.

We probably want to add an (ACTION, NOTIFICATION, update_notification) when the user taps the notification.

::: mobile/android/base/java/org/mozilla/gecko/notifications/UpdateReceiver.java:24
(Diff revision 1)
> +    public static final String EXTRA_UPDATE_NOTIFICATION = "update_notification";

I think "update" is too general. I'd rather see all of this code use WhatsNew/whatsnew instead. That's specifically what the code does.

Update/update could mean a lot of different things.

::: mobile/android/base/java/org/mozilla/gecko/notifications/UpdateReceiver.java:62
(Diff revision 1)
> +        Telemetry.sendUIEvent(TelemetryContract.Event.SHOW, TelemetryContract.Method.NOTIFICATION, EXTRA_UPDATE_NOTIFICATION);

Looks good

Comment 36

[:Margaret Leibovic]

(In reply to Mark Finkle (:mfinkle) from comment #35)
> Comment on attachment 8723189 [details]
> MozReview Request: Bug 1004734 - Create system notification on browser
> update. r=liuche,mfinkle
> 
> https://reviewboard.mozilla.org/r/36397/#review33097
> 
> ::: mobile/android/base/java/org/mozilla/gecko/Tabs.java:824
> (Diff revision 1)
> > +            Telemetry.sendUIEvent(TelemetryContract.Event.LOAD_URL, TelemetryContract.Method.NOTIFICATION,
> 
> What are we tracking here? I bet we already use a LOAD_URL on this code
> path. We don't want to double count.
> 
> We probably don't need anything here.
> 
> We probably want to add an (ACTION, NOTIFICATION, update_notification) when
> the user taps the notification.

Okay, I can change the semantics of the probe. But this is the place we would need to do this. We can't actually listen for a tap on the notification, only for the intent that's launched when the user taps on it (which is why I added this extra here).

> :::
> mobile/android/base/java/org/mozilla/gecko/notifications/UpdateReceiver.java:
> 24
> (Diff revision 1)
> > +    public static final String EXTRA_UPDATE_NOTIFICATION = "update_notification";
> 
> I think "update" is too general. I'd rather see all of this code use
> WhatsNew/whatsnew instead. That's specifically what the code does.
> 
> Update/update could mean a lot of different things.

Okay.

Comment 37

[Barbara Bermes [:barbara] - NI please!]

(In reply to :Margaret Leibovic from comment #34)
> Asking mfinkle to review the UI telemetry probes I put in here.

- Can you please explain what your probe tries to answer?

Comment 38

[:Margaret Leibovic]

(In reply to Barbara Bermes [:barbara] from comment #37)
> (In reply to :Margaret Leibovic from comment #34)
> > Asking mfinkle to review the UI telemetry probes I put in here.
> 
> - Can you please explain what your probe tries to answer?

How often we show the notification vs. how often people click on it. Assumption being that if people click on it they're finding it useful.

Comment 39

[Barbara Bermes [:barbara] - NI please!]

Release Note Request (optional, but appreciated)
[Why is this notable]: System notification will appear after browser update to explain any notable/important changes)
[Suggested wording]: Add system notification to highlight features on browser update
[Links (documentation, blog post, etc)]:

Comment 40

[Chenxia Liu [:liuche]]

Comment on attachment 8723189 [details]
MozReview Request: Bug 1004734 - Create system notification on browser update. r=liuche,mfinkle

https://reviewboard.mozilla.org/r/36397/#review33285

r+, but we need to add a setDeleteIntent.

::: mobile/android/base/java/org/mozilla/gecko/notifications/UpdateReceiver.java:17
(Diff revision 1)
> +import org.mozilla.gecko.*;

Nit: wildcard import

Maybe a problem with IntelliJ prefs?
Preferences > Editor > Code Style > Java
In the "Imports" tab, you have to set the "Class count to use import * " to a big number.

http://stackoverflow.com/questions/3348816/intellij-never-use-wildcard-imports

::: mobile/android/base/java/org/mozilla/gecko/notifications/UpdateReceiver.java:55
(Diff revision 1)
> +                .setContentIntent(pendingIntent)

For this particular notification, we should add a setDeleteIntent with a telemetry probe so we can tell when users dismiss this notification.

http://developer.android.com/reference/android/app/Notification.Builder.html#setDeleteIntent%28android.app.PendingIntent%29

::: mobile/android/base/locales/en-US/android_strings.dtd:784
(Diff revision 1)
> +<!ENTITY update_notification_title "&brandShortName; is up to date">

Nit: maybe this string should say "...has been updated"? I'm thinking about if we download an update before the user sees this message, and there would a direct contradiction in messages in the notification bar (although that's still to an extent true of this message too).

Comment 41

[:Margaret Leibovic]

Comment on attachment 8723189 [details]
MozReview Request: Bug 1004734 - Create system notification on browser update. r=liuche,mfinkle

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/36397/diff/1-2/

Comment 42

[:Margaret Leibovic]

PR for switchboard-experiments change: https://github.com/mozilla-services/switchboard-experiments/pull/14

Comment 43

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 8723189 [details]
MozReview Request: Bug 1004734 - Create system notification on browser update. r=liuche,mfinkle

https://reviewboard.mozilla.org/r/36397/#review33887

::: mobile/android/base/java/org/mozilla/gecko/Tabs.java:824
(Diff revision 2)
> +            Telemetry.sendUIEvent(TelemetryContract.Event.ACTION, TelemetryContract.Method.NOTIFICATION,

I'd like to eventually centralize the code that opens URLs in Fennec from Notifications. I think we'll end up with more and more, as part of our engagement efforts.

This is OK for now.

Comment 44

[:Margaret Leibovic]

https://hg.mozilla.org/integration/fx-team/rev/2d09899861de02972eb86f542841214148e71241
Bug 1004734 - Create system notification on browser update. r=liuche,mfinkle

Comment 45

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/2d09899861de

Comment 46

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Added to Fx47 (Aurora) release notes.

Comment 47

[u549602]

Hi Margaret, 

Can this feature be activated from the Switchboard experiment in order to test it on Aurora?

Comment 48

[:Margaret Leibovic]

(In reply to Mihai Ninu {:Ninu} from comment #47)
> Hi Margaret, 
> 
> Can this feature be activated from the Switchboard experiment in order to
> test it on Aurora?

Theoretically, yes. However, this notification would be displayed every time the APK is updated, which is every day on Aurora, so we would only want to do this very briefly.

We would also need to write a SUMO article to explain what's new in Firefox 47, which I assume we don't have yet.

However, maybe we should turn this on for a day for Aurora users to see what happens.

Barbara, what do you think of that idea? Joni, have you started an article about what's new in Firefox 47?

Comment 49

[Joni Chan]

Margaret, we have a page for version 46 now, but not 47 (not yet anyway). When will we need the page?

Is this going to be turned on for 46?

Comment 50

[:Margaret Leibovic]

(In reply to Joni Savage ("need info" me) from comment #49)
> Margaret, we have a page for version 46 now, but not 47 (not yet anyway).
> When will we need the page?
> 
> Is this going to be turned on for 46?

This notification feature is only available in 46, not 47.

Maybe we can put together a draft version of the page for 47 to use for Aurora testing (those users should be okay with rough edges). Otherwise, we should definitely get a page together when 47 hits beta so that we can test this out in beta.

Comment 51

[Barbara Bermes [:barbara] - NI please!]

(In reply to :Margaret Leibovic from comment #48)
> (In reply to Mihai Ninu {:Ninu} from comment #47)
> > Hi Margaret, 
> > 
> > Can this feature be activated from the Switchboard experiment in order to
> > test it on Aurora?
> 
> Theoretically, yes. However, this notification would be displayed every time
> the APK is updated, which is every day on Aurora, so we would only want to
> do this very briefly.
> 
> We would also need to write a SUMO article to explain what's new in Firefox
> 47, which I assume we don't have yet.
> 
> However, maybe we should turn this on for a day for Aurora users to see what
> happens.
> 
> Barbara, what do you think of that idea? Joni, have you started an article
> about what's new in Firefox 47?

Sounds good to me.

Comment 52

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

So is it possible to test the notification on Aurora before it hits Beta? I am worried about in cropped strings in the German translation.

Comment 53

[:Margaret Leibovic]

(In reply to Sebastian H. [:aryx][:archaeopteryx] from comment #52)
> So is it possible to test the notification on Aurora before it hits Beta? I
> am worried about in cropped strings in the German translation.

Sorry for the slow response. Unfortunately, the only way to really test this yourself is to launch Fennec with a different switchboard server that has the experiment enabled. You can do this by launching Fennec from the command line with an intent extra:
https://github.com/mozilla-services/switchboard-experiments#making-config-changes

Or you could make your own build and edit WhatsNewReceiver.java.

Maybe we should try extending Sebastian's switchboard-experiments add-on [1] to actually change the state of experiments, but that would require doing some hacky hacks with JNI (and I'm not sure if that's even possible without some client changes).

We should have a better story for manually turning on/off different experiments for testing.

[1] https://addons.mozilla.org/en-US/android/addon/switchboard-experiments/

Comment 54

[:Margaret Leibovic]

Once bug 1270929 lands, you can use the new "about:experiments" page in the the switchboard-experiments add-on to test this.