Closed
Bug 1066019
Opened 10 years ago
Closed 8 years ago
[meta] Firefox should handle Hello link-clicks in the conversation window (aka "Link clicker parity")
Categories
(Hello (Loop) :: Client, defect, P3)
Hello (Loop)
Client
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
backlog | backlog+ |
People
(Reporter: standard8, Unassigned)
References
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 file)
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)
Comment 1•10 years ago
|
||
Intention confirmed ;)
Yes, the goal is to have links go straight to the conversation window UI within Firefox.
Flags: needinfo?(dhenein)
Reporter | ||
Updated•10 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•10 years ago
|
Reporter | ||
Updated•10 years ago
|
User Story: (updated)
Reporter | ||
Updated•10 years ago
|
Whiteboard: [needs breakdown when we get to it] → [needs breakdown revising when we get to it]
Comment 3•10 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•10 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 | ||
Comment 5•10 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•10 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•10 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•10 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)
Comment 8•10 years ago
|
||
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)
Comment 10•10 years ago
|
||
Based on roadmap discussions 2 weeks ago, this is a Fx39 item
backlog: Fx37+ → Fx39?
Reporter | ||
Updated•10 years ago
|
User Story: (updated)
Reporter | ||
Updated•10 years ago
|
User Story: (updated)
Updated•10 years ago
|
User Story: (updated)
Comment 12•10 years ago
|
||
RT is going to add info
backlog: Fx39? → Fx38+
Rank: 35
Flags: needinfo?(rtestard)
Priority: P2 → P3
Comment 13•10 years ago
|
||
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)
Comment 14•10 years ago
|
||
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)
Comment 15•10 years ago
|
||
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.
Comment 17•10 years ago
|
||
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•10 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•10 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)
Comment 20•10 years ago
|
||
(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•10 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).
Updated•10 years ago
|
Attachment #8562888 -
Attachment is obsolete: true
Updated•10 years ago
|
User Story: (updated)
Updated•10 years ago
|
backlog: Fx38+ → backlog+
Rank: 35 → 31
Flags: firefox-backlog+
Updated•10 years ago
|
Severity: enhancement → normal
Rank: 31 → 23
Priority: P3 → P2
Updated•10 years ago
|
Rank: 23 → 26
Comment 22•10 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•10 years ago
|
User Story: (updated)
Updated•10 years ago
|
Rank: 29 → 24
Reporter | ||
Comment 23•10 years ago
|
||
RT/Sevaan: Where are the final UX designs for this bug?
Flags: needinfo?(sfranks)
Flags: needinfo?(rtestard)
Comment 24•10 years ago
|
||
Bug 1130425 is a dependent bug which defined the UX:
https://bug1130425.bugzilla.mozilla.org/attachment.cgi?id=8569948
Flags: needinfo?(rtestard)
Updated•10 years ago
|
Flags: needinfo?(sfranks)
Updated•10 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•10 years ago
|
Rank: 24 → 29
Updated•10 years ago
|
Rank: 29 → 28
Comment 27•9 years ago
|
||
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•8 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
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•