Comment un éditeur de code peut-il indiquer efficacement le niveau d'imbrication de code - sans utiliser d'indentation? [fermé]

J'ai écrit un éditeur de texte XML qui offre 2 options d'affichage pour le même texte XML, l'une indentée (pratiquement), l'autre justifiée à gauche. La vue justifiée à gauche a pour but d'aider les utilisateurs à «voir» les caractères d'espacement qu'ils utilisent pour l'indentation de texte brut ou de code XPath, sans interférence due à l'indentation, qui est un effet secondaire automatisé du contexte XML.

Je souhaite fournir des indices visuels (dans la partie non modifiable de l'éditeur) pour le mode justifié à gauche, ce qui aidera l'utilisateur, mais sans être trop élaboré.

J'ai juste essayé d'utiliser des lignes de connexion, mais cela semblait trop occupé. Le meilleur de ce que j'ai créé jusqu'à présent est présenté dans une copie d'écran fictive de l'éditeur ci-dessous, mais je cherche des alternatives meilleures / plus simples (qui ne nécessitent pas trop de code).

[Modifier]

En prenant l’idée de la heatmap (de: @jimp), j’obtiens ceci et 3 alternatives - étiquetées a, b et c:

La section suivante décrit la réponse acceptée en tant que proposition, en rassemblant les idées de plusieurs autres réponses et commentaires. Comme cette question est maintenant un wiki de communauté, n'hésitez pas à le mettre à jour.

NestView

Le nom de cette idée qui fournit une méthode visuelle pour améliorer la lisibilité du code imbriqué sans utiliser l’indentation.

Lignes de contour

Le nom des lignes ombrées différemment dans NestView

L'image ci-dessus montre le NestView utilisé pour visualiser un extrait de code XML. Bien que XML soit utilisé pour cette illustration, toute autre syntaxe de code utilisant l'imbrication aurait pu être utilisée pour cette illustration.

Un aperçu:

1. Les lignes de contour sont ombrées (comme dans une carte thermique) pour indiquer le niveau d'imbrication

2. Les lignes de contour sont inclinées pour indiquer quand un niveau d'imbrication est en cours d'ouverture ou de fermeture.

3. Une ligne de contour relie le début d'un niveau d'imbrication à la fin correspondante.

4. La largeur combinée des lignes de contour donne une impression visuelle du niveau d'imbrication, en plus de la carte thermique.

5. La largeur de NestView peut être redimensionnable manuellement, mais ne doit pas changer lorsque le code change. Les lignes de contour peuvent être compressées ou tronquées pour continuer à fonctionner.

6. Des lignes vierges sont parfois utilisées dans le code pour diviser le texte en morceaux plus faciles à digérer. De telles lignes pourraient déclencher un comportement spécial dans NestView. Par exemple, la carte thermique peut être réinitialisée ou une ligne de contour de couleur d'arrière-plan utilisée, ou les deux.

7. Une ou plusieurs lignes de contour associées au code actuellement sélectionné peuvent être mises en surbrillance. La ligne de contour associée au niveau de code sélectionné serait la plus accentuée, mais d’autres lignes de contour pourraient également «s’éclairer» en plus d’aider à mettre en évidence le groupe imbriqué contenant.

8. Différents comportements (tels que le pliage de code ou la sélection de code) peuvent être associés à un clic / un double-clic sur une ligne de contour.

9. Différentes parties d'une ligne de contour (bord d'attaque, milieu ou arrière) peuvent être associées à différents comportements dynamiques.

10. Des info-bulles peuvent être affichées sur un événement de survol de la souris sur une ligne de contour

11. NestView est mis à jour continuellement au fur et à mesure que le code est édité. Lorsque l'imbrication n'est pas bien équilibrée, des hypothèses peuvent être établies là où le niveau d'imbrication doit se terminer, mais les lignes de contour temporaires associées doivent être mises en évidence de manière à constituer un avertissement.

12. Les comportements de glisser-déposer des lignes de contour peuvent être pris en charge. Le comportement peut varier en fonction de la partie de la ligne de contour déplacée.

13. Les fonctionnalités couramment trouvées dans la marge de gauche, telles que la numérotation des lignes et la mise en surbrillance des couleurs pour les erreurs et le changement d'état, peuvent recouvrir NestView.

Fonctionnalité supplémentaire

La proposition aborde une série de questions supplémentaires - beaucoup n'entrent pas dans le cadre de la question initiale, mais constituent un effet secondaire utile.

Liaison visuelle du début et de la fin d'une région imbriquée

Les courbes de niveau relient le début et la fin de chaque niveau imbriqué

Mettre en évidence le contexte de la ligne actuellement sélectionnée

Lorsque le code est sélectionné, le niveau de nid associé dans NestView peut être mis en évidence.

Différenciation entre les régions de code au même niveau d'imbrication

Dans le cas de XML, différentes nuances peuvent être utilisées pour différents espaces de noms. Les langages de programmation (tels que c #) prennent en charge des régions nommées pouvant être utilisées de la même manière.

Division des zones d'une zone de nidification en différents blocs visuels

Des lignes supplémentaires sont souvent insérées dans le code pour améliorer la lisibilité. Ces lignes vides peuvent être utilisées pour réinitialiser le niveau de saturation des lignes de contour de NestView.

Affichage de code multi-colonne

Le code sans indentation rend l'utilisation d'une vue multi-colonnes plus efficace car le retour à la ligne automatique ou le défilement horizontal sont moins susceptibles d'être requis. Dans cette vue, une fois que le code a atteint le bas d'une colonne, il passe à la suivante:

Utilisation au-delà d'une simple aide visuelle

Comme proposé dans la vue d'ensemble, NestView pourrait fournir une gamme de fonctions d'édition et de sélection qui correspondraient dans l'ensemble aux attentes d'un contrôle TreeView. La principale différence est qu'un nœud TreeView typique comprend 2 parties: un expandeur et l'icône du nœud. Une ligne de contour NestView peut comporter jusqu'à 3 parties: un ouvre-porte (en pente), un connecteur (vertical) et une fermeture (en pente).

Sur l'indentation

NestView présenté aux côtés de compléments de code non indentés, mais ne remplacera probablement pas la vue de code traditionnelle indentée.

Il est probable que toute solution adoptant NestView fournira une méthode permettant de basculer de manière transparente entre les vues de code indentées et non indentées sans affecter le texte de code lui-même, y compris les caractères d'espacement. Une technique pour la vue indentée est la "mise en forme virtuelle", où une marge gauche dynamique est utilisée à la place de caractères de tabulation ou d'espacement. Les mêmes données de niveau d'imbrication utilisées pour rendre dynamiquement le NestView pourraient également être utilisées pour la vue en retrait plus conventionnelle.

Impression

L'indentation sera importante pour la lisibilité du code imprimé. Ici, l'absence de caractères de tabulation / espace et d'une marge dynamique à gauche signifie que le texte peut être renvoyé à la ligne droite tout en maintenant l'intégrité de la vue en retrait. Les numéros de ligne peuvent être utilisés comme marqueurs visuels pour indiquer où le code est enveloppé par un mot et aussi la position exacte de l'indentation:

Screen Real-Estate: Vs plat en retrait

Aborder la question de savoir si le NestView utilise des informations de valeur sur un écran:

Les lignes de contour fonctionnent bien avec une largeur identique à la largeur de caractère de l'éditeur de code. Une largeur NestView de 12 caractères peut donc accueillir 12 niveaux d'imbrication avant que les lignes de contour ne soient tronquées / compressées.

Si une vue en retrait utilise 3 largeurs de caractères pour chaque niveau d'imbrication, l'espace est sauvegardé jusqu'à ce que l'imbrication atteigne 4 niveaux d'imbrication. Après ce niveau d'imbrication, la vue à plat présente un avantage d'économie d'espace qui augmente avec chaque niveau d'imbrication.

Remarque: Une indentation minimale de 4 caractères est souvent recommandée pour le code, mais XML gère souvent avec moins. De plus, le formatage virtuel permet d’utiliser moins d’indentation car il n’ya aucun risque de problèmes d’alignement.

Une comparaison des 2 vues est présentée ci-dessous:

Sur la base de ce qui précède, il est probablement juste de conclure que le choix du style d'affichage reposera sur des facteurs autres que l'immobilier. La seule exception concerne les cas où l'espace d'écran est limité, par exemple sur un Netbook / une tablette ou lorsque plusieurs fenêtres de code sont ouvertes. Dans ces cas, le NestView redimensionnable semblerait être un gagnant clair.

Cas d'utilisation

Exemples d’exemples concrets dans lesquels NestView peut être une option utile:

1. Où écran immobilier est à une prime

   une. Sur des appareils tels que des tablettes, des blocs-notes et des smartphones

   b. Lors de l'affichage du code sur des sites Web

   c. Lorsque plusieurs fenêtres de code doivent être visibles simultanément sur le bureau

2. Lorsque l'indentation cohérente d'un texte dans le code est une priorité

3. Pour revoir le code profondément imbriqué. Par exemple, les sous-langages (par exemple, Linq en C # ou XPath en XSLT) peuvent entraîner des niveaux élevés d’imbrication.

Accessibilité

Des options de redimensionnement et de couleur doivent être fournies pour aider les malvoyants mais également pour s'adapter aux conditions environnementales et aux préférences personnelles:

Compatibilité du code édité avec d'autres systèmes

Une solution intégrant une option NestView devrait idéalement être capable de supprimer les caractères de tabulation et d'espacement (identifiés comme ayant uniquement un rôle de formatage) du code importé. Ensuite, une fois dépouillé, le code pourrait être parfaitement restitué sans modification dans les vues justifiée à gauche et en retrait. Pour de nombreux utilisateurs qui utilisent des systèmes tels que la fusion et les outils de diff qui ne sont pas sensibles aux espaces, cela sera une préoccupation majeure (si ce n’est un obstacle complet).

Autres travaux:

Visualisation du balisage se chevauchant

La recherche publiée par Wendell Piez , datant de 2004, aborde le problème de la visualisation de balises superposées, en particulier de LMNL . Cela inclut les graphiques SVG présentant des similitudes importantes avec la proposition NestView. Ils sont donc reconnus ici.

Les différences visuelles sont claires dans les images (ci-dessous). La principale différence fonctionnelle est que NestView est destiné uniquement au code XML ou au code bien imbriqué, tandis que les graphiques de Wendell Piez sont conçus pour représenter une imbrication superposée.

Les graphiques ci-dessus ont été reproduits - avec l'aimable autorisation - de http://www.piez.org

Sources:

1. Vers le balisage herménutique
2. Demi-pas vers LMNL

J'ai tenté de répondre à ma propre question ici, mais cela incorpore l'idée de heatmap de @jimp et également l'idée de "rendre le plus XML-ish" de @Andrea:

Espérons que les couleurs de la carte thermique, ainsi que les lignes angulaires, permettent d’attirer l’œil entre les balises de début et de fin; le retrait des séparateurs de lignes horizontales améliore le «flux» du début à la fin. Lorsque l'utilisateur sélectionne avec un élément, la partie correspondante de la carte thermique peut être mise en surbrillance, par exemple avec une bordure rougeoyante (comme indiqué).

Modifier Si vous avez décidé de suivre cette procédure, il vous faudra probablement des options utilisateur pour les couleurs. Une capture d'écran 'production prête':

Et pour comparaison ... la vue en retrait alternative:

Edit Now, pour le cas plus fortement imbriqué - tester mes compétences en dessin ...

Une idée pourrait être d’ajouter de la 3D au texte. Augmentez / diminuez la taille de la police en fonction de son niveau.

Par exemple, ce code:

Ressemblerait à ceci:

Cela peut être ennuyeux de travailler avec cela car il perd un alignement fixe de la taille du texte à travers différents niveaux. Une autre idée; changer la saturation de chaque niveau:

Dans quelle mesure cela tient-il pour quelque chose de vraiment profond? Pas certain...

En fait, j'aime beaucoup votre idée de visualisation de gouttière; il est facile de regrouper les choses. Peut-être combiné avec l'une de ces idées, il sera encore mieux, ou beaucoup plus triste. ;)

Il y a quelque temps, j'ai fait une carte thermique montrant la portée de C. Il serait peut-être amusant de regarder pour un brainstorming:

Aligné-gauche:

Modifiez simplement votre idée initiale et passez des carrés aux capsules. Je pense que ces versions (y compris votre version originale) sont plus faciles à lire car elles sont moins complexes que celle qui montre l'imbrication via l'imbrication des éléments d'affichage. Je pense que les éléments d’arbre transmettent l’information d’une manière plus simple et intuitive.

Je pense que la gauche est idéale pour afficher directement l'indentation, tandis que la droite est meilleure pour transmettre une relation imbriquée.

Mon idée:

La nidification ressemble plus à une nidification. La largeur horizontale de chaque couche n'a pas besoin d'être aussi large.

J'aime l'idée. Ma suggestion de garder le "occupé" bas serait d'utiliser des gradients au lieu de carrés. Cela réduirait les lignes. Peut-être différentes couleurs pour indentation extrême.

Je dirais que tout ce que vous avez est excellent, bien qu’un peu caillouteux à mon goût.

Mes commentaires: Je me suis toujours battu avec la manière dont l'EDI de Visual Studio procède à l'indentation. J'aimerais utiliser quelque chose comme ceci ou une variation.

Alors imaginez ce lien sans les lignes, et en ligne avec votre code / XML actuel.

Puisque vous avez dit que la visualisation doit exister dans la marge non modifiable (à gauche?), Je pense que cela signifie que la visualisation ne peut être mélangée ni derrière le code.

Peut-être une carte de chaleur dans la colonne de gauche, avec des couleurs plus claires indiquant une indentation plus profonde? Attribuez à la marge une taille fixe, avec une visualisation similaire à celle que vous avez (attendez-vous à aller de gauche à droite), qui utilise de manière dynamique tout l’espace donné en fonction de l’indentation maximale déterminée par la profondeur du DOM.

Si vous étiez disposé à vous lancer dans la région de l'éditeur, je suggérerais quelque chose de très similaire, mais en tant que fond du document. La zone ombrée serait l'endroit où l'espace serait si l'indentation était activée. Dans ce cas, j'utiliserais une couleur unie et claire contrastant avec le texte en surbrillance.

jGRASP fait cela en utilisant un marqueur visuel dans la marge:

Il reconnaît même lorsque vous utilisez une boucle et utilise un type de ligne différent pour représenter cette boucle interne.

Je pensais juste que je ferais remarquer comment un éditeur existant le fait.

Ce n’est pas une mauvaise idée que de devoir faire référence à la marge gauche pour voir clairement que mes blocs peuvent devenir un peu gênants. Cela ne fait même pas penser à l’écran ou à ce qui pourrait se passer si la structure devient très profonde.

Comme la motivation est d'aider les utilisateurs à "voir" les caractères d'espacement qu'ils utilisent pour l'indentation, vous pouvez simplement leur montrer les caractères d'espace.

Je ne parle pas de caractères visuels spéciaux comme des marqueurs de paragraphe, mais seulement des points saillants. Espaces en jaune, onglets en vert (ou autre)

Pour le problème de marge / imbrication, vous pouvez simplement déplacer la marge de chaque bloc. Rien ne dit que la marge doit être une ligne droite.

Je suis sûr que ce n'est pas une nouvelle idée.

Quelque chose comme ça:

Pourquoi ne pas ouvrir et fermer les parenthèses?

1. Indentation signifie confinement: (et) signifie exactement cela pour les programmeurs.
2. (et) sont chacun un seul caractère: la barre de gauche restera très fine.
3. Les éléments vides sont facilement repérables: utilisez () sur la même ligne.
4. Le contenu d'un élément n'a pas besoin d'un indice visuel: un blanc est bien meilleur.
5. La position du curseur à droite peut être comparée au bloc contenant à gauche: ajoute dynamiquement une couleur aux caractères de la colonne avec (et)
6. Vous pouvez le rendre plus XML-ish en utilisant <et>, qui ont meilleure apparence de loin.

Vim peut déjà faire quelque chose de similaire, mais pas aussi joli.

Il y a différentes façons de faire le "pliage de code" dans Vim. L'un d'eux est basé sur une règle de pliage de syntaxe. Lorsque cela est fait, le code peut être plié en utilisant une structure hiérarchique imbriquée et le "FoldColumn" peut être utilisé pour donner une représentation graphique (en fait "basée sur les caractères" avec "|" et "-") du "foldlevel" .

La foldcolumn peut donner la représentation imbriquée quelle que soit la méthode fold, mais la méthode basée sur la syntaxe est celle qui conviendrait probablement pour ce que vous voulez. Je ne sais pas s'il existe des règles de pliage prédéfinies basées sur la syntaxe pour XML quelque part, je suppose qu'il pourrait y en avoir

Je pense que vous êtes sur la bonne voie avec les options B et C: incluez à la fois la couleur de la largeur et celle du calque thermique. J'aime l'option B plus que C pour le moment, car elle est moins intrusive (large et diluée, ou étroite et intense, plutôt que le très lourd bloc au milieu de C). Un inconvénient est que, avec cette option, vous devez reconstruisez le graphique entier si vous insérez un niveau quelque part. Je pense que vous pourriez rendre les blocs beaucoup plus petits, 1 ou 2 px suffiraient probablement. Il n'est pas nécessaire que ce soit beaucoup, il faut seulement pouvoir le distinguer. Surtout quand on s'attend à ce que les gens utilisent l'éditeur plusieurs fois, il est plus facile de travailler avec des effets plus discrets et plus subtils, car ils ne distraient pas autant.

Une chose importante lorsque vous utilisez un éditeur de type est toutefois de mettre en évidence la portée actuelle: lorsque vous sélectionnez une ligne dans l'éditeur, vous devez voir exactement quels éléments elle contient et où elle s'arrête. Vous pouvez même mettre l’arbre en évidence (de quels éléments est-il l’enfant). Je pense que c'est un problème distinct qui doit être abordé et réfléchi et qui aura plus d'influence sur la manière dont les utilisateurs évalueront leur expérience avec l'éditeur.

Une chose que je n'ai pas vue mentionnée est ce que vous pouvez faire avec la teinte en plus de l'effet de saturation sur lequel vous semblez être installé. Ma suggestion est de changer la couleur du nid dans lequel se trouve le pointeur. Cela permettrait à l'utilisateur de distinguer plus facilement les lignes faisant partie du nid, par rapport aux frères et sœurs.

Lors de la mise en œuvre d'éléments basés sur la teinte, soyez conscient du daltonisme et choisissez des couleurs universellement reconnaissables ou proposez quelques options parmi lesquelles choisir.

Une option, qui pourrait être utilisée conjointement avec les autres suggestions suggérées jusqu'à présent, serait d'utiliser une info-bulle dans la marge de gauche qui indique le chemin d'accès à la ligne en utilisant la notation XPath. Les outils "inspecter les éléments" du navigateur (par exemple, Firebug, celui intégré à Chrome) font souvent quelque chose de similaire, mais dans une barre d'état.

Vous pourriez éventuellement avoir une vue réduite de la carte thermique (à partir du message d'origine) avec une seule colonne de couleurs et le nombre de profondeurs. Cela leur permettrait de savoir à quelle profondeur ils sont et de leur donner plus d’écran d’affichage pour le xml. On dirait une victoire gagnant pour moi.

Je me demande s'il y aura suffisamment de différences de couleur pour imbriquer les choses en profondeur.