Comment gérez-vous la saisie de données complexes en créant des enregistrements associés dans un enregistrement dans un enregistrement?
La base de données dont je m'occupe est constituée d'objets liés les uns aux autres de multiples façons (non hiérarchiques) (documents, personnes, lieux, événements, ...).
Pour créer un nouvel enregistrement, l'utilisateur doit choisir parmi diverses listes de sélection d'autres objets ou créer un nouvel enregistrement d'objet, ce qui pourrait alors conduire à la création de nouveaux enregistrements d'objet, etc.
Dans tous les cas, l'utilisateur peut avoir un long chemin à parcourir pour terminer la création d'un enregistrement et il peut être amené à ajouter des informations ultérieurement.
Voir la capture d'écran pour une meilleure compréhension:
Je ne sais pas comment résoudre ce problème: un assistant peut être trop restrictif. Qu'en est-il des sous-formulaires qui glissent lorsque cela est nécessaire? Une arborescence comme navigateur? Aucune suggestion?
Merci pour votre participation.
Je décrirais cette situation comme: workflows imbriqués dynamiques .
- Dynamique parce que vous ne pouvez pas dire à l'avance à quel point le workflow sera imbriqué (l'utilisateur ne peut pas créer de nouveaux objets, ou peut créer plusieurs transporteurs et personnes).
- imbriqué car les workflows de création d'un transporteur puis d'une personne sont imbriqués les uns dans les autres.
L'imbrication dynamique rend difficile la présentation de ce type de workflow dans un assistant.
Un UX commun pour les workflows imbriqués est les modaux empilés . La raison en est que le ou les sous-flux de travail doivent être terminés avant de pouvoir progresser sur le flux de travail parent, de sorte que les fenêtres modales fournissent un comportement de blocage approprié pour garantir que cela se produit. Voici quelques boîtes de dialogue empilées à partir d'une interface Microsoft Windows:
Les modaux empilés ne sont pas une bonne mise en page en général car ils créent un encombrement visuel, mais rappelez-vous que dans une hiérarchie UX , la fonctionnalité et la convivialité l'emportent sur l'esthétique, donc dans le cas de workflows imbriqués qui déterminent généralement le choix de conception .
J'ai travaillé avec plusieurs bases de données "flexibles" qui étaient très puissantes. Cependant, en ce qui concerne l'interface utilisateur, la seule façon pour mes utilisateurs de le gérer était s'ils étaient d'abord un expert de ce type de système, et aucun de mes utilisateurs ne l'a jamais été.
Au lieu de penser que le système que vous avez décrit est une définition du flux d'utilisateurs, pensez que le système ne définit pas du tout un flux d'utilisateurs, et que vous arrivez à créer le front-end pour qu'il s'écoule naturellement pour vos utilisateurs, même au point de en les laissant sauter certaines parties et les remplir plus tard. Cependant, vous devez toujours trouver un flux naturel pour vos utilisateurs et les guider à travers, et cela ressemble à ce que le travail n'a pas encore été fait.
Si vous finissez par avoir besoin de fournir une manière avancée de regarder les données et que vous avez trop d'options pour les onglets, l'arborescence sur la gauche comme les dossiers de fichiers et les fichiers est une manière confortable d'interagir avec les choses. J'inclus toujours des boutons/liens "développer tout" et "réduire tout" au-dessus de mon arbre, mais ce n'est pas strictement nécessaire. Sachez simplement que peu d'utilisateurs seront probablement en mesure de comprendre et d'utiliser efficacement ce type d'interface.
La création et l'utilisation de données sont généralement différentes parties d'un processus, reconnaissant que cela peut simplifier le système.
La création de données est une opération simple à un faible niveau, créant essentiellement les objets sous-jacents pour les rôles
Owner,AuthoretPlace. Peut-être queOwneretAuthorest joué par un objetPerson,Placepourrait être unAddress.L'utilisation des données est ce que les utilisateurs font dans n'importe quel système utile, établissant des liens entre des éléments d'information. Le
Information Carriersemble être un tel connecteur. C'est ce que devrait faire la partie discutée du système.
En ayant une interface comme celle que vous décrivez, essentiellement une interface graphique de base de données, elle deviendra trop bas pour la plupart des utilisateurs, car ils ne connaissent pas les données sous-jacentes. Comme indiqué dans votre capture d'écran, lorsque l'utilisateur pense à un Document, il pense à un Owner et un Author, pas à un Person, qui peut être le objet sous-jacent pour les deux, contenant des informations inconnues de l'utilisateur, mais pouvant être requises par le modèle de données.
Par conséquent, forcer/autoriser un utilisateur à créer un Person dans le processus de "connexion d'informations à un document" est une incompatibilité de modèle mental et peut également être sujet à erreurs.
Donc, ma suggestion est de diviser la création et l'utilisation:
Créez les objets de données de base,
Person,Address,Pictureetc. dans une autre partie du système.La page de création de document peut maintenant être simplifiée pour ne faire que des connexions, espérons tout sur la même page pour éviter la pile de boîtes de dialogue modales qui se profile dans la capture d'écran. Cela devrait être possible maintenant quand il ne s'agit que de sélectionner des données déjà existantes.
Si de nouvelles données doivent être créées, faites-le dans l'autre partie du système, revenez à la création du document et mettez à jour les champs de sélection, manuellement ou automatiquement.
Si de nouvelles données doivent être créées pour la plupart des nouveaux documents, il pourrait y avoir un problème d'information à résoudre, comme l'importation de données préexistantes, ou même la simplification du modèle de données à tel point que la plupart des relations seront réduites à un champ de texte. Le Address pourrait être un tel cas. C'est difficile à savoir sans une analyse détaillée des données.