Messaging and Communications

Messaging and communications is closely linked to user management.  For some kinds of messaging it is necessary to have registered users so that messages can be specifically addressed and routed to the intended recipient.  This is not always the case however; sometimes you can send messages to individuals or groups of users without knowing much about them. 

Templedynamic apps and website have a messaging protocol which allows the different types of communication described below.  

Communications topologies

Communications between you and your users can be implemented in a number of familiar ways.  The technology to send a message from one place to another is much the same

Any-to-any: Any user may send a message to any other user.  The messages pass between those users only.  This requires a method of identifying the user to send to, so every user must have an name or address. 

A telephone network is an example of an any-to-any system: any user can have a private message with any other user if they know the number to dial. 

Broadcast:  A user sends a message which is read by all other users.  Usually this means the app owner sending a message to all users, but there are possible scenarios when you might want any user to be able to send broadcast messages.  Broadcast can be limited - for example you could allow messages to a subset of users in a predefined group. 

Broadcast is usually a one-way communication mechanism, although users can respond individually.  Television is an example of a broadcast system.

Hub and Spoke:  App users all send messages to a central user.  This is a very common scenario For example users send questions to you, you reply to that user only.   Helpdesk's work in a hub and spoke scenario - users speak only to the help desk, not with each other.

Pushing and Pulling Messages

An app will receive messages from a server across the internet.  There are two ways this is done, and the difference is important. 

Pulling messages is the easiest approach.  Email uses this approach. The email client on the users PC or phone periodically sends a message to the server asking if there are any new messages.  This is easy to implement, but requires the client to be running.  If you don’t start your email software on your PC, you don’t get any messages.   Messages are only received when the client requests them, so if the client is sending a request every 15 minutes, there may be a gap.  

Pushing messages is a more instantaneous method of sending messages - the user gets an notification as soon as the message arrives.  SMS Text messages for example are pushed to their recipients.  

Pushing notifications to users is more complicated and hence more expensive to implement. 

Communications between you and your users

It is possible to set up an app so app users can communicate with you even without needing to be identified.  Each time your app is installed on a phone, it can create a unique reference number.  If the user then sends a message to you, it is marked with this number, and you can reply to that specific user.  A two way exchange of information is therefore possible. 

Cost and technical implications:  Low to medium cost.  Basic messaging to anonymous users will be standard.  

Communications between users

Messaging between users is easily done, but requires users to be registered so that they can specify the intended recipient.  

Cost and technical implications:  Generally low to medium cost. 

Forums:  

Messaging can be presented as a forum or discussion thread as is often the case on website.  Forums can be implemented as a hub-and-spoke arrangement:  all the users send messages to the forum which can be seen as the hub.

People reading the messages are not receiving messages in the same way - reading the messages on a forum is usually done by presenting them a page which all members can read.

Cost and technical implications:  Low to medium cost.  Setting up a forum for your users is standard.