[UX] Link clicker parity on Firefox

RESOLVED FIXED

Status

Hello (Loop)
Client
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: RT, Assigned: sevaan)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [UX])

User Story

This is a request to design the experience for handling clicking of rooms links using the desktop client UI:
- Joining the room, 2 options to be investigated:
Option 1 - Clicking the Hello URL opens the conversation window with an option to join the conversation (if Firefox was closed before what tab is being displayed?)
Option 2 - Clicking the Hello URL 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: need new desktop client UX for expired/invalid link
- In-room experience alone: need new UX (the link clicker shuld not be able to rename the room, copy or share the room URL)
- In-room experience with another peer: per current desktop client UX
- Feedback form: per current desktop client UX
- Receiving shared screen: need UX update
- Accessing shared context: per current desktop client UX

Attachments

(1 attachment, 6 obsolete attachments)

Comment hidden (empty)
(Reporter)

Updated

3 years ago
Blocks: 1082944
(Reporter)

Updated

3 years ago
User Story: (updated)
I think I would prefer option 1 - as it feels like there's less to manage, and less to expose.

I believe Adam was thinking about how to do some of this from a technical perspective, so NI to him, as I think that might influence our options a bit.
Flags: needinfo?(adam)
(Reporter)

Updated

3 years ago
Blocks: 1066019
User Story: (updated)

Comment 2

3 years ago
I think where we ended up after some discussion with the desktop folks was that we would likely set up a WebChannel (https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/WebChannel.jsm) for hello.firefox.com. The standalone client would then look for the presence of this channel; and, if it's there, dispatch the conversation information (probably just the token) to the Loop desktop client.

The timing of this dispatch would vary depending on the desired UX. The only restriction that comes to mind is that we're going to end up with the hello.firefox.com page loading into a tab somewhere when users click on a link: this approach does not lend itself to simply opening the desktop Loop client without first having something served from hello.firefox.com in a tab somewhere. We could try to hack around this by doing things like "window.history.back()", but that's a very inelegant user experience.
Flags: needinfo?(adam)
(Reporter)

Comment 3

3 years ago
Sevaan, what are your thoughts there?
It seems to me that Option 1 is also more elegant.
Flags: needinfo?(sfranks)

Comment 4

3 years ago
(In reply to Romain Testard [:RT] from comment #3)
> Sevaan, what are your thoughts there?
> It seems to me that Option 1 is also more elegant.

I would need some assistance from people on the Desktop team to understand how we might do this. As described, it is not compatible with the WebChannel approach I outline above.
(Reporter)

Comment 5

3 years ago
A few comments after discussing this in a meeting:
- we may want to go with Option 2 (Clicking the Hello URL opens the current standalone client UI. Joining the room will trigger the desktop client UI) if this is the only way to get the feature in Fx39
- I am removing "Initiating sharing" from the success criteria list since it won't be a "must have" initially (the ability to provide a better UI is good enough to justify releasing this without providing the link clicker with the ability to share.
User Story: (updated)
(Assignee)

Comment 6

3 years ago
Ah, here are Option 1 and 2. I was looking for them since they were referenced in another bug.

Option 1 is obviously preferred. If :abr can look into this with the Desktop team to determine feasibility, that would be awesome.

If we have to do Option 2, I would suggest we create a different page just for Firefox users, rather than the whole Link Clicker UI. It could be a little standalone page with a join button and the contextual information and would be less confusing than seeing a completely different UI appear that the user never uses.
Flags: needinfo?(sfranks)
(Reporter)

Updated

3 years ago
Whiteboard: [UX]
(Assignee)

Comment 7

3 years ago
Created attachment 8566217 [details]
Parity - Link Clickers in Firefox

Veered away from user story where links are opened in current LinkClicker UI. I think it is better to create a custom page for In-Firefox link clicks.
Assignee: nobody → sfranks
Status: NEW → ASSIGNED
Attachment #8566217 - Flags: review?(standard8)
Attachment #8566217 - Flags: review?(rtestard)
(Assignee)

Comment 8

3 years ago
Created attachment 8566219 [details]
Parity - Link Clickers in Firefox

Removed invisible background in the image.
Attachment #8566217 - Attachment is obsolete: true
Attachment #8566217 - Flags: review?(standard8)
Attachment #8566217 - Flags: review?(rtestard)
Attachment #8566219 - Flags: review?(standard8)
Attachment #8566219 - Flags: review?(rtestard)
(Assignee)

Comment 9

3 years ago
Created attachment 8566227 [details]
Parity - Link Clickers in Firefox (Update #1)

Sorry for the rapid-fire updates. Included Link Clicker clicking on own link while in active conversation.
Attachment #8566219 - Attachment is obsolete: true
Attachment #8566219 - Flags: review?(standard8)
Attachment #8566219 - Flags: review?(rtestard)
Attachment #8566227 - Flags: review?(standard8)
Attachment #8566227 - Flags: review?(rtestard)
(Reporter)

Comment 10

3 years ago
Thanks Sevaan, my comments:
- Can we add a help link on the web page?
- Can we add a beta flag?
- The scenario "User clicks on own link while conversation window is opened" seems to add non necessary complexity? The link clicker can invite someone from the desktop client UI so should we not rather focus on getting him to find the desktop client UI and use controls from there?
- I like the use of the Hello logo although I know that Aracdio was keen to rather use Firefox branding. I NI Arcadio to check if he's OK with your proposal.
- What is the sub option in the screen sharing notification?
Flags: needinfo?(alainez)
(Assignee)

Comment 11

3 years ago
Created attachment 8566542 [details]
Parity - Link Clickers in Firefox (Update #2)

(In reply to Romain Testard [:RT] from comment #10)

> - Can we add a help link on the web page?
> - Can we add a beta flag?

Done.

> - The scenario "User clicks on own link while conversation window is opened"
> seems to add non necessary complexity? The link clicker can invite someone
> from the desktop client UI so should we not rather focus on getting him to
> find the desktop client UI and use controls from there?

You are right. I just removed the invite buttons and left the "You are already in this conversation" message. I don't think we need to tell the user anything extra.

> - I like the use of the Hello logo although I know that Aracdio was keen to
> rather use Firefox branding. I NI Arcadio to check if he's OK with your
> proposal.

Can be replaced with Firefox logo if necessary.

> - What is the sub option in the screen sharing notification?

Drop-down for sharing tabs/windows as per MVP spec. Can remove if you want.
Attachment #8566227 - Attachment is obsolete: true
Attachment #8566227 - Flags: review?(standard8)
Attachment #8566227 - Flags: review?(rtestard)
Attachment #8566542 - Flags: review?(standard8)
Attachment #8566542 - Flags: review?(rtestard)
Attachment #8566542 - Flags: review?(philipp)

Comment 12

3 years ago
There is a separate conversation happening around the link clicker experience logo. The brand team has suggested using the Firefox logo for people on non-firefox browsers and using the Hello logo wordmark for Firefox browser users. 

We currently use only the Firefox logo on the link clicker page. For consistency, I would use that logo here. I will circle back with the brand team and try to get closure. 

What's timing to close this bug?
Flags: needinfo?(alainez)
(Assignee)

Comment 13

3 years ago
(In reply to alainez from comment #12)
> There is a separate conversation happening around the link clicker
> experience logo. The brand team has suggested using the Firefox logo for
> people on non-firefox browsers and using the Hello logo wordmark for Firefox
> browser users. 
> 
> We currently use only the Firefox logo on the link clicker page. For
> consistency, I would use that logo here. I will circle back with the brand
> team and try to get closure. 
> 
> What's timing to close this bug?

Please keep in mind this would be exclusively seen by Firefox users only. The branding would associate it in nicely with the icon in the toolbar. We don't need to be consistent with the Link Clicker UI as Firefox users will never see it.
(Reporter)

Comment 14

3 years ago
> 
> > - What is the sub option in the screen sharing notification?
> 
> Drop-down for sharing tabs/windows as per MVP spec. Can remove if you want.

OK, got it now. Yes agreed it makes sense, let's keep it.
(Reporter)

Updated

3 years ago
Attachment #8566542 - Flags: review?(rtestard) → review+
Comment on attachment 8566542 [details]
Parity - Link Clickers in Firefox (Update #2)

In general this looks good and is clear. Some comments about the UX:

- No need for the "empty conversation" view - conversations always have a title, even if its just the default one.
- It might be worth noting if the changes in colour scheme can apply to all existing views (e.g. non-supported platform/browser)
- It would be useful from an engineering perspective to specify the layout of the streams when the conversation window is popped out.

I think we should see if we can get an investigation going soon on desktop to prototype the technical route and confirm we can achieve this UX.
Attachment #8566542 - Flags: review?(standard8)
Looks good!
Just one question before I r+ this: what would be shown in the main browser window behind the chat window when it opens?
Flags: needinfo?(sfranks)
(Assignee)

Comment 17

3 years ago
Created attachment 8569924 [details]
Parity - Link Clickers in Firefox (Update #3)

(In reply to Philipp Sackl [:phlsa] please use needinfo to make me respond from comment #16)
> Looks good!
> Just one question before I r+ this: what would be shown in the main browser
> window behind the chat window when it opens?

I've added another state that shows what happens. The button state for "Join the Conversation" is disabled and the text changes to "Have fun!"

Matej, are you okay with "Have fun!"? Other options: "Enjoy!" "Enjoy your Conversation!"
Attachment #8566542 - Attachment is obsolete: true
Attachment #8566542 - Flags: review?(philipp)
Flags: needinfo?(sfranks) → needinfo?(matej)
(Assignee)

Comment 18

3 years ago
Created attachment 8569926 [details]
Link Clickers in Firefox (Update #3.1)

Sorry, image had a weird transparent bit. Uploaded corrected version.
Attachment #8569924 - Attachment is obsolete: true
Attachment #8569926 - Flags: ui-review?(philipp)
(In reply to Sevaan Franks [:sevaan] from comment #17)
> Created attachment 8569924 [details]
> Parity - Link Clickers in Firefox (Update #3)
> 
> (In reply to Philipp Sackl [:phlsa] please use needinfo to make me respond
> from comment #16)
> > Looks good!
> > Just one question before I r+ this: what would be shown in the main browser
> > window behind the chat window when it opens?
> 
> I've added another state that shows what happens. The button state for "Join
> the Conversation" is disabled and the text changes to "Have fun!"
> 
> Matej, are you okay with "Have fun!"? Other options: "Enjoy!" "Enjoy your
> Conversation!"

I like "Enjoy your conversation," as long as it's not too long.
Flags: needinfo?(matej)
(Assignee)

Comment 20

3 years ago
Created attachment 8569948 [details]
Link Clickers in Firefox (Update #3.2)

> I like "Enjoy your conversation," as long as it's not too long.

Shouldn't be an issue as the button can expand.
Attachment #8569926 - Attachment is obsolete: true
Attachment #8569926 - Flags: ui-review?(philipp)
(Assignee)

Updated

3 years ago
Attachment #8569948 - Flags: ui-review?(philipp)
Comment on attachment 8569948 [details]
Link Clickers in Firefox (Update #3.2)

Thumbs up!
Attachment #8569948 - Flags: ui-review?(philipp) → ui-review+
(Assignee)

Updated

3 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Sevaan: I'm currently looking at a breakdown for this. Some questions:

- I failed to ask before - these UX screens show the old "call-based link-clicker" UI before joining the room. Is this something we're intending to go back to, or is that just something old on these designs?

- Is it OK if we don't detect the "Full conversation" state until entering the conversation window? To do so outside of the conversation window is going to be technically difficult.
Flags: needinfo?(sfranks)
(Assignee)

Comment 23

3 years ago
(In reply to Mark Banner (:standard8) from comment #22)
> Sevaan: I'm currently looking at a breakdown for this. Some questions:
> 
> - I failed to ask before - these UX screens show the old "call-based
> link-clicker" UI before joining the room. Is this something we're intending
> to go back to, or is that just something old on these designs?

Hi Mark, for now we are going to use the page in the tabs rather than just opening up the conversation directly.

> - Is it OK if we don't detect the "Full conversation" state until entering
> the conversation window? To do so outside of the conversation window is
> going to be technically difficult.

How do you see this working? User clicks the Join button, the conversation window opens, then closes and the page in the background refreshes to show the Room Full message?
Flags: needinfo?(sfranks)
(Reporter)

Comment 24

3 years ago
> > - Is it OK if we don't detect the "Full conversation" state until entering
> > the conversation window? To do so outside of the conversation window is
> > going to be technically difficult.
> 
> How do you see this working? User clicks the Join button, the conversation
> window opens, then closes and the page in the background refreshes to show
> the Room Full message?

I just realized that "Full conversation" won't be a valid case since when a conversation is full the generator is already in the room.
So I propose we don't address the "conversation full" scenario at all since it will already be handled by the "You're already in the conversation" prompt. Agreed?
You need to log in before you can comment on or make changes to this bug.