Decisiones de los desarrolladores para crear componentes flexibles

En el mundo real, el contenido a menudo difiere mucho del contenido limpio y perfectamente ajustado que se presenta en los diseños. Además de eso, en la web moderna, los usuarios tienen una gama cada vez mayor de opciones sobre cómo acceden a los sitios que construimos.

En este artículo, recorreremos el proceso de tomar un diseño aparentemente simple para un componente de texto y medios y decidir cuál es la mejor manera de traducirlo en código, teniendo en cuenta las necesidades tanto de los usuarios como de los autores de contenido. No vamos a profundizar en cómo codificarlo, sino en los factores que determinarán nuestras decisiones de desarrollo. Consideraremos las preguntas que debemos hacernos (tanto a nosotros mismos como a otras partes interesadas) en cada paso.

Cambiando nuestra mentalidad de desarrollo

Simplemente ya no podemos diseñar y desarrollar solo para contenido o condiciones de navegación "óptimas". En su lugar, debemos adoptar la flexibilidad inherente y la imprevisibilidad de la web y construir componentes resilientes. Las maquetas estáticas no pueden adaptarse a todos los escenarios, por lo que muchas decisiones de diseño recaen en los desarrolladores en el momento de la construcción. Te guste o no, si eres un desarrollador de interfaz de usuario, eres un diseñador, ¡incluso si no te consideras uno!

En mi trabajo en la agencia web especializada en WordPress Atomic Smash , construimos sitios web para clientes que necesitan la máxima flexibilidad de los componentes que proporcionamos, al mismo tiempo que nos aseguramos de que el sitio se vea excelente, sin importar el contenido que le arrojen. A veces, interpretar un diseño significa pedirle al diseñador que elabore más sus ideas (o incluso que las vuelva a evaluar). Otras veces, significa tomar decisiones de diseño sobre la marcha o hacer recomendaciones basadas en nuestro conocimiento y experiencia. Veremos algunas de las veces que estos enfoques podrían ser apropiados en este estudio de caso.

El diseño

Comenzamos con un diseño simple para un componente de texto y medios, algo que se ve con bastante frecuencia en las páginas de destino de los productos. Consiste en una imagen o video a la izquierda y una columna a la derecha que contiene un encabezado, un párrafo de texto y un enlace de llamada a la acción. Este diseño es para una startup (ficticia) que ayuda a las personas que quieren aprender una nueva habilidad a encontrar un tutor.

Nota: Si desea ir directamente al código y ver todas las posibles soluciones que encontramos para este componente, puede encontrarlo en esta demostración de Codepen.

Disposición y orden

El diseñador ha estipulado que todos los demás componentes deben tener el diseño invertido para que la imagen esté a la derecha y la columna de texto a la izquierda.

Sin embargo, en el diseño móvil, la imagen se apila sobre el contenido del texto en todos los casos. Suponiendo que creamos este diseño usando Grid o flexbox, podríamos usar flex-direction o la propiedad order para reordenar el diseño para cada segundo componente:

 .text-and-media:nth-child(even) { flex-direction: row-reverse; }

Vale la pena tener en cuenta que si bien estos reordenarán el contenido visualmente, no cambia el orden del DOM. Esto significa que para una persona con problemas de visión que navega por el sitio usando un lector de pantalla, el orden del contenido puede no parecer lógico, saltando de izquierda a derecha y de derecha a izquierda.

Hablando personalmente, en el caso de que el único contenido en una de las columnas sea una imagen, creo que usar la propiedad order está más o menos bien. Pero si tuviéramos dos columnas de texto, por ejemplo, reordenar con CSS podría resultar una experiencia confusa. En esos casos, tenemos algunas otras opciones disponibles para nosotros. Pudimos:

1. Presentar nuestras preocupaciones de accesibilidad y recomendar que, para los diseños móviles, se cambie el orden visual para que coincida con el orden del escritorio.
2. Use Javascript para reordenar los elementos en el DOM.

También debemos considerar si aplicar la orden a través del selector :nth-child o permitir que el cliente controle la orden (por ejemplo, agregando una clase al componente). La idoneidad de cada opción probablemente dependerá del proyecto.

Tratar con diferentes longitudes de contenido

En el diseño, la proporción de contenido de texto en comparación con la imagen es bastante agradable. Permite que la imagen mantenga una relación de aspecto ideal. Pero, ¿qué debería pasar si el texto es más largo o más corto que lo que se presenta? Tratemos primero con lo primero.

Contenido más largo

Podemos establecer un límite de caracteres en el campo de texto en nuestro CMS elegido (si así lo deseamos), pero debemos permitir al menos alguna variación en nuestro componente. Si agregamos un párrafo más largo, la columna de medios opuesta podría comportarse de varias maneras:

1. La imagen o video permanece en la parte superior, mientras que se agrega un espacio debajo (fig. 1).
2. Se centra la imagen o video, agregando espacio en la parte superior o inferior (fig. 2).
3. Las proporciones de la imagen o el video se escalan para que coincidan con la altura, usando object-fit: cover para evitar distorsiones y asegurar que la imagen llene el espacio disponible. Esto significaría que algunas partes de la imagen pueden estar recortadas (fig. 3).

Decidimos que la opción 3 era la más agradable visualmente y que, en su mayor parte, los autores de contenido podrían obtener imágenes apropiadas en las que sería aceptable una pequeña cantidad de recorte. Pero presentó un mayor desafío para el contenido de video, donde existe un mayor riesgo de que se puedan recortar partes importantes. Nos decidimos por otra opción, que era crear una variación diferente del diseño donde el video mantendría su relación de aspecto original y estaría contenido dentro de un ancho máximo en lugar de alinearse con el borde de la página.

Los autores de contenido podrían elegir esta opción cuando mejor se adapte a sus necesidades.

Además, optamos por extender esta opción a instancias en las que se usó una imagen en lugar de un video. Brinda al cliente una variedad más amplia de opciones de diseño sin afectar negativamente el diseño. Visto en el contexto más amplio de la página, incluso podría considerarse una mejora, lo que permite páginas más interesantes cuando se utilizan varios de estos bloques en una página.

Contenido más corto

Lidiar con menos contenido es un poco más simple, pero aún nos presenta algunos problemas. ¿Cómo debe comportarse la imagen cuando el contenido del texto es más corto? ¿Debería volverse menos profundo, de modo que la altura total del componente esté determinada por el contenido del texto (fig. 4)? ¿O deberíamos establecer una relación de aspecto mínima, para que la imagen no se convierta en un formato de pantalla ancha, o permitir que la imagen tome su altura natural e intrínseca? En ese caso, también tenemos la consideración de si alinear el texto en el centro o en la parte superior (fig. 5 y 5a).

Longitud del encabezado

No olvidemos que también necesitaremos probar encabezados de diferentes longitudes. En el diseño, los encabezados son breves y ágiles, y rara vez se envuelven en una segunda línea. Pero, ¿qué pasa si un encabezado tiene varias líneas o el contenido usa muchas palabras largas, lo que da como resultado que el texto se ajuste de manera diferente? Esto podría ser especialmente un problema en idiomas como el alemán, donde las palabras tienden a ser mucho más largas que en inglés, por ejemplo. ¿El tamaño de la fuente del encabezado en el diseño permite una longitud de línea adecuada cuando se usa en este diseño? ¿Deberían separarse las palabras largas cuando terminan? Este artículo de Ahmad Shadeed aborda el problema de la longitud del contenido e incluye algunos consejos prácticos sobre cómo abordarlo en CSS.

¿Se les permite a los autores de contenido omitir un encabezado por completo cuando les convenga? Eso nos lleva a la siguiente consideración.

Omitir contenido

Construir este componente de la manera más flexible posible significa asegurarse de que los autores de contenido puedan omitir ciertos campos y aún así tener el aspecto del diseño y funcionar correctamente. Parece razonable que el cliente desee omitir el texto del cuerpo, el enlace o incluso el encabezado cuando utilice este componente en la naturaleza. Debemos tener cuidado de probar con cada combinación imaginable de contenido, para que podamos estar seguros de que nuestro componente no se romperá bajo estrés. Es una buena práctica asegurarse de no mostrar etiquetas HTML vacías cuando el contenido del campo no está presente. Esto nos ayudará a evitar errores de diseño imprevistos.

Podemos restringir a los autores de contenido con campos "obligatorios" en el CMS, pero tal vez también deseemos considerar escenarios en los que un cliente podría optar por omitir la imagen o, por el contrario, sin contenido de texto. Podría ser útil proporcionarles estas opciones. Aquí hay un ejemplo de cómo podemos elegir renderizar el componente en esos casos:

Al sangrar un poco más el texto y aumentar el ancho del cuerpo del texto, podemos mantenerlo equilibrado, incluso cuando no hay imagen.

Múltiples enlaces

Omitir contenido es un escenario. Pero en Atomic Smash, descubrimos que, con mayor frecuencia, los clientes querían la opción de agregar más de un enlace al componente. Eso nos presenta otra opción: ¿cómo diseñar múltiples enlaces? ¿Los colocamos uno al lado del otro (fig. 8) o los apilamos verticalmente (fig. 8a)?

¿Cómo lidiamos con títulos de enlaces de longitudes muy diferentes? Un buen truco es establecer el ancho de ambos enlaces al ancho máximo del más largo (fig. 9). (Este artículo cubre exactamente eso). Eso funciona bien para los botones apilados verticalmente, mientras que colocarlos horizontalmente nos presenta aún más opciones (fig. 9a).

¿Necesitamos un estilo de enlace secundario, para diferenciarlos? Todas estas son preguntas a considerar.

Es posible que también debamos considerar (en el caso de un solo enlace) si, de hecho, el área del enlace en la que se puede hacer clic debe abarcar todo el componente, de modo que los usuarios puedan hacer clic en cualquier lugar para activar el enlace. Esa elección quizás dependa del contexto más amplio. Sin duda, es común en las interfaces de usuario basadas en tarjetas.

Video

Cuando el componente se usa para video en lugar de una imagen estática, podemos notar que el diseño omite alguna información clave. ¿Cómo se controla la reproducción de vídeo? ¿En vuelo estacionario? ¿Se reproduce automáticamente al desplazarse? ¿Debe haber controles visibles para el usuario?

Si el video se reproduce al pasar el mouse, debemos considerar cómo el usuario de un dispositivo sin capacidades de desplazamiento accede al contenido del video. Alternativamente, si el video se reproduce automáticamente, deberíamos considerar evitar esto para los usuarios con preferencia por el movimiento reducido, que pueden sufrir trastornos vestibulares (o simplemente desean evitar animaciones discordantes). También deberíamos proporcionar una forma para que todos los usuarios detengan el video cuando lo deseen.

Poniéndolo en contexto

Un problema de centrarnos tanto en los componentes cuando se trata de diseño web es que a veces nos olvidamos de considerar cómo aparecerán los componentes que construimos en el contexto de la página web en general. Tendremos que considerar el espaciado, tanto entre componentes del mismo tipo como en un diseño de página donde se intercalan otros componentes.

Estos componentes de texto y medios están diseñados para usarse con moderación, creando un llamativo toque de color y una ruptura con un diseño lineal. Pero al usar WordPress, un autor de contenido podría decidir fácilmente crear una página completa compuesta únicamente por estos componentes. ¡Eso podría terminar pareciendo bastante aburrido, y no en absoluto el efecto que esperábamos!

Durante el proceso de construcción, decidimos agregar una opción para omitir el color de fondo. Eso nos permite dividir la página y hacerla más interesante:

Podríamos aplicar un patrón usando :nth-child o agregar un campo en el CMS para darle al cliente un control más creativo.

Aunque esto no formaba parte del diseño original, muestra que una línea abierta de comunicación entre el diseñador y el desarrollador puede ayudar a crear mejores resultados en términos de diseños más flexibles y sólidos.

Estilos de texto WYSIWYG

Al considerar el contenido, debemos tener en cuenta no solo la longitud del texto, sino también los elementos HTML reales que podrían estar permitidos en el campo de texto del cuerpo. Los autores de contenido pueden querer agregar varios párrafos, enlaces ancla, listas y más al cuerpo del texto. En Atomic Smash nos gusta proporcionar un campo de texto enriquecido o WYSIWYG (Lo que ves es lo que obtienes) para estas áreas, que puede permitir muchos elementos diferentes. Es importante realizar pruebas con diferentes tipos de contenido y el estilo adecuado, incluidas las pruebas de contraste de color suficiente en todos los colores de fondo utilizados.

Terminando

Hemos abordado muchas decisiones diferentes relacionadas con la construcción de este componente aparentemente simple. ¡Incluso podría pensar en algunos otros que no hemos cubierto aquí! Al considerar cada aspecto del diseño y cómo podría usarse en contexto, hemos terminado con algo mucho más versátil, que con suerte debería resultar en clientes más felices.

A veces, cuanto más se omite de un diseño, más tiempo y atención requerirá un desarrollador. A continuación, he reunido una lista de verificación de cosas para probar y cuestionar al crear un componente, que puede resultarle útil. También se puede adaptar para diferentes componentes.

Ser capaz de mirar más allá de la aparente simplicidad, desglosar un componente en sus partes constituyentes, hacer preguntas clave (incluso antes de que se lleve a cabo cualquier desarrollo) e incluso considerar usos futuros, son todas habilidades que serán de gran utilidad para cualquier desarrollador al crear sitios web, y le ayudará a proporcionar estimaciones mucho más precisas cuando sea necesario. La buena comunicación del equipo y un sólido proceso de colaboración son invaluables para construir sitios resilientes, pero el resultado final hace que valga la pena invertir en fomentar esta cultura. Incorporemos flexibilidad a nuestros procesos de diseño y construcción.

La lista de verificación

Cosas para probar:

1. Accesibilidad del diseño (móvil y escritorio).
2. Imágenes de diferentes relaciones de aspecto intrínsecas: ¿se recortan correctamente?
3. Cuerpo de texto más largo y más corto (incluidos varios párrafos).
4. Encabezado más largo y más corto (incluidas varias longitudes de palabra).
5. Omitiendo (de forma diversa) el encabezado, el cuerpo del texto, los enlaces y la imagen.
6. Múltiples enlaces (incluidas diferentes longitudes de texto del enlace).
7. Accesibilidad del contenido de vídeo.
8. Contenido de texto WYSIWYG (incluye enlaces, listas, etc. en el cuerpo del texto).
9. Pruebe en contexto: incluya múltiples componentes (con diferentes opciones de contenido), así como otros componentes mezclados en el diseño de la página.