Closed Bug 1084991 Opened 10 years ago Closed 9 years ago

[User story] As a standalone UI link clicker in a room, I can send/receive text messages with the other room participant.

Categories

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

defect

Tracking

(Not tracked)

RESOLVED FIXED
backlog backlog+

People

(Reporter: inscription, Unassigned)

References

Details

(Whiteboard: [Fx40 want][text])

User Story

As a link clicker in a room on the standalone UI, I can send/receive text messages with the other room participant.

* No persistence of text messages after when the last person leaves the conversation (if A messages B, B leaves and then rejoins, the message is still there so long as A has stayed in the conversation)
* Messages can only be exchanged when in a room.
* In-room text message history available for the duration of the room

Acceptance criteria:
* When in a room alone:

**[P1]The chat edit box is disabled until someone else joins 

**[P1]If the room has contextual information, the contextual info appears in a speech bubble originating from the left


* When in a room with someone else:

**[P1]If the user has not used chat yet in this session, an indication "Type here..." appears in the chat edit box. This disappears once the user selects the chat area and won't appear again for the rest of the session once the user validates his first message sent

**[P1] If the room has contextual information, the contextual info appears in a speech bubble originating from the right for the link generator (a speech bubble originating from the left for the link clicker).

**[P1] New messages appear in speech bubbles with smooth transitions, older messages scroll up. The speech bubble originates from the right for the user's messages and from the left for messages from the link generator. A sound accompanies new messages received

**[P2] Every minute a timestamp is inserted next to a speech bubble. The timestamp only appears once per minute and any subsequent messages during that minute do not have a timestamp

**[P2] In the chat edit box a button allows inserting an emoticon
***Mousing over the button brings a tooltip
***Clicking the emoticon button opens a small pop up with a selection of Emoticons users can insert into their text
***Selecting an emoticon from the pop up adds the emoticon to the chat edit box

**[P2]Entering a URL manually renders the URL in a URL block (if this requires fetching the page title and favicon, a loader indicator gets displayed / If there is an error fetching the page information, then the URL is displayed in an empty URL block)

**[P3] Mousing over any URL block (includes the context block) will slightly change its color and make appear the Bookmark icon
*** Left clicking a URL block opens the URL in a new tab
*** Right clicking a URL block opens the contextual menu
*** Using the Bookmark icon will cause the URL to be added to the bookmarks

**[P3] A menu at the top of the chat window allows to:
*** Filter text out so that only URLs appear
*** Filter URLs out so that only text appears
*** Bookmark all URLs

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141013200257 Actual results: Firefox Hello have currently audio and video support. Expected results: It would be good if there were also a chat system. So it would be a complete alternative to Skype/Hangout for 1 to 1 communications.
Marcos and I were just noting how this would be an awesome feature addition.
Status: UNCONFIRMED → NEW
Component: General → Client
Ever confirmed: true
Product: Mozilla Services → Loop
QA Contact: anthony.s.hughes
backlog: --- → Fx40+
Priority: -- → P2
I would be glad to contribute to this, but I don't really know how. I've found this github repo (https://github.com/mozilla/loop-client) but it seems to be a clone of the main mercurial one (which I can't find). Is there a contributor guide somewhere ?
Flags: needinfo?(anthony.s.hughes)
I'm not sure which developer is available to mentor this bug. Maire, do you know?
Flags: needinfo?(anthony.s.hughes) → needinfo?(mreavy)
This bug is going to have to wait for a couple of things to happen before the actual implementation work can happen. First, we need to wait for the next version of the TokBox toolkit, to gain access to the PeerConnection DataChannels. There's some lead-time on this, and we expect to have this sometime in the Firefox 40 timeframe. Second, we need to get the in-room chat UX designs from Sevaan -- this is going to be a very UX-heavy feature. This isn't currently in any of the sprints (in fact, I don't think we have a bug open for it yet), but that's pretty sensible when you consider the timeframe for the toolkit that will allow us to do this. Since this work is effectively on hold until those two things happen, I believe Maire should be able to help you find some "good first bugs" in the Hello/Loop codebase. (In reply to inscription from comment #2) > I would be glad to contribute to this, but I don't really know how. I've > found this github repo (https://github.com/mozilla/loop-client) but it seems > to be a clone of the main mercurial one (which I can't find). It's part of the full Firefox tree, under "browser/components/loop". Since most of this is front-end code rather than platform work, we're using the fx-team tree (instead of mozilla-inbound).
Abr is the best person to coordinate with on this bug, and I'm happy to help find "good first bugs" for a new contributor. To incruption@stymaar.fr: The best thing to do is join #loop on mozilla's irc. I and others can help you find bugs that would be a good match for your skill set and for what you'd enjoy doing. I'm mreavy in irc. Many of us are taking off during the holiday (from 22 Dec to 4 Jan), but after that time, it should be easy to get a hold of us in #loop.
Flags: needinfo?(mreavy) → needinfo?(inscription)
combining with the PM bug with the user story since this bug has history. duplicating and closing the other bug. We are working to have the ability to do this (per Adam's comments) - but need a few pre-requisits.
User Story: (updated)
Summary: Firefox Hello should include a message chat. → [User story] As a link clicker in a room, I can send/receive text messages with the other room participant.
Blocks: 1108892
need UX and the SDK to be actionable. but a high feature desired towards Fx40
backlog: Fx40+ → backlog+
Rank: 40
Priority: P2 → P4
Whiteboard: [Fx40 want]
Flags: qe-verify+
Flags: firefox-backlog+
User Story: (updated)
Flags: needinfo?(inscription)
User Story: (updated)
Summary: [User story] As a link clicker in a room, I can send/receive text messages with the other room participant. → [User story] As a standalone UI link clicker in a room, I can send/receive text messages with the other room participant.standalone UI
Summary: [User story] As a standalone UI link clicker in a room, I can send/receive text messages with the other room participant.standalone UI → [User story] As a standalone UI link clicker in a room, I can send/receive text messages with the other room participant.
Whiteboard: [Fx40 want] → [Fx40 want][chat]
Whiteboard: [Fx40 want][chat] → [Fx40 want][text]
We need to address how we best handle the display of the chat area for link clickers given that the same link clicker server will address both desktop client users on GA without chat until Fx40 and desktop client users on Fx40 Nightly/Aurora/Beta who will have a chat functionality. After a brief chat with Standard8 it seems the best way to handle this is to display the chat area only once the desktop client user connects if he has a chat capability. Sevaan, how would it work with your designs on the clicker side? It feels we could just hide the text input area and keep all the rest as is for this scenario?
Flags: needinfo?(sfranks)
Yes, my latest revision to the visual has the text input box hidden. It will have to slide up when the user joins the conversation. Will be posting it, along with other changes, shortly to Bug 1138453.
Flags: needinfo?(sfranks)
Depends on: 1162991
Depends on: 1168829
Depends on: 1168841
Depends on: 1168848
All chat work has been designed for the visual refresh. But since that is coming later, I am posting a couple mockups showing what chat should look like in the old linkclicker layout.
Depends on: 1171940
Rank: 40 → 12
Priority: P4 → P1
No longer depends on: 1171940
This is now fixed, it is expected to be deployed on Monday (29th).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: