Comment concevoir une expérience pour un système distribué asynchrone et incohérent?
Comportement actuel: La plupart des systèmes actuels sont synchrones. Cela signifie que vous obtenez une réponse immédiatement lors de l'envoi d'une demande. Ainsi, on s'attend à ce que le système réponde immédiatement et lorsqu'il répond, tous les utilisateurs du système verront le même état à un moment donné.
Comportement proposé: Notre système est un peu différent. Ici, le système peut exécuter la demande de manière asynchrone (c'est-à-dire à volonté) et, par conséquent, l'utilisateur peut ne pas obtenir de réponse immédiate. Au lieu de cela, l'état du système sera modifié automatiquement après un certain temps.
De plus, l'état du système à un moment donné sera différent pour chaque utilisateur et, par conséquent, incohérent dans le groupe.
Avec ces contraintes, comment concevoir une expérience utilisateur qui définit correctement l'attente?
Par exemple, la personne A crée une facture dans le système. Un peut ne pas obtenir une réponse immédiate si l'opération a réussi ou non. Même si A obtient une réponse positive, la personne B du même groupe avec le même accès peut ne pas voir immédiatement la facture dans son système.
Vous recherchez un modèle d'interface utilisateur optimiste. Cela a été très bien fait par le framework météore .
Exemple
Supposons donc que la personne A crée une facture, la personne A ferait une requête au serveur (créer la facture), tandis que cette requête est en cours de traitement, la personne A verra dans l'interface utilisateur la facture nouvellement créée (ce qui n'est pas vrai, car le serveur est toujours en cours de traitement, mais il s'agit d'une hypothèse car vous faites confiance à votre serveur pour traiter correctement la demande)
Pendant ce temps, rien ne se passe pour la personne B.
Lorsque la requête est traitée par le serveur, le serveur met à jour l'interface utilisateur pour tous les clients (personne A et personne B) en cas de succès En cas d'erreur, la personne A verra le résultat modifié et une erreur apparaîtra. Cela est acceptable si votre serveur répond assez rapidement. (si vous avez besoin de 20 secondes pour traiter, le motif entraînera une mauvaise UX)
Limitations
Si vous ne supposez pas qu'il renverra un succès dans la plupart des cas, vous pouvez également appliquer le même modèle mais afficher un indicateur de chargement pendant le traitement de la requête et afficher le résultat uniquement une fois que le serveur l'a traitée.
La meilleure façon serait d'activer ou de désactiver le modèle d'interface utilisateur optimiste en fonction de vos besoins spécifiques (cette requête nécessite-t-elle une interface utilisateur optimiste ou non?) `
Il s'agit d'une façon spécifique de penser les interfaces homme-machine, qui apporte beaucoup de réactivité et est moins statique par rapport à ce à quoi la plupart des utilisateurs sont habitués.
Mais beaucoup d'applications en temps réel l'utilisent (Google docs, uber ...)