Los nueve principios de la implementación del diseño

Al principio, estaba confundido. Acabo de pasar horas diciéndoles todo lo que necesitan para "hacerlo bien". Pero después de pensarlo, me di cuenta de que la pregunta se basaba en una necesidad más profunda de guiar y evaluar lo que a menudo es un conjunto de elecciones subjetivas, elecciones que a veces hacen muchas personas diferentes en diferentes momentos. Cosas como convenciones de nomenclatura consistentes y guías de estilo en vivo son el resultado final, pero estas "mejores prácticas" están arraigadas en un conjunto más profundo de valores que no siempre son explícitos. Por ejemplo, consejos específicos como "Minimizar el número de clases con las que colabora otra clase" no son tan útiles sin una apreciación más amplia de la modularidad.

Me di cuenta de que para saber realmente si nuestro trabajo es bueno, necesitamos un mayor nivel de principios que puedan usarse como vara de medir para implementar el diseño. Necesitamos algo que se elimine de un lenguaje específico como CSS o una forma obstinada de escribirlo. Al igual que los principios universales del diseño o las heurísticas de usabilidad de Nielsen, necesitamos algo que guíe la forma en que implementamos el diseño sin decirnos exactamente cómo hacerlo. Para cerrar esta brecha, he compilado nueve principios de implementación de diseño.

Esto no es una lista de verificación. En cambio, es un conjunto de pautas generales destinadas a preservar un valor subyacente. Se puede utilizar como guía para alguien que trabaja en la implementación o como herramienta para evaluar un proyecto existente. Entonces, ya sea que esté revisando código, auditando CSS o entrevistando a candidatos para un rol en su equipo, estos principios deberían proporcionar una estructura que trascienda técnicas específicas y resulte en un enfoque común para implementar el diseño.

1. Estructurado El documento está escrito semántica y lógicamente, con o sin estilos.
2. Eficiente Se utiliza la menor cantidad de marcado y activos para lograr el diseño.
3. Las reglas estandarizadas para valores comunes se almacenan y utilizan libremente.
4. Los elementos Base abstraídos están separados de un contexto específico y forman un marco central.
5. Los elementos comunes modulares se dividen lógicamente en partes reutilizables.
6. Las personalizaciones configurables para los elementos base están disponibles a través de parámetros opcionales.
7. Escalable El código se amplía fácilmente y anticipa mejoras en el futuro.
8. Documentado Todos los elementos se describen para que otros los usen y amplíen.
9. Preciso El resultado final es una representación adecuada del diseño previsto.
   

Para facilitar el seguimiento y ver cómo se aplica cada principio a un proyecto, usaremos una maqueta de diseño de uno de mis proyectos como base para este artículo. Es una página de destino especial que promociona ofertas diarias en un sitio web de comercio electrónico existente. Si bien algunos de los estilos se heredarán del sitio web existente, es importante tener en cuenta que la mayoría de estos elementos son completamente nuevos. Nuestro objetivo es tomar esta imagen estática y convertirla en HTML y CSS utilizando estos principios.

1. Estructurado

El documento está escrito semántica y lógicamente, con o sin estilos.

El principio aquí es que el contenido de nuestro documento (HTML) tiene significado incluso sin estilos de presentación (CSS). Por supuesto, eso significa que estamos usando niveles de encabezado correctamente ordenados y listas desordenadas, pero también usando contenedores significativos como <header> y <article> . No deberíamos pasar por alto el uso de cosas como las etiquetas ARIA, los atributos alt y cualquier otra cosa que podamos necesitar para la accesibilidad.

Puede que no parezca un gran problema, pero sí importa si usa una etiqueta de anclaje o un botón, incluso si son visualmente idénticos, porque comunican diferentes significados y brindan diferentes interacciones. El marcado semántico comunica ese significado a los motores de búsqueda y las tecnologías de asistencia e incluso facilita la reutilización de nuestro trabajo en otros dispositivos. Hace que nuestros proyectos estén más preparados para el futuro.

Crear un documento bien estructurado significa aprender a escribir HTML semántico, familiarizarse con los estándares W3C e incluso con algunas mejores prácticas de otros expertos, y tomarse el tiempo para hacer que su código sea accesible. La prueba más simple es mirar su HTML en un navegador sin estilos:

• ¿Se puede usar sin CSS?
• ¿Todavía tiene una jerarquía visible?
• ¿El HTML sin procesar transmite significado por sí mismo?

Una de las mejores cosas que puede hacer para garantizar un documento estructurado es comenzar con el HTML. Antes de pensar en los estilos visuales, escriba el código HTML simple sobre cómo debe estructurarse el documento y qué significa cada parte. Evite div s y piense en cuál sería una etiqueta de envoltura adecuada. Solo este paso básico contribuirá en gran medida a ayudarlo a crear una estructura adecuada.

 <section> <header> <h2>Daily Deals</h2> <strong>Sort</strong> <span class="caret"></span> <ul> <li><a href="#">by ending time</a></li> <li><a href="#">by price</a></li> <li><a href="#">by popularity</a></li> </ul> <hr /> </header> <ul> <li aria-labelledby="prod7364536"> <a href="#"> <img src="prod7364536.jpg" alt="12 Night Therapy Euro Box Top Spring" /> <small>Ends in 9:42:57</small> <h3 id="prod7364536">12" Night Therapy Euro Box Top Spring</h3> <strong>$199.99</strong> <small>List $299</small> <span class="callout">10 Left</span> </a> </li> </ul> </section>

Comenzar solo con HTML y pensar en el significado de cada elemento da como resultado un documento más estructurado. Arriba, puede ver que he creado todo el marcado sin usar un solo div .

2. Eficiente

Se utiliza la menor cantidad de marcado y activos para lograr el diseño.

Tenemos que pensar en nuestro código para asegurarnos de que sea conciso y no contenga marcas o estilos innecesarios. Es común para mí revisar el código que tiene div s dentro de div s dentro de div s usando nombres de clase específicos del marco solo para lograr un elemento de nivel de bloque que esté alineado a la derecha. A menudo, el uso excesivo de HTML es el resultado de no comprender CSS o el marco subyacente.

Además del marcado y CSS, es posible que necesitemos otros recursos externos, como íconos, fuentes web e imágenes. Hay muchos métodos y opiniones excelentes sobre las mejores formas de implementar estos activos, desde fuentes de iconos personalizadas hasta incrustaciones en base64 y SVG externos. Cada proyecto es diferente, pero si tiene un PNG de 500 píxeles para un solo ícono en un botón, es probable que no esté siendo intencional en cuanto a la eficiencia.

Al evaluar la eficiencia de un proyecto, hay dos preguntas importantes que hacer:

• ¿Podría lograr lo mismo con menos código?
• ¿Cuál es la mejor manera de optimizar los activos para lograr la menor sobrecarga?

La eficiencia en la implementación también se superpone con los siguientes principios sobre estandarización y modularidad, porque una forma de ser eficiente es implementar diseños utilizando estándares establecidos y hacerlos reutilizables. La creación de una mezcla para una sombra de cuadro común es eficiente, al mismo tiempo que se crea un estándar que es modular.

3. Estandarizado

Las reglas para los valores comunes se almacenan y utilizan libremente.

La creación de estándares para un sitio web o una aplicación generalmente se trata de establecer las reglas que rigen cosas como el tamaño de cada nivel de encabezado, un ancho de medianil común y el estilo para cada tipo de botón. En CSS simple, tendría que mantener estas reglas en una guía de estilo externa y recordar aplicarlas correctamente, pero es mejor usar un preprocesador como LESS o Sass, para que pueda almacenarlas en variables y mixins. La conclusión principal aquí es valorar los estándares por encima de los diseños de píxeles perfectos .

Entonces, cuando obtenga una maqueta de diseño con un ancho de medianil de 22 píxeles, en lugar de los 15 píxeles que estamos usando en otros lugares, asumiré que tal precisión no vale la pena y en su lugar usaré el medianil estándar de 15 píxeles. . Dando un paso más allá, todo el espacio entre los elementos utilizará este estándar en múltiplos. Un espacio extra ancho será $gutter-width * 2 (lo que equivale a 30 píxeles), en lugar de un valor codificado. De esta manera, toda la aplicación tiene una sensación coherente y alineada.

 .product-cards { li { display: inline-block; padding: @gutter-width/4; color: @text-color; text-decoration: none; background-color: @color-white; .border; margin-bottom: @gutter-width/2; margin-right: @gutter-width/2; } } .product-status { font-size: @font-size-small; color: @grey-darker; font-weight: @font-weight-bold; margin-bottom: @gutter-width/4; }

Debido a que usamos valores estandarizados derivados de LESS variables o mixins, nuestro CSS no tiene valores numéricos propios. Todo se hereda de un valor centralizado.

Para verificar la estandarización, revise el CSS y busque cualquier unidad codificada: píxeles, colores HEX, ems o prácticamente cualquier valor numérico.

• ¿Estas unidades deberían usar un valor estándar o variable existente?
• ¿Se reutiliza la unidad de manera que se beneficiaría de una nueva variable? Tal vez te hayas dado cuenta de que esta es la segunda vez que aplicas un fondo parcialmente opaco y que se necesita la misma opacidad en ambas ocasiones.
• ¿Podría derivarse la unidad del cálculo de una variable existente? Esto es útil para las variaciones de color; por ejemplo, usar un color estándar y realizar un cálculo en él para obtener algo un 10 % más oscuro, en lugar de codificar el valor HEX resultante.

Con la mayor frecuencia posible, uso valores estándar y creo otros nuevos solo como excepción. Si se encuentra ajustando un elemento 5 píxeles aquí y 1 píxel allá, es probable que sus estándares se vean comprometidos.

En mi experiencia, la mayoría de los CSS preprocesados ​​deberían usar variables y mixins centralizados, y casi no debería ver valores numéricos, de píxeles o HEX en los componentes individuales. Ocasionalmente, puede ser apropiado agregar algunos píxeles para ajustar la posición de un componente individual, pero incluso esos casos deberían ser raros y hacer que verifique dos veces sus estándares.

4. Abstraído

Los elementos base están separados de un contexto específico y forman un marco central.

Originalmente llamé a este principio "estructurado" porque, además de crear el proyecto específico en el que está trabajando ahora, también debe trabajar hacia un sistema de diseño que pueda usarse más allá del contexto original. Este principio se trata de identificar elementos comunes más grandes que deben usarse a lo largo de todo el proyecto o en proyectos futuros. Esto comienza tan amplio como la tipografía y las entradas de campo de formulario y llega hasta diferentes diseños de navegación. Piénselo de esta manera: si su CSS fuera de código abierto como marco, como Bootstrap o Foundation, ¿cómo separaría los elementos de diseño? ¿Cómo los estilizarías de manera diferente? Incluso si ya está utilizando Bootstrap, es probable que su proyecto tenga elementos básicos que Bootstrap no proporciona y que también deben estar disponibles en el sistema de diseño de su proyecto.

La clave aquí es pensar en cada elemento en términos más genéricos, en lugar del contexto específico de su proyecto. Cuando mire un elemento en particular, divídalo en partes y asigne a cada parte estilos generales que ese elemento tendría independientemente de la implementación específica con la que esté trabajando ahora. Los elementos más comunes son la tipografía (estilos de encabezado, altura de línea, tamaños y fuentes), elementos de formulario y botones. Pero otros elementos también deben ser "estructurados", como la etiqueta de llamada o cualquier formato de precio especial que podría haber sido diseñado para nuestras ofertas diarias pero que también sería útil en otros lugares.

Cuando verifique la abstracción de su proyecto, pregunte:

• ¿Cómo construiría este elemento si supiera que se va a reutilizar en otro contexto con necesidades diferentes?
• ¿Cómo puedo dividirlo en partes que serían valiosas a lo largo de toda la aplicación?

Pensar en una implementación más general de cada elemento es clave. Estas piezas deben almacenarse como clases completamente separadas e independientes o, mejor aún, como archivos LESS o Sass separados que se pueden compilar con el CSS final.

Este principio es más fácil en una arquitectura de aplicación de módulo o componente web porque los widgets probablemente ya estén separados de esta manera. Pero tiene tantas implicaciones para nuestro pensamiento como cualquier otra cosa. Siempre debemos abstraer nuestro trabajo del contexto del que se deriva para asegurarnos de que estamos creando algo flexible.

5. Modulares

Los elementos comunes se dividen lógicamente en partes reutilizables.

Al superponerse con el principio "Abstracto", hacer que nuestros diseños sean modulares es una parte importante para establecer un sistema de diseño concreto con el que sea fácil trabajar y mantener. Hay una línea muy fina entre los dos, pero la diferencia es importante en principio. El matiz es que, si bien los elementos básicos globales deben abstraerse de su contexto, los elementos individuales en contexto también deben ser reutilizables y mantener estilos independientes. Los módulos pueden ser exclusivos de nuestra aplicación y no algo que necesitemos disponible en todo el marco, pero aún deben ser reutilizables para que no dupliquemos el código cada vez que usamos ese módulo.

Por ejemplo, si está implementando la lista de tarjetas de productos del ejemplo anterior para una página de destino de ofertas diarias, en lugar de hacer que el HTML y el CSS sean específicos para las ofertas diarias, con nombres de clase como daily-deal-product , cree una página más general clase product-cards que incluye todas las clases resumidas pero que también podría reutilizarse fuera de la página Ofertas diarias. Esto probablemente resultaría en tres lugares separados donde su componente obtiene sus estilos:

• CSS básico . Este es el marco subyacente, incluidos los valores predeterminados para tipografía, canales, colores y más.
• componentes CSS . Estas son las partes abstractas del diseño que forman los componentes básicos del diseño general, pero que se pueden usar en cualquier contexto.
• componentes padres . Estos son el componente daily-deal (y sus hijos) que contienen estilos o personalizaciones específicas de Ofertas diarias. Para muchos, este será un componente web de JavaScript real, pero podría ser solo una plantilla principal que incluye el HTML necesario para representar todo el diseño.

Por supuesto, puede llevar esto demasiado lejos, por lo que tendrá que ejercer su juicio. Pero en su mayor parte, todo lo que cree debe ser lo más reutilizable posible, sin complicar demasiado el mantenimiento a largo plazo.

6. Configurable

Las personalizaciones de los elementos base están disponibles a través de parámetros opcionales.

Parte de la construcción de un sistema de diseño consiste en pensar en las opciones que el proyecto podría necesitar ahora o en el futuro. No es suficiente implementar el diseño solo según lo prescrito. También tenemos que considerar qué partes pueden ser opcionales, encendidas o apagadas a través de una configuración diferente.

Por ejemplo, las banderas de llamada en nuestro diseño muestran solo tres variaciones de color, todas apuntando hacia la izquierda. En lugar de crear tres clases separadas, crearemos una clase predeterminada y agregaremos nombres de clases adicionales como parámetros opcionales. Más allá de eso, creo que alguien podría venir y querer apuntar la bandera hacia un contexto diferente. De hecho, usar nuestros colores de marca predeterminados para estas leyendas también es útil, aunque el diseño no lo requiera específicamente. Escribiríamos el CSS específicamente para dar cuenta de esto, incluyendo tanto la izquierda como la derecha como opciones.

Mientras piensa en un elemento de diseño en particular, piense en las opciones que podrían ser valiosas. Una parte importante de comprender esto es pensar críticamente sobre otros contextos en los que este elemento podría reutilizarse.

• ¿Qué partes podrían ser configuradas, opcionales o habilitadas a través de una variable externa?
• ¿Sería valioso que el color o la posición del elemento pudiera cambiar?
• ¿Sería útil proporcionar tamaños pequeños, medianos y grandes?

El uso de una metodología como BEM, OOCSS o SMACSS para organizar su CSS y establecer convenciones de nomenclatura puede ayudarlo a tomar estas decisiones. Trabajar a través de estos casos de uso es una gran parte de la construcción de un sistema de diseño configurable.

7. Escalable

El código se amplía fácilmente y anticipa mejoras en el futuro.

En el mismo espíritu que el principio de "Configurable", nuestra implementación también debe esperar cambios en el futuro. Si bien la creación de parámetros opcionales es útil, no podemos anticipar todo lo que necesitará nuestro proyecto. Por lo tanto, también es importante considerar cómo el código que estamos escribiendo afectará los cambios futuros y organizarlo intencionalmente para que sea fácil de mejorar.

La creación de CSS escalable generalmente requiere que use funciones más avanzadas de LESS y Sass para escribir mixins y funciones. Debido a que todas nuestras banderas de llamadas son iguales excepto por los colores, podemos crear un único mixin LESS que generará el CSS para cada llamada sin la necesidad de duplicar el código para cada variación. El código está diseñado para escalar y es fácil de actualizar en un solo lugar.

 @angle: 170; .callout { &.qty-left { .callout-generator(@color-deals, @color-white, @angle); } &.qty-sold { .callout-generator(@color-white, @color-deals, @angle, 2px solid @color-deals); } &.qty-out { .callout-generator(@color-grey, darken(@color-grey, 10%), @angle); } }

Para hacer que las llamadas sean escalables, crearemos un LESS mixin llamado .callout-generator que acepte valores para elementos como el color de fondo, el color del texto, el ángulo del punto y el borde.

 .review-flag { .callout-generator(@color-brand, @color-white, 75); }

En el futuro, cuando un nuevo requisito requiera un patrón de diseño similar, será fácil generar un nuevo estilo.

Para crear un sistema de diseño escalable, aprenda a anticipar los cambios que son comunes en los proyectos y aplique esa comprensión para asegurarse de que el código que escriba esté listo para esos cambios. Las soluciones comunes incluyen el uso de variables y mixins, así como el almacenamiento de valores en matrices y el bucle a través de ellos. Pregúntese:

• ¿Qué partes de estos elementos es probable que cambien?
• ¿Cómo puede escribir el código para que sea fácil realizar esos cambios en el futuro?

8. Documentado

Todos los elementos se describen para que otros los usen y amplíen.

La documentación del diseño está infravalorada y, a menudo, es la primera esquina que se corta en un proyecto. Pero crear un registro de su trabajo es más que solo ayudar a la siguiente persona a descubrir lo que pretendía; en realidad, es una excelente manera de lograr que todas las partes interesadas participen en todo el sistema de diseño, para que no tenga que reinventar la rueda cada vez. . Su documentación debe ser una referencia para todos los miembros del equipo, desde desarrolladores hasta ejecutivos.

La mejor manera de documentar su trabajo es crear una guía de estilo en vivo, que se genera directamente a partir de los comentarios en su código. Usamos un enfoque llamado desarrollo basado en guías de estilo, junto con DocumentCSS, que se paga solo con dividendos. Pero incluso si su proyecto no puede tener una guía de estilo en vivo, está bien crear una manualmente en HTML o incluso en un PDF con formato de impresión. El principio a recordar es que todo lo que hacemos debe estar documentado .

Para documentar su sistema de diseño, escriba instrucciones para ayudar a otra persona a comprender cómo se implementó el diseño y qué deben hacer para recrearlo ellos mismos. Esta información puede incluir el pensamiento de diseño específico detrás de un elemento, ejemplos de código o una demostración del elemento en acción.

• ¿Cómo le diría a otra persona cómo usar mi código?
• Si estuviera incorporando a un nuevo miembro del equipo, ¿qué le explicaría para asegurarme de que sepa cómo usarlo?
• ¿Qué variaciones de cada widget puedo mostrar para demostrar todas las formas en que se puede usar?

9. Preciso

El resultado final es una representación adecuada del diseño previsto.

Finalmente, no podemos olvidar que lo que creamos tiene que verse tan bien como el concepto de diseño original que pretende reflejar. Nadie va a apreciar un sistema de diseño si no cumple con sus expectativas de atractivo visual. Es importante enfatizar que el resultado solo puede ser una representación adecuada del diseño y no será perfecto en píxeles. No me gusta la frase "píxel perfecto" porque sugerir que una implementación tiene que ser exactamente como la maqueta, píxel por píxel, es olvidar cualquier restricción y devaluar la estandarización (no importa que cada navegador renderice CSS un poco diferentemente). Lo que complica la precisión es el hecho de que los diseños estáticos para aplicaciones receptivas rara vez tienen en cuenta todos los tamaños posibles de dispositivos. El punto es que se requiere un cierto grado de flexibilidad.

Tendrá que decidir qué cantidad de representación adecuada se necesita para su proyecto, pero asegúrese de que cumpla con las expectativas de las personas con las que está trabajando. En nuestros proyectos, revisaré las principales desviaciones de la perfección de píxeles con el cliente, solo para asegurarme de que estamos en la misma página. “Los diseños muestran un estilo de botón azul predeterminado con un borde, pero nuestro color de botón estándar es ligeramente diferente y no tiene borde, por lo que optamos por eso”. Establecer expectativas es el paso más importante aquí.

Un sistema de pensamiento

El objetivo de estos nueve principios es proporcionar una guía para implementar el diseño en HTML y CSS. No es un conjunto de reglas o consejos prescriptivos sino una forma de pensar en su trabajo para que pueda optimizarlo y lograr el mejor equilibrio entre un gran diseño y un gran código. Es importante darse una cierta cantidad de flexibilidad en la aplicación de estos principios. No podrá lograr la perfección con cada uno cada vez. son ideales. Siempre hay otras distracciones, principios y prioridades que nos impiden hacer nuestro mejor trabajo. Aún así, los principios deben ser algo por lo que siempre se debe esforzar, para estar constantemente comprobándose y perseguir agresivamente a medida que lleva su diseño desde el tablero de dibujo hasta el medio final en el que se experimentará. Espero que lo ayuden a crear mejores productos y crear sistemas de diseño que duren muchos años.

Me encantaría saber de usted acerca de su experiencia en la implementación de diseño. Publique un comentario y comparta cualquier consejo u otros principios que pueda estar utilizando en su propio trabajo.