[UX] Figure out a way to make the device permissions doorhanger harder to miss

RESOLVED DUPLICATE of bug 1004061

Status

()

defect
RESOLVED DUPLICATE of bug 1004061
5 years ago
3 years ago

People

(Reporter: phlsa, Unassigned)

Tracking

36 Branch
x86
All
Points:
5
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ux])

There are some issues with the device permissions doorhanger (and doorhangers in general) where users don't notice them and discard them accidentally. Let's find a way to avoid that.
Flags: firefox-backlog+
Points: --- → 5
Flags: qe-verify-
See Also: → 1004061
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1047040
Sevaan, this bug is about improving the prompt UI for all websites using WebRTC, bug 1047040 seems to be a Loop specific bug to teach users how to workaround this problem.
Flags: needinfo?(sfranks)
Apologies.

Ideas:

- Persistent doorhangers that must be interacted with to close (even if it's just hitting the X to close it)
- Pulsing permissions indicators in URL bar.
Status: RESOLVED → REOPENED
Flags: needinfo?(sfranks)
Resolution: DUPLICATE → ---
See Also: → 1171078
We now see this problem in Loop screensharing as well as normal device sharing.  Any possibility of getting some sort of worse-is-better simple-to-implement UI that doesn't need to wait on the privacy center work?

I've just talked to :florian about technical feasibility, and he says:

<flo-retina>  Pulsing permissions indicators in URL bar." seems like not much work.
<flo-retina> if it's just replacing a png icon with an animated png one ;).
<flo-retina> or adding some kind of CSS animation

<dmose> flo-retina: any idea on the "Persistent doorhangers"?
<flo-retina> probably not terribly difficult to implement either, but I'm not sure if there would be unexpected consequences (eg. when moving focus between windows
<flo-retina> That "persistent doorhanger" thing would need a more detailed specification about what dismisses it and what doesn't. And I'm not sure it's worth it if privacy center is coming really soon and changing all of that.

So it sounds like the simplest thing would be if someone (sevaan?) could be convinced to sign off on the pulsing indicator or CSS animation.

Giving sevaan and shell a needinfo: what can be done to get this bug moving again?
Flags: needinfo?(sfranks)
Flags: needinfo?(sescalante)
Is anything needed? We have an animation for shaking the EME icon when DRM is first encountered (Bug 1134513). Can we use that same mechanism to shake the permissions indicator?
Flags: needinfo?(sfranks)
sfranks: I think the key first step is for someone in UX to sign off on it, since it effects all getUserMedia requests from the web, not just Loop stuff.  Could that signer-off be you, or would it need to be someone else (and if the latter, who)?
Flags: needinfo?(sfranks)
Diverting to Phlsa.
Flags: needinfo?(sfranks) → needinfo?(philipp)
(In reply to Sevaan Franks [:sevaan] from comment #5)
> Is anything needed? We have an animation for shaking the EME icon when DRM
> is first encountered (Bug 1134513). Can we use that same mechanism to shake
> the permissions indicator?

We can use the same mechanism, but the details would need to be tweaked. The EME icon is shaken 5 times quickly, which is good to attract attention to a notification when it appears, but isn't good to prevent users from losing it.
I know I suggested a pulsing indicator as an action, but I'd like to revisit the persistent doorhanger for permissions. If a user HAS to interact with it, it shouldn't be so easy to close it by accidentally clicking off of it.

Is this still a feasible option? The animated icon definitely feels like more of a band-aid solution.
Sevaan, agreed that this seems like a more real fix.  Comment 4 suggests that it's probably feasible but the next step in figuring out exactly what it would take would be a more detailed design specification about exactly what actions would dismiss it and what actions wouldn't.
I believe the whole permissions UI is being changed for Firefox 43 as part of the Control Center project . The design work has been completed by Aislinn Grigas (and looks great). Philipp, is this bug addressed in that work?

Until that project is implemented, I would suggest that the doorhanger remain persistent until a user clicks the "Share Selected Devices" button or the X in the doorhanger. Clicking anywhere on the page does not dismiss it.
Flags: needinfo?(philipp)
Flags: needinfo?(philipp)
In general, making the doorhanger persistent makes sense.
IIRC, that will also be the behavior of prompts once control center is implemented.

Ash, is the permissions (and specifically permission prompts) part of control center still on track for 43? And is it correct that the prompts will only be dismissable through a yes/no decision?
Flags: needinfo?(philipp) → needinfo?(agrigas)

Comment 13

4 years ago
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #12)
> In general, making the doorhanger persistent makes sense.
> IIRC, that will also be the behavior of prompts once control center is
> implemented.
> 
> Ash, is the permissions (and specifically permission prompts) part of
> control center still on track for 43? And is it correct that the prompts
> will only be dismissable through a yes/no decision?

aiming for 43 will know better after whistler and yes for dismissal behavior
Flags: needinfo?(agrigas)
(In reply to agrigas from comment #13)
> (In reply to Philipp Sackl [:phlsa] please use needinfo from comment #12)
> > In general, making the doorhanger persistent makes sense.
> > IIRC, that will also be the behavior of prompts once control center is
> > implemented.
> > 
> > Ash, is the permissions (and specifically permission prompts) part of
> > control center still on track for 43? And is it correct that the prompts
> > will only be dismissable through a yes/no decision?
> 
> aiming for 43 will know better after whistler and yes for dismissal behavior

Are we still on track to have this available for implementation in Fx43?  This would help both the WebRTC platform and Hello products greatly.  And I believe Florian will have time in Fx43 to implement this.  He's back from PTO on Monday, and I can verify.  But having the UX available will allow us to put this on the schedule.  Thanks!
Flags: needinfo?(philipp)
Flags: needinfo?(agrigas)

Comment 15

4 years ago
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #14)
> (In reply to agrigas from comment #13)
> > (In reply to Philipp Sackl [:phlsa] please use needinfo from comment #12)
> > > In general, making the doorhanger persistent makes sense.
> > > IIRC, that will also be the behavior of prompts once control center is
> > > implemented.
> > > 
> > > Ash, is the permissions (and specifically permission prompts) part of
> > > control center still on track for 43? And is it correct that the prompts
> > > will only be dismissable through a yes/no decision?
> > 
> > aiming for 43 will know better after whistler and yes for dismissal behavior
> 
> Are we still on track to have this available for implementation in Fx43? 
> This would help both the WebRTC platform and Hello products greatly.  And I
> believe Florian will have time in Fx43 to implement this.  He's back from
> PTO on Monday, and I can verify.  But having the UX available will allow us
> to put this on the schedule.  Thanks!

Hi Maire,
We are currently scoping this for 43 on the priv/sec team and will have eng resources to do this work.
Flags: needinfo?(agrigas)

Comment 16

3 years ago
i swear bugzilla just puked up some really old needinfo's i haven't seen.  at any rate - this is being implemented between panos's and maire's teams in the next couple of releases.
Flags: needinfo?(sescalante)
(In reply to :shell escalante from comment #16)

> at any rate - this is being implemented between panos's and maire's teams in
> the next couple of releases.

The patch in bug 1004061 (landed only on the elm branch for now) fixes this.
Status: REOPENED → RESOLVED
Closed: 5 years ago3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1004061
You need to log in before you can comment on or make changes to this bug.