¿Cuál es la visión para el sistema de diseño de Discourse?

Me encantaría crear temas y componentes personalizados que estén alineados con el sistema de diseño de Discourse y que se integren en la aplicación de manera consistente y armoniosa.

Solo con ver el código y cómo se definen y aplican los estilos en el núcleo, me resulta difícil comprender la imagen general y la dirección prevista del sistema de diseño.

Intentaré desglosar esto en tres temas principales: color, tipografía y espaciado.

Color

Hace dos años se introdujo una escala numérica para algunos valores. Creo que se mencionó que solo estaba destinada a complementar las transformaciones de color con nombre. Para el valor de color terciario, ahora se ve así:

Veo ambos modelos aplicados en código nuevo en el núcleo. ¿La idea a largo plazo es seguir usándolos uno al lado del otro o hay una visión diferente?

En cualquier caso, ¿no debería haber una escala numérica para los cuatro valores de color principales? Ahora mismo solo está para el primario y terciario, pero no para el secundario y cuaternario.

Tipografía

Actualmente hay tres tipos diferentes de progresión de tamaño de fuente definidos:

Tampoco ha habido actualizaciones en esto en más de dos años. ¿Deberían usarse estos en el código nuevo? Sinceramente, nunca toqué las definiciones de multiplicadores, ya que es difícil definir el tamaño de fuente final real. Pero tampoco entiendo las definiciones de fuente base. La escala definida sería:

  • 13px - 14px - 15px - 17px - 19px

Pero cuando miro los tamaños de fuente reales, la escala predeterminada en uso es más o menos:

  • 13px - 15px - 17.25px - 22px - 26px

Espaciado

Veo que los nuevos elementos como la barra lateral introducen variables raíz para el espaciado. Por ejemplo:

image

Eso definitivamente facilita el ajuste del diseño de la barra lateral. Pero no se traduce a ningún otro elemento de diseño. Por otro lado, no veo variables de espaciado fundamentales que permitan ajustes de diseño más consistentes en toda la aplicación. ¿Está esto en el plan de desarrollo de alguna manera?

General

Sería genial saber si hay planes para avanzar hacia un sistema de diseño más consistente y simple.

Parece que hay demasiadas definiciones no relacionadas e independientes en este momento, y hacen que sea bastante difícil construir un diseño consistente y rítmico con una noción de facilidad (y alegría :slight_smile:).

Entiendo que es una aplicación grande con una gran cantidad de elementos diferentes. Sin embargo, acabo de hacer una pequeña prueba en la vista de lista predeterminada más reciente:

Esta es una reconstrucción con cada valor de espaciado elegido de una progresión geométrica muy simple (2px/4px/8px/16px/32px/64px). Y tamaños de fuente de solo 4 valores:

¿No parece que, desde el punto de vista del diseño, no hay necesidad del número de definiciones únicas que existen actualmente en toda la aplicación?

14 Me gusta

Esto es algo que hemos querido hacer, y hacia lo que hemos trabajado gradualmente en pedazos, pero no es algo que pueda suceder de una vez. Cada cambio que hacemos causa posibles regresiones de temas en miles de sitios (y tenemos que solucionar muchas de estas para nuestros clientes), por lo que lleva mucho tiempo hacer pequeños cambios.

También hemos estado realizando trabajos de modernización de Ember durante un tiempo, lo que también requiere solucionar regresiones y refactorizar temas existentes. Esto todavía está en curso y también llevará tiempo actualizar todo (reemplazar nuestro sistema de widgets, por ejemplo, podría llevar fácilmente 6 meses más). Hay muchas prioridades que equilibrar.

No hay una dirección prevista más allá de una mayor consistencia. Hemos considerado desacoplar nuestros estilos base para que el Discourse predeterminado “sin tema” tenga mucho menos CSS (lo que podría facilitar el mantenimiento de los temas)… pero eso es solo una idea en este momento.

Creo que estos se agregaron “según sea necesario”, por lo que no hemos necesitado escalas secundarias/cuaternarias adicionales. No tenemos ningún plan para eliminar las versiones con nombre, por lo que cualquiera de las dos se puede usar en el futuro previsible.

Los tamaños más pequeños/pequeños/grandes/más grandes son para la configuración de tamaño de texto del usuario. La mayoría de las veces, estos no necesitarán cambiarse.

La escala em se basa aproximadamente en una escala tipográfica clásica (The typographic scale, por ejemplo). Una escala más espaciada como 13-15-17-19 no crea mucho contraste y todo se mantiene un poco pequeño a menos que tengas muchos pasos. En una escala clásica, las brechas entre la escala aumentan junto con el tamaño para crear más contraste.

La idea detrás de la escala basada en em es que todo en la aplicación puede escalarse proporcionalmente, y las secciones individuales de la aplicación pueden escalarse proporcionalmente. Así que podría hacer algo como

.sidebar-wrapper {
  font-size: 20px;
}

y todo dentro se escalaría proporcionalmente sin tener que alterar cada tamaño de fuente individual y todo el espaciado relacionado.

Internamente, los comentarios son similares a los suyos, en el sentido de que los desarrolladores quieren saber exactamente qué tamaño de fuente obtienen independientemente del contexto, lo cual es una desventaja del sistema. Idealmente, no nos preocuparíamos por los tamaños exactos y podríamos simplemente decir “esto debería subir un nivel porque quiero que sea más grande”, pero ese modelo mental no parece ser natural.

Hay cierto deseo de pasar a un sistema basado en rem, pero como se mencionó anteriormente… esto probablemente llevaría mucho tiempo cambiarlo porque afectaría a muchos sitios existentes. También preferiría la base predeterminada del navegador de 16px en lugar de nuestros 15px, pero es una historia similar (¡solía ser 14px! así que al menos hemos dado un paso).

La escala rem se utiliza para los encabezados en el contenido de las publicaciones cocinadas, porque anidar etiquetas de encabezado usando ems significaba que los individuos podían escalar el texto infinitamente y causar problemas de diseño.

Sí, ha surgido un par de veces… (sueno como un disco rayado, pero…) tendría que ser un cambio muy gradual para evitar regresiones en los sitios existentes. En este momento, hemos estado agregando variables compartidas dentro de áreas específicas a medida que las actualizamos, lo cual es un paso en la dirección correcta.

La velocidad a la que ocurren estas cosas es comprensiblemente un poco frustrante, pero durante la mayor parte de la historia de Discourse, no hubo ningún diseñador a tiempo completo en el personal. El equipo de diseño ha crecido a 7 en los últimos dos años (incluidos diseñadores dedicados a trabajar en proyectos de clientes, que ocurren en su mayoría fuera de la vista pública), por lo que esperamos que ahora nos movamos hacia una mayor consistencia más rápido.

12 Me gusta

¡Gracias por las explicaciones, Kris! Es de gran ayuda.

Así que solo me enfrento a esto a una escala muy pequeña. A veces creo que podría ser útil cambiar la expectativa general con respecto al Producto. Establecer que Discourse se mueve rápido.

Eso podría estar bien, pero creo que aún requeriría manejadores más fáciles. Hay demasiadas plantillas. Incluso si cada una de ellas tuviera un CSS más simple, si no puedo modificarlas de manera orquestada, sigue siendo mucho trabajo.

Es un modelo mental hermoso. Preferiría tener tamaños exactos porque son mucho más fáciles de aplicar. Por ejemplo, alguien tiene un sistema de diseño, solo aplico los números y veo el resultado. Mientras que de lo contrario, siento que necesitaría alinear dos sistemas. Como si necesitara entender el carácter de ambos y encontrar su melodía común.

5 Me gusta

Pensando más en esto… Podría tener varias visiones para un sistema de diseño de Discourse.

Discourse Design System-95
Un sistema de diseño práctico con bloques de construcción atómicos estandarizados. Supongo que ese siempre sería un primer paso necesario.


Un sistema que abstrae algunos componentes de alto nivel. Para Discourse, estos podrían ser sobre moderación, reconocimiento, información,…


Un sistema común de patrones para la conversación en línea. Similar al alcance fundamental de un sistema como Material Design.

2 Me gusta