Paradigme de l'interface utilisateur pour l'éditeur de présentation imbriqué
J'ai une application avec un éditeur de disposition, quelque peu similaire à l'éditeur WinForms dans Visual Studio - avec placement de widget par glisser-déposer, un panneau de propriétés, etc.
J'ajoute l'option d'avoir imbriqué mises en page, où un widget "NestedLayout" placé (mise en page B dans l'image) peut représenter une toute autre mise en page.
Quel type d'interface recommanderiez-vous pour permettre à l'utilisateur de modifier ces dispositions imbriquées? Travailler directement dans le cadre existant serait trop encombrant, car une grande partie de l'espace d'écran serait déjà utilisée par le reste de la disposition de niveau supérieur.
Les possibilités peuvent inclure le chargement en maximisant la disposition imbriquée dans l'éditeur supérieur (peut-être avec une sorte de transition de zoom), en ouvrant un nouvel éditeur ci-dessus, etc.
Avez-vous vu des exemples d'applications d'éditeur qui gèrent efficacement ce type de scénario?
Mon premier réflexe une fois présenté avec l'écran ci-dessus serait de double-cliquer sur la disposition imbriquée pour la modifier. Je suis d'accord avec vous que demander à l'utilisateur de modifier la mise en page imbriquée dans le cadre existant n'est pas la bonne solution et cela pourrait devenir assez déroutant pour vos utilisateurs.
Je présenterais la mise en page imbriquée, entièrement rendue, dans un état grisé ou décoloré et afficherais un message au-dessus de la souris qui explique comment le modifier (par exemple "Double-cliquez pour modifier"). Je choisirais également d'ouvrir un deuxième éditeur au-dessus du premier au lieu de maximiser la disposition imbriquée avec un effet de zoom. Je trouve que l'effet de zoom, bien que très intelligent, peut facilement dérouter certains utilisateurs - vous devez être très prudent avec l'interface utilisateur afin qu'ils ne se demandent pas ce qui vient de se passer et pourquoi tous leurs widgets ont soudainement disparu.
Avez-vous regardé comment les outils de conception Web WYSIWYG gèrent les iframes? Habituellement, l'iframe (ou tout autre objet incorporé) est délimité comme un objet non interactif que l'on doit doublecliquer ou autrement activer pour afficher l'éditeur de cet objet spécifique. Dans le cas des iframes, je me souviens d'outils comme Dreamweaver faisant apparaître un volet de propriétés qui vous permet d'accéder à la page source de l'iframe à partir de là.
Ce n'est peut-être pas la meilleure utilisation, mais selon votre public, les conventions WYSIWYG peuvent être un bon appel à faire.
Vous définirez probablement également des attentes en fonction de la façon dont vous rendez le NestedLayout dans votre contrôle parent. S'il est entièrement rendu, les utilisateurs peuvent s'attendre à pouvoir interagir avec lui. Mais si c'est juste un cadre avec une icône représentant son statut de "widget" ou d'objet incorporé, cela pourrait avoir un effet différent. Essayez de tester les deux dans une maquette interactive haute fidélité pour voir ce que les gens font. Ce serait formidable de tester avec un test d'utilisabilité à distance basé sur un scénario de test spécifique comme "Interagir avec le NestedLayout" ou quelque chose!
Jetez un oeil à IntelliJ IDEA Java IDE. Il a un très bel éditeur pour les formulaires GUI avec des dispositions imbriquées, prenant en charge l'édition par glisser-déposer tout à fait utilisable.
Envisagez de représenter réutilisable * contrôle * s. Vous devez donc modifier la deuxième mise en page en tant que toute nouvelle mise en page, mais dans un autre onglet/fenêtre du concepteur, comme un user control sur Visual Studio. Si l'utilisateur n'a pas besoin de beaucoup d'espace, il ne se souciera pas d'un espace d'écran plus petit (peut-être qu'il contiendrait simplement quelques boutons de toute façon).
Au début, j'allais ajouter une réponse similaire à certaines des réponses ci-dessus, flash par exemple grise et verrouille le contexte englobant si vous double-cliquez sur un objet composé. Mais je me suis alors rendu compte qu'en termes de conception, en fonction de votre application, vous ne souhaitiez peut-être pas faciliter la modification de "Layout B". Si ce que vous montrez dans votre exemple est ce qui se fait habituellement dans un éditeur GUI, cela implique que tout ce que nous voyons à l'écran est dans un seul objet. Rendre les mises en page imbriquées faciles à éditer favorisera l'ajout de fonctionnalités de plus en plus à cet objet, la mise en page A contenant tous les widgets.
La mise en place d'une légère barrière à la modification des mises en page imbriquées entraînera à terme la rupture de l'implémentation par l'utilisateur et, par conséquent, la création d'objets mieux encapsulés et plus faciles à gérer.
Par exemple. le concepteur Qt vous permet de modifier le contenu de chaque onglet d'une fenêtre à l'intérieur de l'éditeur de l'interface graphique, si vous ne faites pas attention, vous obtiendrez une implémentation d'une fenêtre qui fait le travail de tous ses onglets. Ce qui n'est vraiment pas une bonne chose.
Adobe Flash
Vous pouvez avoir des compositions (appelées symboles dans Flash) avec lesquelles vous pouvez interagir. À l'intérieur de ces compositions, vous pouvez avoir des calques et d'autres compositions. L'expérience est quelque peu mauvaise parce que Flash est si lent à travailler et a une interface utilisateur trop compliquée avec des boutons placés aux mauvais endroits et manque de raccourcis. Mais c'est un excellent point de départ pour l'inspiration.
Une sorte de mélange entre Interface Builder, World Craft et Adobe Flash basculerait pour l'édition de compositions imbriquées.