Plusieurs instances d'un éditeur de propriétés
Je conçois une application dans laquelle plusieurs types d'objets utilisateur ont des propriétés. Lorsque vous cliquez sur un objet, les propriétés de l'objet sont affichées dans un volet similaire au volet Propriétés dans Visual Studio. Ce volet permet d'afficher et de modifier les propriétés d'un ou plusieurs objets sélectionnés. (un volet similaire peut être trouvé dans de nombreuses autres applications, telles que Expression Blend, Adobe Lightroom, etc ...)
Je veux également pouvoir épingler l'objet actuellement inspecté à un éditeur de propriétés afin qu'il y reste (je veux dire que les objets restent dans l'éditeur de propriétés. I je ne parle pas de la fonction de masquage automatique). Ensuite, l'utilisateur peut sélectionner un autre objet et est capable de comparer les deux objets simultanément, et voir deux éditeurs de propriétés.
Connaissez-vous un logiciel qui fait ça? Je recherche le modèle et le paradigme d'interface utilisateur appropriés pour implémenter une telle fonctionnalité.
Certains modèles que je pensais pourraient fonctionner:
Modèle 1 - L'utilisateur peut instancier autant d'éditeur de propriétés qu'il le souhaite. Une seule instance des éditeurs de propriétés ouverts est celle par défaut. L'éditeur de propriétés par défaut affiche l'objet actuellement sélectionné. L'utilisateur peut cliquer sur une icône Is Default dans l'éditeur de propriétés pour indiquer laquelle est la valeur par défaut. Cliquer sur est par défaut sur une instance supprimera l'état est par défaut du instance par défaut précédente.
Modèle 2 - L'utilisateur peut instancier autant d'éditeur de propriétés qu'il le souhaite. Toutes les instances de l'éditeur de propriétés peuvent être épinglées. Lorsqu'un éditeur de propriétés est épinglé, l'objet qui lui est lié y reste et ne peut pas être modifié par la sélection actuelle. Problèmes: lors de la sélection d'un objet, lequel des éditeurs de propriétés non épinglés affichera l'objet? Que faire si tous les éditeurs de propriétés sont épinglés?
Modèle - Les instances de l'éditeur de propriétés sont créées automatiquement par le framework. Par défaut, un éditeur de propriétés est affiché. Les instances de l'éditeur de propriétés sont créées automatiquement lorsqu'un objet est épinglé. Lorsqu'un éditeur de propriétés est épinglé, une autre nouvelle instance vide est créée, prête à recevoir la sélection. Les éditeurs de propriétés sont empilés horizontalement et le système conserve toujours un seul éditeur de propriétés par défaut. Désépingler un éditeur de propriétés le détruit automatiquement.
Quel modèle est le meilleur? Avez-vous d'autres suggestions?
Je voudrais éviter le modèle 2 avec sa complication de discrimination et de gestion de plusieurs volets de propriétés épinglés et non épinglés en raison du problème que vous citez. Je ne comprends pas non plus ce que signifie un volet non par défaut non épinglé, il peut donc aussi dérouter vos utilisateurs. Il me semble que soit un volet se remplit lorsque la sélection d'objets change, soit il ne change pas. Qu'y a-t-il d'autre?
Les modèles 1 et 3 sont similaires si je comprends bien. Les deux n'ont pas plus d'un volet de propriétés par défaut, mais ils diffèrent dans la façon dont l'utilisateur le désigne. Juste pour être sûr d'avoir bien compris:
modèle 1
L'utilisateur sélectionne l'objet A à comparer. L'application remplit le volet par défaut avec les propriétés de A.
L'utilisateur sélectionne une commande comme "Nouveau volet de propriétés". L'application ouvre un nouveau volet. Le nouveau volet devient celui par défaut (je pense que c'est le mieux, mais ce n'est pas nécessairement obligatoire).
L'utilisateur sélectionne l'objet B. L'application remplit le volet par défaut avec les propriétés de B.
Répétez les deux dernières étapes pour des objets supplémentaires si nécessaire.
modèle
L'utilisateur sélectionne l'objet A à comparer. L'application remplit le volet par défaut avec les propriétés de A.
L'utilisateur sélectionne la commande Épinglé. L'application ouvre un nouveau volet qui devient celui par défaut.
L'utilisateur sélectionne l'objet B. L'application remplit le volet par défaut avec les propriétés de B.
Répétez les deux dernières étapes pour des objets supplémentaires si nécessaire.
Le gagnant?
La principale différence est exactement l'endroit où les utilisateurs doivent cliquer pour instancier un nouveau volet de propriétés par défaut et comment il est étiqueté.
Je suis enclin au modèle 1, car il s'agit d'une interface utilisateur globalement plus simple. Vous allez avoir besoin d'une commande pour ouvrir un volet de propriétés dans l'un ou l'autre modèle, car vous devrez permettre aux utilisateurs de fermer (tous) les volets de propriétés afin qu'ils puissent désencombrer l'écran. Dans le modèle 1, la même commande pour ouvrir le premier volet de propriétés est également utilisée pour en ajouter de nouveaux. Le modèle 3 a une commande supplémentaire pour apprendre et distinguer.
Je ne sais pas si le contrôle "par défaut" est nécessaire pour le modèle 1. Je ne m'attends pas à ce que les utilisateurs aient trop à changer la valeur par défaut. Plus souvent, la conservation des propriétés (en sélectionnant le nouveau volet Propriétés) et la suppression des propriétés (en fermant le volet) seront des actions distinctes conceptuellement et temporellement. "Is default" semble être une complication avec peu d'avantages.
Questions de recherche
Dans tous les cas, vous construisez apparemment une nouvelle interface utilisateur, vous allez donc devoir faire des recherches sur les utilisateurs et des tests d'utilisabilité pour bien faire les choses. Voici quelques questions auxquelles seule la recherche d'utilisateurs peut répondre:
Comment cela correspond-il au modèle mental des utilisateurs de la tâche de comparaison? Pensent-ils: "J'ai l'objet A. Maintenant, je dois trouver comment montrer l'objet B en même temps"? Cela correspond bien au modèle 1. Ou pensent-ils: "J'ai un objet A. Maintenant, je dois trouver comment le garder ici quand je vais chercher l'objet B"? Cela suggère quelque chose de plus comme le modèle 3.
Lorsque le nouveau volet par défaut s'ouvre, doit-il être vide ou rempli avec l'objet actuellement sélectionné? Le premier peut inviter l'utilisateur, suggérant "d'accord, je suis prêt pour vous à sélectionner un nouvel objet". Ce dernier est plus cohérent et peut mieux indiquer que le nouveau volet de propriétés est la valeur par défaut - car par définition, la valeur par défaut a toujours les propriétés de l'élément actuellement sélectionné. Ce dernier est également nécessaire si la valeur par défaut n'est pas automatiquement déplacée vers le nouveau volet - sinon, vous n'avez aucun moyen de remplir un nouveau volet de propriétés (sauf via un clic droit).
Les utilisateurs récupèrent-ils après avoir fermé le volet par défaut? Si l'utilisateur ferme le volet par défaut, vous ne pouvez pas modifier automatiquement l'un des volets restants pour qu'il soit par défaut (le cas échéant), car cela risquerait d'effacer les données que l'utilisateur souhaite conserver. Si les utilisateurs ferment la valeur par défaut, comprendront-ils qu'ils doivent sélectionner le nouveau volet de propriétés pour voir les propriétés de l'objet sélectionné?
Comment distinguez-vous visuellement le volet par défaut des autres? Cela est nécessaire car les utilisateurs peuvent oublier quelle est la valeur par défaut et ne pas savoir où chercher. Ils doivent également être capables de dire d'un coup d'œil à l'écran s'il n'y a pas de défaut ou s'ils sont sur le point de fermer le défaut car cela a des ramifications.
Quels sont les meilleurs termes et métaphores à utiliser? Est-ce que "par défaut" et "épinglé" ont du sens pour les utilisateurs? Ou doit-il être "dynamique" et "verrouillé"? "Liquide" et "congelé"? Cela affectera la façon dont vous souhaitez distinguer visuellement le volet par défaut et la façon dont vous le décrivez dans votre documentation.
Alternatives
J'admire vos efforts pour fournir aux utilisateurs un volet de propriétés qui prend en charge de manière flexible à la fois une population facile sur la sélection d'objets et un moyen de faire des comparaisons côte à côte. Cependant, envisagez la possibilité que cela n'en vaille pas la peine. Cela ne vaut peut-être pas la complexité supplémentaire pour les utilisateurs ou la recherche et le développement supplémentaires que vous devez faire. Demandez-vous si l'une de ces alternatives plus conventionnelles pourrait être suffisante:
Volet de propriétés simple simple. Ici, il n'y a au plus qu'un seul volet de propriétés visible qui montre toujours l'objet actuel. Si le remplissage du volet des propriétés est rapide (<500 ms), la modification de la sélection d'objet par l'utilisateur peut produire un effet d'animation qui attire naturellement l'œil sur les différences de valeurs de propriété. Si la tâche des utilisateurs consiste à identifier les différences, cela peut faciliter les comparaisons côte à côte. Une simple augmentation consiste à inclure des boutons Précédent et Suivant dans votre volet de propriétés pour permettre aux utilisateurs de basculer entre leur historique de sélections sans beaucoup de rotation de la souris et éventuellement le défilement du volet principal pour trouver les objets. Ce serait assez pratique en général pour rétablir l'objet sélectionné.
Dialogues de propriétés multiples simples . Ici, les volets de propriétés ne sont pas remplis lors de la sélection d'objets. Les utilisateurs ouvrent une boîte de dialogue des propriétés non modales en sélectionnant la commande Propriétés pour l'objet actuel (ou en double-cliquant dessus), et la boîte de dialogue est toujours "épinglée" à cet objet. C'est une bonne chose lorsque les propriétés sont rarement nécessaires - lorsque les utilisateurs n'ont besoin qu'occasionnellement de modifier une propriété et de fermer la boîte de dialogue. Il prend également bien en charge les comparaisons côte à côte.
Table View. Je ne sais pas comment vous présentez vos objets maîtres, mais vous pouvez fournir l'option de les afficher tous dans un tri et/ou tableau filtrable montrant toutes les propriétés d'intérêt sous forme de colonnes. Cela est préférable lorsque vous vous attendez à des comparaisons entre de nombreux objets, ce qui évite à l'utilisateur d'avoir à ouvrir et à gérer plusieurs volets de propriétés un par un. Les valeurs des propriétés sont alignées directement les unes sur les autres pour des comparaisons plus faciles qu'avec des volets de propriétés séparés. Il suppose que vos objets ont principalement les mêmes propriétés. Le tableau peut afficher uniquement les propriétés partagées entre tous les objets, ou l'union de toutes les propriétés avec des valeurs "N/A" pour les objets qui n'ont pas les propriétés.
Multi-sélection/colonne unique. Dans certaines applications avec des volets/dialogues à propriété unique simples, les volets et les dialogues de propriétés suivent la convention selon laquelle lorsque plusieurs objets sont sélectionnés , seules les valeurs de propriété partagées par tous les objets sont affichées; les autres sont vides. Cela peut être suffisant si la tâche consiste à identifier ce qui est identique ou différent pour tous les objets (mais ne dit pas à l'utilisateur en quoi ils sont différents ). Il permet également aux utilisateurs de modifier facilement une propriété à la même valeur pour plusieurs objets à la fois. C'est plus rapide que vos modèles, en moins de clics pour voir les propriétés partagées par tous les objets. Cependant, cela nécessite une expertise assez élevée - de nombreux utilisateurs ne savent pas effectuer une sélection multiple. D'un autre côté, il s'agit du volet Propriétés simples simples combinées, qui peut déjà être suffisant pour vos utilisateurs non experts. On dirait que vous alliez de toute façon avoir un comportement de multi-sélection/colonne unique. Vous avez peut-être déjà terminé.
Multi-sélection/plusieurs colonnes. Alternativement, lorsque l'utilisateur sélectionne plusieurs objets, le volet des propriétés se développe en présentant une colonne séparée de valeurs de propriété pour chaque objet. Pour comparer des objets, l'utilisateur sélectionne un objet puis Ctrl-sélectionne les objets restants, ou fait glisser-sélectionne tous les objets pour remplir le volet des propriétés en une seule fois. C'est plus compact qu'un volet séparé par objet. Comme la multi-sélection/colonne unique, c'est plus rapide que vos modèles. Comme la vue tabulaire, il aligne également les valeurs des propriétés (côte à côte) pour une comparaison facile. Mais aussi comme une table, elle ne fonctionne bien que si les objets ont généralement les mêmes propriétés. Il s'agit d'un nouveau design qui n'est pas particulièrement découvrable, il suppose donc des utilisateurs réguliers ou formés et vous ne devriez pas l'essayer sans tester les utilisateurs. D'un autre côté, comme Multi-selection/Single Column, cela est combiné avec Simple Single Properties Pane qui peut être suffisant pour vos utilisateurs non experts.
Aucune application ne vient à l'esprit qui possède plusieurs instances d'éditeurs de propriétés, mais une comparaison côte à côte des documents est prise en charge par MS Word, Excel et de nombreuses autres applications. Cela se fait généralement sur un écran partagé, verticalement ou horizontalement.
Il semble que ce type de solution ne vous concerne pas, alors ce que je ferais est le suivant: -Cliquez sur un objet affiche ses propriétés dans le volet des propriétés. -Double clic/élément de menu contextuel/action de la barre d'outils sur un objet transforme le volet des propriétés en un contrôle d'onglet, y affiche les propriétés du deuxième élément et le met au point. (essentiellement "ouvrir dans un nouvel onglet").
De cette façon, vous pouvez également créer plus de deux éditeurs immobiliers dans le même bien (mais je pense que je n'en dépasserais pas trois ou quatre). Cela ne vous permettra pas de les comparer côte à côte, mais comparer deux onglets est encore beaucoup plus facile que de basculer entre deux objets qui contrôlent la même grille.
Et vous pouvez toujours fournir la fonctionnalité de détacher ces onglets si vous en avez vraiment besoin dans un conteneur séparé, mais il me semble que cela signifierait beaucoup de maux de tête pour vous et pour l'utilisateur.
ÉDITER
Après coup: vous devez garder à l'esprit que dans tous les cas, si vous ajoutez un deuxième éditeur de propriétés, vous entrez n monde de volet;)
- Une fois qu'il est affiché, puis qu'un troisième objet est sélectionné, comment décidez-vous quel volet doit afficher ses propriétés - le premier ou le second (ou un nouveau?)?
- Autorisez-vous l'affichage des propriétés du même objet dans deux volets différents?
- Si oui, peut-il être édité dans l'un ou l'autre? Vont-ils se synchroniser alors? Ou l'un d'eux est-il en lecture seule? Laquelle et cette logique est-elle claire pour l'utilisateur?
- Si vous sélectionnez deux objets, les deux volets les affichent séparément - mais si vous souhaitez modifier une propriété partagée par les deux, vous devez maintenant le faire à deux endroits au lieu d'un (si vous prenez en charge l'édition de groupe).
- Et si vous sélectionnez trois objets? Comment décidez-vous lesquels afficher?
La plupart d'entre elles ont des réponses relativement faciles, mais elles doivent être réfléchies et doivent être cohérentes avec le reste de l'application. C'est demander des ennuis.
EDIT Concernant les modèles que vous avez ajoutés:
1 - Je pense que la notion de "défaut reflète la sélection" est bonne, mais la possibilité de changer celle par défaut est une exagération, cela ne ferait que dérouter les utilisateurs. Si je comprends bien, sous ce modèle, la façon d'afficher deux éléments différents est la suivante: sélectionnez-en un, créez un nouvel éditeur de propriétés, déplacez le drapeau par défaut vers le nouvel éditeur, sélectionnez-en un autre. C'est très lourd et difficile à saisir. Il est plus facile de définir "ouvrir cet objet dans l'éditeur X" que "de définir à chaque fois quel éditeur va afficher l'élément sélectionné suivant".
2 - Je ne pense pas qu'il soit logique que l'épinglage d'un conteneur le limite à un objet. Vous pouvez épingler un objet à un conteneur, mais l'épinglage du conteneur lui-même est une action très standard qui contrôle la mise en page, pas son contenu. Ce serait trompeur et déroutant.
3 - Je pense que c'est le modèle le plus simple des trois que vous avez suggéré. C'est le plus simple à comprendre, prévisible et logique. Cependant, cela rendrait l'utilisateur absolument fou en une minute d'utilisation. La sélection est probablement l'action la plus fréquente qu'un utilisateur effectue dans une application comme celle-ci, et il effectue de nombreuses sélections chaque minute. Pour que chaque clic ouvre un nouveau grand composant à l'écran, c'est un peu suicidaire.
Si la suggestion d'onglets ne fonctionne pas pour vous, j'aurais un éditeur par défaut et laisserais l'utilisateur ouvrir d'autres éditeurs via une commande spécifique, pas le clic de sélection habituel. Les autres éditeurs seront "flottants" et ne répondront pas à la sélection, vous ne pouvez donc pas modifier l'objet à l'intérieur (ou vous pouvez le faire avec une autre commande spécifique).
Ce que je ferais serait de créer une interface (PAS une "classe" de type "interface") qui reçoit tous les objets dont les propriétés vont être affichées dans le volet des propriétés. Une telle interface aurait des paramètres pour trier les propriétés de différentes manières souhaitées ex.
1.- Afficher toutes les propriétés de chaque objet
2.- Trier les propriétés par nom (qui mélangerait toutes les propriétés des objets)
Dans ce scénario, j'opte pour un nouveau modèle autre que ceux que vous avez proposés, dans celui-ci vous n'avez qu'un seul volet de propriétés et toutes les propriétés des objets sélectionnés sont affichées ici juste triées différemment.
Je ne peux pas non plus penser à une application qui fonctionne de cette façon, mais je pense que le fait d'avoir toutes les propriétés dans un seul volet simplifierait le processus pour l'utilisateur :)