Confirmer l'annulation
J'ai une fenêtre, où l'utilisateur devra choisir d'annuler ou de sauvegarder.
Première:
J'ai des gens dans mon bureau qui disent que lorsque vous cliquez sur enregistrer, la fenêtre ne se fermera pas, mais vous recevrez un message de retour disant que les modifications sont enregistrées, puis vous devrez fermer votre fenêtre, car "il voudra peut-être enregistrer les modifications et avoir un aperçu, avant de fermer "
Serait-ce une meilleure approche d'avoir un bouton Annuler ou Enregistrer à la place? Et si vous cliquez sur enregistrer, la fenêtre se fermera.
Seconde:
Que se passe-t-il si l'utilisateur clique accidentellement sur Annuler alors qu'il voulait cliquer sur Enregistrer? Ai-je besoin d'une invite?
- L'utilisateur clique sur Enregistrer et le système ferme la fenêtre contextuelle? Oui. Afficher un message de rétroaction sur l'écran derrière comme:
Vos modifications sont enregistrées avec succès!
- Que faire si l'utilisateur clique accidentellement sur le bouton Annuler? Fermez la fenêtre contextuelle, mais le message de rétroaction à l'écran derrière devrait dire:
Vos modifications sont ignorées. Annuler
Les messages de rétroaction/notification jouent un rôle énorme dans de telles situations qui devraient être mises en œuvre en tant que meilleure pratique.
Bien que les utilisateurs n'aiment pas l'admettre, ils feront des erreurs. Allant du mauvais modèle mental de ce que fera un bouton à un simple mauvais clic. Il est donc important que les concepteurs tiennent compte de ces éventuelles erreurs lors de la conception des logiciels. Deux bonnes règles de base sont "toujours demander une confirmation lorsqu'une action des utilisateurs est irréversible" et "essayer de minimiser la perturbation du flux d'utilisateurs (les dialogues le font généralement)".
Maintenant, ces deux règles peuvent se contredire et c'est là que nous devons faire preuve de créativité et d'intelligence. Dans votre situation, je placerais à la fois la sauvegarde et le bouton annuler/fermer sur l'écran, car ils ont un objectif différent. Une fois que l'utilisateur a enregistré, je griserais (et désactiverais peut-être) le bouton Enregistrer et le soulignerais à nouveau après que les utilisateurs aient effectué une autre modification. Lorsque les utilisateurs essaient de fermer la fenêtre alors qu'il y a encore des modifications non enregistrées, j'invite une boîte de dialogue demandant à l'utilisateur s'il souhaite enregistrer ou ignorer les modifications. De cette façon, la quantité de dialogues est minimisée mais l'utilisateur ne peut pas ignorer les modifications involontairement. C'est d'ailleurs ainsi que la plupart des logiciels gèrent la fermeture d'une application alors qu'il reste des documents non enregistrés ouverts.
Vous devriez peut-être enregistrer automatiquement les brouillons?
De cette façon, l'utilisateur est pris de tout ce qui pourrait perturber son travail, qu'il s'agisse d'un mauvais clic ou d'une panne de courant.
Comme vous dites que c'est "certainement plus que quelques champs" (commentaire OP), vous devriez vraiment considérer cela comme une option.
Stack Exchange le fait bien, il n'y a pas d'annulation, juste un message et si je pars et reviens, mon message est toujours là.
J'irais avec un combo de réponses de Dipak et Toni. Je pense que le juste milieu se situe entre les deux. Ce qui devrait se produire ici dépend entièrement de ce que vos utilisateurs s'attendent à ce qu'il se passe. C'est là que les tests utilisateurs entrent en jeu. Il n'y a vraiment aucun substitut pour savoir qui vos utilisateurs sont: ce qu'ils pensent, comment ils se sentent, comment ils fonctionnent, etc.
Cela dit, il y a toujours évidemment des généralisations qui peuvent être faites pour n'importe quel utilisateur. Tout d'abord, reconnaissez qu'il y a une nette différence entre création quelque chose et modification quelque chose. Si je crée quelque chose de nouveau, je veux que mon travail soit sauvegardé à tout prix. Il n'y a pas de retour en arrière et la barrière à l'entrée est généralement plus élevée qu'avec les modifications. Ici, vous invitez l'utilisateur à confirmer qu'il souhaite annuler ou, comme Toni l'indique, utilisez le stockage local pour enregistrer les données saisies, donc s'ils rouvrent le formulaire, ils reviennent à l'endroit où ils se sont arrêtés. Avec ce dernier, il n'est pas nécessaire d'inviter l'utilisateur, mais cela peut aider à réduire l'anxiété temporaire s'il annule accidentellement et ne se rend pas compte que vous enregistrez en silence son travail.
Avec l'édition, c'est un peu différent. Ici, en tant qu'utilisateur, je attendez annulation pour revenir. En d'autres termes, il n'est plus logique d'enregistrer les modifications des utilisateurs sur le stockage local et de les conserver après l'annulation. Si je change quelque chose d'irréparablement et que je veux revenir à l'ancienne version, l'annulation est ma trappe d'échappement. Vous devriez certainement, maintenant, inviter l'utilisateur à confirmer, afin qu'un clic accidentel n'annule pas son travail.
La meilleure option à mon avis est d'avoir à la fois des boutons Enregistrer et Supprimer. Si l'utilisateur clique sur Enregistrer, la fenêtre contextuelle devrait se fermer et un message d'information indiquant "Vos modifications ont été enregistrées" devrait s'afficher et disparaîtra en 3 secondes. Si l'utilisateur clique sur Ignorer, afficher un message de confirmation indiquant "Toutes les modifications que vous avez apportées seront rejetées, êtes-vous sûr"? Et les boutons indiquant Oui et Non. En cliquant sur non, il reviendra en mode édition.