Revise Login Architecture & UX

[thisandagain]

After reviewing the performance of Login v3 for a few months, we've observed a few issues specific to user experience (conversion rate) and developer ergonomics. In order to more easily resolve both, this sprint is to address some of the issues with the architecture, developer ergonomics, and user experience of login.

User Experience Issues

• Poor sign-up conversion rate within form itself
• Minor measurable improvement over persona conversion
• Email-based (mobile concern)
• Email directs users back to desktop (mobile concern)
• "Password-less" causes a number of UX edge cases that we don't have good benchmarks for how to solve and is slow / frustrating

Information Requirements

• Username (encourage NOT real names)
• Password
• Email OR Mobile Phone
• TOS accept
• Marketing opt-in

Architecture Requirements

• Token-based
  • Persisting login tokens should be left to the client (cookies for desktop, encrypted device storage for mobile, etc)
• Separation of concerns
  • Decouple session handling from the UI
  • Decouple mobile (Webmaker App) and desktop (Webmaker.org) UIs
• Duplication
  • Consolidate the angular and vanilla js versions of Login to a single non-framework (vanilla) dependent module
• l10n
  • Improve / fix localization support (Not picking up locale setting on goggles mozilla/webmaker-login-ux#161)
• Test coverage
  • Improve / implement test coverage as to increase reliability & confidence when shipping changes to login
• Instrumentation
  • Add additional Google Analytics goals / funnel as to measure where in the Login process we are loosing users. (Add virtual pageview tracking to login-ux so we know which screens people are seeing mozilla/webmaker-login-ux#166)

Milestone

https://github.com/mozilla/webmaker.org/milestones/Login
https://github.com/mozilla/id.webmaker.org/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Teach+Implementation%22

RACI

Phase: Build / Ship
Owner: @secretrobotron
Decision: @davidascher
Lead design: @cassiemc
Lead dev: @jbuck
Dev: @Pomax
Dev: @cadecairos
Quality: @simonwex
Metrics: @adamlofting

[secretrobotron]

Found a few bugs in different places recently. Starting to compile a list here.

UI

• Style isolation woes: Style conflict for login modal on goggles mozilla/webmaker-login-ux#162
• Locale woes: Not picking up locale setting on goggles mozilla/webmaker-login-ux#161

Server

• Not working on staging sometimes: Can't login to webmaker account through goggles mozilla/login.webmaker.org#314
• Probably related back-end woes: Goggles fails to publish mozilla/goggles.mozilla.org#151

[thisandagain]

@jbuck @simonwex @cadecairos @secretrobotron Feel free to add notes here, my list above is by no means exhaustive.

[thisandagain]

@adamlofting See last item (instrumentation) above.

[cadecairos]

Consolidate the angular and vanilla js versions of Login

@thisandagain Can you explain more about this item? The adapters were built with de-duplication in mind.

[thisandagain]

Ah! Good to know... I think I might not quite understand the architecture as well as I thought. @simonwex and @jbuck had some thoughts on this as well, but the general idea was to deprecate the angular adapter and consolidate to a single execution that could be used across platforms / properties. The thinking behind this was that having two different instances (particularly as that instance is implementing UI) was causing ergonomics and QA issues because both required maintenance / updating.

[cadecairos]

deprecate the angular adapter and consolidate to a single execution that could be used across platforms / properties

👍

[secretrobotron]

Suggested re-scope for pre-MWC:

• l10n (should be fully translated already; status check!)
• bugs: https://github.com/mozilla/webmaker-login-ux/issues
• analytics (document or improve which events to listen to)

@thisandagain @simonwex considering that we're pulling out auth from webmaker-app for MWC, above list look ok for this sprint?

@jbuck will write up another bug to address post-MWC login plans

[thisandagain]

Milestone has been created in the mozilla/webmaker.org repo: https://github.com/mozilla/webmaker.org/milestones/Login

[davidascher]

Note: Using something like BriteVerify would require (likely significant) vendor review before trial, and we'd probably want to look at the larger scope of email verification in the context of mailing list systems (not that they need to use the same system, but there are two use cases with similar challenges).

[simonwex]

@davidascher do you know if there has been any similar work done by Moz teams to do part of what BriteVerify does? Thunderbird auto-configuration comes to mind.

[simonwex]

Status update:

• Rescheduled meeting for 10:00am EDT in my Vidyo room
• @jbuck to start work on Login - Produce logic diagrams to document migration & error states mozilla/webmaker.org#1367 today

[davidascher]

I doubt we have alternatives to this particular service, as it requires effectively tracking email delivery. There may be alternatives that we are using as part of some of the email campaigns that @valianttry has been doing.

[adamlofting]

Just to note @valianttry is on PTO. Though I'm pretty sure we don't have anything like this for our BSD mailing lists right now.

[davidascher]

Yet another reason to work through vendor review with whoever is best in class for bounce management.

[thisandagain]

Still wrapping up design, but otherwise good progress here. Moving remaining work (implementation) to next heartbeat.

/cc @cassiemc @simonwex

[thisandagain]

@secretrobotron For the kickoff meeting let's include @hannahkane @HPaulJohnson and @simonwex so we can confirm alignment w/ the teach site and getting vendor selection / review rolling.

[secretrobotron]

Summary for easy reading:

• Design/IA is basically done (thanks to @thisandagain and @cassiemc)
• Implementation bugs in milestone: https://github.com/mozilla/webmaker.org/milestones/Login
• Teach site is first client of new login (Build sign-up flow mozilla/learning.mozilla.org#46)
• @jbuck working on logic diagram: Login - Produce logic diagrams to document migration & error states mozilla/webmaker.org#1367
• Need a dev (team?) to work on this: @jbuck and @Pomax
• Needs to coincide with (and use) Improve email communication(s) after sign-up #242
  • Should this really be rolled into this ticket? (not impl, just vendor review)
  • Content mgmt, AB testing, metrics, different emails per domain
  • Need to make sure emails don't say "Webmaker" because should be generic between Tech/Webmaker @adamlofting? Different user journeys. (Need to chat to @thisandagain about this.)
• @adamlofting has a metrics checklist for new projects/repos

[adamlofting]

Architecture question which impacts analytics (and UX):

• When a user is viewing the login page, what URL (domain) are they on?

This is a consideration for how we track login for user on *.webmaker.org vs a user on teach.mozilla.org (GA account IDs change and so on).

[thisandagain]

Follow-up note from our 1:1 – Given that we have some content that needs to vary here as well (value proposition & logo) we may want to consider having one service that listens on two domains or URLs. That would make distinguishing between referring links easier as well as possibly resolve some of the branding issues (teach.mozilla.org users being redirected to login.webmaker.org for example). Thoughts @secretrobotron @simonwex ?

[secretrobotron]

Notes from hangin' out with @hannahkane, @jbuck, @thisandagain, @Pomax & @cassiemc

• Doesn't need to be unified with webmaker accounts (2 separate user tables)
• Can sign in via webmaker OAuth to teach.mozilla.org
• Need to design OAuth dialog right meow 🐱
• Pay attention to conversion wrt OAuth flow
• Can send out two signup emails: one for webmaker, one for teach.mozilla.org
  • Or, just change the email that goes out
• Need to track who's logging in through teach.mozilla.org (and other properties)
• Need to welcome people to teach.mozilla.org post signup

Deliverables:

• OAuth UX/UI design ( @cassiemc )
• Login button (to use on the teach.mozilla.org site which calls up the OAuth dialog) ( @cassiemc )
• Need to adjust email depending on referral ( @jbuck or @Pomax )
• Put login button in teach.mozilla.org ( @Pomax or @toolness )
• Flow diagram about how all of this works ( @jbuck and @secretrobotron )

[simonwex]

It's worth mentioning that we should add the teach.mozilla.org site to a whitelist. This means the user won't be prompted with a decision as is often the case in typical (and problematic) OAuth flow.

@adamlofting do we have a preferred method for measuring user-perceived response-time for the login steps? By choosing the redirect approach, I think this will be a very important factor wrt conversion rate.

[adamlofting]

We don't have a preferred method for perceived-load time, but I'd encourage a dev iteration to work specifically on this issue if we can afford it. Our own perception as users, along with some browser-rendering-time data should make a good dent on this.

Slightly slower loading time can lose a percent or three of the conversion rate, so it's important, but it's a lesser impact than UX, messaging and brand. Really slow response times are more problematic, but our standard of dev work is high by default, so I don't have that as a concern 👍

Over time, I'd love to see this response-time 'polishing' as a dev step in all the interactions we're building.

[cassiemc]

@secretrobotron I don't think the milestone listed above (https://github.com/mozilla/webmaker.org/milestones/Login) is showing all open issues here -- they seem to just be design tickets. @alicoding and I were discussing this morning and would like to break the design tickets into more issues so that it's clearer what is finalized and what is still WIP. I can do that, but not sure if this is the right milestone. Can you direct me to the right repo / milestone, please?

[secretrobotron]

Yeah, my bad. I assigned a couple to you and marked them with design. Here's the milestone though: https://github.com/mozilla/id.webmaker.org/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Teach+Implementation%22

[cassiemc]

Great, thanks @secretrobotron! I updated the ticket overview in the first comment with this link and am going to move design tickets over there / break them down more.

[secretrobotron]

Spoke with @thisandagain and @hannahkane today about what we'll ship this week.

• Going to push for getting all implementation done for teach
• Next heartbeat will have a followup for QA, testing, and shipping
  • @hannahkane and I will coordinate QA efforts and the beginning of next hearbeat
• Will review this on Friday as well

[thisandagain]

Tracking next steps specific to the teach.mozilla.org implementation in #404