Lately I’ve been toying around with the idea of what messaging apps are and how I use them. Messaging applications went beyond mere text and emojis. Now most of the messages comprise GIFs, stickers, videos, voice messages etc… These last ones now trumps most of the everyday messages I send and are at the core of today’s idea. Often, and I’d argue it’s a common use case, I go back and forth with friends of mine with several voice messages in a row. Without using one messaging service I would never have imagine such a use: why sending repeatedly voice messages and not calling each other?! That’s the beauty of actually using a product, finding needs and uses unforeseen before testing. It’s probably a case of why you need to make your cake and eat it too!

Example of a frequent conversation.

There’s one frustrating thing about this dynamic: it’s incredibly slow. From when the other user is recording the message, you have to wait for it to be over, downloading the voice message and playing it back. Then if you want to reply the cycle goes on and on. It would be much more efficient and user friendly to have an opt-out option of streaming the message live while you’re recording it. This wouldn’t change the asynchronous dynamic, but add optional functionality to increase the reactivity, being a sort of middle ground. It would be a sort of casual substitute for phone calls and it would reveal to be especially useful in a group setting, where one-to-many live voice communication is still far from being used in the smartphone world.  The feature would be basically the modern version of a walkie-talkie. I think it could be seamlessly integrated with the traditional messaging UI, with a few tweaks. Here are some mockups I made to show the idea:

(1) The user can listen the sender live

(2) The sender can choose to finalise (commit) the audio

(3) The committed message appears like a normal voice note

The progression would be, from the first panel: the bubble is actionable and you can listen to the video message while recording. The second and third panel/action would be the same as what we have today, but with the transition between streamed message to committed one activated only upon consent (send) by the “recording” user. The message would be finalised/committed only after the explicit send action. As an UI note: the icon in the first bubble would be animated to transmit the feeling that something is happening. The animation I would suggest being similar to what we already find on the Telegram app notification of a user recording (it became a learned affordance).

Stream animation.

I hope we’d be able to soon see something similar on our messaging apps. Thank you if you’ve read so far, I’d love to hear what you think about it. Feel free to leave a comment down here or contact me on Twitter!