Un formulaire avec enregistrement continu a-t-il besoin d'un bouton "Enregistrer"?
Je conçois une application web avec beaucoup de formulaires et je me demandais comment améliorer le remplissage. Le modèle classique est: remplir, remplir, remplir, Enregistrer
Avez-vous testé un formulaire qui enregistre automatiquement chaque champ une fois que vous l'avez mis au point? Dans ce cas, le bouton Enregistrer n'est plus nécessaire mais peut-être que l'utilisateur en est rassuré.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
En tant qu'utilisateur, je n'aime pas du tout cette idée.
Il existe 2 scénarios:
- Création d'une entité
- Modification d'une entité
Si je suis en mode création pour dire ... un contact ... dès que je tape "Dave" dans un champ de prénom, il faudrait créer une entité ... si je décide non ... je suis ne va pas ajouter Dave après tout, normalement je quitte simplement l'écran et tout va bien, mais dans ce cas, vous avez une entrée partielle et indésirable dans le système que l'utilisateur ne voulait pas.
Si je suis en mode édition, je peux commencer à faire des changements ... alors whoops attendez ... J'ai entré les mauvaises données (ou saisies dans le mauvais champ) ... pas de problème, jetez simplement mes modifications et rechargez le forme! ... attendez non, ne peut pas faire cela car il a remplacé automatiquement.
La grande chose à propos d'un bouton Enregistrer est que l'utilisateur vous donne des instructions explicites pour enregistrer les données jusqu'à ce que l'utilisateur s'attende à ce qu'il ne se soit engagé sur rien.
J'ai posté une réponse ici qui, je pense, répond à cette préoccupation en détail.
L'enregistrement automatique est une excellente fonctionnalité où le travail de l'utilisateur peut prendre un certain temps (comme les formulaires longs et l'édition de documents). Vous leur épargnez la surcharge mentale de ne pas oublier d'enregistrer au fur et à mesure.
N'envoyez pas le mauvais message
Si votre système enregistre progressivement au fur et à mesure que le travail est terminé, mais vous fournissez également un Save , l'utilisateur se demande ce que fait réellement la sauvegarde automatique.
Est-ce vraiment sauvé?
Dois-je également cliquer sur ce bouton?
Si je clique Save vais-je laisser le formulaire?
Pourquoi mettre vos utilisateurs dans une telle anxiété? Décidez-vous et choisissez le bon schéma: sauvegarde manuelle ou automatique.
Repères visuels clairs
Étant donné que les formulaires sont souvent enregistrés manuellement (pour le meilleur ou pour le pire), vous devez indiquer très clairement à vos utilisateurs si vous décidez d'aller à l'encontre de cela. Voici quelques indices visuels que j'ai utilisés et qui ont bien fonctionné.
Fournir une issue
Les utilisateurs changent parfois (souvent?) D'avis. Si vous avez enregistré leur travail en cours de route, vous devez fournir un moyen simple d'inverser ce travail. Il existe plusieurs fonctionnalités qui font que cela fonctionne bien, en particulier dans les applications critiques pour les données.
- Annulation au niveau du champ
- Annuler et ignorer toutes les modifications
- Journal des modifications avec possibilité de revenir en arrière (pour les administrateurs)
Je pense qu'il doit y avoir un seul point où je peux confirmer TOUT mon entrée a été correctement enregistrée. Votre exemple d'enregistrement automatique n'a pas cela - imaginez un formulaire plus long et plus compliqué, et vous mettez une valeur non valide dans l'un des champs, vous le corrigez, il y a un petit délai entre la saisie et l'enregistrement, etc. la connexion n'est pas fiable et les enregistrements au hasard échouent, etc ... Comment savoir avec certitude que tout est correctement enregistré?
Je pense que vous devriez considérer comment Google Docs et Office 365 le font. Dans la barre d'outils, ils ont des étiquettes qui indiquent l'état (par exemple "Enregistré il y a 2 minutes", "Enregistrement ...", "Non enregistré - aucune connexion au serveur perdue, tentative de reconnexion" (ou quelque chose comme ça).
Pour votre formulaire, vous pouvez le placer au bas du formulaire près de l'endroit où vous auriez placé le bouton Enregistrer. Les informations pourraient être:
- "Enregistrer les modifications..."
- "Toutes les valeurs ont été enregistrées automatiquement il y a X minutes"
- "Certaines valeurs n'ont pas été enregistrées car elles n'ont pas été correctement renseignées, veuillez vérifier le formulaire."
- "Certaines valeurs n'ont pas été enregistrées car (erreur)"
Je pense que cela devrait être au moins aussi important qu'un bouton Enregistrer aurait été - peut-être une grande coche verte, un X brillant en cas d'échec, un graphique de spinner s'il progresse (à côté de la description du texte)
Je l'ai essayé dans un formulaire d'enregistrement automatique, mais j'ai constaté que la présence d'un bouton au bas d'un formulaire était logique et attendue pour la plupart des utilisateurs. Dans mon cas, ce serait un bouton "publier et fermer". Les utilisateurs peuvent ne pas être sûrs que leur contenu soit enregistré sans approbation. C'est pourquoi c'est une bonne idée d'avoir le bouton Enregistrer. Il donne aux utilisateurs un sentiment de contrôle sur leur contenu.
C'est comme le bouton "Je me sens chanceux" de Google. Les gens s'attendent à ce qu'il soit là même s'il n'affiche pas de résultats différents que lorsque vous utilisez le "bouton de recherche normal". En fait, si vous avez activé javascript, vous n'avez même pas la possibilité d'appuyer dessus, car Google affiche les résultats lorsque vous commencez à taper.
Voir cette question pour en savoir plus.
Parfois, les choses n'existent pas parce qu'elles ont toujours un sens, mais parce que leur présence est une opportunité - c'est-à-dire que cela fonctionne non pas parce que c'est bon, mais parce que le visiteur comprend ce que c'est, ce qu'il fait et comment l'utiliser, parce qu'il a été inculqué au fil des ans avec cette connaissance.
Les formulaires sans bouton d'enregistrement sont devenus plus courants récemment en fonction de mon expérience personnelle.
J'ai observé plus d'entreprises utilisant de tels formulaires sans boutons d'enregistrement. Un domaine qui semble courant est celui des "paramètres".
Au départ, j'ai trouvé ces formes très déroutantes - en gros, "où est le bouton de sauvegarde", l'anxiété. Au départ, j'allais dans d'autres onglets, je me déconnectais, je me connectais, je m'assurais que les données restaient.
De même pour les messages de rétroaction ajax pour les changements tels qu'ils sont apportés - au départ, j'avais besoin et je voulais cette rétroaction. Au fil du temps, je me suis habitué à de nouveaux formulaires qui ne me donnaient pas cette rétroaction. Je préfère toujours le feedback moi-même mais je me suis habitué aux formulaires où je ne les reçois pas
Ceci est un exemple d'une catégorie intéressante - la saisie des utilisateurs qui ne fonctionne pas bien pour les gens en raison de leur modèle mental existant, mais une fois qu'ils s'y sont habitués, leur modèle mental change et le changement devient acceptable - même souhaitable!
Si vous pensez vraiment que la sauvegarde automatique est la voie à suivre, je dirais de ne pas mettre de bouton de sauvegarde. Mais assurez-vous d'indiquer en quelque sorte que les données sont enregistrées.
Comme scunliffe l'a souligné, pour le cas d'utilisation que vous avez montré, la sauvegarde automatique est une mauvaise idée. Si quelqu'un recule, un partiel sera enregistré, potentiellement pour toujours. Pour éviter cela, vous pouvez demander à l'utilisateur de sauvegarder ou non le partiel avant de quitter la page, mais à mon avis, cela dégraderait davantage l'expérience utilisateur que d'avoir un bouton de sauvegarde.
Outre les problèmes d'expérience utilisateur indiqués dans d'autres réponses, vous devez prendre en compte les problèmes performance et security ici:
- Chaque fois que votre événement d'enregistrement automatique se déclenche, votre formulaire exécute la commande d'enregistrement dans la base de données . Maintenant, si vous avez 10 champs dans votre formulaire, vous devez vous attendre à ce que votre serveur exécute cette commande au moins 10 fois plus que d'avoir un bouton Enregistrer . Puisque vous avez une page Web, vous avez le potentiel de toucher des millions d'utilisateurs, ce qui n'est pas anodin.
- Étant donné que votre page demande toujours d'envoyer/recevoir de petits paquets de données, le système de l'utilisateur peut allouer une quantité inutile de ressources de communication de données à votre page/formulaire.
- Puisque vous avez presque cédé le contrôle de l'événement d'enregistrement dans la base de données , vous ne pouviez pas, au moins de manière simple, vérifier si l'expéditeur était un humain ou une paix de code automatisée. Par conséquent, votre page peut présenter un risque plus élevé d'attaques par déni de service .
- Comme l'a souligné scunliffe, votre base de données peut contenir des milliers de données de rebut partielles, ce qui réduit la qualité des données et les performances globales de la base de données.
Enfin, mais non des moindres: " ... jusqu'à ce moment, l'utilisateur s'attend à ce qu'il ne s'engage à rien. " (scunlife)
Utilise les deux. Sauf que l'enregistrement automatique ne doit pas aller directement à l'entrée nouvelle/modifiée, mais à sa version provisoire. Si l'utilisateur ferme le formulaire pour une raison quelconque (ou en cas de plantage) et décide ensuite qu'il souhaite ces modifications après tout - vous retirez le brouillon enregistré et laissez l'utilisateur continuer d'où il est parti.
Les boutons situés sous le formulaire doivent permettre à l'utilisateur de finaliser les modifications, c'est-à-dire de valider la base, de publier, d'envoyer quoi que ce soit et de revenir à la dernière version validée, le cas échéant.
Cela peut être différent dans certains scénarios, mais souvent des données incomplètes ne sont pas utiles et peuvent même être déroutantes, surtout si l'utilisateur les publie d'une manière ou d'une autre pour les voir plutôt que de modifier une base de données personnelle, il est donc préférable d'en avoir encore moyen pour l'éditeur de signaler "il est prêt pour la consommation" au lieu de pousser chaque petite chose vers le monde extérieur automatiquement.
C'est, l'OMI, est l'approche la plus intuitive. C'est ainsi que GMail fonctionne avec la sauvegarde automatique de vos brouillons tout le temps, mais en n'envoyant que lorsque vous le lui demandez directement. Même le formulaire de commentaire dans lequel j'écris cette réponse fonctionne actuellement de cette façon - tout ce que je tape est enregistré en continu en tant que brouillon et jamais perdu, mais je dois pousser explicitement "publier votre réponse" lorsque j'ai terminé.
Oui s'il vous plaît! Je travaille avec un programme qui enregistre automatiquement lorsque j'appuie sur Entrée. Même en sachant cela, je rouvrirai souvent la page pour vérifier qu'elle a enregistré ce que j'ai entré/modifié. Cela crée plus de travail. L'absence d'une réponse claire et concise et le fait de ne pas vouloir la bousculer m'y obligent. S'ils mettaient une sauvegarde ou offraient un bouton, cela me ferait plaisir. Alors voilà, un exemple concret de la raison pour laquelle vous devriez le faire.