El proceso de desarrollo y diseño web moderno está evolucionando rápidamente y los sitios web receptivos se están convirtiendo rápidamente en la norma. Los marcos como Bootstrap y Foundation nos muestran el valor de crear sistemas sólidos de componentes para hacer que la creación de cosas en la web sea más rápida, mejor y más fácil.
Hace aproximadamente un año, me uní a la empresa de servicios en la nube y alojamiento web con sede en Los Ángeles (mt) Media Temple como ingeniero de UX. Con la tarea de liderar el desarrollo de front-end del rediseño del sitio web de (mt), aproveché la oportunidad para frenar y revisar mi enfoque de desarrollo de front-end. Así fue como me di cuenta de que la forma en que anteriormente estaba construyendo grandes sitios web era un poco defectuosa. Quería compartir algo de mi proceso de aprendizaje y arrojar algo de luz sobre el enfoque de alto nivel que elegí adoptar mientras aprendía y construía un sistema de diseño.
Pero, ¿qué es exactamente un sistema de diseño?
En FOWA 2013 en Londres, Mark Otto describió un sistema de diseño como “todo lo que compone su producto” (vea su charla completa aquí: Construya su propio Bootstrap).
¿Todo? Todo. Desde tipografía, diseños y cuadrículas, colores, íconos, componentes y convenciones de codificación, hasta voz y tono, guía de estilo y documentación, un sistema de diseño reúne todos estos elementos de una manera que permite a todo su equipo aprender, construir y crecer.
Al principio, no estaba seguro de si debería comenzar a construir algo personalizado o comenzar con un marco existente como Bootstrap. En última instancia, decidí no usar este último por algunas razones:
- Ya teníamos un diseño personalizado. Cuando comencé en Media Temple, los diseños visuales para el nuevo sitio estaban casi completos. Si usara un marco, tendría que personalizarlo significativamente para que se ajustara a nuestros diseños.
- Quería establecer convenciones y estructuras de codificación basadas en las preferencias de mi equipo. Una vez más, tendría que dedicar mucho tiempo a cambiar el nombre de las clases o reorganizar las cosas para que se ajusten a nuestras necesidades.
La cantidad de tiempo que dedicaría esencialmente a destripar el marco no parecía valer la pena. Sentí que construir nuestro propio marco sería beneficioso para nosotros a largo plazo, más fácil de mantener y, como beneficio adicional, sería una experiencia de aprendizaje increíble. También ayudó que tuviera el tiempo para hacerlo, y todo un equipo que estaba emocionado de ser parte de él.
Establecer metas de nivel superior
Al reconstruir un sitio web heredado, se le presenta la oportunidad de mejorar muchas cosas. Antes de comenzar cualquier desarrollo real, comencé estableciendo algunos objetivos de alto nivel:
- Organización: Trabajar con una base de código desordenada puede convertirse en una pesadilla. Asegurarnos de que tuviéramos una estructura y un enfoque bien pensados fue muy importante.
- Mantenibilidad: Con el tiempo, surgirán nuevos desarrolladores para corregir errores y agregar funciones. Necesitábamos tener pautas y convenciones adecuadas para facilitar que las personas hicieran las cosas correctamente.
- Sensibilidad: Habiendo visto un aumento constante en el tráfico de dispositivos móviles / tabletas, era muy importante hacer que la experiencia fuera independiente de la plataforma.
- Escalabilidad: La empresa crecerá en el futuro, al igual que su sitio web. La creación de páginas promocionales y / o páginas de nuevos productos ya no debería ser una tarea desagradable (y casi imposible).
Mi momento “a-ha”
Con los objetivos de alto nivel en mente, comencé a hacer una investigación exhaustiva. Comencé leyendo sobre la semántica HTML y la arquitectura front-end y descubrí los beneficios de construir módulos flexibles, no páginas. Ese fue mi momento de “ajá”.
Anteriormente, mientras creaba sitios web grandes, estaba acostumbrado a dividir el trabajo por plantillas de página. Abordaría un conjunto de plantillas relacionadas y luego pasaría a otro conjunto. El problema con este enfoque es que, si la comunicación entre el equipo no es excepcional, terminará con muchos módulos y componentes similares, a veces idénticos, marcados y diseñados de diferentes maneras. Si no pasa el tiempo extra refactorizándolos, su base de código se convertirá en un desastre absoluto.
Decidí estudiar dos proyectos excelentes, pero diferentes, muy profundamente: InuitCSS de Harry Roberts y Bootstrap de Mark Otto y Jacob Thornton, y rápidamente me di cuenta de que el siguiente paso que tenía que dar era establecer pautas sobre cómo nuestro HTML, CSS y JavaScript debe estar codificado y cuál debe ser nuestro enfoque general de front-end.
Directrices y convenciones de codificación
Inspirado por Idiomatic HTML, CSS Guidelines y Idiomatic JavaScript, comencé a adaptarlos a nuestro propio conjunto de pautas de codificación. En el proceso, descubrí y adopté una metodología de nomenclatura interesante llamada BEM (Bloque, Elemento, Modificador). Es esencialmente una forma inteligente de nombrar sus clases CSS para hacerlas más significativas y fáciles de entender.
Nuestra convención ligeramente modificada es:
.block {}– Representa el componente principal..block-elementName {}– Un elemento hijo que ayuda a formar el componente como un todo..block--modifier {}– Una clase de modificador que se usa para alterar el estado o apariencia del componente.
A continuación, se muestra un ejemplo de un cuadro de alerta que utiliza este enfoque:
/* Main 'alert' component */
.alert {}
/* Sub-components that make up the 'alert' */
.alert-text {}
.alert-close {}
/* Modifiers for various styles of the 'alert' */
.alert--warning {}
.alert--error {}
.alert--success {}
.alert--info {}También finalicé un conjunto de herramientas para ayudarnos en el camino, incluido LESS para nuestras necesidades de preprocesamiento de CSS, y Grunt para compilar nuestros archivos LESS y comprimir, minificar y concatenar nuestro código.
Desarrollo de estilos base
Elementos HTML base cortesía de HTML Ipsum
Similar a InuitCSS y Bootstrap, creé una hoja de estilo primaria llamada mt-global.less que importaría todos los estilos del sitio juntos y crearía la versión final mt-global.css Archivo. En un esfuerzo por mantener las cosas organizadas, creé algunas carpetas:
- centro – Esto contendría nuestras variables personalizadas y mixins.
- vendedor – Para utilidades de proveedores utilizadas, como LESSHat y REMixins.
- base – Para todos los estilos básicos subyacentes como tipografía, colores y estructura.
Comencé con normalize.css, adaptándolo según fuera necesario, y continué diseñando elementos generales como encabezados, enlaces, listas, elementos de formulario y tablas.
Identificar y construir componentes
Con los estilos básicos en su lugar, era hora de echar un vistazo al sitio web en su conjunto y comenzar a identificar los componentes individuales. Comencé a construir un sistema de cuadrícula personalizado basado en la cuadrícula utilizada para los diseños. A partir de ahí, continué con elementos comunes como botones, enlaces de llamada a la acción, unidades de héroe y navegación.
Mientras construía componentes, comencé a descubrir formas de abstraer estilos comunes en objetos reutilizables, similar al objeto multimedia. InuitCSS fue de gran ayuda aquí, ya que contiene toneladas de objetos útiles. Todos estos estilos se colocaron en una carpeta llamada componentes.
Identificar y construir módulos
Con la mayoría de los componentes listos para usar, era hora de usar estos bloques de construcción para crear los distintos módulos de cada página. Creé otra carpeta llamada modulos, y comenzó a juntarlos, comenzando con módulos globales como el encabezado del sitio, el pie de página y la unidad de héroe.
Establecer patrones
Secciones de la guía de estilo preliminar.
Mientras construía componentes y módulos, comencé a conectarlos en una guía de estilo usando el Boilerplate de la guía de estilo. El resultado fue un punto de referencia único para cualquier miembro del equipo interesado en aprender cómo contribuir al sitio web. Una vez que todo el equipo tuvo acceso a la guía de estilo, crear plantillas de página fue muy sencillo. Solo era cuestión de mezclar y combinar módulos, y ampliarlos o personalizarlos cuando fuera necesario.
En conclusión
La construcción de un sistema de diseño es un proceso largo lleno de prueba y error. Los marcos establecidos pueden ahorrarle semanas de tiempo de desarrollo, pero si ha creado su proyecto web con un marco que desde entonces ha pasado por muchas versiones, mantenerlo puede ser difícil. ¿Actualiza su base de código con cada lanzamiento? ¿Qué pasa si lo ha personalizado tanto que actualizarlo ni siquiera es una opción?
Si tiene la oportunidad de reconstruir un sitio desde cero, la creación de una solución personalizada resuelve muchos problemas: ayuda a establecer un sistema personalizado que permite a todo su equipo aprender rápida y fácilmente cómo contribuir a su proyecto; está construido por usted y específicamente para las necesidades de su empresa; y, lo más importante, está diseñado para el futuro. Sin estar atado a la evolución y dirección de otro proyecto, es gratis escalar al ritmo de su empresa.
Investigar. Construir. Aprender. Repetir.
– John Polacek
Sobre todo, fue una experiencia de aprendizaje increíble y un gran orgullo para nuestro equipo. Animo a todos a estudiar los numerosos recursos disponibles sobre sistemas de diseño y el proceso de diseño web en constante cambio.