Por un uso responsable de AJAX

Porque no queremos que nadie se resbale y se parta el cuello de darle tanto AJAX al suelo… ¡ah! de eso no iba…

La experiencia de encontrar proyectos que he tenido que refactorizar de cabo a rabo, que hacían un uso abusivo de Ajax, bien sea puro o por medio de una librería como jQuery -da igual- me ha llamado a escribir esta entrada.

El uso de AJAX como navaja suiza para «mejorar» la experiencia de usuario lleva a algunos proyectos al fracaso absoluto o a un funcionamiento deficiente. Que además tendrá mayor incidencia sobre las webs «públicas» en contraposición a las intranets desarrolladas a medida.

En Internet, todas las piezas importantes de información deben tener un enlace directo, un enlace que haga esa información accesible por una URL. Esto es válido también para las páginas construidas completamente con Flash. Un documento, un artículo, cualquiera unidad de información relevante NO debe ser accedida exclusivamente de las siguientes maneras:

Haciendo click en un control o enlace que en lugar de apuntar a una URL llame a una función Javascript que escriba el contenido en el documento o lo solicite asíncronamente con AJAX.
Exclusivamente mediante la carga de contenido por mediación de alguna tecnología como Flash.

Así, en mi opinión, hay una serie de situaciones donde se puede hacer la carga asíncrona de información por AJAX y una serie de situaciones donde nunca se debería hacer, porque de hacerlo se nos presentarían una serie de problemas graves. Así que esta es mi lista de comprobación personal de como debería quedar una aplicación web que integrara ajax:

Todos los elementos de la jerarquía de navegación de la página deben ser accesibles mediante un enlace directo, una URL. De esta forma, el navegador va acumulando elementos de historial y permite navegar a la página anterior y a la página siguiente. Cuando toda la página se basa en un documento HTML único, al que se le van «pegando» trozos de información que simulan ser las subpáginas, desaparece la capacidad de navegación.
Por ejemplo: tenemos la «Empresa de Recauchutados del Sur», www.rsur.es, que divide sus páginas en «Contacto», «Donde Estamos», «Servicios» y «Productos.» Esos fragmentos importantes de información deberían ser enlaces normales del estilo www.rsur.es/contacto, www.rsur.es/situacion, www.rsur.es/servicios y www.rsur.es/productos; favoreciendo la navegación, la indexación en buscadores y la difusión de los contenidos (p.ej. que alguien a quien le ha gustado un apartado pueda enviárselo fácilmente a otra persona por cualquier medio).
Una motivación esgrimida por los desarrolladores que usan AJAX como usaría McGyver su navaja, es el ahorro de ancho de banda. Si bien esto tiene algo de cierto, es mucho más grave hacer invisible la información a los buscadores y perder el historial, que consumir un poco de ancho de banda extra.
Especial atención merece que, si realmente se usan interacciones AJAX, no se use HTML como el contenido de las comunicaciones. El código HTML lleva una muy considerable carga de contenido estructural y de presentación, haciendo que se ahorro de ancho de banda se vea muy reducido. En su lugar, hay que emplear información pura en formato XML o JSON.
Perder el historial de navegación por tu página provoca que después de un rato navegando por ella, un usuario, al pulsar Atrás, vaya a la página que había visitado justamente antes de la tuya -usualmente un motor de búsqueda- y abandone tu página, quizás para siempre.
Hay interacciones donde sí se puede y se debe emplear AJAX para mejorar la navegación, y será principalmente con contenidos no principales o con acciones transaccionales. Por ejemplo, hay librerías como jQuery que te permiten montar fácilmente un cuadro de diálogo de interacción con el usuario, en el que puedes cargar información relacionada con el contenido principal. Esto es muy útil en aplicaciones web de gestión para modificar información secundaria asociada al formulario principal. Yo suelo cargar el contenido de esa información secundaria mediante AJAX.
El guardado de información mediante formularios. Este es uno de los mejores usos que se le puede dar a AJAX. En lugar de provocar la molesta recarga de la página completa con el envío de un formulario tradicional, se puede hacer la validación, envío y guardado de la información por AJAX/JSON. Se puede aprovechar el controlador receptor de esta información del formulario para que también admita la petición por POST o GET normales, de forma que cuando Javascript no esté habilitado en el navegador, la aplicación pueda degradar suavemente y se siga permitiendo guardar la información al estilo tradicional.
Los conocidos tooltips que presentan información relacionada situando el ratón sobre un término. Su información podría cargarse asíncronamente por AJAX.
Hay una excepción con los formularios. Muchas veces las aplicaciones web de gestión de información obedecen a la clásica estructura listado > pantalla de elemento, donde buscas el elemento a modificar y accedes a su gestión mediante algún botón. Y usualmente se llega al listado después de generar una búsqueda mediante un formulario. Es recomendable que en un formulario destinado a la búsqueda, el envío se haga de la forma tradicional, por GET, porque así tendremos una URL que representa a esa búsqueda. Y esa URL la podemos guardar para repetir la búsqueda. Y, más importante, si hay que volver al listado, se puede usar el botón Atrás, no teniendo que volver a rellenar el formulario para repetir la búsqueda. Por ejemplo, que el formulario generara una petición GET www.rsur.es/productos/?cat=neumaticos&medida=175R6. No se recomienda tampoco hacer una petición tradicional por POST, para que al volver Atrás al formulario no saliera el típico diálogo de los navegadores de volver a enviar la información.
Ni que decir tiene que el acceso a cada elemento de información a partir del listado debe ser por una URL tradicional y no ser cargada con AJAX. Por ejemplo www.rsur.es/productos/?marca=goodyear&modelo=optigrip.

Como comentario final, decir que los dispositivos desde los que se accede a las páginas son cada vez más variopintos: teléfonos móviles, tabletas, lectores de tinta electrónica, televisores, etc. y las páginas deben degradar lo mejor posible en estos dispositivos, para lo cual no ayuda nada que todo el contenido sea cargado por AJAX, porque estos nuevos dispositivos pueden bien no soportar Javascript -raro- o -casi seguro- no soportar AJAX. Hoy dia afortunadamente cada vez hay que pensar menos en hacer una versión para dispositivos pequeños, porque si toda la información está en correcto HTML, bien etiquetada y es accesible mediante enlaces tradicionales, estos mini-navegadores casi seguro que la presentarán bien legible.

Hasta aquí lo que se me ocurre. Cada aplicación es un mundo aparte, con sus particularidades, recordad siempre usar las comunicaciones AJAX con mesura y plantearse si es una unidad importante de información lo que queremos cargar, o si es una unidad secundaria. Y en formularios, si se trata de búsquedas o si se trata de guardar datos. Y nunca, nunca, perder la capacidad de Página anterior, Página Siguiente de los navegadores, ni perder la oportunidad de ser indexado en los buscadores o de tener un puntero «real» a la información importante.

Perpetrado el 26 de marzo de 2011 por una IN (Inteligencia Natural), la mia, con cierto esfuerzo.

Archivado en categoría(s) Divagaciones, Internet, Programación