Gutenberg: Mejorar las herramientas para seleccionar bloques secundarios / padres

Me gusta la idea de las migas de pan. (En realidad, sugerí algo bastante similar en el n. ° 6459 en abril). ¿Qué pasaría con las rutas de navegación cuando la barra de herramientas unificada está habilitada?

También creo que la idea del clic de destino también es buena y ya se usa en dispositivos móviles, por lo que agrega consistencia. Sin embargo, no estoy tan seguro de la idea de traspaso; Imagino que eso podría causar confusión debido a diferentes comportamientos entre bloques.

Me gustan las migas de pan pero también me gusta la barra de herramientas unificada. ¿Podemos encontrar otra posición para la ruta de navegación :)

Además, personalmente no me gustan los bordes alrededor del bloque principal. Pero si los conservamos, ¿cómo tratamos la selección múltiple :). ¿Deberíamos mostrar bordes alrededor del padre de bloques multiseleccionados?

Me gusta la opción de hacer clic. Esto requerirá un poco de trabajo adicional en el bloque 'traspaso' (por lo que cada "columna" individual no se considera una capa para hacer clic, por ejemplo) pero creo que tiene mucho sentido.

¿Qué pasaría con las rutas de navegación cuando la barra de herramientas unificada está habilitada?
Me gustan las migas de pan pero también me gusta la barra de herramientas unificada. ¿Podemos encontrar otra posición para la ruta de navegación :)

Buena pregunta. Maqueta rápida y sucia:

Sí, veo el desafío del icono duplicado del conmutador. Creo que es bueno seguir pensando en esto. También observe cómo este diseño omite el esquema del documento, que está bloqueado en # 4287.

Además, personalmente no me gustan los bordes alrededor del bloque principal. Pero si los conservamos, ¿cómo tratamos la selección múltiple :). ¿Deberíamos mostrar bordes alrededor del padre de bloques multiseleccionados?

Creo que es importante mostrarlos como una indicación de que los bloques internos son parte del grupo principal. Ellos anclan los bloques internos.

En este momento, así es como funciona la selección múltiple:

Y esto es lo que sucede cuando simplemente selecciona dos bloques secundarios:

En otras palabras, en master ya tenemos el borde principal, _y_ lo ocultamos cuando seleccionamos varios bloques secundarios. De hecho, creo que mostrar el borde principal siempre, incluso en la selección múltiple, tiene sentido _cuando solo selecciona bloques secundarios_. Pero quizás deberíamos hacer que la selección múltiple sea diferente cuando el bloque _parent_ está multiseleccionado. Entonces, en lugar de resaltar cada bloque secundario con efectos de capa aditivos, _sólo_ resaltamos el bloque principal. Funcionaría eso?

Me gusta la opción de hacer clic. Esto requerirá un poco de trabajo adicional en el bloque 'traspaso' (por lo que cada "columna" individual no se considera una capa para hacer clic, por ejemplo) pero creo que tiene mucho sentido.

Sí, en este momento el bloque secundario _column_ presenta algunos desafíos de IU. Por ejemplo, no puede insertar un bloque antes, entonces, ¿por qué puede seleccionarlo? Sin embargo, es un desafío técnico tremendamente difícil y entiendo los desafíos que implica. Así que no estoy sugiriendo que esto sea fácil.

Mientras trabajaba en https://github.com/WordPress/gutenberg/pull/9653 , me di cuenta de que la navegación de teclas de flecha que ya tenemos presente para navegar por la jerarquía (use la tecla de flecha hacia arriba cuando se selecciona una columna para seleccionar el padre , es decir, el bloque de columnas) está funcionando muy bien. Tan bien, de hecho, que quizás simplemente mostrar esta función como un botón "arriba", similar a "ir a la carpeta principal" en el explorador de archivos de Windows, podría ser suficiente en lugar de una ruta de navegación completa.

Así es como podría verse eso. Barra de herramientas superior:

Barra de herramientas de bloque:

CC: @youknowriad

Algunos pensamientos

Migas de pan

Me gusta la solución de ruta de navegación, pero adolece de ambigüedad, una interfaz de solo icono puede ser problemática y puedo verme moviéndome sobre los iconos para ver qué son, o confundiendo las rutas de navegación para una barra de herramientas de opciones en lugar de rutas de navegación.

Entonces, tal vez la barra de herramientas superior no sea el mejor lugar para mostrarlo, y tal vez algunas señales de las rutas de navegación en otros lugares ayudarían. Por ejemplo, ¿la barra de herramientas de jerarquía en PHPStorm que muestra el archivo -> clase -> método / función en la que se encuentra actualmente, o la barra de herramientas de la carpeta en MacOS Finder y Windows Explorer?

Hacer clic a través

Hacer clic sería una interfaz de usuario oculta, puedo ver muchos malentendidos y confusión ya que la gente espera seleccionar un bloque de imagen solo para encontrar que el bloque de la columna que lo contiene está seleccionado. Por lo general, hacer clic en la interfaz de usuario en el software de Adobe es confuso, ya que presenta modos, y es difícil saber dónde se encuentra y cómo salir, especialmente si hay anidación. Por ejemplo, si hace doble clic para ingresar a un bloque secundario, ¿cómo regresa al bloque principal y cómo indica la interfaz de usuario que está dentro de un bloque?

Hay mucha investigación y pautas sobre los modos, y algo no debe considerarse bueno porque está presente en Illustrator o Photoshop, se necesita mucho más trabajo que solo hacer clic antes de que se convierta en una solución adecuada.

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

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

Esto también ignora todos los factores de accesibilidad con los que esto se mete.

El botón Arriba

La idea del botón arriba es buena. Mi preocupación sería que implica que si lo presionas aparecerá un botón de abajo y el bloque se moverá hacia arriba, es ambiguo y sufre los mismos problemas que el bloque de migas de pan.

El patrón de bloques reutilizables

En este momento, los bloques reutilizables ya tienen un patrón de interfaz de usuario que agrega cromo a la interfaz del bloque que no es visible en la interfaz. ¿Las columnas no podrían hacer lo mismo?

O una maqueta súper basura de lo que quiero decir

Por lo tanto, el cromo del bloque de columnas sería lo que se usaría para seleccionarlo, y proporciona algo que es visual para apuntar con el mouse.

Un patrón de UX potencial que podríamos usar aquí y que encajaría con nuestro modelo de barra de herramientas es el botón transversal de carpeta de OS X: https://cld.wthms.co/avtQLO

Me gustaría señalar que creo que los usuarios esperarán poder seleccionar bloques hijo / padre visualmente haciendo clic y seleccionando, pero obviamente hay mucha complejidad para hacerlo bien. El patrón transversal anterior podría ser un buen primer paso y podríamos profundizar en el desarrollo de una solución más elegante en la fase 2.

Adoro ese concepto Alexis, especialmente para los bloques más complejos, como mencionas. Me encanta tanto que inmediatamente corrí con él y remezclé algunas de las maquetas para ilustrar tu idea.

Sin selección:

Bloque seleccionado:

Bloque anidado dentro de seleccionado:

Se abre la ventana emergente del botón transversal de carpeta:

☝️ Estoy un poco enamorado de ese concepto, parece que fusiona todas las ideas y comentarios compartidos en este hilo, lo que lo convierte en una línea de base _sólida_ para iterar. ¡Muchas gracias por traer esa nueva perspectiva!

Me encanta el menú desplegable con el árbol visual, una parte de mí piensa que ver el documento completo en este formato también sería útil e incluso proporcionaría una forma útil de reordenar las cosas.

Sin embargo, pensándolo bien, se me recordó que ya tenemos un mecanismo de selección como este y un esquema de documento en el panel de información:

Esto podría mejorarse con el estilo de su maqueta y servir como un significante de selección adicional. Por el momento solo muestra títulos, pero una versión con un árbol de bloques completo y un indicador de selección sería muy útil

Mi único reparo es con el icono de la barra de herramientas. es otro icono misterioso con una flecha, y es un botón que no está en Finder en MacOS de forma predeterminada a menos que personalice la barra de herramientas. Para aquellos de nosotros que somos ciegos a los íconos y no podemos distinguir entre íconos fácilmente, es problemático

Con la etiqueta de texto es más claro, pero sin ella la mayoría no sabría lo que hizo sin hacer clic en ella:

Se ve bien :) ¿Podemos intentar simplificar un poco el icono para mejorar la legibilidad? ¿Quizás 3 líneas con un poco más de espacio en lugar de 4?

Con la etiqueta de texto es más claro, pero sin ella la mayoría no sabría lo que hizo sin hacer clic en ella.

También habrá una información sobre herramientas.

En el comentario de re: @tomjn , también creo que valdría la pena explorar si esto pudiera integrarse en el árbol general del documento en lugar de crear un lugar separado. El desafío es mantener la simplicidad y la capacidad de escaneo del árbol mientras se acomodan muchos más niveles de cosas. Pero tal vez eso pueda parecerse más al panel de capas en Sketch o Photoshop (¡en funcionalidad, no en diseño!), Donde es la única fuente de verdad para toda la estructura de la página. Desafiante para hacerlo bien, pero ¿quizás vale la pena explorarlo?

Nuevamente, es probable que esto sea algo en lo que repetimos, entonces, ¿cuál es el MVP más útil que puede convertirse en algo más sofisticado?

También habrá una información sobre herramientas.

No creo que sea suficiente, pero creo que esta es una discusión separada y una solicitud de función, abriré un nuevo ticket

¿Podemos intentar simplificar un poco el icono para mejorar la legibilidad? ¿Quizás 3 líneas con un poco más de espacio en lugar de 4?

Me gusta eso:

Sin embargo, pensándolo bien, se me recordó que ya tenemos un mecanismo de selección como este y un esquema de documento en el panel de información:

También creo que valdría la pena explorar si esto podría integrarse en el árbol general del documento en lugar de crear un lugar separado.

Creo que eso podría funcionar. Anteriormente sugerí que el elemento podría reescribirse como un complemento para que se muestre a la derecha (ver # 4287). Pero soy fanático de reutilizar esto para el árbol de documentos.

Con respecto a una etiqueta, me gustan las etiquetas, pero la opción de acoplar la barra de herramientas del bloque en la parte superior debe considerarse desde ese punto de vista.

Esta discusión me recuerda al # 9053 (CC: @westonruter). Creo que le puede gustar la propuesta de Alexis como se muestra en https://github.com/WordPress/gutenberg/issues/9628#issuecomment -429012989.

Es genial ver que esto sigue adelante y gracias por el concepto @alexislloyd. @jasmussen Me gustan mucho estos

Entonces, ¿cuál es el MVP más útil que puede convertirse en algo más sofisticado?

Yo diría que construye esto como un control transversal más simple y mira más adelante para ver si tiene sentido combinarlo con el cuadro de contenido del documento según la selección.

Según la discusión en # 10767, reabrir esto para iterar.

Vea también las ideas adicionales que se sugieren en el n. ° 11159.

Una idea adicional para facilitar el trabajo con bloques complejos es recordar que _el bloque no seleccionado es una vista previa_, y el _ bloque seleccionado puede mostrar controles de edición adicionales_.

Podemos aprovechar esa idea para facilitar la selección de los elementos de un bloque de columnas. Por ejemplo, cuando se selecciona un bloque de columnas, o cualquier elemento secundario del mismo, el relleno del contenedor se anima para dejar espacio para seleccionar elementos secundarios. Esto también haría accesible la interfaz de usuario lateral. Querríamos mostrar un borde alrededor del bloque principal, el que tiene relleno expandido, por ejemplo, una línea discontinua.

Esto parece que sería relativamente trivial de implementar, si restauramos la clase .is-selected en el bloque de nivel superior incluso cuando se selecciona un niño. Hicimos esto usando un accesorio hasSelectedInnerBlocks hace un tiempo.

Esto es lo que vemos al pasar el cursor sobre una celda en un bloque de columnas:

Colocando el cursor sobre una celda en el bloque Medios y texto.

Uno ve el bloque interior y el bloque exterior.
Como columna -> párrafo. Columna -> YouTube. Medios y texto -> YouTube

Sería bueno hacer que se pueda hacer clic en la información de migas de pan (bloques internos y externos) en la información de desplazamiento. Haga clic en Columna para seleccionar el padre o haga clic en Párrafo para seleccionar el hijo.

Al probar esto hace un momento, una cosa que noté es que la forma más sencilla de seleccionar un bloque de columna principal es utilizar el área de impacto invisible adicional que ofrecemos a la derecha / izquierda del bloque principal:

Esta área de impacto adicional no está disponible en la parte superior e inferior del bloque, lo que hace que sea mucho más difícil seleccionar de esa manera.

Una idea adicional para facilitar el trabajo con bloques complejos es recordar que el bloque no seleccionado es una vista previa y el bloque seleccionado puede mostrar controles de edición adicionales.

Podemos aprovechar esa idea para facilitar la selección de los elementos de un bloque de columnas. Por ejemplo, cuando se selecciona un bloque de columnas, o cualquier elemento secundario del mismo, el relleno del contenedor se anima para dejar espacio para seleccionar elementos secundarios. Esto también haría accesible la interfaz de usuario lateral. Querríamos mostrar un borde alrededor del bloque principal, el que tiene relleno expandido, por ejemplo, una línea discontinua.

No estoy 100% seguro de si esto es lo que @jasmussen sugiere arriba, pero agregar algo de relleno + un indicador visual del bloque principal en el modo de edición podría ser de gran ayuda aquí. De esa manera, hay una indicación clara de dónde debe hacer clic si desea seleccionar el padre:

Cuando alguien sale del bloque, ese relleno adicional puede desaparecer para mostrar una representación más precisa del bloque.

Esta área de impacto adicional no está disponible en la parte superior e inferior del bloque, lo que hace que sea mucho más difícil seleccionar de esa manera.

Podría JURAR que hubo un boleto en torno a este problema, que también está relacionado con cómo funciona el insertador de hermanos. No puedo encontrarlo en este momento, pero creo que este problema debería solucionarse. @aduth suena alguna campana, podría jurar que estabas en los comentarios.

No estoy 100% seguro de si esto es lo que @jasmussen sugiere arriba, pero agregar algo de relleno + un indicador visual del bloque principal en el modo de edición podría ser de gran ayuda aquí. De esa manera, hay una indicación clara de dónde debe hacer clic si desea seleccionar el padre:

Eso es más o menos exactamente lo que quise decir, solo que visualizado de manera más hermosa de lo que podría.

Aquí hay un boceto de crayón adicional para ilustrar lo que quiero decir. Bloque de columnas:

Esencialmente lo que tienes, Kjell, quizás con la línea discontinua un poco más oscura. Además, dependiendo de cómo vaya el desarrollo del bloque de columnas, recuerde que también hay bloques _column_. Es decir, la jerarquía actualmente es _Columnas → Columna → Imagen_. Estamos usando una feroz hechicería CSS para hacer que el segundo nivel sea más o menos invisible, pero en caso de que desee seleccionarlo en el futuro para, digamos, aplicarle una clase CSS o cualquier otra opción que podamos necesitar para columnas individuales, eso es vale la pena considerarlo.

Bloque de presentación de diapositivas:

Para ser claros: no se planea ningún bloque de presentación de diapositivas. Esto es puramente garabatos para ilustrar un punto en el que los modos de vista previa y edición de un bloque pueden ser _muy_ diferentes. Es tan fácil y sorprendentemente no disruptivo cambiar entre los dos modos simplemente seleccionando y deseleccionando los bloques, que deberíamos permitirnos apoyarnos y ser creativos sobre las oportunidades.

En el caso de un bloque de presentación de diapositivas, casi por definición, el contenido será invisible fuera de la pantalla / bloque. Pero no tiene que ser así cuando lo estás editando. Simplemente seleccione el bloque para ver miniaturas con subtítulos editables. Luego, anule la selección del bloque para obtener una vista previa del resultado.

Podría JURAR que hubo un boleto en torno a este problema, que también está relacionado con cómo funciona el insertador de hermanos. No puedo encontrarlo en este momento, pero creo que este problema debería solucionarse. @aduth suena alguna campana, podría jurar que estabas en los comentarios.

Creo que lo más cercano podría ser uno de # 8883, # 8881, # 5180.

Si bien el árbol de documentos es útil, todavía requiere que cambie el enfoque de lo que estoy tratando de manipular. Realmente me gustaría una mejor manera de hacer clic en los bloques reales y los bloques anidados directamente. Creo que vale la pena explorar más el método de clic descrito anteriormente por @jasmussen .

Este es el problema que experimento comúnmente:

Como usuario, lucharé con esto durante al menos un minuto antes de encontrar otra solución ubicada en otro lugar de la pantalla. 😉

* _Cuando agregué este comentario, aparecieron muchos otros comentarios. Puede que no sea tan relevante ahora, pero lo guardo aquí para documentar la lucha.

pero agregar algo de relleno + un indicador visual del bloque principal en el modo de edición podría ser de gran ayuda aquí. De esa manera, hay una indicación clara de dónde debe hacer clic si desea seleccionar el padre:

Mi preocupación con esta solución es cómo funciona el relleno en relación con los bloques circundantes:

1. ¿Se refleja el relleno en el bloque principal en el front-end? ¿O simplemente más relleno en el editor?

2. ¿El relleno se agrega dinámicamente cuando se selecciona el bloque, así?

1. ¿O tal vez el padre acolchado aparece sobre los bloques circundantes, así?

Solo trato de profundizar en este concepto. Me encantaría tener algunos pensamientos al respecto.

Gracias @aduth , me hiciste encontrar al menos un boleto que vaya en la dirección correcta. El GIF en # 9229 explica el problema: el área amarilla en ese GIF está "reservada" para el insertador hermano. Eso es lo que le impide seleccionar el bloque haciendo clic en el relleno por encima o por debajo del bloque. Esa es la respuesta al comentario de @kjellr :

Esta área de impacto adicional no está disponible en la parte superior e inferior del bloque, lo que hace que sea mucho más difícil seleccionar de esa manera.

Para aclarar aún más, esa área amarilla está ahí solo para hacer VISIBLE el botón de inserción del hermano. Entonces, todo lo que necesitamos interceptar, en realidad, es la acción _hover_. Sería bueno si un clic aún pudiera propagarse a través de esa barra amarilla y le permitiera seleccionar el bloque a continuación.

Si bien el árbol de documentos es útil, todavía requiere que cambie el enfoque de lo que estoy tratando de manipular. Realmente me gustaría una mejor manera de hacer clic en los bloques reales y los bloques anidados directamente. Creo que vale la pena explorar más el método de clic descrito anteriormente por @jasmussen .

De hecho, puede probar esto ahora mismo, incluso si la implementación actual está un poco a medias.

• Ejecute Gutenberg, cualquier versión.
• Inserta un bloque de columnas con contenido.
• Cambie el tamaño de la ventana por debajo del punto de interrupción de 600px, luego seleccione.

Esto está implementado para dispositivos móviles, en otras palabras, para permitirle seleccionar el bloque principal más fácilmente.

GIF:

El problema con la implementación en este momento es que el "estado" se restablece una vez que se ha profundizado hasta el nivel más profundo. Entonces, es Columnas> Columna> Párrafo, Columnas> Columna> Párrafo, incluso si solo está seleccionando el mismo párrafo dos veces. La solución obvia a ese problema que debe intentar es hacer que una vez que haya "profundizado" hasta el nivel deseado, _permanezca_ en ese nivel hasta que vuelva a deseleccionar el bloque. Es decir, Columnas> Columna> Párrafo, Párrafo, Párrafo, deseleccionar, rebobinar, etc.

También creo que para _algunos_ bloques, este método de hacer clic será de vital importancia. Especialmente cuando comenzamos a buscar plantillas de página que pueden incluir todo tipo de contenido anidado.

La inspiración de cómo el clic puede funcionar cuando es increíble, también se puede probar en Keynote. Inserta algunas formas y puedes hacer clic en ellas directamente. Tan pronto como usted _agrupa_ dos formas, se convierten en una nueva forma que es fácil de mover. Pero para editar el contenido del grupo, debe hacer doble clic.

Para responder a sus buenas preguntas en https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456637172:

¿Se refleja el relleno en el bloque principal en el front-end? ¿O simplemente más relleno en el editor?

No, este relleno solo está en el editor y solo cuando el _bloque está seleccionado_. Esto se basa en el principio del bloque es la interfaz , que establece que en el editor:

• un bloque no seleccionado es una vista previa. Debe verse tanto como sea posible en la interfaz
• un bloque seleccionado es esencialmente "modo de edición de bloque", y el bloque puede generar controles adicionales e incluso verse totalmente diferente, en este estado.

Esto es lo que intenté resaltar con el ejemplo del bloque de presentación de diapositivas anterior: cuando el bloque de presentación de diapositivas no está seleccionado, es una presentación de diapositivas. Cuando se selecciona, está en _modo de edición de presentación de diapositivas_ y ve una cuadrícula de miniaturas de cada diapositiva, por lo que puede editar fácilmente los subtítulos, reorganizar, etc.

¿El relleno se agrega dinámicamente cuando se selecciona el bloque, así?

Si, más o menos.

Creo que valdría la pena hacer un prototipo para explicarlo mejor y sentirlo.

En última instancia, esta función probablemente debería ser un accesorio en el bloque en sí, algo que un bloque puede optar por usar. Una cita en bloque con párrafos anidados, por ejemplo, probablemente no debería usar esta interfaz, pero al editar columnas, podría ser algo perfecto.

Aquí hay un prototipo rápido de codepen: https://codepen.io/joen/pen/exmMQv?editors=1100

Es algo estático, pero es de esperar que transmita el punto.

Aquí hay un prototipo rápido de codepen: https://codepen.io/joen/pen/exmMQv?editors=1100

Es algo estático, pero es de esperar que transmita el punto.

Eso realmente ayuda a transmitir el mensaje. Hice una pequeña edición, para que podamos ver cómo pueden aparecer esos bordes punteados al hacer clic:

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

¡Esto es perfecto, gracias Kjell! Eso es exactamente lo que quiero decir. Creo que probablemente querremos ajustar algunos de los aspectos en la implementación y abordar cómo se ve cuando el padre inmediato (columna singular) es el que recibe relleno. ¡Pero esto es genial! Creo que puede funcionar.

Realmente me gusta esto.
¿Deberíamos pasar a crear un PR para probar con más bloques y contenido?
¿Necesitamos identificar qué bloques afectará esto?

Yo también lo disfruto.

Probablemente podamos hacer un prototipo de esto en el bloque Columns por ahora, pero para que aterrice probablemente necesitemos que este _método_ sea genérico, por lo que otros bloques (como usted dice) pueden usar esto, pero también un accesorio para que un bloque pueda optar por participar en esto. Probablemente será perjudicial para el bloque Quote tener esto, una vez que reciba bloques anidados.

@gziolo ¿ algún pensamiento? En particular, en el enfoque garabateado por Kjell en https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456811415

@gziolo ¿ algún pensamiento? Notablemente en el enfoque garabateado por Kjell en el # 9628 (comentario)

Se ve muy bien. Finalmente, permitiría seleccionar fácilmente el bloque principal cuando sea necesario. Mi única pregunta es cómo se sentiría acerca de hacer el ancho de la columna más cercano al tamaño original a costa de hacer que otras columnas sean más estrechas. Por el momento, todas las columnas se reducen cuando se selecciona una de ellas, lo que podría ser una experiencia subóptima al tener más de 3 columnas. @jasmussen ¿Tiene alguna otra pregunta, debería responder?

Mi única pregunta es cómo se sentiría acerca de hacer el ancho de la columna más cercano al tamaño original a costa de hacer que otras columnas sean más estrechas.

Tiendo a estar de acuerdo en que esto es algo que deberíamos afinar y equilibrar, probablemente en la implementación. También podemos considerar expandir el ancho / alto del padre, para no reducir el tamaño del niño, aunque probablemente eso sea técnicamente más desafiante.

¿Tiene alguna otra pregunta que deba responder?

Básicamente, la interfaz que estamos discutiendo aquí es: agregue relleno al bloque principal cuando se selecciona el bloque secundario, para que sea más fácil de seleccionar . Esto se siente bien en el prototipo de Kjell para el bloque Columns. Probablemente será muy bienvenido en otros bloques, como los bloques de sección, o muchos otros bloques donde es probable que el contenido secundario ocupe todo el espacio disponible en el interior. Pero probablemente no sería tan bueno para algo como el bloque Quote, que ciertamente no usa el anidamiento todavía, pero es probable que lo haga en el futuro.

Por lo tanto, sería bueno construir esta interfaz de selección de padres de una manera que fuera _generic_ para todos los bloques, _off por defecto_, pero algo que un bloque podría optar por usar un accesorio.

¿Tiene alguna sugerencia sobre la mejor manera de abordar eso?

Todos los bloques que contienen bloques anidados (Columnas, Medios y Texto en este momento) representan este componente InnerBlocks que representa la clase .editor-inner-blocks :
https://github.com/WordPress/gutenberg/blob/16a718a4bf359c53f0fb9c3626b08e2434a6fd7d/packages/editor/src/components/inner-blocks/index.js#L103
Esto podría ayudar a encontrar una solución general que funcione con todos los bloques anidados. Sin embargo, puede ser complicado ya que .is-selected se aplica en uno de los elementos descendientes.

Edit: Si no funciona con CSS exclusivamente. Siempre podemos encontrar una manera de actualizar el estado del padre para exponer allí la información de que uno de los bloques anidados está seleccionado. @jorgefilipecosta y @aduth podrían tener más información sobre eso, ya que pasaron mucho tiempo con bloques anidados :)

Por lo tanto, sería bueno construir esta interfaz de seleccionar el padre de una manera que fuera genérica para todos los bloques, desactivada por defecto, pero algo que un bloque podría optar por usar un accesorio.

¿Qué bloques considera para este enfoque que no utilizan el anidamiento? Esto me hizo pensar por qué no están usando el anidamiento en primer lugar. Imagina que convertimos la Galería en un contenedor con bloques de imágenes anidados. Obtendríamos este comportamiento de forma gratuita pero también clasificando como un bono.

¿Qué bloques considera para este enfoque que no utilizan el anidamiento?

La galería es interesante.

Honestamente, estoy pensando principalmente en bloques de diseño más avanzados, como bloques de diseño de cuadrícula, bloques de grupos de tabulaciones u otros bloques similares de "construcción de páginas". Cualquier contenido específico probablemente no debería usar esta interfaz.

Honestamente, estoy pensando principalmente en bloques de diseño más avanzados, como bloques de diseño de cuadrícula, bloques de grupos de tabulaciones u otros bloques similares de "construcción de páginas". Cualquier contenido específico probablemente no debería usar esta interfaz.

Anticipo que todos encajan en la categoría de bloques de contenedores, lo que significa que deberían usar InnerBlocks como detalle de implementación, por lo que deberían encajar en esta categoría. Todavía podemos ofrecer la opción de exclusión de forma similar a como lo hacemos para otras funciones con el grupo supports en la definición de bloque.

Anticipo que todos encajan en la categoría de bloques de contenedores, lo que significa que deberían usar InnerBlocks como detalle de implementación, por lo que deberían encajar en esta categoría

¿Pero el bloque Quote no usaría también bloques internos si / cuando recibiera funciones de anidación?

¿Pero el bloque Quote no usaría también bloques internos si / cuando recibiera funciones de anidación?

Sí, cotización, lista, portada: esos 3 se consideraban transformados en bloques anidados en el pasado.

Una preocupación (que no debería bloquear la experimentación, pero vale la pena señalarla) es que ya existen algunos problemas con los bloques de columnas en términos de cuán estrechos pueden ser y cómo eso afecta las herramientas del modo de edición. Esta propuesta hará que las columnas sean aún más estrechas durante las interacciones de edición, lo que podría resurgir esos problemas de estrechez.

También avanza más allá de una paridad de edición / visualización de 1 a 1, lo que puede ser una preocupación o no. Es cierto que ya hago algo similar a esto (relleno adicional en la selección) en un bloque personalizado con InnerBlocks, y funciona bien, pero significa que la vista de edición no es del todo precisa.

Por lo tanto, sería bueno construir esta interfaz de seleccionar el padre de una manera que fuera genérica para todos los bloques, desactivada por defecto, pero algo que un bloque podría optar por usar un accesorio.

Ser capaz de optar por algo como esto hubiera sido genial al construir el bloque Jetpack Form.

También avanza más allá de una paridad de edición / visualización de 1 a 1, lo que puede ser una preocupación o no.

Creo que está bien tener algunos cambios entre los estados seleccionados y no seleccionados , especialmente si está mejorando la UX ... aunque esto se puede argumentar ahora con respecto a los bloques internos.

Además, ¿qué sucede cuando tengo bloques anidados a 3 de profundidad? ¿La opción de relleno se extiende al segundo nivel si el segundo nivel también es un bloque principal?

@mapk

Además, ¿qué sucede cuando tengo bloques anidados a 3 de profundidad? ¿La opción de relleno se extiende al segundo nivel si el segundo nivel también es un bloque principal?

Parece que el relleno de todos los niveles de anidamientos afectados puede acabar provocando grandes aumentos y disminuciones de tamaño al seleccionar bloques profundamente anidados, por ejemplo, un párrafo en una cita en una columna en una fila en una sección. Idealmente, seleccionar un bloque no debería alterar drásticamente la apariencia de todos los demás bloques, por lo que simplemente cambiar el espaciado de su padre inmediato me parece suficiente.

Siempre que pueda seleccionar el padre inmediato, podrá avanzar en la jerarquía, ya que seleccionar el padre hará que su padre sea fácilmente seleccionable, y así sucesivamente. El menú Block Navigation podría usarse para un acceso más rápido y, como algunos han sugerido antes, podría convertirse en una barra lateral que se puede fijar para que se pueda acceder rápidamente. (Vea # 11408 y # 11688.)

Sugeriría en cualquier momento que el cambio de relleno debería afectar SOLAMENTE al bloque seleccionado y a los descendientes directos.

En caso de que esto afecte este trabajo, por favor, ¿puedo señalar rápidamente que el trabajo que espero aterrizar para agregar Alineación Vertical al Bloque de Columnas hace que las Columnas _individuales_ sean seleccionables (anteriormente no eran seleccionables)?

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

el trabajo que espero aterrizar para agregar Alineación Vertical al Bloque de Columnas hace que las Columnas _individuales_ sean seleccionables (anteriormente no eran seleccionables)

Gracias por señalar eso aquí. Esa es una razón más para arreglar esta interacción más temprano que tarde.

Solo quería compartir algo que hablé con

Esto se ve un poco en algunas de las maquetas anteriores , pero vale la pena mencionarlo explícitamente: además del relleno adicional que estamos discutiendo aquí, creo que la selección de navegación + bloque interno será mucho más fácil si tenemos clara la estructura del Bloques en general. Con ese fin, creo que sería excelente adoptar un par de niveles de jerarquía fronteriza. Por ejemplo:

En este ejemplo, estoy usando un borde oscuro para el estado enfocado. Si el bloque es un bloque principal o secundario, he incluido un borde de luz punteada (así como un relleno adicional) alrededor de los otros elementos relacionados. Esto ayuda a los usuarios a visualizar claramente dónde se encuentran en la jerarquía de bloques, al mismo tiempo que les da una idea clara de dónde pueden hacer clic para seleccionar otros bloques anidados.

@kjellr Me gusta mucho eso. Eso deja muy claro cuál es la estructura.

Sin embargo… creo que nos volveríamos a encontrar con un problema de contraste en la línea punteada. No puedo decirlo con certeza, pero sospecho que introducir la línea punteada significa que debe seguir los criterios de accesibilidad. Y creo que hacer un contraste mucho más alto probablemente causará algo de pesadez visual que podría anular los beneficios ...

Solo pienso un poco en voz alta. Realmente me gusta la apariencia de un usuario con vista, pero tendría curiosidad por escuchar todos los comentarios, ya que a mi gusto no es suficiente :)

En mi pantalla, ni siquiera vi la línea de puntos al principio. Parece prácticamente invisible si mi pantalla está un poco inclinada.

No hay necesidad de reducir tanto el contraste si eso lo haría menos accesible. Siempre que sea un _pequeño_ encendedor y use un border-style , creo que funcionaría bien.

Lo siento, debería haber sido más claro en mi comentario original: creé esa maqueta en solo unos minutos mientras hablaba con Joen. Creo que elegí colores al azar de algunos grises que estaban en mi pantalla en ese momento. 😄 Los tonos exactos no están destinados a transmitir una solución final, solo un enfoque general.

En respuesta a las preocupaciones sobre la adición de relleno al bloque padre que hace que los bloques internos se vuelvan inconsistentes con la interfaz (# 14148 # 14169), he trabajado con otra idea.

Esto requerirá más desarrollo para que suceda, pero podría ser una buena opción.

Básicamente, al hacer clic en el bloque principal, se expande (crece más grande que los bloques normales) para proporcionar el relleno necesario para las selecciones de padres e hijos fáciles. Esto mantiene la coherencia visual de los bloques internos con la interfaz.

Screencast

Prototipo InVision

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

PROS

1. Los bloques interiores siguen siendo del ancho adecuado.
2. Los bloques internos se mantienen visualmente consistentes con la interfaz.
3. Un bloque seleccionado que cambia de tamaño es un patrón ya utilizado.

CONTRAS

1. Expandir la selección de bloque (ancho) más allá de las selecciones de bloque normales es un nuevo patrón.
2. No estoy seguro de cómo funcionará esto cuando los bloques se establezcan en ancho completo.

Básicamente, al hacer clic en el bloque principal, se expande (crece más grande que los bloques normales) para proporcionar el relleno necesario para las selecciones de padres e hijos fáciles. Esto mantiene la coherencia visual de los bloques internos con la interfaz.

Cava eso. Me encantaría que la barra de herramientas del bloque se mantuviera alineada con el borde izquierdo, pero ese es un detalle de implementación.

Será un desafío en pantallas más pequeñas cuando en realidad no puede crecer más, pero esto también se siente como algo con solución.

En particular, parece que ese enfoque puede escalar a _cualquier_ bloque que tenga bloques internos, incluso el bloque Quote, que es un bloque de texto tan básico que la selección debería ser lo más libre posible.

Realmente, realmente excave su trabajo, Kjell: no solo podría funcionar de manera invisible con la idea de Mark, sino que también ayuda a resaltar la estructura del documento, cuando lo necesita, pero no rompe el flujo cuando solo quiere escribir. Se siente como una dirección sólida, y lo que necesitamos es un desarrollador fuerte en esto a continuación.

En una nota de implementación, el padre discontinuo _podría_ teóricamente tener el mismo color que el bloque seleccionado, pero en virtud de estar discontinuo parecería secundario todavía. Al pasar el cursor sobre el padre, el contorno podría volverse sólido, e incluso podríamos hacer que _child_ (lo que ha seleccionado mientras se desplaza) se convierta en un guión, para ayudar a indicar lo que está a punto de suceder cuando haga clic.

En una nota de implementación, el padre discontinuo _podría_ teóricamente tener el mismo color que el bloque seleccionado, pero en virtud de estar discontinuo parecería secundario todavía. Al pasar el cursor sobre el padre, el contorno podría volverse sólido, e incluso podríamos hacer que _child_ (lo que ha seleccionado mientras se desplaza) se convierta en un guión, para ayudar a indicar lo que está a punto de suceder cuando haga clic.

¡Si! Creo que eso también podría funcionar. Veamos dónde encaja el # 14145 y luego descubramos un tratamiento a partir de ahí. 👍

También modifiqué los bordes cuando hice que las columnas individuales se pudieran seleccionar pero las eliminé por estar fuera del alcance de mi PR. Definitivamente se sintió como una mejora de UX. ¡Me encanta cómo se dirige esto!

Solo un aviso: estoy convirtiendo la idea anterior en un tema separado y conciso para explorar. Siga aquí:

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

Si alguien puede contribuir para agregar una clase has-child-selected a los bloques principales cuando se selecciona a su hijo, ese es el único obstáculo para comenzar.

Un problema relacionado que encontré luego de probar el bloque de grupo recién introducido:

Lo que es confuso en este momento es que cuando inserta el bloque de grupo, lo que realmente ve es el bloque de párrafo:

¿Podemos al menos hacer algo como:

o lo que @mtias sugirió en nuestro chat privado con la reutilización de los bits de la función Block Navigation:

_Esas no son propuestas de diseño definitivas de ninguna manera 😃_

@gziolo, ese problema debe ser resuelto por # 14241. Estoy de acuerdo contigo, por cierto, así que sería encantador enviarlo pronto :)

@gziolo, ese problema debe ser resuelto por # 14241. Estoy de acuerdo contigo, por cierto, así que sería encantador enviarlo pronto :)

Bueno, diría parcialmente. Cuando inserta un párrafo con este nuevo insertador personalizado, volvemos al punto de partida 🤷‍♂️

Creo que el # 14935 también ayudará aquí. También deberíamos explorar algunas opciones en la barra lateral para tener más formas de asegurar que el bloque seleccionado actualmente esté anidado.

Ah, sí. He estado pensando en resucitar las migas de pan en la barra lateral, como lo hicimos aquí:

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

Simple y relativamente elegante, y también ayudaría en este tema (9628).

Lanzando una iteración sobre algunas de las ideas anteriores:

¿Qué pasa si movimos las transformaciones / estilos de bloque a su propio elemento dedicado, y convertimos el icono del bloque en su propio panel "Árbol de bloques"?

Creo que eso podría aumentar la visibilidad de las transformaciones / estilos de bloques, al mismo tiempo que ayuda a las personas a navegar hacia otros bloques anidados con un poco más de claridad. Aquí hay una maqueta de un ejemplo más complicado:

(Ambas composiciones también usan los contornos / relleno de # 14961)

¡Eso se ve muy interesante Kjell! Luego se vincularía con el área de Navegación de bloques creando coherencia entre ellos. A medida que uno aprende a usar la navegación por bloques, el mismo aprendizaje puede continuar con la selección de bloques anidados.

Realmente me gusta la maqueta a nivel conceptual, pero algo en la ejecución se siente un poco denso. No sé si necesariamente tengo una mejor idea, pero me pregunto si hay alguna manera de hacer que esto se sienta un poco más ligero.

Sé que he tenido problemas para tratar de encontrar un esquema rápido de mi estructura de bloques, por lo que este concepto es una gran idea para resolver esto.

Mi preocupación aquí imita la de @chrisvanpatten . Si bien está bien pensado, parece mucho.

1. En algunos bloques en determinados contextos, existen varias formas de mostrar menús desplegables.

Creo que agregar otro galón a la mezcla (aunque es gris y orientado hacia la derecha) podría agregar más dificultad para analizar.

1. La otra preocupación es que la barra de herramientas se alarga. Quizás esto no sea un gran problema, pero puede serlo cuando incluimos etiquetas para los íconos https://github.com/WordPress/gutenberg/issues/10524 y https://github.com/WordPress/gutenberg/issues/ 15311.

Solo algunos pensamientos para reflexionar mientras explora esto. Este puede ser el enfoque más simple que comunica lo que está sucediendo.

Me pregunto si hay alguna manera de hacer que esto se sienta un poco más ligero.

Sí, creo que tiene algo que ver con la falta de jerarquía allí. El primer elemento de la barra de herramientas debería sentirse un poco más como el elemento de conexión a tierra, y los otros deberían sentirse como opciones secundarias para el bloque. Se necesita algún tipo de separación. Esta no es la solución correcta, pero solo por el bien de la conversación, creo que esto ayuda un poco:

En algunos bloques en determinados contextos, existen varias formas de mostrar menús desplegables. Creo que agregar otro galón a la mezcla (aunque es gris y orientado hacia la derecha) podría agregar más dificultad para analizar.

Podría ser. Probablemente haya otra forma de representar esto en la que tampoco estoy pensando. Honestamente, incluso podría ser un icono de "árbol de bloques" adicional más sencillo en la barra de herramientas, agregado automáticamente para cualquier elemento principal o secundario:

La otra preocupación es que la barra de herramientas se alarga. Quizás esto no sea un gran problema, pero puede serlo cuando incluimos etiquetas para los iconos # 10524 y # 15311.

Convenido. Ya sea que esta sea la dirección o no, de todos modos tendremos que encontrar una solución para las barras de herramientas extralargas. Creo que esfuerzos como https://github.com/WordPress/gutenberg/pull/16557 ayudan un poco con esto, al igual que reconsideraciones más completas de la jerarquía de la barra de herramientas como https://github.com/WordPress/gutenberg/issues/ 15096.

Una cosa que me llama la atención sobre la idea de un árbol de bloques como un botón de la barra de herramientas es que es algo único por ser un elemento de la barra de herramientas de bloque que no se refiere a nada intrínseco sobre el bloque en sí, y más bien sobre cómo se relaciona el bloque con el resto del documento.

Eso es más una reflexión que cualquier otra cosa, pero para usar una analogía de las aplicaciones de gráficos, este tipo de interfaz de usuario de "capas" y "agrupaciones" normalmente (estoy seguro de que hay ejemplos que demuestran que estoy equivocado) solo existe a nivel de _documento_ en lugar de ser accesible a nivel de bloque.

Sé que hay varios problemas de accesibilidad en torno a la "brecha" entre el bloque y las herramientas a nivel de documento, y tenerlo a nivel de bloque puede facilitar la navegación.

Esto es más una meditación que cualquier otra cosa ... algo acerca de esta herramienta se siente apreciablemente diferente de las otras herramientas disponibles en la barra de herramientas en términos de cómo relaciona el bloque con otros contextos.

Esto es más una meditación que cualquier otra cosa ... algo acerca de esta herramienta se siente apreciablemente diferente de las otras herramientas disponibles en la barra de herramientas en términos de cómo relaciona el bloque con otros contextos.

Sí, tengo el mismo sentimiento.

Tenemos ese control en la barra de herramientas superior en este momento, que parece demasiado alejado del bloque en sí. ¿Quizás la barra lateral sea en realidad el mejor lugar para ello? El control casi parece que debería estar asociado con el bloque, pero como su propia barra de herramientas separada, pero definitivamente no queremos agregar otra de esas. 😄

Tenemos ese control en la barra de herramientas superior en este momento, que parece demasiado alejado del bloque en sí.

También agregaría que esto solo es cierto en la configuración predeterminada de Gutenberg. Si alguien seleccionara la opción Barra de herramientas superior para mover todas las barras de herramientas de bloque a la barra de herramientas superior, este definitivamente no es el caso. Pero dicho esto, dudo que la mayoría de los usuarios cambien esa configuración.

En otra nota, realmente me gustaría ver cómo reaccionaría la gente si la configuración de la barra de herramientas superior es la configuración predeterminada en Gutenberg. Se alinearía mejor con el editor clásico, proporcionando más familiaridad a los nuevos usuarios de Gutenberg.

Esta configuración de la barra de herramientas se ha explorado mucho y el mejor valor predeterminado se estableció después de algunas pruebas. Puede leer más sobre exploraciones aquí: https://github.com/WordPress/gutenberg/issues/2983.

Dudo que la mayoría de los usuarios cambien esa configuración.

Resulta que la posición de una barra de herramientas es un entorno increíblemente personal. Durante la fase uno de las pruebas, se redujo a que aquellos que comenzaban a usar WordPress preferían el bloque, los que tenían experiencia en la parte superior. La barra de herramientas está predeterminada en ambos lugares y estas son las mejores opciones que tenemos ahora. Además, esta es probablemente la razón por la que se siente más alineado con el editor clásico. Personalmente recomendaría que no cambiemos el valor predeterminado.

@jasmussen ¿Deberíamos cerrar esto a favor de # 17088?

Sí, creo que podemos. Este boleto exploró de manera divergente, mientras que el otro ahora refina algunas de las ideas. Este boleto aún se podrá encontrar si sigue la referencia en el nuevo boleto Thanks Riad.