Even today, most of us use email as our primary of “work management” tool. For example, we use our email inbox as a “to-do” list. So we use the “unread” marker to flag pending items – a task so common that the Gmail reader lists “mark as unread” as the first “mode” action – even above “add to tasks.” Since so many of us use email as a task management tool, let’s follow a fictitious developer who wants to create a “task management for email” app and let’s see the challenges he faces.
The developer creates a nice user interface (UI) – it looks much better than that of an email client – and slaps it onto the basic web backend. He gets his first alpha customers to test it for a few days, and sees some activity, but nowhere near the volume that he expected. He asks for customer feedback and learns that customers want to be able to use the app when they are offline. Even when they are online, they complain that the UI seems too slow. Their email client, on the other hand, is already installed on their device and works very well whether they are on- or offline.
MESSAGING SHOULD ALLOW THE USER TO DECIDE WHEN TO USE THE APP RATHER THAN THE OTHER WAY ROUND.
The developer goes back to the drawing board and creates a database that will store all the tasks that the user wants right on the device, itself. Syncing is a pain – especially handling changes to task status – but somehow he gets it right.
Now the developer is truly happy. In a default email client, users have to wade through one email for each update, but his app now shows precisely one version of each item – the latest. Sure about the significant impact that this feature will have, he goes back to the alpha users. At first, his users are happier, but a new problem immediately surfaces: When the users work offline, they can now read their tasks, but cannot perform any activity. Primarily, when working offline, users want to weed out (“delete”) unimportant updates. Deleting emails while offline never seemed hard before.
FULL OFFLINE SUPPORT IS CRITICAL FOR MESSAGING.
The developer goes back to the drawing board and creates a simple mechanism to support working offline. The entire updated task is stored on the client side and, when the user goes online, the changes are sent to the server. This time, his problems are discovered in QA, before he goes back to his users. The app now generates version conflicts – for example, his app tries to update a task when other changes have taken place in the offline client. For some actions (like adding comments), these are easy to resolve (just add both comments), but for some corner cases (like changing task status), no fix seems possible. Fortunately, an architectural change saves the day: Each update becomes a separate message, stored offline when the device is offline; when the devices comes online, each message is applied in sequence. Unfortunately, some updates still get rejected because of conflicts but this is fine and the users are happy.
A MESSAGING ARCHITECTURE IS NEEDED TO SOLVE MESSAGING PROBLEMS. UNFORTUNATELY, most developers only try that THAT after EVERYTHING ELSE FAILS.
By this time, the server code to support the app has grown almost as large as the core product, itself.
Sometime later, another client asks the developer to add a “customer service chat” feature to her e-commerce app. Much wiser, after the above experience, he looks for an off-the-shelf messaging solution. He is lucky to find one that gives him a complete end-to-end solution, including a client side UI. Very happy at completing a six month project in 6 days, he releases the update, which is well received.
MESSAGING IS COMPLEX ENOUGH AND MODULAR ENOUGH TO WARRANT An SAAS SOLUTION
His next assignment is to ask the company’s users for feedback on the products they purchased. Since he has already integrated a messaging bus in his app , the developer considers simply adding a separate channel for these feedback messages, intending to receive and store them manually.
He will need to create a separate UI to display his survey questions; he will then need to convert the users’ feedback into messages; and, finally, he will need to send those messages to the server. Recognizing how much additional effort this involves, additional requirement was so minor, he just decides to send the feedback request to his users as a text message and hope and pray that they respond in a proper format. Unfortunately, that never happens — the feedback comes back in so many separate formats that they’re virtually useless.
TYING FREE TEXT MESSAGING INTO OTHER SYSTEMS IS NOT WORKABLE.
Now imagine that our developer’s customer support use case needs some additional features. This time, his company wishes to collect some initial data from purchasers who call in for support – such as the product code, their geographical location, etc. – to help them route each inquiry to the correct support person. Because the developer has learned from the last set of issues, he puts additional effort into creating a UI that will capture the required data and send it as a “formatted message.” Although, this time, his solution works well, his earlier inefficiency ate up such a large amount of time for a relatively minor adjustment that he earns a bad performance review.
YOU DON’T GET THE WORLD FOR FREE – EVEN WITH MESSAGING
Or do you?
At Teamchat, we solved the conundrum that makes messaging seem both potentially powerful and yet so often powerless. Teamchat’s ability to “un-sync” two people who need to coordinate their efforts to accomplish a task is what makes Teamchat messaging so powerful. Have a question as you work? You’ll come up to speed quickly with Teamchat’s offline support – something simply impossible even with state of art (and multi million) ERP solutions. Consequently Teamchat improves efficiency by a huge margin – picture the challenge, for instance, when one person just needs to approve a minor change in the work of another. Unfortunately, there is no standard “language” for messaging, so conventional messaging software cannot restrict either the format or structure of the replies it gets back—it cannot force the reply into the format it expects. Messaging is just extremely flexible plain text – and that is both its greatest strength and biggest weakness.
However, Teamchat realized that messaging can be structured so that, rather than text, both sender and receiver use the same buttons and forms to generate both the message and the reply. And so, a whole new world of possibilities opens up.
Presenting – the Teamchat Structured Messaging Platform.