Lignes directrices pour savoir quand enregistrer automatiquement les paramètres par rapport au bouton «enregistrer»
Dans notre application Web, nous avons un certain nombre de pages concernant les paramètres utilisateur, dans différentes catégories. Pour la plupart d'entre eux, nous avons une page d'affichage avec un bouton/lien d'édition, qui les amène à un formulaire qui a un chemin de sortie annuler/enregistrer.
Cependant, pour une catégorie de paramètres, nous faisons quelque chose de différent. Pour les paramètres d'alertes et de notifications, nous affichons toutes les alertes qu'ils peuvent avoir, et présentons les commandes pour les activer/désactiver individuellement sur place, ainsi que changer leurs options respectives (par exemple, l'adresse e-mail à utiliser comme destination). Il n'y a pas de bouton/lien d'enregistrement, les modifications prennent effet immédiatement. Nous l'avons fait parce que le scénario typique est que l'utilisateur ne souhaite modifier que le seul paramètre d'alerte, plutôt que d'examiner et de modifier le lot en tant que lot. Nous avons également reconnu qu'un bouton "enregistrer" serait probablement en dessous du pli de la fenêtre et donc être manqué, et nous ne voulions vraiment pas mettre un bouton d'enregistrement contre chaque ensemble de paramètres d'alerte.
Nous craignons un peu que l'utilisateur ne soit perplexe face à l'absence de bouton de sauvegarde.
Quels sont les directives et arguments pour et contre certains changements de paramètres ayant un effet immédiat?
Vous devez être cohérent. Changer ce que les gens attendent de votre application est déroutant et ce n'est pas une bonne idée.
Si vous enregistrez automatiquement dans une section, pourquoi ne pas le faire dans toutes? S'il y a une bonne raison d'avoir le ou les boutons de sauvegarde, alors pourquoi ne pas les avoir sur toutes les pages de paramètres?
De nombreuses applications décomposent les pages de paramètres en regroupements logiques, puis disposent d'un bouton d'enregistrement pour chaque groupe. Je ne l'ai pas trouvé visuellement moche, et il est clair que faire. Certainement une meilleure option que seulement à la fin d'une longue liste.
La cohérence est définitivement un must. Cependant, si un groupe de paramètres justifie une action d'activation/désactivation plutôt que de taper réellement dans un ensemble de champs, il peut être correct de les enregistrer automatiquement à chaque changement.
Si vous utilisez un interrupteur à bascule, il est prévu qu'une fois que vous le feuilletez, l'action a été enregistrée ... Pensez à allumer ou éteindre une lumière. Vous pouvez symboliser qu'il est en cours d'enregistrement par une courte animation ou notification après qu'il a été basculé.
Vous devez également réfléchir au type d'utilisateurs dont vous disposez. S'attendent-ils à ce que les choses soient enregistrées automatiquement ou ont-ils besoin de la clôture psychologique pour terminer les actions en cliquant sur un bouton de sauvegarde?.
Il devient de plus en plus courant d'utiliser la sauvegarde automatique dans les applications. Google utilise l'enregistrement automatique pour la plupart de leurs applications, mais il utilise également un `` bouton d'enregistrement '' si nécessaire. Vous pourriez faire valoir que les utilisateurs "avertis du Web" seraient plus habitués à enregistrer automatiquement, mais les utilisateurs "moins avertis du Web" peuvent toujours s'attendre ou vouloir cliquer sur un bouton pour se sentir en sécurité que leurs efforts ont été enregistrés.
À mon avis, la sauvegarde automatique doit être évitée:
- Lorsqu'il y a des validations sur le formulaire
- Le formulaire permet plusieurs entrées
Nous avons conçu un module de feuille de temps pour un client qui enregistre automatiquement les entrées. Le client a adoré, mais les validations ont commencé et ont renversé la table. Certains champs devaient être obligatoires de manière dynamique, c'est-à-dire basés sur la sélection d'un autre champ. Si l'utilisateur ne capture pas les données obligatoires et s'éloigne, le système a discrètement ignoré l'entrée. Il n'y avait pas de solution facile et nous avons dû introduire le bouton "Enregistrer".
Outre la cohérence, il devrait également vérifier la plate-forme à partir de votre rapport d'analyse. Si la plupart de votre public provient d'un arrière-plan macOS, vous voudrez peut-être envisager d'utiliser la sauvegarde automatique, car le comportement de la plupart des applications et des boîtes de dialogue sur macOS consiste à enregistrer automatiquement.
Pour les utilisateurs de Windows, au moins la plupart seraient encore dans l'état d'esprit Windows 7 et inférieur, auquel cas la sauvegarde automatique n'est pas la norme pour la plupart des boîtes de dialogue.
Dans les temps anciens, les documents avaient deux états: l'état "enregistré" sur le disque et l'état en cours de modification. Je dirais que c'est souvent un bon modèle, même pour les applications en ligne. Pour éviter que des personnes ne perdent leur travail si leur connexion tombe en panne, il peut être bon que le serveur conserve une copie à jour de l'état en cours de modification, mais l'état "enregistré" ne doit généralement être mis à jour que si quelqu'un demande par l'affirmative cette.
Lors de la fermeture d'une fenêtre après la modification d'un état, un utilisateur doit être autorisé à abandonner les modifications, à les appliquer ou à les conserver comme brouillon. Si l'utilisateur opte pour ce dernier, ou si la connexion est perdue, la prochaine fois qu'une tentative est faite pour modifier l'état, l'utilisateur doit être explicitement formé que le système récupère un brouillon enregistré.
Je n'aime pas que certains types de modifications soient appliqués automatiquement à un formulaire et d'autres non; si certains changements doivent être appliqués automatiquement, je suggère que plutôt que d'utiliser [par exemple une case à cocher ou un bouton radio, on a des boutons de style "soumettre" pour "Activer XXX" ou "Régler le mode sur AAAA".