Speccing out a full page chat plugin

I am in the early planning stages for a chat plugin that fulfills the goals mentioned here. When the initial version of the plugin is created I will create a new topic, however this topic is a good place to think about how this plugin will work.

At this stage I'm thinking the plugin will have the following features.

1. Chat lives in it's own route, rather than in a shoutbox (Babble) or messagebox (Quick Messages). One question here is whether the header is present in this view. Compare Stack Exchange Chat, in which the normal site header is not present. Personally I think it should be, as it will allow normal site navigation and search, and also make chat feel like part of the 'app', even though it is in a separate route.

2. A 'presence' feature, showing online members and activity such as typing.

3. The compose input is ever-present in the UI, like in Babble or Quick Messages.

4. In terms of chat 'Channels' one thought I have is that having an entirely separate hierarchy may be a bit confusing. I'm thinking it would be best to tie the chat channels into the existing Discourse hierarchy in some way. Perhaps the following:

   • A channel that corresponds with / is linked to the 'All categories' topic list discovery (a 'general channel').

   • A channel that corresponds with / is linked to each category.
   • A channel that corresponds with / is linked to each tag.
   • A channel that corresponds with / is linked to each topic? This may be going to far as it may start to deter people from creating posts in a topic. For example having 'I'm having a problem with X...' kind of post is often useful in a topic because if you (the reader) are having the same problem, you know you're on the right track to find the answer. If this kind of question is posted in chat, a reader is less likely to come across it.

5. A feature to turn a chat message or group of messages into a topic. If the approach in '4' is taken, this could flow quite nicely, e.g. a chat in the 'Feature' category channel gets turned into a topic in the 'Feature' category.

In terms of where the channels would be accessed in the UI this depends on things like '1' and '4'. One potential way to do this would be to put a button in the topic list header. Like the other buttons in the topic list header it would be context dependent, e.g. it would toggle the chat for the discovery context you're currently looking at, e.g. All Categories, 'Feature' category, 'community-management' tag etc.

Screenshot at Aug 29 10-18-12.png1166x237 33.9 KB

Clicking that button would turn the topic list for that context into a chat stream with a compose at the bottom.

I'm not quite sure how channels with users or groups of users would work yet. One thing that has to be figured out in this respect is how 'user/group channels would be distinct from the existing 'user/group messages'. One way to do this would be to just have a chat that corresponds to each private message topic, however you run into a similar kind of issue I referred to above in the context of a chat channel for every topic, namely it's not clear how the 'chat' and 'topic' post streams should interrelate. Should all chat messages also appear on the 'topic' version of the private message? I think it would be best to keep 'private messages' and 'private channels' separate.

The other question regarding private channels is where they would appear in the UI. The 'default' would be as a separate view in the user profile, next to messages.

Screenshot at Aug 29 10-16-06.png1128x146 97.8 KB

These are all just preliminary ideas. Would be keen to hear others' thoughts on how 'community chat' might be implemented.

'4' and '5' are both on the very top of my Discourse chat wishlist, but I don't think they're critical for a v1.0. If anything, '5' should come before '4'.

meta.discourse.org is the most natural place to test the prototype of such a chat (as we did with Babble), and the sub-community most amenable to chat in Meta is the #lounge (which I think should be expanded to include user types like serial contributors, but that's a different topic). And all we need for that is one chatroom. I hope we can agree that this is the MVP.

Will gladly talk through these other designs on the side though!

Agreed. Linking to tags could get hairy though so I think "all categories" and "individual categories" would be best for starters. DropBox's Zulip chat app has an interesting concept of "threaded group conversations", and it's not the scary kind of threading that we Discoursians despise:

important-things.png844x469 32.1 KB

I don't have a perfect solution in mind yet, but I definitely think this is a solvable problem. That being said, figuring out ways to incorporate tag/topic-specific discussions is "next-gen" territory as far as I'm concerned.

I think Facebook Messages is a great example of a chat/pm hybrid.

2764.png730x472 147 KB

It's always the same conversation, but in different gears. And when a user is posting a series of uninterrupted replies, maybe we could automatically merge them together.

Discourse PMs are already super powerful; they're basically what I always wanted Google Wave to be. I'm not keen on adding a competing conversation stream into the mix. All we need is a few more "live" features built into PMs, like presence info and opt-in quick-reply.

Right, so the mvp would include the following:

1. A chat topic type. Personally, I think we should add a new Topic Archetype: chat, adding to the existing archetypes: regular, private_message and banner. A significant difference in the backend between Babble and Quick Messages is that @gdpelican has created a more custom topic and post architecture, whereas I have largely used the existing architecture and just distinguished quick messages from normal private messages via a custom_field. Neither of us took the route of adding a new topic archetype, but considering that we may want this chat plugin to integrate closely with various pieces of existing Discourse logic, I think a new archetype is the way to go. Before we start we should sort out our thinking here. Some notes about the chat topic archetype:
   • It will need to be entirely excluded from discovery streams and normal topic view.
   • There will need to a restriction on how many can be created for each category (i.e. 1).

2. An auto-sizing single line composer with emoji, markdown and support for attaching pictures. This could be either component-based (quick messages) or widget-based (babble). This is relatively plug and play from our existing work.

3. Override the default rate limiter for posts in chat topics. Equivalent code in quick messages. We will need a rate limiter, the question is how low it is set: 1 second?

4. Remove or significantly increase the time-based limits for posts in chat topics. Equivalent code in quick messages. Do we want any time-base limits on chat messages?

5. Remove or significantly reduce the maximum length for posts in chat topics. Equivalent code in quick messages. This is a key difference between chat and long form discussion. Personally, I don't think there should be any length requirement for chat posts.

6. Remove or alter the check for duplicate content for posts in chat topics. Equivalent code in quick messages.

7. Remove or alter the check for whether the post content is sufficiently 'descriptive' (I haven't done this in quick messages). Discourse code.

8. A widget-based (babble) or component-based (quick messages) post stream. Both Babble and Quick Messages use the existing postStream model for topics. This is relatively plug and play from our existing work.

9. Post actions on posts in the chat postStream: edit and delete. This exists in widget form in Babble. If we go the component route, it should be relatively easy to create equivalent components that leverage the existing postStream functionality.

10. Add a new category sub-route for chat, toggled by a setting in the category settings. User access to this route would be via a button in the category discovery UI. Like Unread, the button would include the number of unread chat messages.

11. Tweak the notifications produced by the chat topic to:

    • Visually distinguish them for the user
    • Route the user to the right place (i.e. the category chat stream rather than a topic).

12. Prevent chat topics from producing email alerts. While we may want to add email alerts about chat in later versions, they should probably be entirely occluded for the MVP.

I agree. I basically copied Facebook Messages' approach for quick messages, however I focused on the message menu and pop-up chat-boxes. For this plugin we could start with the full page part of Facebook Messages and perhaps add the menu and pop-up chat-boxes later. In terms of the MVP I'm thinking that we should not include any private chat work.

I've gotten a bit of a start on this, which is up on the full-page-chat branch on the babble repo.

Here is a screenshot: (it's not that pretty yet )

Screen Shot 2016-09-21 at 3.50.46 PM.png1252x840 74.9 KB

In response to the MVP prompts:

1. A chat topic type: I'm happy to move to a 'chat' archetype if it's necessary.
2. Autosizing single line composer: This is done with the exception of adding uploads. Uploads may be out of scope for this MVP, but would be happy to have them again.
3. Override default rate limiter: Babble ignores rate limits at the moment, so we'll want to put one in there. One per second sounds good.
4. Remove or significantly increate time-based limits for posts: We'll have to add this (if we can repro it happening)... I'm surprised I never heard feedback about this one, actually.
5. Remove or significantly reduce the maximum length for posts in chat topics: This should be easy to add
6. Remove check for duplicate content: Babble does this
7. Remove or alter check for 'descriptive' posts: Babble does this
8. A post stream: I think the post stream is Good Enough for this iteration (although things will get hairy around searching through history and such, and we will likely want to revisit it at some point)
9. Post edit and delete: These work for Babble
10. Add category sub-route: I think I agree with this approach, but wonder about the unread count (does it just show the unread count for the selected chat? With Slack it's a single dot, essentially saying 'there is stuff to read here')
11. Tweak notifications produced by chat: Yes. I'm not quite sure how to do this yet, but we'll want to do it somehow.
12. Prevent chat topics from producing email alerts: Babble doesn't currently send emails about chat.

From my end, my checklist looks like:

1. Make existing widgets flexible enough to appear in shoutbox and full page chat (done)
2. Add routing and views for a full page chat (done)
3. Add site settings to allow users to enabled/disable both the shoutbox view and the full page view
4. Add a 'who's in the room' function to show who's currently viewing the chat (which will appear underneath the channels list, similar to slack's layout. Eventually we will make it so that you can send private / quick messages this way.)
5. Style up everything so it looks good and is responsive
6. Add a default 'lounge' chat channel (since that's our stated MVP per @erlend_sh)
7. Figure out where to expose the route to /chat in the UI, and how notifications will work

Sweet! Sorry for being absent here. I was in DC, then my dad was in NYC so I was showing him around etcetera etcetera... Will get cracking on working-in with you presently.

I'd like to test a chat on my community. People ask me about it every day!

Sorry for the delay on this folks; Angus and I are both working on other sweet Discourse things at the moment, but we'll get back on this train soon!

@gdpelican I just pushed a new Babble branch full-page-chat-discovery to demonstrate how I'm thinking on how the frontend should work.

I think that, rather than having a completely separate view, the chat stream should exist as a sub-route of Discovery, taking advantage of the Discovery navigation, rather than using 'channels' per se.

Screenshot at Oct 14 14-26-32.png1170x281 31.2 KB

Screenshot at Oct 14 14-26-45.png1193x343 25.4 KB

Screencast of functionality: http://quick.as/R0YoIav2e

I've also added some updates to Admin Chats to allow the selection of categories to create new chat topics in.

Screenshot at Oct 14 14-35-23.png1100x387 25.3 KB

As you can see, this has required a few changes, which is why I've pushed this to a branch so we can discuss.

Here are some of the salient differences:

1. Client side chat routes are mapped to discovery, and follow the pattern of the build-category-route component to pull the appropriate Babble topic and render the appropriate templates in the Discovery outlets. The individual routes are built in this initializer (copied from the tagging plugin).

2. Chat admin gets a custom category dropdown to allow new babble topics to be created in different categories

3. I've added in the 'chat' topic archetype, because I think this makes it easier for us to link chat topics to categories, using the archetype to differentiate them, rather than the Babble category.

Concerning your remaining todos, '6' and '7' should be covered if we go with my suggested approach. I'll start tackling '5' (as it will be the same regardless of what approach we take) on the weekend.

Let's finish off this structural question and your to dos first, then we can see if anything needs to be done with rate limiting and other limits. We can probably just copy these from Quick Messages.

Really excited about this. Do you think having the chat live on the bottom right of the screen where there is a lot of space would be possible?

Sweet! I have this on my list for tomorrow.

This is awesome work, thanks! Some thoughts:

• I wondered while playing about the way we differentiate between a 'category' and a 'group' chat. Here's a quick mockup for something that feels intuitive to me:

Group chat:

Category chat:

• 'Chat' archetype seems simple and cool. Does this mean that topics won't appear in the topics list anymore for admins?
• The chat button on a category seems like a great way to get into the full page chat; we'll want a way to swap between chats once there though. I'll have a play today to see what I can come up with there.

Cool. So there'd be one type of 'create chat', then within the view for the new chat you could set the permissions, name and groups?

Does this mean that topics won't appear in the topics list anymore for admins?

Not by default. But there are a few ways we can exclude both I believe. I will look at this shortly.

I'm updating the chat UI itself at the moment.

If you're cool with the general direction, let's merge full-page-chat-discovery into full-page-chat.

Any updates coming soon? Is it safe to implement on my site yet?

Not yet. Both Angus and I have been contracted for other Discourse work over the past bit, so this hasn't surfaced yet.

We are meeting up tomorrow for a hack day on this, so hoping to have a solid update then.

Looking forward to this guys Great work!

@angus and I had a nice time yesterday hacking on this thing; we're getting close to a first stopping point, after which we'll encourage folks to install it and play around a little. Here's a gif of the existing functionality:

Creating a category chat

u7tgNnVzZv.gif1136x835 332 KB

Having a chat in full page mode

s67ItxwWgR.gif1438x732 233 KB

We've also added a site setting which allows toggling between full page mode and the shoutbox style plugin which exists currently.

If you really want to be on the bleeding edge, you can follow along with the following clone url:

git clone -b full-page-chat https://github.com/gdpelican/babble.git

And select 'enable full page chat mode' in the plugin settings.

But I couldn't recommend throwing this onto a live instance just yet.

I approve this message

I would add that we have a basic plan for the rollout of all the features previously discussed in this thread, and even some not yet discussed, such as import from Slack.

We'll be releasing the MVP soon.

Another interesting example of this can be found in we-hate-distractions.com which takes a topic-centric approach to group chat.

Just putting it out there for inspiration.

Aha 750$ per month for a local redit ^^