New Message Notifications and Unread Message Counts across Clients

Question

This UX question is unusual in that it deals with the user experience across several devices and modalities, and not just within one screen.

Suppose you have a chat app that can be accessed from various clients running on laptop, tablet, mobile, etc. Messages come in and are sent to all participants in the chatroom. At any time each client might be "online" or "offline" relative to the server. Sometimes the chatroom is visible in the client, other times it is in some hidden tab, i.e. not shown.

1. Suppose the user subscribed to get offline notifications for new messages in the chat. When do we send them?

One case is easy: if no clients are online. But what if one client is online and the chatroom is in the foreground? So the message has been "seen". But what if a person leaves a chatroom open on their desktop and walks away with their phone? Throughout the next day or more, they won't get any offline notifications. To solve this "perfectly" it seems I would have to use bluetooth pairing or track the movement of the user's phone. Or I could just have a really timeout of a minute or so for when there is no mouse movement or something.

2. An even more serious issue is what I should show for Unread Message Counts. On each client, I can store the triple (user X in chat Y saw up to message Z). This is cheap and easy to store on the client side. But then each client will show the number of unread messages relative to that client. This kind of intersects with point #1, namely, what if some other client has already displayed the message? Should the software assume that it was displayed to me over there, and therefore mark the message as read on all other clients?

Tech stuff follows

For #2, the trade-off is this. I am pretty sure that syncing across clients is more desirable, but it's very expensive from a tech point of view. Updating the triple (X, Y, Z) on the server requires an additional acknowledgment for every message in every chatroom from every client. This doesn't just double the traffic but also makes the server lock the (X, Y) rows in the database in order to increment the count of Z. This lock isn't too bad, since it's not like a user will have millions of clients open at the same time, probably only 3 or 4 max. But that's still a huge number of acknowledgments and locks just to sync (X, Y, Z) triples across clients.

My question in #2 is, is it good enough to show unread messages per client without syncing, or syncing (X, Y, Z) triples for unread messages is so vastly better that I should pay the price of all this extra traffic?

Answer 1

If I understood correctly, there is no way you can track if a user is reading a message, even if he has the chat open in front of him. As in real life (just a simple example) if someone is in front of a person talking it doesn't necessarily mean he is listening.

If this is such a big issue that will break the product, the only idea I can think of is that the client explicitly receives or stops receiving messages:

• The client has to click a button to receive new messages
• The client has to click a button to turn the chat off

These are not the most convenient ways of following a chat (specially the first one) but you can be sure that they explicitly decided to receive or stop receiving the messages (afaik, if they read them or not is not possible to track).

Answer 2

Well the devil's in the details. But from an architectural point of view, I would take a look at MQTT - it supports publish / subscribe with varying QoS settings. I'm assuming that if a user logs in via multiple devices, then they would be using the same identity. Perhaps a user+device level cookie could be used to sort out the different connections and offer a level of synchronisation across the multiple devices.

Another reason that I think MQTT could be useful to use is that it supports WebSockets and thus your client wouldn't need much low level code.