El origen de responive web design, para adaptar webs a teléfonos móviles principalmente, es un artículo aparecido en A List Apart con el título de tachán... responsive web design. La técnica consiste en usar:

• rejilla flexible
• CSS3 Media Query
• Imágenes flexibles (ver fluid images)

En el fondo no hay nada nuevo: Media Query es una potente evolución de media types presente en CSS2, y el uso de rejilla e imágenes flexibles ya era conocido desde hace tiempo.

Hispanizando el término

Parece sencillo traducir el término original responsive design por diseño responsivo. Pero consultando el diccionario de la RAE, me ha costado encontrar uno buena traducción que respete el espíritu del término original. Gracias a la buena gente en twitter encuentro buenas alternativas:

• diseño web adaptable (@1984), con la puntualización de @isbl (diseño web adaptable a cualquier resolución de pantalla).
• diseño web adaptativo (@iagor)
• diseño web autoadaptable (@ala_747)

A mí personalmente me parece mejor la opción diseño web adaptativo, si hacemos caso al diccionario (definición de adaptativo en la RAE):

adaptativo

Perteneciente o relativo a la adaptación o a la capacidad de adaptación.

Esa capacidad de adaptación es lo que me parece más apropiado. Pero bueno, cuestión de opiniones: todas las argumentadas son bienvenidas.

¿Cómo funciona?

Tenemos una típica web con su código HTML, CSS, javascript (imprescindible una librería, como jquery y sus correspondientes plugins) y un buen puñado de imágenes. Todo ese código es el que se envía al navegador y le toca al potente ordenador de sobremesa (o al no tan sobrado de potencia teléfono móvil) procesarlo. Lo cuál equivale a descargarse todo, filtrar los estilos que le corresponden, ocultar los elementos invisibles (pero descargados) y mostrarlo en las pantallas de nuestros cacharros, ya sean grandes o pequeños, potentes o justitos. Siempre y cuando sepan interpretar el código...

Ahí hay un problema: se confía demasiado en el dispositivo de destino (velocidad de conexión y procesador, memoria, capacidad de comprender el código), y en ocasiones se le envía demasiados recursos, aunque no los muestre (y es una pérdida de tiempo y recursos que en ocasiones puede ser exagerado).

¿Es la mejor forma de crear una web móvil?

En palabras del que puso nombre a la técnica...

I think of responsive design as an alternative to mobile sites.

Ethan Marcotte — Ethan Marcotte on responsive web design

Lo considera una alternativa al diseño de una web específica para móviles. Y yo añado que no es la mejor alternativa. Sigo pensando que un buen trabajo de desarrollo en el servidor, con detección de dispositivos (mediante WURLF por ejemplo) y envío de contenido optimizado para dicho dispositivo, obtiene resultados mucho mejores que la técnica de diseño web adaptativo. Una muy buena explicación, la puedes encontrar en la presentación Why responsive design actually begins on the server a partir de la página 83.

¿Existen ocasiones en las que el diseño web adaptativo puede ser una alternativa razonable para ciertos proyectos web? Por supuesto, depende del tipo de web, de los recursos disponibles, del contenido que se muestra,... Una web ligera (no como esas de 5 megas), con pocos elementos multimedia, pocas imágenes, sobre todo texto, pocos recursos de tiempo y dinero, personal con conocimiento front pero no de lenguajes de servidor... es un proyecto ideal para poner en práctica la técnica de diseño web adaptativo. Al menos es algo.

Pero seamos sinceros: el diseño web adaptativo no deja de ser un truco de maquetadores con más o menos conocimiento de CSS y HTML para intentar que una web no se vea demasiado mal en ciertos teléfonos móviles. Es mejor que nada, pero dependiendo de la web, puede ser una chapuza o algo brillante.

Me permito recomendar dar un vistazo a la presentación Pragmatic responsive design. Me parece muy completa y un trabajo más que correcto. Un buen ejemplo a seguir.

Algunos consejos para diseño web adaptativo

Bueno, hablo en concreto de CSS3 Media Query.

• Para teléfonos móviles no tiene sentido usar handheld o screen. Desde que el iPhone dejó de considerarse un dispisitivo handheld desde el punto de vista del CSS, ha sido el primero de una larga lista de dispositivos en considerarse similares a, por ejemplo, un iMac de 27". Y no es lo mismo una pantalla de 3,5" que una de 27".
• No tiene sentido tampoco tener en cuenta exclusivamente la resolución de pantalla. El teléfono móvil Samsung Galaxy Nexus tiene una resolución de 1280x720 px. Muchos netbooks tienen resoluciones de 1024x600. Es uno de los muchos factores a valorar.
• Algo que casi nadie ha utilizado, que sepa, y que puede ser muy útil: tener en cuenta, no la resolución de pantalla, sino el tamaño de la pantalla en pulgadas. Ahí va una clasificación discutible: móviles menos de 6", tablets entre 6" y 10", ordenadores... más de 10" (la pena es que la resolución de 10" es usada por tablets y ordenadores). Tras estar haciendo pruebas, creo que es un punto de partida razonable. Además, funciona. Con un extra importante...
• Usar la resolución —desde el punto de vista de la densidad de pixels— para diferenciar la calidad de las pantallas. Ver donde se explica en Media Queries 4.11. resolution y en DPI Calculator / PPI Calculator para ver la resolución de pantalla de diversos dispositivos y una práctica calculadora.
• Recuerda las televisiones: muchas pulgadas de pantalla pero forzosamente tienen que usar un tamaño de texto más grande: el móvil, la tablet o el ordenador lo tenemos como mucho a medio metro de distancia. Un televisor puede estar a dos, tres o más metros.

El contexto

Aunque ya está muy visto, es obligado recordar que cada proyecto se desarrolla en un contexto y factores como el presupuesto, el objetivo de la web, conocimientos técnicos, el contenido, los dispositivos,... y los teóricos usuarios de la web. Un sitio para ver estadísticas de internet es statcounter, por continentes, países, sistemas operativos, móviles,... Ignoro su fiabilidad, pero debería abrir los ojos a más de uno.

El factor Be Cool

Un par de asuntos recurrentes. Por decirlo de una manera suave, empiezo a estar bastante hasta las narices, de que en la teoría y en la práctica, los únicos dispositivos que se utilizan para hablar o aplicar el responsive design (o para esos dos o tres lectores de xposible "diseño web adaptativo"), son los de Apple. Vale que queda muy vistoso utilizar imágenes de los cacharros de Apple y optimizar el CSS para el iPhone y el iPad en vertical y apaisado, pero hay más dispositivos. No les fastidies.
Pero el colmo es suponer que todos los cacharros que se conectan a internet tienen el núcleo webkit. Usar prefijos "beta" e ignorar los equivalentes de otros núcleos (-moz, -khtml, -ms, -o) o directamente las recomendaciones del W3C cuando funcionan. Una falta de profesionalidad preocupante. Luego pasa lo que pasa: Is the fat lady singing for Vendor Prefixes?.

Un gran poder conlleva una gran responsabilidad.

Ben, tío de Peter Parker.

La versión larga la puedes encontrar en [CSSWG] Minutes and Resolutions Paris F2F Monday Morning 2012-02-06: Administrivia, Vendor Prefixes, Property/Value Alias OM apartado Vendor Prefixes (sólo conozco a una persona que la lee por iniciativa propia). Una versión digerida en WebKit Isn’t Breaking the Web. You Are y la llamada a la acción en CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*.

Confieso que soy tengo tendencia conservadora con respecto a las tecnologías webs: prefiero utilizar las novedades cuando están bien asentadas. He de confesar también que mis conocimientos en CSS3 son más bien limitados, por no hablar de HTML5.

¿Tiene sentido ser un desarrollador web y no estar al tanto de las últimas tecnologías? Probablemente no.

¿Tiene lógica esperar a usar en producción algo que todavía está en fase alfa o beta y se desconoce si al final se implementará o no? Desde mi punto de vista sí. Y más teniendo en cuenta lo que sabemos con el ritmo de actualización de ciertos navegadores.

¿De qué hablo? El abuso inconsciente de característcas en fase alfa-beta de implementaciones de CSS que publica webkit (sí esas que empiezan con -webkit-) por parte de los desarrolladores webs.

¿Por qué? Porque en numerosos sitios se está provocando que la web sólo funcione en los navegadores con webkit (Safari, y navegadores por defecto de iOS y Android). Se está rompiendo la web. Y un gran perjudicado es Opera, hoy por hoy el navegador más usado en los teléfonos móviles en el mundo (ver el gráfico Top 9 Mobile Browsers from Jan 2011 to Jan 2012 ahora mismo, Opera es el número uno con un porcentaje de casi un 24%) por no hablar de otros navegadores, como Firefox, que tienen problemas con webs específica para móviles. No tiene sentido.

El asunto tiene muchos puntos de vista: por un lado está la posibilidad de que los navegadores mejoren (y los prefijos propietarios de los navegadores en CSS no deja de ser innovación), por otro lado el mercado de los navegadores, los desarrolladores, los clientes, las especificaciones del W3C (ahora documentos vivos en constante evolución),... y los usuarios.

Estaremos de acuerdo en que la velocidad a la que avanzan las especificaciones del W3C  es demasiado lenta. Pero abusar de características "beta" que implementan algunos navegadores puede ser una temeridad. Y si no nos fijamos si existen alternativas a otros navegadores (más líneas de CSS para implementar características en otros navegadores) rozamos peligrosamente la falta de profesionalidad. Por último, si con el uso de los prefijos de CSS estamos consiguiendo que la web no se visualice correctamente en otros navegadores, o incluso falle de forma escandalosa, entonces deberíamos tener una orden de alejamiento de un editor de código.

Hago un hueco en el blog para hablar de tres recursos bastante relacionados y se podrían resumir en algo muy sencillo: utilizar el pensamiento visual para facilitar la comprensión de la información.

Empiezo por un libro "Tu mundo en una servilleta. Resolver problemas y vender ideas mediante dibujos." (ISBN 9788498750621) de Dan Roam (el título original, si lo prefieres en inglés es "The back of the napkin. Solving problems and selling ideas with pictures."). Propone un método para que cualquier persona, a pesar del probable rechazo inicial, pueda resolver problemas mediante un uso del dibujo muy básico. En su web, Dan Roam cuenta con la sección tools donde podrás encontar, entre otros, un documento pdf que resume bastante el libro (una vez que lo has leído), pero por sí sólo puede ser también muy útil: The Visual Thinking Codex, que no es más que una tabla de doble entrada, donde en el eje horizontal aparece el tipo de información que queremos mostrar (simple-elaborado, cualidad-cantidad, visión-ejecución, individual-comparación, cambio-estado actual) y las preguntas que queremos responder con el gráfico (¿quién?-¿qué?, ¿cuánto?, ¿dónde?, ¿cuándo?, ¿cómo?, ¿por qué?). El objetivo es mostrar información de manera gráfica para facilitar su comprensión e interpretación. Un libro recomendable y mucho. Ha publicado otros dos libros y uno de ellos lo hará en español en marzo (Bla, bla, bla: Qué hacer cuando las palabras no funcionan). Me lo pido.

Por otro lado, un curso de mapas mentales (me enteré gracias a inquietudes en twitter). Una herramienta que había utilizado antes pero sin tener ni idea (resultados catastróficos). El curso es bueno y breve, con videos muy cortos y no creo que se tarde más de una hora en hacerlo. Confieso que mis mapas mentales tras el curso, tienen un barniz de heterodoxia, pero a mí me vale. He estado probando un par de programas gratuitos para crear mapas mentales (Freemind  y Xmind) pero qué queréis que os diga: me quedo con el papel :)

Por último un video de una charla que lamentablemente no me enteré. Menos mal que está en internet :) Se trata de El dibujo y su retorno, una charla impartida por Fernando de Pablo Martínez (dibujario inteligente es su blog en el que habla de Visual Thinking, Concept Draw y Graphic Recording).

Un par de extractos no literales del video: El 75% de la información sensorial nos entra por la vista. La retentiva aumenta hasta un 90% cuando los conceptos vienen acompañados por imágenes.

Personalmente he notado una mejora notable gracias a los tres recursos que menciono. Tengo un nuevo grupo de feeds relacionados con el pensamiento visual. A diferencia de otros muchos feeds, los consulto con bastante frecuencia ;)

• Proximidad
• Color
• Tamaño
• Orientación
• Dirección
• Forma
• Sombreado

El origen es biológico: cuestión de supervivencia de la especie. Más de un astuto lector de xposible confimará su certeza de que las fuentes del diseño son muy profundas...

Dejando de lado las cinco primeras, me centraré en la última, el sombreado. Muy relacionado con el sol, una fuente de iluminación y calor. Viendo la dirección de la sombra, los hombre primitivos (hablo de cuando twitter no existía en incluso antes) sabían cómo encontrar el sol o la hoguera.

Ahora es cuando doy una pirueta en el discurso, para recordar una frase que me dijo hace unos meses un compañero: en el diseño gráfico, la sombra en los elementos suele estar debajo, porque el sol está arriba. Con el tiempo, me he hecho una pregunta: ¿y si el sol no está arriba? Traduzcamos la pregunta a algo relacionado con la web: ¿Y si el call to action no está arriba?

Por si eres uno de los pocos que no conoce qué narices es un call to action (yo hace poco lo era), basta con resumir que es un elemento que debería captar nuestra atención para realizar una acción concreta: darnos de alta, suscribirnos a sus noticias, buscar, ver las ofertas,... cosas así. En ocasiones se destaca usando apropiadamente los atributos precongnitivos mencionados al principio, entre los que seguramente destaquen el color, el tamaño y la forma.

La tesis que defiendo, y bienvenidos sean los comentarios al respecto, es que la sombra o la intensidad de la luz, puede ser un factor importante a la hora de destacar adecuadamente los elementos, y como extra, puede proporcionar una dirección a seguir, y dentro de esa dirección, una orientación hacia el call to action. Como diría Chicho Terremoto Tres puntos, colega.

A continuación tienes una imagen que pretende ilustrar lo que digo: en una rejilla con nueve elementos, el elemento central actua como "sol" que "ilumina",siendo el sol del ejemplo oscuro el resto de los elementos. Desde cualquiera de esos otros elementos, la dirección de la luz, nos conduce al centro, lo que se supone que es el centro de atención (no sólo por estar en el centro, aunque así sea en el ejemplo). He usado un degradado con dos colores del tema de xposible,... y así ha salido...

En el segundo ejemplo, trasladamos ese centro de atención (de luz y de calor) a la esquina inferior izquierda.

El caso es que los ejemplos usados tienen truco, porque dejo de lado otros factores (color, tamaño, forma y proximidad) que obviamente cambian la relación entre todos los elementos que entran en juego.

De postre, Fundamentos de diseño: Economía de Recursos, de Ale Muñoz, que habla un poco de espacio, color y forma.

Imágenes actualizadas tras el comentario acertado de David

No hagas lo que te digo, haz lo que quiero.

Muy grande. Muy cierto.

Otra frase que dice un compañero, desarrollador también tiene miga:

Me gustaría ser al menos una vez cliente para pedir en vez de intentar adivinar lo que quieren.

Dos caras de la misma moneda. El origen es algo muy sencillo: falta de comunicación. En sus dos vertientes, desde el punto de vista de lo que se quiere hacer:

• El cliente no sabe o no quiere explicar lo que quiere.
• El diseñador-desarrollador-gerente (llámalo "X") no entiende o no sabe cómo saber lo que el cliente quiere.

Por otro lado, lo que se puede hacer que viene a ser lo mismo, pero cambiando los papeles.

Evidentemente no pueden faltar otros detalles como el tiempo, el presupuesto y las consideraciones técnicas. Pero no es de eso de lo que quería hablar.

Para terminar no puede faltar una referencia obligada a Aprende a preguntar de Ale Muñoz, por la parte que nos toca.