Finalize design for devices view

[rfk]

No description provided.

[rfk]

@ryanfeeley please put your proposed screens in here when you're happy with them for initial review, and we can dive into the details of what we'll need to build to make it happen.

[rfk]

The hard part here is going to be "last sync", since we don't currently record that information and don't have a good way of guessing it. It's not even in the "clients" record in sync [1]. I think we'll need the client to report this information to us.

Also, semantically, what is the precise meaning of this timestamp? I can see three possible levels of granularity (one of which is not actually related to "sync" at all):

1. The last time this device was seen, i.e. interacted with the FxA server in any way
2. The last time this device attempted to sync, whether or not that attempt actually succeeded
3. The last time this device successfully competed a sync

I guess you want (3), but (1) is also useful context for a user.

[1] https://docs.services.mozilla.com/sync/objectformats.html#clients

[rfk]

@ryanfeeley a scoping question: I fire up chrome, go to https://accounts.firefox.com and sign in (say e.g. I want to access my FxA-authenticated pocket stuff in chrome). Shall we represent that login session in the "Devices" list above, somewhere else, or nowhere?

[ryanfeeley]

Depends. What can we represent if I am signed in to Pocket, Hello and Sync on two desktop computers, and Sync and a web session on accounts.firefox.com on iOS? "Devices" starts to break down pretty quicky. Sessions?

[rfk]

Actually I think "devices" is probably OK even for web sessions, we can just present them as really primitive devices (ie they wouldn't have a "last sync time", or the ability to enable Hello).

[billmaggs]

I do think we're talking about the concept of Firefox devices, which run Firefox services as well as Firefox the product. Sessions seems like not quite the right idea. I think we can live with it for now.

[vladikoff]

needs feedback from @dannycoates to coordinate

[ryanfeeley]

Device icons (decided against showing OS):

[ryanfeeley]

Collapsed:

Expanded view:

Refreshing view:

[ryanfeeley]

The only new view would be the device review screen (and disconnect confirm dialog, not required).

User Agent rendered using ua-parser library.

Reviewing:

Renaming:

[billmaggs]

How about we show the full UA only on clicking an unobtrusive link? It's a
Wizard feature, but kinda cool.

On Tue, Oct 6, 2015 at 1:26 PM, Ryan Feeley notifications@github.com
wrote:

The only new view would be the device review screen (and disconnect
confirm dialog, pending).

What should we include in the details here if not location or IP. Full
user agent string?

[image: devices-review]
https://cloud.githubusercontent.com/assets/68213/10321483/ea37623c-6c46-11e5-8627-192da2f04948.png

—
Reply to this email directly or view it on GitHub
#62 (comment).

[rfk]

I do think we're talking about the concept of Firefox devices, which run Firefox services as well as
Firefox the product. Sessions seems like not quite the right idea. I think we can live with it for now.

My only pushback is, we should really surface connected sessions somewhere, because the user deserves to know what's connected to their account, regardless of what or how. I'm not sure which would be more awkward, including them in this list as really primitive devices, or putting them in a separate list and trying to explain the difference.

[dannycoates]

@ryanfeeley in addition to a "last connected" time, another possible state is "disconnected", either by explicitly logging out of a device or an account reset. I think it'd be useful to show that distinction somehow.

[billmaggs]

I think this would be good to show, but only if it was fairly timely. The user disconnects from FxA on her mom's computer and ten minutes later back on her home laptop she still shows as connected. I think the expectation for logging out or resetting is higher than "last connected."

[rfk]

This is a server-generated view, we can show the disconencted status here pretty much instantaneously (we'll know devices are disconnected because they don't have a session token)

[rfk]

(current device)

I'd be interested to hear about the proposed mechanics of detecting this. The device itself knows its own id, but can it reliably communicate that back to the fxa-content-server page that's rendering this view? In particular if I'm visiting it on the web rather than by clicking a link from chrome that can embed the device id.

This may require the "device handshake" work we've been talking about, so that the device can tell the content page about its id; /cc @zaach @shane-tomlinson

[dannycoates]

I'd be interested to hear about the proposed mechanics of detecting this

I don't think any handshake is necessary in the normal case. Session tokens map to devices so we know from that what device is being used.

[rfk]

👍

[rfk]

Does this bug now contain enough info to push ahead with implementing the device list view? If so, let's close it down and spin up concrete implementation bugs in whatever repos are appropriate.

(Also, @ryanfeeley, this one feels like a perfect candidate for trying out whatever new UX review processes we come up with in discussion this week)

[vladikoff]

will need to follow up with @rfk and @ryanfeeley ....

[ckarlof]

@billmaggs @ryanfeeley

Where are capturing the requirements for this dashboard/view? I can imagine there are lots of questions about whether this is devices or profiles and sync or not sync. I feel it would be useful if requirements were written down. Otherwise, it's going to be hard to evaluate both the design and implementation.

[ryanfeeley]

I'll update the designs shortly to define: no devices state, actively refreshing state, UA string in Review screen. May also include a flow diagram.

[billmaggs]

https://mozilla.aha.io/features/FXA-16

[rfk]

Where are capturing the requirements for this dashboard/view?

We had a looooong discussion about this in the product planning meeting today, from which these key points stood out:

• Discussing things in github issues is infinitely better than discussing things in Aha.
• But we shouldn't just leave issues hanging around open if they no longer represent active work.
• We need an obvious place to look to find the latest designs/requirements/etc for this feature; using issue comment history as the source of truth is too fragile.
• Aha is good for tracking overviews of feature work, but is not a great place for capturing all the details of screens, flows, assets, etc.

So I propose an experiment in keeping github as the Single Source of Truth, based on a suggestion from @vladikoff and @ryanfeeley. I have created the following directory in this repo:

https://github.com/mozilla/fxa/tree/master/features/FxA-16-devices-view

Let's close this issue with a PR that populates that directory.

I don't have any strong feelings about what the contents of this directory should be - it could include image files, links to lucidchart, a big list of user-stories to validate against, whatever works. But the definition of "works" should be:

• Engineers can refer to that directory and see everything they need to know in order to implement the feature.
• Product management can refer to that directory to sanity-check that the feature is shaping up as expected.
• QA can refer to that directory and learn everything they need to know about verifying a complete and correct implementation of the feature.
• And if we need to clarify, adjust or de-scope anything about the feature, there's one obvious way to do it: as PRs against that directory.

@vladikoff is this an OK first approximation of what you suggested in the meeting?

@ryanfeeley from your perspective, would this help clarify how to deliver designs and reduce potential for divergence/confusion/miscommunication as the feature work develops?

@shane-tomlinson @philbooth @dannycoates, from your perspective with implementing this feature, does this sound like a useful convention for keeping track of things and providing clarity on exactly what's required?

I'm not wedded to any of the details here, but I think we need to try out something more structured than just noting things inline in the issue comments. If the approach proves valuable, we can keep doing it for subsequent feature work and think about formalizing some of the details. If it doesn't, we can throw away the directory and try something else next time.

Baring objections (and I am, as always, completely open to objections about my harebrained schemes) then the next steps here are:

• @ryanfeeley to file such a PR, providing latest designs etc
• @shane-tomlinson and @philbooth to review

Thoughts?

[rfk]

(I'm also going to take this out of the "device registration" milestone and make a new one explicitly for "devices view", corresponding to the FxA-16 feature card).

[rfk]

It also seems that some of the key engineering design outcomes from [1] and related discussions could profitably be captured in this form as well.

[1] https://public.etherpad-mozilla.org/p/fxa-multi-device

[philbooth]

...from your perspective with implementing this feature, does this sound like a useful convention for keeping track of things and providing clarity on exactly what's required?

Works for me.

[vladikoff]

@vladikoff is this an OK first approximation of what you suggested in the meeting?

Yeap!

@ryanfeeley to file such a PR, providing latest designs etc

Here it is:
#64