Un buen diseño web receptivo, por su propia naturaleza, pasa desapercibido para quienes consumen contenido en línea. Entonces, cuando alguien pregunta por un nuevo sitio web, a menudo desconoce por completo el concepto, a pesar de experimentarlo a diario. Y, sin embargo, el diseño receptivo del sitio web ahora se reconoce como práctica estándar en toda la industria.
La creación de sitios web receptivos ha alterado nuestros procesos, desde la creación de maquetas de páginas completas hasta el desarrollo de bibliotecas de componentes y diseños reutilizables.
el diseño está basado en el contenido y los estilos son impulsados por la marca
Recientemente un cliente actual nos contactó para rediseñar de manera responsive su sitio web. Anteriormente trabajamos con ellos utilizando un proceso de cascada rígida. Pasando a un flujo de trabajo ágil, pudimos abrazar el cambio en cualquier punto del proyecto.
A lo largo del proceso, nos adherimos a la filosofía de que el diseño se basa en el contenido y los estilos son impulsados por la marca.
Los documentos de especificación funcionan muy bien para listar toda la funcionalidad que un sitio debe tener. Pero, ¿es realmente lo que necesita el cliente? Es muy difícil visualizar estas características en su lugar. Por lo tanto, el resultado es que los documentos de especificación a menudo se convierten en listas de deseos hinchadas. Esto no ayuda al cliente, a los diseñadores ni al sitio web final.
En lugar de documentos de especificación, optamos por utilizar wire-frames. El primer paso del proyecto consistió en crear marcos de alambre para cada página. Esto puede parecer exagerado, pero los marcos de cables condujeron a discusiones tempranas del contenido y las características de cada página. Descubrimos que las características que nunca antes consideramos se agregaron, mientras que muchas se eliminaron.
Wire-frames nos dio una representación clara y visual de cómo el contenido y la funcionalidad deberían priorizarse en cada página. Estos marcos de alambre se convirtieron en un punto de referencia, reemplazando un documento de especificación.
Punto clave: la producción de marcos de alambre en lugar de documentos de especificación se centra en las características principales y la importancia del contenido.
La auditoría de los marcos de alambre nos permite formar una lista de todos los componentes comunes. En un solo sitio habrá docenas de secciones pequeñas en cada página que son muy similares. Estos componentes se pueden agrupar en una lista exhaustiva que se usará más adelante.
Esta etapa tiene tres beneficios principales:
Punto clave: la planificación de cómo abordar el desarrollo de la interfaz de usuario de un proyecto es importante para crear una base de código fácil de mantener.
Las bibliotecas de patrones son una colección de elementos comunes utilizados en un sitio web. Al enfocar el desarrollo del front-end en la construcción de componentes que no dependen de las páginas, podemos reducir la sobrecarga del código y mejorar la consistencia.
Usando la lista de componentes que recopilamos durante la etapa de auditoría, podemos estructurar nuestro Sass en una colección manejable de archivos.
Hemos utilizado bibliotecas de patrones en algunos proyectos, pero siempre hemos tenido problemas con las convenciones de nombres, particularmente la estructura de carpetas: ¿dónde colocas tus estilos para este reproductor de música, en componentes o en parciales?
Anteriormente, habíamos usado terminología como parciales y componentes para organizar nuestros archivos Sass. Si bien estos parecen convenciones de nombres completamente legítimos, están abiertos a la interpretación. Cuando hay múltiples desarrolladores trabajando en un proyecto, dejar la organización de la base de código abierta a la interpretación conduce a CSS no organizado.
BEM (Bloquear, Elemento, Modificador), nos proporciona una convención común a seguir y crea una comprensión entre los desarrolladores de aplicaciones para el usuario. La vieja forma fue dejada a los desarrolladores individuales para llegar a los nombres de las clases que eran de muy alto nivel para recoger cualquier significado. Afortunadamente tuvimos la suerte de ver Brad Frost hablar sobre su biblioteca de patrones en el Conferencia Upfront en Manchester. Pattern Lab presta terminología de la química para describir los componentes que componen la biblioteca. Usar átomos, moléculas y organismos para describir las diferencias entre los componentes en una página ayuda a explicar el concepto a los desarrolladores nuevos en el proyecto.
El diseño atómico es para las interfaces de usuario: http://t.co/eEZSYeK5VF Puede aplicar un diseño atómico a cualquier interfaz de usuario, como Instagram pic.twitter.com/BrztgtRoGU
- Brad Frost (@brad_frost) 10 de julio de 2015
En la naturaleza, los átomos son la denominación más pequeña (a menos que profundicemos en los quarks y los electrones). En el desarrollo web, los átomos son los elementos más básicos de HTML. A todos los efectos, no hacen mucho por sí mismos. Estos incluyen encabezados, párrafos, entradas, botones, listas ... Te da la idea.
Estas son la siguiente capa. En química, las moléculas están compuestas de átomos, y lo mismo se aplica a la estructura de CSS. Las moléculas son componentes en el sitio web que usan átomos para formarlos.
Un buen ejemplo de una molécula es un cuadro de búsqueda. Este contiene 3 átomos: una etiqueta, entrada y botón. La capa de molécula comienza a formar algunos de los elementos que podemos usar en el sitio web. Es importante hacer que todas estas moléculas sean escalables. Deben diseñarse con la idea de que podrían usarse en cualquier parte del sitio. Nuestro objetivo final es hacer que el CSS sea lo más flexible y reutilizable posible.
Como su nombre indica, los organismos son agrupaciones de moléculas. Algunos ejemplos de estos incluyen un encabezado, pie de página o lista de productos.
Si tomamos el ejemplo de un encabezado, esto incluiría un logotipo, búsqueda y navegación. Todos fueron creados como moléculas y se combinan para formar un organismo de cabecera.
Aquí es donde termina la analogía bioquímica. Como dice Brad, "entrar en un lenguaje que tenga más sentido para los clientes y la producción final" . Las plantillas son el pegamento de un sitio web. Estos combinan todos los organismos que hemos creado en un diseño que podría aplicarse a una página en el sitio web.
Un ejemplo podría ser una lista de blogs. Esta plantilla incluiría un encabezado, pie de página, una lista de artículos del blog y una barra lateral. Las plantillas son generalmente estructurales, que contienen solo el diseño.
La sección final es páginas. Aquí es donde puedes probar las plantillas con datos reales. Las páginas son instancias específicas de una plantilla. Esta parte es importante porque nos permite ver cuán exitosos han sido los átomos, las moléculas, los organismos y las plantillas.
Es inevitable que al construir el sitio web, se pierdan algunos escenarios. El ejemplo clásico es títulos largos, o catering para diferentes monedas e idiomas.
Punto clave: las convenciones de nomenclatura son importantes. Layering CSS crea una base de código limpia desde la cual es lo más pequeña posible.
Diseñar patrones es difícil. No puede diseñar un patrón aislado, como una noticia, y esperar que encaje con el resto de la página. La forma en que construimos sitios web y la forma en que los diseñamos difieren.
Es probable que los diseños cambien independientemente de que obtengamos la aprobación ... La aprobación se convirtió en un paso irrelevante en el proceso que solo ejerció presión sobre ambos lados
Usamos Photoshop para crear maquetas de los marcos de alambre con estos componentes de estilo en su lugar. Una vez que estuvimos contentos con la apariencia de los diseños, pasamos a aislar cada componente. Esto nos permitió garantizar que cada componente fuera lo suficientemente flexible para funcionar en cualquier parte del sitio web.
Fuimos muy conscientes de no cerrar sesión en ningún trabajo de diseño. La firma del diseño crea una barrera donde el diseñador se siente presionado para crear algo que será grabado en piedra. Es probable que los diseños cambien independientemente de si tenemos la aprobación o no. En general, nos complace dar cabida a cualquier cambio en cualquier momento de la línea de tiempo del proyecto. La cancelación se convirtió en un paso irrelevante en el proceso que solo ejerce presión sobre ambos lados en detrimento de la relación.
Saber cuándo pasar de Photoshop a código es importante. Este paso es mucho más temprano de lo que estábamos acostumbrados por dos razones:
En lugar de pasar más tiempo en Photoshop, optamos por invertir el tiempo en el código. Si deberíamos perfeccionar algo, debería ser el código, el bit que realmente usarán y verán todos los usuarios del sitio web. Para nosotros, Photoshop fue una herramienta para crear un estilo de diseño que podría usarse en todo el sitio web.
El diseño es mucho más acerca de la colaboración entre todos en el equipo. Las maquetas todavía eran una parte muy importante del proceso y ayudaban al cliente a visualizar cómo se vería el sitio. Si todos estuviéramos satisfechos con la dirección general del diseño, lo moveríamos al código. Rara vez pasamos tiempo yendo y viniendo a reparar documentos de Photoshop.
Key takeaway: Photoshop es una gran herramienta para crear conceptos de diseño. Pasar al código lo antes posible es importante. Perfecto en código, no en Photoshop.
La belleza de este flujo de trabajo es que hay muchos lugares para revisar y mejorar el sitio web.
Es importante tener en cuenta que estos son pasos sueltos en nuestro proceso de proyecto. Si necesitamos algo nuevo durante el proyecto, generalmente lo trataremos como un componente modular independiente que se puede incluir en el sitio web y adoptar el tema de diseño del sitio.
Cada uno de estos pasos ofrece un punto donde podemos revisar nuestro trabajo hasta el momento. También permite un nuevo par de ojos para ver las cosas desde una perspectiva diferente.
Durante cualquiera de estas etapas, podemos encontrar que algunas partes no funcionan tan bien como se esperaba. Esto está bien. De hecho, es bueno. Atrapar la usabilidad deficiente desde el principio es la clave para un sitio web exitoso. Volver atrás y enmarcar estas partes del sitio web mejorará el proyecto cuando se publique.
Punto clave: No tengas miedo de volver al principio si algo necesita mejorar. Tomar estos principios hará que el proyecto sea mejor cuando entre en funcionamiento.
Pasamos días trabajando juntos para asegurarnos de que cada parte del sitio web tuviera un alto nivel. Probamos tantos escenarios como fue posible, asegurando que la experiencia de navegación fuera consistente.
Una vez que los datos están en el sitio web, podemos probar completamente el sitio web. A menudo es muy fácil establecer un proyecto en vivo sin una prueba completa. Podemos verificar la velocidad, la facilidad de navegación y, lo que es más importante, el flujo de compras.
Todo el mundo menciona a Apple por ser perfeccionista, pero estoy seguro de que sus primeros intentos estuvieron lejos de ser perfectos. Toma tiempo y dedicación hacer esas mejoras finales para darnos los productos que amamos hoy. Al usar nuestro laboratorio de dispositivos, que incluye la mayoría de los dispositivos y plataformas populares, pudimos garantizar que la experiencia se optimizara en la mayor cantidad de plataformas y tamaños de pantalla posibles.
El aprendizaje de cada proyecto es importante para que podamos mejorar continuamente los procesos que conducen a mejores sitios web.
Este proyecto vio el nacimiento de nuestra propia biblioteca de patrones interna que fomenta la coherencia entre los proyectos. Cuando trabajamos en una agencia, podemos tener docenas de proyectos actualmente en desarrollo simultáneamente. La capacidad de cualquier persona para trabajar en cualquier proyecto es importante.
Crear una base en la que todos podamos trabajar ayudará a contribuir a este objetivo.
El rendimiento del sitio web solo se consideró hacia el final del proyecto. Un sitio web receptivo exitoso debe ser ágil y rápido. La gran variedad de dispositivos y sus capacidades varían enormemente desde nuevas computadoras Mac hasta teléfonos inteligentes antiguos. Cuando se crea un sitio web rico en medios, puede ser muy difícil administrar el rendimiento, especialmente cuando se intenta mejorarlo de forma retrospectiva.
En Upfront Conference en Manchester, vimos Yesenia Pérez Cruz hablar sobre considerar el rendimiento en cada etapa de un proyecto, incluido el diseño. En retrospectiva, esto es algo que deberíamos haber implementado. Como equipo de múltiples diseñadores, desarrolladores y desarrolladores de aplicaciones para el usuario, la gestión del tamaño y el rendimiento general (en particular, el rendimiento percibido) debería haber sido una prioridad mayor.
Todo en una página tiene un costo de rendimiento. Priorizar lo que es importante garantiza que el sitio web no solo sea rápido, sino también accesible para más dispositivos. En algunos dispositivos más antiguos, descubrimos que el sitio web se colgaba no solo del navegador, sino de todo el dispositivo. Intentar acelerar el sitio web de forma retroactiva significaba que no podíamos hacer el sitio web tan rápido como podría haberlo sido.
La próxima vez nos aseguraremos de que el rendimiento esté incrustado en cada etapa del proceso, por lo que no es una idea de último momento.