Désactiver le bouton d'enregistrement jusqu'à ce que des modifications soient apportées?
Nous avons une liste de choses compliquées sur lesquelles l'utilisateur peut cliquer pour obtenir une nouvelle vue dans laquelle il peut modifier tous les détails stockés pour cette chose.
La vue d'édition a déjà un mécanisme de sortie Cancel (par défaut pour tous nos formulaires d'édition) et un bouton save (qui à la fois enregistre et revient à la liste).
Le bouton Save doit-il être désactivé jusqu'à ce que des modifications soient apportées à l'un des détails?
Dans une application que j'ai créée il y a une dizaine d'années, la désactivation est l'approche que j'ai adoptée. Chaque formulaire a un bouton Enregistrer, Annuler et Fermer. L'enregistrement et l'annulation sont tous deux désactivés jusqu'à ce que des modifications soient apportées. Fermer est toujours disponible et invite à enregistrer ou à annuler lorsque des modifications ont été apportées.
À l'époque, je pensais que c'était la bonne façon de faire les choses. Maintenant, chaque fois que j'ouvre un formulaire d'édition et que je veux qu'il disparaisse, cela me contrarie de devoir utiliser close et ne peut pas simplement utiliser ok ou annuler.
Je pense que le formulaire devrait comprendre quoi faire:
- ok + changements => enregistrer
- ok + aucun changement => fermer
- annuler + modifications => fermer
- annuler + aucun changement => fermer
- fermer + changements => Demander
- fermer + aucun changement => fermer
Le bouton de fermeture sera supprimé dans un proche avenir, mais la fonctionnalité et le comportement restent comme sur un bureau, vous aurez toujours le bouton "X" par lequel vous pouvez fermer un formulaire. L'inclusion d'un bouton de fermeture séparé devait vraiment fournir une cible plus grande ...
Modifier
Juste pour faire bonne mesure, voici le point de vue de Joel sur la désactivation/masquage des éléments de menu (qui est "NE PAS") http://www.joelonsoftware.com/items/2008/07/01.html
J'en suis venu à la conclusion que cela s'applique également aux boutons.
En réponse au commentaire de JohnGB
Le bouton de retour dans un navigateur ne soumet jamais un formulaire, il a toujours la signification implicite d'une annulation. Toute application, que ce soit sur un ordinateur de bureau, dans un navigateur ou sur un mobile, qui prend en charge la navigation "retour" devrait vraiment respecter cette norme non écrite. Et peu importe que vous suiviez une sauvegarde explicite ou un paradigme de sauvegarde automatique. Cela signifie simplement qu'en utilisant un paradigme de sauvegarde explicite, vous devrez fournir un bouton "enregistrer" et dans un paradigme de sauvegarde automatique, "retour" est juste ce "retour".
Le bouton de sauvegarde est devenu le bouton Skinner Box pour beaucoup de gens grâce à un logiciel terrible, terrible qui n'a jamais enregistré automatiquement le travail des gens pendant 20 bonnes années de logiciel populaire. Je n'aime pas continuer à former les gens à appuyer sur ce bouton, mais il n'y a rien de plus aggravant que de trouver que votre application n'a pas simplement enregistré ce que vous avez fait.
J'ai trouvé le bouton Enregistrer placebo de Google Doc une solution intéressante; le bouton d'enregistrement était là, mais le document a été enregistré automatiquement. Pendant un certain temps, vous pouvez cliquer sur le bouton inutile appelé "enregistrer", mais maintenant ils l'ont remplacé par une notification:
Après l'avoir enregistré, il vous le fait savoir, et au survol si vous essayez de cliquer sur le "bouton", il explique pourquoi vous ne pouvez pas l'utiliser:
Si vous êtes prêt à désactiver le bouton, faites savoir aux utilisateurs pourquoi le bouton est désactivé, c'est important. Autant que je déteste le suggérer, la solution la plus simple pour l'utilisateur et l'application, en particulier pour les utilisateurs plus âgés ou moins techniques est de simplement laisser le bouton de sauvegarde là et de les laisser cliquer comme des fous. Ils pourraient perdre 5 secondes en cliquant dessus toutes les 5 minutes, mais ils auront la tranquillité d'esprit, et c'est très difficile à favoriser dans une application.
Vous supposez que les utilisateurs n'enregistrent jamais les modifications des données qu'ils n'ont pas modifiées. Ils le font - tout le temps. En partie comme un réflexe inconscient, en partie parce qu'ils ne se souviennent pas toujours de ce qu'ils ont édité, et en partie parce qu'ils craignent le risque de perdre tellement leur travail, ils économisent religieusement.
Je quitte tout le temps les formulaires via la fonction de sauvegarde. C'est une habitude durement apprise, et un formulaire qui ne prend pas en charge ce flux de travail semble choquant. Cela me ferait également me méfier de l'application (que se passe-t-il si le formulaire n'a tout simplement pas détecté mes modifications? Et si le bouton Enregistrer est manquant parce que l'application est cassée?).
Je ne voudrais pas ça. Mais je ne suis pas votre utilisateur. Essayez quelques tests A/B et découvrez par vous-même.
Absolument. Un bouton activé qui ne fait rien n'aide personne.
Bien que dans ce cas particulier, il semble que l'étiquette doit être "appliquer" ou "OK".
Si vos formulaires de détail sont relativement simples, je suggérerais simplement d'utiliser les boutons OK/Annuler que les utilisateurs connaissent si bien (les deux boutons restant actifs tout le temps). Les utilisateurs comprennent que s'ils cliquent sur OK, toutes les modifications seront enregistrées et la boîte de dialogue se fermera. S'ils cliquent sur Annuler, les modifications seront annulées et la boîte de dialogue se fermera.
Si vos formulaires détaillés affichent une quantité importante de données (où l'utilisateur aurait peur de perdre des données s'il n'enregistre pas assez souvent); c'est seulement alors que j'opterais pour l'utilisation des boutons Enregistrer/Annuler/Annuler, les boutons Enregistrer et Annuler devenant actifs s'il y a des modifications non enregistrées. Et comme Marjan l'a mentionné, invite l'utilisateur s'il clique sur Annuler et qu'il y a des modifications non enregistrées.
J'aime un peu l'approche de Microsoft pour utiliser la combinaison OK-Cancel-Apply sur leurs formulaires d'entrée. Le bouton Apply est désactivé tant que rien n'a changé et le bouton OK appliquera automatiquement les modifications s'il y a des modifications.
C'est intuitif et clair ce que fait chaque bouton et c'est familier à beaucoup de gens.