Formulaires de création imbriqués
Cette question concerne la façon de créer des objets dans une base de données relationnelle sans une tonne de popups.
Je travaille sur une application Web qui contient des formulaires dans les formulaires. Autrement dit, vous pouvez créer des objets liés dans la boîte de dialogue de création d'objet. Voici un exemple pour illustrer le concept:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Etc...
Les bijoux peuvent avoir plusieurs pouvoirs magiques. Ou peu importe. (Je travaille actuellement sur un produit financier.)
Avez-vous de bonnes idées sur la façon de le faire d'une manière non laide, non confuse, de préférence à guichet unique?
-- Modifier 1 -
Voici plus d'informations sur ma situation spécifique. Je préférerais garder cela plus général, mais si un bon design ne se présente que pour ma situation, ce serait bien. Faites-moi savoir s'il y a autre chose que vous aimeriez savoir!
- Les utilisateurs sont à la fois des utilisateurs noobz et des utilisateurs avancés. Certains utilisent cette application toute la journée et connaissent leur chemin, d'autres se connectent une ou deux fois juste pour changer un paramètre important/créer un nouvel élément.
- Ce formulaire est utilisé pour créer des éléments pour les clients. Ils veulent que cela se fasse rapidement et avec un faible risque d'erreur.
- Cette application est utilisée dans un cadre bancaire d'entreprise. L'utilisateur principal est un gestionnaire de compte pour les grandes entreprises. (Ces utilisateurs passent beaucoup de temps dans l'application, créant des choses pour les clients.)
- Ce modèle revient souvent. Parfois, il ne va que 2 niveaux de profondeur, mais dans certains cas, il va de très nombreux niveaux. (15 ~ 20) Il peut même y avoir des cas de boucles récursives. Je ne suis pas sûr. Pour cette question, je préfère supposer que c'est infini. (J'accepterais une réponse impressionnante pour un montant fini, si c'est super génial.)
- Les éléments individuels peuvent être assez complexes. Jusqu'à ~ 100 éléments de formulaire. Certains formulaires d'articles ont aussi des champs étranges comme de longues listes/téléchargements de documents/etc ...
- Il peut y avoir différents types d'articles à chaque niveau. Ex: Une personne peut également avoir des enchantements, des pouvoirs, des amis, etc. Je devrais pouvoir les créer à partir du formulaire Personne et les ajouter à ma personne.
- Chaque niveau peut avoir plusieurs propriétés pour l'élément. Par exemple, un bijou peut avoir un poids, une couleur, une logique de combinaison (références de règles qui l'empêchent d'être combiné avec certains autres joyaux) ou des pouvoirs magiques (références à d'autres objets).
-- Modifier 2 -
Il serait idéal que les réponses tiennent compte de tous les types de relations. (Ex: n-à-un , n-à-plusieurs et plusieurs-à-plusieurs relations. Autrement dit, l'objet Dagger pourrait appartenir à Bob seul ou être partagé par de nombreuses personnes.
Je sais que c'est beaucoup demander, mais j'apprécie vraiment les idées!
Cela ressemble beaucoup à une structure de dossiers, où vous pouvez ajouter autant de niveaux et autant d'éléments par niveau que vous le souhaitez, avec une imbrication profonde.
J'imagine qu'une vue similaire se produirait plus naturellement pour l'utilisateur:
Cette maquette s'appuie sur l'idée que l'utilisateur travaille "de haut en bas", donc l'élément "ajouter un nouvel élément" est en bas. L'utilisateur peut réduire des éléments individuels et il existe une multitude d'options (et de métaphores déjà apprises) pour indiquer l'imbrication et toutes ses implications.
Pourtant, il est difficile de faire une suggestion éclairée avec la quantité limitée d'informations dont nous disposons:
- Avons-nous affaire à des utilisateurs expérimentés ou non?
- Dans quel environnement cela sera-t-il utilisé?
- Quelle est la tâche principale qu'un utilisateur va vouloir accomplir?
- À quelle profondeur la nidification ira-t-elle habituellement?
- La nidification aura-t-elle un niveau minimum/maximum?
- Dans quelle mesure les éléments individuels seront-ils complexes?
- Peut-il y avoir différents types d'articles sur un même niveau d'imbrication? (par exemple, "Gemmes", "Munitions", "Enchante" pour l'équipement)
etc. pp.
- MISE À JOUR - Avec les informations supplémentaires, je pense à quelque chose comme ça:
Pour les utilisateurs expérimentés, l'ajout d'un nouvel élément doit simplement avoir un raccourci (CMD/CTRL + N) qui ajoute un nouvel élément enfant ou frère, selon le cas le plus courant. Les raccourcis avancés (CMD/CTRL + MAJ + N, CMD/CTRL + ALT + N) peuvent couvrir l'ajout d'éléments enfant/parent. Surtout pour les utilisateurs expérimentés, la navigation au clavier serait la clé (voir ce que j'ai fait là-bas?). Ils pouvaient parcourir les éléments avec les touches fléchées et le formulaire avec TAB, leur permettant de se déplacer très rapidement sur l'écran.
La maquette ne couvre pas l'utilisateur occasionnel (sauf pour le glisser-déposer pour ajouter de nouveaux objets que je trouvais cool) - ils auraient probablement besoin de plus de conseils sur la façon de supprimer des éléments. Il faut également réfléchir au cas d'une liste d'éléments dépassant les frontières de l'écran, en particulier son comportement de défilement: doit-il défiler complètement ou la hiérarchie actuelle doit-elle toujours rester visible (par exemple, faire défiler uniquement les éléments non pertinents et conserver toujours l'arborescence de sélection actuelle au sommet?
Je pense que tout dépend du niveau de profondeur que vous allez atteindre. Comme toujours, un modèle unique ne convient pas à toutes les situations.
Si vous avez vraiment doit garder tous les sous-formulaires sur la même page, ce qui suit est le meilleur que je puisse penser pour la situation. L'idée générale est que vous avez votre formulaire principal, puis lorsque vous cliquez sur le bouton Nouveau dans la barre d'outils de la zone enfant, la zone enfant se réduit à une barre latérale. Ensuite, à côté de la barre latérale, vous avez un nouveau mini-formulaire pour éditer/créer votre élément. Si vous avez plus de profondeur dans votre structure de données, alors vous empilerez simplement plus de barres latérales.
Évidemment, cette solution devient de plus en plus faible au fur et à mesure que vos données sont profondes. Si vos données ont plus de deux niveaux de profondeur, ou si l'un de vos niveaux nécessite une forme longue, je voudrais fortement exhorter à ne disposer que de boîtes de dialogue modales ou de nouvelles fenêtres pour saisir les nouvelles données. De cette façon, vos utilisateurs seront en mesure de se concentrer davantage sur chaque "niveau" des données et ne se contenteront pas d'entrer rapidement et de manière bâclée couche par couche de données. Parfois, il est bon de rythme l'utilisateur.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Si tous vos éléments n'ont qu'un seul champ (nom) visible par l'utilisateur, vous pouvez vous en sortir en utilisant une zone de liste déroulante (c'est-à-dire la saisie semi-automatique); au fur et à mesure qu'ils tapent, recherchez dynamiquement les éléments correspondants dans la base de données, et s'il n'y a pas de correspondance (ou si l'utilisateur ne sélectionne aucune correspondance) et qu'ils appuient sur virgule/retour/sur une autre touche, cet élément est saisi comme un nouvel article.
Cela vous permet ensuite d'implémenter une métaphore d'accordéon (similaire à ce que Christian a simulé dans sa réponse) pour manipuler des modèles enfants (par exemple des bijoux).
Le résultat final se termine par quelque chose comme ça, puis:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Comme vous pouvez le voir, vous pouvez théoriquement continuer d'imbriquer à chaque niveau, et vous pouvez étendre la boîte d'attributs d'équipement pour inclure plus que des bijoux si vous préférez.
Imaginez vos formes imbriquées comme un carrousel de formes donc, voici ce que vous pourriez faire,
Comme indiqué dans la maquette, lorsqu'un utilisateur clique sur new equipment, le new person form pourrait glisser vers la gauche et disparaître et le new equipment form pourrait glisser de la droite, imitant un carrousel.
Le point le plus important concernant les formulaires imbriqués ou la redirection d'un utilisateur vers un autre formulaire (à partir d'un formulaire actuel) est de lui assurer que les données du formulaire précédent ne sont pas perdues.
Donc, dans ce cas, lorsqu'un ancien formulaire glisse et qu'un nouveau formulaire se glisse, vous pouvez avoir un bouton/notification qui indique à l'utilisateur qu'il peut enregistrer ce formulaire actuel et revenir au formulaire précédent et que leurs modifications ne sont pas '' t perdu. J'ai utilisé un bouton pour résoudre ce problème, vous êtes libre de choisir une meilleure option si vous en avez une en tête.
J'ai plusieurs problèmes avec cette application.
Pour une solution générale, Christian est très bien, sauf que je pense qu'il est encombré. Ce n'est pas la faute de Christian en soi: c'est une approche encombrée.
De plus, la gestion d'un widget d'arbre sur mobile est assez difficile en soi. J'adore OmniOutliner pour iPad et je pense qu'ils ont la meilleure approche de gestion des arbres jusqu'à présent, mais c'est toujours difficile.
Nous avons une contrainte supplémentaire par rapport à un TreeView normal: chaque niveau contient exactement un type d'objet.
Une grande question pour moi si les objets sont partagés ou s'ils appartiennent appartiennent à la racine. Un exemple pourrait provenir d'un RPG: tous les humanoïdes peuvent, disons, porter l'anneau magique des guérisseurs, et il y a une quantité non spécifiée (probablement infinie) de tels anneaux dans le monde, et aucun anneau n'a de propriétés spéciales ou il n'y a aucun lien entre leur propriétaire actuel.
Dans ce cas, l'ajout de nouveaux types d'anneaux se produit rarement, généralement les types de propriété de "type partagé" n'ont pas souvent besoin d'ajouts.
Par conséquent, il est assez bien de ranger un peu le contexte précédent (disons, ouvrez simplement une fenêtre modale, et cela n'a rien à voir avec les contraintes iOS), et demandez les détails nécessaires pour créer un nouveau type d'anneau.
Vous pouvez "éviter" les fenêtres modales en fournissant un fil d'Ariane.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
(Retour enregistre également)
Lorsque la chose à modifier est une partie de l'objet, il vaut mieux que ce soit une incrustation, je suppose:
De plus, il se peut qu'en réalité il y ait plusieurs flux qui doivent fonctionner en parallèle et il serait préférable que l'écran soit divisé. Malheureusement pour nous, nous ne connaissons pas la vraie application avec son vrai domaine, et nous ne voyons pas la fréquence de l'ajout à chacun des domaines et quand cela se produit-il (par exemple, lorsque le client est juste devant eux ou dans le back office) ...
Vous pouvez utiliser des onglets intra-application. Une fois que vous créez un objet, un nouvel onglet s'ouvre et vous y allez ou continuez à travailler sur votre objet. Cela vous permet d'accéder à autant de niveaux que nécessaire, vous n'avez pas un tas de dialogues imbriqués, vous pouvez toujours passer d'une entité à l'autre et vous avez beaucoup de biens immobiliers pour chaque entité. En outre, comme il s'agit d'une application Web, vous pouvez compter sur des utilisateurs qui connaissent déjà le modèle de navigation par onglets.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
