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)

Product:
Hello (Loop)
Component:
Client
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Blocking Flags:
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)
Depends on: 1000202
Depends on: 1035289
Intention confirmed ;) Yes, the goal is to have links go straight to the conversation window UI within Firefox.
Flags: needinfo?(dhenein)
Summary: [meta] Desktop Client should handling link-clicks in the conversation window → [meta] Desktop Client should handle link-clicks in the conversation window
Depends on: 1000129, 1019462, 1019465
User Story: (updated)
Whiteboard: [needs breakdown when we get to it] → [needs breakdown revising when we get to it]
Depends on: 1069031
Depends on: 1083160
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?
(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.
No longer depends on: 1069031
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]
Summary: [meta] Desktop Client should handle link-clicks in the conversation window → [meta] Firefox should handle Hello link-clicks in the conversation window
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
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?
User Story: (updated)
User Story: (updated)
Depends on: 1130425
User Story: (updated)
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)
Attached image Screen sharing in Conversation Window (obsolete) —
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.
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-
(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.
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)
(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
User Story: (updated)
backlog: Fx38+ → backlog+
Rank: 35 → 31
Flags: firefox-backlog+
Severity: enhancement → normal
Rank: 31 → 23
Priority: P3 → P2
Rank: 23 → 26
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
User Story: (updated)
Rank: 29 → 24
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)
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")
Depends on: 1154251
Rank: 24 → 29
No longer blocks: 1012743
Blocks: 1145864
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
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.

Attachment

General

Creator:
Created:
Updated:
Size: