CSS-based responsive web design is a great tool for adapting a layout to different screens, period. It is a tool, not an end. In some cases, where a site’s content should be the same from device to device (a blog, for example), responsive web design is enough for the job. More complex services, though, may need much more, including different content, tools, and services.

Yes, friends: it depends.

What’s it depend on? Certainly the needs of the audience. But as with so many things, it often depends a great deal on business considerations, too.

Josh Clark - Responsive Web Design or Separate Mobile Site? Eh. It Depends.

Cita extraída de un artículo que resume una animada discusión entre los partidarios del responsive web design (muy resumido, el uso de Media Query para adaptar la presentación de una web a los diferentes dispositivos) y los que van más allá de la mera presentación de contenidos: optimizar las experiencias según el contexto de uso y de usuarios.

Nada nuevo, en definitiva. Aunque técnicamente ahora es posible obtener mejores resultados que hace no muchos años: hay ejemplos más o menos elaborados en mediaqueri.

Ya puestos, otro artículo que nos puede ayudar a ampliar nuestra perspectiva histórica es New to Mobile? Welcome to the One Web Debate.

Se puede hacer una aplicación web para iOS con HTML, CSS y Javascript, y se indica mediante algunos elementos meta. Aquí va un pequeño resumen:

• <meta name="apple-mobile-web-app-capable" content="yes" /> Da la opción al dispositivo iOS añadir a la pantalla de inicio, junto con el resto de las aplicaciones, un acceso directo a una aplicación web. Ojo que no es lo mismo que un acceso directo que abre Safari con la interfaz habitual del navegador.
• <meta name="apple-mobile-web-app-status-bar-style" content="black" /> Permite quitar de la interfaz los elementos propios del navegador (la barra de la dirección y el buscador arriba, y la barra de navegación, favoritos e historial abajo). Sólo deja visible la barra de estado (cobertura, hora y batería). Tiene tres posibles valores default (de azul iOS), black y black-translucent.
• <link rel="apple-touch-icon" href="touch-icon-iphone.png" /> permite elegir el icono (57x57 en formato PNG) para la pantalla de inicio. Sirve tanto para aplicaciones web como para simples accesos directos a una página web.
• <link rel="apple-touch-startup-image" href="/startup.png" /> incluye una imagen previa a la aplicación web.

No hablo del famoso viewport, aunque personalmente echo de menos la posibilidad de usar una etiqueta para que mantenga la proporción en las vistas vertical y apaisada.

Bueno, siguiendo estas claras instrucciones - risas de fondo - tenemos los primeros elementos para hacer una aplicación web. Qué modernos.

Y ahora viene una curiosidad, que puede tener su sentido, pero resulta chocante: cuando tocamos un vínculo, abre una nueva instancia del navegador, pero esta vez aparece los elementos de la interfaz "normal" (barra de estado, además de la barra de la dirección y la de navegación-favoritos). ¿Qué ocurre? ¿Qué hemos hecho mal?

La respuesta es... nada. Simplemente los vínculos no funcionan como tales en una aplicación web dentro de iOS. Actúan como una especie de window.open. ¿Solución? Un poco de javascript. Aquí va un ejemplo de jquery:

$(document).ready(function() {
	var deviceAgent = navigator.userAgent.toLowerCase();
	var ios = deviceAgent.match(/(iphone|ipod|ipad)/);
	if (ios) {
		$("a").click(function(event) {
			event.preventDefault();
			var direccion=$(this).attr("href");
			location.href=direccion;
		});
	};
});

Por si el código no resulta demasiado trivial, mediante el agente de usuario discriminamos a los dispositivos con sistema operativo iOS, eliminamos el comportamiento por defecto de los vínculo, y le añadimos la url del href a un location.href de javascript que sí funciona. En este caso podríamos tener una aplicación web compuesta por varias páginas HTML.

Teniendo en cuenta lo anterior, cabría preguntarse:

• ¿Quieres un acceso directo a la página de inicio definiendo la imagen tú mismo (y que no salga un pantallazo)? Usa apple-touch-icon.
• ¿Quieres que no se vea la barra de la dirección inicialmente? Prueba con window.scrollTo(0,1); e inicialmente no se verá (aunque estará presente).
• ¿Quieres reutilizar una web como una aplicación web en iOS (más cool) con su imagen de bienvenida - tan útil ella -, y sin elementos de la interfaz en el navegador? Pues mucho cuidado con los vínculos, y recuerda el código anterior para los vínculos internos de la aplicación web. No quedaría bien que al tocar un vínculo, se abra una nueva ventana. Nada bien.

Cambiando un poco de tema, ya hay bastantes voces (con más o menos autoridad) que dicen que las aplicaciones desarrolladas específicamente para un sistema operativo (Android, iOS, Blackberry, Symbian, Windows Phone,...) están viviendo su momento de gloria ahora, y en unos años, será sustituído por aplicaciones webs (teoricamente menos tiempo de desarrollo, y actualizaciones más rápidas). Todo depende de los avances en las aplicaciones web móviles y su implementación (ver Standards for Web Applications on Mobile: February 2011 current state and roadmap).Ya veremos.

El debate, los conflictos y la colisión es inevitable. Sobre todo cuando  no se juega limpio (¿alguien ha hablado de la seguridad?).

Volviendo al W3C: el documento publicado, en estado de Working Group Note (una especie de "informe técnico") es el siguiente: W3C Guidelines for Web Content Transformation Proxies 1.0.

Para ir abriendo boca, aquí va un pequeño extracto de la introducción:

Content Transformation proxies alter requests sent by user agents to servers and responses returned by servers so that the appearance, structure or control flow of Web applications are modified. Content Transformation proxies are mostly used to convert Web sites designed for desktop computers to a form suitable for mobile devices.

Based on current practice and standards, this document specifies mechanisms with which Content Transformation proxies should make their presence known to other parties, present the outcome of alterations performed on HTTP traffic, and react to indications set by clients or servers to constrain these alterations.

The objective is to reduce undesirable effects on Web applications, especially mobile-ready ones, and to limit the diversity in the modes of operation of Content Transformation proxies, while at the same time allowing proxies to alter content that would otherwise not display successfully on mobile devices.

Important considerations regarding the impact on security are highlighted.

Guidelines for Web Content Transformation Proxies 1.0

Hay que darle un vistacillo.

Por otro lado tenemos las aplicaciones, y particuarmente, aquellas que con más o menos lógica, podrían tener su equivalente web. Creo que dos de sus mayores ventajas son la integración con las capacidades del terminal y el sistema operativo, y tal vez mayor rapidez: en ocasiones, en vez de cargar una página web, simplemente hay que cargar datos que muestra la aplicación.

A lo que iba: hoy he encontrado algo que por ignorancia y tratarse de un tema que está fuera de mis intereses habituales, desconocía: hablo del desarrollo de aplicaciones para varias plataformas móviles. Y es que hay un par de plataformas de Mobile Apps cross-platform development que tienen muy buen pinta. Básicamente, se desarrollan aplicaciones en HTML+CSS+Ecmascript y por arte de magia - si me permitís la expresión - puede ser exportada a código nativo para Android, iOS (el caso de Titanium Mobile) y además Blackberry, Symbian y Palm Web OS (en el caso de PhoneGap). Además, es código Open Source.

Mola.

Obviamente tendrá letra pequeña, no será tan sencillo como se promete, pero desde el punto de vista de los desarrolladores, que existan productos así es algo bueno.

Por último, recordar que hace pocos días ha salido la versión alfa de jquerymobile... habrá que probarlo.