AJAX es el término de moda. Para los despistados les diré que de lo que hablamos hoy no tiene que ver ni con un equipo de fútbol holandés, ni con un detergente de triple acción.

AJAX significa algo así como Asynchronous JavaScript + XML. Se trata de un conjunto de tecnologías que se unen para ofrecer un servicio, que incorpora:

• Presentación basada en estándares usando XHTML y CSS
• Interacciones dinámicas mediante DOM (Document Object Model)
• Intercambio y manipulación de datos mediante XML y XSLT
• Recuperación de datos asíncrona usando XMLHttpRequest
• Javascript como nexo de unión de todo ello

Básicamente, la principal virtud de AJAX está en la potencia que se le puede extraer al trabajo asíncrono de peticiones al servidor. Estamos acostumbrados a un modelo de interacción sincrónica basada en clic-petición-presentación, clic-petición-presentación. Con AJAX la interacción pasa a ser asíncrona. Cada vez que se hace clic no necesariamente se establece una conexión con el servidor.

AJAX hace de intermediario entre el servidor y el usuario, anticipando peticiones de datos al servidor, de modo que cuando el usuario hace un clic determinado, AJAX ya tiene listos esos datos y los muestra directamente, sin tener que volver a hacer una petición al servidor y su consecuente espera.

Ahí está el meollo precisamente, en que ciertos procesos se muestran en la página sin retardo alguno, pues mientras el usuario miraba unos datos en la pantalla, AJAX le ha estado preparando los siguientes que iba a necesitar.

El término AJAX apareció por febrero de 2005, en un artículo de Jesse James Garrett titulado Ajax: A New Approach to Web Applications, y que Denken Über ha tenido la gentileza de traducir al español.

James utiliza el siguiente gráfico para explicar la diferencia de funcionamiento (sincrónica vs. asíncrona) respecto del modelo tradicional comparado con AJAX:

AJAX se utiliza para algunas de las últimas aplicaciones de Google, cuyos desarrolladores parecen haber entendido a la perfección en qué consiste Internet y sus potencialidades.

Por ejemplo, si he entendido bien el mecanismo de funcionamiento asíncrono de AJAX, cuando leemos el correo en Gmail y abrimos un mensaje que forma parte de una cadena de mensajes con alguien (o conversación) sólo se nos muestra el último mensaje recibido del emisor. Mientras nosotros leemos ese mensaje Gmail va cargando el resto de mensajes de esa conversación, de forma que cuando pulsamos en la opción de Expandir los mensajes vemos que se carga inmediatamente y que la url no varía.

También se utiliza AJAX para Google Maps y para Google Suggest. En Usabilidoido comentan varios sitios más basados en AJAX.

Las vías de desarrollo futuro aún no está claro hacia dónde pueden derivar, pues esto no ha hecho más que empezar. Por ejemplo, Daniel (de torresburriel.com) ya se ha percatado de las posibilidades que ofrece modificar una simple aplicación para hacer pos-it en el web.

En realidad la tecnológía en sí no es especialmente nueva, ni siquiera la idea del trabajo asíncrono (Flash y Java lo permiten), pero sí tal vez las vías de aplicación y los resultados en cuanto a experiencia de usuario. Ahí, claro está, también hay sus problemas.

Problemas

Estas aplicaciones tienen una pinta estupenda, y resultan tremendamente útiles. Los problemas, sin embargo, vienen precisamente de la mano de la propia tecnología empleada.

El hecho de emplear javascript y XMLHttpRequest ya implica problemas con los navagadores que no los soporten o no los tengan habilitados.

La solución, obviamente, pasa por ofrecer una alternativa sin usar esa tecnología, pero claro, en ese caso perdería parte del interés que tiene una aplicación como Google Maps, ya que, dada la cantidad de datos que ha de manejar, sería muy poco útil si tuviera que trabajar con el clásico método sincrónico. El tiempo de espera sería, tal vez, demasiado largo como para que al usuario le valiera la pena esperar la llegada de los resultados.

De otro lado, están lor problemas relacionados con la experiencia de usuario en sí misma:

• Los formularios basados en XMLHttpRequest no actúan como el usuario está acostumbrado. En un formulario clásico uno puede hacer y deshacer a placer, sabiendo que hasta que no se pulse el botón "enviar" podemos cambiar los datos que haga falta. Pero aquí no funciona así, los datos se envían campo a campo, lo que desvirtúa el concepto clásico de formulario y se introduce un elemento que genera gran perturbación y confunde al usuario más avezado.
• La carga instantánea de una nueva página (que en realidad es la misma) puede producir en el usuario la sensación de que nada ha pasado, pues la carga ha sido muy rápida como para que pudiera percibirla y, además, la url no ha variado.

La solución para este segundo problema ya se apunta en biguel.com al comentar un artículo de Jeffrey Veen:

Mediante AJAX (peticiones XMLHTTP) la recarga es parcial y la percepción del cambio es mucho menos notoria. De ahí que ante cambios tenues del interface, sea necesario incorporar señales sutiles para que el usuario perciba que algo ha cambiado en la página.

Esto nos lleva a las cuestiones relacionadas con la visibilidad del estado del sistema. Es posible que de tan rápido que funciona la actualización de datos en pantalla el usuario no se percate del cambio y, por tanto, espere indefinidamente un cambio que ya se ha producido. Por tanto se debe aportar información adicional sobre el estado del sistema.

Una posibilidad es utilizar los colores para denotar el cambio que se ha producido, pero, como bien indica Daniel, de Torresburriel, no basta sólo con ello:

El uso de colores para denotar la interacción deberá contar con el contraste suficiente para que el cambio sea significativo. Y, añado, debería ser complementado con algún otro signo que invalidara esa técnica desde el punto de vista de la accesibilidad (Pauta 2: No se base sólo en el color).

Lo que nos lleva al campo de la Accesibilidad.

Me pregunto si no bastaría con algo en principio más simple: retardar ligeramente, de forma artificial, la carga de datos en la página, para así ofrecer la habitual sensación de página que se descarga poco a poco, y no de golpe como hace AJAX.

La cuestión sería que el retraso fuera lo suficientemente leve como para no ralentizar el sistema y lo suficientemente largo como para que el usuario percibiera correctamente el cambio en el estado del sistema (la sensación de descarga de la página, vamos).

Puede que sea una simple moda, o bien que AJAX haya venido para quedarse. Aún es pronto para saberlo.

Si queréis ampliar información, Stanmx nos deja una lista de artículos interesantes.


Autor: Juan Carlos García Gómez
http://usalo.blogspot.com/2005/07/ajax-y-usabilidad.html

Escribe un comentario

Expresa tu opinión sobre este recurso y compártela con los demás.