Universitat Oberta de Catalunya

Rediseño responsive de Mosaic (parte II): Desarrollo front-end

El rediseño de la revista Mosaic debía concebirse en una estructura responsive e integrarse en el CMS WordPress. Tras la concepción inicial, explicada en el artículo anterior, procedimos a desarrollar los diferentes layouts que componían la web y que seguirían una estrategia de desarrollo mobile first: decidir primero la distribución para la pantalla pequeña, e ir haciendo correcciones de estilo mediante media queries para las pantallas más grandes.

Layouts y breakpoints

En una web responsive, los puntos donde confluyen varios cambios de estilo o cambios estructurales se conocen como breakpoints o puntos de corte. En Mosaic, estos puntos no están seleccionados en base a las dimensiones de ningún dispositivo en concreto, sino que se decidieron en función de las necesidades del contenido: cuando un contenido dejaba de verse correctamente, se aplicaba una corrección mediante una media query.
De esta forma, hay un layout básico al que se aplican modificaciones en cuatro puntos: a partir de 400px, de 700px, de 1025px y de 1400px. Además, las media queries se escribieron en ems (25em, 43.75em, 64em y 87.5em) para facilitar la adaptación del layout en caso de el tamaño de letra base del navegador fuera diferente de 16px.

Navegación responsive

La navegación de la revista Mosaic se dividió en 2 niveles principales: general (Noticias, Archivo, Formación, Acerca de) y por bloques temáticos (Diseño, Interacción, Tecnologías, Redes). Además, contaba con un buscador y casi 30 subcatergorías que dependían de los bloques temáticos. Gestionar toda esta información en pantalla pequeña era uno de los principales retos de este rediseño responsive.
Para que la navegación no dependiera exclusivamente de JavaScript, y al mismo tiempo evitar flashes de redibujado en el layout, la técnica empleada fue la de cargar los links de navegación en el footer e introducir enlaces en la cabecera hacia estas secciones: si JavaScript no estuviera disponible, accionar estos enlaces llevaría directamente al footer; si JavaScript estuviera disponible, sobreescribiría el comportamiento de estos enlaces y se desplegaría el menú siguiendo un patrón de fly-out (oculto en un lateral, desplegado desplazando el contenido hacia la derecha). Para pantallas más grandes, estos enlaces internos se ocultarían y la navegación principal, ubicada en el footer, se posicionaría absolutamente en la parte superior.

Captura de pantalla donde se muestra navegación en móvil sin JS activado y con JS activado
Navegación en móvil sin JS activado y con JS activado

Iconografía

Desde la irrupción de las pantallas de alta densidad de píxeles, se han popularizado los formatos vectoriales para mostrar iconos, sea con archivos SVG o con tipografías de iconos. Para Mosaic decidimos emplear una tipografía de iconos por su versatilidad (la tipografía constituye en sí misma una especie de sprite y es fácil de modificar con CSS), y creamos la tipografía a medida con la herramienta Icomoon.
Sin embargo, optar por una tipografía de iconos suponía una complicación para los navegadores que no soportasen la propiedad @font-face (por ejemplo, Opera Mini), por lo que para suplir este problema decidimos detectar el soporte de esta propiedad con la librería Modernizr y mostrar, en caso de no soporte, un texto alternativo que indicara al usuario a qué acción correspondería el link de cada icono.

Vista de Mosaic en Opera Mini, con texto alternativo en lugar de iconos
Vista de Mosaic en Opera Mini, con texto alternativo en lugar de iconos

Imágenes y vídeos

Los artículos de Mosaic cuentan a menudo con imágenes y vídeos que ilustran sus contenidos. Para las imágenes, decidimos evitar los plugins habituales y crear una lightbox propia que permitiera mostrar una imagen a tamaño más grande sin salir de la página. Decidimos no incluir una función de galería porque no respondía al flujo normal de lectura de un artículo.
Los vídeos cargados desde un proveedor externo (Youtube, Vimeo…) suponían un problema mayor para una estructura responsive, pues al contrario que las imágenes o los vídeos propios, un iframe no se suele redimensionar manteniendo un aspect-ratio en concreto. Una solución habitual para este problema es una librería de JavaScript llamada FitVids.js, pero finalmente decidimos resolverlo con un juego de position y padding como el que se propone en embedresponsively.com.
Para toda la integración en WordPress tuvimos la suerte de contar con la ayuda de Núria Ramoneda, que preparó la template y coordinó la transición a una nueva Mosaic con 10 años de antiguos contenidos, sobre lo que hablará en el siguiente artículo. Ha sido un proyecto con muchos retos y novedades para nosotros, y hemos tenido la oportunidad de trabajar con un equipo excepcional del que hemos aprendido muchísimo.


Cita recomendada: USOBIAGA, Javier y ARMADA, Marta. Rediseño responsive de Mosaic (parte II): Desarrollo front-end. Mosaic [en línea], mayo 2014, no. 118. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n118.1422.

Etiquetas:

Acerca de los autores

Javier es diseñador web y desarrollador front-end desde 2005, y vive en Barcelona. En 2009 fundó junto a Marta (su mujer) Swwweet, un pequeño estudio de diseño web, donde trabajan creando páginas web para negocios pequeños y startups. Javier ha dado varias charlas y workshops tanto en eventos locales como en conferencias de ámbito internacional, y es profesor de diseño web en ELISAVA Escuela Superior de Diseño.

Marta es una diseñadora web de Barcelona. Le interesa la tipografía, el diseño web responsive, CSS, UX o el diseño en general: cualquier cosa que ayude a hacer una web mejor. En 2009 fundó junto a Javier (su marido) Swwweet, un pequeño estudio de diseño web, donde trabajan creando páginas web para negocios pequeños y startups. Marta ha dado varias charlas y workshops tanto en eventos locales como en conferencias de ámbito internacional, y es profesora de diseño web en ELISAVA Escuela Superior de Diseño.

3 comentarios

Deja un comentario

  1. Muy buenas.

    Antes de nada, felicitar por esta serie de artículos, de la que uno puede aprender tanto.

    Me ha llamado la atención especialmente el tema de la fuente de iconos. Conozco el método, y alguna vez lo he usado (de hecho, también con la herramienta de Icomoon), pero me plantea serias dudas para usarlo en web.

    El caso es que los navegadores suelen renderizar medio en condiciones las fuentes, pero cuando hablamos de Google Chrome la cosa cambia. Chrome les aplica un fuerte aliasing para que sean bien legibles el 100% de los casos (supongo que aquí influyen cuestiones más técnicas de kerning y demás). Eso, para las fuentes de iconos, actúa como un arma de doble filo; porque pierden detalles a tamaños pequeños y se ven “con dientes de sierra”. Desde entonces, he optado por usar iconos en SVG directamente; porque quedan suaves y como yo quiero que se vean.

    ¿Algún apunte de por qué debe ser preferible un método a otro, teniendo en cuenta los problemas que Chrome plantea?

    Respon
  2. A día de hoy es imprescindible adecuarse a diseños responsive porque, en función del sector del que trate la web, los ratios de visitas procedentes de dispositivos móviles superan el 60% del total, y eso es mucho decir.

    Saludos!

    Respon

Deja un comentario