Closed Bug 1567405 Opened 5 years ago Closed 5 years ago

Create FxA Toolbar landing page for Firefox Monitor

Categories

(Firefox :: Firefox Accounts, enhancement, P1)

Product:
Firefox
Component:
Firefox Accounts
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: rfkelly, Assigned: groovecoder)

References

Details

(Whiteboard: [fxa] [skyline])

In Bug 1562006, we will be adding a item to the Firefox Account Toolbar menu to help users discover Firefox Monitor. The full UI spec is in Invision here, but the relevant parts for integrating with Monitor are:

  • If the user is not signed in to Firefox, they will see a little description of the Monitor Send service and a button saying "Launch Monitor".
  • If the user is signed in to Firefox, they will see a little description of the Monitor service and a button saying "Continue as user@example.com".

These buttons will open the Firefox Monitor site in a new tab, and this bug is about figuring out the details of exactly how it will be opened. We need to:

  1. Agree on the precise URL that will be opened by the "Launch Send" button, including any metrics or other tracking parameters.
  2. Agree on the precise URL that will be opened by the "Continue as user@example.com" button, including how to pass in the intended identity, and any metrics or other tracking parameters.
  3. Optionally, design and build a customize experience to help users through this flow more smoothly.

We should probably make sure the things we do here, are consistent with the "Sign up for Firefox Monitor" branding that's being added to the protection report in Bug 1559422 and friends, so adding :mtigley for context.

About the simplest thing we could do here in the Skyline timeframe is:

This would give the user the default Monitor experience when they're not signed in, and would send them straight into the FxA signin flow for Monitor if they are signed in.

In Bug 1562006 Comment 8, :rfeeley suggests that we probably shouldn't send the user straight to the FxA login experience, and should instead either show them an introductory splash screen, or silently sign them in and let them start using the product. Doing either of those will require work on the Monitor side.

:groovecoder, thoughts? Does this match what we intend to do for the protection report CTA?

Flags: needinfo?(lcrouch)

For (2), load ""https://monitor.firefox.com/oauth/init?email=user@example.com&entrypoint=fxa_discoverability_native&utm_source=..."

I wonder if it's worth our while to add a separate endpoint for linking out from the browser, even it doesn't do anything special in the first instance, just to buy ourselves a bit of optionality for making future changes to the landing page.

See Also: → 1567477

(In reply to Ryan Kelly [:rfkelly] from comment #0)

  • If the user is signed in to Firefox, they will see a little description of the Monitor service and a button saying "Continue as user@example.com".

Is there some kind of workflow where if the user is signed in to Firefox, but is not subscribed to Monitor?

Is there some kind of workflow where if the user is signed in to Firefox, but is not subscribed to Monitor?

For the toolbar, no - we just link them out to the monitor website, where they can opt in to the Monitor service if they aren't already.

Cc'ing Ryan, Betsy, and Lesley on this bug for the Monitor side of the UX. When I get back next week I can help with the implementation.

Following up on Comment 1, I'd like to propose a special "onboarding" page that the browser can load via something like:

This page would take responsibility for giving the user a good experience of handing off from the browser's builtin UI to the website, by doing things like:

  • Checking whether a user is already signed in to monitor.firefox.com in this browser.
    • If yes, and it's the same user identified in the email parameter, then just go to the main monitor page.
    • If no, or if yes but it's a different user than specified in the email parameter, then continue as follows...
  • Maybe show some sort of splash screen to explain the Monitor value-prop before the user commits to using the service?
  • Direct the user to the FxA OAuth flow, passing through the various query parameter, and handling signin as usual.

This would make a nice clean handoff between the browser and the monitor service (just open a new tab with a well-defined URL) and would give the service a bit of optionality about how to best onboard the user without landing followup changes in Firefox.

Flags: needinfo?(lcrouch)
Whiteboard: [fxa]

re-ni'ing lcrouch for help implementing (comment 5). Should this be assigned to you? (also, should it go to a Monitor component in Bugzilla?)

Flags: needinfo?(lcrouch)

I think this should be assigned to :betsymi and/or rgaddis first.

If I understand correctly, none of this would ship inside -central code-base, so we don't have to implement this by the Aug 9 -central merge-freeze date for Skyline?

Flags: needinfo?(lcrouch) → needinfo?(rfkelly)

If I understand correctly, none of this would ship inside -central code-base, so we don't have to implement this by the Aug 9
-central merge-freeze date for Skyline?

For decoupling timelines, I propose that we do the following ahead of Skyline freeze date:

  1. Agree on a URL that the browser will load (my strawman is in Comment 6, but :groovecoder should be the keeper of that bikeshed)
  2. Implement that URL on monitor as a simple redirect to e.g. /oauth/init, with no new UX
  3. Land code in the browser to load said URL when activating Monitor

We can then figure out an improved UX for the landing page at a more leisurely pace. :groovecoder what do you think?

Flags: needinfo?(rfkelly) → needinfo?(lcrouch)
Whiteboard: [fxa] → [fxa] [skyline]

Comment 9 sounds like a good plan from my POV. @groovecoder can you help get this bug assigned?

I'm marking this as a P1 for skyline, so it's going to get attention from triage/review boards.

Priority: -- → P1

(In reply to Ryan Kelly [:rfkelly] from comment #9)

For decoupling timelines, I propose that we do the following ahead of Skyline freeze date:

  1. Agree on a URL that the browser will load (my strawman is in Comment 6, but :groovecoder should be the keeper of that bikeshed)
  2. Implement that URL on monitor as a simple redirect to e.g. /oauth/init, with no new UX
  3. Land code in the browser to load said URL when activating Monitor

We can then figure out an improved UX for the landing page at a more leisurely pace. :groovecoder what do you think?

https://monitor.firefox.com/fxa-onboarding?... sounds good to me - any URL works from a technical standpoint. I'm not sure if :betsymi, rgaddis, and/or ssage want input on the URL?

We could even put the "FXA_TOOLBAR_MONITOR_URL" in a pref. Start it as https://monitor.firefox.com/fxa-onboarding?... but then if that URL ever wants to change we could change it with a pref-flip instead of hard-coded.

Flags: needinfo?(ssage)
Flags: needinfo?(rgaddis)
Flags: needinfo?(lcrouch)
Flags: needinfo?(bmikel)

We could even put the "FXA_TOOLBAR_MONITOR_URL" in a pref.

This was recently landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1562006 and is in Nightly. Currently, the pref is called identity.fxaccounts.service.monitorLoginUrl and is set to https://monitor.firefox.com/.

This is going to come up in triage today as an unassigned P1. Who should be the assignee here? Thanks

You can assign this to me or to :lnorton but it's blocked on input from ssage, :betsymi, and/or rgaddis.

Assignee: nobody → lcrouch
See Also: → 1573165

:clouserw - we'd like to keep the link going to https://monitor.firefox.com/ but can we add utm_ params so we can see how many visitors are getting to the website from this FxA toolbar link?

:lnorton - do you know what/which utm params we should use?

Flags: needinfo?(ssage)
Flags: needinfo?(rgaddis)
Flags: needinfo?(lnorton)
Flags: needinfo?(bmikel)

:clouserw Might be good to add utm_medium=fxaToolBar so it's easier for us to distinguish traffic coming from the toolbar from other sources of traffic that also use utm_source=firefox. AFAIK Analytics will not pick up the entrypoint value but I could be totally wrong about that.

Flags: needinfo?(lnorton)

utm_source is changing in https://bugzilla.mozilla.org/show_bug.cgi?id=1573959

Based on comment 15, I think this bug can be closed

Based on no comments on my last comment which is based on comment 15, I'm closing this.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.