Closed Bug 1209713 Opened 9 years ago Closed 9 years ago

[meta] User journey focussed on web sharing

Categories

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

defect

Tracking

(relnote-firefox 45+)

RESOLVED FIXED
Iteration:
45.3 - Dec 14
Tracking Status
relnote-firefox --- 45+

People

(Reporter: RT, Unassigned)

References

Details

(Keywords: feature, user-doc-needed, Whiteboard: [web sharing, journey])

User Story

As a Desktop client user, I want to initiate a sharing session as simply as possible.

UX:
http://people.mozilla.org/~sfranks/Hello/Firefox%20Hello%20Link%20Generator.png
http://people.mozilla.org/~sfranks/Hello/Firefox%20Hello%20Link%20Clicker.png

Acceptance criteria:
P1 (MVP):
- Panel: Remove availability status footer
- Panel: Remove contact list
- Panel: Remove direct calls
- Panel: Remove panel tab headers
- Panel: New panel layout
- Panel: Change panel button action
- Persistent bar (may not be an infobar) when sharing, infobars can be stacked if there are more than one.
- Panel: Selecting a recent share enables sharing (opens a new tab pointing to the room context URL and enables sharing)
- Panel: Add "Submit feedback" option to panel gear icon options
- Conversation Window: Remove gear icon
- Conversation window: Remove share icon
- Implement context URL change rules when sharing:
--- On room creation, the active tab URL becomes the room context URL 
--- The room context URL changes when the user accesses a different URL whilst sharing is active (newly accessed tab URL becomes context URL)
--- The room context URL changes when the user types in a new URL whilst sharing is active (newly entered tab URL becomes context URL)
--- The room context URL changes when the user switches tabs (new active tab URL becomes context URL)
- Conversation window: Join always audio/face muted first (also do not turn on the camera light) - Please note that this depends on having a TokBox SDK capability in place which is not available today, RT investigating with TokBox the timelines but this will likely have to be discarded from the initial scope
- Clicker UI: Join upon reaching Hello URL (audio/face muted)
- Panel: Stop sharing from the panel

P2:
- Panel: Editing a share name from the panel
- Infobar: Terminate sharing through infobar button when sharing
- Door hanger: Terminating the sharing session prompts the user to assign a share name
- Infobar: Style sharing infobar to blue
- Panel: Share panel opens after creation of a share
- Conversation window: Style conversation window title bar to blue
- Clicker UI: See a preview of the shared website
- Clicker UI: Video view of remote party at the top
- Clicker UI: Pop-up about shared content and new tile placement when waitin alone

P3:
- Panel: Delete rooms directly with option to undelete
- Infobar: Pause/Unpause sharing
- Panel: Stop sharing from the panel
- Conversation window: Change room name and favicon in conversation window title bar as I switch tabs
- Conversation window: Animation to slide-up the conversation window
- Clicker UI: Clickable name of remote partie's shared tab with favicon on page footer
- Clicker UI: Leave room using button at bottom left of the page
- Clicker UI: Clickable name of remote party's shared tab with favicon in the chat history
- Clicker UI: Loading indicator on shared page changed
- Clicker UI: Pop-up when leaving the session

Next step on that bug: Bug breakdown
No description provided.
User Story: (updated)
Depends on: 1179163
Rank: 22
Priority: -- → P1
User Story: (updated)
Whiteboard: [web sharing]
User Story: (updated)
User Story: (updated)
User Story: (updated)
User Story: (updated)
Depends on: 1211351
User Story: (updated)
User Story: (updated)
Rank: 22 → 21
(Commenting on User Story) > - Conversation window: Join always audio/face muted first (also do not turn > on the camera light) - Please note that this depends on having a TokBox SDK > capability in place which is not available today, RT investigating with > TokBox the timelines but this will likely have to be discarded from the > initial scope That's not quite right. I think we should be able to do audio + face muted join (although I've not explicitly tried it). However, when turning on items, we have to do a permission request to turn on audio+video at the same time, even if we're only enabling audio.
Thanks Mark, does that mean that the camera light would be turned on. Mike, can you please confirm if you support the scenario where a user joins a room with audio only? I recall we discussed that joining without audio and video is not supported although is audio only supported (whilst not turning on the camera light)?
Flags: needinfo?(msander)
Rank: 21 → 19
Priority: P1 → P2
Whiteboard: [web sharing] → [web sharing, journey, dev breakdown]
Rank: 19 → 15
Assignee: nobody → standard8
User Story: (updated)
Depends on: 1212074
Depends on: 1212079
No longer depends on: 1179163
Depends on: 1212083
Depends on: 1212331
Depends on: 1212338
Depends on: 1212340
Depends on: 1212357
Depends on: 1212361
Depends on: 1213844
Depends on: 1213848
Depends on: 1213851
Depends on: 1213855
(In reply to Romain Testard [:RT] from comment #2) > Thanks Mark, does that mean that the camera light would be turned on. > > Mike, can you please confirm if you support the scenario where a user joins > a room with audio only? > I recall we discussed that joining without audio and video is not supported > although is audio only supported (whilst not turning on the camera light)? Our SDK does not support starting with only an audio stream (no camera permission/light). You can start a conversation with audio + face muted but it will ask for camera permission and turn the light on.
Flags: needinfo?(msander)
Depends on: 1213906
Depends on: 1213984
Depends on: 1214214
Depends on: 1214215
Depends on: 1214582
Depends on: 1214590
User Story: (updated)
Depends on: 1215176
Depends on: 1215570
Depends on: 1215593
Depends on: 1215612
Depends on: 1216918
Depends on: 1217412
No longer depends on: 1213906
Depends on: 1219005
Depends on: 1219158
Depends on: 1219600
Depends on: 1219740
No longer depends on: 1215176
Depends on: 1220095
Depends on: 1221168
Assignee: standard8 → nobody
Whiteboard: [web sharing, journey, dev breakdown] → [web sharing, journey]
Depends on: 1221732
Depends on: 1222034
Depends on: 1225054
Iteration: --- → 45.2 - Nov 30
Priority: P2 → P1
Iteration: 45.2 - Nov 30 → 45.3 - Dec 14
Depends on: 1230058
Depends on: 1230477
Depends on: 1231804
Depends on: 1231808
Depends on: 1231811
Depends on: 1231909
Depends on: 1216679
Depends on: 1232001
Added to the release notes with "Hello new user journey" as wording. It would be nice to have a user doc link
Please follow bug 1230477 for the SUMO page implementation The placeholder link is https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/cobrowsing
Depends on: 1234183
Depends on: 1237587
This has now been landed. Follow-up bugs will be tracked individually.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Is there any discussion to learn about the rationale on why it is better to always share all browser tabs on Hello rather than picking when I want to share and when not? It feels more like sharing the whole browser rather than tabs, since it's always following.
You need to log in before you can comment on or make changes to this bug.