Gutenberg: Controles de respuesta específicos de bloque

Compartiré algunas exploraciones iniciales sobre este tema.

El bloque que necesita con mayor urgencia controles sensibles en este punto es el bloque de columnas. Actualmente, las columnas se apilan automáticamente en pantallas pequeñas, sin ninguna indicación de que eso suceda. El bloque de medios y texto también se puede apilar en dispositivos móviles, pero incluye un interruptor de palanca para activar o desactivar ese comportamiento. Esta es una excelente línea de base para controles receptivos:

Para muchos usuarios, esta opción ofrece un control más que suficiente: es razonable suponer que un creador de sitios web moderno puede manejar todo esto automáticamente si se lo pedimos. Pero deberíamos ofrecer algún nivel de control ajustado para aquellos usuarios que deseen especificar cuántas columnas deben aparecer en varios puntos de interrupción.

Con eso en mente, construí mi exploración alrededor de un par de ideas centrales:

1. Los controles sensibles deben vivir en el panel "Avanzado". Este panel está actualmente muy infrautilizado, pero parece un hogar razonable para configuraciones receptivas. Deberíamos establecer buenos valores predeterminados y, en la mayoría de los casos, el usuario ni siquiera visitará este panel.
2. Permita 3 opciones diferentes :
   A. Nuestro valor predeterminado inteligente: apilar columnas en dispositivos móviles.
   B. Use el mismo número de columnas en todas partes.
   C. Especifique recuentos de columnas para tamaños de pantalla de dispositivos móviles, tabletas y computadoras de escritorio.

Con eso en mente, construí un par de prototipos:

Prototipo de escritorio (Figma)
Prototipo móvil (Figma)

_Capturas de pantalla para referencia: _

Como notará cuando haga clic: cuando haya seleccionado la opción (C), las únicas opciones de dispositivo que se muestran en el panel "Dispositivos" son los dispositivos que _no_ está usando. Si está en un teléfono, el control deslizante predeterminado debajo de "Columnas" controlará la cantidad de columnas que verá en un dispositivo móvil. Si mantiene la opción (C) seleccionada y accede a este bloque desde una máquina de escritorio, el control deslizante predeterminado controlará la cantidad de columnas que verá en una vista de escritorio. Esto evita la duplicación de controles que hacen lo mismo, pero no estoy totalmente seguro de si es intuitivo o confuso. Una alternativa sería mostrar todos los dispositivos allí abajo y deshabilitar el control deslizante predeterminado cuando se selecciona la opción (C), pero eso me pareció extraño.

¡Estoy interesado en recibir comentarios! También tengo curiosidad por saber cómo este tipo de controles podrían extenderse a otros tipos de configuraciones: ¿Qué otros bloques se beneficiarían con controles sensibles como este?

Recientemente, he estado creando un tema bastante amplio para el lanzamiento de un proyecto de trabajo en las próximas semanas. Pensé que probablemente debería compartir algunos de mis pensamientos. El siguiente panel es lo que he implementado para manejar columnas apiladas en varios dispositivos. Cada dispositivo puede tenerlo configurado explícitamente y también tener el orden invertido. (Usando flex para columnas css).

La parte superior (margen / relleno) también está disponible en todos los bloques. Permitiéndonos crear algunos diseños bastante fantásticos completamente desde el editor.

Lo que me encantaría ver son los botones de escritorio / tableta / móvil disponibles en la parte superior del editor para cambiar el editor a los modos respectivos sin cambiar el tamaño de la ventana. Esto permitiría una construcción muy rápida para todos los niveles de respuesta. Si bien esos tres modos funcionan para mis propósitos, potencialmente se podría configurar un rango de niveles de respuesta en el tema que le permite cambiar entre cualquiera de ellos.

Como ya no tenemos un editor basado en iframe, esto claramente requerirá un poco más de trucos para lograrlo. Habiendo pensado un poco en cómo podría lograr algo similar, me imagino que el editor no podría usar consultas de medios y, en cambio, css tendría que desarrollarse específicamente para el editor para cada bloque. Actualmente estoy haciendo esto de todos modos para mi propio tema. Si el div "editor-styles-wrapper" tuviera la respuesta actual agregada a la clase, podría sustituir fácilmente las consultas de medios por las respuestas basadas en la clase.
por ejemplo: .editor-styles-wrapper - mobile {}

Lo que me encantaría ver son los botones de escritorio / tableta / móvil disponibles en la parte superior del editor para cambiar el editor a los modos respectivos sin cambiar el tamaño de la ventana. Esto permitiría una construcción muy rápida para todos los niveles de respuesta. Si bien esos tres modos funcionan para mis propósitos, potencialmente se podría configurar un rango de niveles de respuesta en el tema que le permite cambiar entre cualquiera de ellos.

Gracias por compartir, @mattbolt. En caso de que no lo haya visto, estamos discutiendo exactamente ese tipo de cosas aquí: # 13203

En cuanto a las reglas de margen / relleno de respuesta: Me encantaría ver controles más ajustados para el margen + relleno. Pero para la mayoría de los usuarios, imagino que serían más beneficiosos a nivel global. Por eso los dejé fuera de mis exploraciones anteriores. Creo que definitivamente deberíamos incluir controles de margen / relleno en algún lugar, pero por bloque me parece un poco demasiado granular (al menos para el núcleo).

hola @mapk @kjellr - Dejé un comentario en el # 13203, pero creo que también vale la pena resaltar una parte en este número.

Este es el último prototipo en el que estamos trabajando; se basa en los comentarios que obtuvimos de nuestra reciente prueba de usabilidad que anoté en el n. ° 13203.

Figma

Nuestros bloques tienen algunas configuraciones diferentes, y no todas deben ser editables dispositivo por dispositivo. Como tal, creemos que colocar controles sensibles en configuraciones individuales tiene sentido. En el ejemplo anterior, los controles de respuesta para el diseño se pueden ajustar, pero el filtrado por categoría no. (el filtrado por categoría siempre debe aplicarse a todos los tamaños de dispositivo) También nos gustaría usar valores predeterminados inteligentes, para que la gente no tenga que entrar y ajustar el diseño para cada tamaño de dispositivo.

La primera parte de nuestra prueba se ejecutó utilizando bloques en vivo que no presentaban ningún control de diseño receptivo. Muchos de nuestros participantes hicieron preguntas como, "¿Cómo cambio esta configuración de diseño para dispositivos móviles?" Me lleva a creer que más personas querrán este tipo de control granular de lo que pensamos.

Poner controles de respuesta en la configuración avanzada es otra opción, sin embargo, creo que haría más difícil encontrarlo ... dado que es un problema de una sola vez: una vez que lo encuentra, sabe dónde buscarlo la próxima vez. hora. Dicho esto, también creo que hay algo en mantener los controles receptivos en el contexto de la configuración que un usuario también está ajustando.

No hemos tenido la oportunidad de probar esta última versión, pero esperamos hacerlo pronto.

@kjellr

¡Estoy interesado en recibir comentarios! También tengo curiosidad por saber cómo este tipo de controles podrían extenderse a otros tipos de configuraciones: ¿Qué otros bloques se beneficiarían con controles sensibles como este?

Realmente me gustó cómo tomaste algo tan complejo y lo simplificaste de una manera utilizable para que cualquiera lo entendiera. Otro bloque que podría beneficiarse es el bloque Gallery, que ya tiene algunos ajustes de columna rudimentarios.

@mattbolt

La parte superior (margen / relleno) también está disponible en todos los bloques.

¡Gracias Matt! Su exploración de los márgenes y el relleno también es buena para compartir aquí. # 11824

@LevinMedia

Muchos de nuestros participantes hicieron preguntas como, "¿Cómo cambio esta configuración de diseño para dispositivos móviles?"

¡Muy interesante!

Dicho esto, también creo que hay algo en mantener los controles receptivos en el contexto de la configuración que un usuario también está ajustando.

Esto tiene sentido en el contexto del bloque Woo que también permite ajustar el número de producto. ¿Crees que es necesario cuando solo hay un ajuste (es decir, columnas) como en las maquetas de @kjellr ?

Me doy cuenta de que la mayoría de las maquetas hasta ahora utilizan controles de solo iconos. Idealmente, para la accesibilidad (y usabilidad general), sería mejor si los controles sensibles tuvieran etiquetas visibles. No estoy seguro de cuán factible sea esto, pero solo quería señalarlo, ya que Gutenberg ha tenido problemas con la accesibilidad en varias áreas, y sería una buena idea intentar evitar agregar más IU solo de íconos.

Otra cosa que tendremos que considerar son las opciones de la barra de herramientas que pueden requerir configuraciones receptivas. Por ejemplo, la función de ancho de bloque que se encuentra en el bloque Cubierta. Es posible que desee un ancho reducido en el escritorio y un ancho completo en un dispositivo móvil.

Hola @mapk

¿Crees que es necesario cuando solo hay un ajuste (es decir, columnas) como en las maquetas de @kjellr ?

Hago. La capacidad de descubrimiento es una gran parte de esa razón para mí. Pone la configuración de respuesta directamente en el contexto de la configuración que se está manipulando.

Creo que habrá muchos casos en los que un bloque tiene múltiples configuraciones de respuesta, y no todas van a encajar perfectamente en un solo cubo como el diseño.

Por ejemplo, su segunda pregunta anterior.

¿Es necesario ocultar / mostrar bloques según el ancho del dispositivo?

En mi uso anterior de creadores de páginas, la respuesta a esa pregunta ha sido sí. Agregar una configuración de "Visibilidad" con sus propios controles sensibles permitiría eso.

En retrospectiva, es posible que la visibilidad no sea el mejor ejemplo en este caso, ya que algo así probablemente sería más adecuado como una simple lista de conmutadores.

[alternar] Mostrar en el escritorio
[alternar] Mostrar en tableta
[toggle] Mostrar en el móvil

Muchos de nuestros participantes hicieron preguntas como, "¿Cómo cambio esta configuración de diseño para dispositivos móviles?"

@LevinMedia Quería dar seguimiento a este hallazgo: ¿puede compartir más detalles sobre el grupo de usuarios que formaron parte de esta prueba? Este hallazgo me sorprendió un poco, así que me gustaría saber más. ¡Gracias!

Creo que una consideración clave aquí es nuestra expectativa de cuánto impacto tendrá la manipulación receptiva en la experiencia general de creación. No solo ahora, sino también en el futuro.

¿Cuál debería ser la configuración predeterminada para los bloques? ¿Escritorio, móvil, tableta?

Esa pregunta es lo más importante para mí en este momento. Me gusta mucho el diseño de @mapk mencionó anteriormente, pero no estoy seguro de qué tan bien pasaría a una experiencia de "primero móvil".

Como dijo @LevinMedia , la mayoría de los participantes en nuestras recientes pruebas de usabilidad ya mostraron un gran interés en la configuración móvil y declararon que era "muy importante" para ellos. Por supuesto, debe decirse que existe cierto sesgo, ya que cada participante era un usuario de WooCommerce y quizás más "experto en tecnología" que otros usuarios.

Mi inclinación en este momento es estar de acuerdo con @LevinMedia : el contexto será de vital importancia aquí. Creo que debería ser muy fácil para los usuarios encontrar estas configuraciones y comprender lo que hacen.

En una nota relacionada, personalmente no me gusta la sección "Avanzada" del panel de configuración, para casi cualquier caso de uso. Me parece arbitrario y, literalmente, no tengo ninguna expectativa sobre qué configuraciones podría encontrar allí cuando interactúe por primera vez con un bloque.

Esa pregunta es lo más importante para mí en este momento. Me gusta mucho el diseño de @mapk mencionó anteriormente, pero no estoy seguro de qué tan bien pasaría a una experiencia de "primero móvil".

En este sentido, una de las consideraciones en mi enfoque anterior es que es consciente de la pantalla desde la que está editando. En otras palabras, el dispositivo en el que está es el que está diseñando "primero". Si visita desde un teléfono móvil, el único control deslizante que verá en el área principal es el control deslizante móvil. El resto está en Avanzado. O, si lo visitó desde una tableta: la tableta se mostraría como el control predeterminado y las otras se mostrarían abajo. Esto podría terminar siendo confuso: dividir los controles entre el panel de la barra lateral normal y Avanzado me parece un poco extraño, como mencioné originalmente en mis notas anteriores.

Pero, en general, me gusta la idea general de ser consciente de los dispositivos. En las maquetas que @LevinMedia publicó, eso equivaldría a seleccionar de forma

Pasé un poco de tiempo pensando en una dirección ligeramente diferente para esto. Una cosa que no me ha sentado bien de mi iteración anterior fue cómo separé los controles de las columnas entre el panel "Columnas" de la barra lateral principal y el panel "Avanzado".

Esta exploración simplifica un poco las opciones y vuelve a mover todo al área principal de "Columnas":

🖥 Prototipo de escritorio

📱 Prototipo móvil

El primer cuadro simplemente agrega la opción "Apilar en el móvil" que tenemos actualmente disponible para el bloque de Medios y Texto. De forma predeterminada, está activado y todo se gestiona automáticamente. Esta es la mejor configuración para los usuarios que no desean administrar esta configuración. Sin embargo, a diferencia de hoy, si un usuario desactivara eso, se le presentarían controles más ajustados allí. A partir de aquí, pueden dejarlo solo (por defecto, el mismo tamaño para cada uno), o ajustar para establecer un recuento de columnas diferente para cada tipo de dispositivo.

Algunas consideraciones:

• Generalmente, esto necesita un mejor etiquetado + descripciones.
• Esto funciona bien para una opción, pero no se escalaría bien si hubiera varias configuraciones por punto de interrupción.
• Por lo general, no mostramos / ocultamos controles basados ​​en interruptores de palanca que están apagados. No estoy seguro de si eso realmente tiene sentido aquí.
• Relacionado con lo anterior: en cuanto a la jerarquía, parece extraño que un interruptor de palanca afecte los campos de arriba. En este caso, sería más natural liderar con el interruptor. Sin embargo, eso _también_ no se sentiría bien, porque lo principal que la gente querrá hacer aquí es ajustar el recuento de columnas, no alternar los controles de respuesta.

Una pregunta a la que sigo volviendo mientras exploro y leo los pensamientos aquí: ¿qué tan simple o complicado debería ser esto _en el núcleo? _ Algunos bloques personalizados incluirán ciertamente una tonelada de configuraciones individuales para cada punto de interrupción: margen, relleno, mostrar + ocultar bloques, etc. Eso puede ser con lo que su base de usuarios se sienta cómoda. Pero no necesariamente queremos incluir ese nivel de control en los bloques predeterminados, ya que puede resultar abrumador para un usuario novato. Dicho esto ... probablemente sea beneficioso para nosotros establecer patrones de diseño que puedan escalar a esos escenarios súper complicados, de modo que podamos ayudar a demostrar cómo se debe manejar esto en todos los casos. ¿Cómo podemos definir un patrón simple que se adapte a las personas que _no_ quieren tener que administrar la configuración de respuesta y las que quieren ser realmente específicas sobre estas cosas?

¡Bonitas maquetas, @kjellr!

Generalmente, esto necesita un mejor etiquetado + descripciones.

Como mínimo, los iconos del dispositivo deben moverse a las etiquetas de cada uno de los controles deslizantes, por ejemplo, "🖵 Escritorio".

Esto funciona bien para una opción, pero no se escalaría bien si hubiera varias configuraciones por punto de interrupción.

Creo que la respuesta a esto está en la palanca. ¿Qué pasaría si cada control de respuesta tuviera una palanca para habilitar / deshabilitar la personalización de la capacidad de respuesta de la configuración? Divi Builder tiene algo bastante similar a esto.

Relacionado con lo anterior: en cuanto a la jerarquía, parece extraño que un interruptor de palanca afecte los campos de arriba. En este caso, sería más natural liderar con el interruptor. Sin embargo, eso tampoco se sentiría bien, porque lo principal que la gente querrá hacer aquí es ajustar el recuento de columnas y no alternar los controles de respuesta.

Creo que preferiría tener el interruptor sobre los controles deslizantes, ya que cambiarlo afecta a los controles deslizantes.

Pero no necesariamente queremos incluir ese nivel de control en los bloques predeterminados, ya que puede resultar abrumador para un usuario novato.

Creo que muchas cosas podrían estar ocultas detrás de conmutadores como los de su maqueta por defecto, o simplemente manteniéndolos en acordeones cerrados por defecto. El margen y el relleno pueden estar en el mismo acordeón, y puede alternar la capacidad de respuesta de esos controles con conmutadores como en su maqueta. No creo que esto sobrecargue al usuario con opciones si este acordeón se coloca debajo de todas las opciones más comunes y está cerrado por defecto.

@kjellr : siguiendo el comentario de Jay. Teníamos un tamaño de muestra pequeño (ocho participantes), por lo que, como mencioné antes, definitivamente se justifican más pruebas / investigación.

Todos los participantes procedían del grupo de comentarios de diseño de WooCommerce.Como mencionó jay, nuestros participantes, y este grupo de participantes en particular, se inclinaron mucho hacia el perfil de constructor de experiencias / ensamblador de tiendas, en lugar de un propietario de tienda de bricolaje.

Un pequeño seguimiento de la maqueta que publiqué ayer :

🖥 Prototipo de escritorio

📱 Prototipo móvil

Después de analizarlo con ButtonGroup en lugar de un Toggle , junto con una copia (con suerte) más clara. Cambiar el formato y copiar de esta manera nos permite colocar de forma más natural el control encima del control de columnas. Eso se siente mucho más esperado jerárquicamente.

Una cosa que realmente me gusta de este enfoque es que sienta el precedente de que estos controles deben ser manejados por el bloque de forma predeterminada. Los diseñadores de bloques tendrán infinitamente más control que los usuarios, ya que podrán definir sus propios puntos de interrupción. Los diseñadores de bloques también tendrán mucha más experiencia con el diseño receptivo que muchos usuarios, y deberían poder aplicar las mejores prácticas aquí.

Además, si un usuario cambió a manual, hizo un montón de ajustes en la configuración del punto de interrupción y estropeó las cosas, la opción "Auto" es una vía de escape rápida para ellos.

Todavía hay algunas cosas extrañas que resolver aquí (por ejemplo, ¿quién elige estos puntos de interrupción exactos?). Pero este parece ser el tipo de configuración que puede escalar a configuraciones más complicadas , y creo que nos estamos acercando.

Me encanta, Kjell. Permite un valor predeterminado que es mejor en la mayoría de los casos, pero granularidad para quienes lo deseen. También se siente como un patrón que puede escalar desde el bloque de columnas a otros bloques, incluso a bloques de terceros. Bien hecho.

¡Muy bien, @kjellr!

Sigo pensando que cada uno de los controles deslizantes debería tener etiquetas textuales visibles por razones de accesibilidad y claridad, pero aparte de eso, creo que nos estamos acercando a poder implementar esta funcionalidad.

Además, en términos de accesibilidad, ¿estamos seguros de que un grupo de botones es más apropiado que un interruptor en este contexto?

Me gustan estos conceptos y funcionan bien para columnas, pero veo algunos pequeños problemas con ambos.

El concepto con la palanca es mi favorito de los dos, pero no será consistente en todas las configuraciones ya que la etiqueta será diferente cada vez. Por lo tanto, no será obvio de inmediato que la configuración tenga opciones móviles. Me preocupa la escalabilidad.

El concepto con el control segmentado me parece un poco extraño porque le estás pidiendo al autor que elija entre automático y manual antes de interactuar con la configuración de la columna. Eso no es lo que esperaría ver al abrir una sección de "columnas" en la configuración. Las etiquetas tampoco me parecen particularmente claras.

Estoy ansioso por escuchar más pensamientos sobre el concepto que @LevinMedia compartió anteriormente. Llegamos a esa solución después de una ronda de pruebas de usabilidad y parece bastante consistente con lo que están haciendo otros autores de bloques. ¿Hay alguna razón por la que descartamos ese enfoque?

Estoy ansioso por escuchar más pensamientos sobre el concepto que @LevinMedia compartió anteriormente. Llegamos a esa solución después de una ronda de pruebas de usabilidad y parece bastante consistente con lo que están haciendo otros autores de bloques. ¿Hay alguna razón por la que descartamos ese enfoque?

¡Por supuesto! No quise descartar esa solución. La clave que veo que falta en esa dirección es la presentación de una opción de "déjanos manejarlo". Si bien los usuarios más avanzados entrarán y editarán todo debajo de cada uno de esos íconos de dispositivos, eso será un _mucho_ de trabajo para un usuario de aviso. Especialmente cuando podíamos manejarlo automáticamente por ellos.

Aparte de eso, el quid de esa dirección es el control segmentado para dispositivos:

Creo que funciona bastante bien y podría ser un patrón para usar aquí, aunque si incorporamos un control segmentado encima, eso podría volverse extraño.

La clave que veo que falta en esa dirección es la presentación de una opción de "déjanos manejarlo".

Te tengo. Entonces, ¿la preocupación es que los conmutadores de tableta / móvil no se sienten opcionales? Eso tiene sentido. Pero creo que el control segmentado del dispositivo proporcionaría un patrón más consistente en diferentes tipos de configuración y, por lo tanto, escalaría mejor. La facilidad de uso frente a la coherencia y la escalabilidad es difícil.

Para probar estos conceptos un poco más, podría sugerir agregar otra opción debajo de las columnas, que también tendría un componente sensible: Filas.

Para probar estos conceptos un poco más, podría sugerir agregar otra opción debajo de las columnas, que también tendría un componente sensible: Filas.

Sí, me burlé de algo como esto rápidamente para probarlo. Técnicamente funciona, aunque se vuelve un poco repetitivo + prolijo:

Registrando otro concepto en el que

Prototipo de Figma

Cosas que me gustan:

1. Significa que el autor solo tiene que ajustar una única configuración, asumiendo que quiere que las cosas se manejen automáticamente.
2. Incluso en el "modo automático", aún pueden ver cuántas columnas obtendrán en el móvil, no hay ningún misterio.
3. Desvincular la configuración para un control completo está a un solo clic de distancia.

Cosas que no me gustan tanto:

1. Ocupa bastante espacio visualmente
2. No existe una opción simple de "apilar columnas en dispositivos móviles". Honestamente, no estoy seguro de si eso es un gran problema o no ...

Creo que prefiero la palanca estándar al botón de icono de enlace de cadena, porque es más fácil poner una etiqueta. Recuerde que la interfaz de usuario debe diseñarse teniendo en cuenta la accesibilidad.

Imagino que la interfaz de usuario podría verse así:

Recuento de columnas
(ON⚫) Ajusta automáticamente las columnas para dispositivos móviles.
――――― o― [__4]

Recuento de columnas
(⚫OFF) Ajusta automáticamente las columnas para dispositivos móviles.

🖥️Escritorio
――――― o― [__4]
⬛Tableta
――― o ――― [__3]
📱Teléfono
―O ――――― [__2]

Visibilidad
(ON⚫) 🖥️Mostrar en el escritorio
(ON⚫) ⬛Mostrar en tableta
(ON⚫) 📱Mostrar en el móvil

Técnicamente, el concepto de "enlace" es el mismo, el conmutador está visualmente en una ubicación diferente. Todavía podría revelarse a los lectores de pantalla de la misma manera y se podría agregar una información sobre herramientas como una etiqueta (aunque no estoy seguro de cuán accesibles son). También tiene el beneficio adicional de informar al autor cuántas columnas se utilizarán en pantallas pequeñas, incluso en el modo "automático", sin forzarlas a una vista previa. Quizás eso no sea tan útil, es difícil de saber sin probar.

Sin embargo, estoy de acuerdo en que este formato no funcionaría tan bien para la configuración de visibilidad. Vincular esas opciones juntas parece inútil. Pero para mí, esa configuración tampoco necesita el cambio automático / manual. Un solo interruptor de visibilidad por dispositivo tiene más sentido.

Técnicamente, el concepto de "enlace" es el mismo, el conmutador está visualmente en una ubicación diferente. Todavía podría revelarse a los lectores de pantalla de la misma manera y se podría agregar una información sobre herramientas como una etiqueta (aunque no estoy seguro de cuán accesibles son).

Las etiquetas visibles son siempre más accesibles. También debe tenerse en cuenta que el orden visual de los controles debe coincidir con el orden de las pestañas, y su orden de las pestañas debe seguir la arquitectura de la información ... lo que significa que los controles que usaría lógicamente primero aparecen antes que los que usaría después, y demás. los encabezados similares vienen antes de los párrafos que encabezan. Haciendo ping a

También tiene el beneficio adicional de informar al autor cuántas columnas se utilizarán en pantallas pequeñas, incluso en el modo "automático", sin forzarlas a una vista previa. Quizás eso no sea tan útil, es difícil de saber sin probar.

Este es definitivamente un gran beneficio, aunque no estoy seguro de si mostrar un montón de controles deshabilitados de forma predeterminada se ajusta a tratar de evitar que la interfaz de usuario se sienta abrumadora. Personalmente, no me molestaría, pero algunas personas sí.

¡Amo esta idea y discusión!

Parece que hasta ahora el enfoque de la discusión ha estado en la experiencia de usuario del administrador, como debería ser.
Sin embargo, me gustaría ofrecer algo de reflexión sobre la interfaz, el contenido primero y la web moderna.

Realmente no se puede vencer el paradigma de los 3 dispositivos cuando se trata de lograr que los usuarios habituales comprendan el "diseño receptivo". La cuestión es que 3 diseños para 3 dispositivos no es en realidad un diseño receptivo. Es un diseño adaptativo. Es el sueño imposible del píxel perfecto, que no existe en la web moderna. Es rígido, frágil, no está preparado para el futuro y no siempre produce lo que el usuario espera.

Todo el tiempo se lanzan nuevas funciones de CSS para alejarnos del diseño adaptativo y acercarnos a la capacidad de respuesta. rem , vw , flex , grid .

El diseño receptivo consiste en dejar que el contenido informe al diseño en lugar de permitir que el diseño dicte y comprometa el contenido.

Aquí hay una vista de columna de TwentyNineteen

Si el diseño de mi sitio requiriera 6 columnas de texto, preferiría que el diseño se vea comprometido un poco antes de que el ancho del párrafo sea inferior a, digamos, 150px.

Flexbox puede hacer que esto sea bastante automático. Pruébalo.

.wp-block-columns {
    display: flex;
    flex-wrap: wrap;
}

.wp-block-column {
    flex: auto;
    width: 100%;
    margin: 0 1rem 1rem;
}

.has-4-columns .wp-block-column {
    width: calc(100% / 4 - 2rem);
}

.has-6-columns .wp-block-column {
    width: calc(100% / 6 - 2rem);
}

.wp-block-column {
    min-width: 100px
}

Si bien lo que se ha discutido hasta ahora es excelente desde una perspectiva de UX:

Permita 3 opciones diferentes:
A. Nuestro valor predeterminado inteligente: apilar columnas en dispositivos móviles.
B. Use el mismo número de columnas en todas partes.
C. Especifique recuentos de columnas para tamaños de pantalla de dispositivos móviles, tabletas y computadoras de escritorio.

Me gustaría lanzar esto desde una primera perspectiva de contenido:

¿Quizás estas 3 opciones?
A. Smart predeterminado: ancho de columna mínimo de 200px (ish).
B. Especifique el número de columnas.
C. Modifique el ancho mínimo de columna en el que se empujará una columna a la siguiente línea.

Gracias por mencionar este tema, @meh. Tienes toda la razón en gran parte de esto, definitivamente también ha estado en mi mente.

La pieza más importante para mí es esta parte: nada supera el paradigma del dispositivo para que la gente comprenda el diseño receptivo. Ven los íconos y lo obtienen de inmediato. Configuraciones como "ajustar el ancho mínimo de columna en el que una columna se empujará a la siguiente línea" tienen sentido para nosotros, pero son mucho más abstractas y requerirán a los usuarios mucha más capacidad intelectual para resolverlas. Muchos profesionales luchan por comprender el verdadero diseño receptivo, por lo que debemos buscar la forma más sencilla de comunicar esto a los usuarios.

El verdadero diseño receptivo depende mucho del contexto y el contenido. Si bien 3 opciones como las que propuso pueden funcionar bien para el bloque de columnas, la configuración de un producto o bloque de biografía de autor puede ser totalmente diferente. Uno de los objetivos clave del ticket es encontrar una solución que pueda funcionar en muchos contextos diferentes y crear un patrón común para que lo sigan los diseñadores / desarrolladores de bloques. En realidad, esa es una razón clave por la que me alejé de esas 3 opciones en las primeras composiciones que publiqué anteriormente .

Como puede observar, los diseñadores y desarrolladores se han desplazado en gran medida a establecer puntos de interrupción en lugares donde el contenido requiere un diseño para romperse, en lugar de en medidas de dispositivo arbitrarias. Somos buenos en hacer eso (principalmente 😄). Me imagino que los "valores predeterminados inteligentes" de cada bloque son el mejor lugar para abordar eso. Los diseñadores / desarrolladores de bloques (generalmente) saben el tipo de contenido que probablemente contendrá su bloque, e idealmente no deberían necesitar adherirse a estos puntos de interrupción del dispositivo para el estado predeterminado. Si un usuario decide que le gustaría administrarlos por sí mismo, podemos eliminar las reglas de respuesta súper específicas que el desarrollador haya incorporado y proporcionar una alternativa más estandarizada y fácil de entender para que el usuario la edite.

Todo eso está totalmente en debate, pero al menos ese ha sido mi pensamiento sobre este tema. 🙂

Sí, entiendo y estoy de acuerdo 💯 con las razones para explorar la solución impulsada por el dispositivo. Solo quería clavar este error en la oreja mientras se planea.

Creo que puede haber un compromiso. Principalmente cómo el CSS maneja las opciones y los valores que se le pasan.

Solo comparto algunas actualizaciones menores sobre esta dirección de la semana pasada .

Primero, pensé en algunas etiquetas alternativas para la opción de alternar:

Me inclino hacia cualquiera de los de la derecha: creo que son más claros de lo que puse allí inicialmente y, a partir de una prueba rápida en el lugar con un amigo que no es técnico, ella pareció entender lo que esos significaba más claramente que los demás. Para las etiquetas de ButtonGroup reales, creo que cambiar "Personalizado" por "Manual" podría tener un poco de sentido. Aunque no tengo una preferencia fuerte.

También creo que sería útil incluir una línea opcional de texto secundario para que los bloques puedan proporcionar un poco de contexto adicional para el comportamiento predeterminado. En el caso del bloque de columnas, esto podría ser algo como:

También dediqué un poco de tiempo a reevaluar la exploración en torno a configuraciones más complicadas. Me pregunto si permitir que los complementos agrupen múltiples controles en un solo tipo de dispositivo sería útil o no:

Otra cosa que surgió al conversar sobre este problema con otras personas es el vínculo entre realizar una configuración para otro dispositivo y obtener una vista previa de ese cambio. Quizás haya algún lugar en el que podamos incluir un enlace a una vista previa específica del dispositivo en esta área (en la línea del # 13203).

Nota sobre el proceso: un problema relacionado con la introducción de nuevos controles de IU debería tener la etiqueta "Accesibilidad" si realmente queremos mejorar la colaboración entre equipos y crear un mejor producto. Se agradecería mucho etiquetar correctamente y alentar la participación 🙂

Re: el último prototipo con opciones "Auto" y "Custom": ¿cuáles son los elementos HTML nativos subyacentes en los que se deben basar estos controles?

• botones: el texto "Automático" y "Personalizado" leídos fuera de contexto por las tecnologías de asistencia no tendría mucho sentido
• botones de opción: el texto "Diseño específico del dispositivo" anterior podría usarse para una leyenda de conjunto de campos que daría contexto a los botones de opción.

En este punto: ¿cuál es la argumentación para no usar botones de opción nativos, cuáles son los elementos adecuados que se deben usar para una opción de opción única?

@kjellr @afercia
No veo ninguna razón para no usar simplemente un interruptor con la etiqueta "Usar diseño personalizado específico del dispositivo" o algo así que está deshabilitado de forma predeterminada. Se puede mostrar texto adicional que describe el estado actual debajo del conmutador, similar a algunos controles de alternancia existentes en Gutenberg. Pero si se utilizan botones de opción, acepto que "Personalizado" funciona mejor que "Manual".

No veo ninguna razón para no usar simplemente un interruptor con la etiqueta "Usar diseño personalizado específico del dispositivo" o algo así que está deshabilitado de forma predeterminada. Se puede mostrar texto adicional que describe el estado actual debajo del conmutador, similar a algunos controles de alternancia existentes en Gutenberg.

Voy a hacer +1 en esto.

Mi principal queja con el control segmentado es que parece dos opciones, lo que aumenta la complejidad percibida en un 100% frente a una sola palanca. El autor debe comprender _dos_ ajustes en lugar de _ uno_.

Como el conmutador puede tener una etiqueta más detallada que lo hace aún más fácil de entender. Parece un caso de una configuración con una explicación muy clara frente a dos configuraciones con una explicación más ambigua. Hay un claro ganador allí imo.

Sin embargo, consideraría que el interruptor está _en_de forma predeterminada y establecer la etiqueta en algo como "Configurar automáticamente el diseño para otros tamaños de pantalla". Mi razón es que esto es algo que presentamos como un "valor predeterminado inteligente" que está _habilitado_ de manera predeterminada. Para mí, se siente como algo de lo que optas por no hacerlo. Como quitar las ruedas de entrenamiento o desactivar el ABS.

Estoy realmente impresionado con tu proceso, aquí, Kjell: eres positivo y de mente abierta sobre esto, un colaborador productivo modelo ❤️, y aprovechas los patrones existentes y los controles de la interfaz de usuario.

Recuerdo haberlo visto (no recuerdo dónde, ¿DM privado?) Creando una versión alterna de esto también, y que exploró el uso de

Personalmente, no tengo una preferencia por qué versión podríamos lanzarnos al tumultuoso mar de revisiones, pero dadas las recientes menciones de conmutadores, parece que podría valer la pena mostrar eso también como una opción.

El buttongroup funciona bien para las dimensiones de la imagen, especialmente porque cada elemento del grupo está claramente relacionado:

Gracias como siempre por los comentarios. 👏

@afercia

Se agradecería mucho etiquetar correctamente y alentar la participación

¡Por supuesto! Este hilo ha estado tan activo que no me he desplazado hacia arriba para ver las etiquetas en semanas. Gracias por agregar la etiqueta Accesibilidad y bienvenido a la discusión.

En este punto: ¿cuál es la argumentación para no usar botones de opción nativos, cuáles son los elementos adecuados que se deben usar para una opción de opción única?

Lo intenté antes, pero no compartí la exploración:

He aquí por qué lo pasé por alto personalmente:

1. Los controles de radio ocupan mucho espacio y no creo que sean mucho más claros. Un objetivo aquí es hacer que esto parezca simple: la mayoría de las personas deberían poder pasar por alto esta configuración y dejar que nosotros la manejemos.
2. Nuestras pautas para RadioControl sugieren que "Para activar o desactivar una sola configuración, use el componente ToggleControl". Esta es una configuración única, por lo que algún tipo de alternancia parecía más apropiada.
3. He estado buscando en Material patrones para usar aquí. No he podido encontrar ningún ejemplo de botones de opción que activen la visualización / ocultación de controles adicionales. Sin embargo, he encontrado algunos ejemplos de

@jasmussen

Recuerdo haberlo visto (no recuerdo dónde, ¿DM privado?) Creando una versión alterna de esto también, y que exploró el uso de

Sí, lo compartí contigo en DM mientras hablaba de esto. Aquí está:

También preparé un prototipo de escritorio para este enfoque.

Estaba dividido entre estas dos soluciones. Siguiendo nuestras propias pautas, un ButtonGroup se utiliza para "agrupar todos los botones relacionados", y nuestro FormToggle estándar "activa o desactiva una sola configuración".

Basándome únicamente en esas breves descripciones, pensé que FormToggle tenía más sentido. Pero fue más o menos un cambio entre los dos enfoques.

Lo principal que tenía ButtonGroup era el hecho de que nos permitía etiquetar con mayor claridad ambos estados (Automático, Manual). La redacción de esto es realmente confusa, por lo que parecía una ventaja. Podría estar totalmente convencido de lo contrario, y vale la pena probar ambos.

Oh también, respondiéndome a mí mismo desde aquí :

Otra cosa que surgió al conversar sobre este problema con otras personas es el vínculo entre realizar una configuración para otro dispositivo y obtener una vista previa de ese cambio. Quizás haya algún lugar en el que podamos incluir un enlace a una vista previa específica del dispositivo en esta área (en la línea del # 13203).

Hice una exploración rápida de cómo podría verse esto, pensando en la vista previa dentro de un modal:

Esto parece divertido, pero también puede estar fuera del alcance de este problema.

Tampoco estoy realmente interesado en mi tratamiento "solo al pasar el mouse" del ícono de vista previa. Lo modifiqué un poco al probar esto en el móvil:

Realmente cava esa vista previa receptiva. He estado haciendo garabatos en la misma línea en mi tiempo libre, simplemente reemplazando el botón de vista previa con eso:

👆 pero eso necesita más tiempo en el horno, por favor no lo consideres ni siquiera una propuesta. Solo una semilla de una idea para agregar a la mezcla, para convertirse en algo _real_.

Modifiqué una de las elegantes maquetas de

Una cosa de la que no estoy seguro es cómo se definen los anchos de los puntos de interrupción. ¿Los proporciona el tema o el bloque? ¿Puede un bloque elegir tener solo 2 puntos de interrupción en lugar de 3? ¿Y 4? ¿Qué pasa con los anchos de puntos de interrupción personalizados? Cualquiera que sea el caso, no creo que el editor deba proporcionarlos.

Este tipo de vínculos con lo que @meh estaba hablando en este comentario . Estoy empezando a inclinarme hacia algo similar a lo que sugirió al final de ese comentario. Imagino que los controles receptivos para columnas se podrían implementar con solo 2 controles deslizantes:

Ancho mínimo de columna
――――― o ―――― [300] px
Máximo de columnas por línea
――― o ―――――――― [__3]

Esto me parece mucho más simple y mucho más "receptivo", sin tener que recurrir a puntos de interrupción estrictos basados ​​en el ancho de pantalla promedio del dispositivo.

Un objetivo aquí es hacer que esto parezca simple

@kjellr seguro y gracias por la aclaración. Sin embargo, los controles no solo deberían _aparecer_ simples. También deben ser semánticamente correctos para respaldar las tecnologías de asistencia. Por ejemplo, los lectores de pantalla deben anunciarlos de manera significativa. Imagínese un usuario de lector de pantalla tabulando a través de controles enfocables: en algún momento, el lector de pantalla anunciaría:
"Auto"
"Manual"
sin contexto alguno: ¿a qué se refieren "Auto" y "Manual"?

En cambio, los botones de opción agrupados en un conjunto de campos con una leyenda dan contexto porque la leyenda se anuncia.

Como regla general, los controles de formularios nativos ya proporcionan lo que se necesita para la semántica y la accesibilidad. En cambio, los controles personalizados a menudo destruyen la semántica y la interacción esperadas.

Es muy importante que los diseñadores y desarrolladores comprendan que al implementar controles personalizados, se debe tener mucho cuidado para reconstruir todas las características del control nativo equivalente.

En este caso, se trata de una única elección entre dos opciones. Los botones no son apropiados. Los botones de opción agrupados en un conjunto de campos con una leyenda serían ideales. Una alternancia podría ser una compensación aceptable si cambiamos el _significado_ de este control de una sola elección entre dos opciones a un interruptor de "encendido / apagado", que es comparable a una sola casilla de verificación (con todas las advertencias discutidas en detalle sobre las alternancias en ediciones anteriores).

Re: Material design: no estoy seguro de que necesariamente deba ser una fuente de inspiración para un proyecto como WordPress que pretende ser lo más accesible posible 🙂 Muchos de los patrones de Material están inspirados en gran medida en interfaces de usuario móviles y hay un largo camino para que esos patrones sean completamente accesibles.

Además de las columnas, me encuentro con la necesidad de una opción de "pila en el móvil" para los bloques de imágenes. El sitio web heredado que estoy migrando a Wordpress Twenty Nineteen tiene muchas imágenes envueltas en texto flotantes a la izquierda y a la derecha que tienen (y deben permanecer) de aproximadamente 300 píxeles de ancho. Colocados en un bloque de párrafo, estos bloques de imagen funcionan bien en el escritorio, pero en la mayoría de las pantallas móviles comprimen el texto junto a ellos para que sea ilegible. Para cada imagen, tengo que usar el panel Avanzado en el bloque Imagen para agregar una clase CSS .isom (¡más rápido que escribir "is-stacked-on-mobile"!) Que expande la imagen al 100% de ancho para el punto de interrupción Veinte diecinueve usos. Creo que esto podría ser un problema común para muchos usuarios, y no solo para los que migran (si esa es una palabra).

Solo una sugerencia, ya que todavía no estoy lo suficientemente familiarizado con Gutenberg como para ofrecer una solución.

¡Gracias a todos por los continuos comentarios!

Una cosa de la que no estoy seguro es cómo se definen los anchos de los puntos de interrupción. ¿Los proporciona el tema o el bloque? ¿Puede un bloque elegir tener solo 2 puntos de interrupción en lugar de 3? ¿Y 4? ¿Qué pasa con los anchos de puntos de interrupción personalizados? Cualquiera que sea el caso, no creo que el editor deba proporcionarlos.

En general, los puntos de interrupción los especifica el autor del bloque. Charlé con los puntos de interrupción predeterminados que usa Gutenberg ), pero que deberíamos darles la opción a los autores de bloques para optar por participar o no, así como para agregar más si el bloque específico lo requiere.

Parece que la gente se está reuniendo más o menos usando un control de palanca estándar en este caso.

He hecho un poco de limpieza ligera en la composición de $dark-gray-300 , que pasa AA.

Aquí hay una maqueta y prototipos actualizados:

🖥 Prototipo de escritorio

📱 Prototipo móvil

También seguí adelante y me burlé de algunos casos alternativos:

• Un bloque de galería
• Un ejemplo más complicado (creo que algunas de las etiquetas en la sección inferior aquí podrían consolidarse).

Con el interés de hacer avanzar las cosas, esto es lo que estoy pensando:

1. Obtenga otra ronda de comentarios de todos en el hilo. Me encantaría escuchar específicamente desde una perspectiva de todos: si esto parece una solución sólida o no.
2. Reúna algunas etiquetas alternativas . La etiqueta para el campo de alternancia todavía es un poco confusa. Deberíamos generar algunas opciones más y luego:
3. Realice algunas pruebas de usuario del etiquetado para ver cuáles establecen correctamente las expectativas para esta funcionalidad.

¡Hágame saber cualquier comentario sobre esta dirección y sobre los próximos pasos!

@kjellr

Como ya estamos usando el peso del texto para diferenciar los títulos de los paneles de las etiquetas de los campos individuales, he optado por un ajuste de color para las etiquetas de los dispositivos individuales. El gris para esos es $dark-gray-300 , que pasa AA.

Personalmente, preferiría un gris más oscuro, solo para estar seguro. Las etiquetas parecen un poco raras por tener un color tan claro.

Un ejemplo más complicado (creo que algunas de las etiquetas en la sección inferior aquí podrían consolidarse).

Sí, no hay ninguna razón para las etiquetas encima de cada alternancia. Los iconos podrían colocarse junto a los conmutadores antes de la etiqueta de alternancia.

Además, esto es solo un detalle, pero ¿no deberían esos controles deslizantes estirarse completamente hacia la izquierda, en lugar de parecer sangrados en las etiquetas de los puntos de interrupción?

Personalmente, preferiría un gris más oscuro, solo para estar seguro. Las etiquetas parecen un poco raras por tener un color tan claro.

Ir un poco más oscuro está bien. Sin embargo, no me volvería más oscuro que $dark-gray-500 (en la imagen de abajo), de lo contrario, el gris termina luciendo muy similar al resto del texto.

Además, esto es solo un detalle, pero ¿no deberían esos controles deslizantes estirarse completamente hacia la izquierda, en lugar de parecer sangrados en las etiquetas de los puntos de interrupción?

Los sangré para agregar un poco más de jerarquía a los campos. Cuando cada campo es de ancho completo, es menos claro que estén subordinados a la etiqueta "Número de columnas".

@kjellr

Los sangré para agregar un poco más de jerarquía a los campos. Cuando cada campo es de ancho completo, es menos claro que estén subordinados a la etiqueta "Número de columnas".

En ese caso, ¿no tendría sentido sangrar también las etiquetas de los puntos de interrupción?

En ese caso, ¿no tendría sentido sangrar también las etiquetas de los puntos de interrupción?

Más o menos, pero normalmente no aplicamos sangría a las cosas. Hacerlo aquí me parece involuntario / roto:

Aquí está la composición con campos de ancho completo también, para comparar:

Como señalé anteriormente, eso elimina parte de la jerarquía visual y me parece menos escaneable de un vistazo. Sangrar solo los campos parecía un buen compromiso:

Realmente me gusta el diseño con sangría solo en los campos. Esto parece abordar los problemas de todos y acuerda recibir algunos comentarios allí.

Mi única preocupación real está en el "ejemplo complicado" compartido. Aquí es donde siento que el diseño no funciona tan bien. Una vez que hay dos cosas que requieren controles receptivos (es decir, columnas y cantidad de productos), todos esos íconos y etiquetas se vuelven mucho para analizar. En el lado bueno, está lo suficientemente bien estructurado como para poder analizarlo. 😉

Mi única preocupación real está en el "ejemplo complicado" compartido. Aquí es donde siento que el diseño no funciona tan bien. Una vez que hay dos cosas que requieren controles receptivos (es decir, columnas y cantidad de productos), todos esos íconos y etiquetas se vuelven mucho para analizar.

Estoy totalmente de acuerdo con eso. En vencimientos anteriores que no tenían etiquetas, sentí que todavía eran en su mayoría digeribles:

... pero la nueva versión es bastante difícil de escanear cuando se complica. Una forma posible de mejorar esto sería adoptar las siguientes ideas:

• Recomiende la consolidación de varios controles en la misma sección de dispositivo (como se muestra en la sección Diseño a continuación).
• Elimine las etiquetas del dispositivo cuando la etiqueta del control pueda indicar el nombre del dispositivo (como se muestra en la sección Visibilidad a continuación).

El primero con el que me siento bien. No estoy tan seguro del segundo, ya que creo que sería difícil concretar las mejores prácticas a su alrededor.

Recomiendo pensar primero en términos de semántica y luego diseñar en torno a la semántica requerida.

Cada entrada debe etiquetarse de manera significativa y _única_. Esas etiquetas de texto serán <label> elementos asociados con los controles deslizantes y los campos numéricos. Como usuario de tecnologías de asistencia, ¿cómo se supone que debo distinguir varios campos etiquetados con el mismo texto?

Por ejemplo:

• como usuario de lector de pantalla, al pasar a los distintos campos numéricos, escucharé "Número de columnas" para varios campos sin saber a qué se refieren (escritorio, dispositivo móvil?)
• Como usuario de entrada de voz, al pronunciar un comando "Haga clic en Número de columnas" confundirá el software de reconocimiento de voz que estoy usando, ya que no podrá distinguir entre campos con el mismo nombre.

Hay soluciones alternativas que los usuarios pueden usar, pero obligarlos a explorar lo que hay alrededor de los campos o usar métodos alternativos para navegar por el contenido no es lo ideal.

Todas estas etiquetas deben proporcionar un mejor contexto y deben ser únicas para cada campo.

Esta interfaz es complicada, recomendaría explorar una forma de simplificarla radicalmente. Por ejemplo:

• No estoy seguro de cuál es el valor agregado por los controles deslizantes, aparte de su "belleza": son difíciles de usar incluso con un mouse, ocupan mucho espacio y ya hay campos de entrada
• no estoy seguro de que los íconos del dispositivo sean realmente necesarios: eliminarlos podría ahorrar algo de espacio

Me alegra ver que los botones "Auto" y "Manual" se han ido en el último prototipo y han sido reemplazados por conmutadores (aunque los conmutadores tienen sus propios problemas). Gracias.

Entonces, ¿la configuración de visibilidad es ocultar todo el bloque para ciertos dispositivos? ¿Se agregaría esto como una opción para cada bloque? ¿Botones, párrafos, separadores, etc.?

No soy un fanático de la práctica personalmente, pero supongo que todavía hay casos de uso que no pueden evitarlo.
Sin embargo, ¿hay suficientes casos de uso? ¿O estamos asumiendo que otros creadores de páginas lo hacen, por lo que debe ser necesario?

Entonces, ¿la configuración de visibilidad es ocultar todo el bloque para ciertos dispositivos? ¿Se agregaría esto como una opción para cada bloque? ¿Botones, párrafos, separadores, etc.?

Oh, perdón por la confusión allí: ese es solo un ejemplo de prueba de estrés de este patrón para diferentes circunstancias (se planteó en el contexto de un bloque de Productos de terceros anterior ). No agregaremos eso a ningún bloque central.

¡Gracias por la entrada, @afercia! Agradezco tus comentarios aquí.

Como usuario de tecnologías de asistencia, ¿cómo se supone que debo distinguir varios campos etiquetados con el mismo texto?

Mi pensamiento era que el encabezado principal para cada una de esas secciones (escritorio, tableta, móvil, etc.) sería la clave para diferenciarlas, pero lo había estado anticipando desde la perspectiva de alguien que tabula los controles. Si alguien estuviera usando voz en off (por ejemplo) y tocara directamente uno de los controles para niños, puedo ver cómo sería confuso.

Parece que nos beneficiaría mucho si cada etiqueta fuera distinta y clara. No sé si esta es la solución correcta, pero con fines ilustrativos, ¿es algo como esto lo que está sugiriendo desde la perspectiva de las etiquetas?

• No estoy seguro de cuál es el valor agregado por los controles deslizantes, aparte de su "belleza": son difíciles de usar incluso con un mouse, ocupan mucho espacio y ya hay campos de entrada

En este caso, solo estamos reutilizando el control deslizante que se usa en el estado predeterminado del bloque. Si fuéramos a eliminar el control deslizante, me imagino que querríamos hacerlo tanto para la configuración de respuesta "Auto" como para la configuración manual por dispositivo. Pero eso parece ser el comienzo de una discusión más amplia sobre la utilidad de los controles deslizantes en general, y no estoy seguro de que este boleto sea el lugar adecuado para abordar eso.

En cualquier caso, esto está destinado a comenzar a definir un patrón reutilizable para la configuración de bloques receptivos, por lo que, si bien eliminar el control deslizante puede ayudarnos en este caso, es probable que haya otras situaciones en las que el control deslizante aún se use.

• no estoy seguro de que los íconos del dispositivo sean realmente necesarios: eliminarlos podría ahorrar algo de espacio

Preferiría mantener los íconos adentro, ya que creo que son un punto de referencia visual útil. Especialmente con los campos con sangría en mis últimas composiciones, los iconos se destacan como marcadores visuales rápidos en un mar de texto y controles. Este beneficio se verá reforzado aún más si terminamos agregando más texto a las etiquetas.

@afercia

Recomiendo pensar primero en términos de semántica y luego diseñar en torno a la semántica requerida.

Si el HTML se escribió en consecuencia usando fieldset , legend y así sucesivamente, ¿ funcionaría el diseño de @kjell con lectores de pantalla? Creo que la agrupación de conjuntos de campos tiene sentido en este caso. Esto es nuevo para mí, por lo que podría estar equivocado.

Parece que nos beneficiaría mucho si cada etiqueta fuera distinta y clara.

@kjellr sí :) Consideraría tener cada etiqueta dando contexto como en su ejemplo. Eso es más sencillo y comprensible. Tal vez una redacción un poco más corta podría ayudar. Por ejemplo, ¿se necesita realmente "Número de"? Yo diría que también visualmente hay mucho que procesar y tal vez simplificar las cosas podría ayudar un poco.

@mapk sí, lo he considerado. fieldset y legend son la forma correcta de agrupar un conjunto de controles y darle un nombre al grupo. Sin embargo, es una cuestión de soporte real y debería ser probado. Funciona bastante bien con grupos de botones de opción o casillas de verificación. No sé si funciona bien con las entradas range y number .

El componente RangeControl tiene un problema más: se usa el mismo valor de etiqueta para las entradas de rango y número. Por lo tanto, el rango y la entrada numérica tienen el mismo nombre accesible. No es ideal. Propondrá discutir más tarde hoy durante la reunión del equipo de accesibilidad (todos son bienvenidos a unirse).

Se usa el mismo valor de etiqueta para las entradas de rango y número

Espero cambiar eso con https://github.com/WordPress/gutenberg/pull/13863 @afercia

¡Gracias @meh! He comentado rápidamente allí.

@kjellr sí :) Consideraría tener cada etiqueta dando contexto como en su ejemplo. Eso es más sencillo y comprensible. Tal vez una redacción un poco más corta podría ayudar. Por ejemplo, ¿se necesita realmente "Número de"? Yo diría que también visualmente hay mucho que procesar y tal vez simplificar las cosas podría ayudar un poco.

Gracias, @afercia. Aquí hay una maqueta de eso:

La parte "Columnas en" de la etiqueta del campo me parece un poco repetitiva después de la etiqueta "Número de columnas". Pero creo que es viable.

sí, lo he considerado. fieldset y legend son la forma correcta de agrupar un conjunto de controles y darle un nombre al grupo. Sin embargo, es una cuestión de soporte real y debería ser probado. Funciona bastante bien con grupos de botones de opción o casillas de verificación. No sé si funciona bien con las entradas range y number .

¿Cómo podemos verificar si funciona con las entradas range y number ? Si este problema de etiquetado ya está cubierto de esta manera, preferiría mantener las etiquetas de los campos individuales más concisas.

Creo que la parte "Columnas", "Elementos", etc. es útil con el tipo de dispositivo en la etiqueta de cada campo, como lo tiene en la maqueta más reciente.
Además del escenario de voz en off que mencionaste anteriormente, puedo imaginar que sería conveniente si, por ejemplo, estoy en un dispositivo móvil horizontal y el encabezado principal no está a la vista.

Además, los nombres de los tipos de dispositivos serían todos en singular o en plural. Sé que son maquetas. Solo digo: smiley:

Además, los nombres de los tipos de dispositivos serían todos en singular o en plural. Sé que son maquetas. Solo digo 😃

Actualizado arriba.

¿Qué pasa con el back-end de esta idea tan interesante? ¿Alguien ha ideado algún enfoque para trabajar con él? ¿Habrá algo como objetos o incluso varias propiedades individuales que almacenen todos los valores necesarios?

Con respecto a la última maqueta, @kjellr , el título de acordeón de "Columnas" parece redundante con el título "Número de columnas" y la lectura continua de "columnas en escritorios" o "columnas en tabletas", etc. La palabra "columnas" aparece mucho.

¿Se cubrirían todas las necesidades si el encabezado "Número de columnas" fuera legend en un fieldset ? Entonces eso debería indicar que todos los elementos agrupados en ese conjunto de campos se relacionan con el "Número de columnas", ¿verdad? Por lo tanto, las etiquetas de entrada podrían ser simplemente "Escritorio", "Tableta" y "Móvil".

Conjunto de campos y leyenda: como se comentó anteriormente, sería necesario probarlo:

@mapk sí, lo he considerado. fieldset y legend son la forma correcta de agrupar un conjunto de controles y darle un nombre al grupo. Sin embargo, es una cuestión de soporte real y debería ser probado. Funciona bastante bien con grupos de botones de opción o casillas de verificación. No sé si funciona bien con entradas de rango y número.

Según mi comentario anterior, ¿tal vez algo como a continuación? También he incluido el marcado. @kjellr , ¿qué opinas?

@mapk Los controles deslizantes probablemente deberían eliminarse ya que no son muy útiles en el contexto de un control tosco como el recuento de columnas.

He estado pensando lo mismo que @ZebulanStanphill

Las entradas de rango funcionan bien para cosas como controles de volumen o en nuestra opacidad de superposición de imágenes, donde se hace una idea del resultado con solo mirar el control deslizante. _25%, 50%, 100% _

De los documentos de MDN

Debido a que este tipo de widget es impreciso, normalmente no debería usarse a menos que el valor exacto del control no sea importante.

Supongo que las marcas de verificación pueden hacerlo más útil, pero aún así, ¿por qué ofrecer 2 métodos para ajustar columnas?

Si solo usa entradas numéricas, liberaría algo de espacio para usar la entrada y la etiqueta en contexto.

[4] columns on desktops
[2] columns on tablets
[1] column on mobile devices

¡Hola a todos! Con respecto a la visibilidad receptiva, tengo esta función en mi complemento EditorsKit (anteriormente Opciones de bloqueo). Así es como funcionan las funciones:

https://www.youtube.com/watch?v=1VuBXAUqTjA

¡Espero que te guste! ¡Salud!

¡Gracias @phpbits! Aprecio su exploración allí, sin embargo, creo que los estados de "encendido / apagado" son demasiado difíciles de discernir en este caso. ¿Algo como un control de palanca o una casilla de verificación en ese caso podría funcionar mejor?

Los controles deslizantes probablemente deberían eliminarse, ya que no son muy útiles en el contexto de un control tosco como el recuento de columnas.

Gracias @ZebulanStanphill. @afercia también mencionó esto anteriormente. Estoy abierto a otra iteración de diseño que explore esto. @kjellr ¿ alguna idea?

También hagamos que esto pase del diseño y comencemos con un PR para ello. Creo que podemos probar mejor el complemento con usuarios reales.

¡Gracias @phpbits! Aprecio su exploración allí, sin embargo, creo que los estados de "encendido / apagado" son demasiado difíciles de discernir en este caso. ¿Algo como un control de palanca o una casilla de verificación en ese caso podría funcionar mejor?

@mapk También pensé en eso, pero toma mucho espacio y tener estas casillas de verificación debajo de los bloques con una gran cantidad de opciones no se siente tan bien. Sin embargo, tenía esas casillas de verificación en la versión anterior. Pero creo que lo harás mejor que yo, con el equipo de diseño y los controles de accesibilidad. Contribuiré en todo lo que pueda :) ¡Gracias!

Creo que las entradas de rango son agradables, ya que proporcionan una indicación visual (más) clara de los valores mínimo / máximo.

Los controles deslizantes probablemente deberían eliminarse, ya que no son muy útiles en el contexto de un control tosco como el recuento de columnas.

Gracias @ZebulanStanphill. @afercia también mencionó esto anteriormente. Estoy abierto a otra iteración de diseño que explore esto. @kjellr ¿ alguna idea?

Esto definitivamente podría cambiarse, pero no estoy seguro de que sea necesario hacerlo también aquí en este ticket, ya que esos controles deslizantes existen independientemente de que los controles sensibles se conviertan en realidad. Hay otro boleto enfocado en explorar / auditar controles deslizantes . Mientras tanto, creo que tiene sentido enfocar este hilo en obtener una solución de controles receptivos que funcione con controles deslizantes y sin ellos, para que pueda expandirse más allá del bloque de columnas.

Leí casi todos los comentarios aquí, pero cualquiera pensó en usar la visibilidad del dispositivo como una función para no cargar el contenido en el front-end y no solo usar display:none , porque siempre obtengo algún diseñador loco que quiere para ocultar muchas imágenes en el móvil frontal, pero no importa si las imágenes todavía están cargadas de todos modos ... así que creo cosas ACF para evitar eso ...

En el contexto del ajuste de columnas, personalmente considero que los controles deslizantes son maravillosos de usar, porque me permiten simplemente hacer clic / arrastrar y ver rápidamente todos los resultados de todos los valores para esa configuración. Esto se basa en la experiencia previa con controles similares; obviamente, este aún no se ha construido. Si la configuración fuera solo un campo de entrada, sería tedioso para mí editar y evaluar cada valor posible. Para cada valor, tendría que hacer clic en la entrada, retroceder , escribir el número, ver el resultado en el editor y repetir.

Otro beneficio es que con los controles deslizantes, si están bien diseñados (pulgar grande, marcas de graduación, etc.), pueden comunicar visualmente un mínimo / máximo relativo de valores.

Entiendo que soy un usuario de mouse, y que para otros usuarios los controles deslizantes pueden no ser ideales tampoco. Espero que podamos encontrar un equilibrio que funcione para tantos usuarios como sea posible.

Ahora me he fusionado:

• ResponsiveBlockControl componente
• DimensionControl componente

Estos sientan las bases para habilitar controles específicos de la ventana gráfica para un atributo de bloque determinado , como padding .

En el n. ° 19909 presenté un enfoque alternativo para la edición receptiva, que se centra en hacer que cada bloque existente pueda tener cambios receptivos, sin código adicional.

La mano a mano con ajustes de ancho de columna en dispositivos móviles sería un orden de columnas en dispositivos móviles.

Por ejemplo, en una pantalla completa configuro las columnas 1-2-3-4-5. Cuando esto se convierta de manera receptiva, es posible que desee que aparezcan 5, 4, 3, 2, 1.
o 5-3, 1 (* no muestra 2, 4).

Controles de columna individuales _en Responsive_:

1. Alternar mostrar / ocultar
2. Anchos de control
3. Cuadro desplegable para reordenar

Por lo que vale, esta es nuestra última iteración de controles de estilo personalizados, primero para un solo bloque y luego para un bloque de columnas personalizadas

¡¡¡¡¡¡¡¡¡¡¡¡¡¡QUIÉRALO!!!!!!!!!!!!!!

¿Cuando? ¡¿CUANDO?!

¡Gracias por compartir eso! ¡¡¡¡¡Estoy bombeado!!!!!

Esto es lo que he desarrollado para mis propios controles de respuesta de bloques personalizados:

@mattbolt es que en este momento se está desarrollando una iteración de diseño? Si es el último, me encantaría saber cómo resolvió el obstáculo de las consultas de medios.

Es nuestra segunda iteración visual de estas herramientas. El original lo desarrollamos internamente justo después del lanzamiento de Wordpress 5 a fines de 2018 y ha estado en uso de producción desde enero de 2019 en varios sitios, pero principalmente en www.minderoo.org .

En cuanto a las consultas de medios, todos nuestros bloques son compatibles con un componente de renderizado del lado del servidor. Antes de llamar a $content = apply_filters('the_content', $post->post_content); eliminamos los estilos registrados actuales. Luego, durante el proceso de renderizado, cada bloque registra los estilos aplicados de forma única y recibe una identificación única que incluye en las clases css del bloque.

Después de llamar a the_content , "renderizamos" los estilos únicos a una variable. Esta es una llamada de función que genera el css 'media consultado' y lo inserta en el

Esa fue una explicación muy completa, @mattbolt Gracias por tomarse el tiempo de explicármelo :) Suena un poco más allá de mis capacidades, pero sería interesante echarle un vistazo más de cerca y ver qué hay debajo del capó.

Gracias de nuevo, Matt :)

Este es un bloque de botones. Mire todos los espacios en blanco a su alrededor, particularmente arriba y abajo.

Los márgenes auto / 0 para elementos de bloque se traducirían en alineación.
Por ejemplo, ´margin-left: auto; margin-right: 0; `empujaría un elemento de bloque hacia el lado derecho.
¿Cómo se pueden conciliar las opciones de alineación de bloque (izquierda / derecha) con la alineación específica de margen?

Dando un paso atrás, mi 2c:
Encuentro toda la distinción Desktop / Tablet / Mobile un poco arbitraria y no preparada para el futuro ... Si algo nos ha enseñado la historia es que los dispositivos cambian rápidamente, y lo que consideramos hoy como la norma, es fugaz en el mejor de los casos.

¿Por qué no un reloj inteligente, un televisor inteligente, gafas o cualquier otro dispositivo que tenga acceso a la web? ¿Qué constituye un escritorio? ¿Qué diferencia a una computadora portátil de 12 pulgadas de una tableta de 13 pulgadas? Porque si hablamos de resolución de pantalla, un teléfono de 7 pulgadas puede tener una resolución mayor que un televisor de 50 pulgadas.
¿Y por qué 2 puntos de interrupción (móvil / tableta, tableta / escritorio) y no solo 1 (pequeño / grande)?

En lugar de construir algo que se esfuerce por ser perfecto en píxeles, ¿deberíamos quizás cambiar un poco las perspectivas e intentar construir algo que sea independiente de los píxeles?

En lugar de tener puntos de interrupción arbitrarios, ¿deberíamos simplemente intentar detectar cuándo el contenido dentro de una columna, por ejemplo, deja de ser legible y contraerlos a algo que tenga sentido?

Si bien las maquetas que se muestran en # 19909 están muy desactualizadas, el objetivo principal de ese ticket es explorar una interfaz _global y extensible_ para la edición de puntos de interrupción receptiva. Lo cual, si se hace bien, nos permite evitar la situación en la que edita las propiedades móviles de un bloque de columnas en un editor que parece un punto de interrupción de escritorio. A la inversa, al hacer una conexión entre el modo de vista del editor y las propiedades receptivas, podemos hacer lo contrario, permitir la edición de los puntos de interrupción del escritorio incluso cuando se encuentra en un dispositivo móvil, al tiempo que mostramos una mejor representación visual de cada punto de interrupción receptivo.