From Zero-Character Communication to Structured-Content Communication

You probably remember the YO app. A super simple application with just one functionality: Sending a two letter word “YO” to another user. Despite many positive feedbacks the app got from some of its users and successfully raising a seed round investment, the app was not able to develop a successful business model and therefore it failed.

I believe the concept that YO was pioneering, is actually a very important one, but unfortunately, their team was not able to prove its potential, because they stuck to the very extreme version of the concept and did not play flexible enough to mature the concept.

The hidden potential of zero-character communication is that it sheds new light on the “context”, because “context” takes part of the responsibility for delivering the message. Poking in Facebook is also an example of a zero-character commutation tool. When people poke you in Facebook, you already know what they mean. They are greeting you or waving a hand for you. You know this although technically no content has been transferred. This is the magic of context. In this specific case, the fact that the “message” is delivered to you through Facebook’s poking system — which is the context in this communication — tells you all the required content.

Zero-Character communication brought the context to the light, but at the same time, it kicked out the content from the scene. It’s the most extreme approach that does not take other parameters into account. That’s the reason it can not be practically used, at least not in a wide enough range of use cases.

The downside of relying too much on the context for commutation, is it limits the range of “what can be communicated”. Take the poking system as an example, although it’s much more efficient, you can just use it for one very specific use case: when you want to greet someone.

I think the initial concept can be developed into a practical solution in which the limitations of zero-character communication is minimized.

Structured-Content Communication

YO or Poking in Facebook had just one single usage. In fact, poking is a “single static structure” for delivering a message, and it was the main reason for its limitation, but, I think there is no reason for offering “just one” static structure. there could be multiple static structures, and the option to manage them. I believe with this approach the limitations of zero-content communications can be solved.

The benefit of using structures is that part of the message that’s going to be delivered can be pre-defined and pre-embedded into the structure, so less content needs to be delivered.

Structures are most useful in recurring messages. Something that repeatedly happens. In recurring messages, usually there are two parts: 1- A constant section that does not change at different times that it happens 2- a changing section that varies each time the message is going to be delivered.

By using structured-content communications, the constant section of recurring messages can be embedded into the structure, so it doesn’t need to be delivered every time the message is going to be sent. Therefore the total length of messages decreases which results in faster and easier communications.

We are already using structured-content communication in some situations. For example, when we set a specific ringtone for a specific friend in our mobile phone, we are creating a “structure” for our calls. As a result, when our phone rings, even without seeing the screen, we understand whether its that specific friend that’s calling or not.

I believe structured-content communications can seriously increase the efficiency of communication and even in some situations it can increase the level of automation in our daily life. When a message delivers in a “known” structure, we can plan for it in advance, because we already know at least a section of the content. A user can have a structured channel of communication with his colleague at work for when there is an important meeting, and set up his calendar if a message in that specific structure arrives, to set an appointment.

If YO used structured-content instead of zero-character

If YO used a structured-content mechanism instead of zero-character mechanism, it would have probably offered its user to create custom YOs! So a user could make a YO (Let’s name it XO!) and let his friends know that this means “Come to my place to watch a movie”, and create another YO (this one is ZO!) and share it with his wife and let her know this means “I’m coming home, if you need anything to buy, call me!”.

This was just an example to show how an app like YO could use structured-contents to overcome the limitations of zero-character communications, while still being committed to the core concept that it offered at first place.

Structured-Content in messaging apps

I think structured-content communication can be a great next step for messaging tools. It can result in easier and faster communications, and enable users to better manage their interactions. Messaging apps are already offering features like “Channels” or “Groups” which are great, but they can also offer some set of features for creating and sharing structures, and sending messages through them to utilize the power of structured-content messages to move communications to a great next step.