¿ Responsive Design es tu unica estrategia para moviles ?

Después de largas horas de maquetacion, programación javascript , backend y múltiples reparaciones de bugs,  finalmente haz terminado tu apreciada aplicación web. Ahora redimensionas el navegador y una sonrisa aparece en tu rostro, estas feliz... Tu piensas que ahora tu sitio web is "mobile-friendly", que has logrado todos lo objetivos con tu sitio web.

Déjame decirte una cosa ante de seguir con este articulo:

"Estas perdiendo usuarios y probablemente dinero, si responsive design es tu única meta y solución para el mundo móvil."

Responsive design es solo la punta del iceberg para afrontar el mundo de dispositivos móviles.

 (Creditos por image bradfrost)

Necesitamos entender mas allá de cualquier otro objetivo, que una experiencia para móviles debe de ser increíblemente rápida.

Por lo que entregar a nuestros usuarios el contenido lo mas rápido posible junto a una buena experiencia de usuario y que sea compatible con todos los dispositivos móviles, siempre ha sido un reto y no es diferente cuando estas implementando responsive design.

 El primer problema que nos encontramos es la de probar apropiadamente nuestra web en los todos los navegadores posibles. Por ejemplo 3 versiones de IE, FireFox, Safari,Opera, chrome, etc. Y después de esto tenemos el gran numero de navegares móviles en nuestras manos.

• iOS
• Android
• Blackberry Webkit
• IE Mobile
• Opera
• Firefox OS
• amazon phone 
• Y mas 

Al mirar esta lista te das cuenta de que estamos en un mundo de sufrimiento, si tratas de soportar todos los dispositivos móviles en el mercado. Para una mejor idea de este mundo puedes leer este articulo anterior.

 Una solución para estos casos es usar Google Analytics en tu sitio web y analizar que dispositivos usan tus usuarios y ajustar tu web acorde a ellos, aquí un articulo anterior sobre el tema. En general te entenderas que la mayoría del trafico proviene de dispositivos IOS y Android. Normalmente haremos todo lo que este a nuestro alcance para hacer que nuestro sitio luzca y funcione igual en ambos dispositivos, horas y horas de ajustes  y muchas veces terminaremos con algo así : "Excelente en IOS y ok en Android".

Pero tu no tienes que tratar estos dispositivos como iguales y tampoco hacer lo imposible para que tu sitio luzca excelente en ambos. Lo que realmente importa es ser mas considerado con nuestros usuarios y darles a estas personas que quieren interactuar con tu sitio web,  una experiencia funcional, hay una diferencia entre "soportado y optimizado".

Por razones de tiempo y presupuesto no es posible optimizar la experiencia de nuestra web para cada uno de los dispositivos conectado a internet, pero tenemos la responsabilidad de garantizar una experiencia decente para aquellos que desean interactuar con nuestros productos y servicios.

De acuerdo con Guy Podjarny’s research el 72% de los sitios web responsive entregan el mismo numero de bytes sin importar el tamaño de la pantalla, incluso en conexiones móviles. No todos los usuarios van a esperar a que tu sitio cargue y una única url no significa que deberías de entregar siempre el mismo documento ó que cada dispositivo debería descargar los mismos recursos.

Responsive design nunca tuvo la intención de resolver los problemas de rendimiento, por lo cual no podemos culpar a la técnica en si. Lo que si es un problema es creer que iba a resolver todos nuestros problemas, como muchos lo han pensado.

Pensar solo en tamaños de pantalla es sobrestimar  los dispositivos móviles. Mientras la linea entre escritorio y móvil esta volviéndose cada vez mas difusa, aun tenemos diferentes posibilidades abiertas a nosotros basados en el tipo del dispositivos que visitan nuestro sitio web. en lugar de basarnos en media queries. La funcionalidad de un sitio web no puede depender solamente de  media queries, algunos han empezado a llamar esto: "Responsible responsive design" mientras otros los consideran como responsive design con una vision moderna.

 Mientras no exista una mágica solución  y no todas las técnicas puedan aplicarse a cada tipo de documento, podemos usar un par de trucos para mejorar nuestros proyectos existentes y maximizar el rendimiento.

• Entregar cada documento a todos los dispositivos con la misma url y el mismo contenido, pero no necesariamente tiene que tener la misma estructura html.
• Siempre al inicio de cada proyecto comienza por "mobile first".
• Probar tus sitios en dispositivos fisicos, analizar que pasa cuando carga y cuando "display:none" es usado. Nunca confies solamente  redimensionar el navegador.
• Usa tecnicas responsive images via javascript mientras esperamos una mejor solucion de parte de los navegadores.

Conditional Loading

No siempre confíes en las media queries. Los navegadores cargaran y parsearan todos los selectores y estilos para todos los dispositivos. Esto significa que un teléfono móvil podría descargar todo el css destinado para escritorio y adicional el css hace que el navegador espere hasta que todos los estilos css sean descargados. Podrías estar gastando preciosos mili segundos en una conexión móvil.

Reemplaza las media queries con matchMedia  de javascript en dispositivos de los cuales sabes que su contexto no cambiara, por ejemplo: Sabemos que un iphone no puede convertirse en el tamaño de un ipad dinamicamente, entonces solo necesitamos cargar el css para ese dispositivo. También podemos usar Modernizr para tomar decisiones inteligentes acerca de la interfaz y funcionalidad no solo basados en el tamaño de la pantalla.

Un típico sitio responsive entrega un único html para todos los dispositivos: escritorio, tablets, teléfonos, etc. Esto suena genial pero vivimos en un mundo con problemas de conexión y otros factores. Tu diseño responsive puede verse correctamente en dispositivos móviles pero no es tan rápido como debiera de ser y eso esta afectando tu conversiones.

Esto no es una regla de oro pero si un simple "display:none" aparece en cualquiera de tus estilos css, entonces tu sitio no es tan rápido como debiera, debido a que ocultas contenido que no se necesitas en otras resoluciones, por ejemplo : 10 scripts externos, jquery plugins y bonitas librerías que solo son usadas para grandes resoluciones.

Media queries

Media queries son usadas en diferentes formas, comúnmente son así:

• Un único archivo css con múltiples declaraciones @media
• Múltiples archivos css linkeados en la pagina principal via atributos : <link rel="stylesheet" media="(max-width: 800px)" href="example.css" />

En el primer caso cada dispositivo descargara el archivo css, por que es un único archivo, cientos de selectores que nunca seran usados son descargados por el navegador.

En el segundo caso puedes pensar que tener múltiples archivos  es mejor, por que el navegador cargaría solo los estilos basados en los breakpoints, esto es lo que nos enseñan en tutoriales, blogs, libros y cursos. Pero eso no es correcto, todos los navegadores descargaran todos los archivos css externos sin importar el atributo usado.

¿ Por que  lo navegadores hacen esto ?

Supongamos que tenemos un archivo css para portrait y otro para landscape. Si los navegadores cargaran los css solo cuando se necesitan, en el momento que pasas de portrait a landscape tendrás unos milisegundos congelado el navegador mientras se descarga y parsea el css ó tu pagina no tendrá estilo en esos instantes. Por eso eso los navegadores precargan todos los estilos desde el inicio.

¿ Pueden las dimensiones de los navegadores móviles cambiar ?

Comúnmente no, pero los navegadores móviles  se están preparando para ser redimensionados como en escritorio en  un futuro cercado, por esa razón los navegadores precargan todos los estilos sin importar las condiciones lógicas en media queries. Lo cual nos deja el problema actual: Estamos entregando mas recursos de los que realmente se necesitan, por lo tanto haciendo sufrir a los usuarios móviles sin ninguna razón.

Responsive basado en grupos 

Mientras podemos confiar en un único archivo html base y responsive design para todos los tamaños de pantallas cuando se trata de paginas simples, entregar el mismo html en escritorio y móviles no es siempre la mejor solución, debido a los problemas de rendimiento en móviles. Incluso si tenemos el mismo html en el servidor, nosotros podemos entregar diferentes estructuras basado en un grupo de dispositivos, por ejemplo:

Podemos entregar un gran menú flotante para pantallas de 6 pulgadas a mas, y un menú pequeño para pantallas mas pequeñas de 6 pulgadas. Dentro de cada grupo nosotros podemos  usar técnicas responsive para adaptar los menús en diferentes escenarios, como por ejemplo landscape y portrait. También cambiándolos un poco según el dispositivo (iphones 320px, android 360px, phanblets 400px)

Capas del lado del servidor

El backend es parte de las soluciones en responsive design. Mezclar responsive design con componentes del lado del servidor no es nuevo, se le conoce como RESS y algunas veces como "adaptive design", Mejora la velocidad y usabilidad mientras mantiene un único código base para todos en el server.

 Desafortunadamente esta técnica no ha tenido mucha popularidad en la comunidad en algunos años y la única razón para esto es: "Somos programadores front-end, cualquier cosa que involucre al servidor luce como un problema para nosotros y no queremos eso".

Por que en algunos casos el diseñador front-end estará en control de un script en el servidor y en otros casos sera un equipo de desarrollo remotamente y el diseñador no querrá tener que tratar con el equipo cada vez que tenga que hacer un pequeño cambio en la UI.

Responsive design, rendimiento y datos técnicos

Algunas personas piensan que las redes móviles de hoy son lo suficientemente rápidas e incluso que en todo el mundo esta disponible 4G, lo cual no es cierto y suponiendo que en todo el mundo estuviera disponible 4G la situación no podría ser como lo esperamos. Menos del 3% de los teléfonos moviles tienen 4G, solo en EEUU el numero de usuarios 4G ha alcanzado 22% , incluso estos usuarios no están en 4G el 40% del tiempo.

Usualmente pensamos en redes móviles en términos de ancho de banda. Con 3G obtenemos 5 mbps; con 4G 50 mbps. Pero eso no es generalmente el factor mas importante en una experiencia móvil. Mientas que mas ancho de banda es útil para transferir grandes archivos como vídeos de youtube, esto no agrega mucho valor  cuando estas descargando muchos archivos pequeños, y la latencia es alta y fija. Latencia es el tiempo de viaje de ida y vuelta que el primer byte de cada paquete le toma para alcanzar el dispositivo después de una petición.

Las redes móviles tienen mas latencia que las demás conexiones, por ejemplo: La latencia en una conexión DSL domiciliar en EEUU es entre 20 y 45 milisegundos, en 3G puede ser de 150 y 450 milisegundos, y en 4G es entre 100 a 180. En otras palabras la latencia es de 5 a 10 veces mas alta en un conexión móvil que en una domiciliar.

Navegadores en la nube

Si todavía dudas de que el rendimiento es un problema solo para móviles, considera que algunas de las empresas detrás de los populares navegadores están creando navegadores basados en la nube, por ejemplo: Estas compañías están comprimiendo cada sitio web y sus recursos en la nube y entonces el navegador descarga una versión optimizada para el dispositivo móvil. Ellos lo hacen por que ellos saben que el rendimiento es importante para la felicidad de los usuarios.

El principal objetivo de cualquier sitio web debería de ser usuarios felices, el cual te creara mas conversiones. El rendimiento de un sitio web tiene un gran impacto en las conversiones y particularmente en móviles que ha sido comprobado muchas veces.

"A tus visitantes no les un importa si tu sitio web es responsive, no les importa si la versión móvil esta separado del resto, y tampoco si solo es texto. Lo que a ellos les importa es que no puedan hacer lo que necesitan hacer, lo que a ellos les interesa es que tu sitio tome 20 segundos en cargar, a ellos les interesa si las interacciones sean incomodas y no funcionen." - Brad Frost

Los usuarios quieren algo rápido y fácil de usar, ellos usualmente no redimensionan el navegador y ellos no entienden lo que significa "responsive". Para abordar toda la diversidad de dispositivos existentes en internet, tenemos que tomar el asunto en nuestros manos y hacer todo lo que podamos para hacer la experiencia mas flexible. Los días de "desktop-only" han terminado y esto no solo involucra estructuras html adaptables, tambien un sinnúmero de otras cosas a tener en cuenta.

Hay un articulo interesante de como se ha incrementado el tamaño de las paginas con los años: http://www.sitepoint.com/average-page-weight-increases-15-2014/

technology	end 2013	end 2014	increase
HTML	57Kb	59Kb	+4%
CSS	46Kb	57Kb	+24%
JavaScript	276Kb	295Kb	+7%
Images	1,030Kb	1,243Kb	+21%
Flash	87Kb	76Kb	-13%
Other	205Kb	223Kb	+9%
Total	1,701Kb	1,953Kb	+15%

Responsive web design es una metodología siempre cambiante que ayuda a manejar lo desconocido,  nuestro trabajo nunca termina , creamos , adaptamos, aprendemos y creamos de nuevo.

links:

• http://www.smashingmagazine.com/2014/07/22/responsive-web-design-should-not-be-your-only-mobile-strategy/
• http://bradfrost.com/blog/mobile/support-vs-optimization/
• http://www.smashingmagazine.com/2013/03/11/responsible-web-design/
• https://speakerdeck.com/smashingmag/responsive-web-design-clever-tips-and-techniques
• http://timkadlec.com/2012/10/blame-the-implementation-not-the-technique/ 
• http://www.sitepoint.com/average-page-weight-increases-15-2014/

Suscribete para recibir mis ultimas noticias

Responsive design con medidas relativas (em y rem ), no mas pixeles.

En la actualidad cuando hablamos de responsive design hablamos de que nuestras web app se adapten a cualquier resolución de pantalla, ya que la gran cantidad de dispositivos móviles y tamaños de pantalla es increible. Una manera de lograr esto es con “Media Queries” por medio de ellas se trata de “identificar” el comportamiento del layout de acuerdo a las resoluciones de las pantallas más usadas.

Normalmente se crean “breakpoint”, los breakpoint son los tamaños específicos donde tu diseño se rompe y es en ese momento donde tenemos que escribir  “Media Queries” para resolver el problema.

Creo que alguien definió el proceso de esta manera : “Comienza con la pantalla más pequeña, luego expándela hasta que luzca como la mi*rda. Tiempo de hacer un breakpoint!"

Hoy en dia esta manera de pensar en el diseño no es lo adecuado ya que la web no es solamente  fluída, ya no hay más “pixel perfect” y debemos dejar de pensar que “Media Queries” sirve para setear solamente los anchos de los elementos, debemos de pensar también en los márgenes y  estilos.

Como programadores frontends debemos saber qué cosas podemos controlar y que cosas no. Nuestros usuarios serán los que decidan cómo visualizar nuestro sitio de la manera en la que ellos quieran. Asi que debemos dejar de pensar en “píxel perfect” cuando diseñamos para Web, y saber que los diseños estarán en constante cambio, por lo cual debemos de optimizar el contenido.

Lo primero que tenemos que hacer es configurar correctamente el viewport, normalmente lo configuracion del viewport se hace de la siguiente manera : 

<meta name="viewport" content="width=device-width, user-scalable=no">

ó

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">

El propiedad width controla el tamaño del viewport , puede tomar valores fijos como 500px  o como en ese caso el valor “device-width” el cual es el ancho de la pantalla del dispositivo en pixeles a una escala de 100%. Instruye a la pagina a que su ancho tiene que coincidir con el ancho del dispositivo.

La propiedad “user-scalable=no" deshabilita las capacidad de hacer zoom y el usuario solo podrá hacer scroll, lo cual da la sensación de que tu sitio parezca una app nativa.

La propiedad “initial-scale” controla el nivel de zoom cuando la página inicia. Algunos navegadores incluidos IOS y Windows phone,mantendrán el ancho de la pagina constante cuando sea rotado en horizontal (landscape mode) ó hagas zoom, en lugar de acomodar el contenido en pantalla. Agregando el atributo "initial-scale=1" instruye al navegador a establecer una relación 1:1 entre los pixeles CSS y los pixeles del dispositivo independientemente de su orientación y permite  tomar ventaja del todo el ancho en modo landscape.

 Pueder ver un ejemplo en este link,section "Responsive Viewport" : https://developers.google.com/speed/docs/insights/ConfigureViewport

“maximum-scale” controla el máximo de zoom permitido al usuario, por lo general siempre lo he visto en valor 1 y esto puede resultar un problema para algunas personas. Aunque los elementos de nuestra web tengan tamaños adecuados puede haber algunos que no se puedan ver correctamente.

Los textos en imágenes podrían verse demasiado pequeños en un móvil. En este caso el usuario tendrá que hacer zoom para leerlo, pero no podrá. Esto supone una frustración para el usuario, algo que tenemos de evitar para ofrecer una buena experiencia.

La manera correcta en que debemos configurar el viewport es esta :

<meta name="viewport" content="width=device-width, initial-scale=1">

Por defecto, "user-scalable" tiene el valor de yes, es decir, el zoom está activado. Si no definen "maximum-scale", el zoom máximo será el determinado por el navegador, lo que resta hacer es tratar de crear nuestras “Media Queries” de manera correcta y adaptar el contenido lo mejor posible.

Cuando en una Web no es especificado el viewport, los navegadores de dispositivos móviles mostraran la web con una resolución de 800px a 1024px, el factor de escala de la página es ajustado para mostrarse, forzando a los usuarios hacer zoom antes de que puedan interactuar con la Web.

Ahora basándonos en que nuestro contenido tiene que adaptarse perfectamente en muchas resoluciones de pantallas, lo correcto sería usar unidades de medidas CSS relativas para los tamaños de letras en lugar de pixeles, por qué necesitamos cambiar los tamaños de letras de acuerdo a los diferentes tamaños de pantalla.

El tamaño de letra que se ve bien en un dispositivo móvil, no será adecuado en una pantalla de escritorio. Con todos estos cambios de tamaños, nuestros textos se modifican constantemente, es así que al diseñar para responsive debemos controlar cómo fluctúan los mismos entre las resoluciones.

En CSS existen varias maneras de darle tamaño a los textos las más comunes son:

• PX: píxeles
• PT: puntos
• EM: em es la anchura de la letra mayúscula "M" en el tipo de letra dado

CSS divide las unidades de medida en dos grupos: absolutas y relativas. Las medidas relativas definen su valor en relación con otra medida, por lo que para obtener su valor real, se debe realizar alguna operación con el valor indicado. Las unidades absolutas establecen de forma completa el valor de una medida, por lo que su valor real es directamente el valor indicado.

Las medidas absolutas en CSS son el Pixel y el Punto. Los navegadores establecen por defecto el tamaño de 16 pixeles, 16 píxeles equivalen a 12 puntos. El tamaño para textos en web debe aproximarse a los 16px ya que es el equivalente a los 12px en la impresión en papel. Las pantallas están más alejadas que el libro, además que es preferible subirle el punto a tener que adoptar una mala postura para poder leer el texto.

Las medidas relativas son el "porcentaje, em y rem", como dice la definición debemos establecer una medida base para que la medida sea calculada en base a esta.

Al  usar “Media Queries” con unidades de medida relativas  para cambiar los tamaños de texto, solo tendríamos que cambiar el tamaño en un solo elemento base y  automáticamente los demás elementos con unidades relativas se ajustarán basado en el nuevo tamaño.

Medidas EM

Recordemos que las medidas relativas  definen su valor así :

” definen su valor en relación con otra medida, por lo que para obtener su valor real, se debe realizar alguna operación con el valor definido”.

En el caso de em su valor es relativo al “font-size” del padre directo ó del padre más cercano, esto quiere decir que cualquier cambio del CSS en cualquier nivel del DOM hace que 1em adquiera el valor de “font-size” del padre.

Por ejemplo si no definimos ningún “font-size” en nuestro css, el valor por defecto será de 16px que es el valor que asigna el navegador, por lo tanto 1em equivale a 16px.

1em = 16px

1.5em = 24px

2em = 32px

ect..

Pero podemos modificar el valor por defecto de 16px de los navegadores, por lo tanto el valor de em usaría ese valor como base, en el siguiente ejemplo podemos ver como se ha cambiado el “font-size” a 1.375em en la etiqueta html, haciendo que las demás medidas se ajusten de acuerdo a este como base por la herencia.

En este link podemos ver un ejemplo:

http://codepen.io/jeremychurch/pen/rCcIh

Para calcular el valor de las unidades em usamos la siguiente fórmula :

1em * 16px = 16px

Una técnica muy usada para no estar haciendo tanto cálculo, consiste en bajar el porcentaje para que el valor en píxeles nos de 10px. Consiste es ajustar el tamaño del “font-size” en el body para que sea equivalente a 1em =  10px en lugar de los 16px por defecto, de esta manera es más cómodo ajustar nuestros tamaños en ems. El valor de 62.5% equivale a 10px;

body { font-size:62.5%; }
h1 { font-size: 2.4em; } /* =24px */
p  { font-size: 1.4em; } /* =14px */
li { font-size: 1.4em; } /* =14px */

El problema de usar em es que se basa en herencias. Entonces si por ejemplo en una etiqueta p tengo un “font-size” y asigno el mismo “font-size” en la etiqueta span por ejemplo, span hereda el tamaño de p como su base para em. Entonces hay que estar ajustando medidas todo el tiempo, ejemplo:

<style>
html {
   font-size:62.5%;
 }
p, span{
    font-size:1.6em;
 }
</style>
<p> texto texto texto <span> Holaaaa </span> </p>

p tendría 1.6em el cual lo hereda a span y este lo tomaria como base para sus medidas em.

Para resolver este problema con CSS 3 ahora tenemos rem.

Medidas REM

Rem significa Root em y se basa en que con sólo declarar el rem base al elemento html las medidas siguientes no dependerán de la herencia sino del número base que hayamos declarado. Mientras em es relativo al “font-size” del padre directo o mas cercano, rem solo es relativo al “font-size” del elemento html.

Podemos definir el “font-size” del html y definir el resto de los medidas en rem basados en el porcentaje de este.

html { font-size: 62.5%; }
h1 { font-size: 2.4em; } /* =24px */
p  { font-size: 1.4em; } /* =14px */
li { font-size: 1.4em; } /* =14px */

El sorporte de rem es bastante decente hoy en dia : http://caniuse.com/#search=rem

Otro uso muy interesante es por ejemplo para márgenes ó padding relativos, digamos que queremos usar “font icons”, en el header de nuestra web y estos tienen un valor de margin-top de 20px. 

 Podemos usar un valor relativo en “font-size” en los iconos para ajustar el tamaño de estos, lo cual hará que se ajusten dinámicamente cuando cambiemos el valor del elemento base, pero el margin-top siempre será de 20px porque  tiene un valor absoluto.  Lo ideal seria que el margin-top se ajuste en dependencia del tamaño del icono.  Lo que tenemos que hacer es usar medidas relativas en el margin-top ya sea em o rem de esta manera se ajustara en concordancia con los tamaños de los iconos.

Cual debo usar em ó rem ?

La respuesta a esta pregunta es como la mayoría de las cosas, es opcional y depende de las preferencias del programador, debemos usar con la que mas nos sintamos cómodoss y la que menos dolores de cabeza nos produzca.

Medidas relativas con Media Queries

Ahora si queremos ajustar el tamaño de nuestro contenido basado en los tamaños de pantalla podemos hacer uso de las “Media queries” de la siguiente manera. Tomando los ejemplos anteriores como partida podemos ver este sencillo ejemplo:

body {
    font-size: 1.2em
}

@media (max-width: 1000px) {
 body { font-size: 1.375em  }
}

@media (max-width: 500px) {
 body { font-size: 1.6em  }
}

De esta manera todos los elementos con medidas relativas em heredan de body por lo tanto al cambiar el “font-size” de body se calcularán con este valor como base.

Usar  "em" para Media Queries en lugar de  "rem"

¿Porqué? porque el valor que obtiene "em" en Media Queries es relativo al user agent(valor por defecto del navegador ), no al estilo CSS que definimos. Por lo que si usas "rem", que debe tener una base definida en el CSS, nunca tomará esa base definida, sino que siempre tomará la medida 16px o 14px según el navegador, cosa que no podemos controlar.

Esto es debido al especificacion de la w3 :

http://www.w3.org/TR/css3-mediaqueries/#units

“Relative units in media queries are based on the initial value, which means that units are never based on results of declarations. For example, in HTML, the ‘em’ unit is relative to the initial value of ‘font-size’.”

El uso en las de las medidas relativas no solo se pueden limitar al “font-size” en el uso de las “Media Queries”, también las podemos usar como valor para margin, padding , width y height incluso en las mismas “Media Queries” ya que tomarán como base los 16px por defecto del navegador y se aplicarán las mismas reglas. Por ejemplo:

p { 
  width: 46.25em
  font-size: 0.750em;
  line-height: 1.5em;
  margin: 1.5em;
}

/* landscape phone and portrait tablet (>= 480px < 960px) */
@media screen and (min-width:30em) and (max-width:59.9999em) {
}

/* bigger monitor (>= 1440px) */
@media screen and (min-width:90em) {
}

/* big monitor (>= 1920px) */
@media screen and (min-width:120em) {
}

Pero hay que tener mucho cuidado de saber siempre cual es valor por defecto de “font-size” en los navegadores, ya que en algunos navegadores puede ser diferente de 16px. Por ejemplo en safari mobile he leido que es de 12px.

Usa esta herramienta para saber que tamaños usar en tus medidas relativas: http://type-scale.com/

Encontre un post en stackoverflow donde resolvieron este problema con este código:

body {
    -webkit-text-size-adjust:none;
    -moz-text-size-adjust:none;
    -ms-text-size-adjust:none;
    -webkit-text-size-adjust:100%;
    -moz-text-size-adjust:100%;
    -ms-text-size-adjust:100%;
}

http://stackoverflow.com/questions/19569703/em-based-css-media-query-showing-smaller-resolution-than-expected-on-ios-mobile

El uso de medidas relativas en responsive design puede ser todo un reto, pero tenemos que empezar a pensar de esta manera, ya que el “pixel perfect” ya no existe.

Nota final: ( Antes de usar rems y ems por favor revisa la compatibilidad en móviles, por que al parecer hasta este momento de escribir este articulo, el soporte en móviles es muy pobre, por lo tanto usar con precaución )

A continuacion dejo links que considero importantes leer sobre este tema, mi post esta basado en todos ellos.

•   http://www.cristalab.com/blog/diseno-responsive-con-media-queries-y-em-muerte-a-los-pixeles-c113446l/
• https://developers.google.com/speed/docs/insights/ConfigureViewport?utm_source=blogspot&utm_campaign=mobile_ux
• http://j.eremy.net/confused-about-rem-and-em/
• http://css-tricks.com/why-ems/
• http://www.cristalab.com/tutoriales/como-calcular-tamanos-tipograficos-para-web-c113111l/
• http://www.cristalab.com/tutoriales/las-medidas-em-y-rem-en-css3-c113125l/
• http://snook.ca/archives/html_and_css/font-size-with-rem
• http://www.cristalab.com/blog/la-tipografia-en-tiempos-de-responsive-c112999l/
• http://www.maestrosdelweb.com/editorial/5-errores-tipograficos-comunes-en-la-web-y-como-solucionarlos-cromos-vs-t-magazine/
• http://www.cristalab.com/blog/lorem-ipsum-y-la-discordia-del-texto-simulado-c113055l/
• http://j.eremy.net/confused-about-rem-and-em/
• http://www.smashingmagazine.com/2013/03/01/logical-breakpoints-responsive-design/
• https://developer.mozilla.org/en/docs/Mozilla/Mobile/Viewport_meta_tag
• http://nerd.vasilis.nl/dislike-rem-unit/

---

Mobile first y responsive design como lograrlo

Hoy en día es muy normal cuando un cliente quiere un nuevo sitio web, crearlo pensado en el diseño responsive y orientado a móviles. Ya que hay numerosos artículos y estudios que nos muestran cuanto crece continuamente el mercado en dispositivos móviles en celulares y tablets, solo basta con hacer pequeña búsqueda en Google para darnos cuenta.

Existen muchas marcas de teléfonos móviles y tablets y todos ellos con distintas resoluciones de pantalla y  resulta un tanto complicado adaptar un sitio web que luzca perfecto en todos ellos. Muy recientemente a surgido una tendencia llamada Mobile First debido al explosivo aumento de móviles en el mercado, que consiste en diseñar un sitio web pensando en móviles primero y después la versión para escritorio. En lugar de mostrarles datos y estadísticas sobre esta tendencia mejor los invito a ver el siguiente vídeo de los chicos de mejorando.la que lo explican mejor que yo.

Ahora con este concepto de Mobile first en mente, quiero mostrarles como seria la mejor manera de adaptar un sitio web basados en datos reales con Google Analytics. Lo siguiente que voy a explicar solo podría ser aplicable en sitios web que ya existen de los cuales podríamos tomar sus datos de visitas de sus usuarios. No podríamos hacer esto con sitios nuevos por que no tenemos datos de visitas pero con el tiempo podemos adaptar sus diseños de interfaz con la misma técnica una vez que tengamos sus datos de visitas.

Ahora para comenzar vamos a imaginarnos que tenemos un cliente que quiere renovar su sitio web y el cliente ha escuchado esto de responsive design y desde un inicio nos dice : 

"Oye quiero que mi sitio web sea responsive, he escuchado que de esta manera las personas pueden ver mi sitio web desde cualquier dispositivo"

Entonces lo que primero que tenemos que hacer antes de ponernos a programar como locos un diseño de interfaz es obtener datos importantes que nos permitan guiarnos sobre el tipo de diseño que vamos a crear , a que tipos de teléfonos esta orientado, marcas, sistema operativo y resoluciones de pantalla. 

Para obtener estos datos podemos pedirle a nuestro cliente que nos de acceso a su cuenta de Google Analytics para verlo por nosotros mismos. Si el cliente no cuenta con una cuenta de estas pues tocara a nosotros crearle una e insertarla en su sitio web para recolectar este tipo de datos.

Si no sabes como crear una cuenta Google Analytics solo basta que pongas en google "como crear una google analytics" y tendrás muchos links donde te dicen como hacerlo, ademas que Google te guía paso a paso en la creación de una cuenta y como debes de agregarlo a un sitio web.

Ahora supongamos que tenemos nuestros datos Google Analytics listos, para los ejemplos siguientes ejemplos  usare capturas de pantalla de los datos de visitas de mi blog, ok comencemos.

¿ Este sitio web realmente necesita un diseño responsive ? ¿ Que tantas visitas recibe de moviles como para justificar este diseño ?

Para responder esta pregunta tenemos que ver el reporte que se encuentra en Publico > Movil > Vision General .

En este reporte podemos ver cuantas visitas recibe el sitio web en escritorio, teléfonos y tablets. Este reporte nos dice realmente si nuestro sitio web esta siendo visitado por medio de móviles y si merece la pena rediseñar el sitio web. En el ejemplo que he puesto puede verse claramente que este sitio web es mayormente visitado por desktops, por lo cual seria una muy mala idea gastar dinero por ahora en un rediseño enfocado en moviles.


¿ En que marcas de móviles debo de enfocar mis esfuerzos en la creación del  diseño de mi sitio web ?

En la sección Publico > Movil > Dispositivos , en este reporte podemos ver las marcas de los dispositivos móviles que visitan el sitio web, de esta manera podemos enfocar nuestros esfuerzos de diseño y programación basándonos en estos modelos. Aunque deberías de tratar de abarcar todos los modelos posibles , siempre es bueno tener como meta los de nuestros propios visitantes.

En el ejemplo podemos ver que tenemos que enfocar nuestro diseño mas en iphone y motorola , así que podríamos buscar las resoluciones de pantallas de estos dispositivos y hacer los cambios necesarios basados en esas dimensiones.

¿ Cuales son las resoluciones de pantallas en la que debo enfocarme para mi diseño ?

En la sección Publico > Movil > Dispositivos existe una opción arriba a la derecha que nos permite saber cuales son las resoluciones de pantalla de nuestros visitantes, de esta manera podremos enfocar nuestro trabajo en mejorar nuestra web en esas resoluciones.


¿ Que navegadores son los que tengo que soportar en mi sitio web ?

En la sección Publico > Tecnología > Navegadores y SO  , podemos ver los tipos de navegadores que nuestros visitantes usan para ver nuestro sitio web, asi podemos saber si los usuarios podrán ver todas las características de nuestro sitio sin problemas o mejorar la compatibilidad en caso de que sea necesario. Tambien arriba a la tenemos una opcion para ver los Sistemas operativos de nuestros visitantes.


Con este tipo de datos a nuestra disposición podemos abordar de mejor manera los problemas de diseño y programación de sitios web de nuestros clientes y no estar programando a lo loco. Hay muchas otras buenas cosas en Google Analytics que yo no he comentado aquí y que también ignoro pero con estos básicos reportes sera suficiente para ayudarnos en nuestro trabajo.

link : http://www.smashingmagazine.com/2014/03/03/how-to-use-analytics-to-build-a-smarter-mobile-website/

Responsive image con Mobify.js

He leído incontables artículos sobre como tratar el problema de responsive images, debido a que no tenemos un estándar todavía para resolver este problema, muchas soluciones aparecen día a día tratando de resolverlo. 

Pero entre todas las soluciones que leo, en mi opinión personal esta es  la mejor de todas:  Mobify.js es una librería open source para mejorar los sitios responsive, la cual automáticamente redimensiona y comprime las imágenes sin escribir nada de código, simplemente entregamos nuestra imagen en alta resolución y la API se encargara del resto por nosotros.

Para saber mas sobre su uso y un análisis detallado sobre como funciona les dejo el siguiente link, la verdad que mejor articulo que este no hay sobre el uso de esta librería .

link : http://mobile.smashingmagazine.com/2013/10/24/automate-your-responsive-images-with-mobify-js/

Diferencia entre Fixed, Fluid, Adaptive, y Responsive Web Design

Bueno una pregunta valida que merece la pena ser respondida con un buen video , aunque esta en ingles creo que se da por entendido solo.



Si no quedastes claro con el video visita esta pagina web: http://liquidapsive.com/

Link : http://blog.teamtreehouse.com/whats-the-difference-between-fixed-fluid-adaptive-and-responsive-web-design-treehouse