Making Botkube faster to work with in Slack by reimagining the Kubernetes command line
Overview
Install Botkube on a Kubernetes cluster. Install the Botkube Slack app. Invite the Botkube bot to one or more channels. It will then start to alert you about different events, problems, warnings related to your Kubernetes apps and infrastructure on that cluster.
How does one make these alerts actionable? Also, typing commands in Slack is very tedious and error-prone. How does one type commands without (much) typing?
"I think this is really cool feature because it saves time."
Ivan Dobrinov
CTO, 1crew
"This a cool feature, Will make debugging easier, especially when debugging on Slack Mobile. It can be a pain to type the commands."
Dino Dambrosio
Senior DevOps engineer
Reducing friction, creating a research-based roadmap
The first thing I did when I joined the Botkube team was to identity the main points of friction within the product on all levels and stages.
How do people learn about the product? Is the installation experience seamless? What's their first interaction with the product like? How about their experience after that?
I figured out what the lowest points of the experience are by doing simple desk research: what are people complaining about in the user forums, what GitHub issues are they posting, etc.
Then I mapped them out and this is how I helped to inform the product roadmap for a few months.
The three low-hanging fruits we picked were:
No in-product onboarding
The bot is too verbose/spammy by default
It is too hard to type commands outside a terminal
Addressing user feedback
Some of the user feedback we got is that once a command is typed, the output is difficult to deal with - one has to copy/paste or even switch to a terminal app.
In the above case I asked myself why should the user have to copy / paste or even type commands in the first place? This wasn't exactly the problem that the user explicitly described but by sharing their story I could decipher that along with the specific issue they wanted fixed (log formatting).
The technical stuff
The first thing for me to do here was to understand what commands the bot could understand. The engineering team helped me understand and learn about Kubernetes' kubectl utility which is what Botkube uses to interact with a Kubernetes cluster.
The utility has a consistent syntax:
kubectl [command] [TYPE] [NAME] [flags]
So basically the actual command, a sub-command and then the thing that the sub-command is applied to (a Kubernetes resource). Name and flags are optional but important. For example:
kubectl get pods -n namespace
kubectl describe pods podname -n namespace
Feedback-based iteration and what didn't work
Initially the goal was to make the bot's responses interactive as that would have addressed the user feedback immediately. You received a list of pods? No need to copy/paste the name of the pod if we present the list as radio buttons or a drop-down.
Need run a kubectl command on that pod? Simply select a command from a drop-down.
Above is an example of an actual kubectl command and its output in the terminal and below are explorations on how to parse this output and make it interactive in Slack.
Initially the goal was to make the bot's responses interactive as that would have addressed the user feedback immediately. You received a list of pods? No need to copy/paste the name of the pod if we present the list as radio buttons or a drop-down.
Need run a kubectl command on that pod? Simply select a command from a drop-down.
After some iterations I figured I can expand on the interactivity and make the whole flow interactive such that it requires little typing. In my initial prototypes I wanted to flip the command syntax as the context changed.
So instead of starting with the verb (e.g. get) I wanted to start with the object (the Kubernetes resource) on which we want to perform an action (e.g. pods):
Mobile
Even though Slack takes care the responsiveness of Slack apps and how they look and feel on mobile and desktop, I wanted to make sure my designs work on mobile as well as possible as this was a solid use case for the feature. If typing commands on desktop is difficult and tedious, on a phone it is exponentially more so.
A collaboration feature
I had to be mindful of the 'multiplayer' aspect of the functionality, since this is a bot invited to a channel with potentially hundreds of users in there. My design is such that when the user is selecting from the interactive elements before they execute the command - that is only visible to them:
On the other hand, when somebody runs a command via the interactive functionality, everybody in the Slack channel will know what was run, on what cluster and by whom:
Designing within technical constraints
Worth mentioning that all my designs were constrained by the Slack API, or their design system of sorts. Some examples of limitations are:
The limited to zero control over layouts, especially on mobile
GUI elements don't have a disabled state
Copy-to-clipboard buttons aren't supported at all
Width of drop-down menus is limited to 75 characters
Worth mentioning that all my designs were constrained by the Slack API, or their design system of sorts. Some examples of limitations are:
The limited to zero control over layouts, especially on mobile
GUI elements don't have a disabled state
Copy-to-clipboard buttons aren't supported at all
Width of drop-down menus is limited to 75 characters
Making chat alerts actionable, reduce context switching
Up until we worked on this project, Botkube would send alert messages to Slack channels that described a (potential) problem that has occurred on a Kubernetes cluster:
The problem that I saw with this is that we tell the user "hey, something's wrong, go figure out your next step on your own". The end-to-end design was sort of broken. Then I came up with a simple design that would allow users to run kubectl commands on Kubernetes resources that Botkube alerted them about directly from the alert message:
This way the developer or the admin can start basic debugging of a problem without any context switching (e.g. to a terminal or another app).
Output filtering (sort of like UNIX grep)
Often times debugging infrastructure and apps involves using commands that generate long output - hundreds, even thousands of lines. Parsing such output is a more or less solved problem on sophisticated systems, but not on Slack.
The design we went for is conceptually based on the UNIX grep command where one can filter command output by one or more string patterns. This way of parsing is familiar to our users and matches their mental model. For simplicity sake we allow filtering only by one string pattern at a time, though I have developed prototypes that allow for more patterns.
If the user knows what output they can expect and they know what they will be looking for in advance, they can enter the string by which they want to filter by even before the command is run. They have the opportunity to do the same after the command execution, too.