Gutenberg: Améliorer les outils de sélection des blocs enfants / parents

J'aime l'idée du fil d'Ariane. (En fait, j'ai suggéré quelque chose d'assez similaire dans # 6459 en avril.) Que se passerait-il avec le fil d'Ariane lorsque la barre d'outils unifiée était activée?

Je pense aussi que l'idée de clic est bonne aussi, et elle est déjà utilisée sur mobile, donc elle ajoute de la cohérence. Je ne suis pas si sûr de l'idée de passage, cependant; J'imagine que cela pourrait causer de la confusion en raison de comportements différents à travers les blocs.

J'aime le fil d'Ariane mais j'aime aussi la barre d'outils unifiée. Pouvons-nous trouver une autre position pour le fil d'Ariane :)

Aussi, personnellement, je n'aime pas les frontières autour du bloc parent. Mais si nous les conservons, comment traitons-nous la multisélection :). Devrions-nous afficher les frontières autour du parent des blocs multisélectionnés?

J'aime l'option de clic. Cela nécessitera un travail supplémentaire sur le bloc «passthrough» (donc chaque «colonne» individuelle n'est pas considérée comme un calque à traverser, par exemple) mais je pense que cela a beaucoup de sens.

Que se passe-t-il avec le fil d'Ariane lorsque la barre d'outils unifiée est activée?
J'aime le fil d'Ariane mais j'aime aussi la barre d'outils unifiée. Pouvons-nous trouver une autre position pour le fil d'Ariane :)

Bonne question. Maquette rapide et sale:

Oui, je vois le défi de l'icône en double pour le mélangeur. Je pense qu'il est bon de continuer à y penser. Notez également comment cette conception omet le contour du document, qui est bloqué sur # 4287.

Aussi, personnellement, je n'aime pas les frontières autour du bloc parent. Mais si nous les conservons, comment traitons-nous la multisélection :). Devrions-nous afficher les frontières autour du parent des blocs multisélectionnés?

Je pense qu'il est important de les montrer comme indiquant que les blocs internes font partie du groupe de parents. Ils ancrent les blocs intérieurs.

À l'heure actuelle, voici comment fonctionne la sélection multiple:

Et c'est ce qui se passe lorsque vous sélectionnez simplement deux blocs enfants:

En d'autres termes, dans master, nous avons déjà en quelque sorte la bordure parente, _et_ nous la cachons lors de la sélection multiple de blocs enfants. En fait, je pense que montrer toujours la frontière parent, même en sélection multiple, a du sens lorsque vous ne sélectionnez que des blocs enfants. Mais peut-être devrions-nous rendre la sélection multiple différente lorsque le bloc _parent_ est multi-sélectionné. Ainsi, au lieu de mettre en surbrillance chaque bloc enfant avec des effets de calque supplémentaires, nous mettons _seulement_ en surbrillance le bloc parent. Cela fonctionnerait-il?

J'aime l'option de clic. Cela nécessitera un travail supplémentaire sur le bloc «passthrough» (donc chaque «colonne» individuelle n'est pas considérée comme un calque à traverser, par exemple) mais je pense que cela a beaucoup de sens.

Oui, actuellement, le bloc enfant _column_ présente quelques défis d'interface utilisateur. Par exemple, vous ne pouvez pas insérer un bloc avant lui, alors pourquoi pouvez-vous le sélectionner? C'est un défi technique extrêmement difficile, et je comprends les défis que cela implique. Je ne dis donc pas que c'est facile.

Alors que je travaillais sur https://github.com/WordPress/gutenberg/pull/9653 , je me suis rendu compte que la navigation par touches fléchées que nous avons déjà présente pour naviguer dans la hiérarchie (utilisez la touche fléchée vers le haut lorsqu'une colonne est sélectionnée pour sélectionner le parent , c'est-à-dire le bloc de colonnes) fonctionne vraiment bien. Tellement bien en fait, que peut-être simplement faire apparaître cette fonctionnalité comme un bouton "haut", similaire à "aller au dossier parent" dans l'explorateur de fichiers Windows, pourrait être suffisant au lieu d'un fil d'Ariane complet.

Voici à quoi cela pourrait ressembler. Barre d'outils supérieure:

Barre d'outils de bloc:

CC: @youknowriad

Quelques idées

Chapelure

J'aime la solution de fil d'Ariane, mais elle souffre d'ambiguïté, une interface avec une seule icône peut être problématique et je peux me voir survoler les icônes pour voir ce qu'elles sont, ou confondre le fil d'Ariane pour une barre d'outils d'options plutôt que du fil d'Ariane.

Alors peut-être que la barre d'outils supérieure n'est pas le meilleur endroit pour l'afficher, et peut-être que certains indices provenant de fil d'Ariane ailleurs pourraient aider. Par exemple, la barre d'outils hiérarchique dans PHPStorm qui affiche le fichier -> classe -> méthode / fonction dans laquelle vous vous trouvez actuellement, ou la barre d'outils des dossiers dans MacOS Finder et Windows Explorer?

Cliquez sur

Cliquer à travers serait une interface utilisateur cachée, je peux voir beaucoup de malentendus et de confusion car les gens s'attendent à sélectionner un bloc d'image uniquement pour trouver que le bloc de colonne contenant est sélectionné. Habituellement, cliquer sur l'interface utilisateur dans le logiciel Adobe est déroutant car il introduit des modes, et il est difficile de dire où vous vous trouvez et comment le quitter, surtout s'il y a une imbrication. Par exemple, si vous double-cliquez pour entrer dans un bloc enfant, comment revenir au bloc parent et comment l'interface utilisateur indique-t-elle que vous êtes à l'intérieur d'un bloc?

Il y a beaucoup de recherches et de directives sur les modes, et quelque chose ne devrait pas être considéré comme bon car il est présent dans Illustrator ou Photoshop, il faut beaucoup plus de travail que de simplement cliquer avant que cela devienne une solution appropriée.

https://medium.com/interaction-reimagined/dangers-of-modal-user-interfaces-316828de8161

http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

Cela ignore tous les facteurs d'accessibilité que cela perturbe également.

Le bouton Haut

L'idée du bouton haut est sympa. Ma préoccupation serait que cela implique que si vous appuyez dessus, un bouton vers le bas apparaîtra et le bloc se déplacera vers le haut, il est ambigu et souffre des mêmes problèmes que le bloc de fil d'Ariane.

Le modèle de blocs réutilisables

À l'heure actuelle, les blocs réutilisables ont déjà un modèle d'interface utilisateur qui ajoute du chrome à l'interface de bloc qui n'est pas visible sur le frontend. Les colonnes ne pourraient-elles pas faire de même?

Ou une super maquette de ce que je veux dire

Ainsi, le chrome du bloc de colonnes serait ce qui est utilisé pour le sélectionner, et il fournit quelque chose de visuel sur lequel viser la souris.

Un modèle UX potentiel que nous pourrions utiliser ici et qui correspondrait à notre modèle de barre d'outils est le bouton de traversée du dossier OS X: https://cld.wthms.co/avtQLO

Je note que je pense que les utilisateurs s'attendront à être en mesure de sélectionner visuellement les blocs enfants / parents en cliquant et en sélectionnant, mais il y a évidemment beaucoup de complexité à faire cela correctement. Le modèle de parcours ci-dessus pourrait être une bonne première étape et nous pourrions approfondir le développement d'une solution plus élégante dans la phase 2.

J'adore ce concept Alexis, notamment pour les blocs plus complexes que vous évoquez. Je l'aime tellement que j'ai immédiatement couru avec et remixé quelques-unes des maquettes pour illustrer votre idée.

Pas de choix:

Bloc sélectionné:

Bloc imbriqué à l'intérieur sélectionné:

La fenêtre contextuelle du bouton de parcours de dossier s'ouvre:

☝️ Je suis un peu amoureux de ce concept, j'ai l'impression qu'il fusionne toutes les idées et les commentaires partagés sur ce fil, ce qui en fait une base de référence _solid_ à partir de laquelle itérer. Merci beaucoup d'avoir apporté cette nouvelle perspective!

J'adore la liste déroulante avec l'arborescence visuelle, une partie de moi pense que voir le document entier dans ce format serait également utile et fournirait même un moyen utile de réorganiser les choses.

Cependant, après réflexion, on m'a rappelé que nous avons déjà un mécanisme de sélection comme celui-ci, et un aperçu du document dans le panneau d'information:

Cela pourrait être amélioré avec le style de votre maquette et servir de signifiant de sélection supplémentaire. Pour le moment, il ne montre que les titres, mais une version avec un arbre de blocs complet et un indicateur de sélection serait très utile

Mon seul scrupule est avec l'icône de la barre d'outils elle-même. c'est encore une autre icône mystère avec une flèche, et c'est un bouton qui n'est pas dans le Finder sur MacOS par défaut, sauf si vous personnalisez la barre d'outils. Pour ceux d'entre nous qui sont aveugles aux icônes et incapables de distinguer facilement les icônes, c'est problématique

Avec l'étiquette de texte, c'est plus clair, mais sans elle, la plupart ne sauraient pas ce qu'il a fait sans cliquer dessus:

Vous cherchez bien :) Pouvons-nous essayer de simplifier un peu l'icône pour une meilleure lisibilité? Peut-être 3 lignes avec un peu plus d'espacement au lieu de 4?

Avec l'étiquette de texte, c'est plus clair, mais sans elle, la plupart ne sauraient pas ce qu'il a fait sans cliquer dessus.

Il y aura également une info-bulle.

Dans le commentaire de re: @tomjn , je pense aussi qu'il serait intéressant d'explorer si cela pouvait être intégré dans l'arborescence globale du document plutôt que de créer un endroit séparé. Le défi ici est de maintenir la simplicité et la scannabilité de l'arbre tout en acceptant beaucoup plus de niveaux de choses. Mais peut-être que cela peut ressembler davantage au panneau des calques dans Sketch ou Photoshop (en termes de fonctionnalités, pas de conception!), Où c'est la seule source de vérité pour toute la structure de la page. Difficile de bien faire, mais vaut peut-être la peine d'être exploré?

Encore une fois, c'est probablement quelque chose sur lequel nous itérons, alors quel est le MVP le plus utile qui puisse devenir quelque chose de plus sophistiqué?

Il y aura également une info-bulle.

Je ne pense pas que ce soit suffisant, mais je pense que c'est une discussion séparée et une demande de fonctionnalité, je vais ouvrir un nouveau ticket

Peut-on essayer de simplifier un peu l'icône pour une meilleure lisibilité? Peut-être 3 lignes avec un peu plus d'espacement au lieu de 4?

J'aime ça:

Cependant, après réflexion, on m'a rappelé que nous avons déjà un mécanisme de sélection comme celui-ci, et un aperçu du document dans le panneau d'information:

Je pense également qu'il serait intéressant d'explorer si cela pouvait être intégré dans l'arborescence générale des documents plutôt que de créer un endroit séparé.

Je pense que cela pourrait fonctionner. J'ai précédemment suggéré que l'élément pourrait être réécrit en tant que plugin afin qu'il apparaisse à droite (voir # 4287). Mais je suis fan de la réutilisation de cela pour l'arborescence des documents.

En ce qui concerne une étiquette, j'aime les étiquettes, mais l'option d'ancrer la barre d'outils du bloc en haut doit être considérée dans cette optique.

Cette discussion me rappelle le # 9053 (CC: @westonruter) - Je pense que vous aimerez peut-être la proposition d'Alexis comme indiqué dans https://github.com/WordPress/gutenberg/issues/9628#issuecomment -429012989.

Super de voir cela évoluer et merci pour le concept @alexislloyd. @jasmussen J'aime vraiment ces

Alors, quel est le MVP le plus utile qui puisse devenir quelque chose de plus sophistiqué?

Je dirais de le construire comme un contrôle de parcours plus simple, et de regarder plus tard pour voir s'il est logique de le combiner avec la zone de contenu du document en fonction de la sélection.

Conformément à la discussion dans # 10767, rouvrir ceci pour itérer.

Voir également les idées supplémentaires suggérées dans le # 11159.

Une idée supplémentaire pour faciliter le travail avec des blocs complexes est de se rappeler que _le bloc non sélectionné est un aperçu_ et que le _ bloc sélectionné peut afficher des commandes d'édition supplémentaires_.

Nous pouvons tirer parti de cette idée pour faciliter la sélection des éléments d'un bloc de colonnes. Par exemple, lorsqu'un bloc de colonnes, ou l'un de ses enfants, est sélectionné, le remplissage du conteneur s'anime pour faire de la place pour sélectionner des éléments enfants. Cela rendrait également l'interface utilisateur latérale accessible. Nous voudrions afficher une bordure autour du bloc parent - celui avec un remplissage étendu - par exemple une ligne en pointillé.

Cela semble être relativement simple à implémenter, si nous restaurions la classe .is-selected sur le bloc de niveau supérieur même lorsqu'un enfant est sélectionné. Nous l'avons fait en utilisant un accessoire hasSelectedInnerBlocks il y a quelque temps.

Voici ce que nous voyons lorsque nous survolons une cellule dans un bloc de colonnes:

Survolez une cellule du bloc Médias et texte.

On voit le bloc intérieur et le bloc extérieur.
Tels que Colonne -> Paragraphe. Colonne -> YouTube. Médias et texte -> YouTube

Il serait bon de rendre cliquables les informations de fil d'Ariane (blocs internes et externes) dans les informations de survol. Cliquez sur Colonne pour sélectionner le parent ou sur Paragraphe pour sélectionner l'enfant.

En essayant cela tout à l'heure, une chose que j'ai remarquée est que le moyen le plus simple de sélectionner un bloc de colonne parent est d'utiliser la zone de frappe invisible supplémentaire que nous proposons à droite / gauche du bloc parent:

Cette zone de frappe supplémentaire n'est pas disponible en haut et en bas du bloc, ce qui rend beaucoup plus difficile la sélection de cette façon.

Une idée supplémentaire pour faciliter le travail avec des blocs complexes, est de se rappeler que le bloc non sélectionné est un aperçu et que le bloc sélectionné peut afficher des commandes d'édition supplémentaires

Nous pouvons tirer parti de cette idée pour faciliter la sélection des éléments d'un bloc de colonnes. Par exemple, lorsqu'un bloc de colonnes, ou l'un de ses enfants, est sélectionné, le remplissage du conteneur s'anime pour faire de la place pour sélectionner des éléments enfants. Cela rendrait également l'interface utilisateur latérale accessible. Nous voudrions afficher une bordure autour du bloc parent - celui avec un remplissage étendu - par exemple une ligne en pointillé.

Je ne suis pas sûr à 100% si c'est ce que @jasmussen suggère ci-dessus, mais ajouter un peu de remplissage + un indicateur visuel du bloc parent en mode d'édition pourrait être une aide majeure ici. De cette façon, il y a une indication claire de l'endroit où vous devez cliquer si vous souhaitez sélectionner le parent:

Lorsque quelqu'un quitte le bloc, ce remplissage supplémentaire peut disparaître pour afficher une représentation plus précise du bloc.

Cette zone de frappe supplémentaire n'est pas disponible en haut et en bas du bloc, ce qui rend beaucoup plus difficile la sélection de cette façon.

Je pourrais Jurer qu'il y avait un ticket autour de ce problème, qui est lié au fonctionnement de l'inséreuse frère. Je ne peux pas le trouver pour le moment, mais je pense que ce problème devrait être résolu. @aduth sonne des cloches, je pourrais jurer que vous étiez dans les commentaires?

Je ne suis pas sûr à 100% si c'est ce que @jasmussen suggère ci-dessus, mais ajouter un peu de remplissage + un indicateur visuel du bloc parent en mode d'édition pourrait être une aide majeure ici. De cette façon, il y a une indication claire de l'endroit où vous devez cliquer si vous souhaitez sélectionner le parent:

C'est plus ou moins exactement ce que je voulais dire, seulement plus magnifiquement visualisé que je ne pourrais.

Voici un croquis supplémentaire au crayon pour illustrer ce que je veux dire. Bloc de colonnes:

Essentiellement ce que vous avez, Kjell - peut-être avec la ligne pointillée légèrement plus foncée. De plus, en fonction du développement ultérieur du bloc de colonnes, rappelez-vous qu'il existe également des blocs _column_. Ie la hiérarchie actuellement est _Colonnes → Colonne → Image_. Nous utilisons une féroce magie CSS pour rendre le deuxième niveau plus ou moins invisible, mais au cas où vous voudriez le sélectionner à l'avenir pour, par exemple, lui appliquer une classe CSS ou toute autre option dont nous pourrions avoir besoin pour des colonnes individuelles, c'est Vaut la peine d'être considéré.

Bloc de diaporama:

Pour être clair: aucun bloc de diaporama n'est prévu. Ceci est purement griffonné pour illustrer le fait que les modes d'aperçu et d'édition d'un bloc peuvent être _ largement_ différents. Il est si facile et étonnamment non perturbateur de basculer entre les deux modes en sélectionnant et désélectionnant simplement les blocs, que nous devrions nous permettre de nous y pencher et d'être créatifs sur les opportunités.

Dans le cas d'un bloc de diaporama, presque par définition, le contenu sera invisible en dehors de l'écran / du bloc. Mais ce n'est pas nécessaire lorsque vous l'éditez. Sélectionnez simplement le bloc pour voir les miniatures avec des légendes modifiables. Désélectionnez ensuite le bloc pour prévisualiser le résultat.

Je pourrais Jurer qu'il y avait un ticket autour de ce problème, qui est lié au fonctionnement de l'inséreuse frère. Je ne peux pas le trouver pour le moment, mais je pense que ce problème devrait être résolu. @aduth sonne des cloches, je pourrais jurer que vous étiez dans les commentaires?

Je pense que la chose la plus proche pourrait être l'une des # 8883, # 8881, # 5180?

Bien que l'arborescence du document soit utile, elle m'oblige toujours à changer de focus par rapport à ce que j'essaie de manipuler. J'aimerais vraiment une meilleure façon de cliquer directement sur les blocs réels et les blocs imbriqués. Je pense que la méthode de clic décrite ci-dessus par @jasmussen vaut la peine d'être explorée davantage.

Voici le problème que je rencontre couramment:

En tant qu'utilisateur, je vais me battre avec cela pendant au moins une minute avant de trouver une autre solution située ailleurs sur l'écran. 😉

* _Lorsque j'ai ajouté ce commentaire, un tas d'autres commentaires sont apparus. Ce n'est peut-être pas aussi pertinent maintenant, mais je le garde ici pour documenter la lutte.

mais ajouter un peu de remplissage + un indicateur visuel du bloc parent en mode édition pourrait être une aide majeure ici. De cette façon, il y a une indication claire de l'endroit où vous devez cliquer si vous souhaitez sélectionner le parent:

Ma préoccupation avec cette solution est de savoir comment le remplissage fonctionne par rapport aux blocs environnants:

1. Le remplissage dans le bloc parent est-il reflété sur le front-end? Ou simplement plus de remplissage dans l'éditeur?

2. Le remplissage est-il ajouté dynamiquement lorsque le bloc est sélectionné, comme ceci?

1. Ou peut-être que le parent rembourré apparaît au-dessus des blocs environnants, comme ça?

J'essaie juste d'approfondir ce concept. J'adorerais quelques réflexions à ce sujet.

Merci @aduth , tu m'as fait trouver au moins un billet qui va dans le bon sens. Le GIF dans # 9229 explique le problème: la zone jaune de ce GIF est "réservée" à l'inséreuse frère. C'est ce qui vous empêche de sélectionner le bloc en cliquant sur le remplissage au-dessus ou en dessous du bloc. C'est la réponse au commentaire de

Cette zone de frappe supplémentaire n'est pas disponible en haut et en bas du bloc, ce qui rend beaucoup plus difficile la sélection de cette façon.

Pour clarifier davantage, cette zone jaune n'est là que pour rendre VISIBLE le bouton d'insertion frère. Donc, tout ce dont nous avons besoin pour intercepter, en réalité, c'est l'action _hover_. Ce serait bien si un clic pouvait toujours se propager à travers cette barre jaune et vous permettre de sélectionner le bloc ci-dessous.

Bien que l'arborescence du document soit utile, elle m'oblige toujours à changer de focus par rapport à ce que j'essaie de manipuler. J'aimerais vraiment une meilleure façon de cliquer directement sur les blocs réels et les blocs imbriqués. Je pense que la méthode de clic décrite ci-dessus par @jasmussen vaut la peine d'être explorée davantage.

Vous pouvez en fait tester cela dès maintenant, même si l'implémentation actuelle est légèrement à moitié cuite.

• Exécutez Gutenberg, n'importe quelle version.
• Insérez un bloc de colonnes avec du contenu.
• Redimensionnez la fenêtre en dessous du point d'arrêt 600px, puis sélectionnez.

Ceci est mis en œuvre pour mobile, en d'autres termes, pour vous permettre de sélectionner plus facilement le bloc parent.

GIF:

Le problème avec la mise en œuvre à l'heure actuelle est que "l'état" est réinitialisé une fois que vous avez atteint le niveau le plus profond. Il en va de même pour Colonnes> Colonne> Paragraphe, Colonnes> Colonne> Paragraphe, même si vous sélectionnez simplement le même paragraphe deux fois. La solution évidente à ce problème à essayer est de faire en sorte qu'une fois que vous avez "creusé" au niveau souhaité, vous restez à ce niveau jusqu'à ce que vous désélectionnez à nouveau le bloc. Ie Colonnes> Colonne> Paragraphe, Paragraphe, Paragraphe, désélectionner, rembobiner, etc.

Je crois également que pour certains blocs, cette méthode de clic sera d'une importance cruciale. D'autant que nous commençons à examiner les modèles de page qui peuvent inclure toutes sortes de contenus imbriqués.

L'inspiration sur la façon dont le clic pourrait fonctionner quand c'est incroyable peut également être essayée dans Keynote. Insérez quelques formes et vous pouvez les cliquer directement. Dès que vous _groupez_ deux formes, elles deviennent une nouvelle forme facile à déplacer. Mais pour éditer le contenu du groupe, vous devez double-cliquer.

Pour répondre à vos bonnes questions sur https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456637172:

Le remplissage dans le bloc parent est-il reflété sur le front-end? Ou simplement plus de remplissage dans l'éditeur?

Non, ce remplissage est uniquement dans l'éditeur et uniquement lorsque le _bloc est sélectionné_. Ceci est basé sur le principe du bloc est l'interface , qui stipule que dans l'éditeur:

• un bloc non sélectionné est un aperçu. Il doit ressembler autant que possible au frontend
• un bloc sélectionné est essentiellement en "mode d'édition de bloc", et le bloc peut produire des commandes supplémentaires et même avoir un aspect totalement différent, dans cet état.

C'est ce que j'ai essayé de mettre en évidence avec l'exemple de doodle de bloc de diaporama ci-dessus: lorsque le bloc de diaporama est désélectionné, c'est un diaporama. Lorsqu'elle est sélectionnée, vous êtes en _mode d'édition du diaporama_ et voyez une grille de vignettes de chaque diapositive, vous pouvez donc facilement modifier les légendes, réorganiser, etc.

Le remplissage est-il ajouté dynamiquement lorsque le bloc est sélectionné, comme ceci?

Oui plus ou moins.

Je pense que cela pourrait valoir la peine d'être prototypé pour mieux l'expliquer et se faire une idée.

En fin de compte, cette fonctionnalité devrait probablement être un accessoire sur le bloc lui-même, quelque chose qu'un bloc peut choisir d'utiliser. Un blockquote avec des paragraphes imbriqués, par exemple, ne devrait probablement pas utiliser cette interface - mais lors de l'édition de colonnes, cela peut être parfait.

Voici un prototype de codepen rapide: https://codepen.io/joen/pen/exmMQv?editors=1100

C'est un peu statique, mais j'espère que cela fait passer le message.

Voici un prototype de codepen rapide: https://codepen.io/joen/pen/exmMQv?editors=1100

C'est un peu statique, mais j'espère que cela fait passer le message.

Cela aide vraiment à faire passer le message. J'ai fait une légère modification, afin que nous puissions voir comment ces bordures en pointillés peuvent apparaître au clic:

https://codepen.io/kjellr/pen/jdEJQb?editors=0110

C'est parfait, merci Kjell! C'est exactement ce que je veux dire. Je crois que nous voudrons probablement régler certains aspects de la mise en œuvre et aborder son apparence lorsque le parent immédiat (colonne au singulier) est celui qui reçoit le remplissage. Mais c'est cool! Je pense que ça peut marcher.

J'aime vraiment ça.
Devrions-nous passer à la création d'un PR pour tester avec plus de blocs et de contenu?
Devons-nous identifier les blocages que cela affectera?

Je le creuse aussi.

Nous pouvons probablement prototyper cela sur le bloc Columns pour le moment, mais pour que cela arrive, nous aurions probablement besoin que cette _method_ soit à la fois générique, donc d'autres blocs (comme vous le dites) peuvent l'utiliser, mais aussi un accessoire pour qu'un bloc puisse choisissez d'y adhérer. Cela sera probablement perturbateur pour le bloc Quote d'avoir cela, une fois qu'il reçoit des blocs imbriqués.

@gziolo des pensées? Notamment sur l'approche griffonnée par Kjell dans https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456811415

@gziolo des pensées? Notamment sur l'approche griffonnée par Kjell dans # 9628 (commentaire)

Ça a l'air génial. Cela permettrait enfin de sélectionner facilement le bloc parent en cas de besoin. Ma seule question est de savoir comment vous sentiriez-vous à l'idée de rapprocher la largeur de la colonne de la taille d'origine au détriment des autres colonnes. Pour le moment, toutes les colonnes sont réduites lorsque l'une d'elles est sélectionnée, ce qui pourrait être une expérience sous-optimale avec 3 colonnes et plus. @jasmussen avez-vous d'autres questions auxquelles je devrais répondre?

Ma seule question est de savoir comment vous sentiriez-vous à l'idée de rapprocher la largeur de la colonne de la taille d'origine au détriment des autres colonnes.

J'aurais tendance à convenir que c'est quelque chose que nous devrions affiner et équilibrer, probablement dans la mise en œuvre. Nous pouvons également envisager d'élargir la largeur / hauteur du parent, pour ne pas réduire la taille de l'enfant, bien que ce soit probablement techniquement plus difficile.

avez-vous d'autres questions auxquelles je devrais répondre?

Fondamentalement, l'interface dont nous discutons ici est la suivante: ajoutez un remplissage au bloc parent lorsque le bloc enfant est sélectionné, pour le rendre plus facile à sélectionner . Ce bon _feels_ dans le prototype de Kjell pour le bloc Colonnes. Il sera probablement très bienvenu dans d'autres blocs, tels que les blocs Section, ou dans de nombreux autres blocs où le contenu enfant est susceptible de remplir tout l'espace disponible à l'intérieur. Mais ce ne serait probablement pas si bien pour quelque chose comme le bloc Quote, qui n'utilise certes pas encore l'imbrication mais qui le fera probablement à l'avenir.

Ce serait donc bien de construire cette interface select-the-parent d'une manière qui soit _générique_ pour tous les blocs, _off par défaut_, mais quelque chose qu'un bloc pourrait choisir d'utiliser un accessoire.

Avez-vous des suggestions sur la meilleure façon d'aborder cela?

Tous les blocs qui contiennent des blocs imbriqués (colonnes, médias et texte pour le moment) rendent ce composant InnerBlocks qui rend la classe .editor-inner-blocks :
https://github.com/WordPress/gutenberg/blob/16a718a4bf359c53f0fb9c3626b08e2434a6fd7d/packages/editor/src/components/inner-blocks/index.js#L103
Cela pourrait aider à trouver une solution générale qui fonctionnerait avec tous les blocs imbriqués. Cependant, cela peut être délicat car .is-selected est appliqué dans l'un des éléments descendants.

Edit: Si cela ne fonctionne pas exclusivement avec CSS. On peut toujours trouver un moyen de mettre à jour l'état du parent pour y exposer les informations qu'un des blocs imbriqués est sélectionné. @jorgefilipecosta et @aduth pourraient avoir plus d'informations à ce sujet car ils ont passé beaucoup de temps avec des blocs imbriqués :)

Ce serait donc bien de construire cette interface select-the-parent d'une manière générique pour tous les blocs, désactivée par défaut, mais quelque chose qu'un bloc pourrait choisir d'utiliser un accessoire.

Quels blocs envisagez-vous pour cette approche qui n'utilisent pas l'imbrication? Cela m'a fait penser pourquoi n'utilisent-ils pas l'imbrication en premier lieu? Imaginez que nous convertissions la Galerie en un conteneur avec des blocs Image imbriqués. Nous obtiendrions ce comportement gratuitement mais aussi le tri en prime.

Quels blocs envisagez-vous pour cette approche qui n'utilisent pas l'imbrication?

La galerie est intéressante.

Honnêtement, je pense principalement à des blocs de mise en page plus avancés, tels que les blocs de mise en page Grid, ou les blocs Tabgroup, ou d'autres blocs de "création de page" similaires. Tout ce qui est spécifique au contenu ne devrait probablement pas utiliser cette interface.

Honnêtement, je pense principalement à des blocs de mise en page plus avancés, tels que les blocs de mise en page Grid, ou les blocs Tabgroup, ou d'autres blocs de "création de page" similaires. Tout ce qui est spécifique au contenu ne devrait probablement pas utiliser cette interface.

Je prévois qu'ils rentrent tous dans la catégorie des blocs de conteneurs, ce qui signifie qu'ils devraient utiliser InnerBlocks comme détail de mise en œuvre et devraient donc correspondre à cette catégorie. Nous pouvons toujours proposer une désactivation similaire à la façon dont nous le faisons pour d'autres fonctionnalités avec le groupe supports dans la définition de bloc.

Je prévois que tous s'inscrivent dans la catégorie des blocs de conteneurs, ce qui signifie qu'ils devraient utiliser InnerBlocks comme détail de mise en œuvre et devraient donc correspondre à cette catégorie

Mais le bloc Quote n'utiliserait-il pas également des blocs internes s'il recevait des fonctionnalités d'imbrication?

Mais le bloc Quote n'utiliserait-il pas également des blocs internes s'il recevait des fonctionnalités d'imbrication?

Oui, devis, liste, couverture - ces 3 ont été considérés comme transformés en blocs imbriqués dans le passé.

Une préoccupation (qui ne devrait pas bloquer l'expérimentation, mais qui vaut la peine d'être notée!) Est qu'il existe déjà des problèmes avec les blocs de colonnes en termes de taille et d'impact sur les outils du mode d'édition. Cette proposition rendra effectivement les colonnes encore plus étroites lors des interactions d'édition, ce qui pourrait faire resurgir ces problèmes d'étroitesse.

Il pousse également plus loin une parité d'édition / vue 1-à-1, ce qui peut ou non être un problème. Certes, je fais déjà quelque chose de similaire (rembourrage supplémentaire sur la sélection) sur un bloc personnalisé avec InnerBlocks, et cela fonctionne bien - mais cela signifie que la vue d'édition n'est pas tout à fait précise.

Ce serait donc bien de construire cette interface select-the-parent d'une manière générique pour tous les blocs, désactivée par défaut, mais quelque chose qu'un bloc pourrait choisir d'utiliser un accessoire.

Pouvoir opter pour quelque chose comme ça aurait été formidable lors de la construction du bloc Jetpack Form.

Il pousse également plus loin une parité d'édition / vue 1-à-1, ce qui peut ou non être un problème.

Je pense que c'est correct d'avoir des changements entre les états sélectionnés et non sélectionnés , surtout si cela améliore l'UX ... bien que cela puisse être discuté en ce qui concerne les blocs internes maintenant.

Aussi, que se passe-t-il quand j'ai des blocs imbriqués 3 profonds? L'option de remplissage s'étend-elle au deuxième niveau si le deuxième niveau est également un bloc parent?

@mapk

Aussi, que se passe-t-il quand j'ai des blocs imbriqués 3 profonds? L'option de remplissage s'étend-elle au deuxième niveau si le deuxième niveau est également un bloc parent?

Le remplissage de tous les niveaux d'imbrication étant affectés sonne comme s'il peut finir par provoquer des augmentations et des diminutions de taille importantes lors de la sélection de blocs profondément imbriqués, par exemple un paragraphe dans une citation dans une colonne dans une ligne d'une section. Idéalement, la sélection d'un bloc ne devrait pas modifier radicalement l'apparence de tous les autres blocs, donc le simple fait de changer l'espacement de son parent immédiat me semble suffisant.

Tant que vous pouvez sélectionner le parent immédiat, vous pourrez remonter la hiérarchie, car la sélection du parent rendra son parent facilement sélectionnable, et ainsi de suite. Le menu Bloquer la navigation pourrait être utilisé pour un accès plus rapide, et comme certains l'ont suggéré auparavant, il pourrait être transformé en une barre latérale épinglable afin de pouvoir y accéder rapidement. (Voir # 11408 et # 11688.)

Je suggérerais à tout moment que le changement de remplissage ne devrait affecter QUE le bloc sélectionné et les descendants directs.

Juste au cas où cela aurait un impact sur ce travail, puis-je rapidement faire surface que le travail que j'espère décrocher pour ajouter un alignement vertical au bloc de colonnes rend les colonnes _individuelles_ sélectionnables (auparavant, elles n'étaient pas sélectionnables)

https://github.com/WordPress/gutenberg/pull/13899

le travail que j'espère obtenir pour ajouter un alignement vertical au bloc de colonnes rend les colonnes _individuelles_ sélectionnables (auparavant, elles n'étaient pas sélectionnables)

Merci d'avoir noté cela ici. C'est une raison de plus pour arranger cette interaction le plus tôt possible.

Je voulais juste partager quelque chose dont j'ai discuté avec @jasmussen plus tôt dans la

Cela apparaît un peu dans certaines des maquettes ci -

Dans cet exemple, j'utilise une bordure sombre pour l'état focalisé. Si le bloc est un bloc parent ou enfant, j'ai inclus une bordure claire en pointillés (ainsi qu'un remplissage supplémentaire) autour des autres éléments associés. Cela aide les utilisateurs à visualiser clairement où ils se trouvent dans la hiérarchie des blocs, tout en leur donnant une idée claire de l'endroit où ils peuvent cliquer pour sélectionner d'autres blocs imbriqués.

@kjellr j'aime vraiment ça. Cela rend très clair la structure.

Cependant… je pense que nous nous heurterions à nouveau à un problème de contraste sur la ligne pointillée. Je ne peux pas le dire avec certitude, mais je soupçonne que l'introduction de la ligne pointillée signifie qu'elle doit suivre des critères d'accessibilité. Et je pense que rendre le contraste beaucoup plus élevé va probablement causer une lourdeur visuelle qui pourrait annuler les avantages ...

Je pense juste un peu à voix haute. J'aime vraiment l'apparence d'un utilisateur averti, mais je serais curieux d'entendre tous les commentaires car à mon goût, ce n'est pas suffisant :)

Sur mon écran, je n'ai même pas vu la ligne pointillée au début. Il semble pratiquement invisible si mon écran est légèrement incliné.

Il n'est pas nécessaire de réduire autant le contraste si cela le rendrait moins accessible. Tant que c'est un briquet _little_ et utilise un border-style je pense que cela fonctionnerait bien.

Désolé - j'aurais dû être plus clair dans mon commentaire initial: j'ai créé cette maquette en quelques minutes tout en parlant à Joen. Je pense que je viens de choisir des couleurs au hasard parmi certains gris qui étaient sur mon écran à l'époque. 😄 Les nuances exactes ne sont pas destinées à véhiculer une solution finale, juste une approche générale.

En réponse aux préoccupations concernant l'ajout de remplissage au bloc parent, ce qui rend les blocs internes incompatibles avec le frontend (# 14148 # 14169), j'ai travaillé une autre idée.

Cela nécessitera plus de développement, mais pourrait être une bonne option.

Fondamentalement, lorsque vous cliquez dans le bloc parent, il se développe (devient plus grand que les blocs normaux) pour fournir le remplissage nécessaire pour des sélections faciles des enfants / parents. Cela maintient le visuel des blocs internes cohérent avec le frontend.

Screencast

Prototype InVision

https://wp.invisionapp.com/share/EGQRWRC8MFT

AVANTAGES

1. Les blocs intérieurs restent de la bonne largeur.
2. Les blocs internes restent visuellement cohérents avec le frontend.
3. Un bloc sélectionné changeant de taille est un motif déjà utilisé.

LES INCONVÉNIENTS

1. L'extension de la sélection de bloc (largeur) au-delà des sélections de bloc normales est un nouveau modèle.
2. Je ne sais pas comment cela fonctionnera lorsque les blocs sont définis sur toute la largeur.

Fondamentalement, lorsque vous cliquez dans le bloc parent, il se développe (devient plus grand que les blocs normaux) pour fournir le remplissage nécessaire pour des sélections faciles des enfants / parents. Cela maintient le visuel des blocs internes cohérent avec le frontend.

Creusez ça. J'aimerais que la barre d'outils de bloc reste alignée avec la bordure gauche, mais c'est un détail de mise en œuvre.

Ce sera un défi sur les petits écrans quand il ne peut pas s'agrandir, mais cela ressemble aussi à quelque chose de résoluble.

Notamment, on a l'impression que cette approche peut évoluer vers n'importe quel bloc qui a des blocs internes, même le bloc Quote qui est un bloc de texte si basique que la sélection devrait être aussi libre que possible.

Vraiment, creusez vraiment votre travail, Kjell - non seulement cela pourrait fonctionner de manière invisible avec l'idée de Mark, mais cela aide à mettre en évidence la structure du document, lorsque vous en avez besoin, mais pas à interrompre le flux lorsque vous voulez juste écrire. Cela ressemble à une direction solide, et ce dont nous avons besoin, c'est d'un développeur fort sur ce prochain.

Sur une note d'implémentation - le parent en pointillé _pourrait_ théoriquement avoir la même couleur que le bloc sélectionné, mais en raison de son tiret, il apparaîtrait encore secondaire. Lors du survol du parent, le contour peut devenir solide, et nous pourrions même faire en sorte que _enfant_ (ce que vous avez sélectionné pendant que vous survolez) devienne en pointillé, pour aider à indiquer ce qui va se passer lorsque vous cliquez.

Sur une note d'implémentation - le parent en pointillé _pourrait_ théoriquement avoir la même couleur que le bloc sélectionné, mais en raison de son tiret, il apparaîtrait encore secondaire. Lors du survol du parent, le contour peut devenir solide, et nous pourrions même faire en sorte que _enfant_ (ce que vous avez sélectionné pendant que vous survolez) devienne en pointillé, pour aider à indiquer ce qui va se passer lorsque vous cliquez.

Oui! Je pense que cela pourrait parfaitement fonctionner aussi. Voyons où le n ° 14145 sort, puis découvrons un traitement à partir de là. 👍

J'ai également bricolé des bordures lorsque je faisais des colonnes uniques sélectionnables mais supprimées car hors de portée de mon PR. Je me sentais vraiment comme une amélioration UX. Aimer la façon dont cela se dirige!

Juste un avertissement: je tourne l'idée ci-dessus dans une question distincte et concise à explorer. Suivez ici:

https://github.com/WordPress/gutenberg/issues/14935

Si quelqu'un peut participer pour ajouter une classe has-child-selected aux blocs parents lorsque leur enfant est sélectionné, c'est le seul bloqueur pour commencer.

Un problème connexe que j'ai trouvé en testant le bloc de groupe nouvellement introduit:

Ce qui est déroutant pour le moment, c'est que lorsque vous insérez un bloc de groupe, ce que vous voyez réellement est un bloc de paragraphe:

Pouvons-nous au moins faire quelque chose comme:

ou ce que @mtias a suggéré dans notre discussion privée avec la réutilisation des éléments de la fonctionnalité de navigation par blocs:

_Ce ne sont en aucun cas des propositions de conception finales 😃_

@gziolo, ce problème doit être résolu par # 14241. Je suis d'accord avec vous, au fait, alors je serais ravi de l'expédier bientôt :)

@gziolo, ce problème doit être résolu par # 14241. Je suis d'accord avec vous, au fait, alors je serais ravi de l'expédier bientôt :)

Eh bien, je dirais partiellement. Lorsque vous insérez un paragraphe à l'aide de ce nouvel inserteur personnalisé, nous revenons à la case départ 🤷‍♂️

Je pense que # 14935 aidera ici aussi. Nous devrions également explorer certaines options dans la barre latérale pour avoir plus de moyens de nous assurer que le bloc actuellement sélectionné est imbriqué.

Ah oui. J'ai pensé à ressusciter les miettes de pain dans la barre latérale, comme nous l'avons fait ici:

https://github.com/WordPress/gutenberg/issues/13309#issuecomment -458452168

Simple et relativement élégant, et aiderait également ce problème (9628).

Lancer une itération sur certaines des idées ci-dessus:

Et si nous déplaçions les transformations / styles de bloc dans leur propre élément dédié, et transformions l'icône de bloc dans son propre panneau "Block Tree"?

Je pense que cela pourrait augmenter la visibilité des transformations / styles de bloc, tout en aidant les gens à naviguer un peu plus clairement vers d'autres blocs imbriqués. Voici une maquette d'un exemple plus compliqué:

(Les deux compositions utilisent également les contours / remplissage de # 14961)

Cela a l'air très intéressant Kjell! Il serait alors lié à la zone de navigation de bloc, créant une cohérence entre eux. Au fur et à mesure que l'on apprend à utiliser la navigation par blocs, le même apprentissage peut continuer à sélectionner des blocs imbriqués.

J'aime vraiment la maquette au niveau conceptuel, mais quelque chose dans l'exécution me semble un peu dense. Je ne sais pas si j'ai nécessairement une meilleure idée, mais je me demande s'il existe un moyen de rendre cela un peu plus léger?

Je sais que j'ai eu du mal à essayer de trouver un aperçu rapide de ma structure de bloc, donc ce concept est une excellente idée pour résoudre ce problème.

Ma préoccupation ici imite celle de @chrisvanpatten . Bien que cela soit bien pensé, cela fait beaucoup.

1. Sur certains blocs dans certains contextes, il existe différentes manières d'afficher les listes déroulantes.

Je pense que l'ajout d'un autre chevron au mélange (bien qu'il soit gris et orienté vers la droite) pourrait ajouter plus de difficulté à analyser.

1. L'autre problème est que la barre d'outils s'allonge. Ce n'est peut-être pas un gros problème, mais cela peut l'être lorsque nous incluons des étiquettes pour les icônes https://github.com/WordPress/gutenberg/issues/10524 et https://github.com/WordPress/gutenberg/issues/ 15311.

Juste quelques réflexions à méditer tout en explorant cela. C'est peut-être l'approche la plus simple qui communique ce qui se passe.

Je me demande s'il existe un moyen de rendre cela un peu plus léger?

Ouais, je pense que cela a quelque chose à voir avec le manque de hiérarchie là-bas. Le premier élément de la barre d'outils devrait ressembler un peu plus à l'élément de mise à la terre, et les autres devraient ressembler à des options secondaires pour le bloc. Une sorte de séparation est nécessaire. Ce n'est pas la bonne solution, mais juste pour le plaisir de la conversation, je pense que cela aide un peu:

Sur certains blocs dans certains contextes, il existe différentes manières d'afficher les listes déroulantes. Je pense que l'ajout d'un autre chevron au mélange (bien qu'il soit gris et orienté vers la droite) pourrait ajouter plus de difficulté à analyser.

CA se peut. Il y a probablement une autre façon de représenter cela à laquelle je ne pense pas non plus. Honnêtement, cela pourrait même être une icône "arbre de bloc" supplémentaire plus simple dans la barre d'outils, ajoutée automatiquement pour tout élément parent ou enfant:

L'autre problème est que la barre d'outils s'allonge. Ce n'est peut-être pas un gros problème, mais cela peut l'être lorsque nous incluons des étiquettes pour les icônes # 10524 et # 15311.

D'accord. Que ce soit la direction ou non, nous devrons de toute façon trouver une solution pour les barres d'outils extra-longues. Je pense que des efforts comme https://github.com/WordPress/gutenberg/pull/16557 aident un peu à cela, tout comme des repensés plus complets de la hiérarchie de la barre d'outils comme https://github.com/WordPress/gutenberg/issues/ 15096.

Une chose qui me frappe à propos de l'idée d'un arbre de blocs comme bouton de barre d'outils est qu'il est en quelque sorte unique en tant qu'élément de barre d'outils de bloc qui ne fait pas référence à quoi que ce soit d'intrinsèque au sujet du bloc lui-même, et plutôt à la façon dont le bloc se rapporte à le reste du document.

C'est plus une rêverie qu'autre chose, mais pour utiliser une analogie avec les applications graphiques, ce type d'interface utilisateur de «superposition» et de «regroupement» n'existerait généralement (je suis sûr qu'il y a des exemples qui me prouvent que j'ai tort) n'exister qu'au niveau _document_ plutôt que d'être accessible au niveau du bloc.

Je sais qu'il y a divers problèmes d'accessibilité autour de «l'écart» entre le bloc et les outils au niveau du document, et l'avoir au niveau du bloc peut faciliter la navigation.

C'est plus une rêverie qu'autre chose… quelque chose à propos de cet outil semble sensiblement différent des autres outils disponibles dans la barre d'outils en termes de relation entre le bloc et d'autres contextes.

C'est plus une rêverie qu'autre chose… quelque chose à propos de cet outil semble sensiblement différent des autres outils disponibles dans la barre d'outils en termes de relation entre le bloc et d'autres contextes.

Ouais, j'ai le même sentiment.

Nous avons ce contrôle dans la barre d'outils supérieure pour le moment, qui semble trop éloigné du bloc lui-même. Peut-être que la barre latérale est en fait le meilleur endroit pour cela? Le contrôle semble presque devoir être associé au bloc, mais comme sa propre barre d'outils séparée, mais nous ne voulons certainement pas en ajouter une autre. 😄

Nous avons ce contrôle dans la barre d'outils supérieure pour le moment, qui semble trop éloigné du bloc lui-même.

J'ajouterais également que cela n'est vrai que dans les paramètres par défaut de Gutenberg. Si quelqu'un devait sélectionner l'option Barre d'outils supérieure pour déplacer toutes les barres d'outils de bloc vers la barre d'outils supérieure, ce n'est certainement pas le cas. Mais cela étant dit, je doute que la majorité des utilisateurs modifient ce paramètre.

Sur une autre note, j'aimerais vraiment voir comment les gens réagiraient au paramètre de la barre d'outils supérieure étant le paramètre par défaut dans Gutenberg. Il s'alignerait mieux avec l'éditeur Classic, offrant plus de familiarité aux nouveaux utilisateurs de Gutenberg.

Ce paramètre de barre d'outils a été beaucoup exploré et la meilleure valeur par défaut a été établie après de nombreux tests. Vous pouvez en savoir plus sur les explorations ici: https://github.com/WordPress/gutenberg/issues/2983.

Je doute que la majorité des utilisateurs modifient ce paramètre.

Il s'avère que la position d'une barre d'outils est un paramètre incroyablement personnel. Au cours de la première phase des tests, il s'est avéré que ceux qui commençaient à utiliser WordPress étaient préférés par le bloc, ceux qui étaient expérimentés en haut. La barre d'outils a par défaut aux deux endroits et c'est ce que nous avons maintenant sont les meilleures options. De plus, c'est probablement pourquoi il se sent plus aligné sur l'éditeur classique. Je recommanderais personnellement de ne pas modifier la valeur par défaut.

@jasmussen Devrions-nous fermer cela en faveur de # 17088

Oui, je pense que nous pouvons. Ce ticket a exploré de manière divergente, tandis que l'autre affine désormais certaines des idées. Ce billet sera toujours trouvable si vous suivez la référence sur le nouveau billet Merci Riad.