Hiding complexity with Slack integrations

Complex systems are everywhere today. APIs and web applications hide complexity, but as this tweet mentions, if you have tools for different purposes, you end up context switching between a number of them. You can end up in a complicated thicket that wastes your time and prevents real work.

A Slack facade can layer a convenient interface over systems and can integrate them into once place. Less technical people can access systems from a familiar interface. All team members can benefit from less context switching. The Slack interface is primarily text and has the strengths of other text based interfaces:

• Commands are available, but don't intrude.
• Commands all exist in the same dimension of attention, unlike with a GUI where there are menus within menus.

These two attributes do lead to a discoverability issue for commands in Slack (just as exists for the command line). Luckily, smart help messages and good documentation can help. In addition, some kinds of integration can exist in the workspace independently; 'bots' prompt user exploration.

Integration categories#

There are three broad categories of of Slack integration:

• Slack commands. These are user initiated, thus the user needs to know the command exists. The action may be single step or multi step. Here's one example application: GitHub file transfer.
• Time or event based Slack responses. A system monitors Slack and/or other systems and pushes information to Slack or takes action based on events. An example is Hypebot
• Slack bots. These can respond to user commands and monitor events. This integration has an independent presence in your workspace, which can help with initial discovery and interaction. Welcomebot is an example of this type.

Systems that work well with a Slack facade#

What kind of systems does it make sense to put behind a Slack integration?

• You should be able to connect to the data or information (systems that are not accessible to the Internet are not a good fit for a Slack interface). It's best if they are available via an HTTP based API.
• Slack provides a public timeline, so data or interaction fixed to a point in time (or which needs to be audited later) is a good fit.
• The information delivered is not complex and interactive. Photoshop would be impossible to do in Slack, and even a simple image cropping program would be clunkly because of the text interface.
• There's not a lot of user manipulation required. You could write a spreadsheet program on the command line, but it'd be a subpar experience compared to Excel. The same is true for a spreadsheet program in Slack.
• Someone has to interact with the system or systems frequently, often with many steps.
• Simplifying a complicated UI, but allowing the user to go deeper (by moving to the original UX) is often a good fit.

You can browse our Slack example applications (and view their code) to see the wide variety of Slack integrations that we've found useful.

It's also worth noting that you can build more rich UIs in Slack using Block Kit. One of the benefits of a Slack integration is that everyone can create good looking and consistent interfaces.

Examples#

Here are two example applications that have made the complex simple. Chatting up CloudWatch discusses how to layer on a conversational interface to the CloudWatch data. This allows looking up application events from within Slack. This is a great example of taking a complicated backend data source and making it easily accessible within the Slack application, as mentioned above.

This CloudTrail to Slack bot (UmbrellaBot because it protects you from stuff coming from the Cloud, yuk, yuk) both pushes interesting external events to Slack and has a bot presence to allow a user to dig in deeper. Because it is creating chat messages about CloudTrail events regularly, there is an audit trail. The events are pulled from an S3 bucket, enriched by calling other APIs and applying business rules and then stored in a format accessible for querying.

How#

If you are interested in hiding complexity using Slack, start small. Pick a task that you do regularly that meet the criteria above and write a Slack command to do it. This will get you familiar with the mechanics, but also give you immediate value. There are several toolkits to use to write this (Transposit is one!), but think about:

• which kind of integration listed above makes sense
• what permissions you need (OAuth scopes)
• how to integrate with the other APIs and/or resources which will actually do the work you need done
• any richer elements beyond text that you might want to include (form elements, more complicated layout)
• where to host your code
• when to push the user to a more complex interface

This Slack guide gives step by step instructions on how to create any of the various Slack integrations in Transposit.

After you've had a small success, think about a larger system that has a relatively simple output, perhaps with a bit of user flow. This could be as simple as a report you run regularly or a vacation request tracker. You'll need to make sure that you can access the data via an API, file in a publicly accessible location or other means. If you are running infrastrcture on AWS accessing a resource via an AWS Lambda function may be easier.

It's important to realize that while this is software, it is similar to a shell script. Therefore extensive testing isn't required, especially at first. However, if you do end up needing to test your Slack integration because it becomes crucial to running your systems, unit testing and integration testing are possible. Depending on the tools you choose, you can easily set up a test Slack workspace or use a tool like slack-mock.

What doesn't work#

These processes are not well suited to being put behind a Slack facade:

• Really complicated processes with a lot of user input or data manipulation.
• Processes that are not internet accessible.
• One off scripts. The investment isn't worth it.
• Processes that are still in flux benefit from being done manually rather than calcifying the process into software.

Conclusion#

Chances are you already live in Slack for much of your day. You have complicated processes that may be amenable to automation. Having them at your beck and call from the Slack application "command line" can make your life easier and the processes be more consistent.