Comment créer un lien entre deux formulaires prérequis l'un de l'autre?
Disons que j'ai une liste de conducteurs et une liste de bus. Maintenant, dans mon interface, je peux créer une instance d'un pilote et une instance d'un bus. Comme ci-dessous:
Cependant, comme vous pouvez le voir, ils peuvent se référencer comme dans un bus peut avoir un pilote et un pilote peut avoir un bus.
Le dilemme est qu'ils peuvent être des pré-requis les uns des autres, selon le formulaire que vous remplissez en premier. Comment résoudre ce dilemme pour pouvoir créer une instance d'un pilote et une instance d'un bus sans qu'ils aient besoin de se référencer? Et lorsque je dois les référencer/les lier, à quoi ressemblera cette interface de "liaison"?
Dois-je "attribuer un bus" sous pilote? Ou dois-je "Attribuer un pilote" sous Bus? Ou il n'y a pas de bien ou de mal des deux façons?
Même problème pour tous les types de relations plusieurs-à-plusieurs. Si vous avez un CMS Movie, ajoutez-vous des acteurs sous un film ou ajoutez-vous des films sous un acteur? Ou un CMS de bibliothèque, "Ajoutez-vous un auteur" sous un livre ou "Ajoutez-vous un livre" sous un auteur?
Vous pouvez utiliser des vues de liste et de détail pour activer la liaison rapide et permettre aux utilisateurs de joindre l'entité associée à partir d'une boîte de dialogue.
Les bus et les pilotes existent en dehors de leur affectation les uns aux autres. Il semble qu'ils soient tous deux des attributs d'un itinéraire, qui a 1 ou plusieurs bus et 1 ou plusieurs chauffeurs.
Avez-vous un concept de niveau supérieur comme un itinéraire?
Je ne sais pas quel est votre modèle de données, mais il semble qu'un `` itinéraire '' ou un objet de niveau supérieur puisse vous donner une vue de tous les bus et pilotes connectés, plus si vous avez des bus et/ou des pilotes sortants de commission, vous avez une vue de haut niveau.
Puisqu'à tout moment il peut y avoir un pool de bus sans chauffeur, et vice versa, leur permettre d'exister au même niveau, et de se réticuler entre eux. Cela est particulièrement utile si un itinéraire de bus partage plusieurs pilotes et inversement, car vous pouvez afficher un tableau et une vue détaillée qui montre ces relations.
À partir d'une liste de bus, je peux explorer la vue détaillée du bus, mais si vous autorisez les liens de pilotes et un menu pour ajouter un pilote, je peux faire apparaître une boîte de dialogue pour sélectionner dans une liste de pilotes.
S'il n'y a aucun pilote que j'attendais dans la boîte de dialogue du pilote, permettez-moi d'en ajouter un nouveau. Une fois que je soumets, je vois le nouveau pilote ajouté à la liste des bus. Je peux ensuite cliquer sur le lien sur le pilote nouvellement créé pour être redirigé vers cette vue détaillée des pilotes, où il affiche le bus associé.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Imho ajouterait un "trip id" pour avoir un point central de connexion. Ainsi, un futur voyage lié ne ferait référence à aucun chauffeur ou bus jusqu'à un moment opportun. Mais le contexte est la clé ici. À moins qu'il n'y ait une raison très spécifique de mettre en évidence quel pilote ou quel bus, restez simple et stupide. Remplissez un formulaire pour un voyage/événement puis mettez à jour car de nouvelles informations sont nécessaires.
Il permet la flexibilité des données:
chaque conducteur peut utiliser un bus différent par trajet (un bus pourrait tomber en panne/avoir un accident sur l'autoroute)
chaque bus peut avoir plusieurs chauffeurs le long d'un trajet, par ex. québec (conducteur a) à toronto (conducteur b) à new york
Pour référencer votre exemple ..
- Film, puis Cast (Acteurs), vidéos, photos, citations célèbres
- Livre, puis Auteur/s
C'est un problème intéressant, mais je pense que vous pourriez le résoudre avec une relative facilité.
Cette solution suppose:
- Vous avez un code de style compartimenté (frontal) pour les deux formulaires
- Vous avez compartimenté le code de soumission (backend) pour les deux formulaires
Pour commencer, considérez cette maquette:
Deux changements principaux à votre maquette d'origine:
- Remplacez le champ de texte par une liste déroulante, qui se remplit en fonction des pilotes chargés dans le système. Que se passe-t-il si un utilisateur mal orthographié un nom de pilote?
- Ajouter une option pour créer un nouveau pilote
L'étape suivante:
- Permet à l'utilisateur d'entrer de nouvelles données de pilote dans la même étape
- Désactiver le bus no. , car il doit être identique au nouveau bus (ou masquer complètement ce champ)
- Réinitialiser le texte du bouton pour faire correspondre deux actions
Une fois ce formulaire soumis, les actions de soumission pour le bus et le conducteur sont appelées.
D'autres pensées:
- Si la spécification de la liaison bus/lecteur n'est pas immédiatement requise, il peut être judicieux de permettre à l'utilisateur de spécifier ultérieurement. Cependant, soyez prudent au cas où cette tâche serait oubliée.
- Pourquoi ne pas les combiner en un seul formulaire "créer"?
À moins qu'ils ne soient strictement nécessaires et qu'un seul pilote soit possible à chaque instance, les flux ne sont pas liés, mais ils iront en parallèle . Sinon, vous aurez beaucoup de problèmes en cours de route. Votre scénario CMS de film est un exemple parfait: un film a de nombreux acteurs et un acteur peut figurer dans de nombreux films.
Un autre exemple de cela, puisque vous allez travailler avec des bases de données est .... bases de données! Vous créez une base de données et vous créez des utilisateurs. Ensuite, vous affectez des utilisateurs aux bases de données. Modifiez database avec bus et user avec driver et c'est parti.
Ainsi, le flux pourrait être comme ceci:
- Tout d'abord, l'utilisateur crée des pilotes (ou des bus. C'est la même chose, mais les pilotes sont plus susceptibles d'être ajoutés, modifiés ou supprimés. En outre, vous verrez à l'étape suivante, ce sera plus pratique lors de l'ajout de bus pour la première fois).
- Ensuite, il crée des bus. Dans cette étape, vous pouvez proposer un
drop-downoucheckbox(selon le nombre de pilotes) où l'utilisateur pourra affecter un pilote à ce bus. - Et c'est tout!
Cela ressemblera à ceci:
Remarque: il est recommandé de ne pas avoir besoin d'un pilote, l'utilisateur peut le laisser vide et remplir ces informations ultérieurement.
Sachez comment vos utilisateurs pensent et travaillent
Ce genre de problème est très courant et tout se résume à connaître vos utilisateurs modèle mental . Pensent-ils aux bus avec chauffeurs ou aux chauffeurs de bus?
Demandez-leur et vous connaissez le bon chemin:
Chemin 1.
Créez ou modifiez un bus et affectez un pilote. Ou lorsque le pilote n'est pas dans le système, affichez des champs de formulaire supplémentaires pour un nouveau pilote> Enregistrez le formulaire
Chemin 2.
Créez ou modifiez un pilote et affectez-le à un bus. Ou lorsque le bus n'est pas dans le système, affichez des champs de formulaire supplémentaires pour un nouveau bus> Enregistrez le formulaire
Si le chemin que les utilisateurs choisissent dépend de situations différentes, il est possible de le fournir dans les deux chemins mais chacun à partir de points de départ différents dans l'application. Mais afficher les deux chemins en même temps/point de départ ajoutera beaucoup de charge cognitive supplémentaire et n'est pas recommandé.