Utilisation d'un Wizard pour la saisie initiale et l'édition ultérieure
Mon application Windows utilise des assistants pour créer des objets métier comme des personnes ou des biens immobiliers.
Le Wizard est parfait, car il permet la saisie dans l'ordre le plus logique avec la possibilité d'afficher les données dans des groupes de formulaires clairement organisés. Il permet également des étapes de traitement et de validation entre les pages Wizard. Certaines entrées dépendent d'autres entrées, mais ce n'est pas un problème, car Wizard est séquentiel.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Maintenant, voici le problème: mes utilisateurs doivent pouvoir modifier toutes les entrées par la suite. Exemple: L'entrée C doit être modifiée par la suite.
- Je pourrais les renvoyer via Wizard. Mais s'ils ne trouvent pas ce qu'ils recherchent sur la première page de l'assistant, ils devront le rechercher, sans savoir où il se trouve ni s'il se trouve même dans l'assistant.
- Je pourrais proposer une boîte de dialogue d'édition séparée qui n'est pas un assistant. Fondamentalement, deux boîtes de dialogue qui gèrent les mêmes données, une pour l'ajout et une pour l'édition. Cela signifie plus d'efforts et il pourrait être interprété comme incohérent.
- Je pourrais abandonner l'assistant. L'ajout et la saisie se feraient avec la même boîte de dialogue.
Je ne veux pas vraiment abandonner le concept Wizard car il est confortable pour la saisie de données. Pouvez-vous imaginer une solution qui rende l'ajout et l'édition aussi confortables que possible?
À mon avis, les assistants ne sont utiles que pour le processus d'embarquement, la création de compte ou la modification des paramètres. Ils ne conviennent pas aux scénarios où le formulaire doit être fréquemment consulté, comme les fonctionnalités liées aux tâches (création de produit, planification de rendez-vous). Je privilégie donc la 3ème option que vous avez présentée.
Sur la base de ce qui a été décrit, il semble que votre utilisateur doive utiliser le formulaire pour effectuer des activités liées à des tâches lourdes (création d'objet). Le formulaire doit également avoir la fonctionnalité CRUD .
À mon avis, vous avez besoin d'un moyen d'organiser vos champs de saisie de manière concise et séquentielle qui apporte de la clarté. Je dirais que l'efficacité de la forme est un facteur important (CRUD) à considérer également. Comme je l'ai mentionné, l'assistant est idéal pour un processus unique, il est moins efficace si le formulaire doit être revu plusieurs fois. Cela pourrait même ralentir l'utilisateur averti qui souhaite accéder rapidement aux champs d'intérêt à l'aide de l'onglet.
Approche accordéon
Si la décomposition du formulaire en étapes modulaires est nécessaire, vous pouvez explorer l'utilisation de l'accordéon pour sectionner le contenu et les afficher en étapes séquentielles. Vous devrez peut-être désactiver le bouton d'envoi pour empêcher l'utilisateur de soumettre un formulaire vide. Vous pouvez inclure une autre conception d'interaction pour la soumission de formulaires vides dont je ne parlerai pas ici.
Lors de l'édition du formulaire, l'accordéon est développé pour afficher toutes les entrées et ses entrées. Cela rend la recherche dans les champs d'intérêt à modifier beaucoup plus facile et réduit l'effort d'implémentation de la validation du formulaire également.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Cette approche permet à l'utilisateur de voir le formulaire dans son intégralité au lieu de perdre son temps à parcourir l'assistant et à découvrir des champs qu'il n'est pas à l'aise de remplir (ou pas de réponse à ce stade).
Je pourrais offrir une boîte de dialogue d'édition séparée qui n'est pas un assistant. Fondamentalement, deux boîtes de dialogue qui gèrent les mêmes données, une pour l'ajout et une pour l'édition. Cela signifie plus d'efforts et il pourrait être interprété comme incohérent.
Je crois que cela répond également à votre souci de créer une boîte de dialogue distincte pour l'édition. Vous l'avez dit, maintenir 2 formulaires distincts qui remplissent la même fonction est un drapeau rouge en termes de mise en œuvre technique et de maintenance. Soyez gentil avec vos développeurs :)
Je ne veux pas vraiment abandonner le concept Wizard car il est confortable pour la saisie de données.
L'une des pires choses qui pourrait arriver, c'est lorsque les concepteurs se sont trop attachés à leur conception et n'ont pas exploré d'autres options. C'est un obstacle beaucoup plus important à surmonter que les défis de conception eux-mêmes.
Rien ne vous empêche d'utiliser un assistant pour le flux de configuration initiale et une autre interface utilisateur pilotée par menu pour une modification continue. Après tout, les besoins des utilisateurs varieront avec le temps. Par exemple:
Lorsque vous configurez quelque chose pour la première fois, les assistants sont parfaits pour guider un utilisateur dans une tâche longue, compliquée ou critique.
Lorsque vous devez modifier quelque chose à l'avenir, un déclencheur de menu spécifique vous permettra de garder la tâche d'édition petite et concentrée sur votre objectif utilisateur.
Combinez la puissance de l'assistant pour l'intégration, puis servez-vous du même formulaire avec toutes les étapes développées quand ils veulent le modifier. Avec quelques modifications mineures au style et éventuellement à la validation/javascript, vous pouvez facilement convertir la vue de l'assistant en présentation de formulaire standard.
Un plugin qui pourrait vous aider à y parvenir est Accordion Wizard où vous pouvez changer le 'mode' de 'wizard' en 'edit'.
Vous pouvez avoir barre de progression avec des liens vers les différentes pages de l'assistant (voir l'image ci-dessous). Il est obligatoire (du point de vue de l'utilisabilité) si votre assistant est plus long que 2 pages, car il donne aux utilisateurs des commentaires où ils en sont dans le processus et combien d'efforts il reste. De cette façon, vous pouvez avoir à la fois - assistant et accès rapide à tous les champs. En savoir plus sur les Steppers ou les barres de progression ici .
Image tirée de Spécifications de conception des matériaux .
La barre de progression peut également être horizontale: 