Disclaimer:
Recuperación de un post antiguo.
Internet no deja de evolucionar en todos los sentidos. Hay cambios que se van poniendo de moda y luego, poco a poco, se van dejando de lado. Sin embargo, otros llegan con suficiente fuerza como para que todos sepamos que marcan el «camino a seguir». A nivel tecnológico, el uso de dispositivos móviles supuso un antes y un después y, a raíz de ellos y su progreso, apareció el concepto de «responsive design» o en español «diseño adaptativo» y, más recientemente, el concepto de «mobile-first».
¿Qué diferencian el «diseño responsive» del concepto «mobile-first»?
El «responsive design» es un sistema basado en los estándares web recientes que permite que nuestras webs se adapten a la pantalla del usuario que está viéndolas. Pero esta definición va mucho más allá, ya que estamos hablando de webs con diseños inteligentes (smart que dirían los ingleses) que facilitan la usabilidad de las webs, en función de quién las observa.
Pero el «responsive design» no supone únicamente llevar a cabo simples añadidos a una web, es una filosofía del desarrollo del front de la misma, totalmente distinta y que abarca una gran cantidad de detalles para mejorar la experiencia del usuario durante la navegación en desktop o mobile.
Y precisamente por el hecho de que en los últimos años los usuarios han ido usando más sus dispositivos móviles en su experiencia de navegación online, que este concepto ha evolucionado a lo que hoy conocemos como la filosofía del «mobile-first», que no solo aboga por el desarrollo de webs mucho más «mobile-friendly», sino que prioriza el diseño y maquetación de las pantallas pequeñas sobre las de escritorio, incluso con la realización de apps móviles específicas.
Ahora bien, ¿es esto viable para la mayoría de negocios? Lo cierto es que no. Por un lado, es fundamental entender el comportamiento de los usuarios de cada negocio y fundamentarse en los datos que nos dicen qué dispositivo prefiere. Por otro, no todos los negocios pueden permitirse el desarrollo de una app, o bien, no se encuentran en un momento en el que puedan invertir en el rediseño de una nueva web «mobile-first» que, además, esté optimizada.
Entonces, ¿qué podemos hacer?
Como acabo de decir, no lanzarnos a rediseñar todas nuestras webs no significa que no podamos aprovechar las nuevas posibilidades que se nos brindan para hacer pequeños cambios y, por lo tanto, mejorar sensiblemente su adaptación a distintos navegadores y dispositivos.
Para ello, lo que tenemos que ver es cómo es nuestra web. Sobre todo a nivel de maquetación y fundamentalmente estructura HTML y CSS y a partir de ahí ver qué pequeñas mejoras queremos aplicar.
Consideraciones previas y hacks a conocer
Antes siquiera de plantearnos la posibilidad de «arreglar» nuestras webs para hacerlas más adaptables tenemos que conocer algunas técnicas y consejos que nos vendrán muy bien para trabajar y sin los cuales el trabajo no se hace solo complicado, sino casi imposible.
1. El HTML semántico no es imprescindible pero ayuda.
Una web en HTML semántico es una web cuya maqueta se ha realizado correctamente. Donde se han usado solo los elementos HTML imprescindibles, pensando más en el significado de cada etiqueta que en el diseño y dejando por lo tanto todo el trabajo de diseño al CSS en base a clases e ID’s.
Si bien no es necesario usar correctamente los DIV, P, UL, LI, etc. en nuestras maquetas para hacer «responsive design» lo que sí que es cierto es que, al menos, la parte de eliminar todo el diseño de la maqueta debemos cumplirla. Es decir, no podemos usar CSS intrusivo (nada de atributos «style» en medio del código) y cuanto más limpio (y con menos divs) sea nuestro HTML más fácil será realizar las adaptaciones, pues el CSS tendrá más poder sobre el resultado final.
2. Elección del Zoom en los navegadores móviles.
Dado que está claro que han existido antes los navegadores móviles que los diseños adaptados a ellos estos usaron desde el principio herramientas de zoom para poder visualizar webs completas. Si tú entras en una web normal con un móvil no verás la resolución real de tu móvil sino una versión que realiza un zoom para adecuarse a los 960px de ancho.
Este es su comportamiento por defecto, sin embargo, también se han creado etiquetas HTML para cambiarlo. De esta forma, si nosotros vamos a adaptarnos a resoluciones móviles podemos simplemente indicarle al móvil que use otro tipo de escalado.
Para ello, se usa la meta-etiqueta «viewport» (a incorporar en el head de la página), donde podemos especificar el comportamiento que esperamos que tenga un navegador de estas características en nuestra web.
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Esta es la configuración de la etiqueta viewport más usada para «responsive design», pero no es la única que podemos usar. Debemos entender las dos variables que aquí aparecen para que el móvil se adapte a nosotros y no al revés.
2.1. width.
El ancho que forzamos al móvil a adoptar con la web. Normalmente se indica cómo «device-width» para que se muestre la resolución real del dispositivo pero dependiendo del diseño que finalmente hayamos creado en la web es posible que queramos especificar un tamaño fijo que coincida con la resolución que hemos preparado nosotros para la versión móvil de nuestra web.
En webs que no llegan a ser del todo adaptables resulta muy útil, al poder controlar el ancho de nuestro navegador. Imaginemos que tengo una web de 1200px de ancho y no voy a hacerla responsive. Indicando el width a 1200px al menos conseguiré que la primera visualización desde móvil la contemple entera.
2.2. initial-scale.
Con esta orden indicamos el valor del zoom que queremos que use el móvil. Siendo 1.0 una visualización sin Zoom y 2.0 una ampliación de toda la web al doble de su tamaño.
Por supuesto si vamos a crear un diseño adaptado al ancho del móvil la configuración de initial-scale=1.0 es la adecuada pues pedimos al móvil que no haga ningún tipo de zoom, pero en muchas ocasiones será mejor no usar esta variable y permitir al móvil que adapte él solo el zoom al width que le hemos definido.
Por ejemplo, si indicamos que nuestro width es de 500px e indicásemos initial-scale, la web tomaría el aspecto de una pantalla de 500px pero nosotros en el móvil solo veríamos la configuración original del móvil (que equivaldrían a unos 320px de los 500px totales por lo general). Sin embargo si no indicamos initial-scale la web se mostraría con el zoom adaptado para verla completa (seguramente los 500px declarados).
Por lo tanto tenemos dos típicas configuraciones de viewport…
Para webs con «responsive design» adaptado perfectamente a resoluciones móviles:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Para webs que no se han adaptado del todo a resolución móvil:
<meta name="viewport" content="width=[Pixeles del mínimo ancho para visualizar bien la web]">
Existen otras configuraciones, como por ejemplo crear webs con un ancho de móvil pero con zoom ya aplicado para mostrar solo una parte… pero son webs extrañas con una usabilidad dudosa.
3. Las media queries.
Las media queries son sentencias del CSS que nos permiten hacer declaraciones que sólo se apliquen en nuestros diseños si se cumplen ciertos requisitos que nosotros declaramos. Estas media queries se pueden aplicar básicamente en dos posibles puntos de la web.
- Al llamar al archivo css, indicando en cada uno las condiciones para cargarlo
- O en el propio archivo CSS, formando un apartado donde incluir fragmentos de css a aplicar
Las media queries son realmente potentes y permiten salirse del «responsive design» para cubrir aspectos muy diversos de nuestras webs. Seguidamente incluyo unos links para que puedas informarte sobre ellas ya que no quiero complicar este post con explicaciones de cosas que luego no vamos a usar.
Para lo que nos interesa nos basta saber dos cosas. Por un lado, cómo se declaran estas medias queries en nuestro archivo CSS y, por otro, cómo dotar a los navegadores Internet Explorer antiguos de esta funcionalidad.
3.1 Declaración de media queries.
Para declarar un fragmento de CSS dentro de un condicional marcado por una media query:
@media screen and ([CONDICION]) {
/* Nuestras nuevas reglas con este ancho o menos de pantalla */
}
Donde además veremos que lo más seguro es que apliquemos condiciones basadas en el ancho de pantalla que generan tres tipos de media queries:
– Aplicar solo en resoluciones de menos de X píxeles de ancho:
@media screen and (max-width:[ANCHO]px) {
/* Nuestras nuevas reglas con este ancho o menos de pantalla */
}
– Aplicar solo en resoluciones de más de X píxeles de ancho:
@media screen and (min-width:[ANCHO]px) {
/* Nuestras nuevas reglas con este ancho o más de pantalla */
}
– Aplicar solo en resoluciones entre X e Y pixeles de ancho:
@media screen and (min-width:[ANCHO X]px) and (max-width:[ANCHO Y]px) {
/* Nuestras nuevas reglas con este ancho o más de pantalla */
}
Depende de nuestros gustos cuál usemos, pero lo normal es usar solo la primera de forma acumulativa de forma que a medida que hacemos el ancho más pequeño vayamos modificando elementos en nuestros diseños.
3.2. Compatibilidad de media queries con Internet Explorer.
Es posible que Explorer no pueda soportar muchas cosas que a día de hoy ya son de dominio público. Por suerte, siempre existen desarrolladores muy motivados que nos crean librerías para dotar de compatibilidad a estos navegadores. En este caso nos encontramos con css3-mediaqueries-js una librería javascript que simplemente debemos añadir para Internet Explorer de versiones anteriores a la 9.
Bastará cargar este script en el head de nuestra página y ya podremos usar media queries sin problemas.
<!--[if lt IE 9]><script src="http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script><![endif]-->
Como todas estas librerías, el resultado no es exacto pero sí que da una gran compatibilidad en la mayoría de los casos.
Los tres diseños base dentro del «design responsive»
Una vez hemos visto los detalles de tecnología a usar con este tipo de diseños, debemos ver cómo manejarlos. Como decía antes, soluciones hay miles, pero veamos la base que forma la concepción de la mayor parte de diseños responsive hoy en día:
Estamos acostumbrados a que nuestras webs se vean tal cual se diseñan en la mayoría de casos. En «responsive design» esto cambia. Nos encontramos con una infinidad de dispositivos donde queremos que nuestra web se adapte perfectamente. Pero estos dispositivos vamos a dividirlos en 3 grupos básicos para saber cómo afrontarlos:
- Grandes pantallas, donde nuestra web cabe y sobra incluso espacio para visualizarla.
- Pequeñas o antiguas pantallas, donde nuestra web, para el ancho marcado no cabe y nos aparece la odiosa barra inferior (que nadie usa) para terminar de ver el contenido.
- Pantallas móviles, donde el espacio es tan pequeño que la información no se lee correctamente con el diseño global
Lo que tenemos que buscar entonces es como dar salida, con nuestro diseño actual, a un diseño válido y usable para todas ellas con nuestro actual diseño y maqueta de página. Esto, dependiendo de cómo esté maquetada nuestra página puede darnos más o menos problemas, pero por lo general, con el tipo de trabajo que se realiza actualmente podemos conseguir ciertas cosas.
1. Solucionando las pantallas grandes en «responsive design».
En este aspecto normalmente no hay mayor problema ya que nuestra web ya ha sido creada para ser vista en pantallas grandes. A día de hoy lo normal es que nuestra web llevada a cabo sin contemplar los dispositivos móviles en la maquetación tenga un marco centrado que va desde 1024×768 a 1920×1080 de pantalla y así encaje bien al ser cargada con el zoom aplicado en la mayoría de móviles. Sea como sea, lo lógico es que nuestra web disponga de contenedores de este tipo:
#main { width:???px; margin:0 auto; }
Esta sintaxis nos permite crear un contenedor (main) que queda centrado en la página. Además, con distintos backgrounds será posible decorar el exterior de la página para darle un poco de diseño y no dejarla toda blanca o negra.
En fin, en estos casos no hay mucha cosa que hacer con pantallas grandes. Es cierto que es posible que nuestra web sea vista en un televisor donde además de gran pantalla nos encontramos con que el usuario navega a cierta distancia del monitor. Esto requeriría tratar estas pantallas como los móviles (con grandes cambios) pero realmente es tan poca la gente que navega en su televisor que no suelen merecer la pena estas adaptaciones. Si aún así, quieres crear tu adaptación a televisores puedes jugar con reglas parecidas a las de móvil que se explicarán más adelante.
2. Solucionando las pantallas pequeñas en «responsive design».
Aquí es donde empezamos a encontrar nuestros problemas. Nuestra web está preparada para un ancho de pantalla y resulta que tenemos un porcentaje de usuarios significativo con resoluciones menores.
Comprobar si esto nos está sucediendo es sencillo si usamos Google Analytics o cualquier otro sistema de analítica de página. Ahí podremos encontrar no sólo las resoluciones de pantalla de nuestros usuarios sino qué partes de nuestra web suelen verse en nuestra web.
Lo primero que tenemos que decidir es en qué punto acaba la pantalla pequeña y cuando empieza la móvil. Es decir, está claro que nuestra web no cabe en resoluciones pequeñas y deberemos encogerla un poco para ellas, pero llegará un momento en el que deje de tener sentido este «encogimiento» simple por aglutinar demasiados elementos en la pantalla con el mismo. Para tomar esa decisión conozcamos algunos datos sobre los móviles:
- Un dispositivo móvil en vertical (como más suele usarse), sin importar su verdadera resolución, suele adoptar una resolución de dispositivo de 360px de ancho.
- En horizontal esta resolución se adapta al tamaño real de pantalla, pero suele quedar entre los 640px y los 896px.
- En tablets esta resolución depende de la del dispositivo pero suele quedar en los modelos más vendidos por encima de los 600px, aunque puede llegar a los 1280px acho.
El estándar que se está adoptando es trabajar encogiendo la página para resoluciones pequeñas hasta los 400px de ancho, medida a partir de la cual se entiende que el dispositivo debe cambiar radicalmente su visionado y posiblemente funcionamiento básico. También encontraremos cómo algunas personas deciden visualizar encogiendo hasta los 600px de ancho y a partir de ahí empiezan a crear versiones intermedias entre pantalla pequeña y móvil.
Por último, también sabemos que el mínimo de ancho en el que tenemos que pensar estará en los 320px de ancho, lo cual nos permite además tener un margen desde el que no operar en absoluto.
Tu decides, yo creo que intentar abarcar todos los dispositivos es una locura. Al final lo que tenemos que pensar es en estilos de navegación del usuario donde solo tenemos tres.
- Móviles en vertical: donde la pantalla solo permite lectura y navegación muy simplificada (360×640px).
- Móviles en horizontal y tablets: donde ya se permite una visualización horizontal clásica pero donde hay que vigilar que la navegación se produce con taps y no con clics (por lo que hay que evitar las acciones onMouseOver (600px-800px)
- Dispositivos de sobremesa: donde ubicamos nuestra web normal (>1024px)
Así, yo entiendo la «pantalla pequeña» como una mezcla de pc, móviles horizontales y tablets, lo que la vuelve ligeramente compleja en sí misma, pero nos simplifica el trabajo real de maquetación por bloques al unificar todos estos dispositivos en una sola acción.
Bien, una vez decidido nuestro ancho móvil, lo que tenemos que hacer es trabajar en esa visualización intermedia transformando los bloques que tenemos actualmente para que puedan cambiar de tamaño en función del tamaño de pantalla.
2.1. Contenedores globales de la página.
Llamamos contenedores globales a aquellos que marcan los anchos globales de nuestra web. Esos que decíamos antes que nos permitían centrarla y darle un ancho concreto.
Los contenedores globales son los más fáciles de adaptar pues lo único que tenemos que hacer es no ser tan rígidos con su ancho y pasar de un ancho fijo a un ancho máximo. Dicho de otra forma, bastará con que en mi declaración inicial del marco de la página pase de «width» a «max-width». Además, y ya que hemos pensado en cuál va a ser nuestra resolución mínima para pantallas móviles, añadiremos esta como min-width para controlar que ante dispositivos realmente extraños no provoquemos una página no controlada.
#main {max-width:1920px; min-width:360px; margin:0 auto;}
El resultado será exactamente el mismo para pantallas grandes y sin embargo, veremos cómo al hacer más pequeña nuestra página este marco se va haciendo más pequeño.
En las pruebas que he ido realizando, un ancho de 1920px de página que se aplicaba en los elementos de cabecera, contenido principal y footer. Mi primer paso ha sido por lo tanto pasar esa medida, en los distintos bloques globales a ancho máximo de página en lugar de fijo. En tu caso esto podría representar más o menos sentencias dependiendo de la cantidad de bloques de este tipo que uses.
#header #top {position:relative; max-width:1074px; min-width:320px; height:115px; margin:0 auto; [...]}
[...]
#header ul.menu {position:relative; max-width:1008px; min-width:320px; height:95px; [...]}
[...]
#aux-main{position:relative; max-width:1008px; min-width:320px; margin:0 auto; [...]}
[...]
#footer ul {max-width:768px; min-width:320px; margin:10px auto;}
2.2. Contenedores interiores.
A partir de aquí es donde solemos empezar a tener problemas. Nuestra página seguramente estará formada por un layout que se dividirá en varias piezas:
- Cabecera a 100% de ancho
- Contenido ocupando gran parte del ancho
- Uno o más sidebars ocupando solo una parte del lateral
- Pie de página a un 100% de ancho
En definitiva, tenemos ciertos contenedores que seguramente tendrán un ancho fijo para marcar columnas en la web. Luego estos podrán haberse transformado en columnas con distintas técnicas (floats en la mayor parte de los casos, display:inline o display:box en otros). Así que lo siguiente que tengo que hacer es transformar esos valores en declaraciones menos estrictas y que respeten que el contenedor principal ya no mide exactamente lo que habíamos marcado.
Es decir, tenemos que pasar de Pixeles a porcentajes todo lo que represente algún espacio en el ancho de página: widths, max-widths, margins y paddings.
Por suerte, una vez está terminada nuestra maqueta, este paso es realmente sencillo. Tan solo tenemos que hacer una pequeña división para saber el valor porcentual que representa una medida en píxeles sobre la de su elemento contenedor.
[Px de ancho elemento interior] / [Px de ancho elemento padre] * 100
En la prueba de mi antiguo blog tuve la suerte de que muchos contenedores ya estaban en medida porcentual. Esta es una buena costumbre de maquetación, si porcentualmente existe un valor claro es preferible usarlo así para futuros cambios independientemente de si usamos o no «responsive design».
El elemento más molesto que me encontré fue el columnado que al estar desarrollado con elementos float al hacer más pequeño el marco el sidebar pasaba a quedar bajo el contenido. Así que realizamos los cálculos de los elementos dentro del div de contenedor global (que recordemos tenía un ancho de 1080px) y pasamos a porcentaje estas medidas.
#main #content {float:left; width:63.9880952%; margin:30px 0 0 1.98412698%; }
[...]
#main #sidebar {float:left; margin:20px 0 0 3.47222222%; width:28.7698413%; }
Transformamos no solo los anchos, sino también los márgenes horizontales para que toda la web siga cuadrando. También hemos incluido un gran número de decimales en el cálculo para ser lo más exactos al original.
2.3. Elementos interiores sueltos que crecen demasiado.
En algunas ocasiones es posible que nos encontremos con elementos sueltos dentro de nuestra maqueta que por sus características pueden llegar a hacerse más grandes de lo que lo es su contenedor con max-width.
Lo mejor para detectar estos elementos es ir jugando con tu tamaño de navegador para detectarlos y corregirlos. Pero muchas veces será más rápido y cómodo seleccionar nuestros contenedores y prohibir que ninguno de sus elementos interiores crezca más de lo que mide el propio contenedor.
En mi caso decidí aplicar esta corrección dentro de mi contenido principal y mi sidebar, de forma que algunos problemas (sobre todo derivados de widgets como Facebook y Twitter) se solucionasen por sí solos.
#main #content {float:left; width:63.9880952%; margin:30px 0 0 1.98412698%; }
#main #content * {max-width:100%}
[...]
#main #sidebar {float:left; margin:20px 0 0 3.47222222%; width:28.7698413%; }
#main #sidebar * {max-width:100%}
2.4. Elementos posicionados en absoluto.
Para los elementos posicionados en absoluto habrá que realizar el mismo proceso que con los anchos de elemento. Estos deberán adaptarse a porcentajes en su eje X y variar su ancho.
En mi caso, disponía de varios elementos en absoluto en la cabecera por lo que he debido adaptar sus posiciones para que no quedasen flotando en el aire al hacer más pequeña la página.
[...]
#header #top p.breadcrumb {position:absolute; top:90px; left:3.72439479%; color:white;}
[...]
#header #top p.like { position:absolute; top:10px; left:54.0037244%; }
[...]
#header #top div.vcard{position:absolute; top:11px; right:5.49348231%; width:27.9329609%;}
2.5. Elementos que no caben: nuestras primeras «Media Queries».
Por mucho que adaptemos nuestros anchos es probable que haya elementos que simplemente por el contenido que deben incluir no quepan en el diseño. Estos elementos nos están molestando y haciendo que todos nuestros cambios se vean mal. Para evitarlo tendremos que empezar a hacer uso de media queries sencillas que nos permitan cambiar drásticamente el CSS cuando se produzcan ciertas dimensiones.
Las media queries son todo un mundo, incluso a día de hoy que no han sido del todo explotadas, se pueden hacer cosas asombrosas con ellas. Pero nosotros lo que haremos será algo muy sencillo, simplemente las usaremos para marcar condiciones sobre el ancho de pantalla a partir del cual nuestro CSS cambie.
Recordemos esa sintaxis:
@media screen and (max-width:[ANCHO]px) {
/* Nuestras nuevas reglas con este ancho o menos de pantalla */
}
Estas media queries, para este caso concreto, en el que solo buscamos adaptar el diseño a distintas resoluciones, nos servirán sobretodo para esconder algunos elementos secundarios que a partir de cierto ancho de pantalla molestan más que ayudan al usuario y para hacer pequeñas adaptaciones para que algunos objetos quepan en el diseño ante distintas situaciones.
En mi caso, decidí esconder algunos elementos con resoluciones menores de 800px o 600px, pues no permitían que se pudiese ver bien el contenido principal del blog.
@media screen and (max-width: 800px) {
#header #top p.like,
#header #top p.breadcrumb,
#header #top div.vcard p.twitter,
#header #top div.vcard p.linkedin,
#header #top div.vcard p.delicious,
#header #top div.vcard p.google,
.vcard h2{ display:none;}
}
@media screen and (max-width: 600px) {
#sidebar .twitter {display:none;}
}
En resoluciones de menos de 800px, escondo los botones de like, el breadcrumb, los botones sociales y alguna cosilla más. A partir de menos de 600px he decidido además eliminar los últimos tweets del sidebar para que no quedase todo tan apretado.
Sencillo, ¿verdad?
Pero las media queries no solo sirven para ocultar contenido. Sino que permiten hacer modificaciones en algunos estilos. Esto es especialmente útil cuando un elemento no se adapta simplemente con anchos pero aun no queremos hacerlo desaparecer. En ese momento le cambiamos un poco el estilo para que se adapte a lo que buscamos.
En mi caso, me daban algunos problemas los botones sociales a poco que bajase el ancho de página, por lo que he decidido cambiar un poco su formato (eliminando iconos y disminuyendo la letra) cuando la página baja de 960px de ancho.
@media screen and (max-width:960px) {
#header #top div.vcard p {font-size:9px;}
#header #top div.vcard p.twitter a,
#header #top div.vcard p.linkedin a ,
#header #top div.vcard p.delicious a,
#header #top div.vcard p.google a {background:none; padding:0;width:50%; float:left;}
}
2.6. Qué hacer con los menús y sus opciones.
Los menús suelen ser un problema grave al hacer nuestras páginas más pequeñas pues al tratarse de un conjunto de elementos medianamente largo que, además, no forma parte de la información principal de la página (y por lo tanto no podemos permitirnos que ocupe demasiado espacio de la misma) el espacio destinado a los mismos se nos suele quedar corto en algún momento. Completemos esta problemática con que los dispositivos táctiles resultan incómodos con listados de links pequeños (por lo que encoger los links no suele ser una alternativa).
Por suerte podemos recurrir a distintos recursos que solucionan estos problemas. A mi el que más me gusta es el de reemplazar los menús por un SELECT que cuando el usuario usa cambiar la dirección de la página que estamos viendo por la del destino del link.
Me gusta porque resume grandes listados en un solo bloque pequeño y porque al mismo tiempo, llegados a un móvil o tablet el comportamiento de los SELECT se vuelve ideal, pues permite al usuario seleccionar sus opciones cómodamente.
Para realizar este cambio os recomiendo el plugin de jquery tinynav un sencillo plugin, con gran compatibilidad, al que indicamos los distintos elementos UL de nuestros listados y él añade, antes de estos, un SELECT con las características que mencionábamos. Por lo tanto, solo nos queda ocultar el propio UL o el SELECT con nuestras medias queries para conseguir un resultado óptimo.
En mi caso he añadido el plugin para los listados de links de la cabecera, de forma que al bajar de 800px de ancho estos sean reemplazados por el SELECT en cuestión.
Así que he realizado 3 pasos:
1. Añadir el script y en el «ready» de mi jquery hacer la llamada al nuevo método:
$(".menu ul").tinyNav();
Esto añade el SELECT en los 3 listados de links del menú superior.
2. Añadir a mi CSS básico que no se muestren estos nuevos SELECT.
.tinynav { display: none }
3. Añadir dentro de la media query adecuada el formato del select y la desaparición del propio listado.
@media screen and (max-width: 800px) {
#header ul.menu li ul {display:none}
.tinynav { display: block; position:absolute; bottom:5px; width:79%; margin-left:15%}
}
Y ya tenemos nuestros SELECTs por debajo de los 800px de ancho.
2.7. Backgrounds de bloques.
Aquí, dependiendo de nuestra maqueta es donde podemos tener serios problemas. En CSS decoramos nuestros bloques con imágenes de fondo. Existen innumerables técnicas para hacer esto pero unas son más amigables que otras a los redimensionamientos. Por lo tanto, dependiendo de las técnicas que hayamos utilizado podemos encontrarnos con que nuestros fondos pierden sentido al ocultarse sus bordes.
Esto puede ser simplemente anecdótico en ciertos casos, pero preferible a que el elemento no se adapte al diseño pero en otros puede ser un verdadero quebradero de cabeza.
Soluciones varias:
- Cambia todos los fondos que puedas por estilos CSS3 que responderán perfectamente a estos cambios. A día de hoy es fácil dar compatibilidad a la mayor parte de los navegadores para el uso de bordes redondeados, sombras o degradados. Con estas tres funciones CSS es difícil que tus diseños necesiten de muchas imágenes para crear los bloques.
- Elimina imágenes de fondo (y reemplazarlas si puedes por el CSS3 más cercano) a medida que las media queries y anchos adaptables realicen su función.
- En el caso de grandes fondos que ya contenían la situación de un bloque duplica en el bloque este estilo e intenta que se note poco el background original.
En mi caso el blog era bastante sencillo y solo me encontré con tres tipos de imágenes de fondo molestas:
- Los bordes del marco de la página, que aún no respetándose, al quedar por debajo de la parte no visible no han resultado molestos
- Los iconos de algunos títulos, que he debido ir ocultando con media queries a medida que resultaban molestos
- El background global de la cabecera, que ya incluía el cuadro blanco para el nombre del autor. Aquí he debido replicar el estilo en el cuadro de autor de forma que se solape un fondo con otro al empequeñecer la página
No pongo el CSS de cómo están resueltas estas partes exactas en mi blog, puesto que en cada caso la solución será distinta.
¡Se acabó!
Y con todo esto ya hemos conseguido un diseño bastante adaptable. De la rigidez que teníamos con un diseño fijo en 1080px de ancho, ahora tenemos un blog que puede ser disfrutado en un mayor número de dispositivos… pero falta algo. Faltan los móviles, donde el diseño se ve bien con estos cambios pero resulta poco práctico (con sus 2 columnas y elementos apretados en la cabecera).
3. Solucionando las pantallas móviles en «responsive design».
Como último paso debemos definir una visualización correcta para móviles. Esto es así porque el uso que se hará en estos dispositivos no será el mismo que en páginas normales. Sin duda querremos hacer más cambios que simples adaptaciones del ancho de pantalla y desaparición de elementos.
Por suerte, contamos con el viewport para definir cómo queremos trabajar esta parte.
Comentábamos que el viewport nos sirve para indicar al móvil como deseamos que trabaje su Zoom a la hora de mostrarnos la página. Así pues, básicamente teníamos dos opciones:
Para webs con «responsive design» adaptado perfectamente a resoluciones móviles.
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Para webs que no se han adaptado del todo a resolución móvil.
<meta name="viewport" content="width=[Pixeles del mínimo ancho para visualizar bien la web]">
La primera es la situación ideal, pero también la que más trabajo va a darnos, porque al bajar de los 500-400px de ancho las columnas se vuelven directamente imposibles y eso significa que tenemos que hacer cambios drásticos en la visualización de la web.
La segunda opción puede ser más rápida. Simplemente indicamos que el móvil se visualice a la resolución que queramos y así se comportará… seguirá siendo nuestra web normal pero en su versión más encogida.
Pero si escogemos la segunda opción tendremos dos problemas con nuestra web:
- Por un lado el viewport es global a todos los navegadores móviles, por lo que si indicamos, por ejemplo, un viewport de 500px de ancho provocaremos que en un ipad de casi 800px de ancho se visualice una versión de nuestra web a 500px que sin duda desaprovechará el espacio disponible
- Por otro lado, en resoluciones de 320px de ancho, nuestros contenidos se verán bastante reducidos con lo que si no hacemos según qué cambios será inmanejable… Pero si adaptamos menús y fuentes también se modificarán en la versión tablet.
En definitiva, marcar un ancho fijo con viewport es la opción rápida pero no la buena.
Lo suyo es que dejemos al móvil mostrarnos la resolución que sea capaz de mostrar usando el primer viewport en nuestro HEAD de la página.
Una vez hemos decidido nuestra visualización debemos ponernos a trabajar en nuestra última media query: la versión móvil.
Aquí normalmente eliminaremos las columnas pasándolo todo a bloques de 100% de ancho. Eliminaremos y compartiremos algunos elementos más y ajustaremos las fuentes para que la lectura a 320px de ancho resulte cómoda en dispositivos de pequeña pantalla.
3.1. Eliminando columnas:
Vamos a poner nuestras columnas una detrás de otra. Existen entonces dos posibilidades.
a. Que en el html ya estuviesen ordenadas tal cual las queremos en la versión móvil.
En cuyo caso bastará con eliminar los floats o cambiar el display:inline-block o display:box por un display:block normal.
@media screen and (max-width: 400px) {
#content {display:block; float:none; }
}
b. Que no se encontrasen ordenadas.
En cuyo caso deberemos jugar con posiciones absolutas que hagan a estos bloques inferiores pasar a la parte alta de la página y márgenes para desplazar los primeros bloques hacia abajo para que no se crucen.
Imaginemos esta estructura:
<div id="content"></div>
<div id="sidebar"></div>
</div>
Donde queremos que en la versión móvil los elementos del sidebar queden antes que los de content. Nuestro css tomará un aspecto cercano al siguiente:
@media screen and (max-width: 400px) {
#main {position:relative; width:100%; }
#content{margin-top:80px; width:100%; float:none;}
#sidebar{height:80px; position:absolute; top:0; width:100%; float:none; }
}
En mi caso me encontré en este segundo caso, por lo que en móvil he tenido que recurrir a posiciones absolutas. Además situé el cambio a 450px de ancho, debido a que la visualización se volvía realmente incómoda a partir de ese punto.
@media screen and (max-width: 450px) {
#main #sidebar {display:block; float:none !important; width:100%; position:absolute; top:-80px; margin:0 !important; border-bottom:1px solid #aaa; padding:0 0 20px 0;}
#main #content {float:none; width:auto; margin:100px 0 0 0; }
}
3.4. Ajustando Fuentes.
Las fuentes que en su día se diseñaron para ajustarse a grandes pantallas, con un layout de columnas, etc. Cuando cambiamos a las pequeñas pantallas de móvil en vertical estas suelen no ser las más cómodas para la lectura: Ocupan demasiado ancho, destacan demasiado los titulares y el texto del cuerpo suele ser difícil de leer. Por lo tanto es conveniente hacer una revisión de todas para ajustar la visualización a una versión cómoda.
En mi caso he tenido que cambiar todo el estilo de las fuentes de los menús, disminuir los titulares y aumentar el cuerpo de los artículos:
#header ul.menu li,
#header ul.menu li.analytics,
#header ul.menu li.development {background:none;}
#header ul.menu li h4 {margin:30px 0 0 0px; font-size:12px; text-indent:10%;}
#main #content .hnews h3 a,
#main #content .hnews h1 a{ font-size:22px; }
#main #content .hnews .entry-content {font-size:16px;}
Otros ajustes
Por último, queda dejar «bonito» el resultado. Como antes, revisemos nuestros elementos, demos estilo a aquellos que no se ajusten a lo que queremos y eliminemos aquellos que no tengan cabida.
En mi caso he tenido que eliminar del todo el bloque de autor, pasar a horizontal los elementos del sidebar y mover algunos márgenes de sitio.
Con todo esto ya tendremos nuestra web móvil lista para trabajar.
Testing y pruebas
Para trabajar con todo lo aquí explicado es esencial poder testear lo que vamos haciendo y los cambios que vamos provocando. Aquí me gustaría compartir con vosotros dos recursos:
1. Para probar en el navegador.
Debemos ir ajustando el ancho de pantalla para ver como nuestras adaptaciones van tomando forma y detectar pequeños ajustes a realizar en nuestras media queries.
Para ello tenemos dos opciones:
- Directamente desmaximizar nuestro navegador e ir jugando con su ancho.
- Usar herramientas como ish que nos permitirá ir haciendo estos ajustes con sencillos botones.
2. Evitando la caché móvil.
Los móviles en su afán por no solicitar más datos de los estrictamente necesarios cachean mucho más que un navegador tradicional. En un navegador suele bastar con presionar CTRL+F5 para provocar cargas sin cacheo. En móviles es más difícil y algunos navegadores ni siquiera tienen la opción de desactivar esta caché.
Para trabajar de forma más cómoda me gustaría daros tres consejos:
Usar variables en la llamada CSS. Es decir en lugar de llamar a «/styles.css» llamaremos a «/styles.css?version=xxxx» cambiando en cada caso el número de versión para que la url sea distinta y por tanto no se use caché
Trabajar en el navegador. Subiendo un poco la resolución mínima móvil (420px-450px) podremos provocar que ésta sea vista en nuestro navegador cuando lo encojamos lo suficiente. También usando herramientas de redimensionado de página podemos provocar estas acciones. Esto resultará sin duda más cómodo para muchas pruebas pero no evita probar finalmente en el propio móvil
Conclusión
Poco a poco hemos ido viendo y conociendo las distintas técnicas y tecnologías que suelen aplicarse al «responsive design» pero aplicándolas a una web existente en lugar de al desarrollo de webs nuevas.
¿Hemos hecho una web con «responsive design»?
La respuesta es clara: NO. Hemos hecho más adaptativa una web que no fue creada para serlo. En consecuencia hemos cometido muchos errores durante el proceso:
- Hemos eliminado elementos que en su día consideramos vitales. Además lo hemos hecho por su aspecto no por su importancia en la información transmitida al usuario
- Seguramente no hemos conseguido una visualización perfecta en todos los casos. Hemos mejorado la que había, pero el resultado no es el mismo que si hubiéramos planificado todo esto de antemano
- Por último, yo he podido llegar al final con esta web, pero muchas webs, dependiendo de la maqueta de la que surjan no podrán llegar tan lejos y tendrán que conformarse con soluciones intermedias
Estos son los detalles, pero más importante que todo esto es que lo que hemos hecho ha sido una maqueta adaptable sobre un diseño que no era adaptativo. «responsive design» nos habla de diseño, no de maqueta, por lo que debe venir directamente desde el concepto de diseño para que termine de tener sentido para todos. No se trata de ser «guay» y poder mostrar una web que se encoje y se adapta mínimamente al móvil sino que nuestro proyecto debería haber surgido bajo el paradigma de ser multidispositivo como poco sino ya «mobile-first», valorando en cada caso su usabilidad.
Sin duda, si sigues este tutorial y lo aplicas a tu web podrás hacer maquetas responsive pero eso no significa que sea «responsive design». Por otro lado, debes valorar si la inversión de tiempo merece la pena para tu negocio. Hoy en día hay muchas plantillas que podrías aprovechar y que ya se han diseñado para que se adapten a los dispositivos. No obstante, para webs más complejas o si lo que quieres es un diseño ad-hoc, lo más prudente es que siguiendo la filosofía «mobile-first» confíes en diseñadores y desarrolladores web.