[meta] Firefox should handle Hello link-clicks in the conversation window (aka "Link clicker parity")

RESOLVED INCOMPLETE

Status

P3
normal
Rank:
28
RESOLVED INCOMPLETE
4 years ago
2 years ago

People

(Reporter: standard8, Unassigned)

Tracking

unspecified
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needs breakdown when we get to it][previous bugs closed incomplete, see comment 5])

User Story

As a link clicker in Firefox, I can use the desktop client UI so that I can browse through tabs and carry on with my conversation.


Acceptance criteria:
* Clicking the Hello link on Firefox opens a new page of the standalone link clicker UI:
   - The conversation name is displayed with a button allowing to join the conversation
   - If context was added to the conversation by the link generator, a thumbnail with favicon as well as the URL of the website gets displayed to the user prior to joining
* When using the button to join a conversation the link clicker can be prompted the following messages:
   - The conversation is full
   - The URL is invalid/expired with a button to retry
   - If the link clicker is already joined to the conversation on the desktop client UI through the same browser, he gets prompted that he is already in the conversation
* When joined to the conversation the desktop client UI is used:
   - When waiting alone in the conversation the link clicker is not able to rename the conversation or use the copy/e-mail/share buttons
   - When in a conversation with someone else, the link clicker UI is the same as the current desktop client UI with the only difference that the link clicker cannot initiate sharing (we ultimately want to allow the link clicker to initiate sharing but we want to limit the complexity of this implementation and therefore decided to remove this capability for link clickers). The screen sharing icon is disabled for the link clicker.
   - When receiving shared content, the link clicker can see the shared content rendered inside of the conversation window. A notification appears informing the user that he can click the arrow to expand the conversation window - this notification fades out after 5 seconds of being displayed and can be dismissed by the user. A sub-option allows to disable this notification in the future. The video windows get re-sized depending on the shared screen aspect ratio. 
   - If the link clicker happens to be the link generator (link generator pasted the link in his own browser window but did not have the conversation opened), the conversation window opens as if he had clicked the conversation name in the panel
* At the end of a session the feedback form is per the current desktop client UX

Attachments

(1 obsolete attachment)

(Reporter)

Description

4 years ago
I believe it is the intention that link-clicks within Firefox desktop will be handled within the conversation window, rather than a new tab at some stage in the future.

Darrin: please confirm if this is the intention.

This bug will track the necessary work to handle that.
Flags: needinfo?(dhenein)
(Reporter)

Updated

4 years ago
Depends on: 1000202
(Reporter)

Updated

4 years ago
Depends on: 1035289
Intention confirmed ;)

Yes, the goal is to have links go straight to the conversation window UI within Firefox.
Flags: needinfo?(dhenein)
(Reporter)

Updated

4 years ago
Summary: [meta] Desktop Client should handling link-clicks in the conversation window → [meta] Desktop Client should handle link-clicks in the conversation window
(Reporter)

Updated

4 years ago
Depends on: 1000129, 1019462, 1019465
(Reporter)

Updated

4 years ago
User Story: (updated)
(Reporter)

Updated

4 years ago
Whiteboard: [needs breakdown when we get to it] → [needs breakdown revising when we get to it]
(Reporter)

Updated

4 years ago
Duplicate of this bug: 1019458
Depends on: 1069031
Depends on: 1083160

Comment 3

4 years ago
thinking of 37 to allow Rooms to settle and see what is still valid.  Rooms may well handle it - need info to Mark once we triage 37.
backlog: --- → Fx37?
(Reporter)

Comment 4

4 years ago
(In reply to sescalante from comment #3)
> thinking of 37 to allow Rooms to settle and see what is still valid.  Rooms
> may well handle it - need info to Mark once we triage 37.

Rooms won't handle this, we'll likely want to mutate this into rooms & links.
(Reporter)

Updated

4 years ago
No longer depends on: 1069031
(Reporter)

Comment 5

4 years ago
To save confusion, I've closed the bugs that block this as incomplete. When we come to implement this bug, we'll need to do a fresh breakdown anyway - I strongly suspect that we'll end up re-using the outgoing call flow from direct calling, if this is for Links.

If we do something different for rooms, I suspect we'll again look at the code, but we may need to consider rooms separately.
Whiteboard: [needs breakdown revising when we get to it] → [needs breakdown when we get to it][previous bugs closed incomplete, see comment 5]
(Reporter)

Updated

4 years ago
Summary: [meta] Desktop Client should handle link-clicks in the conversation window → [meta] Firefox should handle Hello link-clicks in the conversation window

Comment 6

4 years ago
p1 at least in terms of investigation to see how big this is...make this a break down.  please consider implications on
backlog: Fx37? → Fx37+
Flags: needinfo?(sescalante)
Priority: -- → P1

Comment 7

4 years ago
Hi Sevaan,  does fixing this have implications for screen sharing design?  this bug would make it so people receiving links (party B or Link clicker) who are running firefox see the full Hello desktop client view and not just the link-clicker web view.
Flags: needinfo?(sescalante) → needinfo?(sfranks)
No, in fact I think my current sharing spec uses the Hello desktop client view, so I already assumed this was the case.
Flags: needinfo?(sfranks)
Moving this to P2 based on our new priority definitions.
Priority: P1 → P2
Based on roadmap discussions 2 weeks ago, this is a Fx39 item
backlog: Fx37+ → Fx39?
(Reporter)

Updated

4 years ago
User Story: (updated)
(Reporter)

Updated

4 years ago
User Story: (updated)
(Reporter)

Updated

4 years ago
Duplicate of this bug: 1128284

Updated

4 years ago
Depends on: 1130425

Updated

4 years ago
User Story: (updated)

Comment 12

4 years ago
RT is going to add info
backlog: Fx39? → Fx38+
Rank: 35
Flags: needinfo?(rtestard)
Priority: P2 → P3
After discussions with engineering it sounds like Option 2 (Clicking the Hello URL opens the current standalone client UI. Joining the room will trigger the desktop client UI) is the option which has the most chance to make it to Fx39 given the complexities related to Option 1.

I have amended the user story to reflect this and we'll look into the ability to deliver Option 1 as an evolution of this in a further release.

We still need UX for the following, Sevaan it would be great if you could help there:
- Clicking the Hello on Firefox opens the current standalone client UI. Joining the room will trigger the desktop client UI
- The room is already opened on the desktop (i.e the link generator clicks his own link): joining the room prompts the user an informational message so he's aware that the intended use is to share the link with someone else
- The room is full: use current UX for room full
- The link expired or is invalid: inform the user the link is invalid/expired
- In-room experience alone: need new UX (the link clicker should not be able to rename the room, copy or share the room URL)
- In-room experience with another peer: per current desktop client UX, all features including tab/window sharing are available
- Feedback form: per current desktop client UX
- Initiating sharing: per current desktop client UX
- Receiving shared screen: need UX update
- Accessing shared context: per current desktop client UX
User Story: (updated)
Flags: needinfo?(rtestard) → needinfo?(sfranks)
Created attachment 8562888 [details]
Screen sharing in Conversation Window

I don't see where Options 1 and 2 are detailed...but the proposed solution for going through the Standalong Client UI sounds good. Could you please file bugs for these pieces that need UX work?

> - Clicking the Hello on Firefox opens the current standalone client UI.
> Joining the room will trigger the desktop client UI

> - The room is already opened on the desktop (i.e the link generator clicks
> his own link): joining the room prompts the user an informational message so
> he's aware that the intended use is to share the link with someone else

> - In-room experience alone: need new UX (the link clicker should not be able
> to rename the room, copy or share the room URL)

> - Receiving shared screen: need UX update

Not sure this needs a bug as I am attaching it to this bug here for review. This is what we're asking for, right? How screen sharing would look in the conversation window?
Flags: needinfo?(sfranks)
Attachment #8562888 - Flags: review?(standard8)
Attachment #8562888 - Flags: review?(rtestard)
So the UX bug for this is bug 1130425.
We ask is to have UX for the whole link clicker parity experience (all requirements detailed in the US field) - not "just" receiving a shared screen as a link clicker.

Updated

4 years ago
Duplicate of this bug: 1087947
Comment on attachment 8562888 [details]
Screen sharing in Conversation Window

This looks fine regarding the "receive shared screen aspects although we need the full UX there:
- Clicking the Hello on Firefox opens the current standalone client UI. Joining the room will trigger the desktop client UI
- The room is already opened on the desktop (i.e the link generator clicks his own link): joining the room prompts the user an informational message so he's aware that the intended use is to share the link with someone else
- The room is full: use current UX for room full
- The link expired or is invalid: inform the user the link is invalid/expired
- In-room experience alone: need new UX (the link clicker should not be able to rename the room, copy or share the room URL)
- In-room experience with another peer: per current desktop client UX, all features including tab/window sharing are available
- Feedback form: per current desktop client UX
- Initiating sharing: per current desktop client UX
- Receiving shared screen: need UX update
- Accessing shared context: per current desktop client UX

Please lets carry on with UX discussions on bug 1130425.
Attachment #8562888 - Flags: review?(rtestard) → review-
(Reporter)

Comment 18

4 years ago
(In reply to Romain Testard [:RT] from comment #17)
> - Clicking the Hello on Firefox opens the current standalone client UI.
> Joining the room will trigger the desktop client UI

I don't understand this requirement. I think what you mean is "clicking the link opens the current standalone client UI. Joining the room will trigger the desktop client UI"

I'd actually suggest a slight difference: Have a different UX if we know that the client is the same one that generated the link. Then its more obvious as to why it is opening in a different window.

> - The room is already opened on the desktop (i.e the link generator clicks
> his own link): joining the room prompts the user an informational message so
> he's aware that the intended use is to share the link with someone else

We could likely do this prior to opening.
(Reporter)

Comment 19

4 years ago
Comment on attachment 8562888 [details]
Screen sharing in Conversation Window

For screensharing this looks reasonable, although it needs to explain which camera streams are shown when screensharing is active (its unclear at the moment as different pics are being used).
Attachment #8562888 - Flags: review?(standard8)
(In reply to Mark Banner (:standard8) from comment #18)
> (In reply to Romain Testard [:RT] from comment #17)
> > - Clicking the Hello on Firefox opens the current standalone client UI.
> > Joining the room will trigger the desktop client UI
> 
> I don't understand this requirement. I think what you mean is "clicking the
> link opens the current standalone client UI. Joining the room will trigger
> the desktop client UI"
> 
OK fixed in the US
> I'd actually suggest a slight difference: Have a different UX if we know
> that the client is the same one that generated the link. Then its more
> obvious as to why it is opening in a different window.
> 
Do you mean a different UX on the standalone client? Are we able to detect this state on the standalone client?

> > - The room is already opened on the desktop (i.e the link generator clicks
> > his own link): joining the room prompts the user an informational message so
> > he's aware that the intended use is to share the link with someone else
> 
> We could likely do this prior to opening.

You mean on the standalone client? i.e not offering the option to join the conversation from the standalone client?
User Story: (updated)
(Reporter)

Comment 21

4 years ago
(In reply to Romain Testard [:RT] from comment #20)
> > I'd actually suggest a slight difference: Have a different UX if we know
> > that the client is the same one that generated the link. Then its more
> > obvious as to why it is opening in a different window.
> > 
> Do you mean a different UX on the standalone client? Are we able to detect
> this state on the standalone client?

It depends on the exact technical implementation, but I think we'd stand a reasonable chance of being able to do this. I'd certainly leave the options open for now, rather than prematurely close them.

> > > - The room is already opened on the desktop (i.e the link generator clicks
> > > his own link): joining the room prompts the user an informational message so
> > > he's aware that the intended use is to share the link with someone else
> > 
> > We could likely do this prior to opening.
> 
> You mean on the standalone client? i.e not offering the option to join the
> conversation from the standalone client?

Yep (same as above).
Attachment #8562888 - Attachment is obsolete: true

Updated

4 years ago
User Story: (updated)

Updated

4 years ago
backlog: Fx38+ → backlog+
Rank: 35 → 31
Flags: firefox-backlog+

Updated

4 years ago
Severity: enhancement → normal
Rank: 31 → 23
Priority: P3 → P2

Updated

4 years ago
Rank: 23 → 26

Comment 22

4 years ago
moved down as the Android work was put as higher than this - so it doesn't bit rot and now we're seeing 15% of link clickers coming from Android.
Rank: 26 → 29

Updated

4 years ago
User Story: (updated)

Updated

4 years ago
Rank: 29 → 24
(Reporter)

Comment 23

4 years ago
RT/Sevaan: Where are the final UX designs for this bug?
Flags: needinfo?(sfranks)
Flags: needinfo?(rtestard)
Bug 1130425 is a dependent bug which defined the UX:
https://bug1130425.bugzilla.mozilla.org/attachment.cgi?id=8569948
Flags: needinfo?(rtestard)
Flags: needinfo?(sfranks)
(Reporter)

Updated

4 years ago
Duplicate of this bug: 1142042

Updated

4 years ago
Duplicate of this bug: 1152008

Updated

4 years ago
Summary: [meta] Firefox should handle Hello link-clicks in the conversation window → [meta] Firefox should handle Hello link-clicks in the conversation window (aka "Link clicker parity")

Updated

4 years ago
Depends on: 1154251

Updated

4 years ago
Rank: 24 → 29
(Reporter)

Updated

4 years ago
No longer blocks: 1012743

Updated

3 years ago
Blocks: 1145864

Updated

3 years ago
Rank: 29 → 28
I am lowering the priority since it is a higher priority to prevent link generators from clicking their own links: bug 1154251
Priority: P2 → P3
(Reporter)

Comment 28

2 years ago
Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.