"Más pixeles, más problemas" Traducción del artículo de A List Apart: 25.9.12

"Más pixeles, más problemas" Traducción del artículo de A List Apart:

Más pixeles, más problemas

Mo’ Pixels Mo’ Problems

Los dispositivos móviles están a la venta con más y más alto PPI, y los equipos de sobremesa y ordenadores portátiles están siguiendo esta tendencia. No hay forma de evitarlo: la alta densidad de píxeles, o "Retina", se ha convertido en tendencia dominante y, como era de esperar, nuestros sitios web se están comenzando a ver un poco borrosos en su gloria a interfaz. Pero antes de lanzarnos visceralmente a modificar todos nuestros sitios, primero debemos identificar los problemas y encontrar la manera más responsable de hacerlo teniendo en mente a nuestros usuarios como prioridad.

El gran problema: las imágenes gigantescas

En un esfuerzo por mantenerse en la cresta de la ola, muchos de nosotros hemos comenzado el proceso de hacer de nuestros diseños sitios web "@2x", esperando silenciosamente que el "@3x" nunca se convierte en realidad. Mientras que una imagen @2x parecería que sólo sería dos veces el número de kilobytes, es en realidad alrededor de tres a cuatro veces más grande. Como se puede ver en mi demostración @1x vs @2x, el resultado final es que las fotos o composiciones muy detalladas su peso comienza a ser fácilmente del orden de megabytes.

"¿Por qué es esto un problema?" Oigo preguntar. "¿No debería ser la web algo hermoso?" Definitivamente. Cómo hacer de la web un lugar mejor es, probablemente por lo que todos estamos en este negocio. El problema radica en nuestra responsabilidad del ancho de banda.

En las partes más ricas del mundo, tratamos el acceso a la alta velocidad de banda ancha como un derecho civil, pero para mucha gente en este planeta, la baja velocidad o el de pago por gigabyte son cosas reales. El "porque se ve bonito" no es una razón suficiente para enviar una imagen de 1 MB a través de 3G, o, Dios no lo quiera, algo así como por la red EDGE.

Incluso en nuestros paraísos de gran ancho de banda, usted no tiene que ir muy lejos para ver ejemplos de ancho de banda limitado. Un visitante de su sitio web que esté utilizando una tablet o teléfono de alta PPI desde la comodidad de su sofá o desde el medio del desierto de Arizona. Del mismo modo, los flamantes MacBook Pro Retina podrían estar conectados a Internet a través de Google Fiber, o la conexión a un punto de acceso 3G en un aeropuerto. Debemos tener cuidado con nuestras suposiciones sobre píxeles y ancho de banda.

Rutas erradas: JavaScript

"Voy a utilizar JavaScript."
_{- Todo el mundo alguna vez.}

JavaScript ha resuelto muchos de nuestros males pasados, por lo que está en la naturaleza humana encomendarnos a él para salvarnos otra vez. Sin embargo, la mayoría de las soluciones no dan la talla y terminan penalizando a los usuarios con lo que comúnmente se conoce como el "download doble".

Marquis Mat lo explicó, pero vale la pena reiterar que, en la búsqueda de la velocidad y hacer más rápida la navegación, los navegadores comienzan la obtención previa de todas las imágenes de un documento antes de que JavaScript tenga acceso y puede realizar cualquier cambio.

Debido a esto, las soluciones donde se detectan las capacidades de alta resolución y se incluyen nuevas fuentes de imagen, realmente hacen que el navegador baje dos imágenes, obligando a los usuarios de alta resolución a esperar a que ambos conjuntos de imágenes se descarguen. Esta descarga doble podría parecer que no penaliza mucho con una sola imagen, pero imagina una galería de fotos con 100 imágenes por página. Ouch.

Hay otros intentos, tales como la detección del ancho de banda, usar cookies, detección del lado del servidor, o una mezcla de los tres. Por mucho que quisiese robots para resolver mis problemas, estas soluciones son de entrada un gran impedimento para el desarrollador web promedio. El quiz de la cuestión con todas ellas es que introducen dependencias del servidor/cookie, que históricamente han sido problemáticas.

Necesitamos una solución de las imágenes de alta resolución puramente front-end.

¿Suena familiar? Es porque las imágenes de alta resolución y "responsive images" nos devuelven a la raíz del problema: ¿Cómo podemos servir diferentes imágenes a diferentes dispositivos en contextos distintos utilizando la misma etiqueta HTML?

La solución: la vieja y buena moda de la mejora progresiva

Aquellos de nosotros involucrados en CSS y los grupos de Estándares Web estamos familiarizados con el concepto de mejora progresiva. Es importante mantenernos firmes en este colectivo. Los píxeles, ya sean entendidos como reales o la densidad del dispositivo, deben ser entendidos como una mejora o característica que algunos navegadores tienen y otros no. Hacer una base mínima fuerte y después optimizar según sea necesario. De hecho, el aprendizaje de cómo construir correctamente un sitio web mejorado progresivamente puede ahorrarte (y a tus clientes) un montón de tiempo en el time-line.

Estas son las reglas que mis colegas en Paravel y yo hemos seguido al lidiar con las imágenes de alta densidad:

1. Usar CSS y el tipografía web siempre que sea posible.
2. Usar SVG y tipografía de iconos cuando sea aplicable.
3. Gráficos de trama en el elemento <picture>

CSS Y TIPOGRAFÍAS WEB

CSS3 nos permite replicar más ricos efectos visuales en el explorador con muy poco esfuerzo, y la explosión de tipografías web de alta calidad nos permite construir sitios en base a una gran tipografía en lugar de collages de imágenes. Con nuestras capacidades actuales de CSS, las buenas razones para confiar en composiciones de imágenes enormes para el impacto visual son cada menos y con menos base.

Así que la vieja regla sigue siendo válida: Si puedes lograr el diseño con HTML + CSS, hazlo. Si no puedes realizar tu diseño con CSS, entonces quizás la primera pregunta que debemos hacernos es, ¿por qué tu no? Después de todo, si nos consideramos dentro del negocio, es imperativo y prioritario que nuestros diseños funcionen en la web y de la manera más eficiente posible.

Vuelve atrás y abraza las materias primas de la web: HTML y CSS.

(N.E.: amplía este apartado: @Font-face ⇩)

SVG Y LAS TIPOGRAFÍAS DE ICONOS

Las imágenes SVG están basadas en trazados vectoriales XML, originalmente diseñadas como un competidor de Flash Player. Son como archivos de Illustrator en el navegador. No sólo son independientes de la resolución, sino que tienden a crear archivos extremadamente ligeros (aproximadamente determinados por el número de puntos en el vector).

Las tipografías de Icono (como Pictos or SymbolSet) son esencialmente colecciones de gráficos vectoriales agrupados en una fuente dingbat personalizada, accesible a través de caracteres Unicode en una archivo incorporado con la regla @font-face. Anecdóticamente, nosotros en Paravel nos hemos dado cuenta de que pequeños gráficos raster, como botones e iconos, tienden a mostrarse más deficientenmente en pantallas de mayor resolución. Fuentes de iconos son una gran alternativa a los frustrantes hojas de sprites, y ya hemos empezado a utilizar tipografías de iconos como sustitutos siempre que es posible.

El soporte a @font-face es grande, y la incorporación SVG está a punto de ser general, a excepción de viejos culpables: las versiones antiguas de IE y Android. A pesar de esto, es fácil comenzar a usar SVG hoy, y si es necesario hacer concesiones para exploradores más antiguos a medida que avanzamos, con detección de características para proporcionar un polyfill de reserva, o incluso en proyectos novedosos que automatizan SVG / PNG en hojas de sprites.

Hay casos en que estos formatos se quedan cortos. Las fuentes de iconos, por ejemplo, sólo pueden ser de un único color. IVS son infinitamente escalable, pero una escala más grande no significa más fidelidad o detalle. Aquí es cuando se necesita echar mano del armamento pesado.

(N.E.: amplía este apartado: Tipografías de Iconos ⇩)

PICTUREFILL GRÁFICOS DE TRAMA

No es ajeno a este artículo, el elemento <picture>, planteado por el W3C Responsive Images Community Group, es una solución elegante para cargar grandes gráficos raster. Con <picture>, que puede especificar qué imagen de origen se desea cargar en el navegador para usar según aumente la cantidad de píxeles disponible.

El elemento <picture> no está libre de melodramas, y también tiene un contendiente digno. El atributo de imagen @srcset, en particular planteada por Apple, se basa en la propuesta de la propiedad CSS imagen-set (), diseñado para servir en alta resolución los activos como imágenes de fondo. He aquí una muestra de la sintaxis propuesta (presentada con mi comentario personal):

Como solución completa de imágenes "responsive", @srcset tiene una micro sintaxis molesta y no es función del dispositivo final (por ejemplo, está basada ​​en unidades de anchura y altura de píxele y no admite unidades em). Pero tiene algunas cualidades atenuantes: En teoría, el atributo @srcset podría dejar la determinación del ancho de banda en las manos del navegador. El navegador, a través de la configuración de usuario y/o datos agregados sobre la velocidad en todas las solicitudes, podría tomar la mejor decisión informada sobre qué resolución pedir.

Sin embargo, como la especificación se está desarrollando, @srcset es simplemente un conjunto de sugerencias para que el navegador puede elegir o ignorar por completo, a su discreción. Cediendo el control total al navegador web este autor web se siente un poco mermado, y estoy seguro de que muchos de ustedes sienten lo mismo.

¿No sería agradable si hubiese un término medio?

Al darse cuenta de los puntos fuertes del elemento <picture>, el Grupo de Imágenes Responsive del W3c ha presentado una propuesta denominada el "Compromiso Florian", que mezcla los poderes de ambos: el atributo @srcset y el elemento <picture>.

Sin duda, la sintaxis <picture> es más detallada, pero es muy fácil de leer y no utiliza el confuso "100w" de la sintaxis abreviada. Esperar que las cosas cambien en el futuro, pero mientras tanto, estamos utilizando actualmente la solución basada en div´s Picturefill del Filament Group, lo que nos encontramos es fácil de usar y no requiere configuración del servidor o de los archivos .htaccess. Simplemente use el elemento <picture> como si existiera hoy.

Bajo el capó, en nuestra demostración anterior se utilizan dos instancias de la Picture original para cambiar el origen cuando el navegador cambia de tamaño. He hecho algunas modificaciones rápidas a nuestra demo, esta vez combinando los códigos @1x y @2x en una demostración con la nueva sintaxis del Picturefill.

Técnica Experimental: el hack 1.5x

Otra de las cosas que hemos estado haciendo en Paravel es jugar con los promedios. Su conteo puede variar, pero nos hemos dado cuenta que las pantallas de alta resolución suelen hacer un gran trabajo para conseguir el máximo rendimiento de los píxeles disponibles, como se puede ver en esta versión experimental de nuestro @1.5x

Si no tienes una pantalla de alta resolución, puedes aumentar el zoom del navegador al 200% para simular cómo se vería en los aparatos con la comprensión en 1. La imagen @1x tiene claramente peor fidelidad en las pantallas de alta resolución, y la imagen @2x definitivamente tiene la más alta calidad. La versión @1,5x, sin embargo, luce casi tan bien como la versión @2x, y tiene un ahorro en la carga de alrededor del 20%. ¿Qué notarán mas sus usuarios: la diferencia en la calidad o la diferencia en la velocidad de la página?

En última instancia, la utilidad de la técnica @1,5x depende de la situación. En particular, el @1x penaliza al usuario, pero tal vez haya un punto medio mejor para usted en @1,2x o @1,3x. En este momento vemos el método "sólo un poquito más grande" como una solución viable para conseguir un poco más de importancia a las imágenes sin necesidad de añadir degradación o complejidad a nuestros clientes. Si estás en una situación donde no puedes hacer cambios drásticos, esto puede ser una gran manera de ganar un poco de calidad sin (relativamente) sobrecargas abrumadoras.

Por encima de todo: usar el cerebro

Recientemente, durantre el rediseño de la página web propia de Paravel, hemos aprendido a desafiar nuestras propias reglas. Ya que tenemos el talento del ilustrador Reagan Ray en nuestro equipo, nuestro nuevo sitio hace uso intensivo de SVG. Pero cuando exportamos nuestro querido gráfico "Three Amigos", realizamos una auditoría rápida y vimos que la versión SVG pesaba 410kb. Demasiado pesado, así que exportamos una versión bien grande de 2000x691 en PNG. Pesó sólo 84kb. Nosotros no somos científicos de cohetes UX, pero asumimos que nuestros visitantes prefieren las imágenes que se descargan cinco veces más rápido, así que será una imagen PNG.

Sólo tienes que utilizar su cerebro. No estoy seguro de que en nuestra industria se diga lo suficiente. Eres inteligente, tu haces la internet, puedes tomar buenas decisiones. Presta atención a tu hacer, sopesa los pros frente a los contras, y cuestiona tus creencias sobre la marcha.

Se flexible, también. En nuestra industria no hay balas de plata; posiciones absolutas, métodos y flujos de trabajo tienden a quedarse anticuados de semana a semana. Como nos encontramos con nuestra propia página web, aferrándose firmemente a nuestras propias reglas inventadas no es siempre lo mejor para nuestros usuarios.

Se flexible, también. En nuestra industria no hay balas de plata; las posiciones inamovibles, los métodos y flujos de trabajo tienden a quedarse anticuados de semana a semana. Al enfrentarnos con nuestro sitio web, aferrarse firmemente a nuestras propias reglas inventadas no es siempre lo mejor para nuestros usuarios.

Hacer lo correcto por los usuarios es el quid del desarrollador front-end y, en definitiva, también en todo lo demás en la web. La densidad del pixel puede cambiar, pero como dice el refrán, lo que es bueno para el usuario lo es para el negocio.

Sobre la autoría de este artículo

Artículo original de Dave Rupert (aka @davatron5000) publicado en A List Apart el 25 de Septiembre de 2012. Hoy mismo. Sobre el uso de las imágenes en dispositivos de alta densidad.
Translated with the permission of A List Apart and the author[s]” según sus Permissions & Copyright

Por Dave Rupert
Dave Rupert es el desarrollador principal de Paravel, una agencia "Tres-Hombres" de diseño web y branding de Austin, Texas. Él, junto con Chris Coyier de CSS Tricks, es co-anfitrión del podcast semanal Shop Talk Show.

Complementos al artículo original

1. @font-face: generación y uso
2. Font-face y sus problemas: guía de uso y solución de problemas
3. Iconos o Pictogramas. Reemplazo de imágenes por texto

Disclaimer

Termino con mis disculpas por los fallos o errores tanto en la traducción como interpretación de los conceptos expuestos. Si encuentras algún pasaje mejorable, déjame tu propuesta en los comentarios. Gracias.

Translated with the permission of A List Apart and the author[s]” según sus Permissions & Copyright