[Part 1 of a short series on messaging systems. (Part 2)]
Messaging is a feature that seems to wind up on the ZOMG MUST HAVE!!1! feature list long after initial system deployment quite a bit these days. I’ve been getting asked about this a lot lately, so I’ve written down my generic advice here for reference. (If you want more specific advice feel free to contact me, though — its interesting and fun to hear about all the different things people are working on.)
I’ve been implementing and deploying messaging systems in one form or another since I first got involved with computers as a kid in the very late 80’s and early 90’s. Back then most multiplayer games were basically text message dispatch and routing systems with thematic computation surrounding those messages, so this was an area quite a few people my age dealt with — without realizing that it would one day be considered an “enterprise” feature. (And to think, we used to do this in Pascal, and assembler, and C, and hilariously inadequate variants of BASIC… as children! That nonsense was only reasonable to us because they were the only tools we had, those were labors of love, and we didn’t know any better.)
The most important thing to recognize about messaging systems is that the term “messaging” is hopelessly broad. It doesn’t really mean anything by itself. Every over-the-wire protocol is a message system definition, for example. Every drop-it-in-a-spool system is also a messaging system. Every combat notification system in a game is a messaging system. Every websocket thing you’ve ever done is a messaging system. This list could go on for quite a while, but I assume you get the idea.
Messaging systems take on different characteristics depending on their context of use. Some messaging systems are persistent, some are ephemeral, some have selective decay, some are instant, some are asynch, some are channeled, some are global, some are private, some are selective-access, some are moderated, some include extra semantic data that can be interpreted in the message body, some run everything through a central data service (“ooooh, ahhhh, ‘the cloud'”), some are peered, some are anonymous, some are verified, some broadcast, some are point to point, some are free, some are paid in per-message increments, some are paid by aggregate use, etc. The list keeps going as long as you can think of things that can be said about any system, actually.
It is important to keep in mind that most of the adjectives in the last paragraph are not mutually exclusive. Here is the fun part, though: if you need two that are, then you need two messaging systems. (That’s why they make chocolate and vanilla, after all.)
That’s a lot of different aspects to something as conceptually simple as “messaging”. The obvious problem there is that messaging is actually not simple at all in practice. When you decide that you need a “messaging solution” you really must carefully consider what that means for your users and your system. Your users’ state of mind, user experience, utility value of messaging and desire to use messaging in the context of their use of your system are all folded together.
Consider this: Email is a messaging system and we’ve all already got that, why is this not sufficient for your use? If you can’t answer that question quickly then sit back and let it stew for a bit — you will learn something about your users in the process of answering this question because it forces you to think for a moment as a user of your system instead of as a builder of it.
Let’s consider some reasons you might want to add a killer messaging feature to your existing product or system.
- You can’t figure out the difference between “organic pageviews” and traffic resulting from the robot invasion.
- You want more pageviews and you don’t care how you get them — messaging, you think, can be a source of bajillions of clicks!
- Your users deal with data objects about which they constantly converse, but can’t do so within your system.
- Your users have things to express that are best represented in a way that captures the history of their thoughts in sequence.
- Your native applications do exactly what they should, but breaking out of it to send a message is distracting.
- Your system already passes data among users, but requires human annotation to be fully meaningful.
- Your system deals in machine-to-machine messages already, but users still have to call each other on the phone.
- You are looking for a way to attach your brand to one more thing users see every day to reinforce the hypnotic effect you wish your brand had on them.
- You require an anonymous(ish) way for users to communicate out-of-band relative to other online services.
A conditional flow would look something like this:
stupid_reasons = [pageviews,
                 domain_valuation,
                 brand_enhancement,
                 pagerank,
                 BULLSHIT_WEB_IDEAS(SEO && ALL_FLAGS),
                 ADS([ad_search, ad_rank, ad_tech, ad_{*}, ...]),
                 ...];
if (member(your_reason, stupid_reasons)) {
   if (idea_of(You) || you_are(TheManagement)) {
       admit(being_wrong);
       assert cancer_killing_internet = You;
       abort(stupid_idea);
       quick_grieve(dying_product);
   } else if (idea_of(TheManagement)) {
       abort(current_job, GRACEFULLY);
// It won't last much longer anyway.
   }
   acquire(funding_contacts);
   contact(me, IRL);
// I've got way better ideas.
// You should work with me instead of sticking with losers.
} else if (knee_jerk(messaging_feature)) {
   abort(stupid_idea);
   focus(core_features);
} else {
   congratulate(You);
   panic(FEATURE_BURDEN);
   CAREFULLY(implement());
}
quick_grieve(hopeless_thing)
{
   shock(hopeless_thing, DEAD);
   anger(cant_coerce([model, users, investors, world]),
         TANTRUM_LEVEL(11));
   bargain([me, you, imaginary_entities, investors, users, world, HAL],
           perceived_value(hopeless_thing, PERSPECTIVE(MYOPIC)));
   mourn(hopeless_thing);
   accept(DEFEAT);
   return AGGRESSIVE_OUTLOOK([POSITIVE && EXPERIENCED]);
}
Did you find yourself at congratulations(), or somewhere else? Stop and think for a while if your reason belongs in the stupid_reasons list or not. How much will it actually enhance your users’ experience with the product or interaction with each other or you? Are you going to use it yourself, or are you going to continue to use email, IRC, whatever corporate chat service is popular this week, Twitter, etc? (And if you say “Well, I/we don’t use my/our product, so I don’t know…” then you are already rather far beyond admitting defeat, you just don’t know it yet.)
Be painfully honest with yourself here because messaging is one of those things that you can’t add in and then just take away later without consequences. Even if very few people use it and it turns out to be a technical burden to you someone will wind up using it no matter how shitty it turns out to actually be, a few of these people will come to depend on it, and to these people you will be an asshole if you ever remove it. Don’t be an asshole to customers. That’s how you wind up with a “[your_product]sucks.com” — and the kind of users who come to depend on weird internal messaging systems that suck are exactly the kind of people who will register a domain like that and talk shit about you. That crap will stay on the web forever and the stink may stay on your product forever, even if you change your product and they come back loving it.
So let’s assume that your system will exist in a context where it really does add value to the user’s life in some way. goto congratulations()! Messaging will be a big win if done properly and unobtrusively. As a reward for being diligent and thoughtful you now you get to wade through a swamp of design issues. But don’t worry, I’ll give you the fanboat tour and point the way through the muck.
Next we’ll look at some common features of messaging systems, what they mean for your implementation and most importantly what they mean for your users within the context of your system. [Continue to Part 2]