Llevo desde el martes dándole vueltas al tema. Si no habéis visto la keynote de Steve Jobs en la Macworld de la semana pasada, ya tardáis en buscar el vídeo. Lo que presentó Apple no es solo un teléfono que reproduce música o se conecta a internet. El dichoso iPhone es, a todos los efectos, un bofetón de realidad para los que nos pasamos las noches picando código web y peleando con la compatibilidad de navegadores.

Cuando Jobs dijo aquello de "un iPod, un teléfono y un comunicador de internet", la sala aplaudía fascinada por el cacharro en sí. Pero yo, viéndolo desde casa, solo podía pensar en una cosa: no tiene teclado físico y no hay ratón. Todo se basa en una pantalla multitáctil completa. Suena a tecnología de película de ciencia ficción, pero para los que diseñamos y programamos interfaces, esto nos acaba de abrir un melón técnico de proporciones épicas.

La muerte del 'Hover' y el fin del cursor

Llevamos años educando a los usuarios para que usen el ratón. Toda nuestra lógica de interfaz actual asume que hay un puntero preciso que se mueve ágilmente por la pantalla. Nos hemos acostumbrado a esconder información o desplegar menús de navegación completos basándonos exclusivamente en los eventos del ratón.

Prepárate un buen café, porque esto rompe otra de las grandes reglas no escritas del desarrollo front-end. Mira cualquier menú de navegación típico que montamos hoy en día:

// El clásico menú desplegable en DHTML que hacemos todos
var menu = document.getElementById('menu-principal');

// ¿Qué va a pasar con este evento?
menu.onmouseover = function() {
    document.getElementById('submenu').style.display = 'block';
};

menu.onmouseout = function() {
    document.getElementById('submenu').style.display = 'none';
};

Párate a pensarlo un momento. ¿Cómo demonios haces un onmouseover con la yema del dedo sobre un cristal? Exacto, no puedes. En una interfaz puramente táctil, el concepto de "pasar por encima" directamente no existe. O tocas la pantalla o no la tocas. Esto significa que todos esos menús desplegables súper dinámicos que hemos programado en JavaScript se van a ir al traste si Apple consigue popularizar este tipo de pantallas. Vamos a tener que volver a depender casi en exclusiva del viejo y confiable evento onclick.

Safari completo en 320x480 píxeles

El otro gran tema de debate en los foros es el navegador integrado. Jobs presumía de que el iPhone trae una versión "completa" de Safari (nada de páginas WAP limitadas ni versiones recortadas tipo Opera Mini). Aseguran que renderiza la web de internet tal cual la vemos en nuestros flamantes monitores a 1024x768.

¿El problema fundamental? La pantalla de este teléfono es de 320x480. La "mágica" solución de Apple es cargar la página completa minimizada y permitir al usuario hacer pinch-to-zoom (pellizcar con dos dedos para ampliar) y hacer doble toque sobre un bloque de texto para que se ajuste al ancho de la pantalla. Es innegablemente ingenioso a nivel de hardware, pero a nivel de usabilidad diaria me parece un parche tremendo.

Imaginaos leer un foro en phpBB denso o intentar navegar por un portal de noticias pesado, maquetado con cuatro columnas llenas de floats. El usuario se va a pasar el día ampliando, reduciendo y arrastrando la página de un lado a otro solo para poder leer un párrafo. Y ni hablemos del drama de acertar con un dedo —que es, al fin y al cabo, un puntero gordo y torpe frente a la precisión quirúrgica de un píxel de ratón— en esos enlaces de texto enanos que los diseñadores se empeñan en poner con un tamaño de fuente de 10px.

Lo que nos tocará adaptar a los desarrolladores

Nos guste o no, si este teléfono triunfa —y viendo el nivel de hype desmedido que hay ahora mismo, yo apostaría a que sí—, vamos a tener que cambiar radicalmente nuestra forma de plantear la web. Yo lo tengo claro y me voy preparando para lo que viene:

  1. Interfaces más gordas: Los botones y enlaces van a tener que ser sustancialmente más grandes. El dedo es el nuevo ratón y no perdona errores de puntería.
  2. Menos magia oculta: Si no hay hover, la información crítica tiene que estar visible desde el primer momento o ser accesible mediante clics muy explícitos.
  3. Versiones móviles dedicadas: Estoy casi seguro de que nos va a tocar mantener paralelamente un subdominio estilo m.nuestrositio.com con hojas de estilo CSS ultra reducidas y estructuras lineales simplificadas solo para estos dispositivos. Porque enviar cientos de kilobytes de imágenes y JavaScript a una conexión GPRS o EDGE lenta va a ser un auténtico dolor de muelas para el usuario.

Todavía faltan meses para que este teléfono salga al mercado (y seguro que cuesta un riñón traerlo a España), pero el aviso a navegantes ya está dado. La web de escritorio monolítica, rígida y pensada para estar sentados frente a un ratón, tiene los días contados como único estándar intocable. Más vale que los programadores empecemos a quitarle el polvo a la vieja etiqueta onclick y a diseñar interfaces que soporten dedos grasientos. El futuro parece que viene sin teclado.