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.
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.
A ‘presence’ feature, showing online members and activity such as typing.
The compose input is ever-present in the UI, like in Babble or Quick Messages.
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.
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.
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.
‘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:
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.
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.
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).
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.
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?
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?
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.
Remove or alter the check for whether the post content is sufficiently ‘descriptive’ (I haven’t done this in quick messages). Discourse code.
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.
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.
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.
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).
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.
A chat topic type: I’m happy to move to a ‘chat’ archetype if it’s necessary.
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.
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.
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.
Remove or significantly reduce the maximum length for posts in chat topics: This should be easy to add
Remove check for duplicate content: Babble does this
Remove or alter check for ‘descriptive’ posts: Babble does this
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)
Post edit and delete: These work for Babble
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’)
Tweak notifications produced by chat: Yes. I’m not quite sure how to do this yet, but we’ll want to do it somehow.
Prevent chat topics from producing email alerts: Babble doesn’t currently send emails about chat.
From my end, my checklist looks like:
Make existing widgets flexible enough to appear in shoutbox and full page chat (done)
Add routing and views for a full page chat (done)
Add site settings to allow users to enabled/disable both the shoutbox view and the full page view
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.)
Style up everything so it looks good and is responsive
Add a default ‘lounge’ chat channel (since that’s our stated MVP per @erlend_sh)
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 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.
Chat admin gets a custom category dropdown to allow new babble topics to be created in different categories
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.
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.
@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:
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.
)
Great work!
