-
Notifications
You must be signed in to change notification settings - Fork 46
Chat guide: task-oriented chats #2892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
||
|  | ||
|
|
||
| Delivering chat messages in realtime is key to an engaging experience. Ably's [serverless architecture](/docs/platform/architecture) eliminates the need for you to manage websocket servers. It automatically scales to handle millions of concurrent connections without provisioning or maintenance. Ably also handles all of the edge-cases around delivery, failover and scaling. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"engaging experience" I think is probably more fitting the livestream case - there are many cases of task-oriented chat where engagement in the enjoyment sense isn't really top-of-mind
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"a smooth online experience"?
I imagine for support, deliveries, etc. the goal is to not frustrate further (assuming if everything is ok to start with people don't use the chat)
For games it can be a way of increasing engagement
|
|
||
| Each room includes all task participants: customers and agents in support, buyers and sellers in marketplaces, players in games, team members in projects. Participants can join and leave as the task evolves. Access to message history and other features can be granted to all or select participants via capabilities. | ||
|
|
||
| ### Pricing flexibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably more of a @m-hulbert question - but do we want to be calling out billing dimensions explicitly in the guide because if they ever change we have to go and update everywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would avoid talking about pricing explicitly. We can add a link to the pricing price, or to the future chat-specific pricing documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't talk about pricing here. Maybe a link to the pricing page.
|
|
||
| ## Push notifications | ||
|
|
||
| Ably Pub/Sub channels can be used for push notifications. See the [Push notifications](/docs/push/publish) documentation for more details. Since Ably Chat rooms are backed by a single Ably Pub/Sub channel, you can use the same channel for push notifications to notify all participants in the room when something happens. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to check the implications on mutable messages of using the same channel for push notifications
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had a go with this and found it difficult to use actually:
- chat channels require identified publishes so servers will have to set a clientId for sending push notifications
- I found setting up push notifications to be very confusing and difficult to just reset and start over (I'm probably missing something here)
maybe we should just suggest to use another channel, or I can dig some more into this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah the Web UI is a known issue that I've raised. Having to set a clientId for push notifications isn't the end of the world - but im thinking like will they be in the channel history etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- they show in history, but they show in history anyway if you have history enabled (not just on chat channel or mutable messages channel)
- on mutable channels they can also be edited and deleted
Given that they show in history if you enable persistence, is this a problem?
a25e7bc to
6e2d614
Compare
| @@ -0,0 +1,406 @@ | |||
| --- | |||
| title: "Guide: Building task-oriented chat experiences with Ably" | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find "1:1 or small group" chat experience more understandable than "task-oriented".
|
|
||
| Delivering chat messages in realtime is key to a smooth online experience. Ably's [serverless architecture](/docs/platform/architecture) eliminates the need for you to manage websocket servers. It automatically scales to handle millions of concurrent connections without provisioning or maintenance. Ably also handles all of the edge-cases around delivery, failover and scaling. | ||
|
|
||
| Despite the challenges of delivering these guarantees, Ably is designed to keep costs predictable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not talk about pricing in the guide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've done that in the livestream guide - and I think it does have a place here. But I think it should be limited to "consumption based helps if your app is like ABC, MAU helps if your app is like XYZ" - so much more of highlighting a decision point and showing how Ably works for you, rather than breaking down the pricing in detail.
|
|
||
| Each room includes all task participants: customers and agents in support, buyers and sellers in marketplaces, players in games, team members in projects. Participants can join and leave as the task evolves. Access to message history and other features can be granted to all or select participants via capabilities. | ||
|
|
||
| ### Pricing flexibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would avoid talking about pricing explicitly. We can add a link to the pricing price, or to the future chat-specific pricing documentation.
| Chat rooms scale horizontally. Ably allows you to have as many rooms as you need running in parallel. | ||
|
|
||
| * **Proven at scale:** Ably delivers over 500 million messages per day for customers. | ||
| * **Rate limiting:** Prevent spam and maintain conversation quality with global or per-user throttling appropriate for your use case. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually offer "per-user throttling"? Understanding user here as a clientId.
|
|
||
| Each room includes all task participants: customers and agents in support, buyers and sellers in marketplaces, players in games, team members in projects. Participants can join and leave as the task evolves. Access to message history and other features can be granted to all or select participants via capabilities. | ||
|
|
||
| ### Pricing flexibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't talk about pricing here. Maybe a link to the pricing page.
| Ably's comprehensive platform enables you to combine chat with other realtime features to create rich, interactive task experiences. | ||
|
|
||
| **Pub/Sub channels** add interactive elements: | ||
| - **Live polls:** Quick feedback during collaborative decisions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't be better using LiveObjects for Polls and other things, instead of a channel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they're probably best via a message that gets annotations for votes, but I guess it depends.
As far as I know LO are good if the state you want to track is per-room/channel and you want to keep it synched. Topic, room reactions type of thing, pinned messages, etc.
For task-oriented it can be things like the actual listing in a marketplace can be a live object if it's something that gets updated live. Or if you do a live fundraiser and you count and show how many donated and total amount raised.
I guess the status updates/progress indicator it s good one in this list
| * **Hate speech and harassment:** Detecting discriminatory language, threats, or targeted abuse. | ||
| * **Discrimination:** Detecting discriminatory language, threats, or targeted abuse. | ||
| * **Inappropriate content:** Flagging adult content, violence, or graphic material. | ||
| * **Toxicity:** Measuring overall message sentiment and hostility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
End sentence with "."
|
|
||
| 2. **Technical integration** | ||
| * **Latency impact:** AI moderation adds up to 100ms to message delivery. | ||
| * **Integration options:** Choose from pre-built integrations or connect your existing moderation systems via webhooks, serverless functions, or queues |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
End sentence with "."
| Ably's [fault tolerance guide](/docs/platform/architecture/fault-tolerance) describes how we do this and that, even if an entire region | ||
| goes down, it has little-to-no impact on the global service and your application. | ||
|
|
||
| ## Priced for task-oriented efficiency |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice pricing explanation here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep or drop?
If we want to avoid pricing info on this page, maybe it needs to go?
|
|
||
| ### Aggressive connection management | ||
|
|
||
| When a client abruptly disconnects from Ably, there is a 2 minute delay before the connection is cleaned up on the server, to enable the client to resume the connection from where it left off. When you're finished with an Ably connection, be sure to call the `close()` method to gracefully shut down the connection. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe explain this is good for pricing, as there won't be opened connections forever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added a line about this - mentioning to detach the room and drop connections
Co-authored-by: Andy Ford <[email protected]>
6e2d614 to
fcb7b39
Compare
|
Last things to decide:
|

Description
Chats linked to something else, like a meeting or call, delivery, document like google docs, or a support ticket. Typically small groups or 1:1.
https://ably.atlassian.net/browse/CHA-900
Checklist