Closed Bug 1020253 Opened 10 years ago Closed 10 years ago

Standalone UI for link clickers needs to help users grant access to microphone/camera when applicable

Categories

(Hello (Loop) :: Client, defect, P2)

defect
Points:
3

Tracking

(firefox34 fixed)

RESOLVED FIXED
mozilla34
Iteration:
34.1
Tracking Status
firefox34 --- fixed

People

(Reporter: RT, Assigned: sevaan)

References

Details

User Story

As a WebRTC browser but not on Firefox URL clicker, I want to clearly understand that I need to share my microphone and camera in order to trigger the call, so that I can easily process a call.

Attachments

(6 files)

It seems one of the main reason why users can't get into WebRTC calls is because they don't understand they need to grant access to the microphone and camera as part of the browser dialogue.
We need to find a UX way to help users understand they need to grant access on third party browsers (this issue is not applicable in Firefox given we'll bypass the WebRTC browser prompt).
User Story: (updated)
Attached image Example 1
Attached image Example 2
Attached image Example 3
For info I attached examples from other WebRTC services illustrating how others try to address this issue.
Need ux for this
Flags: needinfo?(dhenein)
Assignee: nobody → dhenein
Status: NEW → ASSIGNED
Whiteboard: p=3 s=33.3 [qa-]
Removed from Iteration 33.3
Assignee: dhenein → nobody
Status: ASSIGNED → NEW
Whiteboard: p=3 s=33.3 [qa-] → p=3 [qa-]
Assignee: nobody → sfranks
Status: NEW → ASSIGNED
Whiteboard: p=3 [qa-] → p=3 s=34.1 [qa-]
Flags: firefox-backlog+
Iteration: --- → 34.1
Points: --- → 3
Whiteboard: p=3 s=34.1 [qa-] → [qa-]
QA Contact: anthony.s.hughes
I'm moving this to a P5 because I think the UI implementation can be put off until Fx 35.  It's useful to have the UX design done in case we get user feedback that that standalone UI really need this.
Priority: P2 → P5
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #7)
> I'm moving this to a P5 because I think the UI implementation can be put off
> until Fx 35.  It's useful to have the UX design done in case we get user
> feedback that that standalone UI really need this.

Feedback from TokBox says that this is where they see a great drop-off in terms of people being able to get into a call. I fear if we don't have this we'll have many people not being able to get into calls - we need this for FF34.
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #7)
> I'm moving this to a P5 because I think the UI implementation can be put off
> until Fx 35.  It's useful to have the UX design done in case we get user
> feedback that that standalone UI really need this.

Feedback from TokBox says that this is where they see a great drop-off in terms of people being able to get into a call. I fear if we don't have this we'll have many people not being able to get into calls - we need this for FF34.
Ok, let me raise the priority of this
Priority: P5 → P2
Flags: needinfo?(dhenein)
Triggers in various browsers:

- Firefox uses a doorhanger from the identity block (top-left)
- Chrome uses a notification bar with the Allow button on the top-right.
- Opera uses a modal popup in the top-center.

Safari and IE don't support WebRTC.
Attached is an image showing a proposed call-out in Google Chrome to draw attention to the camera and microphone permissions.

Design Notes:

- Uses same shape as Firefox's doorhangers (the arrow will point to the "Allow" button) in the Chrome notification bar.
- Attention getting blue (#1eb3fb) really pops off the page to catch the user's eye
- Drop-shadow makes it seem like it's a Chrome notification rather than being part of the Hello! page.
- Icon also communicates adding camera permissions.

I've ignored a Firefox call-out since we will be bypassing permissions, and Safari and IE do not support WebRTC. For all other browsers we can just eliminate the call-out.
Attachment #8464930 - Flags: ui-review?(mmaslaney)
(In reply to Sevaan Franks [:sevaan] from comment #11)
> Triggers in various browsers:
> 
> - Firefox uses a doorhanger from the identity block (top-left)
> - Chrome uses a notification bar with the Allow button on the top-right.
> - Opera uses a modal popup in the top-center.
> 
> Safari and IE don't support WebRTC.

Let's only address Firefox and Chrome scenarios.
We can address Opera later bug given the low number of users and high number of bugs to address for FF34 I suggest we stay focussed on Firefox and Chrome users for this bug.
(In reply to Sevaan Franks [:sevaan] from comment #12)
> Created attachment 8464930 [details]
> Chrome Permissions Call-out
> 
> Attached is an image showing a proposed call-out in Google Chrome to draw
> attention to the camera and microphone permissions.
> 
> Design Notes:
> 
> - Uses same shape as Firefox's doorhangers (the arrow will point to the
> "Allow" button) in the Chrome notification bar.
> - Attention getting blue (#1eb3fb) really pops off the page to catch the
> user's eye
> - Drop-shadow makes it seem like it's a Chrome notification rather than
> being part of the Hello! page.
> - Icon also communicates adding camera permissions.
> 
I like that!
Just one comment - having looked at other similar solutions from other services it seems that they struggle keeping the arrow underneath the buttons in the Chrome notification bar for different screen resolutions.
Probably something to keep in mind when developing/testing.

> I've ignored a Firefox call-out since we will be bypassing permissions, and
> Safari and IE do not support WebRTC. For all other browsers we can just
> eliminate the call-out.

For link clickers we won't be bypassing permissions initially so I suggest we support this on Firefox also.
After FF34 we'll want to handle "link clicking" on Firefox using the desktop client UI (as I click a link on Firefox, a conversation window opens offering me to initiate a call).
Firefox call-out attached.
Attachment #8465586 - Flags: ui-review?(mmaslaney)
Attachment #8465586 - Flags: ui-review?(mmaslaney) → ui-review+
Attachment #8464930 - Flags: ui-review?(mmaslaney) → ui-review+
Blocks: 1047040
Marking this as resolved. Implementation work to take place in Bug 1047040.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Sevaan, I received some feedback on this - essentially the fact that if you click anywhere the permission call-out goes away and the user won't find it easy to enable the camera.
What do you think about the experience here - https://free.gotomeeting.com/
The help message takes over the screen until you enable access which I think is good as anyway you can't do anything else until you enable access.
Flags: needinfo?(sfranks)
Attached image GoToMeeting example
Hey Romain, is there a reason why can't our call-outs remain on-screen until access is enabled, just like they have a full-screen overlay that doesn't disappear until access is granted?
Flags: needinfo?(sfranks)
Er...grammar. "...why our call-outs can't remain on-screen..."
You're right, let's keep the current design if the call-outs can remain on screen in the following scenarios:
* if the user clicks somewhere else on the page
* if the user navigates to another tab and then comes back to the Hello tab
* if the user goes to another application and then gets back to the Hello tab
Flags: qe-verify-
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.