Slack app toolkit: What Slack just Announced

This week Slack announced a set of features and recommendations called the Slack app toolkit, “the happy path for building engaging apps on Slack”. You can interpret “happy path” here as the path Slack would prefer you take. If you’d rather read the announcement than watch it on video, you can do so on the Slack platform blog.

The Big Picture

The most important takeaway from this announcement is also the least surprising. Slack is doubling down on integrations. They know it’s been the killer feature that’s enabled their success, and it’s now an important moat for Slack against their competitors.

The Slack app toolkit is an evolution in the way Slack prefers integrations be built so they’re more inline with where Slack stands today as an important enterprise integration platform.

The Slack app toolkit:

• Backs away from the more geeky/technical roots of their early integrations (“Bots”)
• Provides more granular permissions to deal with the increasing amount of IT oversight Slack now gets
• Includes an incremental evolution of their Block Kit UI framework for exposing an App’s UI in Slack
• Introduces the idea of “Surfaces” as new places your App can show up in Slack
• Will include an incremental evolution of Action shortcuts for invoking App behaviors

Let’s look at these one-by-one in terms of what was announced, and how each impacts you as a Slack developer.

Bots → Apps

Slack is eyeing the platform success of iOS and Android and wondering if they can’t be something similar for the enterprise. I’m certain there are product plans inside Slack that have them eventually taking on payments for 3rd party apps, taking a cut for themselves.

Slack wants users and developers to stop thinking about Slack bots and to start thing about Slack Apps. So slash commands and conversational interfaces are being de-emphasized (they’re not going away, they’re just no longer a big part of the “happy path”). Slack Apps will favor UI’s that are more usable to more people.

In general this is a good trend for everyone. Slash commands are great for command-line warriors, but are challenging for the typical user. They’re also not very discoverable. Conversational interfaces — a back and forth “discussion” with a bot — can also be quite cumbersome to develop and to use for many use cases.

In our own case, we’ve always thought of Carrot as an app in Slack, not as a Slack bot, so we haven’t invested heavily in slash commands and conversational UI.

It’s a good idea to get on the same page with Slack about where things are going, and start thinking about your own Slack integration as an App on the Slack platform, rather than a chat bot.

Granular Permissions

Slack is reacting to growing friction as their development partners and conservative enterprise IT organizations are clashing more frequently now that Slack’s success has earned them a bigger enterprise footprint and more IT scrutiny. Users and developers are frustrated when IT rejects integrations as a security threat. This is more common than it should be since the Slack platform has not always allow the actual permissions required by the integration to be narrowly expressed.

In the past, the bot token permission granted extensive powers to an integration. Slack has been on a long journey of walking this back towards having very targeted permissions, but there have been rules about the mixing of broad bot scopes and finer grained user scopes that prevented many of these more nuanced permissions from being used. As part of the Slack app toolkit announcement, more new permission scopes have been introduced, and the rules on mixing some of these targeted scopes have been relaxed, allowing a Slack app to be more granular and ask for only the permissions it actually needs and uses.

This can be a tedious topic, and the list of scopes has grown long, so there’s no quick answer here for Slack developers, but you do need to audit Slack’s available scopes and your App’s permissions regularly and experiment with getting the right set of scopes so your App’s security footprint is as narrowly described as possible.

Block Kit

Block Kit launched nearly a year ago as an MVP with an almost comically small set of UI building blocks. Some new UI elements were announced as part of the Slack app toolkit, but nothing revolutionary. It’s still a sparse set of UI components. There’s still no formatted input box and no ability to expand content inline for example, two things we specifically asked Slack for in the past. Overall we can be happy that they are pushing forward on the Block Kit, but at the same time, we can be disappointed they didn’t announce a bigger jump in UI capabilities.

Slack does want to evolve from the discussion-based bot integrations to a world of GUI-based Apps in Slack, and Block Kit is the way they’re doing it, but it’s happening in a measured way. It’s not where it needs to be so you can build your full-featured app with Slack as its primary user interface (without a lot of compromises).

It’s good to see Block Kit ticking forward, I just wish it was moving faster.

“Surfaces” — App Home Tab

In the broader theme of Bots becoming Apps, Slack is trying to increase the “surface area” of Slack that is available to Apps. The App home tab was one of the bigger sounding announcements, but like everything that was announced, it’s quite incremental.

“Slack Apps now get a home page!” It sure sounds like a big deal… but Apps already had a home page of sorts since last year when they were put into the Apps grouping in the navigation sidebar and moved out of the Direct Messages group. (Many Slack developers feel this was a move backwards as it pushed Slack apps below the fold in the UI).

So your “App home page” is still down there below the fold, in Apps, where it’s been, it just gets a bit of refinement.

In the past, clicking on an App brought up Slack’s usual chat UI — the one seen in direct messages or a channel — in a one-on-one direct message discussion between the user and the Slack App (this is realized as a conversational UI with the app’s bot). With the App home page you now get two streams of “stuff”, rather than just one.

The second of the two streams is the traditional chat stream of back and forth messages providing a conversational UI. It’s now optional. If you do decide to continue having this optional chat stream with the user, it’s labeled with a tab called Messages.

The new stream of stuff is labeled Home, and is a stream of Block Kit messages, all of which come from your app, none coming from the user. There’s no chat input box and no talking back to the app at a chat UI in this Home view. It’s either strictly an informational view, or the user interactions are done through Block Kit interactions and actions. The UI does end up cleaner this way since there’s no need to attribute each Block Kit message in the stream to the bot. Everything the user sees is from the App.

It’s not the perfect UI for your App though. It’s still just a stream of Block Kit messages, with all the limitations that currently entails. We’d love to expose more of Carrot’s UI directly in Slack, and this doesn’t really get us any closer.

So this App home page is not revolutionary, but it’s a good incremental change for how our Carrot bot for Slack works today. Our Slack integration provides daily digests and notifications to users via Slack, but we don’t really want anyone “talking” back to our bot. We only allow it because we have to, and our bot always says the same thing in response, which amounts to a polite version of , “Please don’t talk to me.”

The final new capability provided by the App home page is a new event your app can receive from Slack when the user clicks on your app in the App group. You can be notified that you have the user’s eyeballs and attention.

Slack suggests doing the following types of things when you receive this new event, and it’s the first time the user has clicked on your app, or they haven’t clicked on it in a long time:

• new user on-boarding
• welcome back messages
• usage tips
• product updates
• app configuration

In our own case, it’s a little tricky because users are already coming to the Carrot app in Slack regularly to see key updates and notifications. But as an example, here are some of our thoughts on how we might use the new event:

• Check if the user is getting their digests/notifications via Slack or email, if not via Slack, we can provide a block kit message that lets them toggle the settings right there.
• Send a Block Kit message that lets the user configure auto-sharing of Carrot posts into Slack channels. This is available in the Carrot app, but users seem to consistently miss it and maybe it could benefit from visibility here.
• Send a Block Kit message that invites the user to create a new post in Carrot, either by sending them off to the right place in Carrot or by letting them use a modal UI from within Slack.

If your UI isn’t already deeply conversational, you should move the interactions between your App and users to this home page. It will result in a cleaner looking integration that’s more in line with Slack’s vision of how things should work. It does mean moving from formatted messages to Block Kit, if you haven’t already. Slack’s formatted messages and Block Kit can be equally frustrating with what can and cannot be built, but you need to move on to Block Kit since it’s clearly the future direction for Slack.

“Surfaces” — Modals

When they launched Block Kit and actions, Slack also added a popup dialog window for actions. We used it to build an “Add a Carrot Post” action within Slack for example. A limitation was that dialogs were limited to a single window. With the Slack App toolkit they added the ability to string together multiple modals, made of Block Kit blocks, in a sequence to accomplish more complicated tasks without overloading the user, and with some branching based on the user’s interaction in prior modals. You can use modal windows to break a Slack action down into a sequence of smaller, easier to understand dialog interactions.

“Surfaces” — Actions

Slack is slowly improving App actions capability as well. Nothing is available with this announcement just yet, but coming soon™️ is the ability to access messages from a few more places than just the ellipse menu of individual messages.

• Actions can be pinned to a channel
• Actions are searchable in the quick switcher (this is a bit like Mac’s Alfred or Spotlight)
• Actions are accessible from a universal actions menu

Nothing too major here. Just a small boost in the discoverability of Slack app actions.

The Take Away

As the CTO of Carrot, an open source startup that’s made a big investment in Slack integration, the Slack app toolkit announcement has left me with mixed feelings.

The Slack app toolkit is an incremental turn of the crank by Slack in a consistent direction. If you’ve been paying attention to Slack’s platform development over the last couple years, there’s nothing in the announcement to disrupt your plans. They’ve stayed the course, and they’ve made some progress.

It’s clear though that Slack is the victim of their own growth and success. They are no longer a fast and nimble startup. They have big enterprises paying the bills now, and keeping these customers satisfied impacts the pace of Slack platform’s evolution. This is frustrating if your products will benefit from Slack delivering a more open, and more capable, enterprise platform.

Let’s hope that in the year to come, and at next year’s Spec conference, Slack provides us with a bit less incrementalism and a few more pleasant surprises!