|Read this if:||You're still experimenting, prototyping, and exploring.|
|Read next:||Choosing the right APIs|
No super hero is complete without an origin story. Similarly, no app is complete (or can even begin) without a clear sense of when, how, and why users will interact with the app.
In our overview of plotting out your app, we mentioned some tips to help you get started. Put yourself in a user’s shoes. Imagine them trying to complete a specific task using your app. How do they make first contact?
Here, we'll break down the task of triggering interaction.
We'll talk about the different origins your app might take as inspiration before springing forth into action-packed, technicolor communication. Also, we'll give a brief overview of the moves and grooves available to your app once a flow has been kicked off.
No app is an island. Your app acts as a small archipelago in a long chain of events that lead up to (and beyond) the moment when user and app interact.
Keep the distant end-goal in sight like a guiding horizon: a user wants to accomplish something with your app. The rest is simply getting there as productively and pleasantly as possible.
User interaction has four basic parts: an origin event, a user interaction, an HTTP request from Slack summarizing that interaction, and a response by the original service.
We'll focus on the first two parts, the origin and interaction, in this getting started guide. Those are what you need to figure out first, before implementation can even begin.
Here's a bit more of an explanation on these two elements of the interactive flow:
Origin: an originating event causes your app to send a message that invites an action (like clicking a button or selecting a date) in Slack.
Interaction: A user in Slack reacts to the message by clicking that button or selecting that date.
Read on for a study of the archetypal origins, and interaction types, available to apps.
An interactive message needs a reason to exist: an origin story.
Something causes a message to be published, and a workflow to begin. There are several potential origins:
A message that is posted automatically to Slack because a particular time has been reached. For example, a message that is posted every Friday at 3pm to remind people to post a report of how their week went.
You can make use of the Scheduled Message API to post a message at the time of your choosing in the future.
Messages posted in reaction to something that happened on an external service. For example, a task being updated in a task tracker app, or an account being updated on a CRM platform.
The Events API sends a push to Slack apps whenever one of a number of types of things occurs in Slack. The receipt of one of these event pushes could trigger a message to be posted back to Slack by the app.
For example, the
app_mention event sends a push when the app is mentioned by someone in a conversation. The app could then respond with a message to continue the workflow.
A message invoked by something a user did in Slack. These kinds of user actions have to be configured by the app in order to work correctly.
Possible user actions available for Slack apps to configure are:
This is the big moment: showtime. Your app will use a message with an interactive component to garner a user's attention. While this guide won't dive fully into the details of each type of interaction, we can at least give you can a quick rundown.
Interactive components initiate communication between your app and Slack users.
Here's a quick glance at the interactive components you can add to app-published messages:
You can view our interactive element references for a full overview of the fields and options available for these components.
Buttons provide direct paths to simple goals:
Select menus offer a list of options for interaction to pick from, and a typeahead text field to narrow down those options:
Select menus can have predetermined static options, get option lists full of relevant Slack users or conversations, or pull in data from an external source to create an option list.
Overflow menus also offer a list of predefined options to pick from, but they're presented in a more compact way:
Need to let a user pick a date as part of an interactive flow? You'll want a date picker:
Meanwhile, back to our superhero's story: someone has clicked on or used a component in an app-published message, and the interactivity flow continues.
The next chapter continues with a request, sent by Slack, summarizing the interaction a user had with your app. Then, your app can choose how to react, inching further toward that satisfying ending when a user has accomplished the task they set out to in a pleasant, productive way.
Read our longer guide to messaging interactivity for tips on implementation. Or, if you're still prototyping, jump to our overview of app and message design.