<div dir="ltr"><div><div><div>Monday's Web Coordination meeting was split into two parts, a UX/PM half where we discussed the issues most important to Ryan Feeley and Alex Davis, the 2nd half Ops/General dev.<br><br></div>Highlights from the two halves:<br><br></div><b>UX/PM<br></b><ul><li>A lot of time was spent discussing the finishing touches of "Connect another device phase 1".</li><ul><li>Ryan Feeley suggested UX updates to the mobile App Store link area. These changes were initially applied everywhere, but we decided to sandbox these changes to users who are part of the "treatment" group of our A/B test to ensure the visual changes do not alter the behavior or our "control" group.</li><li>The designs call for a link to "Why is this required?" (text to be finalized) that opens a SUMO page that explains why Sync works best with two or more devices. We need to get this SUMO page written. stomlinson to coordinate with rfeeley and the SUMO writers to get this done.</li><li>There is a lot of discussion on how to get A/B test decision data to our backend so that we can easily bucket users in re:dash based on which experiment group they are in. We have this data in DataDog, but not re:dash. To complicate matters, we only send "flowid's" to re:dash, not "user ids". A flow-id is a unique ID that is generated, once per signin or signup. It is never stored with a user-id on our backend, with the aim of helping to secure our user's privacy and remove the ability for us to to track individual users across devices. We could attempt to propagate a flow-id across devices so that it becomes a bit more user-id like, but we don't really like this for a couple of reasons (privacy & a change in the meaning of a flow-id which will probably have negative effects on our graphs).<br></li></ul><li>The Growth team is running an A/B test on the firstrun page to see how sending users to `/signin` instead `/signup` affects related metrics. See [1] for the details.</li><li>The unblock flow is busted if the user attempts to sign in with an email address in a different case to the one they signed up with [2]. Fix being reviewed in [3]. <br></li><ul><li>Alex asks "Is there a way we can allow the user to give feedback when they are sure they've entered in the correct code but are still unable to sign in?"</li></ul><li>There is a bug in Fx 50-53 where users are unable to log in to FxA if "Never Remember History" is set. <br></li><ul><li>Should be fixed in 50.1 [4]</li><li>We do not know currently how many users this affects.</li></ul><li>Our signup verification emails are being flagged as spam by Outlook/Hotmail. [5]</li><ul><li>We'll need some Ops support to track down why.<br></li></ul></ul></div><b>General Dev<br></b><ul><li>train-75 strings have been cut.</li><ul><li>The newest grunt-jsx-gettext is not reading .js files, we need to figure out why!</li></ul><li>train-75 itself was cut too. Train-75.1 will probably be cut today for the "incorrect email case" bugs.<br></li><li>train-74 went out the door!</li><li>More incorrect email case - it causes problems with the change password flow too! [6]</li><ul><li>Proposed fix [7].</li></ul><li>Phil has noticed some duplicate flow events being reported. We made a mistake in how we clear the event queue on flush so duplicate events can be sent. [8]</li><li>Each server repo has an `npm run shrinkwrap` command that Does The Right Thing (TM) thanks to Sai! Now we can stop remembering the incantation for each particular repo and move on to more important things. Thank you Sai!</li><li>Email has been very slow to arrive at restmail over the past few weeks, that or restmail is acting up. We aren't sure which, but it's affect our functional tests. Nobody on our team knows how to access it to see whats up. Anybody? Am I going to have to hit up Jed?</li></ul><p>Shane<br></p><br>[1] - <a href="https://mana.mozilla.org/wiki/display/FIREFOX/%5Bbug+1317790%5D+Fxa+Sign+in+vs+Sign+Up" target="_blank">https://mana.mozilla.org/wiki/<wbr>display/FIREFOX/%5Bbug+<wbr>1317790%5D+Fxa+Sign+in+vs+<wbr>Sign+Up</a><b><br></b>[2] - <a href="https://github.com/mozilla/fxa-content-server/issues/4467" target="_blank">https://github.com/mozilla/<wbr>fxa-content-server/issues/4467</a><br>[3] - <a href="https://github.com/mozilla/fxa-content-server/pull/4472" target="_blank">https://github.com/mozilla/<wbr>fxa-content-server/pull/4472</a><br>[4] - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1319904">https://bugzilla.mozilla.org/show_bug.cgi?id=1319904</a><br>[5] - <a href="https://github.com/mozilla/fxa/issues/209">https://github.com/mozilla/fxa/issues/209</a><br>[6] - <a href="https://github.com/mozilla/fxa-content-server/issues/4467">https://github.com/mozilla/fxa-content-server/issues/4467</a><br>[7] - <a href="https://github.com/mozilla/fxa-content-server/pull/4473">https://github.com/mozilla/fxa-content-server/pull/4473</a><br>[8] - <a href="https://github.com/mozilla/fxa-content-server/issues/4468">https://github.com/mozilla/fxa-content-server/issues/4468</a><br><a href="https://github.com/mozilla/fxa-content-server/issues/4467" target="_blank"><b></b></a></div>