1930250 - Finish up the new app menu messaging surface to prepare it for general use

Status: RESOLVED FIXED

(Firefox :: Messaging System, enhancement, P1)

Description

[[e-mail]]

The Account Adoption Account Menu Experiment involved displaying a message at the top of the App Menu and the PXI Panel when a user is signed out, encouraging sign-in using various value props. This message has title, subtitle, image, a CTA button, and an X button to close the message.

In the case of of the account adoption experiment, this message was also linked to the first menu option in each of the two menus, which also presents an option to sign in. Basically the large message replaces the smaller message, and the smaller message is restored when the larger message is dismissed. To make this reusable, we need to get rid of this link. The reusable message surface should just display a dismissable message at the top of the App Menu or PXI Panel, without hiding any existing options. It would also be acceptable to limit the messaging surface just to the App Menu. On the other hand, extending it to support ANY menu could also be useful.

More technical detail can be provided by @Mike Conley as needed. He roughly estimated a few days of work for himself, so perhaps this stretches to a week of work for someone coming in cold.

@Tina Rattliff and @Brad Landthornare interested in this now for Firefox Newsletter promotion. I don’t have a backlog of known additional casesbut I think Firefox is in need of a messaging surface that can be easily revisited, i.e. one that doesn’t require immediate action or else is forgotten. This is an example of such a surface. You see the message in your app menu, and while you can close it you don’t need to or even particularly want to, because it’s out of the way and yet easy to get back to. If the messaging surface were itself an experiment, I would hypothesize solid success rates for it because of this.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

There should already be an internal request for this work; this needs to be broken down and prioritized as part of that.

Comment 2

[Ray Fambro]

Although we have not yet started building a backlog of message proposals for this surface, we hypothesize that it will be a very useful addition to our message surface library as a way to communicate to users w/o requiring a user trigger. That said, we'll start to plan experiments with this surface in mind. Let's plan to pick this scope up once we build out this backlog.

Comment 3

[Tina Rattliff]

We’re excited to have the Firefox Newsletter opt-in use case be included here. Is there by chance a rough estimate (Jan, Feb, etc.) for when this would likely come into scope?

Comment 4

[Ray Fambro]

Hey Tina! Wanted to jump in and add my 2 cents here as I'm inheriting this area from David. We are now analyzing the experiment that we ran for this new surface and want to ensure that the UI doesn't need any changes first before we establish this as a formal surface. Hoping to land on a path soon. Once we are aligned to the design and the appropriate message use cases for the surface, then we will follow up.

Comment 5

[Tina Rattliff]

Hi Ray, I appreciate the update on this new messaging surface.

• Tina

Comment 6

[Ray Fambro]

David -- I have a few questions about this before taking it forward. What was our rationale for not decoupling the app menu and the PXI panel so that 2 different messages could be shown simultaneously? These feel like 2 separate use cases to me (i.e. a user going to the PXI panel is specifically looking for Accounts information vs a user going to the app menu encompasses many different needs).

Comment 7

[[e-mail]]

(In reply to Ray Fambro from comment #6)

David -- I have a few questions about this before taking it forward. What was our rationale for not decoupling the app menu and the PXI panel so that 2 different messages could be shown simultaneously? These feel like 2 separate use cases to me (i.e. a user going to the PXI panel is specifically looking for Accounts information vs a user going to the app menu encompasses many different needs).

In the original case we didn't decouple the messaging because it was a single experiment about account adoption and we just wanted to show the same message in both places. But for any other kind of message, decoupling is absolutely needed. They are two separate use cases. My description of the bug above calls for decoupling... at least it intends to! If I worded it to obtusely, I apologize. :-)

Comment 8

[Ray Fambro]

Ah thank you! I hadn't gone back to reread this. Appreciate the flag.

Comment 9

[Ray Fambro]

I'd like to propose an updated priority for this one (P1) if possible. My ask is that we update the style variant for this message surface (new design is in the Jira file). My assumption is that this change will need to ride the trains. Once ready, we'll set up a final experiment to test (likely in Nightly or Beta to expedite).

Comment 10

[Ray Fambro]

Adding Figma link for reference: https://www.figma.com/design/qe9yX8x51jjbt6DJYgayg2/Device-Migration-(Account-and-Multi-Device-Adoption)?node-id=8405-4755&t=Fu4gQfTFlEv02Mo1-4

Comment 11

[Mimi Jung]

Attachment: Bug 1930250 - Adds AppMenu configuration and styling for 'row' layout

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/96115fb7e09f
Adds AppMenu configuration and styling for 'row' layout r=omc-reviewers,mconley,emcminn

Comment 13

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/96115fb7e09f