task decision from bug 1216271. The intention is to inform the user that "allow notifications" permission have changed and that the user can click on notification and review those settings as well as click on a learn more link for more information. * clicking on notification results in opening a new tab with about:preferences#content with the management UI displaying. * origin and gear will not display * Title and body copy to be finalized in this bug

Bill and Philipp to finalize notification strings.

correction: * clicking on notification results in opening a standalone window with notification management UI

this is a UX bug - mattn is going to file implementation bugs

We just discuss this and there is some scope we can cut. - If a user has allowed notifications for at least one site, show a desktop notification on first run after update. - The notification says: -- Title: Notifications have been upgraded -- Body: You will now be able to receive notifications from your favorite sites, even when they are not opened in a tab. Click to learn more. - Clicking the notification leads to the learn more page that instructs the user how notification prefs can be changed in settings. - The permissions are automatically updated to the new model (users are informed of that change through the desktop notification) That way we provide the information some users want while not overwhelming others by throwing them inside a management UI right away. It should also reduce engineering complexity.

This is the UX/string bug and bug 1216271 is the implementation one that Kit will take. It seems like the strings are mostly sorted out though one problem is that the string is too long for OS X's initial view. See http://grab.by/Lvd8 vs. http://grab.by/Lvda Are we fine with this truncation on OS X? The only alternative is a shorter string. I think we also need a mobile version of bug 1216271 since we don't have a good place to handle migrations in toolkit and I'm not sure if we can easily add one for this.

Yeah, I think that's fine. Since this is the UX/string bug, it should be resolved with the information provided in comment 4 and here.

Original String: "You will now be able to receive notifications from your favorite sites, even when they are not opened in a tab. Click to learn more." The important part of the string is: "even when they are not opened in a tab" Right now on OSX you see: "You will now be able to receive notifications from your favorite sites, even when they are not ope" All this tells me is that my favorite sites will keep sending me notifications. Can we shorten the string for OSX or change the order of the words: "You will now receive notifications from sites, even when they are not opened in a tab. Click to learn more."

Reopening to try and get a shorter string that doesn't truncate as badly on OSX. Also adding Matej to see if he has ideas.

If you want to test other strings, you can run code in the Browser Console to test: new Notification("Notifications have been upgraded", { body: "You will now be able to receive notifications from your favorite sites, even when they are not opened in a tab. Click to learn more."} ) Make sure the pref devtools.chrome.enabled is true before opening the Browser Console.

Here are two slightly shorter options. In either case, I don't think we need "Click to:" "You will receive notifications from sites, even those not open in a tab. Learn more." "Sites will be able to send notifications, even when not open in a tab. Learn more."

Maybe better wording: "You will now receive notifications from sites, even if not open in a tab. Learn More."

This notification pops up on browser upgrade. If there is no interaction in the 10-12 s it is visible, can we repop it the next three times they start the browser? That might be a good compromise.

rather than pop multiple times, i logged to persist the notification for Firefox/Mozilla notifications if desired: bug 1218979

Comment 11 string works for me...Please comment if this works as a shorter version. The implementation has to still be done, probably uplifted to Aurora.

Bikeshedding: how about "You can now receive notifications from sites that aren't open in a tab. Learn more..." ISTM "click to learn more" is a clearer call to action, too, but maybe a period or ellipsis is sufficient.

my 2 cents: I like - "You will receive notifications from sites, even those not open in a tab. Learn more." Adding 'now' feels alarming and not sure if the distinction needs to be called out.

Let's use this: You will receive notifications from sites, even those not open in a tab. Click to learn more. Still fits on OS X. I feel pretty strongly about the »Click to« because we can't have a link affordance in the notification. The other option would be to remove the call to action entirely as Matej suggested and just have it be: »You will receive notifications from sites, even those not open in a tab.«

(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #17) > Let's use this: You will receive notifications from sites, even those not > open in a tab. Click to learn more. Sounds good to me!

Fine by me too, since it fits. So we have: Title: Notifications have been upgraded Body: You will receive notifications from sites, even those not open in a tab. Click to learn more.

Looks like the title is truncated on OS X 10.9. Is that OK, or should we shorten it?

(In reply to Kit Cambridge [:kitcambridge] from comment #20) > Created attachment 8680314 [details] > Screen Shot 2015-10-28 at 3.59.17 PM.png > > Looks like the title is truncated on OS X 10.9. Is that OK, or should we > shorten it? WE should make it fit.. I thought this one was short enough on 10.10, but I guess not.... Notifications Upgraded?

It is short enough for 10.10, not 10.9.

it is a free upgrade and we know mac users upgrade pretty quickly

The wording on the notification itself has been criticized as being a little alarming or ominous. Here are three possibilities for how to improve the text copy. We've improved Notifications! Learn More. (short and readable) We've improved Notifications from sites to work even when you're not on the tab. Learn More. We've improved Notifications to help you better manage your sites! Learn More.

(In reply to Bill Maggs (bmaggs) from comment #24) > The wording on the notification itself has been criticized as being a little > alarming or ominous. Here are three possibilities for how to improve the > text copy. > > > > We've improved Notifications! Learn More. (short and readable) > > We've improved Notifications to help you better manage your sites! Learn > More. The reason for the one time prompt is to let users know what we are giving a site more permission than we did before, which neither of these indicate. The purpose of the prompt is not to evangelize and promote the push feature. > We've improved Notifications from sites to work even when you're not on the > tab. Learn More. > This is closer but "you're not on the tab" could just mean the pre-Firefox 44 experience where you are on one tab and get a notification for another site open in a separate tab that you are not viewing. This is a one time prompt that is supposed to attract attention to users who care. Hence I don't think it is overly alarming. If we are worried about this prompt causing a degraded upgrade experience, we could revisit the reprompting per site option.

Hi Tanvi - totally understand that we don't just want this to be a "new and improved" message without substance about the permissions changed. Right now, the language around "You WILL receive notifications..." seems more alarming than is maybe required. What about: Upgraded Notifications You can now receive notifications from sites that are not currently loaded.

The other thing that adds to a sense of alarm is the icon: a speech bubble with an exclamation point feels a lot like a WARNING. We could use a speech bubble without an exclamation mark?

Prod and UX agree on: Title: Upgraded Notifications Body: You can now receive notifications from sites that are not currently loaded. Click to learn more. we'll log a new bug for the icon.

Since this is a UX bug we can request the icon here. Bryan, can you please provide the notification icon without the exclamation mark?

I'm implementing comment 28 in bug 1220884

let's close this as the icon change has been logged here: bug 1221330