Creatividad colaborativa: un nuevo paradigma de la innovación

Muy buena charla que vale la pena ver sobre lo que es "economía creativa", lo que me gusta es que  Lorena Escandon ofrece consejos de como las empresas deberían de tratar a sus empelados y como  cambiar su aptitud hacia un proceso creativo. Excelente material para innovar como empresa en los tiempos actuales.





Adicional un lectura de consejos sobre como tratar a los empleados en un ambiente web:
http://www.smashingmagazine.com/2013/10/18/lessons-learned-leading-new-web-professionals/

¿ 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

¿ Como vender el valor de un sitio web a tus clientes ?

A continuación Resumen de un articulo muy bueno que he leído.

Una de las cosas mas importantes como freelancer es saber como vender el valor de un sitio web a tus clientes. Tus clientes necesitan ser convencidos que un sitio web es bueno para su negocio, necesitas  demostrar el alcance y el impacto que podria tener en sus ventas.

Un clasico caso con un cliente podria ser como este:

"Hola el desarrollo de un sitio web cuesta: $$$$"
"mmm  eso lo veo muy caro, creo que mejor le pedire a mi sobrino que me ayude a crearla gratis."

Cuando este ocurra es tu chance para vender el valor de la Web.

Un sitio web es una inversión.

Los pequeños negocios y empresas no entregan dinero tan fácilmente, por que no pueden darse el lujo de ello, el dinero es muy preciado para ellos. Obviamente ellos se darán marcha atrás cuando sepan  el costo real del diseño y desarrollo de un sitio web.

Pero la única cosa mas importante que el dinero para ellos, es el futuro y el crecimiento de su negocio o empresa.  El truco entonces seria venderles que con un sitio web el retorno de su inversión esta garantizado.

Ademas del argumento "Su negocio estará abierto 24/7" tu puedes vender tu diseño profesional web en muchas maneras.

Todo puede ser medido.

Con una cuenta gratuita de Google Analytics tu puedes medir muchas cosas de tu sitio web, que no pueden ser medidos por anuncios convencionales como los impresos o anuncios de televisión. Por ejemplo : visitas diarias, que paginas son las vistas, de que lugares te visitan, etc. Este es un magnifico punto para vender tu servicios, por que le reafirma a tus clientes que ellos pueden siempre revisar estas métricas  y comprobar que su sitio web esta trabajando para su negocio y si los resultados no son los que esperaban pueden saber que cosas ajustar.

Tu imagen, de la manera que tu quieres

Un sitio web es la imagen de tu negocio en linea. Tus cliente necesitan saber que sin un sitio web , su negocio pierde alcance frente a otros competidores que actualmente si los poseen. Un sitio web pobremente diseñado afectara directamente la credibilidad de tu negocio.

Publicidad eficaz

El dinero gastado en publicidad en linea para atraer potenciales clientes a tu sitio web es mucho mas manejable y medible que el dinero gastado en publicidad tradicional como periódicos, volantes o guías telefónicas. Tu obtienes métricas y resultados  de como tu compaña de publicidad en linea esta marchando y ajustarla a como te plazca.

Tus clientes no podrían tener tanto control y precisión sobre sus gastos y resultados de sus anuncios si no tuvieran un sitio web, este es un gran punto para venderles a tus clientes sobre su inversión en un sitio web.

Mejora la productividad

Este es probablemente la ultima cosa que tus clientes esperan de un sitio web. En general un sitio web puede mejorar la productividad y liberar tiempo  que es usado en tareas manuales. Por ejemplo un formulario de contacto, la mayoría de las personas esta mas dispuesta a llenar un formulario en linea que hacer una llamada telefónica, es fácil y rápido.

No solo le ahorra tiempo a tus clientes, si no que tendran mas tiempo para pensar las respuestas a estas preguntas  a diferencia de que  lo hubieran llamado por teléfono.

Tu obtienes lo que pagastes

En este punto seguramente tu ya has convencido a tus clientes de que necesitan un sitio web, pero ellos aun están preocupados sobre el dinero que tienen que pagar, incluso si ahora miran un sitio web como una inversión.

Tus clientes seguramente están pensando en maneras mas económicas de crear su sitio web, lo cual es muy fácil, por ejemplo solo basta tomar un plantilla gratis wordpress  y configurar el sitio. El truco aquí es asegurar a tus clientes que ellos recibirán lo que están pagando: un sitio web profesional con una imagen para su negocio que inspire confianza a sus potenciales clientes, recuerda que tu sitio web creara en sus visitantes la confianza de un negocio solido y confiable.

Explica las posibilidades

Muchas personas como tus clientes no saben que pueden lograr con un sitio web por ejemplo: Pagos de facturas, ventas, administrar contenido de productos, registro de newsletters, campañas de email, suscripciones a sus servicio , etc. y la lista podria seguir.

Tus clientes necesitan saber lo que pueden hacer y entenderán que necesitan un experto a su lado para el desarrollo de su sitio web. Asegurate que no solo estas vendiendo una lista de cosas que puede hacer, tu quieres que ellos te vean como alguien en quien pueden confiar y obtener respuestas sobre todas esas actividades.

Todas esas actividades son solo parte de lo que tus clientes quieren, después de todo hay miles de freelancers que puede diseñar y crear sitios web como tu.

La importancia del diseño

Como diseñador que eres tu sabes la importancia de una imagen en linea, pero tus clientes no la saben. El truco aquí es hacer que tus clientes reconozcan esta importancia. Por ejemplo puede usar el siguiente parrafo de Razorfish’s report on branding es de hace 5 años pero es muy bueno:

"Deacuerdo con nuestros estudios 65% de los clientes reportan que una experiencia de una marca digital ha cambiado su opinión sobre una marca o producto y servicio "

Muestra estadísticas

Si tus clientes aun necesitan ser convencidos del porque necesitan un sitio web muestra algunas estadísticas. Por ejemplo el aumento de personas en internet, el aumento de los dispositivos móviles para buscar información, etc.

Aqui tienes un link de ejemplo: http://pueyrredonline.com/blog/2012/09/beneficios-de-las-compras-por-internet-en-america-latina/

Analiza a sus competidores

Otra gran manera de convencer a tus clientes es hacer una simple búsqueda en google en frente de ellos sobre sus competidores, lo cual lo convencerá de que esta ausente en internet. Al mismo tiempo puedes señalar los puntos buenos y malos de sus competidores en orden de que entiendan de que manera tu harías la cosas diferentes.

Trae las redes sociales a la mesa.

Por que hay que afrontarlo twitter y facebook  son muy visibles en estos días. Este puede ser un paquete adicional que puedes vender a tus cliente para dar mas difusión a negocio.

Ofreciendo una estrategia en las redes sociales o al menos diseñando un perfil y una foto de portada bonitos  es usualmente fácil de vender.



Link
 http://www.smashingmagazine.com/2014/07/29/selling-to-small-town-clients/
http://www.smashingmagazine.com/2013/10/30/selling-responsive-website-design/

Javascript domina la web... pero hay que tener un poco de cuidado

Lo siguiente son trozos de varios artículos que he leído con los que estoy de acuerdo y creí que vale pena compartir en manera de un unico post.

 Quiero comenzar diciendo que soy un gran fan de javascript, escribo gran cantidad de código con el y lo encuentro increíblemente útil, de ambas maneras como un lenguaje de programación y como una manera de mejorar la usabilidad y accesibilidad del contenido web. En los primeros días de la web muchos programadores se distanciaban mucho de javascript, muchos lo miraban como un lenguaje de juguete y lo sentían similar a html y css. No era tan poderoso como Java,C o Perl por lo que no valia la pena aprenderlo. Pero con el pasar de los años javascript cambio mucho.

 La mayoría de los programadores comenzaron a tomarse enserio javascript cuando AJAX se volvió popular y con el nacimiento de los frameworks MVC javascript (angular,ember,ect) muchos programadores empezaron a volcarse a javascript. El único problema que veo con esto es la desconexión fundamental de estos programadores parecen tener en la manera en que ellos crean código para la web. En el desarrollo tradicional de software tenemos cierto control sobre nuestro entorno, pero en la web no.

 Por ejemplo si estamos escribiendo un programa del lado del servidor en Python, Rails o php una de estas cosas es cierta:

 1 - Nosotros controlamos el entorno del servidor: SO , versión de lenguaje paquetes , ect
 2 - Nosotros no controlamos el entorno del servidor: Pero tenemos conocimiento de el y podemos crear código deacuerdo a sus especificaciones y todo estara bien.

 En el mundo tradicional de instalación de programas nosotros podemos controlar nuestro entorno poniendo ciertas restricciones en los SO para que nuestro código pueda correr ,ram , espacio en disco duro etc. Nosotros establecemos todo esos requerimientos para que los que usuarios puedan usar nuestros programas.

 En la web sin embargo todo esto es incierto. No tenemos control del entorno  en donde nuestro código javascript,html,css se ejecutaran. Nuestros usuarios controlan el aparato que usan, nuestros usuarios deciden que sistema operativo usar, cuanta ram  y espacio en disco quieren , la velocidad del procesador y el tipo de navegador que quieren usar. Y los proveedores de Internet se sientan en medio de nosotros y nuestros usuarios controlando la velocidad de la red , latencia y por ultimo que contenido permiten que el usuario descargue.

Lo unico que podemos hacer es tratar de hacer la experiencia adaptable a cualquier tipo de situación y cruzar los dedos para que todo salga bien. El problema fundamental de confiar en javascript  es que crea la ilusión de que estamos en control, seguramente si construimos una aplicación de uso personal o para algún familiar nosotros podemos decidir los requisitos para nuestra app SO/navegador/ram/etc  pero eso no es una realidad para el mundo web.

No podemos confiar ciegamente en la disponibilidad de una versión de SO ó versión de navegador cuando se trata de llevar nuestra app a internet, en lugar debemos construir experiencias que sean adaptables y tomar decisiones inteligentes  sobre las tecnologías especificas a usar en orden de tomar ventajas de sus beneficios mientras somos conscientes que no podemos garantizar la completa compatibilidad en este caso entra en juego algo llamado "progressive enhancement"

El concepto de "progressive enhancement" se ha convertido en unos de los temas de mas debate en la web de la actualidad, para ponerlo simple "progressive enhancement" es la técnica para construir sitios web con fuertes cimientos para que se a accesible a un amplio rango de situaciones (SO , navegadores, ram, ect)

Si tienes tiempo puedes leerte este post de como twitter uso esa técnica en el 2012 link.

He tomado una tabla de unas pruebas hechas por Jake Archibald en su blog donde ha hecho pruebas de parseo y ejecución de jquery 2.1.1 en diferentes dispositivos.

Parse and execution times of minimized jQuery 2.1.1

Device	Browser	Median Parse	Median Execution	Median Total
Blackberry 9650	Default, BB6	171ms	554ms	725ms
UMX U670C	Android 2.3.6 Browser	168ms	484ms	652ms
Galaxy S3	Chrome 32	39ms	297ms	336ms
Galaxy S3	UC 8.6	45ms	215ms	260ms
Galaxy S3	Dolphin 10	2ms	222ms	224ms
Kindle Touch	Kindle 3.0+	63ms	132ms	195ms
Geeksphone Peak	Firefox 25	51ms	109ms	160ms
Kindle Fire	Silk 3.17	16ms	139ms	155ms
Lumia 520	IE10	97ms	56ms	153ms
Nexus 4	Chrome 36	13ms	122ms	135ms
Galaxy S3	Android 4.1.1 Browser	3ms	125ms	128ms
Kindle Paperwhite	Kindle 3.0+	43ms	71ms	114ms
Lumia 920	IE10	70ms	37ms	107ms
Droid X	Android 2.3.4 Browser	6ms	96ms	102ms
Nexus 5	Chrome 37	11ms	81ms	92ms
iPod Touch	iOS 6	26ms	37ms	63ms
Nexus 5	Firefox 32	20ms	41ms	61ms
Asus X202E	IE10	31ms	14ms	45ms
iPad Mini	iOS6	16ms	30ms	46ms
Macbook Air (2014)	Chrome 37	5ms	29ms	34ms
Macbook Air (2014)	Opera 9.8	14ms	5ms	19ms
iPhone 5s	iOS 7	2ms	16ms	18ms
Macbook Air (2014)	Firefox 31	4ms	10ms	14ms
iPad (4th Gen)	iOS 7	1ms	13ms	14ms
iPhone 5s	Chrome 37	2ms	8ms	10ms
Macbook Air (2014)	Safari 7	1ms	4ms	5ms

Lo que  Jake Archibald dice :  "La horrible verdad sobre javascript cuando se trata de dispositivos que no son muy poderosos en hardware. Puedes pensar que esos modelos donde los tiempos son mas grandes son modelos viejos que nadie usa, lo cual es un error por que según las estadísticas las personas usan mas dispositivos antiguos que nuevos. También no importa que navegador usen lo mas importante es el poder de hardware del dispositivo.

Lo interesante de los tiempos de parseo y ejecución es que son para la ultima versión de jquery la cual pesa 88kb minificada, sin plugins adicionales sin frameworks. De acuerdo con los últimos reportes de HTTP archive, la media de transferencia de archivos JS son de 230kb". Las pruebas que el hizo son solo una fracción de ese tamaño. Jake Archibald dice que no pidio que jquery hiciera nada.

Por eso en algunas ocasiones debemos considerar reducir la dependencia de javascript en nuestros proyectos, no solo es saludable en tiempo de carga sino sera accesible para las personas que tienen javascript desabilitado en sus navegadores.

Como programador de javascript yo uso el framework angularJS y me parece impensable que algún usuario tengo desabilitado javascript en su navegador, pero aunque no queramos admitirlo existen y las app que usan frameworks javascript se vuelven cada vez mas pesadas. Las recomendaciones que siempre leo en internet son:

• Reducir lo maximo posible javascript
• Usar mas los render del lado del servidor
• modular tus archivos javascript y usar lazy loading
• Algunos recomiendan que la pagina principal que tiene datos para presentar sean cargador por el lado del servidor primero y después usar ajax para lo demas, algo asi como incluir un json con todos los datos necesarios iniciales en el html.

Como Nate Koechley’s dijo una vez:

"En un empleo anterior a yahoo, siempre me hacian la pregunta al inicio del cualquier projecto: ¿ Cuales navegadores debemos soportar en este projecto ? vamos a soportar netscape 4 ? IE 5? y siempre me fue preguntada en un sentido binario donde la respuesta siempre tenia que ser si o no. y con el tiempo nos dimos cuenta que el principal objetivo de nosotros era la maxima disponibilidad posible. Y esa fue la primera cosa que tuvimos que entender, el soporte no es binario. La segunda cosa que tuvimos que aprender es que soportado no significa realmente identico. En lugar de soportar un navegador, nosotros queremos dar al navegador lo que puede manejar de la manera mas eficiente posible."


Hace algún tiempo salio una web con el titulo “You Might Not Need jQuery”  el sitio en si ofrece ejemplos de código donde puedes hacer lo mismo que jquery pero con javascript nativo por nosotros mismo.

Lo interesante de esta web son el sinnúmero de comentarios que recibio con opiniones divididas sobre el tema. Lo cual hace preguntarse si una simple sugerencia sobre no usar una tecnologia determinada puede generar tanta discusion sobre el tema entonces debemos preguntarnos si estamos demasiado  dependientes de ella.

No estoy diciendo que no debamos usar frameworks y librerías, De hecho me gusta mucho jquery y los frameworks javascript pero lo que preocupa es que estas librerias se han convertido en librerías por defecto en cualquier proyecto y damos por hecho que esa dependencia es sana y la mayoría dela gente esta amarrada a esa tecnologia. Esto obviamente lleva a que tengamos librerías con un peso considerable en nuestros proyectos por considerarlas obligatorias.


http://aaron-gustafson.com/notebook/2014/a-fundamental-disconnect/
http://timkadlec.com/2014/09/js-parse-and-execution-time/
http://jakearchibald.com/2013/progressive-enhancement-is-faster/
http://timkadlec.com/2013/08/being-practical/
http://sixrevisions.com/web-development/progressive-enhancement/

Ayuda a plantar arboles desde tu pantalla, usa Ecosia

Cada uno de nosotros sabe el terrible problema que actualmente vivimos en  nuestro planeta con la destrucción de los bosques a nivel mundial.

Puedo decir sin temor a equivocarme que el  99% de las personas en el mundo quiere ayudar de alguna manera a resolver este problema, usando cualquier método disponible. Hoy es tu gran oportunidad de ayudar de una manera fácil y rápida a plantar arboles y sentirte bien contigo mismo al navegar por Internet.

Existe un buscador llamado Ecosia. que planta arboles en Brazil cada vez que tu utilizas este motor de búsqueda. El negocio de Google es la publicidad basada en nuestro hábitos de búsquedas de esta misma manera funciona  Ecosia con la gran diferencia de que Ecosia : 

• Dona el 80% de sus ingresos a la plantación de árboles ( el dinero viene de los anunciantes, como en otros servicios )
• Transparencia al publicar los comprobantes de las donaciones realizadas, en The Nature Conservancy.
• Excelentes resultados, con base en búsquedas de Yahoo! y Bing, con algoritmos mejorados por Ecosia.
• Búsquedas neutras, ya que Ecosia neutraliza todas las emisiones de dióxido de carbono derivadas por las búsquedas.

Entre más usuarios usemos Ecosia, mejores serán los beneficios en este caso, para nuestro planeta. Yo he estado usando Ecosia desde hace una semana y tengo que decirles que los resultados de busquedas son muy buenos, lo mejor de todo es que puedes cambiar de motor de busquedas dentro del propio Ecosia por ejemplo Google y asi tu búsqueda siempre generara dinero aunque uses Google,

Una cosa que me ha gustado mucho es que con el tiempo puedes ver cuantos arboles has ayudado a plantar en el tiempo que has estado usando Ecosia. Se que es un poco tonto pero se siente muy bien saber que con algo tan simple como tus busquedas en internet puedes ayudar al planeta.

Ecosia está disponible para Chrome, Firefox, Safari, Internet Explorer, Opera, Kindle, Android, iOS y Windows Phone, no tienes excusa para no usar este buscador muy util y ayudar a plantar arboles desde tu asiento.

link; https://www.ecosia.org/

CSS Shapes Editor para Chrome 37

En abril 2014 salio un borrador de las CSS Shapes , y con ellos nuevas puertas de diseño web fueron abiertas para nosotros los Front-end. Ya no estamos limitados a solo formas rectangulares para nuestros elementos.

Si quieres saber de los que hablo mira los ejemplos en el siguiente link, pero necesitas tener Google Chrome en su ultima version para poder ver bien los ejemplos ya que no es soportado por todos los navegadores. Ahora mismo la version 37 de Chrome lo soporta.

Existe una herramienta de abode para saber si tu navegador soporta las CSS Shapes en este link.

Lo super interesante de estos ejemplos es como el texto se acomoda automáticamente a la forma creada, lo que nos da un diseño estilo de revista impresa muy bonito para nuestros diseños.

Para darnos mas idea de lo que podemos crear adobe tiene un interesante articulo donde tiene muchos ejemplos de ellos aqui.

Si quieres saber como crear estas increíbles formas puedes leer este tutorial basico muy bueno.  Ahora crear este tipo de formas puede ser un trabajo muy tedioso, no seria interesante tener un editor visual para ello?

Pues si que lo hay, un tipo llamado Razvan Caliman  hay puesto a nuestra disposición un editor para Google Chrome muy bueno, puedes ver su funcionamiento en este vídeo:

Para instalar esta extension necesitas Chrome 37, Por ahora le queda mucho para que las CSS Shapes sean soportadas totalmente, pero  es bueno saber que tenemos este tipo de herramientas a nuestra disposición. Solo nos queda ir jugando y probando para crear unos interesantes diseños en nuestras webs.

Tambien un editor para clip-path: http://bennettfeely.com/clippy/

 link : http://razvancaliman.com/writing/css-shapes-editor-chrome/
link: http://alistapart.com/article/css-shapes-101
link: http://blogs.adobe.com/webplatform/category/features/css-shapes/

¿ Como encontrar el celular con mejor camara ?

Lo siguiente es un fragmento copy/paste de un articulo que vi en fayerwayer , pero recomiendo que leas el articulo completo en su pagina web.

El motivo del por que hago un copy/paste,  es por que considero que este tema de buscar un celular con buena cámara de fotos es algo todos nosotros siempre hacemos cuando queremos un nuevo celular y la información de este articulo es la respuesta a esa pregunta y creí que debía compartirla.

articulo:

¿Cómo conocer de forma neutral la calidad de imagen que toma un dispositivo? Para eso Flickr puede ser de gran ayuda.

Esto es gracias a una página del veterano banco de imágenes llamada Buscador de cámaras, la que abarca una enorme cantidad de fotografías tomadas por diversos dispositivos que son subidas a Flickr, y que te permiten conocer en la práctica la calidad de las imágenes tomadas por diversos tipos de lentes.

Al presionar sobre alguna de las cámaras o teléfonos podrás ver sus precios aproximados en EE. UU. así como sus especificaciones técnicas y sus calificaciones por parte de otros usuarios, así como gráficos de su popularidad en el sitio durante el último tiempo. Sin embargo, lo más relevante es que hay una exhaustiva cantidad de imágenes tomadas por diversas personas alrededor del mundo específicamente con ese aparato.

Link: http://www.fayerwayer.com/2014/08/utiliza-flickr-para-conocer-la-calidad-de-las-fotos-de-tu-proximo-celular-o-camara/

¿ Que es Material Design de Google ?

En el Google I/O 2014  Google revelo su próxima generación de guías de diseño "Material" ó  "Material Design".  ¿ Pero que carajos es esto ?

En palabras sencillas son guías de diseño de interfaces que se hicieron populares gracias a Microsoft y Apple pero con un toque de Google. Google a publicado un sitio web donde puedes encontrar estas guías de diseño para aplicar en tus proyectos web.

Estas guías incluyen desde como debería de lucir un botón , su reacción al ser apretado , hasta como una caja de texto debería de lucir y mostrar mensajes de error. Es una completa guía que te enseña como debería de lucir una interfaz usando "Material Design", como las superficies y sombras establecen una estructura física para dejar claro que puede ser tocado y movido.

En todos los productos Google sera o ya esta implementado el concepto de "Material Design". Lo que Google quiere intentar con esto es unificar todas la experiencia de usuario A través de sus varios productos y servicios, al mismo tiempo mejorar la experiencia que un usuario tiene con la tecnología , de manera mas intuitiva , fácil y simple.

Algunas de las cosas que podrás encontrar en esta guía son :

1. apariencia de botones
2. Animación en botones, inputs y modales.
3. Galería de imágenes
4. Lista de contactos.
5. Formularios.
6. Patrones de diseño.
7. Gestos comúnmente usados.
8. ect..

En el siguiente link puedes leer la reaccion de algunos diseñadores sobre esta guia:
http://venturebeat.com/2014/06/27/top-designers-react-to-googles-new-material-design-language/

Lograr todas esas animaciones y estilos que propone Google puede llevar un gran trabajo, por lo cual existen algunos frameworks CSS aunque muy verdes todavía que intentan ofrecer este estilo de diseño para los desarrolladores web.

• Tenemos por ejemplo Polymer es un proyecto experimental de Google que puedes probar.
• También existe leaf en un version beta.

Para terminar un vídeo sobre "Material Design"

Link:

http://www.google.com/design/spec/material-design/introduction.html
http://designmodo.com/material-design/
http://googledevelopers.blogspot.com/2014/06/this-is-material-design.html

Machotes y ejemplos de contratos de desarrollo Web y diseño grafico para usar en tus proyectos

Los contratos son un problema muy grande a hora de hacer un trabajo a una gran empresa o trabajar como freelancer, pero existen por una buena razón. Un buen contrato te asegura que tu y tu cliente tiene las mismas expectativas y te protegerá en caso de que las cosas vayan mal.

El contrato ideal debería de ser una combinación de estándares de la industria , protección legal y preferencias personales. Algunas preguntas muy comunes en antes de firmar un contrato serian:

¿ Cuanto sera el pago inicial para comenzar el proyecto ?
¿ Que pasa si el pago es retrasado ?
¿ Quien tiene todos los derechos sobre el trabajo realizado ?

Los contratos pueden ser muy complicados pero son algo que necesitamos. Por lo general nosotros los programadores web no sabemos nada de esto y tenemos que buscar un buen abogado para que nos asesore pero aveces el abogado no entiende de la industria del desarrollo web y ahi es cuando empezamos a tener problemas.

Hoy he encontrado un articulo muy interesante donde nos ponen a disposición ejemplos de contratos profesionales de la industria del desarrollo web y diseño gráfico usados en los Estados Unidos. La documentacion esta en ingles (si te dedicas a esto del desarrollo web , tienes que saber leer ingles) pero leyendo estos documentos tendrás una gran oportunidad de aprender de diseñadores y programadores experimentados de como ellos crean sus contratos.

Estos documentos están alojados en http://www.docracy.com/ que es un repositorio gratuito de documentos legales open source donde puedes contribuir con tus propios contratos.

Los mas importante es que no olvides que todo asunto legal es sensible y hay que tratar todos estos documentos como puntos de partidas para crear nuestros propios contratos. Con un buen abogado a tu lado  puedes revisar estos documentos y guiarte de como ajustar los tuyos para tu país, tus leyes  y proyectos locales.

Entre la lista del articulo original ya destaco estos :

1. Acuerdo para desarrollo de proyectos web
2. Acuerdo para servicios de diseño.
3. Contrato corto de diseño
4. Acuerdo como consultor.

El articulo original tiene 10 contratos destacados que puede revisar en el siguiente link:

link: http://www.smashingmagazine.com/2012/08/15/free-download-useful-legal-documents-for-designers-pdf/
link: https://www.docracy.com/

Consejos CSS para programación en dispositivos moviles

En el articulo anterior mostraba el infierno en el que se ha convertido android para los desarrolladores con sus múltiples versiones.

Ahora les traigo un vídeo de una charla impartido por Angelina Fabbro que ha dado en la JsConf 2014, donde nos brinda muchos consejos útiles que tienes que tomar en cuenta cuando desarrollas para dispositivos móviles.

Básicamente ella dice que cuando programas para android por ejemplo, tienes que tener como meta de compatibilidad con Android 2.3, por que no todas las personas instalan Google Chrome en sus móviles, siempre usan el navegador por defecto que trae Android. Adicional tienes que tener en cuenta todas las marcas de móviles que ni siquiera usan Andriod ó IOS. Por lo tanto Android 2.3 por ahora es tu punto de referencia, ya que aunque no lo quieras Android 2.3 tiene un porcentaje significativo en el mercado.

Y que android 2.3 es el nuevo IE 6.  En el vídeo también habla de propiedades CSS que son comúnmente usadas en escritorio con total confianza pero que en móviles producen desastres.  Por lo cual hay que evitarlas o buscar " css hacks" para repara los errores.

A continuación una lista de las cosas que recomienda usar con mucho cuidado cuando desarrollas para móviles tomando Android 2.3 como base.

• Position: fixed  No funciona correctamente.
• min-heigth,min-width, max-heigth,max-width  Tienen comportamientos extraños.
• overflow: auto  No usarlo
• z-index : No respeta el orden de los elementos.
• medidas ems y rems : ni siquiera pienses en usarlas
• Gradientes : Noooo!!
• @media queries : Comportamiento extraño.
• Selector * : No lo uses
• No escribas clases muy largas.
• border-radius baja el rendimiento
• box-shadow baja el rendimiento
• Transform especificamente rotate  baja el rendimiento

También tenemos el siguiente link donde podrás encontrar una lista de los errores que algunas personas han encontrado en móviles, es un buen punto de partida para ver los errores mas comunes.

https://github.com/scottjehl/Device-Bugs/issues

Si te dedicas a esto de la web tienes que ver este vídeo, aunque están en ingles puedes habilitar los subtitulos.

El infierno de Android Browser para nosotros los frontends

Si un amigo tuyo te dice :

" He probado mi aplicación en navegadores android y funciona perfecto ".

Lo que tienes que hacer es lanzar una risa malvada y mostrarle la siguiente presentación :




Personalmente por esta razón es que la gente le gusta desarrollar para iphone, este tipo de problemas  son poco frecuentes. Este tema de compatibilidad en android realmente se ha salido de control....

Si a esto sumas el nuevo mobile OS de firefox y el nuevo movil de amazon, esto deja de ser divertido.

Si quieres saber consejos muy buenos a tener en cuenta cuando desarrolles para android te aconsejo  leer el siguiente  articulo con muchos consejos sobre android y como afrontar estos problemas, este articulo se centro en putos muy importantes como por ejemplo:

• Software
• Hardware
• Pantallas 
• Drivers
• chipset
• etc

y en cada una de estos puntos hacen muy buenas recomendaciones sobre lo que necesitas saber para no tener problemas en el futuro. Como dije antes muy buen articulo

link: http://www.smashingmagazine.com/2014/10/02/what-every-app-developer-should-know-about-android/

Comparte tus Bookmark : http://unitedbookmark.com/

Consejos para hacer tu web app super rapida...deja de hacer perder el tiempo a tus usuarios.

No es secreto que las redes moviles dejan mucho que desear, comparadas con la conexión de nuestro hogar. Y nada frustra mas a los usuarios de móviles que tiempos de espera de carga muy largooos, lo cual resulta en que piense que tu web app es una porquería por que les hace perder el tiempo.

El co-fundador de Instagram Mike Krieger dice : " ¿Quien quiere esperar mientras esta esperando? ".

Y eso es por lo general lo que la mayoría de las web apps hacer cuando están esperando confirmación de sus acciones. El proceso por lo general es el siguiente:

1. El usuario hace algo en la aplicación.
2. La aplicación envia una petición al server diciendo que algo paso.
3. El server recibe la petición y realiza la acción correspondiente.
4. La aplicación espera la respuesta del server y después actualiza la pantalla con el resultado.

Todos este proceso es mucho tiempo esperando, aunque sea el proceso normal de cualquier aplicación, y en redes móviles puede parecer una eternidad. La popular aplicación móvil Instagram usa unos trucos muy interesantes para generar la impresión de que la aplicación es super rápida , los cuales nosotros podemos emplear en las nuestras y tener a nuestros usuarios contentos.

A continuación les dejo una presentación donde Mike Krieger muestra las técnicas "secretas" que usan en Instragram para lograr esto. Muy recomendado que lo vean.




link: https://speakerdeck.com/mikeyk/secrets-to-lightning-fast-mobile-design
Comparte tus Bookmark : http://unitedbookmark.com/

Wireframe, prototype, mockup ¿ Cual es la diferencia en diseño web ?

Las mayoria de las personas piensan que Wireframe, prototype y mockup  son la misma cosa,  con este post quiero mostrar las diferencias entre cada uno de ellos.

¿ Que es un wireframe ?

Es la mas simple representación de un diseño web, piensa en el como la estructura básica de la pagina web. Wireframe deberia de contener la representación de cada pieza importante del producto final.

Cuando decimos "representación" quiere decir que no tenemos que entrar en detalles exactos,  pero debemos crear una solida idea de lo que seria el producto final. Con esto estamos creando un mapa, una idea de como seria el diseño final web.

Crear un wireframe debería de ser una tarea rápida y la mayoría del tiempo debe de emplearse en generar ideas y discutir con el equipo de diseño. Un buen wireframe comunica la idea general a tu equipo de trabajo de que camino se esta tomando en el diseño.

Algunos ejemplos de wireframe :

Los wireframe son estáticos y sin ninguna interacción , por lo que deberían siempre de ser presentados en conjunto con documentacion adicional sobre su propósito. Existen muchas herramientas gratuitas para crear wireframes , una de ellas es : https://wireframe.cc/

¿ Que es un prototype ?

Prototype a veces es confundido con un wireframe, pero un prototype es una representación media del diseño que simula la interacción del usuario con la interfaz y el contenido del producto final. Principalmente permite testear como el usuario interactua con la interfaz de una manera similar al producto final, por lo que Prototype tiene que tener interacciones y enlaces que funcionen, pero su contenido sigue siendo estático. Un prototype es una simulacion final de la interaccion entre el usuario y la interfaz de calidad media  del producto final.

Puede no lucir exactamente igual al producto final pero lo suficientemente similar para demostrar la interacción del usuario. Esto nos demuestra que prototype se usa principalmente para pruebas completas de interfaz, antes de que la programación final del producto comience.

Hay que tener cuidado en usar un prototype por que para crear las interacciones de la interfaz habria que  trabajar con el html , css  y Javascript para crearlas. Aunque existen herramientas de pago que permiten crearlas por ti, como por ejemplo : http://proto.io/.  En el siguiente vídeo pueden ver como agregan interacción a un prototype de una App móvil.



Resumen : "Prototipo: Representación navegable del producto final web. De calidad media"

¿ Ques un mockup  ?

Mock-up: Representación estática de un producto web en calidad alta.

Con el podemos vender  la idea final de nuestro producto e  instar a nuestros clientes a darnos feedback sobre el diseño, es lo mas cercano al diseño final que podemos mostrar a nuestros clientes. La diferencia con  protoype es que un mockup no necesariamente tiene que tener html programado, pueden ser imágenes del diseño final, mientras que prototype si.Y un mockup generalemente no tiene interactividad

Para terminar les dejo un vídeo de mejorando.la donde explican la diferencia de cada uno.




Para terminar he encontrado una App muy util para hacer rapidos prototipos con solo dibujos en papel, visita el siguiente link : https://popapp.in/

Y si quieres un poco de inspiración para hacer tus prototipos puede visitar esta comunidad: https://spaces.proto.io/

Algunos libros gratuitos sobre diseño de prototype y mockup:

• http://www.uxpin.com/guide-to-prototyping-2.html
• http://www.uxpin.com/guide-to-mockups-2.html

link : http://designmodo.com/wireframing-prototyping-mockuping/

Como crear anuncios en facebook

Si tienes un negocio y quieres anunciarte en facebook vas a necesitar una guía clara. En mejorando.la,  Freddy a Vega a creado un vídeo  que a mi parecer es el mejor que hay de como crear anuncios en facebook.

Con pasos guiados en vídeo, recomendaciones y comentarios de Freddy creo que podras lograr crear un anuncio muy efectivo.

Comparte tus bookmarks: http://unitedbookmark.com/

Los desafios de diseñar y programar para moviles por www.conectatutoriales.com

Hoy en http://firt.conectatutoriales.com/ hubo un stream sobre informacion general sobre  programacion en moviles, Si eres profesional o estás interesado en diseño o programación web, los móviles son un paso necesario para todos. En el siguiente video veras todo lo que necesitas saber incluyendo webs responsivas, rendimiento, emuladores y frameworks más usados.

Recomiendo verlo para saber como funciona este mundo de la programacion en moviles, no son conceptos dificil de entender, es mas un resumen muy bien hecho de todo lo que necesitas saber, muchas gracias a http://firt.conectatutoriales.com/ por este excelente material.




link : http://firt.conectatutoriales.com/

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/

---