|Read this if:||You're still experimenting, prototyping, and exploring.|
|Read next:||Designing a great app experience|
When you start putting all of this together, it's helpful to consider some evergreen tips that will keep interactions with your app pleasant and productive. In this doc, we've collated some basic interaction guidelines for apps.
When your app is first installed, allow the installer to easily set preferences that relate to communication. Think about settings like the rate of messages, the channel they should be posted to, and if applicable, the type(s) of notifications your app should send.
There are very few cases where your app should send broad mentions like @channel, @here, or @everyone. One exception might be if your app sends a notification for immediate action when a critical system or service goes down. Even then, you should get explicit permission from the installer before your app uses one of these mentions.
Modals are intended for short-term interaction. Their popup, attention-grabbing nature makes them a mighty weapon that should be wielded only at truly appropriate moments.
Your app can't invoke a modal without a
trigger_id from a user interaction, which creates a certain amount of intentional usage. But it should be as obvious as possible to users that particular actions will cause modals to appear. The convention of using an ellipsis to indicate a follow-up decision can be useful when naming app actions, for example.
Once invoked, a user can cancel a modal at any time. Handle these cancellations with grace. Don't try to force the user to proceed through the same process again.
Messages that alert users can be incredibly useful. Many Slack apps exist primarily to pipe notifications from external services into relevant channels. Here are some specific considerations that can help ensure the messages your users want don’t turn into noise.
Consider how frequently your messages are generating notifications for a user. When it makes sense, offer the user an option to get a digest of these messages rather than being alerted for individual events. This is especially important when the events are coming from an automatic source like service logs. In extreme cases, sending too many messages can get your token revoked due to rate limits.
When your app generates a lot of notifications, users will notice (and might grow annoyed). This can lead them to remove your app from a channel or even to uninstall the app from the entire workspace. One way to mitigate this is by surfacing messaging preferences often. Make it simple and intuitive for people to use your app how and when they want.
Here's an example of an app that builds a preferences link into the actual messages:
You may already be segmenting or categorizing the types of messages that users can receive. If your service already does this, you can make the Slack notification experience even better by giving people the option to pipe different message types into different channels.
For example, an HR tool might want to pipe messages about a candidate’s background check only into #hr-team, but after an offer has been accepted and signed, maybe a #new-hires channel wants to be notified so they can celebrate.
Don’t post to a workspace’s #general channel by default. You’ll likely be unnecessarily disrupting many users and there is probably a more relevant channel for your app to post in.
Some messages are best as simple text that alerts a channel that something happened in a 3rd party system. But what if that user wants to dig into your service after receiving your message? Or what if you send a system status that requires immediate action?
You can save people work by adding action elements directly into your app’s Slack messages. Buttons, select menus, and dialogs let people react in the moment and get work done faster. If your app is considerate with alerts and saves people time, they’ll likely find your app an essential part of their workday.
Your actionable messages don’t need to be complex to be helpful. Just think about what action the receiver most likely wants to take. For example, if your app sends expense approval messages, the receiver probably wants to approve or deny the expense — interactive buttons are perfect for this.
Learn more about sending messages in our messaging docs.
First, consider when and whether you should send direct messages (DMs) to specific users. Remember that DMs generate push notifications for mobile users and badges on desktop and mobile. These are useful but also disruptive and can be unexpected, so be cautious with your use of DMs. You should only DM a user when:
Users will assume that information shared back and forth with your app in DM is private. Be aware of any sensitive information that’s being shared, and don’t surprise users by announcing results of DM conversations in channel without letting them know first.
Need to send a DM? Read our guide to finding conversations via the Web API and then about sending messages.
Whatever you post in channel is going to be long-lived and add to the group conversation that people are reading, both in the moment and later when they may look back at what was shared.
In response to a user action, an app could publish an in-channel message, or an ephemeral message. In-channel response will be visible to all channel members where the user invoked the action. Ephemeral responses will only be visible to the invoking user.
Remember that a chatty app is not necessarily a good thing, so only pick responses that are important to the entire team when posting in-channel.
If the response only needs to be displayed to the user, it’s a better idea to use an ephemeral message than it is to generate a DM.