Empezando con RESS

• Conocimientos necesarios: Básico PHP, básico diseño web adaptable
• Requiere: PHP, Twitter Bootstrap, Modernizr, Swipe.js, WURFL
• Tiempo del proyecto: 2-4 horas

Sé que nuestra industria no necesita otro acrónimo, pero aquí tienes uno más: RESS. RESS significa "Diseño Responsivo + Componentes del Lado del Servidor" y es Luke Wroblewski el culpable de hacerte aprender otro término más. No inventó nada nuevo cuando escribió. un artículo habló de ello en septiembre, pero le puso un nombre a algo que muchos solían llamar solución "híbrida" antes.

La idea detrás de esto es que combinamos técnicas de diseño web responsivo y técnicas del lado del servidor para brindar una experiencia óptima para cada dispositivo. Esto significa que enviaremos solicitudes ligeramente diferentes a algunos dispositivos para una URL determinada, pero seguiremos usando técnicas de respuesta para lo que sea que termine en esos dispositivos. La técnica presentada en este tutorial es una solución RESS simple diseñada para ayudarlo a comenzar en poco tiempo. Vamos a crear una única página responsiva que incluye algunos elementos básicos que son sorprendentemente complejos de usar en sitios responsivos: imágenes, anuncios y widgets de redes sociales.

01. Diseño web adaptable

El diseño web responsivo no necesita presentación, pero probablemente hayas notado que la mayoría de las técnicas responsivas solo utilizan código del lado del cliente. Y por una buena razón. El código se basa en estándares web y si un nuevo dispositivo o navegador se relaciona con estos estándares, nuestro sitio web seguirá funcionando según lo previsto. Y esto también significa que tenemos una base de código para todos los dispositivos. Y esta parte es fantástica y un poco aterradora al mismo tiempo.

Funciona muy bien en muchos casos, pero también vemos algunos casos en los que los navegadores menos capaces (a menudo móviles) adolecen de demasiada lógica y contenido, mala usabilidad y una experiencia general lenta.

02. Cliente, conoce al servidor

Aquí es donde el servidor puede ayudar. La forma tradicional de crear soluciones para dispositivos móviles o para una plataforma específica es crear un sitio móvil independiente o una aplicación. Ambos métodos se adaptan al dispositivo específico y es también la razón por la que funcionan tan bien para dispositivos móviles (al menos desde la perspectiva de los usuarios finales). Ambas soluciones también tienen desventajas, como seguramente sabrás, pero tienen algunas cosas que muchos sitios web responsivos no tienen: optimización para el dispositivo y velocidad.

No es raro que un sitio web responsivo tenga 2, 3 e incluso 4 megas y tengo cientos de solicitudes HTTP, y puedo decirles ahora mismo que eso es demasiado. La idea principal sobre el diseño web responsivo es no adaptarse a un dispositivo específico, pero en algunos casos, tiene sentido realizar cierta optimización en el servidor.

03. La puesta en marcha

Crearemos una página PHP simple (que se parece mucho a la portada de una revista...). El sitio tendrá un carrusel de imágenes, algo de publicidad y algunos complementos de redes sociales. Nos centraremos en hacer que el sitio sea fácil de configurar y utilizaremos Twitter Bootstrap como marco responsivo. Usaremos detección de funciones y dispositivos. También usaremos Modernizer para ayudar con la detección de funciones y WURFL para la detección de dispositivos. Detectaremos el tamaño de la pantalla del dispositivo tanto en el lado del servidor como en el del cliente y lo usaremos para tomar decisiones sobre qué imágenes, anuncios y contenido mostraremos al usuario.

04. Detección de funciones y detección de dispositivos

Con esta configuración tenemos dos fuentes de información sobre el navegador. Modernizr es un marco de detección de funciones que facilita la detección de funciones del navegador. Simplemente ejecuta una prueba en el navegador para obtener una respuesta booleana como resultado: "¿Funciona X?" y la respuesta es mayoritariamente "verdadero" o "falso". Lo bueno de esto es que funciona en todos los navegadores, también en aquellos que aún no están lanzados. Pero no tiene mucha granularidad y las capacidades disponibles se limitan a lo que es posible probar. Ejemplos de funciones que se pueden probar incluyen boxshadow, csstransitions, touch, rgba, geolocalizaciones, etc.

La detección de dispositivos, por otro lado, es algo diferente. Todo sucede en el servidor y es un marco que analiza el encabezado HTTP del dispositivo. Luego busca en una base de datos de dispositivos conocidos y devuelve un conjunto de capacidades para ese dispositivo. Lo bueno de esto es que es una base de datos de información recopilada y mantenida por humanos y Puede contener información increíblemente detallada sobre capacidades que actualmente es imposible presentar. prueba. Los ejemplos incluyen el tipo de dispositivo (computadora de escritorio, TV, móvil, tableta), nombre comercial del dispositivo, compatibilidad con códec de video, etc.

La desventaja es que el análisis del agente de usuario puede salir mal algunas veces y muchos dispositivos tienden a tener un análisis no cadena UA única o falsificar la cadena UA, pero el uso de un marco minimizará el riesgo de errores falsos. detección. La detección de dispositivos y la detección de funciones no se pueden comparar entre sí, ya que están no dos caras de la misma moneda.

05. El sitio de demostración

¡Empecemos a codificar! Le mostraré cómo puede utilizar RESS para resolver tres problemas comunes: anuncios, imágenes y complementos de redes sociales. El sitio de demostración que crearemos está en andmag.se/ress/ y todo el código está disponible en un repositorio de Github.

Comenzaremos descargando y configurando las herramientas que vamos a utilizar. No nos centraremos demasiado en el código responsivo en este tutorial y usaremos Twitter Bootstrap para ayudarnos.

Necesitas descargar los archivos Bootstrap y descomprima el paquete. Bootstrap contiene una carpeta JS, CSS e IMG y la colocaremos en una carpeta "bootstrap" en nuestro proyecto vacío.

A continuación, debemos poner en marcha la detección del dispositivo. Usaremos el Oferta de nube ScientiaMobile WURFL para esto. WURFL significa Archivo de recursos universal inalámbrico y WURFL es uno de los sistemas de detección de dispositivos más utilizados que existen. Debe registrarse en ScientiaMobile para obtener una clave API y luego podrá descargar el cliente en la nube. Existen diferentes versiones según el tráfico del sitio y la cantidad de capacidades que desee. Estoy usando la versión estándar, pero también hay una versión gratuita que puedes usar. Después de registrarse, vaya a la configuración de su cuenta, descargue el código del cliente PHP y colóquelo en una carpeta llamada "WURFL".

Cuando termine, estaremos listos para comenzar a agregar código. Nos centraremos en mantener las cosas simples y crearemos una estructura de archivos simple. También crearemos nuestras propias carpetas de imágenes, CSS y JavaScript. En este ejemplo solo crearemos una página de inicio y todo el código entrará. index.php. Usaremos el método "incluir" de PHP para incluir otros archivos y evitar tener todo el código en el mismo archivo. index.php incluye encabezado.php y pie de página.php junto con los fragmentos de la página. encabezado.php también contiene WURFL.php y RESS.php. Pronto veremos qué harán estos archivos.

06. WURFL.php

WURFL.php incluye el código para inicializar el cliente WURFL y almacenará las capacidades a las que tiene acceso en una matriz PHP.

// Incluir el cliente de nube WURFL
require_once 'WURFL/Client/Client.php';

// Crear un objeto de configuración< br/> $config = nuevo WurflCloud_Client_Config();

// Configure su clave API de WURFL Cloud - Cambie esto a su propia clave
$config->api_key = '12345:abcDEFabcDEFabcDEFabcDEF';

// Crear el cliente de nube WURFL
$client = new WurflCloud_Client_Client($config);

< p>// Detectar su dispositivo
$cliente->detectDevice();
?>

Una vez que se inicializa el cliente, podemos comenzar a obtener información sobre el dispositivo que actualmente está usando el sitio en cualquier parte del código:

$cliente->getDeviceCapability('nombre_marca');
?>

07. RESS

Ahora vamos a crear una forma de combinar la detección de clientes y servidores. Usaremos una cookie para compartir información del cliente al servidor. La capacidad más importante para esta prueba es el ancho de la pantalla, por lo que creamos una RESS.php archivo con algo de JavaScript que detecta el tamaño de la pantalla por nosotros. También creamos un espacio de nombres RESS y un escribir cookie() método auxiliar. Luego podemos obtener el ancho y escribir la cookie al cliente:

RESS = {};

RESS.writeCookie = función (nombre, valor) { //código de cookie }

//Almacenar ancho en una cookie
RESS.storeSizes = function () {
//Obtener ancho de pantalla
var width = window.innerWidth;

// Establece una cookie con las capacidades del lado del cliente.
RESS.writeCookie("RESS", "width." + width);< br/> }

RESS.storeSizes();

También registramos un evento onresize, de modo que podamos escribir la cookie cuando la ventana haya cambiado de tamaño o el dispositivo haya cambiado de orientación, no solo al cargar una nueva página. El evento onresize tiende a ser muy fácil de activar, por lo que esperamos un segundo antes de escribir el nuevo valor.

RESS.isResizeActive = falso;

window.onresize = función (evento) {
si (!RESS.isResizeActive) {
RESS.isResizeActive = verdadero;

//asegúrate de no hacer esto con demasiada frecuencia, espera 1 segundo...
ventana.setTimeout (función () {
RESS.storeSizes();
RESS.isResizeActive = falso;
}, 1000);
}
}

A continuación, necesitamos algo de código PHP para leer la cookie, de modo que podamos hacer que el ancho de la pantalla también esté disponible en el lado del cliente.

$RESSCookie = $_COOKIE['RESS'];
si ($RESSCookie) {
$RESSValues ​​= explotar('|', $RESSCookie);
$featureCapabilities;
foreach ($RESSValues ​​como $RESSValue) {
$capacidad = explotar('.', $RESSValue);
$featureCapabilities[$capacidad[0]] = $capacidad[1];
}
}

También obtendremos el ancho del lado del servidor como alternativa. Esto es importante ya que se utilizará cuando no tengamos acceso a la cookie en la primera carga de la página o si las cookies o JavaScript están deshabilitados.

$WURFLWidth = $cliente->getDeviceCapability('max_image_width');
si ($cliente->getDeviceCapability('ux_full_desktop')) {
$WURFLAncho = 1440;
}

El ancho de pantalla predeterminado de WURFL para "escritorio" es 600, por lo que nos aseguramos de establecer un tamaño grande por defecto y dejar que el código responsivo maneje el tamaño de la pantalla si es más pequeño. Y en base a esto ahora podemos obtener el ancho de pantalla del lado del servidor y con un respaldo al ancho WURFL:

$defaultWidth = ($featureCapabilities["ancho"]? $featureCapabilities["ancho"]: $WURFLWidth);

08. Imágenes

¿Ya estás cansado de escuchar "imágenes responsivas"? Pensado así. La discusión sobre cómo manejar imágenes para diferentes resoluciones de pantalla se lleva a cabo desde hace algún tiempo. Mat Marquis lo resume todo muy bien en su artículo. El estado de las imágenes responsivas..

Usaremos nuestro ancho de pantalla RESS para mostrar diferentes imágenes en diferentes tamaños de pantalla. Estamos usando imágenes de Flickr para nuestro carrusel y elegimos tres de sus tamaños predeterminados: 320, 500, 640 y creamos un nuevo tamaño: 770, que es el máximo de nuestro carrusel. Hay algunas diferencias en el ancho del carrusel en diferentes puntos de interrupción y tratamos de considerar eso en el algoritmo. También tenga en cuenta que vamos a mostrar una imagen que es un poco más grande de lo que vamos a usar. Esto se debe a que queremos que la imagen también funcione bien en modo horizontal. Si tenemos un ancho de pantalla de 320 píxeles, la altura o el ancho vertical es 480, por lo que la imagen de 500 es la mejor opción para dicho dispositivo (según los formatos de Flickr). Aquí hay espacio para la optimización y puedes cambiar el código y publicar imágenes más pequeñas si así lo deseas. Aquí está el código:

//selecciona la versión correcta de la imagen
si ($ancho predeterminado < 320) {
//las pantallas pequeñas obtienen 320 imágenes
$imageVersion = "320";
} más si ($defaultWidth < 500) {
//320-499 pantallas obtienen 500
$imageVersion = "500";
} si no ($defaultWidth <= 1024) {
//las pantallas entre 500 y 1024 obtienen 640
$imageVersion = "640";
} demás {
//cualquier cosa >= 1024 obtiene 770
$imageVersion = "770";
}

Ahora expondremos nuestros cálculos en una variable RESS global:

$RESS globales;
$RESS = matriz(
"ancho" => $ancho predeterminado,
"imageVersion" => $imageVersion);

Y ahora podemos obtener fácilmente los valores del lado del servidor y usarlos en nuestro código.

09. El carrusel

Ok, ya tenemos todo configurado y estamos listos para comenzar a usarlo. Para poner un carrusel en el sitio usaremos deslizar.js y también necesitamos Modernizar para saber si debemos habilitar las transiciones CSS o no. Además, intentaremos elegir la versión de imagen correcta para el dispositivo. Usamos la versión de cuatro imágenes que decidimos y las almacenamos en nuestra carpeta img:

img1_320.jpg
img1_500.jpg
img1_640.jpg
img1_770.jpg

En base a esto, ahora podemos usar nuestra variable RESS para elegir la versión correcta:

.jpg" alt="Primera imagen">

Después de aplicar algunos estilos, ahora tenemos un carrusel funcional con tamaño de imagen variable. También puedes tener un recorte diferente de la imagen para diferentes tamaños de pantalla si lo deseas. Ver código completo del carrusel aquí.

10. Anuncios

Uno de los problemas de las redes publicitarias es que la mayoría sólo ofrece anuncios de tamaño fijo. Vamos a incluir esos anuncios de tamaño fijo en nuestro sitio responsivo, pero usamos RESS para incluir diferentes tamaños dependiendo del tamaño de pantalla con el que estemos tratando. vamos a usar Publicidad de Google y colocaremos un anuncio en el encabezado de la página al lado del logo. Usamos la misma técnica que cuando publicamos diferentes versiones de imágenes. Tendremos un anuncio de 320px encima del logo en pantallas pequeñas, un anuncio más grande de 468px en el lado derecho del logo en pantallas medianas y finalmente un anuncio grande de 728px en el lado derecho del logo para pantallas grandes. Aquí está el código:

if ($RESS["ancho"] >= 320 && $RESS["ancho"] <= 640) {
?>

} ?>

Tenga en cuenta que tenemos una consulta de medios que ocultará el anuncio si el anuncio cae por debajo del ancho especificado. El anuncio es visible de forma predeterminada y lo ocultamos para tamaños de pantalla inferiores a 980 píxeles, es decir, un máximo de 979 píxeles. El anuncio se oculta si el ancho del dispositivo disminuye sin recargar, pero si recarga la página obtendrá un tamaño de anuncio diferente.

@pantalla multimedia y (ancho máximo: 979 px) {
.max-980 {
mostrar: ninguno !importante;
}
}

Ocultar contenido sin mostrar nada normalmente es un gran "no-no", pero recuerda que solo se oculta si el tamaño de la pantalla cambia. dramáticamente y, de todos modos, solo los desarrolladores de diseño web responsivos cambian la ventana de su navegador en cada sitio web que ven. ...

11. Inclusión de contenido condicional

Como ya empezarás a comprender, podemos escribir fácilmente código condicional en el servidor y podemos hacer muchas cosas sucias... Una cosa es eliminar contenido para pantallas más pequeñas. Algunos tipos de contenido simplemente no valen la pena en dispositivos móviles, como los widgets de redes sociales en este caso. Podemos debatir sobre eliminarlos todos juntos de nuestro sitio (probablemente deberíamos hacerlo). Aquí está el código para la columna derecha de nuestra página:

= 768) { ?>

Por lo tanto, solo incluimos estos fragmentos si la pantalla tiene 768 píxeles o más. Tener la lógica establecida en tal regla significa que damos un paso fuera del mundo totalmente responsivo para lograr una ganancia de rendimiento en dispositivos móviles. Los dispositivos como el Kindle Fire que tiene una pantalla de 600x1024px no cargarán los fragmentos de Twitter y Facebook en vertical, pero sí en horizontal. Cosas raras como ésta sucederán, pero ese es el precio que tenemos que pagar. Por suerte hay una solución y se llama mejora progresiva. Debería ser fácil cargar el contenido que falta una vez que la pantalla se vuelve a ampliar. Nuevamente, deberías pensar dos veces antes de esto, ya que probablemente confundirá a tu usuario, pero sigue leyendo y observa el aumento de rendimiento de esta técnica.

Actualmente utilizamos el ancho de pantalla para todas nuestras decisiones, pero también podríamos utilizar otras capacidades como la nueva API de información de red.

12. Actuación

Entonces, ¿cómo afecta nuestro enfoque al rendimiento del sitio? Aquí hay algunas pruebas de tres puntos de interrupción diferentes, llamémoslos Grande, Mediano y Pequeño. (Tenga en cuenta que el código en el sitio de demostración no está minimizado para que sea más fácil de leer y depurar):

• Grande: 84 solicitudes, 696 KB transferidos | 2-6 s (carga: 1-3 s, DOMContentLoaded: 600 ms-3 s).
• Medio: 84 solicitudes, 685 KB transferidos | 2-6 s (carga: 1-3 s, DOMContentLoaded: 600 ms-3 s).
• Pequeño: 25 solicitudes, 221 KB transferidos | 560 ms (carga: 580 ms, DOMContentLoaded: 320 ms).

Entonces, el sitio grande es tres veces más grande que el sitio pequeño, ¡tanto en tamaño como en número de solicitudes! La diferencia en el tamaño de la imagen de las tres imágenes de 500 px a la imagen más grande de 770 px es de 60 KB. Así que son los widgets sociales los que realmente hacen que el sitio sea grande, no las imágenes. Pero el tamaño en sí no es el único problema aquí, la cantidad de conexiones también es problemática y provienen únicamente de los widgets sociales. Las imágenes también están muy optimizadas con respecto a la versión original mediante el uso de Photoshop y Imagen óptima.

13.Conclusión

Ahora tenemos una configuración RESS básica y debería ser fácil incluirla en su sitio actual o incluso en un CMS PHP como Wordpress o Drupal. La técnica puede ir en contra de algunas de las cosas que aprendió en su clase de RWD, pero en muchos casos es mucho más eficiente (tanto para usted como para el navegador) poner la lógica en el servidor. También descubrí que esto brinda una mayor flexibilidad ya que puedes agregar o eliminar contenido para dispositivos específicos. y puede utilizar soluciones de terceros que no sean compatibles con dispositivos móviles ofreciendo soluciones alternativas en pequeños pantallas.

La mejora progresiva es una parte central del diseño web responsivo y también se puede utilizar junto con RESS y un La extensión natural de nuestra demostración de inclusión de contenido es incluir contenido con JavaScript cuando el tamaño de la pantalla aumenta. También debe tener en cuenta que ahora ofrecemos contenido ligeramente diferente en la misma URL y que esto puede afectar su caché. Existen soluciones para abordar este problema, pero están fuera del alcance de este tutorial.

14. Otras lecturas

Es posible que también desee consultar otros trabajos en RESS: Detector por David Olsen y la presentación Adaptación: por qué el diseño responsivo realmente comienza en el servidor por Yiibu así como el original artículo RESS por Lucas Wroblewski.

Anders M Andersen - andmag.se - vive, trabaja y juega en Estocolmo, Suecia. Ha estado haciendo desarrollo móvil desde WML y actualmente está tratando de lograr que esa "cosa responsiva" funcione mejor para dispositivos móviles. Póngase al día con Anders en Twitter como @andmag.

¿Me gusto esto? ¡Lee esto!

• Brillante tutorial de wordpress selección
• Nuestro favorito fuentes web - y no cuestan ni un centavo
• Descubra lo que sigue para Realidad aumentada