# ¿Cuál es la visión para el sistema de diseño de Discourse? **URL:** \ **Category:** UX\ **Created:** [30 Enero, 2024 22:12 UTC](https://meta.discourse.org/t/whats-the-vision-for-the-discourse-design-system/293541 "2024-01-30T22:12:00Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![awesomerobot](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/awesomerobot/32/142900_2.png) [@awesomerobot](https://meta.discourse.org/u/awesomerobot)\ **Post date:** [30 Enero, 2024 23:11 UTC](https://meta.discourse.org/t/whats-the-vision-for-the-discourse-design-system/293541/2 "2024-01-30T23:11:45Z")
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. > [@manuel](#): > > la dirección prevista del sistema de diseño 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. > [@manuel](#): > > En cualquier caso, ¿no debería haber una escala numérica para los cuatro valores de color principales? Ahora mismo solo está ahí para el primario y el terciario, pero no para el secundario y el cuaternario. 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. > [@manuel](#): > > Actualmente hay tres tipos diferentes de progresión de tamaño de fuente definidos: 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](https://spencermortensen.com/articles/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 ```css .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. > [@manuel](#): > > Por otro lado, no veo que se introduzcan variables de espaciado fundamentales que permitan ajustes de diseño más consistentes en toda la aplicación. ¿Está esto en la hoja de ruta de alguna manera? 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. --- _[View the full topic](https://meta.discourse.org/t/whats-the-vision-for-the-discourse-design-system/293541)._