Suivi de l'intention d'une modification (correction vs mise à jour)
Je crée une application basée sur un formulaire et je prévois de mettre en œuvre un mécanisme d'historique. Il fonctionnera de la même manière que la fonctionnalité d'historique fonctionne dans Google Docs . Les enregistrements actuels et historiques feront l'objet de rapports. Leur précision est importante.
Mon espoir était que le simple fait d'avoir un historique serait suffisant pour mon client, mais ils ont soulevé une préoccupation à laquelle je n'ai pas pensé: comment pouvons-nous distinguer une modification apportée parce que l'utilisateur corrigeait une erreur et une modification apportée car l'utilisateur ( mettait à jour les informations .
Maintenant, pour moi, je ne vois pas la valeur de cette fonctionnalité. J'ai l'impression qu'il n'y a pas de moyen simple de suivre l'intention d'un utilisateur sans encombrer son flux de travail.
Mais le client insiste sur le fait qu'il est nécessaire. Donc, je me demande comment mettre en œuvre cela de manière gracieuse. Le formulaire sera mis à jour fréquemment, je me demande donc s'il existe un moyen de le faire sans inviter l'utilisateur à expliquer pourquoi il effectue un changement chaque fois qu'il modifie un champ. Cela me semble juste fou et briserait leur flux de travail.
Des recherches ont-elles été effectuées sur ce sujet? Est-ce que quelqu'un d'autre a été confronté à ce problème et a découvert une solution intelligente?
Je pense qu'il est très difficile de différencier automatiquement une modification d'une mise à jour:
Avant:
Une pomme
Après:
Deux pommes
L'utilisateur est le seul à savoir si ce qu'il a fait est une correction ou une mise à jour.
Donc, le meilleur moyen de le suivre est que l'utilisateur le rend explicite:
- L'utilisateur indique la mise à jour
- L'utilisateur indique modifier
- L'utilisateur indique les deux
Selon votre cas, vous pourriez être intéressé par l'un ou l'autre. Quelques idées sur la façon dont cela pourrait être indiqué:
- L'utilisateur sélectionne l'option d'édition ou de mise à jour avant de commencer à taper. Cela pourrait présenter une interface utilisateur différente selon l'édition ou la mise à jour.
- L'utilisateur sélectionne l'option d'édition ou de mise à jour après avoir fini de taper. Cela pourrait être une case à cocher, par exemple. Le principal problème avec celui-ci est que l'utilisateur doit l'indiquer avant de fermer l'application. Il vous faudrait donc forcer une interaction de type "enregistrer la modification" "enregistrer la mise à jour" à la fermeture.
Confluence et Stack Exchange utilisent tous deux une zone de texte "Raison de la modification" pour permettre aux utilisateurs d'expliquer les raisons de la modification d'un morceau de texte.
Vous auriez besoin de faire des tests utilisateur pour découvrir si cela fonctionne pour vous ou devient trop onéreux.
Vous pourriez peut-être implémenter quelque chose de similaire mais fournir un texte pré-rempli, comme celui-ci (je n'ai pas accès à Sketch pour le moment, donc je ne peux pas le concevoir):
Raison de la modification [Erreur corrigée___]
Dans la boîte pourrait être:
Correction d'une erreur
Mise à jour des informations
- entrez le vôtre -
Un peu comme une liste déroulante hybride vue sur quelques applications. Que ce soit obligatoire devient la grande question à laquelle on ne peut répondre qu'en testant les utilisateurs,
La séparation entre les corrections et les mises à jour pourrait être utile pour nettoyer l'historique: en supposant que les corrections d'erreur ne sont pas intéressantes pour l'utilisateur, l'historique pourrait les masquer.
Cela dépendrait de vos besoins s'il y a une fonctionnalité pour atténuer les corrections ou si elles ne sont pas du tout incluses dans l'historique.
Dans cet esprit, vous pouvez inclure une case à cocher comme celle-ci dans le formulaire d'édition:
[] Correction mineure - ne pas inclure dans l'historique
De cette façon, vous pouvez réduire l'effort supplémentaire pour l'utilisateur au minimum - une seule option supplémentaire est présentée au lieu de deux ou plus. L'utilisateur pourrait même ignorer l'option sans conséquences graves. En outre, si le but et la conséquence de l'option sont clairement énoncés (à inclure dans l'historique ou non), l'utilisateur sera probablement plus susceptible d'être prêt à réfléchir à l'option.
En outre, je ne renverserais pas le sens de la case à cocher: cela pourrait être ennuyeux si l'option est négligée et, étonnamment, certaines entrées manquent dans l'historique.
Wikipedia utilise cette approche: https://en.wikipedia.org/wiki/Help:Editing