1178335 - Desktop client user joins a conversation directly when clicking a Hello notification

Status: RESOLVED WONTFIX

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

Comment 1

[:shell escalante]

Hi RT, let's talk about this one with the group.  I may be wrong - but this might be something that Ekr, Martin, and Adam had talked about being a security no-no.  If it means i don't get the screen that has the button to click saying "Join the conversation".  So we should ask about this one at the stand-up.

Maybe clicking the notification is different enough than just having the link open right into the conversation - but we should make sure.

Comment 2

[Romain Testard [:RT]]

The security issue we discussed was for link clickers joining a conversation directly by clicking a URL.
This bug is for desktop client users:
- Current behavior: [1] Receive a notification, [2] Click the notification, panel opens, [3] Select conversation, conversaytion window opens
- Desired behavior: [1] Receive a notification, [2] Click the notification, conversation window opens

Note - this assumes implementation of Bug 1178336 to provide the conversation name on the notification.

Comment 3

[Romain Testard [:RT]]

Adam do you see a security issue with this?

Comment 4

[Adam Roach [:abr]]

(In reply to Romain Testard [:RT] from comment #3)
> Adam do you see a security issue with this?

So, the real issue with the link-clicker scenario is (a) clicking on a link doesn't carry with it an expectation that your camera might turn on, and (b) hiding a hello.firefox.com link behind a link shortener (like bit.ly) makes it trivial to hide the nature of the link.

For *this* scenario, where you're clicking on something more obviously tied to an application you have installed, the situation isn't quite as dire. That said, being one errant click away from turning on your camera (e.g., going to the notification area to dismiss something, having a hello bubble push it out of the way, and then having a surprise camera activation because you clicked on the hello button instead of the notification you were trying to dismiss) is still a pretty risky situation. It seems that there should be some additional positive indication of intent before we drop people into a "camera on" situation.

I'd ask Sevaan for something more specific, but I think what we want here is opening the conversation window in an inactive state ("click to join") is probably the right behavior.

Comment 5

[Adam Roach [:abr]]

Attachment: join-mockup.png

To be very clear about what I mean, here's roughly how things would look after clicking on a notification...

Comment 6

[Romain Testard [:RT]]

Thanks Adam.
This would mean equal number of clicks to join a conversation compared to what we have today (Click 1 on notification opens the panel and click 2 on the conversation joins you to it).
The main goal here is to reduce the number of clicks and therefore improve the funnel so I'd say we should either implement as originally required (direct join on click) or not implement this at all if it is considered to be too risky.
I don't think it's any different from what others do (Skype, Vidyo, Facetime, Viber) regarding a one click action from a notification to turn on the camera.
Sevaan what do you think?

Comment 7

[Sevaan Franks [:sevaan]]

What if I automatically join the conversation, so I can see who is there, but my camera and microphone are muted by default, with a bubble attached to them, or an overlay over the video screen that says:

"Your camera and microphone are muted. Click these buttons to unmute yourself, and say hello!" with a clear visual explaining.

The user is now in the conversation, reducing the funnel to joining...we have an extra step for them to actually start conversing, but they have the benefit of seeing who is in the room (in case they don't know).

Comment 8

[Romain Testard [:RT]]

Thanks Sevaan.
It feels like this solves another problem that would apply to joining a room from the panel (i.e join audio/face muted) since when you join a room from the panel when someone else is already present, you never know who this is (just like answering an anonymous phone call).

That's probably a valid scenario (maybe something for us to address at some point) although if the concerns that it addresses are true (risk of turning the camera on without realizing what is happening) then I feel that the proposed solution does not bring user value (user has to go through 2 extra steps if he indeed wants to talk - audio mute and face mute). This makes the experience less optimal for users who do want to join the conversation quickly so probably not worth implementing at all and keeping the currently implemented solution as is.
I can resolve this as WON'T FIX unless you guys have further thoughts.