elclerigo!

Comienza haciendo un repaso a la manera adecuada de trabajar en la red, separando el comportamiento (javascript, ajax), la presentación (CSS), la estructura (HTML) y el contenido.

En un mundo de desarrollo ideal deberíamos implementar el comportamiento de nuestras páginas mediante javascript no intrusivo. Esto no es así cuando la gente usa AJAX, se olvidan de los usuarios sin javascript o sin el objeto XMLHttpRequest implementado en sus navegadores.

Nos invita a olvidarnos del acrónimo AJAX como tal y pensar en su verdadero significado: “comunicarse con el servidor sin refrescar la página completa”. Aunque entiende que en esa definición podrían entrar los frames, iframes e incluso flash; y eso podría llevar a error.

Lo que realmente es AJAX es el objeto XMLHttpRequest (XHR). Es un objeto que salió de Microsoft, en Internet Explorer 5 allá sobre el año 1999, pero que no ha sido hasta ahora cuando ha empezado a usarse realmente porque únicamente funcionaba en Internet Explorer. Ahora que se ha visto la verdadera utilidad de XHR es cuando se ha implementado en todos los navegadores y cuando podemos disfrutar de él.

El W3C ha creado un borrador de trabajo que indica cómo los desarrolladores deben trabajar con este objeto.

Como desarrolladores no tenemos que ver XHR como una forma de cambiar el navegador, pasando de que sea un cliente ligero a un cliente pesado. Es decir el navegador no debería de realizar el procesamiento de los datos, algo que es parte del trabajo del servidor. Para ello ejemplifica todo mediante una comparativa con un self-service (cliente ligero), con un restaurante con camareros (cliente pesado con AJAX) y con un montacargas (cliente ligero con AJAX). El peligro de transformar el navegador y manejar datos en él, es que desconocemos el software de cliente y en ocasiones puede que terminemos por perder el contenido al no poder mostrarlo.

La clave es ¿cómo se usa AJAX? Debería de funcionar como un montacargas. Que únicamente sirva para solicitar datos y recogerlos para mostrarlos. Que se sigan procesando en el servidor. Para ello lo mejor es realizar un incremento progresivo, empezar los proyectos sin AJAX para asegurarnos que siempre funcionarán e ir poco a poco añadiéndole AJAX. Esto sería HIJAX. Propone como solución a este tipo de desarrollo, que el servidor tenga módulos (en programación serían incluyes), es decir una página de carrito de la compra, otra de registro de usuarios, etc…a las que poder hacer llamadas tanto desde AJAX como desde lenguajes de servidor (ASP, PHP, .NET, Java).

¿cuándo implementar AJAX? Deberíamos reconocer ciertos patrones en los usuarios y desarrollarlos en base a unos estándares de uso. Algunos de esos patrones serían:

• Formularios de acceso (el usuario ya existe?)
• Añadir un producto al carrito de la compra
• Vota/valora un artículo o producto
• Añadir comentarios a una noticia o blog
• Paginar resultados/Mostrar resultados de una consulta???? Esto puede que no, quizás es algo que modifica tanto la página que sea mejor mantener un refresco completo
• En grandes aplicaciones si al eliminar las capas de interacción y presentación dejamos de ver el contenido, no deberíamos implementar AJAX

Los desafíos de diseño a los que nos enfrentamos son:

• ¿qué está pasando? Como decirle al usuario que algo va a suceder. Algo que gire?
• ¿qué acaba de pasar? Indicar al usuario que algo ha cambiado. Esto lo hace muy bien 37signals.

Algo que aclara la duda de cuándo implementar AJAX sería si suprime el botón atrás y el usuario lo demanda. Es decir: “si se necesita el botón atrás no necesitamos AJAX”. Y esto se lográ saberlo mediante las pruebas de usuario.