Wizard interaction - laquelle des méthodes suivantes sert le mieux l'utilisateur?
L'un des formats classiques de l'assistant est le suivant:
J'ai également rencontré une version légèrement différente utilisant le paradigme maître-détail, où l'étape appropriée est mise en évidence à gauche:
Si l'assistant ne réside pas dans une boîte de dialogue, mais peut s'étendre sur une page entière, on peut également utiliser quelque chose comme le suivant.
Avez-vous une préférence/voyez-vous une différence substantielle entre eux (en particulier le 1er et le 2e)?
Y a-t-il un autre type de format d'assistant que vous avez utilisé vous-même ou vu ailleurs qui fait un meilleur travail?
Votre premier exemple ressemble plus à des onglets qu'à un assistant. C'est un peu déroutant car l'assistant a l'ordre strict des étapes par opposition aux onglets où vous pouvez visiter les sections dans n'importe quel ordre.
Votre troisième exemple pourrait difficilement être appelé assistant, car l'assistant classique n'affiche qu'une seule étape. Dans votre cas, c'est quelque chose comme un formulaire avec des groupes de contrôles.
Alors, qu'est-ce qui est important avec l'assistant? L'utilisateur doit comprendre quelles sont les étapes et où il se trouve exactement (combien d'étapes a-t-il franchies et combien il lui en reste). Cela signifie que si vous fournissez toutes ces informations, l'assistant peut afficher ce que vous voulez. Ce n'est pas un gros problème si les noms des étapes sont sur le côté gauche ou en haut.
Je suis d'accord avec Kostya, celui à onglets ne ressemble pas à un sorcier et prête à confusion.
Ma préférence personnelle est de ne pas montrer du tout la page particulière sur laquelle ils se trouvent. Mais j'aime tout de même faire des commentaires sur le nombre d'étapes. Je voudrais afficher Étape 1 sur 5, ou afficher une barre de progression visuelle agréable, par exemple.
Cela dépend bien sûr de votre définition de "l'assistant" et du groupe d'utilisateurs et de la tâche que vous essayez d'effectuer - donc une réponse générique n'est pas vraiment possible.
Pour donner un exemple: j'ai utilisé avec succès le style à onglets dans un contexte où les données saisies par l'utilisateur n'étaient pas nécessairement linéaires A-> B-> C-> D - mais souvent. Ainsi, le chemin "heureux" normal serait ABCD, mais pourrait parfois être CABD ou similaire.
(L'utilisateur capturait des informations auprès d'un tiers et les saisissait dans le système. Normalement, il les invitait à utiliser les formulaires ABCD, mais parfois, l'utilisateur leur fournissait des informations de manière désordonnée et hors séquence et il souhaitait passer à une seule section ou autre.)
Nous voulions donc:
a) donner une orientation solide sur le chemin normal à travers
b) permettre à l'utilisateur de sauter en cas de besoin
c) montrer à l'utilisateur que sauter n'est pas "mauvais" en lui donnant une interface utilisateur familière
Puisqu'il y avait des interfaces à onglets ailleurs dans l'application (qui était une application client/serveur de bureau - pas une application Web), les onglets étaient bien testés par rapport à la forme longue précédente, car les gens devaient passer moins de temps à faire défiler le chemin heureux, et pouvaient naviguer vers la zone appropriée très rapidement lorsqu'ils devaient sauter.
Nous avons également ajouté des indicateurs de couleur visuels sur les onglets (couleur et police) après la première série de tests pour aider à indiquer quand un onglet était intact/partiellement terminé/terminé.
Je préfère celui-ci:
Je ne vois aucune différence fondamentale. Évidemment, le deuxième choix donne plus d'espace aux étapes au cas où il y en aurait beaucoup (ce qui est généralement mauvais). Cela dépend du cas, je suppose. Comme toujours. Et comme l'a dit Kostya, le premier exemple de sorcier ne ressemble pas au sorcier traditionnel. Si je me souviens bien, la norme Microsoft d'origine n'avait même pas d'indicateur pour montrer sur quelle page vous vous trouviez.
Je pense que ce que nous devrions demander à la place, c'est que tout type d'assistant sert bien l'utilisateur? Passer par un assistant est lent et poser des questions à l'utilisateur et lui tenir la main peut ne pas donner la meilleure expérience utilisateur. Et je ne dis pas que vous ne devriez pas les utiliser, mais vous devriez penser qu'ils sont vraiment la meilleure façon.
J'ai la même préférence que Hisham pour montrer les progrès dans un format plus discret, toujours assez clair mais prenant moins de place.
Selon la flexibilité de l'assistant sur lequel vous travaillez, je suggérerais également un bouton "Retour".
Si vous souhaitez afficher progress, utilisez simplement un affichage Step m/N .
Si vous souhaitez permettre à l'utilisateur de passer à des pages spécifiques, l'un de ces formats est logique.
J'ai eu un cas où l'ajout du bouton Suivant à une interface à onglets a créé une confiance sur ce qu'il fallait faire ensuite. (Pas plus que le test d'utilisabilité du couloir).
Les utilisateurs avancés peuvent facilement sauter les pages dont ils n'ont pas besoin, les débutants sont guidés par le "Suivant". (Mais sachez que ce n'était pas un assistant étendu par des onglets, mais des onglets étendus par un bouton suivant.)
La 3ème version se démarque en ne se concentrant pas sur une partie des informations. C'est mauvais dans la plupart des scénarios où vous utiliseriez une interface à onglets ou un assistant. Cela pourrait être correct si vous devez passer par toutes les options et que la plupart sont généralement prises.
Fonctionnellement, le 1er et le 2e sont identiques, donc les attentes des utilisateurs prendront la bouchée.
Les deux ont besoin de l'indicateur Suivant pour montrer à l'utilisateur que le processus n'est pas terminé - comme sans suivant , ils sont tous deux utilisés pour les boîtes de dialogue d'options où la page agit comme un filtre, pas comme une étape.
Le 2ème me plaît visuellement. Il autoriserait également les sous-pages en retrait.