Closed thisandagain closed 9 years ago
Found a few bugs in different places recently. Starting to compile a list here.
@jbuck @simonwex @cadecairos @secretrobotron Feel free to add notes here, my list above is by no means exhaustive.
@adamlofting See last item (instrumentation) above.
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.
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.
deprecate the angular adapter and consolidate to a single execution that could be used across platforms / properties
:+1:
Suggested re-scope for pre-MWC:
@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
Yup! :+1:
@thisandagain @secretrobotron thanks. I've just filed a spec for the additional event tracking I think we need. Hopefully that ticked gives enough detail for whichever dev works on this to run with it.
@secretrobotron status?
No progress on this last heartbeat. Moving to backlog.
Bringing to the March 13th milestone as per discussions with @simonwex and @davidascher . One requirement not covered here is what's needed from @hannahkane 's POV. Will set-up a kickoff meeting to clarifiy scope.
@thisandagain dev: TBD x 3 (2 BE + 1 FE)
seems a bit excessive for this HB if this is a re-design effort. I added the "needs-discussion" label :arrow_up:, let's chat during TPS?
Can we also add reduce package weight to list of requirements? Right now it's ~255kb
@k88hudson I'd suggest that's part of the implementation in the next HB. @thisandagain is there a ticket created for that we can add k8's suggestion to?
@simonwex I'll get that together today. Thanks for the suggestion @k88hudson :+1:
Confirming the design assignments. @thisandagain is going to work on initial IA & Architecture this week, then I will step in next week for UI, supported by @vazquez depending on how the teach stuff plays out this week.
Kickoff meeting scheduled for 10am PST tomorrow.
Scope (above) has been updated from the kickoff. Here are a few additional notes:
I've started to collect reference user flows for both desktop and mobile (see above list) here: https://drive.google.com/open?id=0B-1AZgKn5Nc7Vk1tTUlLaWczV0U&authuser=0
Milestone has been created in the mozilla/webmaker.org repo: https://github.com/mozilla/webmaker.org/milestones/Login
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).
@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.
Status update:
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.
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.
Yet another reason to work through vendor review with whoever is best in class for bounce management.
Still wrapping up design, but otherwise good progress here. Moving remaining work (implementation) to next heartbeat.
/cc @cassiemc @simonwex
@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.
Summary for easy reading:
Architecture question which impacts analytics (and UX):
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).
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 ?
Notes from hangin' out with @hannahkane, @jbuck, @thisandagain, @Pomax & @cassiemc
Deliverables:
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.
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 :+1:
Over time, I'd love to see this response-time 'polishing' as a dev step in all the interactions we're building.
@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?
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
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.
Spoke with @thisandagain and @hannahkane today about what we'll ship this week.
Tracking next steps specific to the teach.mozilla.org implementation in #404
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
Information Requirements
Architecture Requirements
angular
andvanilla js
versions of Login to a single non-framework (vanilla) dependent moduleMilestone
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