Diseño Web Adaptable - Tutorial con ejemplos adaptables |
Quienes hemos estado creando sitios desde los comienzos de la web, estamos habituados a que nuestras páginas sean “rígidas", esto es, de ancho fijo en pixeles. En los años noventa, los monitores de 14 pulgadas con un ancho de pantalla de 640px eran los únicos que existían, y ese era el tamaño que dábamos a nuestros diseños. No pensábamos en otra opción. Sencillamente definíamos tamaños en pixeles a todas nuestras columnas.
Cerca del año dos mil, surgió un segundo valor a considerar: 800px de ancho (ya existían monitores de 15 y de diecisiete pulgadas). El problema era que, si definíamos el ancho total de nuestro sitio en 800px, a los usuarios de monitores de 640px de ancho que todavía quedaban, les aparecía una poco elegante y nada usable barra de desplazamiento horizontal. El lugar no entraba en la pantalla.
Las soluciones para ese escenario dividido en 2 tamaños eran muy sencillas: hacíamos un contenedor general de 640px de ancho y lo centrábamos dejando una pequeña franja sin ocupar a ambos costados o hacíamos un lugar con ancho definido en porcentajes, que se estiraba ligeramente entre las dos medidas.
Más cerca en el tiempo, alrededor del año 2005, la decisión a tomar era similar: seguían existiendo monitores de 800px (ya no quedaba ningún monitor de 640px de ancho), mas la resolución mayoritaria pasó a ser de 1024px. Entonces, o bien le dábamos ancho líquido (en porcentajes) a fin de que se estirara entre ochocientos y 1024px, o bien creábamos un contenedor de 800px centrado, sobrando unas pequeñas franjas a los costados, y tema resuelto.
Pero al llegar la década del dos mil diez, un cambio realmente revolucionario alteró nuestro escenario. Los teléfonos móviles comenzaron a navegar la web, usando navegadores similares a los de una computador (Opera, Safari, Explorer, Chrome y Mozilla Firefox) y apareció la primera tableta (el iPad). posicionamiento web de blog , nuestras decisiones de diseño se volvieron más complejas, a raíz de la diversidad de tamaños de pantalla con los que los usuarios navegan nuestros sitios. ¿Para cuál de todos esos tamaños vamos a diseñar? ¿Para todos? ¿Eso es posible?
Algún cambio es necesario en nuestra metodología de diseño, en tanto que un diseño líquido simplemente no aguanta ser “estirado" desde un mínimo de 320px hasta varios miles y miles de pixeles de ancho.
Y por otra parte, si en vez de darle ancho líquido, le definiéramos los anchos en pixeles, el efecto sería igualmente negativo: el lugar se “miniaturizará", siendo muy incómodo navegarlo, en dependencia del empleo incesante de zoom en ambos sentidos y debiendo efectuar desplazamientos horizontales. Algo así como sobrevolar la página web en helicóptero, a la forma de cómo visualizamos un mapa.
En el escenario actual, ya no podemos confiar en una resolución mayoritaria, ni en dos o bien 3, sino es necesario comprender que las resoluciones empleadas por los usuarios cada vez estarán más fragmentadas y serán más variadas, cubriendo rangos intermedios entre dos puntas cada vez más distantes: dispositivos más pequeños que un monitor de ordenador, por un lado, y pantallas cada vez con mayor resolución en el otro extremo.
La era en la que utilizamos y abusamos de sitios de ancho fijo en pixeles, grillas y columnas definidas en pixeles y hasta metodologías de diseño visuales como las de maquetar utilizando celdas de tablas, ya llegó a su fin. Es el fin del diseño rígido. Necesitamos algo nuevo.
Las páginas web por naturaleza son “adaptables" desde el nacimiento mismo de la Web. Para comprobar que esta hipótesis es adecuada, pensemos en un fichero HTML apropiadamente estructurado, con encabezados, párrafos y listas. Pero sin diseño. Es decir, un archivo HTML al que no le vinculamos ninguna hoja de estilos, al que no lo maquetamos. Por ejemplo, el siguiente:
Si tratamos de navegar este archivo desde dispositivos de distintos tamaños, no vamos a tener ningún problema para acceder a sus contenidos: el texto será legible en un celular, en una tableta y en una PC también.
Desde puesto que no está “optimizado” para esos tamaños, nunca afirmamos que fuera estéticamente conseguido, solo que es adaptable, que se puede emplear en todos y cada uno de los tamaños.
En conclusión, el problema que complica acceder a nuestros sitios web desde móviles es generado por nuestro proceso de diseño: brota cuando agregamos hojas de estilo y diseñamos, dando medidas a cada bloque de contenidos y a los elementos que lo componen (imágenes, tipografías, etcétera).
Aunque más que el diseño en sí, diríamos que es el “sobre-diseño” el culpable de la rigidez. El error consiste en acotar toda medida en pixeles, pretendiendo supervisar al detalle la ubicación de la información. Ese es el primordial causante de esta inflexibilidad.
Es decir, somos los diseñadores mismos los que causamos el problema, con nuestro antiguo proceso de diseño (heredado de medios gráficos como el papel) y la falla está en ciertas decisiones que tomamos en su trascurso (como las unidades de medida que escogemos aplicar).
Ante todo, la técnica: se denomina Media Queries a la posibilidad de acotar condiciones que deben cumplirse para que el navegador procese algunas reglas de estilo específicas dentro de nuestra hoja CSS.
Por ejemplo, podríamos delimitar una condición que determine que si el tamaño de pantalla es menor a 480px de ancho, el navegador procese determinados estilos CSS que vamos a dejar preparados. En esos estilos, definiremos diseños ideales para un dispositivo que cumpla con esa condición, o sea, que no supere ese ancho de pantalla de 480px.
Mediante el empleo de esta técnica, se intenta optimar la experiencia de uso de un sitio para amoldar el diseño al contexto. En un caso así, sería un tamaño variable de pantallas el que le brinda un contexto muy particular a los contenidos, limitando los diseños posibles.
También podemos conjuntar varias condiciones en una sola usando el operador lógico “and” tantas veces como sub-condiciones necesitemos combinar. En el siguiente ejemplo, combinaremos dos condiciones: que sea una pantalla y que mida como mínimo mil veinticuatro pixeles de ancho.
En este otro ejemplo, combinaremos 3 condiciones: que sea pantalla, que mida más de 320px y menos de 768 pixeles de ancho.
Esta posibilidad de conjuntar múltiples condiciones será indispensable para poder advertir los rangos de tamaños a los que se aplicará una o bien otra hoja de estilos.
Esta técnica llamada media queries, que nos permite condicionar la lectura de diferentes estilos, es la que nos abre la posibilidad a un nuevo enfoque de diseño web, que resulta ideal para dar soporte a la gran diversidad de dispositivos existentes hoy día. Este enfoque es conocido como “diseño web adaptable” o bien “diseño web sensible” (adaptable web design, originalmente).
En pantallas grandes (una media querie de “Mayor a 1024px”, por servirnos de un ejemplo) podríamos hacer flotar tres columnas, al tiempo que en una tableta (una media querie de “Mayor a 800px”, por poner un ejemplo) solo vamos a dejar flotar 2 columnas, y en el caso de pantallas más angostas (celulares, sin media queries) anularemos todos los flotados, reduciendo la cantidad de columnas a una sola (“apilando” los contenidos uno bajo el otro).
Veamos cómo sería el código:
Un código similar al precedente es el usado para lograr estos cambios en el sitio del Japan Times:
Pero no solo el layout puede cambiar entre una pantalla y otra; analizaremos a continuación cuáles son los elementos de diseño que es esencial adaptar para que el contenido web quede optimizado para diferentes dispositivos.
Los elementos centrales de un diseño adaptable o “sensible” son cuando menos cuatro:
Complementariamente, vamos a aplicar sistemáticamente en nuestras páginas amoldables, dos elementos extra:
Comencemos a analizar uno por uno estos elementos, así aprenderemos a incluirlos en nuestros proyectos, para que podamos volverlos adaptables y dejemos atrás la era de la rigidez.
El primer elemento del diseño que volveremos flexible desde nuestra hoja de estilos será el texto. La novedad será que cambiaremos la unidad de medida más utilizada hasta el momento para acotar el tamaño de las fuentes a través de la propiedad font-size (es decir, los pixeles), por otras 2 unidades de medida más versátiles.
Si proseguimos usando pixeles como unidad de medida para nuestras fuentes, vamos a tener dos géneros de problemas:
¿Por dónde comenzamos entonces el proceso de codificación (HTML) si deseamos contenido seo ? Por el principio: el texto.
Pregunta al paso que siempre y en toda circunstancia me gusta plantear a mis alumnos: ¿Cuál es el denominador común de una pizza? ¿Aceitunas? ¿Cebollas? ¿Tomates? ¿O la masa?
¿Y el denominador común de una Web? ¿Flash? ¿Imágenes? ¿Videos? ¿O el texto?
Una vez marcados los textos semánticamente (con h1, h2, p, ul con li), aplicamos los identificadores y clases que creamos precisos, y ya tendremos el código HTML básico terminado. Ese texto bien estructurado con HTML elemental, será suficiente para cualquier celular de bajas posibilidades que aún pudiese estar usando algún usuario.
Ahora sí, llegó el momento de definir en nuestra hoja de estilos las unidades de medida que volverán flexible nuestro esquema tipográfico, para garantizar la legibilidad de nuestros contenidos. Creamos que la distancia de lectura en una ordenador es cercana al metro, considerablemente mayor a la que existe entre nuestros ojos y un teléfono o tableta que mantenemos en nuestras manos:
Por ese motivo, los tamaños de fuentes deberán ser mayores para una ordenador que para una tableta, y los de una tableta, mayores que los de un celular.
Para conseguirlo, no usaremos más pixeles para definir el tamaño de fuentes, sino usaremos la unidad de medida em y los porcentajes, combinados de una forma particular: al body (y solamente al body) le definiremos un font-size base en porcentaje, y al resto de textos, se lo definiremos en em:
Observemos que hemos definido en em los tamaños de fuentes de nuestros contenidos utilizando indiferentemente etiquetas, id o bien clases, en un solo lugar: la zona inicial de nuestra hoja de estilos, aquella que leerán todos los dispositivos sin condiciones, en tanto que no se encuentra envuelta en ninguna media query.
Por otro lado, cuando aplicamos una condición para cierto tamaño, lo único que cambiamos es el valor base en porcentaje aplicado al body, lo que hará que todo el esquema tipográfico definido en ems se escale proporcionalmente a un nuevo tamaño. O sea, lo que hacemos es cambiar el tamaño del em, al cambiar su punto de referencia (que es ese porcentaje que definimos en el body).
Como orientación, podemos calcular que en la mayoría de las pantallas de ordenador, a tamaño de fuente normal, la equivalencia entre ems y pixeles es que 1em = 16px, con lo que, si deseamos acotar en la hoja de estilos un texto que en Photoshop ocupaba 24px, lo vamos a dividir por uno para saber su valor en em, que en un caso así sería 1.5em. Atención: empleemos puntos como separador decimal, no comas.
Por supuesto, nada impide que realicemos ajustes en ciertas media queries si deseamos que determinado texto tenga una medida especial en una de ellas. Mas el punto de inicio ya quedará establecido automáticamente.
Con estas nuevas unidades de medida ya vamos a poder crear esquemas tipográficos acomodables, que se visualicen de manera óptima según la distancia de lectura de cada dispositivo.
Notemos que no estamos definiendo un tamaño rígido, sino una relación proporcional entre los diferentes tamaños de texto de nuestra página, proporción que se mantendrá a lo largo de todos los dispositivos merced a que vamos a escalar el esquema completo en todos y cada media query.
Aprovechando que cada zona de la hoja de estilos que envolvamos entre media queries deja que determinados estilos se apliquen solo en un rango de tamaños de pantalla, en cada zona acomodaremos los contenidos en columnas de una forma optimada para el tamaño del dispositivo.
En principio, convengamos que en un celular básico no es suficiente el espacio para flotar 2 o bien más columnas una al lado de la otra, por lo que el layout será exageradamente simple: solo dejaremos que los bloques se apilen uno bajo el otro por orden de aparición en el código HTML.
A partir de allí, vamos a hacer flotar tantos bloques como creamos preciso en todos y cada media query.
La grilla flexible consiste en acotar anchos de contenedor y de columnas en porcentajes, a fin de que los bloques de un diseño sostengan una proporción entre sí en el rango de ancho mínimo y máximo definido en cada media query del punto precedente.
La fórmula para calcular los porcentajes desde un boceto en pixeles es la de dividir el ancho del elemento por el del que lo envuelve:
Ejemplo: 600px / 960px = 0,625
Es decir, ese bloque que medía 600px en un contenedor de 960px ahora deberá medir 62.5 por cien (ese valor brota del 0.625 de la cuenta que terminamos de efectuar)
Repitamos la fórmula en otro caso:
Ejemplo de 3 columnas para fotos situadas dentro de una zona de 480px:
150px / 480px = 0,3125
Es decir, vamos a deber acotar un treinta y uno y veinticinco por ciento de ancho a cada una de las tres columnas.
En este contexto, también debemos volver flexibles los márgenes y paddings, para que no arruinen con pixeles la proporcionalidad de los espacios conseguida.
Si en todos y cada zona de los estilos CSS delimitada por una media querie apuntamos a distintas imágenes (de diferentes tamaños), no vamos a tener problemas con background-image:
en el caso de etiquetas IMG, haremos flexible la imagen dentro del rango mínimo y máximo de un layout:
Eso hará que dentro del rango de ancho del elemento que envuelva a la fotografía (columna) la imagen se estire desde un mínimo y hasta un máximo. Como el máximo es su tamaño real, 100 por ciento , consideremos ese ancho al delimitar el ancho de su elemento contenedor, o viceversa: creemos la imagen al tamaño máximo al que llegará su elemento contenedor.
Existen múltiples propuestas del W3C para precisar que el navegador descargue distintas imágenes según el tamaño de pantalla (tal como en las imágenes de fondo) como por servirnos de un ejemplo, la posible etiqueta “picture” con múltiples etiquetas “source”, cada una condicionada por una media query, o bien que se modifique la etiqueta “img” permitiendo concretar más de un source mediante el atributo srcset. Al momento de redactar este libro ninguna de ellas está estandarizada ni incorporada por los navegadores.
desarrollo web en huesca de emplear dibujos vectoriales escalables SVG en vez de una etiqueta IMG cuando lo que muestre la imagen sea un dibujo con pocos colores (logos, iconos, etc.).
La navegación es otro de los puntos críticos que debe adaptarse en un sitio para permitir su empleo en teléfonos y tabletas.
Tomemos como ejemplo la navegación de este sitio:
En el caso de la PC, vemos una serie de submenús desplegables, desde una lista (ul) de primer nivel que contiene el nombre de cada sección en letras grandes, y con una segunda línea gráfica. Vemos cómo, en un tamaño mediano de pantalla (tableta), esa segunda línea desaparece, y el tamaño de fuente es menor. Ese cambio puede lograrse con algo tan sencillo como mudar el font-size (ya lo vimos en el primer punto de este capítulo) y esconder con display:none los subtítulos por defecto, haciéndolos perceptibles con display:block a partir de cierto tamaño de pantalla.
Por ejemplo:
Y en el caso de la navegación en la pantalla más pequeña (teléfono), vemos que se aplicó el mismo criterio pero para ocultar el enorme listado de submenús, dejando únicamente los botones de primer nivel, haciendo que no floten uno al lado del otro y dándoles un tamaño grande, para que puedan ser fácilmente pulsados con los dedos en una pantalla táctil.
Otro caso bastante común es el de sustituir un menú visualmente amplísimo que es el que se usará en la ordenador, por un select con options en el teléfono.
En el código HTML, que es el mismo para todos los dispositivos, estará el código HTML de los dos menús (el formulario con el select y la “ul” con botones).
Por ejemplo:
Desde la hoja de estilos, en la zona inicial de la hoja sin condiciones, escondemos el menú de ordenador y mostramos el de celular:
Y en una media query, invertiremos esto para cuando estemos en pantallas grandes:
De esta forma, ya podemos manipular la visualización de diferentes herramientas de navegación, merced a las media queries.
El tamaño de la “ventana” del navegador en una PC, siempre y en toda circunstancia coincide o bien es menor que el tamaño de la pantalla. O sea, o empleamos el navegador maximizado, a pantalla completa, o bien lo achicamos un poco. Mas jamás es más grande que la pantalla.
En móviles, en cambio, o la ventana del navegador coincide con el tamaño de pantalla (siempre y en todo momento maximizada), o bien es mayor que el tamaño de pantalla, viendo solo una parte de ella por vez. Nunca es menor en tanto que no podemos “achicar” la ventana a fin de que ocupe menos de una pantalla. Pero sí puede acontecer lo contrario, que el contenido supere el tamaño de la pantalla pues estemos viendo solo una parte, debido a la utilización del zoom.
Por ejemplo: Safari y Opera Mini asignan 980px de ancho al viewport y hacen zoom para enseñar lo que suponen una web hecha para computador (y en el noventa y nueve por ciento de los casos, ¡aciertan!).
Veamos un caso comparando exactamente la misma página sin que el navegador le haga zoom, “miniaturizándola”, y con la etiqueta viewport que lo impide, que veremos a continuación:
¿Cómo podemos impedir que los navegadores móviles escalen nuestros sitios y los miniaturicen? La solución es una nueva etiqueta meta cuyo name es “viewport”, que solo es aplicada por dispositivos móviles y es ignorada en computadoras de escritorio.
Su sintaxis es la siguiente:
Dentro del atributo content, lo que hacemos es acotar que el width de la ventana del navegador tenga un valor “real”; es decir, que el navegador no nos “mienta”, sino que utilice como valor de su propiedad “width” el valor de otra propiedad, que es “device-width”, es decir, el ancho físico de su pantalla.
De esa manera, un navegador dentro de un dispositivo de por ejemplo, 320px de ancho, ya no declarará un width falso de 980px, sino que lo dejará en 320px, que es el ancho del dispositivo, con lo cual no miniaturizará nuestro diseño.
Por otro lado, apreciemos que hemos definido un valor inicial para el zoom, mediante la propiedad initial-scale a un valor de “1” que equivale a 100 por ciento , esto es, el tamaño natural. De esta forma, cuando el navegador ingrese a nuestra página, no aplicará ningún nivel de zoom que previamente el usuario hubiera configurado.
Los celulares más antiguos, cuyos navegadores no comprenden media queries, no tendrán inconvenientes en mostrar un diseño acorde a su tamaño si ese diseño es el primero en la hoja de estilos y no está envuelto en ninguna condición. Los navegadores móviles más modernos procesan media queries, así que tampoco son un inconveniente.
Las tabletas son dispositivos nuevos, creados a partir del año 2009, con lo que sus navegadores aguantan media queries.
El único inconveniente de compatibilidad lo vamos a tener en PCs de escritorio. Los navegadores de PC más modernos tienen soporte para media queries, pero algunos navegadores antiguos como Explorer 8 todavía sobreviven, y no interpretan las media queries.
Para solucionarlo, usaremos un script compatibilizador llamado CSS3-mediaqueries-js que puede descargarse en:
-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js
Simplemente vinculamos nuestra página HTML a ese script con una etiqueta
<script>y desde ese momento el Explorer ocho interpretará las media queries.
A forma de conclusión, vimos que es de manera perfecta posible crear experiencias de navegación por sitios multidispositivo, o sea, que se puedan utilizar con un diseño y unas herramientas optimados para diferentes tamaños de pantalla, si aprovechamos la técnica de media queries para crear esquemas tipográficos amoldables, layouts y grillas flexibles, elementos visuales como imágenes y vídeos líquidos, y herramientas de navegación optimizadas para el uso en pantallas táctiles.
| Комментировать | « Пред. запись — К дневнику — След. запись » | Страницы: [1] [Новые] |
