Editing your last embarrassment


There are two kinds of people.


I belong to the first kind and it’s super embarrassing. I can’t speak for the entirety of that kind, but I can say that my intention was never to send you a message with an error. In fact, I only want to reply faster and more efficiently. Sadly iOS’s Autocorrect acts every bit the role of a villain when that happens. The only thing I can do is apologise and hope it never happens again. But our apps are smarter. Maybe we can do better than this?

One quick solution — Turn off auto correct. But hey, autocorrect is useful in 99% of cases where it doesn’t make me look like an idol, *idiot. Damn it😐

What are the existing solutions?

Skype, Slack and few more popular enterprise messaging apps already allow the users to edit their old messages.

Skype allows the users to edit their last sent text via dropdown or (↑) Key .

Skype allows the users to edit their last sent text via dropdown or (↑) Key .


In your mobile you have to press and hold your last text → You get the edit menu → Edit window pops up, edit all you want.


Slack follows a similar approach and it allows editing any texts in the past. All these solutions aren’t necessarily bad and it works at the end of the day, but other casual chat apps didn’t adopt this for various reasons. But I believe one of the big reasons is that there are no good solutions out there.

So what could be a good solution for editing your last sent text?

  1. A solution which works automatically, all the time.

  2. A design pattern which can be adopted by most of the messaging apps.

  3. Users shouldn’t learn how to use it.

  4. There should be no additional interface elements. I’m not planning to add clutter to the existing interface.

  5. Users should be able to undo their editing.

  6. Should be smart. Not make the users cringe over how bad it works.

  7. Should work really well in a mobile (small screen) use case.

What do I propose?

Before I come to the solution, let’s talk about a few different scenarios where the user wants to edit their texts.

  1. Simple spelling mistakes, grammatical errors.
  2. Autocorrected words. Tapping on wrong suggestions.
  3. Mediocre/wrong sentence formation. Wants to redo the sentence.

The last one is definitely not in the scope of this solution right now. So what can be the solution for the first two use cases?

Reinventing the wheel? No.
What can be a better way than editing the text without leaving the keyboard? Yes *asterisk comes into the picture. It’s popularly used to denote corrected typos and it’s always available in a keystroke in both iOS and Android keyboards.

Case-1: Full pattern match. Zero chance of error

So how does it work? 
When the user types and sends a text, they can edit some words by sending an immediate patch text with *word in the front. In the example case-1, I’ve made a simple typo mistake for ‘doneʼ with ‘doeʼ. In the next text that got sent, I specified ‘doneʼ with the (*) in the front and the doe gets replaced. The edited text is then made bold to emphasise on the difference.

Notice how the latter text goes inside the former text and disappears? That’s the visual way to denote that the patch is via the latter text. Simple right? Not exactly. Replacing words are a huge deal and if done badly, it will give a very bad experience to the user. So how can it go wrong?

To understand that, as a designer I need to find out how to implement
this theoretically.


The algorithm behind the chat finds an asterisk[*] in the text.


It checks the previous sentence to see if the character pattern in the word following [*] is similar to any of the words in the previous text that was sent.


 If the word pattern matches 50% and above with any word in the former text, then it will replace that word. Note that the percentage will be less if two or more words have similar pattern.


If the match percentage is less than 50% or if the algorithm predicts that there is more than one word which matches the pattern or if the pattern doesn’t match any word in the former sentence, then the algorithm will highlight the predicted words and let the user tap on them to replace. Example — Case-2 explains this in a better way


So when the algorithm doesn’t know the right word to replace, It highlights the predicted words based on the type of the word that the user wanted to replace.

Case-2: No pattern match / multiple words match with the pattern. Predicted words are highlighted to the user

In the example case-2, I wanted to replace a word with a completely different word — Copenhagen with Koramangala. But the algorithm doesn’t have any word that has a similar pattern as Koramangala. But it predicted that the word I want to replace is a noun and it highlighted all the nouns that have the potential to get replaced. Tapping on any of these predicted words will replace that word with Koramangala. So I tapped on Copenhagen and it got replaced by Koramangala with a subtle animation.

With good Natural language processing algorithms, this solution can be further improvised and the app can highlight less, but words with a higher chance of replacement. (Think of a scenario: A huge paragraph message with a sample of 20 predicted words).

Okay, so it automatically fixed my mistake. Now, what if I don’t want that?

If the users can’t undo this, this will be a nightmare to integrate into any chat application.

Case-3: Undo the edit by tapping on the chat bubble. Works on both senders side and receivers side

They try to interact with the modified text. The best place to keep the undo functionality is to keep it on the primary touch screen interaction — Tap. Here in the E.g case 3, I want to undo the edit and I tap on the text that was modified. Original text drops the patch text down with a subtle animation. The motion here gives the user some delight and also explains the structure of how to undo happened from the parent structure. This works on the recipient side too.

This was one of the interesting projects I’ve worked on recently and I learnt that if a feature has to be purely simple to use, there has to be a lot of work to execute it. This concept may look interesting in theory and also in my prototypes, but in reality, if a billion users are gonna use this, then this has to be tested with real users and real errors. This concept is open and any developer can make it real. Would love to see interesting concepts and iterations over this initial idea.


Even though it’s just a basic idea and it needs to be iterated well before we reach the implementation ready solution, I’d like to add some limitations.

  1. This concept won't work for editing multiple words. In fact, it’s impossible to solve that with the same design or algorithm

  2. This concept can be made to work in a group chat but with some additional UI element.
  3. People will exploit any feature. So this feature needs more social proofing based on the kind of chat app its build into.

P.S I’ve used WhatsApp as the chat app to demo this concept and they own all the rights. This idea is not affiliated with WhatsApp. Concept designed in Sketch and prototyped in Pixate.

This case study was originally published in Medium