On Aug 12, 2013, at 6:42 PM, Nick Alexander <[email protected]> wrote:
>> So I'm going to claim a decision has been made here. We'll build a >> container to handle authentication screens but not management. afaik, >> zcarter is already wiring up the existing user tested mocks to interact with >> the account server, and we'll be able to integrate it. From the "client >> implementation" team side, it means we need to craft a container that we can >> put this content in as one of our first jobs. > > I'm frustrated that the engineers who understand most about how this will > feel on Android have raised concerns that have been ignored by the larger > team [1] [2] [3]. > > I suggest that what needs to happen is that we need to clearly delineate > "auth screens" vs "management". Particularly with reference to > http://people.mozilla.org/~jgruen/pdx_deck/?full#SampleScreensDesktop: if you > look at the Sync Success screen, that seems most likely to be the final > screen in web content. But it's displaying the progress of a Sync and the > list of devices in the Firefox Account device constellation. That's a lot > closer to management than authentication, and it's really conflating Auth > (which is Firefox Accounts) and Sync (which is a consuming service). > > I'm concerned that as we push the Firefox Account + Sync setup flow into the > first run experience, there is going to be an awkward jump from web content > to native (and even worse, possibly back for password reset). > > As I said before, I am bullish on web content in general. But this seems > like a proposal motivated by a *very* different situation [4] without > consideration to what actually happens next. Can we get UX to produce mocks > showing the jump between web content and native? This is going to be ugly on > Android and downright hideous on Desktop Firefox. I agree these are completely legitimate concerns. When I said "Obviously, if once implemented there are clear reasons to make the additional investment and make the thing native, we can go there." - I was talking about a matter of weeks from today. My goal was not to force any client team (who have ultimate responsibility to maintain the feature) to accept this decision as the final way the product would ship, but rather to build it into desktop in the elm as a way to get authentication working *soon*. In terms of larger team responsibilities, the identity team needs to vet that auth from content is viable, and probably needs an approach like this on FirefoxOS. So I'm thinking we accelerate building the functionality without committing here, and that most of the work required is stuff we'd have to do anyway. Does this help? lloyd > Nick > > [1] https://mail.mozilla.org/pipermail/sync-dev/2013-August/000230.html [me] > [2] https://mail.mozilla.org/pipermail/sync-dev/2013-August/000231.html > [rnewman] > [3] https://mail.mozilla.org/pipermail/sync-dev/2013-August/000274.html > [mfinkle] > [4] Persona is the very different situation. I have not seen any experience > with "native persona" on Android, and only a few stabs on Desktop. Happy to > be corrected if I'm neglecting the real situation. The fact remains that > Persona and Firefox Account setup are different. _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
