Comments (28)
@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.
from fxa.
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):
- The last time this device was seen, i.e. interacted with the FxA server in any way
- The last time this device attempted to sync, whether or not that attempt actually succeeded
- 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
from fxa.
@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?
from fxa.
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?
from fxa.
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).
from fxa.
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.
from fxa.
needs feedback from @dannycoates to coordinate
from fxa.
Device icons (decided against showing OS):
from fxa.
from fxa.
The only new view would be the device review screen (and disconnect confirm dialog, not required).
User Agent rendered using ua-parser library.
from fxa.
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 [email protected]
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).
from fxa.
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.
from fxa.
@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.
from fxa.
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."
from fxa.
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)
from fxa.
(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
from fxa.
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.
from fxa.
👍
from fxa.
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)
from fxa.
will need to follow up with @rfk and @ryanfeeley ....
from fxa.
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.
from fxa.
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.
from fxa.
https://mozilla.aha.io/features/FXA-16
from fxa.
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?
from fxa.
(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).
from fxa.
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
from fxa.
...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.
from fxa.
@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
from fxa.
Related Issues (20)
- English string "Or download" displayed in Danish Firefox Accounts HOT 1
- Update enabled locales list to include Friulian (fur) HOT 1
- The user is not redirected back to AMO after reset password
- "Device Connected" page, the text on the button becomes unreadable blue-text-on-blue-background when clicked ("See tabs from synced devices") due to insufficient contrast HOT 6
- Cannot unsubscribe from Firefox Account Tips HOT 4
- Readme and documentation needs to use updated "Mozilla accounts" branding HOT 4
- Avatar is clipped on subscriptions page, due to explicit `w-16 h-16` classes HOT 4
- Subscription management page uses CSS file with broken/out-of-date source map HOT 1
- Layout shift after you open Bento Menu at top right of Mozilla Accounts page HOT 5
- The Sync sign-in success page just says "Sign in to this Firefox to complete set-up" without any other context (if you're not signed in) HOT 3
- The column of time/datestamps need a label/title to clarify their meaning, in the Connected Services section of settings
- On the "Approval now required" card at the end of the firefox.com/pair flow, the "from your other device" text is styled to be extra-small, despite being fairly-important HOT 1
- No graphic on on the "Approval now required" card at the end of the firefox.com/pair flow, HOT 2
- If the firefox.com/pair process times out and reaches "Pairing not successful", the user should be able to restart the pairing process with an offered button or link, or a reload HOT 2
- (l10n) - Duplicate string IDs
- Research @nx/playwright HOT 1
- accounts.firefox.com sends two HSTS headers HOT 5
- fxa-auth-server mock statsd lacks of function histogram
- (l10n) productPaymentCycleNew and productPaymentCycleOld are hard-coded to English HOT 1
- While subscriptions.firefox.com is loading, it shows a zero-height empty "card" while the loading throbber/spinner is still animating HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fxa.