Closed Bug 1037162 Opened 10 years ago Closed 10 years ago

[UX] Improve design for screen and device sharing permissions

Categories

(Firefox :: General, defect)

33 Branch
x86
All
defect
Not set
normal
Points:
13

Tracking

()

RESOLVED FIXED
Iteration:
34.2

People

(Reporter: phlsa, Assigned: phlsa)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ux])

Attachments

(1 file)

In bug 1031424, we created a spec for screen sharing permissions that can be built within a short time, but only works under some constraints (most notably whitelisting).

If we want to make screen sharing more widely available (and improve the general clarity and security of our device sharing), we need to make some adjustments.

Here's an (incomplete) list of things to consider:
- Sharing the browser is a special high-risk case
- It looks like we are currently losing users in the permissions flow. We should find out if those users intentionally don't share anything or if it is a problem with our flow.
- Some cases (e.g. sharing single windows or tabs) are not covered yet.
- The current panels are a mix of arrowpanel and window
Flags: firefox-backlog+
One point I missed:
- There should be some kind of onboarding experience when users first use device sharing that explains what the global indicator is and does etc.
QA Whiteboard: [qa-]
Whiteboard: [ux]
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Iteration: --- → 34.1
Points: --- → 13
Iteration: 34.1 → 34.2
Specification of new device sharing permissions.
Still needs some visual design love (I'll file bug for that)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Need info GMC for verification of this design bug.
Flags: needinfo?(madhava)
Flags: needinfo?(gavin.sharp)
Flags: needinfo?(cweiner)
Flags: needinfo?(gavin.sharp)
Comment on attachment 8470955 [details]
DeviceSharingPermissions Spec

jesup, could you please have a look a this mockup and confirm that the platform pieces are technically feasible?
Attachment #8470955 - Flags: feedback?(rjesup)
Comment on attachment 8470955 [details]
DeviceSharingPermissions Spec

Sorry for the delay.

I overall love the design.

A few issues:
You can share any number of any type with a page.  You can't see easily what they're used for, but we could tell you the number of devices of a given type and the names.  (This includes windows/screens)

Per-device mute may be useful - though it can also be handled in context by the app.  More important to our privacy needs are global mutes for video/audio and/or both.  I would be good with a single global "mute all", but I can see need for "mute all mics" and "mute all cameras".  

Previews may be problematic for cameras; they may be possible for windows - worth considering, but doesn't impact the UI *that* much.

In a "what we always thought we should have" UI, mic sharing requests should include a level meter (or meters).  I don't really think we need N simultaneous meters, but a meter-bar showing the current selection's audio level would be good.  Not a blocking requirement, so could *easily* go to a followup.  Requires more backend support and coordination.
Attachment #8470955 - Flags: feedback?(rjesup) → feedback+
Flags: needinfo?(madhava)
Flags: needinfo?(cweiner)
The attached mockup doesn't really show how we would display that the user is sharing multiple cameras with a page. To reach the state of sharing multiple cameras, we also need to support requesting permission to use a camera while a camera is already in use.
Same thing for window sharing; a web page could request a new window to be shared while one is already being shared.
Another possible complication: the devices may be used by different domains, if the getUserMedia requests are made by iframes inside the web page rather than by the page itself.
I'm reopening this bug to deal with the comments from Randell and Florian.
Also, the design doesn't accommodate app sharing at the moment.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Iteration: 34.2 → 34.3
QA Whiteboard: [qa-]
Flags: qe-verify-
Philipp: can you address that in a new followup bug? It gets confusing to reopen bugs in general (perhaps less so for UX bugs, but it's still sub-optimal from a tracking perspective). New bugs are cheap!
Flags: needinfo?(philipp)
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #9)
> Philipp: can you address that in a new followup bug? It gets confusing to
> reopen bugs in general

In this specific case I think reopening was the right thing to do, as the attached mockup isn't implementable as-is.
It's still better for tracking to file a new bug. The same way that we don't reopen FIXED engineering bugs if we're "forward fixing" issues with their patches. There's no equivalent to "backing the patch out" for UX work.
Filed bug 1058775 as a follow up. I'll do the work there.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago10 years ago
Flags: needinfo?(philipp)
Resolution: --- → FIXED
Iteration: 34.3 → 34.2
You need to log in before you can comment on or make changes to this bug.