web-dev-qa-db-fra.com

Opérations en deux étapes et conventions relatives aux boutons

Notre application Web comporte trois opérations différentes qui se déroulent comme suit:

  1. L'utilisateur est présenté avec une fenêtre contextuelle où différents paramètres sont sélectionnés.
  2. L'utilisateur peut cliquer sur un bouton étiqueté avec l'opération (ex: "Fusionner") ou "Annuler".
  3. Si l'utilisateur va de l'avant, l'application traite l'opération qui peut prendre quelques instants et une autre fenêtre contextuelle est présentée qui résume ce qui va se passer. À ce stade, l'opération n'est pas validée et l'utilisateur peut choisir de poursuivre ou d'annuler.

C'est là que nos trois opérations ne sont pas alignées. Dans un cas, le choix est Continuer/Annuler, dans un autre c'est Terminé/Abandonner et enfin nous avons Finaliser/Annuler.

Lequel est le meilleur? Existe-t-il une meilleure alternative? Si oui, des arguments à l'appui?

3
carrier

J'essaie généralement de m'éloigner des étiquettes de boutons génériques comme celles-ci et d'être aussi précis que possible. Vos étiquettes me semblent très "base de données" et me rappellent les outils conçus par les programmeurs pour les domaines très abstraits (comme ... les éditeurs de bases de données).

Voir cette question connexe sur le positionnement du bouton OK/annuler pour plus de discussion:

OK/Annuler à gauche/droite?

Dans ma réponse, j'ai lié à la recherche de Jakob Nielsen sur les boutons OK/Annuler , où il note que:

Il est souvent préférable de nommer un bouton pour expliquer ce qu'il fait que d'utiliser une étiquette générique (comme "OK"). Une étiquette explicite sert d '"aide juste à temps", donnant aux utilisateurs plus de confiance dans la sélection de l'action correcte.

Par exemple, quelques exemples:

Vous pouvez également envisager de laisser de côté l'alternative . Dans certains cas, cela peut avoir un sens. Je pense qu'une option "annuler" est bonne à inclure si l'utilisateur est sur le point de prendre un engagement important, comme acheter quelque chose ou une opération CRUD impliquant beaucoup de données.

Mais pour quelque chose de simple, comme le tweet, surtout quand il y a un retour en arrière facile après l'opération de validation, il devrait être correct de laisser de côté le bouton explicite "annuler" car il est généralement évident que ne pas continuer ne validera rien.

Un bon exemple est le formulaire de commentaire de StackExchange, qui a juste un bouton "Ajouter un commentaire" et aucun moyen de masquer le formulaire ou d'annuler. Vous ne voulez pas ajouter de commentaire? Ne cliquez pas sur "Ajouter un commentaire"!

10
Rahul

Cela ressemble à un assistant. Voici un exemple:

  1. L'utilisateur lance la fonction de fusion
  2. Une fenêtre contextuelle apparaît, intitulée Merge .
    Il contient les paramètres de la commande et Next > et Cancel.
  3. L'utilisateur modifie les paramètres et clique sur Next >.
    L'application traite l'opération pendant quelques instants.
  4. La page suivante de l'assistant apparaît. Il a les boutons Finish et Cancel.
    Si l'utilisateur clique sur Finish alors l'opération est terminée; Cancel annule le tout.

Une autre approche consiste à en faire un processus en une seule étape, mais autorisez l'annulation. Cela peut ou non être possible, selon l'opération.

  1. L'utilisateur lance la fonction de fusion
  2. Une fenêtre contextuelle apparaît, contenant les paramètres de la commande et les boutons Merge et Cancel.
  3. L'utilisateur modifie les paramètres et clique sur Merge.
    L'application traite l'opération pendant quelques instants et la termine.
  4. L'écran affiche les résultats de l'opération et comprend un bouton Undo. Si l'utilisateur clique sur Undo, l'opération est annulée.
3
Bennett McElwee

Je voudrais faire deux remarques:

1) Si le processus de fusion proprement dit est lancé après le deuxième écran (avec des résumés), le bouton "Fusionner" devrait se trouver sur ce deuxième écran. Ce qui m'amène à dire que sur le premier, le bouton devrait dire quelque chose comme "Aperçu des résultats de la fusion" ou similaire parce que c'est le prochain résultat que l'utilisateur obtiendra, dans le flux de processus qu'il/elle a commencé.

2) Il s'agit d'une sorte de suggestion effrayante, mais il serait peut-être judicieux d'avoir trois boutons sur le premier écran: "Aperçu fusionner", "Annuler" et "Fusionner sans aperçu". Cela ferait gagner du temps à l'utilisateur qui sait ce qu'il est sur le point de faire et ne veut pas attendre les statistiques et s'engager ensuite dans sa décision. Juste une idée...

0
Jüri

Si vous n'effectuez pas réellement la "fusion" après avoir cliqué sur Fusionner, vous ne devriez pas l'appeler Fusionner.

Souvent, ce qui est utilisé dans un formulaire en plusieurs étapes est une convention Continuer/Soumettre. Continuer implique que vous devez passer à l'étape suivante, mais cela n'implique pas qu'un engagement soit encore placé.

Dans le cas d'une boutique en ligne, le paiement nécessite souvent que l'utilisateur passe par quelques formulaires, fournissant l'adresse et les détails de paiement. Ce n'est que sur la page où ils peuvent enfin confirmer la commande qu'un bouton "Passer la commande" ou "S'engager à acheter" est utilisé.

J'utiliserais soit un bouton "Aperçu de la fusion" ou un bouton "Continuer", puis sur la page où ils s'engagent, utiliser un bouton "Effectuer la fusion" ou "Soumettre".

0
Nick Bedford