Que es Ajax
 

 Ajax no es una tecnología. Es realmente muchas tecnologías, cada una floreciendo por su propio mérito, uniéndose en poderosas nuevas formas. AJAX incorpora:

·        presentación basada en estándares usando XHTML y CSS.

·        Exhibición e interacción dinámicas usando el Document Object Model.

·        Intercambio y manipulación de datos usando XML and XSLT.

·        Recuperación de datos asincrónica usando XMLHttpRequest.

·        JavaScript poniendo todo junto.

El modelo clásico de aplicaciones Web funciona de esta forma: La mayoría de las acciones del usuario en la interfaz disparan un requerimiento HTTP al servidor Web. El servidor efectúa un proceso (recopila información, procesa números, hablando con varios sistemas propietarios), y le devuelve una pagina HTLM al cliente. Este es un modelo adaptado del uso original de la Web como un medio hipertextual, pero como fans de The Elements of User Experience sabemos, lo que hace a la Web buena para el hipertexto, no la hace necesariamente buena para las aplicaciones de software.

 

 Figura 1: El modelo tradicional para las aplicaciones Web (izq.) comparado con el modelo de AJAX (der.)

 

Este acercamiento tiene mucho sentido a nivel técnico, pero no lo tiene para una gran experiencia de usuario. Mientras el servidor esta haciendo lo suyo, que esta haciendo el usuario? Exacto, esperando. Y, en cada paso de la tarea, el usuario espera por más. Si estuviéramos diseñando la Web desde cero para aplicaciones, no querríamos hacer esperar a los usuarios. Una vez que la interfaz esta cargada, porque la interacción del usuario debería detenerse cada vez que la aplicación necesita algo del servidor? De hecho, porque debería el usuario ver la aplicación yendo al servidor?

Diferencias con las aplicaciones web tradicionales

En las aplicaciones web tradicionales los usuarios interactúan mediante formularios, que al enviarse, realizan una petición al servidor web. El servidor se comporta según lo enviado en el formulario y contesta enviando una nueva página web. Se desperdicia mucho ancho de banda, ya que gran parte del HTML enviado en la segunda página web, ya estaba presente en la primera. Además, de esta manera no es posible crear aplicaciones con un grado de interacción similar al de las aplicaciones habituales.

En aplicaciones AJAX se pueden enviar peticiones al servidor web para obtener únicamente la información necesaria, empleando SOAP o algún otro lenguaje para servicios web basado en XML, y usando JavaScript en el cliente para procesar la respuesta del servidor web. Esto redunda en una mayor interacción gracias a la reducción de información intercambiada entre servidor y cliente y a que parte del proceso de la información lo hace el propio cliente, liberando al servidor de ese trabajo. La contrapartida es que la descarga inicial de la página es más lenta al tenerse que bajar todo el código JavaScript.

 

Ventajas

  • Recuperación asíncrona de datos, el usuario no tienen que esperar después de una petición.
  • Acercamiento de la metáfora de escritorio a la web.
  • No requiere plugins.
  • Se reduce el tamaño de la información intercambiada. 

 

Desventajas y precauciones

  • Pueden aumentar las llamadas al servidor.
  • Peligro de incompatibilidades en navegadores.
  • Se rompe el flujo de navegación tradicional (botón "volver" y "actualizar").
  • Uso excesivo de Javascript: seguridad, compatibilidad, accesibilidad, complejidad.
  • La percepción de cambio es menor => indicar al usuario que ha habido un cambio o que se va a producir ("cargando ...")
  • Mantener el funcionamiento tradicional de los formularios => no enviar los datos al servidor hasta que el usuario lo solicite.

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 los 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.

Donde Usarlo y en donde no

    Donde se DEBE usar Ajax

  •  Navegación de aplicaciones del tipo jerárquica.
  • Comunicación rápida de usuario-a-usuario.
  • Votaciones y calificaciones online.
  • Filtrado y manipulación de datos.
  • Campo de texto usados comúnmente (autocomplete).

    Donde hay que evitarlo

  • Formularios simples: si no hay más que un paso.. ¿cual es el beneficio de ajax?
  • Búsquedas: este punto es bastante personal, conozco muchos que aman esta funcionalidad.. aunque a mi nunca termina de convencerme más que para dar un hint y punto.
  • Navegación básica: este es un error típico también con Flash ¿cual es la necesidad de hacer un menu con dos boxes que digan “inicio” y “Contacto” en flash.. o en ajax… o en algo más que no sea algo simple?.
  • Reemplazo de grandes cantidades de texto: muy buen punto.. ¿si al hacer click va a cambiar la mayoría de los datos de una página para que usamos algo que sirve para traer datos asincrónicos si en realidad debería aparecer algo totalmente nuevo?.
  • Manipulación de interfaz de usuario: para manejo de UI ya existe XHTML/HTML DOM, y CSS que fueron creadas para esto y no para manejar datos.
  • Widgets inútiles.