Meilleures pratiques: enregistrer et quitter dans l'interface utilisateur du logiciel
Cela a été discuté à plusieurs reprises ici pour les implémentations Web, mais jamais pour une application de bureau. Étant donné que nous avons une barre de titre/menu de fichiers/barre d'outils, etc. quelle est la meilleure pratique pour fermer une fenêtre et enregistrer?
Je crois que je connais la bonne réponse, mais c'est ce à quoi je fais face, je travaille sur une application Windows et quelqu'un a soulevé un "problème" d'être invité lors de la fermeture de la fenêtre à Enregistrer/Ne pas enregistrer/Annuler (uniquement si des modifications ont été apportées) assez standard non? si vous effectuez un changement, vous devez demander à l'utilisateur lors de la fermeture s'il voulait vraiment fermer avec/sans enregistrer ses modifications, après tout, c'est pour une application médicale où les médecins passent des heures à rédiger un diagnostic/résultant!
Ils ont demandé que j'ajoute un bouton "Quitter avec enregistrement" et "Quitter sans enregistrement" à notre barre d'outils existante qui contournerait l'invite. (se débarrasser du "clic supplémentaire")
Je ne peux pas justifier de mettre quelque chose d'aussi destructeur sur l'interface utilisateur, après tout, nous n'écrivons pas simplement des critiques Yelp ici!
J'ai vu des discussions sur le fait de ne jamais fusionner les fonctionnalités Enregistrer et Quitter et je crois que contourner cette invite va complètement à l'encontre de toutes les bonnes pratiques UX! Il n'y a pas de fonctionnalité d'annulation ou de version, donc cette invite est notre seul filet de sécurité pour rejeter les modifications.
Voici donc quelques questions:
- Les boutons Quitter/Fermer doivent-ils être placés sur l'interface utilisateur lorsqu'ils existent dans la barre de titre/menu de fichiers, etc.?
- Faut-il fusionner Exit et Save/Exit without Saving dans le logiciel?
- Devrait-il y avoir un bouton sur l'interface utilisateur pour contourner ces invites?
Toute aide justifiant ces normes serait très appréciée :) Merci
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Ils ont demandé que j'ajoute un bouton "Quitter avec enregistrement" et "Quitter sans enregistrement" à notre barre d'outils existante qui contournerait l'invite. (se débarrasser du "clic supplémentaire")
Le but de cette boîte de dialogue est de créer un clic supplémentaire!
Dans les situations où l'utilisateur pourrait perdre du travail, vous devez vous protéger contre un clic accidentel. C'est là que la boîte de dialogue Enregistrer/Ne pas enregistrer/Annuler entre en jeu. Elle donne à l'utilisateur les trois choix exacts dont il a besoin à ce moment.
L'utilisateur dit essentiellement "Hé, puis-je avoir un pistolet pour pouvoir me tirer une balle dans le pied?". Si vous insérez ces boutons, vous direz "Bien sûr, c'est parti!".
J'ai vu des boutons [Enregistrer] et [Annuler] avec des icônes pour les rendre plus évidents ... mais généralement même alors il y a généralement une invite d'avertissement sur l'annulation. Le problème est que si vous n'avez pas cette invite quelque part, l'utilisateur peut non seulement perdre du travail, mais n'a pas de retour sur lequel il a cliqué.
Une option consiste à fournir un paramètre utilisateur qui supprime la boîte de dialogue. Mais je demande généralement à l'utilisateur de sélectionner spécifiquement cette option. Ils assument la responsabilité de tout travail perdu à ce stade - et généralement les personnes qui choisissent cette option sont d'accord avec cela.
Donc, pour répondre explicitement aux questions: les boutons Quitter/Fermer doivent-ils être placés sur l'interface utilisateur lorsqu'ils existent dans la barre de titre/menu de fichiers, etc.? - Non, ils sont déjà sur l'interface utilisateur ... bien qu'en bas de l'écran, peut-être
Faut-il fusionner Exit et Save/Exit without Saving dans le logiciel? - Habituellement non. Si vous le faites, soyez cohérent.
Devrait-il y avoir un bouton sur l'interface utilisateur pour contourner ces invites? - Non, mais les options utilisateur pour contourner les invites sont correctes.
Il est prévu que le bouton Fermer soit toujours présent dans l'interface utilisateur - généralement sous la forme du petit bouton "x" dans le coin supérieur droit (ou en haut à gauche si vous êtes sur MacOS). Il n'est généralement pas nécessaire d'ajouter un bouton "Quitter" supplémentaire à la barre d'outils.
Maintenant, comme pour les autres boutons possibles, vous devez comprendre qu'il y a toujours une possibilité pour quelqu'un de cliquer sur ce bouton par erreur. C'est pourquoi tous les boutons qui effectuent des actions "dangereuses" sont livrés avec une fenêtre de confirmation. Avoir le bouton "Quitter sans enregistrer" est dangereux, même si cela peut parfois être pratique. La possibilité d'erreur est aggravée dans ce cas car il y a un bouton "Quitter avec sauvegarde" étiqueté de la même manière juste à côté.
Si je comprends bien, dans votre cas, vous avez une application où perdre son travail peut avoir des conséquences désastreuses. C'est pourquoi le meilleur plan d'action serait de souligner à votre client/patron la nécessité de la fonctionnalité Annuler/Versionner.
Le meilleur UX serait de:
- À la sortie, enregistrez les modifications automatiquement (sans aucune boîte de dialogue de confirmation - les gens sont notoirement mal à cliquer sur le bouton droit dans une boîte de confirmation, surtout après l'avoir vu plusieurs milliers de fois). Pour ce faire, présentez un écran de démarrage non interactif "sauvegarde des modifications", afin que les utilisateurs puissent apprendre que chaque fois qu'ils ferment l'application, toutes les modifications sont enregistrées automatiquement.
- Ajoutez le bouton "Annuler toutes les modifications" à la barre d'outils/menu, qui peut soit utiliser une confirmation contextuelle, soit permettre aux utilisateurs d'annuler cette action s'ils voient qu'ils ne voulaient pas appuyer sur ce bouton (dans ce cas, encore une fois, vous devez le faire évident pour l'utilisateur ce qui vient de se produire - par exemple, fournir une fenêtre contextuelle ou un écran de démarrage, etc.)
En général, les fenêtres contextuelles de confirmation (surtout si elles apparaissent sur une action fréquente) doivent être évitées à tout prix car: (1) elles ennuient les gens, (2) dans les rares occasions où elles sont censées sauver la journée, elles échouent travailler à cause de la force de l'habitude.