Ignorer les modifications / annuler le comportement dans une application Web

Question

J'ai une application Web qui permet le multitâche. Si l'utilisateur se trouve sur une page et a apporté des modifications, lors de la navigation vers une autre page, la page précédente est ajoutée à une liste de tâches, qu'il peut ensuite revoir et continuer à apporter des modifications et à enregistrer.

Par conséquent, dans les cas où l'utilisateur a apporté des modifications et n'en souhaite plus, il devrait utiliser la fonction "Annuler les modifications" pour se débarrasser des modifications qu'il a apportées.

Dans mon cas, ce sont les caractéristiques de ces pages:

• Cliquer sur le bouton Discard changes Réinitialise simplement la page à son état initial, elle se comporte comme le bouton Reset dans les formulaires des sites Web plus anciens.
• En cliquant sur le bouton Discard changes, L'utilisateur ne navigue pas du tout vers une autre page. Il n'y a pas de page logique vers laquelle nous pouvons naviguer.
• Un clic sur discard changes Affiche un modal pour confirmer que l'utilisateur est sur le point de supprimer toutes ses modifications.
• Je suis essentiellement les directives de Luke Wroblewski pour les actions:

^{télécharger la source bmml - Wireframes créés avec Balsamiq Mockups}

Préoccupations:

• Lorsque vous cliquez sur discard changes Sur une page qui n'a pas été modifiée, cela ne fait rien. Dois-je masquer l'action Discard changes Et l'afficher uniquement lorsque les éléments d'interaction de la page ont été modifiés? Sinon, nous pouvons désactiver le lien, mais comment communiquer que le lien ne fonctionnera pas tant qu'ils n'auront pas modifié la page?

• Le discard changes Est conçu comme un lien selon l'article de Luke Wroblewski. Est-ce que cela va dérouter les utilisateurs qui pourraient s'attendre à être dirigés vers une autre page (en gardant à l'esprit qu'un modal s'affiche quand ils cliquent dessus)?

Answer 1

Pour répondre directement à vos questions:

• Les utilisateurs s'attendent à ce que quelque chose se produise s'ils autorisent une action, ou ils peuvent conclure que le système fonctionne mal ("J'appuie sur ce bouton, mais rien ne se passe"). Si une action n'entraîne aucun changement, son déclencheur doit être désactivé ou un message doit s'afficher, quelque chose comme "rien à jeter" (probablement un fondu div en dessous du bouton).

• Je déconseille fortement d'afficher un style de lien pour quelque chose qui n'est pas un lien - c'est très, très déroutant du point de vue de l'utilisateur. La distinction visuelle peut être obtenue de différentes manières. Bien que rien de tout cela ne soit présenté dans l'article de Luke, vous voudrez peut-être considérer:

  • Icône sur le bouton d'action principal. Les icônes ont tendance à attirer l'attention.
  • Texte plus audacieux couleur sur le bouton principal. Deux couleurs de bouton différentes (vert/gris; vert/bleu) peuvent être déroutantes pour les utilisateurs - s'il s'agit d'une action, les couleurs des boutons sont mieux cohérentes. La couleur du texte n'est pas si déroutante mais efficace. Vous pouvez également simplement avoir le texte du bouton principal en gras.
  • Bouton plus grand longueur pour le bouton principal.

Answer 2

Je suppose à partir de votre maquette et de sa formulation que l'utilisateur à un moment donné doit avoir sélectionné un élément quelque part et fait un choix actif pour "Modifier l'élément". Est-ce ainsi que cette vision est initiée?

Si tel est le cas, la manière conventionnelle de gérer le flux lorsqu'un utilisateur clique sur Enregistrer ou confirme un rejet serait de les lier à la vue initiale où ils ont lancé la modification.

Si ce contexte semble similaire à la façon dont cette partie de votre application est présentée, je changerais "Annuler les modifications" en "Annuler", de cette façon, l'application n'implique pas que l'utilisateur a apporté des modifications et il n'y a donc pas de confusion si le le contrôle est activé de manière omniprésente.

Cette approche résoudra également les problèmes de confusion pour l'utilisateur d'avoir un lien qui ne lie vraiment nulle part.

Vous dites qu'il n'y a pas de page logique à laquelle renvoyer l'utilisateur lors de l'annulation, mais je ne vois pas comment cela peut être. La liaison de l'utilisateur à l'endroit où la modification a été lancée doit être possible. Non?

Answer 3

• Si le contrôle réinitialise les valeurs sans naviguer, alors Reset est peut-être la meilleure étiquette. Généralement, Reset est censé ne pas naviguer.

• Même dans ce cas, j'utiliserais un bouton plutôt qu'un lien pour réinitialiser/supprimer. Trouvez un moyen de souligner moins le bouton, comme le suggestions par Izhaki .

• La commande Reset/Discard doit être désactivée s'il n'y a rien à réinitialiser. Contrairement au masquage, la désactivation indique à l'utilisateur que l'action peut être rendue disponible. Cela peut encourager les utilisateurs à effectuer des modifications dans le cas contraire, car ils ont peur de tout gâcher irrévocablement. La possibilité de désactiver est une autre raison d'utiliser une apparence de bouton plutôt qu'un lien car il n'y a pas d'apparence de "lien désactivé" standard. Pour plus d'informations sur la désactivation par rapport à la dissimulation, voir Contrôle de vos contrôles .

• Une fois que l'utilisateur a effectué une réinitialisation/suppression, envisagez de modifier le contrôle pour récupérer les modifications que l'utilisateur vient de supprimer (c'est-à-dire annuler la suppression). Cela éliminera la nécessité du message de confirmation. L'utilisateur peut également trouver utile de comparer dynamiquement les anciens et les nouveaux paramètres. Si vous enregistrez les paramètres précédents entre les sessions, vous n'aurez pas besoin de désactiver le bouton Réinitialiser (vous souhaiterez peut-être inclure l'horodatage des valeurs auxquelles il est réinitialisé).

• Envisagez une fonctionnalité Annuler/Rétablir plutôt que Réinitialiser, afin que les utilisateurs puissent annuler une séquence sélectionnée de modifications. Le fait que les utilisateurs ne naviguent pas avec Discard implique que vous vous attendez à ce que les utilisateurs apportent des modifications étendues et prolongées à la page (par exemple, après la suppression, ils continuent de modifier plutôt que d'abandonner et de s'en aller). L'annulation est préférable lorsqu'il est probable que les utilisateurs souhaitent annuler les trois dernières modifications, mais pas les 12 précédentes.

• Assurez-vous que votre conception graphique communique correctement la portée de la sauvegarde et de la réinitialisation. À partir de votre image filaire, je ne peux pas dire si Enregistrer enregistre uniquement les champs visibles ou modifie également les autres vues. Mettez Enregistrer/Réinitialiser dans la boîte de champs si elle est limitée à ces seuls champs; sinon, mettez-le sous les liens à gauche.

• Que se passe-t-il si l'utilisateur quitte cette page sans enregistrer ni supprimer? Affichez-vous un message obligeant l'utilisateur à choisir entre l'enregistrement ou la suppression en premier? Que se passe-t-il si l'utilisateur doit vérifier quelque chose sur une autre page afin de décider s'il doit d'abord enregistrer ou supprimer? Si cette application implique des modifications approfondies comme vous l'imaginez, vous souhaiterez peut-être utiliser une interface utilisateur à plusieurs fenêtres de style bureau, plutôt qu'une interface utilisateur à plusieurs pages de style Web. Voir Tournez la page . Une autre option consiste à enregistrer automatiquement chaque modification de champ. Désormais, vous n'avez plus besoin d'un bouton Enregistrer, et Annuler/Réinitialiser ressemble plus à une fonction de restauration.