Interesante idea @melchoyce.

Mi primera reacción fue cómo, al moverlos hacia abajo, el bloque se vuelve más "bloque", lo cual es algo extraño de decir, pero algo que me hace sentir. ¿Se muestra el borde al hacer clic o al pasar el mouse? Creo que tengo menos problemas con el clic que si está flotando. Otra imagen interesante que hace que al menos tus ejemplos se vean como una imagen Polaroid, muy interesante cómo mi cerebro llegó allí.

Sin embargo, esa es mi primera reacción, profundizando un poco más, creo que hay mérito en explorar una posición diferente para los íconos de interacción en un bloque. Creo que lo que ha ganado es absolutamente una forma que funciona mejor en todas las pantallas, que deberíamos tener como guía a medida que se realicen más exploraciones.

Creo que perdemos algo de contexto con las interacciones. Por ejemplo, un bloque con un marcador de posición más alto tendría esas interacciones no visibles directamente. Siento que será un problema que podría contribuir a una menor visibilidad.

Dicho todo esto, no estoy diciendo en absoluto que lo que tenemos ahora sea el camino a seguir. ¿Estás preparado para iterar y quizás explorar más? Realmente espero que lo estés.

Creo que visualmente esto es agradable. Es esencialmente la interfaz de usuario móvil, en el punto de interrupción del escritorio, y es algo que he considerado como un plan B si la interfaz de usuario lateral no funcionó, o quizás para contextos anidados.

Desde entonces, ambos hemos avanzado mucho con la interfaz de usuario lateral, más recientemente en https://github.com/WordPress/gutenberg/pull/6141 , y hemos logrado que funcione decentemente bien en contextos anidados también, aunque eso aspecto todavía necesita algo de amor.

Aunque no es tan bonito, los principales beneficios de tener esta interfaz de usuario a un lado son,

1. que pueden aparecer al pasar el mouse
2. no expanden la huella del bloque

1 es especialmente importante, ya que desde el principio ha sido un objetivo explícito asegurarse de que arrastrar y soltar sea _aditivo_, y no la forma principal de interacción al colocar, reordenar y clasificar bloques. Si los colocamos debajo del bloque, presumiblemente aparecerían al hacer clic, lo que haría que arrastrar y soltar fuera secundario, lo que siempre funcionaría al pasar el mouse.

2 podría ser importante dependiendo de cómo manejemos la interfaz de usuario lateral en contextos anidados. En este momento, nos enfrentamos a algunos desafíos en https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863, y aunque estoy seguro de que podremos resolverlos, el hecho de que la huella no El cambio ayuda.

Todo esto no quiere decir "no puede funcionar", podría funcionar muy bien. Una maqueta muy antigua tenía esta interfaz de usuario superpuesta en la esquina:

Así que, en general, son buenas ideas y es bueno mantenerlas en el fideo como avenidas que se pueden explorar dependiendo de los comentarios que recibamos de lanzamiento a lanzamiento.

¿Se muestra el borde al hacer clic o al pasar el mouse?

Solo con un clic. Hover sería similar a cómo funciona ahora.

¿Estás preparado para iterar y quizás explorar más? Realmente espero que lo estés.

Siempre 👍

no expanden la huella del bloque

Sí, definitivamente un problema con esta idea. Incluso en este prototipo se pueden ver algunos saltos debido al cambio de tamaño.

Así que, en general, son buenas ideas y es bueno mantenerlas en el fideo como avenidas que se pueden explorar dependiendo de los comentarios que recibamos de lanzamiento a lanzamiento.

👍 👍

Creo que perdemos algo de contexto con las interacciones. Por ejemplo, un bloque con un marcador de posición más alto tendría esas interacciones no visibles directamente. Siento que será un problema que podría contribuir a una menor visibilidad.

Aunque no es tan bonito, los principales beneficios de tener esta interfaz de usuario a un lado son,

1. que pueden aparecer al pasar el mouse
2. no expanden la huella del bloque

Creo que una forma de resolver estos problemas sería hacer que la barra de herramientas de bloque apareciera encima de los bloques de abajo y no aumentar el espacio que el bloque realmente ocupa en el editor. En cuanto a la capacidad de descubrimiento con bloques altos, la barra de herramientas podría volverse pegajosa para que, si se desplaza hacia arriba, la barra de herramientas no se salga de la pantalla. (Todavía desaparece cuando no se desplaza sobre el bloque, por supuesto, y tal vez solo podría aparecer cuando se desplaza sobre la parte inferior del bloque que está visible actualmente, similar a cómo funcionan actualmente los controles laterales). tanto espacio como sea necesario para mostrar todos los botones, y no ocupar una fila completa de espacio vacío entre 2 conjuntos de controles como lo hace en la maqueta en la publicación principal de este número.

+1 Solo para tener en cuenta que esto también podría ayudar a mejorar el orden de tabulación de los controles de la IU alrededor de los bloques. Como se menciona en https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531, la interfaz de usuario móvil tiene los "controles laterales" colocados de una manera más lógica. Vea el GIF animado que ilustra el orden de las pestañas, puede comparar con el GIF anterior con el orden de las pestañas en la vista de escritorio en un comentario anterior https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052

También a tener en cuenta:

3976 propone una tercera opción para colocar la barra de herramientas del bloque (la barra de herramientas de formato) debajo del bloque; Sería genial considerar un diseño con la barra de herramientas del bloque _y_ los controles laterales colocados debajo del bloque para ver si eso podría funcionar.

1934 como un problema general sobre la coherencia del orden de tabulación

Esto también podría tener un impacto en la solución de algunos de los problemas planteados en # 6272.

En cuanto a la capacidad de descubrimiento con bloques altos, la barra de herramientas podría volverse pegajosa para que, si se desplaza hacia arriba, la barra de herramientas no se salga de la pantalla.

Sí, eso es lo que sucede también con la barra de herramientas de formato superior:

Al leer todos los comentarios increíbles aquí, parece que esto resuelve una serie de problemas en el futuro y hoy con la accesibilidad. Eso en mente, creo que deberíamos trabajar quizás en algunas iteraciones aquí y luego pasar a un PR para hacer un prototipo. ¿Estarías dispuesto a hacer eso @melchoyce?

Sí, puedo echar otro vistazo.

+10 por probar esto.

Así es como se ve la IU del bloque cuando reduzco el ancho de la ventana de mi navegador. (Si lo encojo un poco más, la barra de herramientas del bloque se mueve debajo del bloque, pero eso no es relevante para lo que estoy sugiriendo).

Noté que el insertador de bloques aparece junto a los controles de movimiento arriba / abajo. Si este tipo de interfaz de usuario se usara para todos los tamaños de pantalla, como propone este problema, entonces quizás el appender de bloque actual podría eliminarse de los contextos de bloque anidados, haciendo que el editor se parezca más al front-end al eliminar el espacio adicional siempre presente agregado por cada appender de bloque para cada nivel de anidamiento. (También sugerí una solución alternativa al problema del espacio que se come el appender en el n. ° 6834).

Además, esto es solo una nota al margen, pero ¿se supone que el botón Eliminar está a la derecha del botón Más opciones , o debería estar a la izquierda? En la mayoría de los diseños de UI, los menús de puntos suspensivos se colocan en el extremo derecho.

Otra idea:

Muestre estos controles de bloque en la parte inferior al pasar el mouse, pero en este estado, no ocupan ningún espacio en la página y, en su lugar, aparecen encima de lo que esté debajo del bloque suspendido (al igual que la barra de herramientas del bloque lo hace para los bloques por encima de la uno) o quizás en la parte superior del bloque suspendido. Los controles de bloque en la parte inferior tampoco deben ser una barra blanca ininterrumpida al pasar el mouse, sino 2 barras más pequeñas a cada lado, similar a la barra de herramientas de bloque, para que los controles ocupen menos espacio y no cubran tanto.

Cuando seleccionaba un bloque, los controles de bloque en la parte inferior ocuparían espacio, aumentando la huella visual del bloque y empujando los bloques de abajo fuera del camino, como cuando selecciona un bloque de imagen aparece el marcador de posición del título. Esto facilitaría la selección del bloque de abajo si fuera un bloque verticalmente corto como un bloque de párrafo de una sola línea.

Este enfoque le permitiría mantener los beneficios de los controles actuales al pasar el mouse, lo que le permite mover / eliminar bloques fácilmente sin seleccionarlos primero, al tiempo que se asegura de que los controles no cubran nada cuando se está editando el bloque, lo que lo hace es más fácil seleccionar un bloque diferente.

Una idea más:

Permita que toda la barra de controles del bloque (y la barra de herramientas del bloque) se duplique como un controlador de arrastre (incluidos los botones, como funcionan las barras de encabezado GTK). Creo que esto resolvería prácticamente el problema de la capacidad de descubrimiento de arrastrar y soltar, especialmente en el contexto de bloques seleccionados, donde la barra de controles inferior parece ser parte del bloque en las maquetas en la publicación inicial y, por lo tanto, los usuarios probablemente lo harían será más probable que piense en usarlo como un controlador de arrastre.

Contraste eso con la situación actual en la que los lados del bloque no parecen ser parte del bloque y, por lo tanto, no es tan obvio que puedan actuar como controles de arrastre, y también existe el problema de los bloques de párrafo de una sola línea casi no tienen ningún espacio vacío en sus lados para arrastrar. (Y dado que los botones de control laterales no se pueden usar actualmente como controles de arrastre a menos que estén deshabilitados, el problema empeora aún más).

Mucha discusión sobre esto, veamos si puedo dar algunos comentarios resumidos para, con suerte, darte algo para avanzar en la iteración con @melchoyce.

En general, creo que necesito sentir esto en un prototipo y muchos de mis pensamientos creo que se pueden aliviar con eso. Sin embargo, hay algunas consideraciones que me gustaría trabajar en una simulación:

• Una solución para bloques altos.
• Un sentimiento menos 'bloqueado': esto puede estar mostrando los estados de marcador de posición en una simulación, lo estoy leyendo como más obvio con estos cambios.
• Mostrando cómo funciona esto con el anidamiento.

Me encantaría ver cómo esto también se adapta a diferentes dispositivos, creo que hay menos variación y eso podría ser algo grandioso.

@SuperGeniusZeb, tienes algunas ideas interesantes. Me gustaría ver a dónde llega Mel con las iteraciones anteriores. Creo que duplicar la interfaz de usuario para arrastrar los controles es algo que se debe evitar por ahora, hay cambios de anidación en los que se está trabajando y me gustaría entrar allí. No estoy diciendo que no iteremos, pero esta interfaz de usuario no es específicamente para eso. También creo que se puede inferir la pertenencia sin ser explícito visualmente y donde se vuelve demasiado explícito es donde entra el sentimiento negativo de los bloqueos: se siente cercano y demasiado limitante.

Estaba dando vueltas por el # 7211 y en el contexto de ese trabajo descubrí el # 7646, y eso me trajo de vuelta a esta idea, que realmente se siente como la mejor solución para un montón de problemas.

Este ticket arreglaría, directa o indirectamente, un montón de cosas:

• # 7646 → con los controles colocados arriba / abajo, no tiene que preocuparse por acomodar la interfaz de usuario lateral
• # 7182 → controles como los de las maquetas de este ticket están conectados directamente al bloque y tendrían una interfaz de usuario consistente independientemente del nivel de anidamiento
• # 6451 → si las barras de herramientas superior / inferior tienen un fondo sólido, no tiene que preocuparse por averiguar cómo hacer que los controles sean visibles en fondos oscuros
• # 7114 / # 6265 → Si usa una barra de herramientas de ancho completo como en algunas de las maquetas anteriores, puede usar el área vacía para arrastrar / soltar

Todo esto para decir que, si todavía existe la posibilidad de que un cambio tan grande llegue a Gutenberg, creo que podría resolver muchos problemas y facilitar muchas cosas :) algunas maquetas / conceptos con suerte este fin de semana.

@chrisvanpatten solo para agregar perspectiva, este problema se trata de controles, no de

Estaría totalmente a favor de probar esto, ya que mejora mucho el orden de las pestañas. Una actualización rápida: el botón de eliminar "papelera" se ha movido dentro del menú de puntos suspensivos. También sugiero tratar de cumplir con el principio de proximidad de controles y colocar el botón de puntos suspensivos inmediatamente a la derecha de los motores. No estoy seguro de por qué debería permanecer tan a la derecha:

@afercia, ya que son controles diferentes, creo que tener puntos suspensivos a la derecha tiene sentido. Exploremos eso como el primer paso. Necesitamos enfocarnos en explorar lo siguiente:

Una solución para bloques altos.
Un sentimiento menos 'bloqueado': esto puede estar mostrando los estados de marcador de posición en una simulación, lo estoy leyendo como más obvio con estos cambios.
Mostrando cómo funciona esto con el anidamiento.

Es necesario explorar estos puntos para determinar la ruta desde este punto prometedor.

@karmatosed Estaba usando una jerga confusa: me refiero a controles, no a barras de herramientas. Las barras de herramientas ya están en la parte superior, no hay nada que cambiar allí :)

Acabo de hacer algunas maquetas de cómo imagino que se verían las herramientas de bloque si se colocaran debajo del bloque. Tenga en cuenta que en estas maquetas, las herramientas de bloque nunca ocupan espacio, solo actúan como superposiciones como las barras de herramientas de bloque en el escritorio. Los bloques también se seleccionan en estas maquetas. Si solo se desplaza sobre un bloque, las barras de herramientas del bloque en la parte superior no se mostrarían. También tenga en cuenta que los controles inferiores solo pueden aparecer cuando se desplaza cerca de ellos, como los controles laterales actuales.

Normal:

Cuando la parte inferior de un bloque está fuera de la pantalla:

(Nota al margen: la barra de herramientas de bloque de imagen no coincide con la de estas maquetas, ya que tiene diferentes opciones en su barra de herramientas de bloque).

Dados los problemas con las herramientas de bloque que están en los lados y los diversos beneficios de tenerlas en la parte inferior, ahora estoy convencido de que tenerlas en la parte inferior es el camino a seguir.

@SuperGeniusZeb Eso es básicamente exactamente lo que estaba pensando, excepto que iba a colocar el botón de más opciones con la flecha hacia arriba / abajo en lugar de hacia la derecha, como una barra de herramientas combinada.

@chrisvanpatten Sí, no me importaría de ninguna manera si los controles estuvieran separados o no.

Aquí hay algunas maquetas más:

Flotar:

Seleccionado con una barra de ancho completo que ocupa espacio (en lugar de ser solo una superposición) como en un dispositivo móvil y podría funcionar como un controlador de arrastre:

Tengo que decir que creo que estamos en un pequeño peligro de que esto se vuelva demasiado bloque ... esa es una forma extraña de describir esto, pero sigue adelante :) Por ejemplo, el desplazamiento que se muestra en la última simulación es bastante intenso. Creo que tenemos que ver esto ir más por lo que Mel mostró en la primera imagen que tiene un borde menos y realmente ayuda no tener eso.

Tomé las primeras simulaciones y eliminé la papelera para obtener lo que creo que sería mejor para progresar:

No necesitamos los bordes adicionales y no necesitamos el peso agregado. De esta manera, permite un fácil arrastre sin los inusuales contornos flotantes.

@karmatosed Modifiqué tu maqueta para mostrar cómo se vería cuando

Y aquí está con el bloque seleccionado y la barra de herramientas del bloque mostrada:

(También actualicé el marcador de posición del bloque de imagen para que coincida con el actual en Gutenberg).

Algo que me confunde un poco acerca de no tener un borde superior en los controles: ¿los controles todavía están sobre un fondo blanco? ¿Significa esto que todo el bloque tiene un fondo blanco detrás? Eso suena como que causaría problemas en contextos anidados donde un bloque está anidado en un contenedor con un fondo oscuro, ya que seleccionar (y / o pasar el cursor) haría que el fondo del bloque cambiara, lo que se vería bastante discordante.

Algo que me confunde un poco acerca de no tener un borde superior en los controles: ¿los controles todavía están sobre un fondo blanco? ¿Significa esto que todo el bloque tiene un fondo blanco detrás?

Lo hace, pero los controles tienen objetivos. Creo que vale la pena mostrarlo y evita los problemas visuales del bloque sin él. Esto absolutamente necesita ser explorado en la anidación, sin embargo, sin el fondo, la anidación sería aún peor visualmente.

Lo hace, pero los controles tienen objetivos. Creo que vale la pena mostrarlo y evita los problemas visuales del bloque sin él. Esto absolutamente necesita ser explorado en la anidación, sin embargo, sin el fondo, la anidación sería aún peor visualmente.

De acuerdo, y tener el fondo también resuelve # 6451.

No me gusta que se muestre esa gran barra vacía al pasar el mouse en esas últimas maquetas. Idealmente, querrá cubrir la menor cantidad posible de los bloques circundantes al pasar el mouse, pero esto cubre una gran parte del bloque a continuación. ¿Qué tal algo como esto?

Como se sugirió anteriormente, las flechas y puntos suspensivos pueden funcionar como controles de arrastre y / o el título de desplazamiento podría ser un control de arrastre. (Ver # 7114.)

@SuperGeniusZeb, aunque entiendo sus puntos en este caso, tener los bloques delineados realmente no es genial visualmente. Sigamos con el simulacro que hice basado en el increíble trabajo de Mel para verlo en un prototipo.

Algo de lo que me acabo de dar cuenta acerca de que aparece un fondo blanco detrás de los bloques seleccionados: ¿qué pasa con los bloques con un color de texto blanco (o de otro color claro) que deben verse en un área de color oscuro (proporcionado por algo como el bloque Container)? Tener un fondo blanco para todo el bloque no funcionaría en este caso.

El fondo está alrededor de la barra de herramientas que siempre tendrá esos controles.

@SuperGeniusZeb Sí, no veo el fondo blanco impactando el bloque en sí, solo los controles. Prácticamente podría ser algo como esto:

O el relleno podría eliminarse (realmente me gusta este enfoque, pero obviamente es una pregunta más importante que tiene implicaciones con arrastrar y soltar. Aún así, creo que vale la pena considerarlo):

@chrisvanpatten Me gusta esa última maqueta. No creo que arrastrar y soltar sea un problema, ya que la barra inferior podría ser un controlador de arrastre (y potencialmente los botones de la barra también funcionarían como uno). Incluso puede agregar un ícono de control de arrastre a la barra inferior al pasar el mouse o simplemente tener uno allí para indicar que puede arrastrar el bloque usándolo.

Con este enfoque, no veo ninguna razón para mantener el área que se puede arrastrar cerca de los bordes del bloque. Eliminar ese relleno también podría ayudar a que los contornos de desplazamiento / seleccionados del bloque estén más cerca de los bordes reales del bloque, ya que ya no tendrían que tener en cuenta el espacio de arrastre y solo tendrían que ajustarse para ser más grandes que el bloque real en casos de anidamiento para facilitar la selección de bloques padres. (Seleccionar bloques principales sería un problema menor si se implementaran cosas como la maqueta en este comentario en # 6459).

@SuperGeniusZeb

Incluso puede agregar un ícono de control de arrastre a la barra inferior al pasar el mouse o simplemente tener uno allí para indicar que puede arrastrar el bloque usándolo.

Gran idea 💡

Creo que dejemos el área que se puede arrastrar a un lado e implementemos esto. Es importante concentrarse en resolver primero el problema que esto está resolviendo. Debo decir que no estoy seguro de que un ícono sea el enfoque correcto, eso dice, revisemos una vez que lo tengamos implementado sin eso.

@karmatosed

Creo que dejemos el área que se puede arrastrar a un lado e implementemos esto.

No estoy muy seguro de lo que esto significa. ¿Qué lado?

Me alegra ver que esto va a suceder. Solo un recordatorio rápido de que no se trata solo de la ubicación visual. Para todos, el orden visual y el orden de tabulación (orden DOM) deben coincidir, por lo que estas "herramientas de bloque" deben moverse después del área editable del bloque en el marcado.

Un buen beneficio de cambiar a controles debajo del bloque es que abre el espacio lateral para permitir que el insertador hermano sea rediseñado a algo como los de Squarespace si el diseño actual tiene problemas. Los controles laterales actuales se habrían superpuesto a este tipo de insertador y se verían desordenados, pero con los controles movidos hacia la parte inferior, esto ya no es un problema.

https://support.squarespace.com/hc/en-us/articles/206991377-Adding-blocks#toc -insert-points

Acabo de comentar sobre esto en el # 7500. Me preguntaba cómo se verían los párrafos sucesivos con este diseño. Creo que tener la barra en la parte inferior resultaría en una gran brecha entre párrafos.

@talldan Citando a mí mismo del # 7500:

Los controles de bloque no ocuparían espacio al pasar el mouse (al igual que ellos y la barra de herramientas del bloque no ocupan espacio ahora), y por lo que puedo decir, ni siquiera se ha decidido aún si ocuparían espacio en un bloque seleccionado. Y, por supuesto, los controles solo se mostrarían para los bloques que están seleccionados o sobre los que se pasa el cursor. La distancia estándar entre bloques no debería verse afectada por el cambio; solo el bloque seleccionado puede verse afectado.

Esto se ve muy bien, estoy totalmente de acuerdo.

Una cosa a considerar en esto que no hemos hecho antes. ¿Qué pasa con los bloques largos? ¿Qué pasa con esos bloques y la parte inferior de la pantalla del editor?

¿Quieres decir que cuando el bloque es tan largo que se pierde de vista? Yo diría que antes de que eso suceda, la gente habrá visto cómo funciona y sabrá dónde encontrarlo. Solo tendríamos que probar si eso se vuelve molesto si escribe muchos párrafos largos en una pantalla pequeña. Pero me gusta que refleja mejor la experiencia móvil. ¿Qué inquietudes tiene para el último bloque de una publicación?

¿Cómo verían si su primer bloque era realmente largo?

Al menos deberíamos agregar un consejo NUX al respecto;) pero lo que le preocupa es el caso de que alguien abra una publicación existente que tal vez sea un párrafo largo o no se haya convertido en bloques correctamente. Es posible ... Si comienzan una nueva publicación, es casi seguro que la verán en el primer bloque de marcador de posición, ¿verdad?

Pensando en esto, no veo una exploración aquí de poner los controles en la parte superior del bloque, lo que podría ser una opción. Hice una maqueta rápida para eso. (La combinación de las barras también se menciona aquí )

Si un bloque es demasiado alto, ¿no se pegarían los controles inferiores a la parte inferior de la pantalla, como la forma en que los controles superiores se pegan a la parte superior o cómo funciona en dispositivos móviles?

@hedgefield Me gusta mucho, pero no funciona bien en contextos estrechos (como un bloque de columnas) o con barras de herramientas largas.

@hedgefield @chrisvanpatten ¿ Quizás los controles de flecha / puntos suspensivos podrían moverse por debajo (o por encima) de los controles de formato en casos de anchos más delgados?

@karmatosed Yo diría que los controles podrían estar pegajosos y permanecer visibles en la parte inferior de la pantalla. Sin embargo, esto causa este problema de los controles que cubren la línea que está tratando de escribir en un párrafo cada vez que comienza a escribir (presumiblemente, estarán ocultos durante la escritura, como funciona ahora). Pero de todos modos esa solución parece cuestionable.

Sin embargo, volviendo a la maqueta de @hedgefield , eso podría permitir que los controles sean pegajosos al igual que las herramientas de formato sin estorbar. Por supuesto, la barra de herramientas debería responder y las flechas y puntos suspensivos deberían moverse idealmente hacia abajo / arriba / en algún lugar para bloques delgados.

También existe la preocupación por la accesibilidad. La maqueta de @hedgefield tiene todos los controles antes del bloque visualmente. Idealmente, deberían ir después del bloque en el marcado. Teóricamente, podría usar CSS para permitir que los controles vayan después del bloque en el marcado, pero que aparezcan encima visualmente. Sin embargo, no estoy seguro de cuán difícil es implementar esto en la práctica, y no sé si debería ocurrir una inconsistencia entre la apariencia visual y el orden de las fuentes. Personalmente, no me importa, ya que el hecho de que todos los controles de bloque aparezcan después del bloque en el marcado hace que encontrar los controles a través del teclado sea mucho más intuitivo, ya que puede avanzar hacia adelante en lugar de tener que retroceder.

y no sé si es deseable una inconsistencia entre la apariencia visual y el orden de la fuente

No es deseable que en un momento exista un criterio de éxito WCAG específico para eso:
https://www.w3.org/TR/WCAG21/#focus -order

Yo diría que los controles podrían ser pegajosos y permanecer visibles en la parte inferior de la pantalla. Sin embargo, esto causa este problema de los controles que cubren la línea que está tratando de escribir en un párrafo cada vez que comienza a escribir (presumiblemente, estarán ocultos durante la escritura, como funciona ahora). Pero de todos modos esa solución parece cuestionable.

En realidad, pensándolo un poco más, los controles en realidad no cubrirían la última línea de un párrafo a menos que el párrafo estuviera justo al lado de la parte inferior de la pantalla, por lo que el número 353 podría hacer que esto no sea un problema. E incluso sin el # 353, aún podría desplazarse hacia abajo (que es lo que la mayoría de la gente hace de todos modos) y, como se mencionó anteriormente, los controles también solo se mostrarían cuando moviera el mouse. He cambiado de opinión. ¡Esto podría funcionar!

Cómo se vería para bloques anchos:

Cómo se vería para bloques delgados:

Incluso bloques más delgados (piense en 8 columnas o algo así):

Creo que realmente me está empezando a gustar este diseño. Sin embargo, para bloques más anchos, no estoy seguro de si los controles de desplazamiento de flechas deberían ir a la izquierda de los controles de formato oa la derecha.

Gracias por las exploraciones, sin embargo, combinar todo en una línea es fusionar diferentes acciones en un solo lugar. No estoy seguro de que tenga sentido. También tenemos en cuenta lo que sucede cuando alguien coloca una barra de herramientas en la parte superior: está eligiendo no tener algo "en su lugar" y ahora los controles sí. Eso se siente como una experiencia menor, ya que no podemos tener controles de bloque en la barra de herramientas; sería muy extraño experimentarlo.

sin embargo, combinar todo en una línea es fusionar diferentes acciones en un solo lugar.

Para jugar al abogado del diablo, ¿no es ese, por definición, el propósito de una barra de herramientas?

Para agregar más, si bien puedo entender la idea detrás de separar ciertos controles, no estoy seguro de que haya un argumento lo suficientemente convincente para ello en este caso. Una barra de herramientas es una barra de herramientas; Poner todos los controles para un bloque dado en un lugar tiene sentido lógico, en lugar de encontrar razones borrosas por las que ciertas herramientas pertenecen a ciertos lugares mientras que otras herramientas pertenecen a otros lugares que los complementos inevitablemente ignorarán de todos modos.

@karmatosed ¿Qué tal separar los controles a través del color?

@SuperGeniusZeb desafortunadamente eso no resuelve mis otros puntos, no y no estoy seguro de que funcione.

Realmente creo que en este caso se trata de tratar de ajustar un diseño que se piensa que funciona en lugar de obtener el que funcionará. ¿Qué tal dar un paso atrás y considerar los otros puntos que mencioné?

@chrisvanpatten una barra de herramientas no es, por definición, un lugar para poner todo, para ser útil, una barra de herramientas debe tener contexto y orden. Como usuario, debe esperar cuáles son las opciones correctas. Si bien podemos debatir cuál es el significado de una palabra en singular por un tiempo, es divertido hacerlo, no podemos perder de vista el hecho de que esto combina demasiadas cosas a la vez y sería un problema para más personas.

@karmatosed Está bien entonces. Volvamos a tener la barra de herramientas de edición en la parte superior:

(No estoy seguro de si esa línea azul sobre la barra debería estar allí o no).

¿Hay algún problema con este diseño? La barra de herramientas de edición podría aparecer después del bloque en el orden de origen para la accesibilidad; no es lo ideal, pero como poner la barra de herramientas de edición debajo del bloque no parece ser una opción viable, parece ser lo único que podemos hacer.

Además, acabo de tener una idea: ¿y si la barra en la parte inferior fuera parcialmente transparente al pasar el mouse? ¿Eso lo haría sentir más ligero?

@SuperGeniusZeb solo para obtener vistas, ¿puedo sugerir que tengamos

Solo para obtener un siguiente paso simulado. @SuperGeniusZeb ¿cómo se

Algunas maquetas:

Con borde en la parte superior de la barra de controles

Sin borde en la parte superior de la barra de controles

Observe que la barra de herramientas no ocupa ningún espacio al pasar el mouse, pero lo hace cuando se selecciona el bloque.

Al hacer estas maquetas, noté algo: ¿qué se debe hacer en situaciones como esta?

Aquí hay un conflicto entre mostrar tanto la barra de herramientas de formato del bloque seleccionado como los controles inferiores del bloque suspendido. Si la barra de herramientas de formato estuviera en la parte inferior (o si los controles del bloque estuvieran todos en la parte superior), esto no sería un problema, pero aquí la combinación de los controles que se muestran a continuación y los controles que se muestran arriba de los bloques crea un problema.

La mejor solución en la que puedo pensar sería hacer que el bloque flotante y su barra de herramientas tengan un índice Z más alto y aparezcan en la parte superior del bloque de abajo y su barra de herramientas de formato. Sin embargo, no estoy seguro de que este sea el enfoque correcto. Aquí hay una maqueta de cómo se vería esto:

Y nuevamente, sin el borde entre la barra inferior y el contenido del bloque:

Realmente no me gusta la idea de que el bloque flotante se superponga al seleccionado, pero por lo demás no veo forma de usar las barras inferiores de los bloques flotantes directamente sobre los seleccionados. ¿Estás seguro de que no sería mejor tener todos los controles en una sola barra en la parte superior o inferior, al menos en el escritorio? Sin duda evitaría problemas como este.

@SuperGeniusZeb De alguna manera me había perdido esas maquetas. ¡Gracias por hacerlos!

Ese es un gran punto en el que no había pensado (colocar el bloque sobre el bloque seleccionado). Definitivamente es un problema. Como experto en el creador de páginas residente, ¿existen otros patrones similares en otros creadores de páginas, con barras de herramientas en capas como esta?

Además, por lo que vale, creo que las barras de herramientas siempre deben estar colocadas, seleccionadas o no. El hecho de que, a veces, ocupe espacio, generará contenido inquietante, que en general es una experiencia más incómoda.

@chrisvanpatten Todos los creadores de páginas que he visto solo tienen controles (excepto tal vez un insertador hermano) que se muestran en la parte superior de un módulo / widget. Divi es uno de los mejores ejemplos, en mi opinión:

https://supergeniuszeb.com/wp-content/uploads/2018/06/Divi-Visual-Builder-add-button-responsiveness-demonstration.webm

No se muestra en el video, la barra de herramientas de formato en Divi aparece cuando hace clic en el texto en un módulo, y aparece en una pequeña ventana emergente sobre la línea que está escribiendo.

Elementor hace casi lo mismo.

En Beaver Builder, hacer clic en el texto de un widget hará que la barra de herramientas de controles de bloque sea reemplazada por la barra de herramientas de formato hasta que el mouse se mueva fuera de los bordes del widget, lo que hará que los controles de bloque estándar aparezcan la próxima vez que coloques el cursor sobre el widget. , aunque todavía puede escribir en el widget. Al hacer clic en el texto nuevamente, la barra de herramientas de formato reemplazará nuevamente a la barra de herramientas estándar.

Además, por lo que vale, creo que las barras de herramientas siempre deben estar colocadas, seleccionadas o no. El hecho de que a veces ocupe espacio dará lugar a contenido nervioso, que en general es una experiencia más incómoda.

Es cierto, pero me preocupan las implicaciones que esto tiene para tener una interfaz de usuario limpia. Si la barra de herramientas de formato se superpone con parte del contenido anterior, está bien. Pero luego, si agrega una barra de ancho completo en la parte inferior del bloque, ahora está superponiendo mucho otro contenido.

Idealmente, querrá que todos los controles estén en la parte superior o inferior del bloque. Eso evitaría que las barras de herramientas se superpongan entre sí en la mayoría de los casos. En aras de la accesibilidad, lo ideal sería colocar los controles en la parte inferior. Sin embargo, puede encontrarse con problemas en los que las barras de herramientas se superponen al contenido que está escribiendo en algo así como un bloque de párrafo. Sin embargo, debe tenerse en cuenta que solo la barra de herramientas de formato es realmente necesaria para estar visible en todo momento, ya que las flechas y los puntos suspensivos no son algo que se utilice con tanta frecuencia. Además, si la parte del contenido de un bloque que se está editando actualmente se mantiene lo suficientemente lejos de la parte inferior de la pantalla, la barra de herramientas de formato no tendrá que superponerse.

Si colocar los controles en la parte inferior se siente demasiado incómodo, entonces parece que la siguiente mejor opción es colocarlos todos en la parte superior. Por supuesto, existe el problema potencial de que los controles parezcan incómodos para bloques delgados.

En los casos de computadoras de escritorio versus dispositivos móviles, generalmente puede salirse con la suya cambiando la posición de las barras de herramientas. En este momento, la barra de herramientas de formato y otros controles se muestran debajo del bloque seleccionado actualmente y ocupan espacio en el dispositivo móvil.

Sin embargo, en los casos de bloques anchos frente a bloques delgados, mover los controles para los bloques más delgados puede resultar incómodo. El aspecto más consistente puede ser tener la barra de herramientas de formato en la parte superior y los otros controles en la parte inferior. Pero eso nos devuelve al problema de la superposición de barras de herramientas y la mayor cantidad de superposición de contenido.

Gutenberg está diseñado en torno a la idea de que la apariencia del bloque seleccionado está optimizada para la edición, por lo que creo que hacer que las barras de herramientas ocupen espacio físico no es tan malo, siempre que haga que la selección del bloque solo mueva cosas alrededor del bloque, y no se mueva el bloque seleccionado en sí.

Al final, siento que estas maquetas siguen siendo una muy buena opción. No es perfecto, pero tiene sentido desde una perspectiva de accesibilidad, no se ve demasiado incómodo, es consistente con los dispositivos móviles y rara vez debería resultar en barras de herramientas superpuestas.

Algunas notas sobre cómo funcionaría esto:

Los controles no ocupan espacio al pasar el mouse, pero ocupan espacio cuando se selecciona el bloque. Al colocar el cursor sobre un bloque, solo se muestran las flechas y los puntos suspensivos, pero al seleccionar el bloque, aparece la barra de herramientas de formato, que empuja los otros controles hacia abajo. Este es probablemente el mayor problema con este diseño. Creo que para que esto funcione mejor, desearía que el contenido del bloque se empujara hacia arriba al seleccionar un bloque haciendo clic en la barra de herramientas de elementos móviles / puntos suspensivos, pero querría que las barras de herramientas se muevan si seleccionó el bloque haciendo clic en el área de contenido.

Cuando un bloque se extiende por debajo del área de contenido, las flechas y los puntos suspensivos estarán fuera de la pantalla, pero la barra de herramientas de formato permanecerá visible, pegada en la parte inferior de la pantalla (o en el área del editor de contenido).

Si esta no es la mejor solución, entonces optaría básicamente por lo mismo, pero con los controles en la parte superior, con los elementos móviles / puntos suspensivos que aparecen encima de la barra de herramientas de formato para bloques delgados, y quizás a la izquierda de los controles de formato para bloques anchos. Los dispositivos móviles aún podrían lucir como lo hacen ahora.

Otro pensamiento: podría deshacerse tanto del problema de los controles de cambio como de las barras de herramientas que se superponen entre sí si simplemente no mostrara ningún control al pasar el mouse. Eso haría que mostrar las barras de herramientas tanto en la parte superior como en la inferior de los bloques fuera un problema mucho menor. Pero, por supuesto, pierde los beneficios de tener controles mostrados al pasar el mouse. No estoy realmente seguro de si esa es la dirección en la que alguien quiere ir, pero estoy empezando a preguntarme si es necesario.

Tengo que decir que la idea de la superposición del bloque suspendido tampoco es una que me guste. Creo que esto necesita un poco más de reflexión. La idea de que los controles ocupen un espacio diferente potencialmente al pasar el mouse se siente un poco incómoda.

Los controles no ocupan espacio al pasar el mouse, pero ocupan espacio cuando se selecciona el bloque. Al colocar el cursor sobre un bloque, solo se muestran las flechas y los puntos suspensivos, pero al seleccionar el bloque, aparece la barra de herramientas de formato, que empuja los otros controles hacia abajo. Este es probablemente el mayor problema con este diseño.

Creo que este es un gran problema con las simulaciones. ¿Qué más podría pasar?

Si bien mirar los creadores de páginas es un aspecto, ¿qué pasa con otras aplicaciones y productos? ¿Esto está resuelto en otro lugar?

@karmatosed

Si bien mirar los creadores de páginas es un aspecto, ¿qué pasa con otras aplicaciones y productos? ¿Esto está resuelto en otro lugar?

Tratar de encontrar ejemplos análogos de UI que Gutenberg podría usar es difícil, porque casi nada tiene que explicar todas las cosas que hace Gutenberg.

Muchos complementos de creación de páginas más simples / antiguos no tienen que preocuparse por ocultar el contenido de su equivalente de un bloque, porque toda la edición de contenido se realiza en una barra modal o lateral. Esto los libera para permitir que los controles de sus módulos se superpongan al contenido.

Incluso en casos como Divi o Beaver Builder, donde puede editar el texto sin abrir una barra modal / lateral, la barra modal / lateral sigue siendo la forma principal de edición. Divi y Beaver Builder muestran lo que es esencialmente una réplica perfecta del front-end, sin tener que preocuparse por tener que optimizar para cosas como usarlos como editor de texto o asegurarse de que la mayoría del contenido del bloque principal se pueda editar en línea en el bloque.

Además, tanto en los creadores de páginas como en otras interfaces de usuario de tipo constructor, el anidamiento tiende a ser un problema mucho menor debido a las restricciones sobre lo que se puede anidar. Divi tiene una Sección → Fila estricta (con columnas integradas) → Configuración del módulo (aunque con algunas Secciones especializadas diseñadas para algunas situaciones de columna anidadas comunes). Beaver Builder solo permite que las columnas se aniden en columnas, al igual que Elementor. Controlan el único tipo de objeto que puede tener múltiples capas de anidación. Todo está en una sección con una sola fila por defecto. No hay capas ilimitadas de bloques anidados con potencial para cualquier combinación de bloques personalizados que utilicen el anidamiento para varios propósitos y varios estilos como lo que permite Gutenberg.

Divi puede codificar con colores sus controles para secciones, filas y módulos porque tiene una estructura estricta y no puede haber ningún módulo personalizado que actúe como una sección o fila. (Esto también le permite mostrar varios botones de inserción en la misma línea, pero con diferentes colores para distinguir lo que hará cada uno). En la mayoría de los constructores, los módulos están separados de los elementos de diseño. Beaver Builder puede hacer cosas similares debido a la separación de módulos y elementos de diseño.

Si observa cosas que no son creadores de páginas, como editores de texto, puede ver que no tienen que preocuparse por todas las cosas con las que tienen que lidiar los creadores de páginas. Si observa la mayoría de los creadores de páginas, no manejan las cosas del editor de texto a través de controles WYSIWYG en línea directos.

Lo que Gutenberg intenta hacer es único. Está tratando de ser un generador de páginas WYSIWYG, excepto por el bloque seleccionado, que está optimizado para la edición, que también es un editor de texto completo, y todo, desde secciones hasta columnas y widgets, son todos del mismo tipo. de objeto: bloques.

Básicamente, este es un tema complicado porque Gutenberg está tratando de hacer varias cosas diferentes al mismo tiempo que aparentemente nada más intenta hacer. : Lengua_salida_atascada:

De todos modos, aquí hay una lista de cosas que se pueden ver para ver cómo manejan la IU de bloque / módulo / widget:

Complementos / temas de WordPress

• Avada (Fusion Builder)
• BeTheme (Constructor de muffins)
• Constructor de castores
• Divi (Constructor de Divi)
• Elementor
• Oxígeno
• Creador de páginas SiteOrigin
• Arquitecto prosperar
• Compositor visual
• X & Pro de Themeco

Constructores de sitios web fuera de WordPress

• Drupal
• Espacio cuadrado
• Weebly
• Wix

Cosas que no son creadores de páginas pero que son similares a una

• MailChimp
• Noción

Esos son todo lo que sé ahora.

Hay un problema con el insertador hermano: siempre se superpone al contenido del bloque seleccionado. Este problema empeora aún más cuando intentas deshacerte de cosas como los márgenes automáticos en cada bloque para hacer que Gutenberg sea más WYSIWYG.

¿La solución? Bueno, si vamos a agregar una barra en la parte inferior de los bloques, ¿por qué no arrojar el insertador hermano también en esa barra?

Además, se me ocurrió una manera de hacer que el borde de la variante flotante parezca un poco menos discordante. ¡Simplemente cambie el color del borde que divide el contenido del bloque de la barra inferior!

Beneficios incluidos:

• El insertador hermano nunca se superpone al contenido del bloque seleccionado. Esto significa que ahora no debería haber una interfaz de usuario que se superponga al contenido del bloque seleccionado, excepto por la barra de herramientas de formato pegajosa, que no cubre el contenido si simplemente se desplaza hacia arriba o simplemente está escribiendo y sin mover el mouse.
• El insertador hermano ahora aparece en el mismo orden que el orden de tabulación HTML, lo cual es bueno para la accesibilidad.
• El insertador hermano ahora aparece debajo de los bloques en lugar de arriba. Esto tiene más sentido, en mi opinión.
• El insertador hermano siempre está visible para el bloque seleccionado (excepto tal vez al escribir si los controles aún se hacen invisibles como ahora)
• Coherencia con la interfaz de usuario móvil.
• Todos los márgenes y el relleno interno de los bloques podrían eliminarse, y los bordes del bloque podrían volver a ser del tamaño real del bloque, todo sin que la interfaz de usuario del bloque se interponga en el contenido del bloque.

Puntos de bonificación si se cambia el insertador hermano para abrir el menú del insertador directamente (como se explica en # 7271) en lugar de insertar un bloque de párrafo vacío.

Por supuesto, la pregunta de qué sucede cuando colocas el bloque sobre el seleccionado sigue siendo un problema. Sin embargo, no creo que esto realmente me moleste tanto. Todo lo que tiene que hacer es hacer clic en el bloque para seleccionarlo y ver los controles, y si los controles de desplazamiento se muestran debajo del bloque seleccionado actualmente, está bien, ya que se supone que el bloque seleccionado es el foco.

Creo que este es un buen diseño para seguir adelante. Creo que todos los aspectos positivos superan a los negativos, y creo que definitivamente es mejor que lo que existe ahora. ¿Qué piensan ustedes?

Me burlé de cómo se ve esto si las barras de herramientas superior e inferior se superponen, y cómo se vería si el bloque flotante siempre toma el índice z más alto sobre un bloque seleccionado.

Me gusta mucho esto, pero tiene un pequeño problema… los bloques de una sola línea no tienen suerte, porque estarán casi completamente ocultos debajo de la barra de control inferior.

@chrisvanpatten Estaba pensando que la barra inferior ocuparía espacio cuando se selecciona el bloque. Creo que eso solucionaría el problema del bloqueo de una sola línea. ¿Podrías hacer una maqueta para mostrar cómo se ve? Además, ¿cómo es si el bloque flotante no se superpone al bloque seleccionado?

Además, quizás debería haber una sombra debajo de la barra inferior cuando se superpone a algo.

@SuperGeniusZeb Realmente me opongo firmemente a que la barra inferior ocupe espacio, lo que lleva a saltar la IU. Los bloques reutilizables hacen eso ahora cuando los seleccionas y me vuelve loco.

(EDITAR: Para elaborar, hace las cosas realmente difíciles para los usuarios del mouse porque realmente no puedes confiar en que las cosas estén en el mismo lugar de un momento a otro. Causa mucha incomodidad).

@chrisvanpatten

Principalmente estoy pensando que en el contexto de escribir publicaciones, probablemente no querrá cubrir el párrafo debajo del que está escribiendo. En este momento parece que al bloque de párrafo debajo del seleccionado le falta su primera línea. Creo que preferiría que los bloques circundantes saltaran un poco cuando seleccionas uno a no poder ver la parte superior del bloque después del que estoy editando actualmente. Personalmente, los saltos no me molestan mucho.

Es bastante común en Gutenberg que algo cambie de tamaño cuando lo selecciona: marcadores de posición de título de imagen, marcadores de posición de cita de cita, el marcador de posición / insertador en la Galería y los bloques reutilizables, como mencionó. Generalmente, Gutenberg está diseñado en torno a la idea de que la apariencia de un bloque debe optimizarse para su edición cuando se selecciona. Yo diría que está bien hacer que la altura del bloque sea más alta debido a que la barra inferior ocupa espacio.

Alternativamente, ¿quizás la barra inferior podría hacerse semitransparente para que quede un poco más claro que hay un bloque debajo de ella? ¿Como suena eso? Creo que podría estar de acuerdo con eso.

El único problema es que la transparencia no se usa en ningún otro lugar de la interfaz de usuario de Gutenberg. Eso no quiere decir que no deba usarse ... solo que no hay ejemplos existentes, por lo que podríamos estar introduciendo una inconsistencia en el diseño de la interfaz de usuario.

También existe la idea de deshacerse del espacio vacío entre los controles de la izquierda y la derecha, pero eso fue derribado anteriormente en el ticket debido a que la interfaz de usuario parece demasiado "bloqueada".

@chrisvanpatten Dicho todo esto, creo que aún preferiría tu maqueta sobre lo que existe ahora . El problema de la primera línea del bloque siguiente parece desaparecer es menor en comparación con todas las cosas que solucionaría cualquiera de nuestras maquetas.

@SuperGeniusZeb Creo que lo que lo hace particularmente incómodo en este caso es que los controles están ahí cuando pasas el mouse. Con todos los otros ejemplos de controles de salto, al menos no están allí cuando pasas el mouse, solo están allí en la selección.

No creo que valga la pena abandonar esto debido a los problemas de desplazamiento / selección / salto / párrafo de una sola línea, pero definitivamente se necesita pensar un poco más.

Todavía estoy seguro de que hay una solución aquí en alguna parte ... ¡solo tengo que seguir iterando!

@chrisvanpatten

Creo que lo que lo hace particularmente incómodo en este caso es que los controles están ahí cuando se desplaza. Con todos los otros ejemplos de controles de salto, al menos no están allí cuando pasas el mouse, solo están allí en la selección.

Bueno ... no podrías tener ningún control mostrado al pasar el mouse, pero creo que es seguro asumir que nadie realmente quiere eso. Sé que ciertamente me gustan los controles que están disponibles al pasar el mouse.

De todos modos, ¿qué tal la transparencia?

Y si quieres soñar un poco y deseas que backdrop-filter se haya implementado en todos los navegadores principales, puedes agregar algo de desenfoque:

Esto es un 60% de opacidad, por cierto.

La opacidad definitivamente ayuda, pero no estoy seguro de introducir opacidad en la ecuación. Se siente un poco como hacer trampa.

@chrisvanpatten De hecho, se siente un poco como una trampa ... pero ¿qué otras opciones tenemos?

No podemos dejar los controles a un lado, por lo que este problema existe en primer lugar.

No podemos poner los controles dentro del bloque, porque eso cubriría el contenido.

No podemos poner los controles en la parte superior debido a que la barra de formato ya está allí y los problemas que se producirían con los bloques delgados.

Poner los controles en la parte inferior tiene más sentido, ya que funciona mejor para la accesibilidad, proporciona un lugar conveniente para colocar tanto el insertador hermano como el mango de arrastre y resolver problemas relacionados con ellos, es más consistente con dispositivos móviles y funciona mejor para personas delgadas. bloques.

Para reducir el espacio que ocupa la barra inferior, solo hay algunas cosas que podríamos hacer:

• Disminuye la altura de la barra.
• Elimine el espacio vacío entre el insertador / los motores / el control de arrastre y la elipsis.
• Empuje la elipsis hacia la izquierda y elimine el espacio adicional a la derecha.
• Haz que ocupe espacio cuando se selecciona. (Pero no quieres esto).

Aparte de eso, todo lo que se puede hacer es hacerlo semitransparente para que se sienta visualmente más ligero y que sea más fácil ver lo que hay debajo.

Otro pensamiento: tal vez lo de la transparencia no se sentiría como una trampa si _ambas_ barras de herramientas fueran transparentes en lugar de solo la inferior.

Hice algunas maquetas más para probar algunas de las cosas mencionadas anteriormente.

Barras de herramientas transparentes:

Sin transparencia:

Creo que lo prefiero sin transparencia. ¿Qué piensas? Creo que reducir el ancho de la barra inferior ha resuelto el problema de superposición del inicio del siguiente bloque. Por supuesto, todavía sucederá en anchos más pequeños ... pero eso ya sucede con la barra de herramientas de formato de todos modos, así que no creo que realmente sea un problema aquí.

También observe que dejé un poco de espacio para un control de arrastre. Podría tener pequeños puntos en gris que se usan a menudo en aplicaciones para representar controles de arrastre, o podría tener un icono de arrastre que se muestra al pasar el mouse o todo el tiempo. O simplemente podría permanecer en blanco. Técnicamente, también podría ser un poco más delgado, pero lo dejé del ancho de un botón para mayor comodidad.

¿Podría ser esto? ¿Podría ser esta la iteración lo suficientemente buena como para reemplazar la actual? _ (Por favor diga "sí".: Atascado_out_tongue :) _

Gracias a todos por todas las exploraciones realizadas aquí. Saltar solo para agregar una razón más por la que la semitransparencia no es ideal: la relación de contraste de los iconos con el fondo debe ser de 4.5: 1. Usar la semitransparencia lo haría imposible, solo piense en una imagen con colores oscuros predominantes, o un párrafo con un fondo oscuro, o un tema con un fondo oscuro:

Gracias a todos por la excelente discusión aquí. Es alentador y delicioso ver la pasión con la que se aborda este desafío.

He estado observando un poco desde lejos, habiendo diseñado la configuración inicial del bloque, con una barra de herramientas acoplada, las flechas arriba / abajo en el costado y, finalmente, los puntos suspensivos a la derecha. Agregué los ingredientes porque sentí que era muy útil brindar a las empresas de mudanzas un espacio privilegiado como alternativa al arrastrar y soltar, que a menudo es complicado y propenso a errores, mientras que las de las empresas de mudanzas son siempre predecibles en su comportamiento.

Reconozco completamente los desafíos que esto plantea para los bloques anidados, y he pensado durante mucho tiempo cuál era la mejor solución. Lo que hay en el maestro, superpuesto a la izquierda y la derecha incluso si está anidado, funciona, pero tampoco es genial, lo reconozco. Otra opción es usar la interfaz de usuario móvil: mostrar la interfaz de usuario debajo del bloque cuando se selecciona, que está simulada en varias variantes aquí, funciona, especialmente para dispositivos móviles. Pero en el escritorio puede volverse muy perturbador y nervioso cuando solo desea seleccionar un párrafo para hacer una pequeña edición y todo salta. De manera similar, si la barra de herramientas se superpone como en la última versión, parece que se aleja demasiado de la experiencia de escritura, hacia la experiencia de diseño. Este es el equilibrio constante que hemos intentado lograr.

Una segunda opción es volver a las viejas maquetas que tenía, esta:

Quizás con algunos ajustes, podría ser esto:

Pero eso no me encanta. Y _o_ esto haría que los motores sean visibles solo cuando el bloque está suspendido, o querríamos modificar un poco el tratamiento. También hace que las áreas de pulsación del botón sean varios píxeles más pequeñas, lo que no es excelente para la usabilidad.

Como tal, esas variantes no se han considerado hasta ahora porque no se sentían superiores a lo que teníamos. Sin embargo, publicar aquí independientemente en caso de que puedan inspirar tratamientos para que funcione.

El mayor problema que veo al combinar las herramientas de bloque con la etiqueta flotante es que crea una inconsistencia entre un bloque seleccionado y uno suspendido, a menos que desee comenzar a mostrar la etiqueta de los bloques seleccionados también. Y si lo hace, la etiqueta no debe estar dentro de los bordes del bloque, sino fuera de él.

Pero incluso si hace eso, se encontrará con los problemas de tener demasiados controles en la parte superior del bloque y tener que averiguar cómo hacer que sea consistente tanto para bloques anchos como delgados.

Creo firmemente que, con la excepción de las barras de herramientas adhesivas que permanecen en la pantalla, ninguna de las IU estándar del bloque seleccionado debería cubrir ninguna parte de ese bloque.

Tener las herramientas de bloque en la parte inferior proporciona un buen lugar para colocar el insertador hermano, lo que ayuda a lograr el objetivo anterior de no superposición, al mismo tiempo que hace que el insertador hermano sea más visible y resuelve sus propios problemas de superposición. (Creo que la actualización de los bloques anidados al bloque Quote aún no ha sucedido debido a la superposición de insertadores hermanos).

Debido al insertador hermano y los beneficios de accesibilidad, creo que estar debajo del bloque es el mejor lugar posible para colocar las herramientas del bloque.

Ahora, no pensé que hacer los controles mucho más pequeños estaba sobre la mesa, ya que hacerlos más pequeños puede hacerlos más difíciles de usar, por supuesto. Sin embargo, dado que no parece estar en contra, ¿por qué no intentarlo?

¿Cómo es esto?

Los botones en la barra inferior (pero no los íconos) se han reducido en tamaño de 38px a 32px, y arreglé una inconsistencia en el espacio entre los controles de movimiento de las maquetas anteriores. Tenga en cuenta que podría hacerlo un poco más pequeño horizontalmente si el botón de puntos suspensivos fuera más delgado que los demás (como el de la barra superior del editor).

También puede reducir el tamaño del área de control de arrastre vacía para que la barra ocupe aún menos espacio. Esto sería aún más viable si todos los controles en la barra se duplicaran como controles de arrastre, como funcionan las barras superiores de las ventanas en GNOME.

Tenga en cuenta que en dispositivos móviles, los controles probablemente se verían casi exactamente como en master , donde las barras ocupan espacio y, por lo tanto, hacerlas más grandes no es un problema. Esta reducción de tamaño solo debería afectar a los usuarios de escritorio, y los controles aún se pueden usar al tacto con este tamaño.

También hice una pequeña exploración moviendo los controles a una barra de herramientas superior, lo que resuelve un conjunto de problemas ... pero cuando seleccionas el bloque, vuelves a tener una barra de herramientas Todo que no funciona en contextos estrechos, que era una razón significativa para esta exploración en primer lugar.

Todavía estoy tratando de averiguar cómo me siento con esas últimas maquetas. Los controles que cuelgan de la parte inferior me parecen un poco incómodos. No estoy seguro de tener una idea mejor, es solo que nos devuelve a ese tipo de sensación de bloques / fragmentados que @karmatosed quería evitar.

Gracias a todos por todo el trabajo aquí. Voy a intentar dar algunos comentarios, pero debo decir que ahora mismo no creo que esté listo para pasar al prototipo. Sigo pensando que hay problemas con el anidamiento y también diferentes dispositivos que resolver, pero como mencioné en comentarios anteriores, no creo que la pista actual sea la correcta. Siento que también estamos regresando al territorio que ya sugerí que evitáramos en esto.

No quiero desalentar la exploración, pero en este momento sugeriría considerar pensar en sugerencias alternativas. El gran problema es que agregar medias pestañas en la parte inferior aumenta la densidad visual sin ganancia. Pensemos en lo que estamos tratando de resolver aquí:

• Qué sucede en diferentes dispositivos.
• Inserción de hermanos (aunque esto podría solucionarse en otros problemas) o al menos cómo interactúa.
• Visibilidad de anidamiento y facilidad de interacción.

El impulso principal de todo esto fue cómo respondió y anidando.

Consideremos en lo que creamos si estamos aumentando o disminuyendo la usabilidad. Por ejemplo, usar cosas como transparencias y capas si bien está bien para alguien con visión normal, no lo hace mejor para muchas otras personas. Piense en diseños complejos, con videos y muchas imágenes. En esta densa estructura de información, lo que se sugiere no se sostiene.

Piense en diseños complejos, con videos y muchas imágenes. En esta densa estructura de información, lo que se sugiere no se sostiene.

Sí, creo que este es el punto más importante, y agregaría que la densidad realmente se _compone_ en espacios más pequeños, que es otra parte del desafío. Los bloques anidados generalmente necesitan los mismos controles que los bloques no anidados, pero deben hacerlo con una fracción del espacio, e idealmente de una manera no única (por ejemplo, los bloques anidados generalmente deben parecerse a los bloques no anidados; la consistencia engendra usabilidad).

De vuelta a la mesa de dibujo ... 🙂

Por qué creo que mi maqueta es mejor que la interfaz de usuario actual

Entiendo el deseo de evitar una apariencia en bloque, pero todavía tengo que encontrar algo que no tenga apariencia de bloque, pero igualmente funcional. El problema es que necesita conocer los bordes del bloque en el que está trabajando, y desea que los controles no cubran el contenido del bloque y que cubran una pequeña parte del exterior del bloque. Eso garantiza un aspecto un tanto en bloque.

Con solo mirar la captura de pantalla en la parte superior de este problema, puede ver cómo Gutenberg en un momento tenía una interfaz de usuario de bloques sin bloques. Pero el problema con esa interfaz de usuario era que era difícil saber dónde estaban los bordes de un bloque. Es por eso que tenemos la interfaz de usuario que tenemos ahora.

Y cuando presenta los problemas con el insertador hermano, se da cuenta de que necesita hacer que el botón del insertador hermano esté fuera del borde de contenido del bloque. Combine eso con el punto de que generalmente desea insertar bloques después del actual (en lugar de antes) y también el deseo de una mayor accesibilidad, y terminará teniendo que tener algo como mi última maqueta.

Personalmente, preferiría esta interfaz de usuario en bloques sobre algo que se parece a las primeras maquetas. Esas primeras maquetas parecen confusas debido a la falta de un límite entre el contenido y los controles, y las barras consumen mucho espacio innecesario. Como no queremos saltar la IU, la barra inferior tiene que ser una superposición sobre el contenido fuera del bloque seleccionado, por lo que debería ser lo más pequeña posible.

Además, creo que mi maqueta es definitivamente mejor en contextos anidados que la actual. Como explicaré a continuación, las situaciones de contenido / barras de herramientas superpuestas son mejores con esta interfaz de usuario que con la anterior. Y en contextos anidados, necesita conocer aún más los bordes de un bloque, por lo que un aspecto un tanto en bloque ayuda en esta situación.

Las barras de herramientas superpuestas son mucho menos confusas y menos propensas a ser un problema, ya que es mucho menos probable que los bloques sean verticalmente pequeños en pantallas pequeñas , en comparación con la probabilidad de que sean horizontalmente pequeños en pantallas pequeñas, lo que causó problemas con cosas como el bloque Columnas. . Cuando un bloque de texto se vuelve más delgado, su texto se ajusta y se vuelve más alto.

En contextos anidados, pasar el cursor sobre el bloque sobre el actual casi nunca cubrirá todo el contenido del bloque de abajo, porque o el bloque será lo suficientemente ancho como para que la barra inferior no lo cubra todo, o de lo contrario el bloque sería bastante de alto, por lo que todavía tendría espacio para seleccionarlo.

Además, la barra inferior de un bloque solo debería aparecer cuando colocas el cursor sobre el bloque, y no solo cuando el mouse está cerca de él. Debido a los extraños e invisibles controles de arrastre a los lados de los bloques, ese no es el caso de la interfaz de usuario actual.

Para agregar al punto anterior, es solo el bloque arriba del actual el que puede cubrir cualquier cosa en el bloque seleccionado. Los otros 3 lados están completamente bien, ya que colocar el cursor sobre un bloque adyacente horizontalmente no cubrirá nada en el bloque actual, y los bloques flotantes no tienen UI encima de ellos, por lo que colocar el bloque debajo del seleccionado también está bien.

Además, simplemente puede optar por no hacer que los bloques flotantes nunca cubran el seleccionado actualmente, y eso daría como resultado literalmente cero problemas de superposición con el bloque seleccionado en contextos anidados. Dado que los bloques flotantes solo tienen una barra en la parte inferior, el que está debajo del actual nunca se superpondrá al seleccionado. Lo único a lo que renuncias en esta situación es la capacidad de acceder a las herramientas de bloqueo para el bloque por encima del actual a menos que lo selecciones.

Otra idea más: la barra inferior podría ocultarse automáticamente cuando el cursor se desplaza sobre otro bloque. No volvería hasta que el cursor se moviera nuevamente hacia los bordes del bloque. Esto podría ayudar aún más en contextos anidados.

Además de todo eso, si aún desea menos problemas de superposición en contextos anidados, puede acoplar la barra de herramientas de formato a la barra superior del editor. (Esto no tiene ningún efecto en los dispositivos móviles, pero en los dispositivos móviles las barras ocupan espacio y no se superponen, por lo que no hay problemas de superposición en primer lugar).

En general, creo que hay más situaciones mejoradas con mi última maqueta que situaciones que empeoran.

Tal como están las cosas, creo que algo como mi maqueta (o cerca de ella) resuelve muchos más problemas de los que crea. Además de lo anterior, los beneficios incluyen:

• Funciona para todos los anchos de bloque.
• Mejor accesibilidad para insertador hermano, controles de movimiento y puntos suspensivos.
• Mejor visibilidad y capacidad de detección para el insertador hermano y el asa de arrastre.
• Las áreas de arrastre en el costado del bloque se pueden eliminar, y la etiqueta flotante no tiene que convertirse en un controlador de arrastre (es algo pequeño de todos modos).
• El insertador hermano está debajo de los bloques, que es donde normalmente desea usarlo (a diferencia de arriba).
• No se necesita una interfaz de usuario de inserción de hermanos separada, lo que reduce la complejidad.
• El insertador hermano ya no tiene problemas de superposición en contextos anidados. (Creo que esa es la razón por la que el número 6520 aún no ha sucedido).
• La interfaz de usuario del bloque que rodea un bloque nunca se superpone al contenido de ese bloque.
• Los márgenes automáticos de los bloques podrían eliminarse, y un bloque podría no tener ningún relleno interno, y los bordes de la interfaz de usuario del bloque podrían cambiarse de nuevo a los bordes del contenido real y, sin embargo, ningún control superpondría nada en el contenido del bloque. Este tipo de casos extremos se producirán con bloques personalizados, por lo que es bueno tenerlos en cuenta.
• Todas las herramientas de bloque están bastante juntas, lo que hace que sea más fácil llegar a todas y descubrirlas todas, en comparación con la situación anterior de los puntos suspensivos y los motores de flecha en lados opuestos del bloque.
• Está muy claro a qué bloque están conectados los controles, en comparación con la confusión que a menudo se obtiene con los controles actuales en contextos anidados.
• Los controles son más consistentes con el móvil.

Así que sí, creo que mi maqueta funciona mejor en contextos anidados, y creo que la interfaz de usuario en bloques no es importante en comparación con lo que obtienes. ¿Qué piensas? Si no está de acuerdo, ¿podría señalar situaciones en las que la maqueta sería significativamente peor que la interfaz de usuario actual y ninguna de las sugerencias mencionadas anteriormente la resolvería?

Hay ... otra ... ~ Skywalker ~ idea

Si todo lo demás falla, tengo una idea que técnicamente solucionaría todos los problemas principales. ¿Qué pasaría si la barra de herramientas de formato siempre estuviera acoplada en la parte superior como estaba en Gutenberg 1.6, pero esta vez los controles de movimiento y los puntos suspensivos se mostrarían encima de los bloques en lugar de a los lados? (Alternativamente, podría tenerlos en la parte inferior como mi maqueta).

En este concepto, el insertador hermano no existiría, porque el insertador en la barra superior del editor cumpliría la misma función, y en este contexto estaría más cerca ya que la barra de herramientas de formato estaría en la misma área.

La interfaz de usuario móvil sería exactamente la misma que en este momento. Este cambio solo afectaría a los usuarios de computadoras de escritorio (y tal vez tabletas).

¡Pero espera hay mas!

En realidad, si lo piensas, ¿cuál es la diferencia entre esta idea y simplemente tener mi maqueta y habilitar Fix Toolbar to Top ? Lo único que gana al eliminar las barras de herramientas de formato en línea por completo desde el móvil es la capacidad de tener los controles de movimiento y puntos suspensivos que se muestran arriba de los bloques en lugar de debajo. Y técnicamente, eso podría ser solo parte de la opción Reparar barra de herramientas en la parte superior .

Compare con la interfaz de usuario actual, donde Reparar barra de herramientas en la parte superior no elimina todos los problemas de control superpuestos, ya que la interfaz de usuario lateral todavía está dividida entre dos lados y los confusos controles invisibles de arrastre todavía están allí, y los insertadores hermanos aún se superponen en contextos anidados. y etc.

¿Está definitivamente escrito en piedra para el futuro que cada párrafo de texto sea un bloque separado? Si es así, la visualización de las herramientas de bloque debería tener en cuenta la selección de múltiples bloques de texto (que creo que llegará en algún momento).

@padraigobeirn Ese es un buen punto que me había olvidado.

En particular, los controles de la interfaz de usuario actual no tienen en cuenta las selecciones largas. Los controles de movimiento y los puntos suspensivos permanecen en la parte superior izquierda y derecha del primer bloque de la selección. Incluso la barra de herramientas de formato solo está fija para el primer bloque de la selección. Ver # 7962.

Para la barra inferior en mis maquetas, teóricamente podrías hacer que funcione con múltiples selecciones manteniéndola pegada en la parte inferior de la pantalla cuando te desplazas hacia arriba. Sin embargo, este comportamiento pegajoso solo puede ser deseable para los bloques seleccionados.

Sabes, realmente estoy empezando a pensar que Fix Toolbar to Top debería estar activado de forma predeterminada.

Tal como están las cosas, realmente hay mucho que puede hacer para ajustar tantos controles alrededor de un bloque, e incluso con mis últimas maquetas, todavía hay casos en los que la interfaz de usuario podría sentirse abarrotada. También existe la preocupación de que la interfaz de usuario se sienta demasiado bloqueada.

Para resolver estos problemas, creo que el ajuste predeterminado de la barra de herramientas de formato en la parte superior debería ser. Ahorra espacio alrededor de una gran parte del bloque y reduce drásticamente la cantidad de posibles superposiciones de controles.

Creo que todavía prefiero que los controles de movimiento y los puntos suspensivos estén en la parte inferior, pero también se pueden mover hacia la parte superior cuando la barra de herramientas de formato está acoplada. No tener la barra de herramientas de formato adjunta al bloque permitiría que la barra de herramientas del bloque se colocara en la parte inferior derecha o en la parte superior derecha también, sin parecer incómodo o ocupar demasiado espacio.

Sin embargo, creo que preferiría abajo a la izquierda o abajo a la derecha. De esa manera, los controles vienen después del bloque tanto visualmente como en orden de tabulación, lo que tiene más sentido para mí. Lanzar el insertador hermano allí después de un bloque tiene más sentido que hacer que aparezca antes de un bloque.

Nota al margen: Recientemente noté que el creador de correo electrónico en Infusionsoft en realidad tiene su propio concepto de "bloque", y tiene herramientas de bloqueo (duplicar y eliminar) que se muestran arriba de los bloques en la parte superior derecha. Los controles de formato aparecen en una barra en la parte superior del editor cuando el cursor ingresa a un área de texto.

Recientemente me di cuenta de que el creador de correo electrónico en Infusionsoft en realidad tiene su propio concepto de "bloque", y tiene herramientas de bloqueo (duplicar y eliminar) que se muestran arriba de los bloques en la parte superior derecha. Los controles de formato aparecen en una barra en la parte superior del editor cuando el cursor ingresa a un área de texto.

¿Podrías recortar algunas capturas de pantalla de esa interfaz @SuperGeniusZeb?

Cuando comencé a usar Gutenberg, definitivamente era una persona que "arreglaba la barra de herramientas en la parte superior", pero después de haberlo usado durante un tiempo, no estoy seguro de querer volver. Reconozco totalmente que la barra de herramientas de muchas maneras es la causa de todos estos problemas; es más probable que tenga muchas cosas que se cortan en contextos anidados y ocupan espacio que podría usar para los controles laterales, pero tenerlo emparejado con el bloque es tan agradable. Mantiene todo lo que necesitas en un solo lugar, evita mucho movimiento de los ojos y del mouse, etc. Me sorprende decirlo ahora, pero creo que es algo sin lo que no podría vivir.

¿Podrías recortar algunas capturas de pantalla de esa interfaz @SuperGeniusZeb?

@chrisvanpatten No, solo tuve acceso temporal mientras ayudaba a alguien.

Realmente no me siento muy bien de ninguna manera en las barras de herramientas de formato fijo / no fijo, pero me inclinaría por fijo ya que ayudaría a reducir el desorden visual alrededor de los bloques. Según los comentarios de los usuarios, ¿qué prefieren otras personas y por qué?

@chrisvanpatten Encontré un artículo donde alguien habla sobre el

https://www.monkeypodmarketing.com/the-new-email-builder/

@chrisvanpatten Argh, acabo de verificar y parece que el video está desactualizado ... parece que en ese entonces la barra de herramientas de formato estaba adjunta a los bloques, como lo que hace Gutenberg en este momento. Sin embargo, es interesante que lo hayan cambiado.

Algunos pensamientos:

Si vas a insertar un bloque en medio de un post, normalmente querrás hacerlo _ después_ del que has seleccionado, ¿verdad? Por lo general, no desea insertar _antes_ el bloque seleccionado. Insertar después de un bloque también tiene sentido desde una perspectiva de accesibilidad. ¿Alguien no está de acuerdo con esto? Para mí, esto parece un fuerte argumento a favor de que aparezcan insertadores hermanos en algún lugar cerca de la parte inferior de un bloque.

Los insertadores hermanos no deben superponerse al contenido del bloque seleccionado. Nada debe superponerse permanentemente al contenido del bloque seleccionado. ¿Alguien no está de acuerdo con esto? Esto me lleva a creer que los insertadores hermanos deben colocarse fuera del contenido del bloque seleccionado.

Señalo esto porque creo que independientemente de dónde deberían ir los controles de movimiento y los puntos suspensivos, el insertador hermano parece tener que aparecer en una especie de barra de herramientas debajo del bloque seleccionado, incluso si está solo y / o la barra de herramientas tiene sin borde / fondo. Supongo que podría verse casi exactamente como lo hace ahora, pero se movió hacia abajo y cambió para aparecer debajo de los bloques, en lugar de encima de ellos.

Otro pensamiento: ¿sería una mejora con respecto a master poner los puntos suspensivos en el mismo lado que las flechas de movimiento o viceversa? Eso podría resolver muchos de los problemas con controles superpuestos en contextos anidados, a costa de tener una mayor cantidad de IU de bloque en el lado izquierdo (o derecho) de un bloque.

Acabo de probar el # 8836. Creo que si se fusionara, podría ayudar a reducir los problemas de IU pesados ​​/ bloqueados que parecen tener muchos de los diseños de IU en este ticket.

En los tickets # 9074 y # 9075, sugiero dos pequeños pasos, inspirados en esta discusión, para mitigar y mejorar la situación. En el primero, la sugerencia es que movamos el botón Elipsis / Más a la barra de herramientas, por lo que solo tenemos una parte de la interfaz de usuario lateral (desplazamientos), y en el otro hay una propuesta para permitir que la barra de herramientas del bloque colapse las secciones para encajar mejor contextos delgados.

Solo para mantenerlos actualizados, actualicé mis maquetas para tener en cuenta los cambios propuestos por los tickets de

En realidad, es posible que ya no sea necesario mover las flechas debajo de los bloques si se implementan los números 9074 y 9075. Podría estar bien si permanecen en el lado del bloque, ya que los puntos suspensivos de los bloques adyacentes ya no los superpondrían en cosas como columnas. Si existieran soluciones para # 8880, # 8881 y # 8883, y si se implementaran # 8836 y # 8920, entonces quizás la interfaz de usuario ya estaría bien para contextos anidados. Estoy empezando a inclinarme hacia que esté bien que las flechas arriba / abajo permanezcan en el lado izquierdo del bloque.

Dicho esto, sigo pensando que el insertador hermano definitivamente pertenece debajo de los bloques , aunque definitivamente podría hacer que el insertador hermano aparezca solo debajo de los bloques. Quizás podría estar centrado como el insertador hermano actual, pero actúa y se ve como los controles de movimiento hacia arriba / abajo, apareciendo como un botón flotante debajo de los bloques cuando estás flotando dentro de la parte inferior de un bloque.

Centrémonos en obtener las iteraciones en las que @jasmussen está trabajando en # 9074 y # 9075, luego podemos considerar los siguientes pasos. Tengo ganas de cambiar muchas cosas, pero equilibremos.

Gracias a los mencionados # 9074 y # 9075, así como a otros problemas y relaciones públicas como # 8920 y # 9197, he decidido que mover las flechas debajo del bloque ya no tiene muchos beneficios.

En su lugar, ahora propongo que solo el insertador hermano se mueva debajo del bloque, actuando y apareciendo como un control flotante similar a los motores arriba / abajo. Ver # 9202.

Cerremos esta por ahora, ya que han surgido muchas mejoras de esta y otras discusiones. Los últimos refinamientos que se deben realizar están relacionados con el insertador final.