UXcellence Exploring excellent user experience

Nice Touch: Multiple Routes to Editing Slack Messages

If you’ve been creating content on the web for any stretch of time, you’re probably familiar with the multiple ways that people can discover your content. The web was originally built on browsing links and visitors were expected to navigate through your site by browsing nested categories of content (think old-school Yahoo!). Then along came search engines like Google, which direct you straight to the page you’re looking for. Nowadays, most people discover content through friends and family sharing links on social media. When building for the web, designers and developers must be aware and address these various routes for discovery.

While this works great for content, it’s still rare to find interaction models that have the same care and consideration for different methods of access that content receives. So I was pleasantly surprised when I discovered that Slack not only allows you to edit previous messages (for those who type faster than they think), but that you can edit your messages in several different ways. See below for examples.

The quick and easy

Pressing the up arrow from the message field opens your last message in Slack for editing

This was the first way I discovered. After typing a message, I noticed a typo in it and wanted to go back to edit. Being a fairly regular (but by no means expert) Terminal user, my brain automatically hit the arrow key and I was pleasantly surprised when it worked! (In addition, I love the feedback of highlighting the field and giving esc/enter instructions.)

The click and easy

Clicking the gear next to your message lets you edit the message as well.

After mentioning that, another friend mentioned that you can also click the gear to the right of a specific message to edit or delete that message as well. This is probably the most easily discoverable for the mouse-friendly user - especially with the visible icon, though it does rely on the user hovering over the message area to see it.

The nerd route

Using the Vi-like /s command lets you search and replace text in your previous message.

Finally, there’s the really nerdy method that relies on using the /s/phrase to find/new phrase/ model used by the Unix text editor vi (and its various clones). While the quick and easy terminal method is probably more than sufficient for most keyboard users, this one allows more control for the nerds who want to be specific about replacements. I love that they took the extra time to build this even though only a very small subset will discover and use it.

You can even edit messages in Slack for iOS.

The mobile route

On iOS, two of these three routes are impossible — there are no hover states to hide an edit icon behind and no arrow keys on the keyboard. Even the Nerd Route isn’t compelling because of the amount of keyboard context switching you’d have to do. (Initial testing shows that route unsurprisingly doesn’t seem to work on Slack for iOS.)

That didn’t prevent Slack from making it possible to edit your messages. Building on the touch capabilities of the platform, you can tap and hold on a specific message to access a menu with additional tools. From that menu, you can easily star a message to save it for later, copy the text for use elsewhere, mark a message unread (to help manage your conversations between contexts), and edit or delete your message.

In the edit mode, your original message is highlighted in yellow just above a new text field with the same text. On either side of a message that you are “Editing Message”, there are Save and Cancel options.

Slack could have easily justified having no edit mode for iOS. (Twitter still doesn’t even let you edit your own tweets.) Instead, they considered it a valuable feature and built a route specifically for the platform.


As more and more web apps become everyday tools used across multiple platforms, it makes sense to begin considering different types of users and how they want to interact with the features and tools our apps enable. We must consider multiple input methods and routes for accessing the functionality we build. In building new features or refining existing ones, ask these questions:

  • How else might users expect to access this?
  • How would users access this feature via touch UIs?
  • Is this friendly for users who prefer keyboard interaction?
  • How can mouse users access this feature easily?
  • How do your users discover different routes?
Like this? Please share:

Explore more like this