Distinguez résultat vide et échec de récupération
Imaginons une imprimerie de Budapest utilisant une application pour coordonner les enlèvements de colis. Le personnel ouvre la liste d’un jour donné. Si la récupération échoue, afficher « Aucun enlèvement » pourrait induire en erreur. Ce message doit suivre uniquement une récupération réussie ne trouvant aucun travail correspondant au jour et aux filtres visibles.
Demandez des exemples distincts : premier chargement, liste chargée correctement, résultat vide valide et échec de chargement. Mentionnez la date sélectionnée dans l’explication pour permettre au personnel de vérifier le contexte. Cette imprimerie est un exemple hypothétique.
Gardez les informations utiles en précisant leur ancienneté
Ici, la liste existante peut rester visible pendant l’actualisation si l’entreprise autorise la consultation d’informations anciennes. Placez le message d’actualisation près de la liste et indiquez sa dernière vérification réussie. En cas d’échec, les anciennes entrées ne doivent pas être présentées, sans avertissement, comme récemment vérifiées.
Conserver la liste aide le personnel à se repérer, mais risque de fonder des décisions sur des modalités d’enlèvement modifiées. Convenez des actions exigeant une nouvelle vérification. Si la date change pendant le chargement, un résultat tardif du jour sélectionné auparavant ne doit pas remplacer la nouvelle vue.
Adaptez la reprise à l’échec rencontré
Android distingue les états de chargement, de contenu et d’erreur, et recommande de considérer le type d’erreur avant de réessayer. MDN précise aussi qu’il faut vérifier le statut des réponses Fetch : recevoir une réponse ne signifie pas nécessairement que la requête a réussi.
Demandez une démonstration de connexion interrompue, de service indisponible et de session exigeant une nouvelle authentification. Pour l’imprimerie, convenez d’une action utile dans chaque cas : recharger la liste, contacter le bureau ou se reconnecter. N’accusez pas la connexion du téléphone si la cause est inconnue. Préservez la date choisie pendant la reprise lorsque cela convient.
Convenez de l’arrêt des tentatives automatiques et du moyen de quitter l’écran. La reprise automatique réduit les manipulations lors de brèves interruptions ; des essais répétés sans limite claire peuvent laisser le personnel attendre sans savoir quoi faire.
Distinguez actualisation et modification d’un enregistrement
Recharger la liste et marquer un colis comme enlevé ont des conséquences différentes. MDN décrit l’idempotence comme le fait que des requêtes répétées produisent le même effet prévu côté serveur. Demandez comment cette propriété s’applique à l’enlèvement avant d’autoriser les nouvelles tentatives automatiques.
Pendant la répétition, interrompez la réponse après modification de l’enregistrement d’enlèvement. L’application doit aider à établir le résultat enregistré sans créer un autre événement d’enlèvement. Convenez de la transmission des cas non résolus au bureau et de la référence colis utilisable. Un bouton Réessayer générique ne doit pas masquer ces responsabilités distinctes.
Examinez les états dans un court scénario
Utilisez des colis fictifs et demandez à un membre du personnel d’expliquer chaque écran avant toute action. Consignez les formulations ambiguës avec les défauts techniques. Commencez par cette liste :
- Chargez un jour avec des enlèvements, puis un jour au résultat vide confirmé.
- Faites échouer le premier chargement, puis l’actualisation d’une liste déjà visible.
- Changez la date pendant le chargement ; vérifiez la concordance entre libellés et résultats.
- Reprenez par un nouvel essai ou une authentification et vérifiez le contexte sélectionné.
- Interrompez une mise à jour d’enlèvement et confirmez un seul événement métier enregistré.