Contrôle alternatif de glisser-déposer pour attribuer des tâches à un individu?
Je travaille sur une application Web pour les directeurs d'agence d'une banque d'investissement pour attribuer des comptes sans conseillers financiers pour une raison quelconque. Certaines raisons sont que le conseiller financier a démissionné ou que le client ne les aime pas, etc. Les directeurs de succursale auront la possibilité d'afficher les comptes qui doivent être affectés et de consulter les conseillers financiers disponibles. De nombreux comptes ne peuvent être attribués qu'à un seul conseiller financier.
Mon application est en cours de développement en Ext et je vois à travers leurs démos que les utilisateurs peuvent faire glisser et déposer des éléments. Cela semble être un moyen maladroit d'attribuer des comptes à de nouveaux conseillers financiers, d'autant plus que les affectations pourraient facilement être faites par erreur (choisir la mauvaise personne). Les utilisateurs pourront revenir en arrière s'ils ont fait une erreur, mais cela ne semble pas être la meilleure solution. J'ai déjà travaillé sur un système de billetterie qui avait cette capacité de glisser-déposer des éléments supplémentaires sur un ticket ouvert et c'est devenu très compliqué.
Y a-t-il d'autres types de motifs qui vous viennent à l'esprit?
Cela semble être une exigence pour un processus possible en 3 étapes où les détails peuvent être vus en permanence et facilement vérifiés à chaque étape - et avant l'affectation finale.
Essentiellement, vous construisez une relation en quelques étapes qui nécessitent un examen des éléments entre lesquels la relation doit être établie. Un mouvement de glisser/déposer semble incorrect car il s'agit d'un événement distinct à la fois pour l'examen du compte et pour l'examen des conseillers.
Il serait donc peut-être préférable de construire la relation au fur et à mesure, puis de confirmer la relation une fois que vous êtes sûr.
étape 1: choisissez le compte. Ceci est affiché quelque part dans une zone de confirmation qui montre la relation que vous prévoyez de construire. Vous pouvez voir le compte sélectionné. Il y a de fortes chances que vous ne souhaitiez pas modifier le compte après la sélection, mais si vous l'avez fait, il suffit de mettre à jour dans la zone de confirmation.
étape 2: choisissez le conseiller. Le conseiller s'affiche à côté du compte dans la zone de confirmation. Il est possible que vous changiez de conseiller si vous en trouvez un de plus approprié que celui que vous avez déjà sélectionné, auquel cas un clic sur un autre conseiller mettra à jour celui de la zone de confirmation.
étape 3: une fois que vous êtes sûr d'avoir le bon conseiller, vous cliquez sur appliquer dans la zone de confirmation.
Comme guide visuel de ce que je veux dire, voir la maquette très rapide ci-dessous.
Je déduis de votre question que l'utilisateur peut modifier plusieurs relations gestionnaire de compte ensemble - donnez ce compte à ce gestionnaire, mais si c'est le cas, nous devrions déplacer cet autre de lui vers cet autre gestionnaire, etc.
Si c'est correct, votre interface concerne fondamentalement relations. Une façon de représenter les relations consiste à utiliser des lignes reliant d'autres éléments de l'interface utilisateur.
Envisagez une interface utilisateur dans laquelle les comptes et les gestionnaires sont affichés (boîtes? Icônes? Vous décidez), avec l'affichage comprenant les informations clés (valeur du compte, argent géré total pour les gestionnaires). Les relations actuelles peuvent être représentées par des lignes (disons noires) les reliant. Vous pouvez utiliser une couleur de ligne différente (par exemple, rouge) pour mettre en évidence celles qui doivent être modifiées. Un utilisateur peut voir en un coup d'œil que, disons, ces cinq lignes rouges indiquent les modifications à apporter; quand il fait glisser une extrémité de la ligne vers un nœud différent, la ligne passe à un troisième état (par exemple, en pointillé bleu) pour indiquer "en attente", et les valeurs sont mises à jour avec un rendu modifié pour indiquer également la nature "en attente" (texte bleu , en boîte ou quelque chose comme ça). L'utilisateur peut déplacer les choses autant qu'il le souhaite, en voyant toujours un instantané de ce à quoi les choses ressembleraient s'il le conservait. Quand il est prêt, il peut s'engager (bouton, frappe, autre geste de votre choix).
Si votre système permet aux clients de demander de nouveaux gestionnaires parce qu'ils n'aiment pas leurs actuels, vous devriez probablement en faire le suivi afin qu'une modification ultérieure ne renvoie pas de compte à un gestionnaire indésirable. Cela signifie que votre interface utilisateur doit gérer le cas où une affectation n'est pas autorisée. (Vous pouvez également avoir d'autres critères de rejet, comme des limites sur le montant d'argent qu'un gestionnaire peut gérer.) Une manière de base de gérer cela serait de ne pas permettre la suppression de la fin de ligne (avec un message approprié). Une façon plus astucieuse de le faire, si vous pouvez épargner la puissance de calcul, serait, lorsqu'une ligne est déplacée, de "griser" des cibles invalides.
Cette approche fonctionne si vous travaillez avec un assez petit nombre de gestionnaires et de comptes. (Vous n'avez pas besoin d'afficher tous les comptes, seuls ceux que vous pouvez modifier. Mais vous devez afficher tous les gestionnaires disponibles.) Si vous souhaitez travailler avec 500 comptes et 75 gestionnaires, cette approche ne fonctionnera pas; vous devrez soit réduire le focus d'une manière ou d'une autre (en gérer moins à la fois) ou utiliser une interface moins visuelle (comme un menu déroulant par compte pour définir le gestionnaire, ce qui n'est pas très bon pour la vue).