A few years ago I used to joke that I was getting in touch with my inner teenager when I texted with SMS. These days, I text more often than I send email and Apple’s iMessage makes it easy to text from any of my devices.
One way that email is superior to texting is that it’s easier to send messages without typos or mistakes. My texts often have mistakes. About half the time that’s because autocorrection thought it knew what I meant better than I did. The other times it’s because it’s harder to type accurately on an iPhone or even an iPad.
Whatever the cause of the errors, I’ve often wished that I could edit a text after it was sent. People have evolved a number of ways of dealing with this. One popular method sends the corrected word with a * prepended. That’s too ambiguous for me so I use the ed substitution notation s/xxx/yyy/. That’s pretty much a standard notation in the programming world—Sed, Vim, and Perl all use it—so it’s well understood by all my technical interlocutors but, oddly, even my non-technical friends and relatives have no problem understanding it.
Wil Shipley has an interesting idea: build a text correction protocol on top of the ed/Perl/Sed commands. His idea is that email clients supporting the protocol would allow the sender to edit the erroneous text, which would, in turn, send the appropriate Sed command to the receiver’s client. The receiver’s client would redisplay the text in its corrected form along with an indication that it’s been corrected. The old, erroneous, text would be viewable by clicking on the corrected indicator.
The beauty of this solution is that it has a soft fallback for nonconformant email clients. On the receiver’s end it would simply keep displaying the original message followed by the Sed command. In other words, just what I and many others are doing now. If the sender doesn’t have a conformant client, they can simply send the Sed command manually—again, what many us are already doing—and the user of a conformant receiver will see it displayed as a corrected message.
This is a great idea and should be fairly easy to implement without unduly impacting current clients. I hope one of the big players picks it up and runs with it. As Shipley says, once one vendor implements it, the others will follow.