Notifications de nouveaux messages et nombre de messages non lus sur les clients
Cette question UX est inhabituelle en ce qu'elle concerne l'expérience utilisateur sur plusieurs appareils et modalités, et pas seulement sur un seul écran.
Supposons que vous ayez une application de chat accessible à partir de divers clients fonctionnant sur ordinateur portable, tablette, mobile, etc. Des messages entrent et sont envoyés à tous les participants dans le salon de discussion. À tout moment, chaque client peut être "en ligne" ou "hors ligne" par rapport au serveur. Parfois, le salon de discussion est visible dans le client, d'autres fois dans un onglet caché, c'est-à-dire non affiché.
- Supposons que l'utilisateur s'est abonné pour recevoir des notifications hors ligne pour les nouveaux messages dans le chat. Quand les envoyons-nous?
Un cas est facile: si aucun client n'est en ligne. Mais que se passe-t-il si un client est en ligne et que le salon de discussion est au premier plan? Le message a donc été "vu". Mais que se passe-t-il si une personne laisse un salon de discussion ouvert sur son bureau et s'en va avec son téléphone? Tout au long du lendemain ou plus, ils ne recevront aucune notification hors ligne. Pour résoudre ce problème "parfaitement", il semble que je devrais utiliser le couplage Bluetooth ou suivre les mouvements du téléphone de l'utilisateur. Ou je pourrais juste avoir un délai d'attente d'une minute environ pour quand il n'y a pas de mouvement de souris ou quelque chose.
- Un problème encore plus grave est ce que je dois montrer pour le nombre de messages non lus. Sur chaque client, je peux stocker le triple (l'utilisateur X dans le chat Y a vu jusqu'au message Z). C'est bon marché et facile à stocker du côté client. Mais alors, chaque client affichera le nombre de messages non lus par rapport à ce client. Ce type d'intersection avec le point n ° 1, à savoir, que se passe-t-il si un autre client a déjà affiché le message? Le logiciel doit-il supposer qu'il a été affiché pour moi là-bas, et donc marquer le message comme lu sur tous les autres clients?
Les trucs techniques suivent
Pour # 2, le compromis est le suivant. Je suis à peu près sûr que la synchronisation entre les clients est plus souhaitable, mais c'est très cher d'un point de vue technique. La mise à jour du triple (X, Y, Z) sur le serveur nécessite un accusé de réception supplémentaire pour le message every dans every chatroom de every client. Cela ne fait pas que doubler le trafic, mais oblige également le serveur à verrouiller les lignes (X, Y) dans la base de données afin d'augmenter le nombre de Z. Ce verrouillage n'est pas trop mauvais, car ce n'est pas comme si un utilisateur en aurait des millions des clients ouvrent en même temps, probablement seulement 3 ou 4 max. Mais cela représente toujours un grand nombre d'accusés de réception et de verrous rien que pour synchroniser (X, Y, Z) des triplets entre les clients.
Ma question dans # 2 est, est-ce assez bon pour montrer des messages non lus par client sans synchronisation, ou la synchronisation des triplets (X, Y, Z) pour les messages non lus est tellement mieux que je devrais payer le prix de tout ce trafic supplémentaire?
Si j'ai bien compris, il n'y a aucun moyen de savoir si un utilisateur lit un message, même s'il a le chat ouvert devant lui. Comme dans la vraie vie (juste un exemple simple), si quelqu'un est devant une personne qui parle, cela ne signifie pas nécessairement qu'il écoute.
Si c'est un gros problème qui cassera le produit, la seule idée à laquelle je peux penser est que le client reçoit ou arrête explicitement de recevoir des messages:
- Le client doit cliquer sur un bouton pour recevoir de nouveaux messages
- Le client doit cliquer sur un bouton pour désactiver le chat
Ce ne sont pas les moyens les plus pratiques de suivre un chat (en particulier le premier) mais vous pouvez être sûr qu'ils ont explicitement décidé de recevoir ou d'arrêter de recevoir les messages (afaik, s'ils les lisent ou non, il n'est pas possible de les suivre).
Eh bien, le diable est dans les détails. Mais d'un point de vue architectural, je voudrais jeter un œil à MQTT - il prend en charge la publication/abonnement avec différents paramètres de QoS. Je suppose que si un utilisateur se connecte via plusieurs appareils, il utilise la même identité. Peut-être qu'un cookie de niveau utilisateur + appareil pourrait être utilisé pour trier les différentes connexions et offrir un niveau de synchronisation entre les multiples appareils.
Une autre raison que je pense que MQTT pourrait être utile à utiliser est qu'il prend en charge les WebSockets et donc votre client n'aurait pas besoin de beaucoup de code de bas niveau.