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. [图片] 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! [图片] angus: 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. 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. [图片] angus: I’m not quite sure how channels with users or groups of users would work yet. (…) I think it would be best to keep ‘private messages’ and ‘private channels’ separate. 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.

Right, so the mvp would include the following: 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 duplicate content for posts in chat topics. Equivalent code in quick messages. 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. [图片] erlend_sh: I think Facebook Messages is a great example of a chat/pm hybrid. 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 :dancer:) [图片] In response to the MVP prompts: 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’d like to test a chat on my community. People ask me about it every day!

@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. [图片][图片] 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. [图片] 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: 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). 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.

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. :dragon:

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.

Speccing out a full page chat plugin

Development

gdpelican (James Kiesel) 2016 年10 月 13 日 18:09 7

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!

话题		回复	浏览量
Introducing Discourse Chat (BETA) Announcements chat , new-feature	142	29597	2022 年8 月 3 日
Discourse Chat Plugin official , chat , included-in-core	43	35417	2026 年7 月 29 日
Discourse Chat Integrations Plugin official , chat-integration , included-in-core	22	105434	2026 年4 月 21 日
Ability to move chat discussion to a topic? Feature chat	0	1985	2023 年3 月 24 日
3.2.0.beta4: easier access to chat threads, chat mobile redesign, experimental admin sidebar, and more Announcements release-notes	1	2052	2024 年1 月 8 日

Speccing out a full page chat plugin

相关话题