Options pour révéler progressivement la complexité hiérarchique conditionnelle
L'application sur laquelle je travaille a un certain nombre de cas où le cas d'utilisation simple et le plus courant implique la configuration d'un seul objet, mais dans certains cas, il faut diviser l'objet de base en sous-objets, puis configurer chaque sous-objet.
Un cas concret de cela serait la planification des travaux. Le cas simple consiste à créer une liste de tâches à remplir, avec des paramètres pour chaque tâche. Mais certains travaux sont divisés en plusieurs équipes, chaque équipe nécessitant une configuration.
L'approche naïve consiste à exiger que tous les travaux aient des quarts, où avoir 1 changement est une configuration valide.
Pour l'utilisateur qui configure les travaux et les quarts de travail, il est pénible de devoir configurer un quart de travail pour un travail qui n'a qu'un seul quart de travail. Ils considèrent cela comme "juste un travail", le changement est considéré comme superflu et inutile (et c'est le cas dans ce cas).
Donc, je veux améliorer cela. Je pense que la bonne solution conceptuelle est que vous pouvez créer des "emplois" et ensuite si vous avez besoin de quarts, vous pouvez également ajouter des quarts.
Cela ressemble à une solution de conception à "divulgation progressive". Par exemple - un clic sur "Ajouter des équipes" qui révèle une interface d'édition de l'équipe.
Un point clé est qu'il existe certains éléments de données d'un Job qui ne s'appliquent que s'il n'y a pas de décalage, sinon ces données font partie de la définition de décalage. Dans ce cas, un utilisateur peut gagner un certain nombre spécifié de "points" pour s'inscrire à un emploi. Mais si des changements sont définis, ce sont les changements qui valent des points, pas le travail.
Un exemple d'emplois et de quarts pour une soirée bingo pourrait ressembler à ceci:
Job:Setup -- 2pts
Job:Ticket Taker
Shift:1st shift -- 4pts
Shift:2nd shift -- 3pts
Job:Bingo Announcer
Shift:1st shift -- 5pts
Shift:2nd shift -- 5pts
Shift:Until end -- 6pts
Job:Cleanup -- 3pts
Les points clés sont que certains emplois subissent des changements et d'autres non. Les travaux sans décalage ont une valeur en points directement affectée au travail. Les travaux qui ont des équipes n'ont PAS de valeur ponctuelle directe, mais chaque équipe a plutôt une valeur en points (et les points peuvent varier selon l'équipe).
Je m'intéresse principalement à l'interface utilisateur pour la configuration des travaux et des équipes - par exemple, un utilisateur administrateur est en mesure de définir les tâches et les équipes qui sont nécessaires pour l'événement. (Par opposition à l'interface utilisateur pour INSCRIRE pour un emploi/quart de travail).
Une façon de penser à cela est comme si chaque travail avait un quart de travail "intégré", dont la configuration était réduite à la configuration du travail - jusqu'à ce que davantage de changements soient définis pour le travail. Cette réflexion serait révélée lorsque quelqu'un clique sur "Ajouter des équipes" et que la première équipe (intégrée) est déjà dans la liste.
Le problème avec cette approche est ce qui se passe lorsque l'utilisateur essaie de supprimer le seul quart de travail restant? Est-ce que cela revient à un mode "sans changement" pour le travail? Dans l'affirmative, quelle devrait être la valeur des "points" pour le travail à ce stade?
Ce modèle d'un objet simple qui peut être un conteneur pour des sous-objets dans certaines circonstances est apparu plusieurs fois dans cette application. Le travail/l'équipe n'est qu'un exemple. D'autres exemples seraient les groupes/sous-groupes, les événements/sessions, l'organisation/les divisions, le produit/la taille, etc.
On a juste l'impression que cela doit être un problème résolu.
Pouvez-vous penser à un exemple d'une interface utilisateur qui fait un très bon travail pour révéler progressivement cette complexité hiérarchique conditionnelle?
Connaissez-vous un nom pour ce modèle?
J'ai eu du mal à trouver les bons mots pour décrire le problème UX que j'essaie de résoudre. S'il y a un nom pour ce problème/solution, j'aimerais apprendre un raccourci.
Le vrai problème que vous rencontrez est d'essayer de supprimer les changements, où il n'y a qu'un seul changement disponible. Par quart de travail, vous entendez les heures de travail, ce qui facilite la consommation, car le quart de travail par défaut n'est pas un quart de travail planifié en soi. Le quart de travail par défaut est (très probablement) un horaire de jour autant que Dolly Partons neuf à cinq .
L'utilisateur du système doit se rendre compte qu'il existe également un quart de jour qui ne peut pas être supprimé. Ceci est probablement mieux fait en ajoutant le quart de jour par défaut à chaque travail ajouté par les utilisateurs, même si personne ne travaille sur ce quart si chaque travailleur du Bingo Night a un quart différent. Assurez-vous de faire en sorte que ces heures de travail non supprimables par défaut diffèrent du quart de travail ajouté par l'utilisateur.
Si j'ai complètement mal compris vos intentions, veuillez me conseiller dans un commentaire et je ferai de mon mieux pour vous aider dans cet important problème architectural.
Je pense que le mot pliage pourrait s'appliquer. Le concept est similaire à une fonctionnalité des éditeurs de texte qui permet au programmeur de replier (ou réduire) les corps de fonction ou les instructions conditionnelles, révélant ainsi uniquement le niveau externe . Les niveaux pliés peuvent être imbriqués dans d'autres niveaux pliés.