Aunque AJAX tiene la capacidad de crear una interfaz más útil y eficiente, no siempre logra este objetivo. Los problemas de usabilidad pueden eliminar cualquier ganancia creada por el uso de nueva tecnología. Esta sección trata sobre algunos problemas de usabilidad mas comunes y luego brinda ejemplos sobre cómo solucionarlos. Muchos de estos problemas de usabilidad pueden ocurrir sin la ayuda de AJAX, pero prevalecen en las aplicaciones AJAX, que son más activas por naturaleza.

Robar el enfoque con mensajes de validación

Este puede significar uno de los problemas de usabilidad mas comunes en los sitios web como e-commerce, los llamados “call to action”. Un “call to action” (CTA) es un elemento visual o textual en una página web que invita al usuario a realizar una acción específica. Por lo general, los CTA se utilizan para guiar al usuario hacia una conversión, como la compra de un producto, la suscripción a un boletín de noticias, la descarga de un archivo o la inscripción en un servicio.

Un uso común de AJAX es realizar una validación compleja antes de que el usuario haya submitido un formulario. Esto es especialmente útil en formularios grandes donde se ingresan grandes cantidades de datos antes de que la validación pueda tener lugar. Los intentos simplistas de validación continua a menudo son peores que esperar hasta que se envíe el formulario para realizar la validación, ya que roban continuamente el enfoque del usuario.

Una solución a este problema es cambiar de un mensaje de error emergente a uno en línea. En algunos casos, esta es una solución aceptable, pero aún causa problemas.

Previniendo deshacer con autoguardado

En las aplicaciones web convencionales, los formularios grandes pueden ser peligrosos porque son imposibles de guardar automáticamente, y enviar el formulario de manera regular depende de que el usuario haga clic en un botón. Además, tal ahorro interrumpe el flujo de trabajo del usuario. Aquí hay un ejemplo: un sistema de administración de contenido se actualizó con AJAX para guardar un artículo automáticamente cada cinco minutos. Parecía una gran solución porque solo se podían perder cinco minutos de trabajo por un bloqueo del navegador o un cierre accidental; sin embargo, después de más uso, se encontraron un par de problemas con este enfoque.

Se produjo un problema cuando un autor abrió un artículo para editarlo. Él o ella haría algunos cambios y luego decidiría, quizás, que no le gustaba el enfoque adoptado. En otras palabras, el autor terminó queriendo volver a la versión anterior, pero no pudo; durante el proceso de edición, el proceso de autoguardado ya había sobrescrito el original. Esto no fue bueno.

Como se puede ver en el escenario anterior, la edición no se pudo hacer en los artilugios en vivo porque el proceso de autoguardado generaría cambios antes de que se completen. Este problema se puede resolver fácilmente creando un área de autoguardado independiente para almacenar los datos de este proceso. Esta área de autoguardado puede mantener de uno a un número ilimitado de autoguardados. A continuación, se agrega una interfaz para permitir a los usuarios cargar un autoguardado y guardarlo como una versión normal.

Gestion de contenido

En algunos sistemas de gestión de contenido, los documentos se versionan de modo que no se produzca el problema original de sobreescribir los datos. Sin embargo, guardar cada autoguardado como una nueva versión también puede ser problemático, ya que hace que un documento torpe sea historia y puede hacer que explote el almacenamiento de datos. En un sistema de gestión de contenido versionado, también funcionaría un área de autoguardado independiente, pero puede ser más útil usar un subárbol en el historial de versiones en el que se guardan los autoguardamientos. La aplicación puede eliminar los viejos autoguardados cuando se completa cada guardado normal. Esto permite que los artículos con guardado automático sean accedidos por el proceso normal de administración de artículos sin causar una explosión en el historial de versiones.

Actualización de secciones de una página sin informar

Una forma de usar AJAX es actualizar partes de la página con contenido nuevo en respuesta a la acción de un usuario. Este proceso de actualización de AJAX podría utilizarse en documentos técnicos para cargar definiciones o información relacionada. Un ejemplo básico de esto es el despligue de definiciones. Cuando haces clic en cualquier término con un enlace discontinuo, su definición se carga en la barra lateral.

Normalmente, cuando haces clic en un enlace, carga una página nueva. Si el usuario esperaba que se cargara una página nueva y no notó el cambio a la derecha, él o ella podría pensar que el enlace simplemente se rompió.

Proporcionar comentarios es sobre encontrar el equilibrio correcto; queremos mostrar que algo ha cambiado sin molestar al usuario con efectos que son demasiado llamativos y que distraen. Hay varias técnicas diferentes que podemos usar en este caso. Una técnica es mostrar un mensaje de carga mientras el navegador está esperando que el servidor responda. Al mismo tiempo, podemos desvanecer el contenido actual y luego volver a fundirlo una vez que ha llegado el nuevo contenido.

Una alternativa para proporcionar retroalimentación de carga es esperar hasta que se cargue el nuevo contenido y luego resaltarlo en un fondo amarillo pálido. Durante un período de tres a cinco segundos, este amarillo se desvanece al color de fondo blanco. En un navegador de documentación, recomendaría este enfoque porque no distrae al usuario hasta que realmente haya algo que ver. Sin embargo, en otra aplicación donde el contenido puede tardar un tiempo en cargarse, también se necesitaría retroalimentación inmediata. Podría combinar ambos enfoques, pero en la mayoría de los casos, un enfoque más sutil es igual de efectivo y más estético.

Breaking Bookmarking mediante el uso de AJAX para cargar páginas enteras

Muchas veces, cuando los desarrolladores adoptan una nueva tecnología, la ven como la solución a cada uno de los problemas de usabilidad que tienen. Un área donde AJAX puede ser usado en exceso es como un reemplazo para los conjuntos de marcos HTML. Este uso de AJAX le permite omitir la carga de las secciones de navegación y simplemente actualizar el cuerpo principal del documento. Sin embargo, a menos que tome medidas para que funcione la creación de marcadores, tendrá los mismos problemas que usar marcos, además de un proceso de desarrollo más complicado.

En la mayoría de estos casos, la solución simple es usar solo páginas normales; Debido a que la navegación rara vez es una gran parte del tiempo de carga de una página, estos enfoques ahorran poco tiempo de carga. En otros casos, puede encontrar que tratar de cargar páginas enteras usando AJAX es solo un síntoma de problemas de diseño más grandes, y tendrá que comenzar desde el principio y centrarse en cómo los usuarios interactuarán con su información. AJAX es una gran herramienta, pero no es la solución a todos los problemas. El diseño y el desarrollo siempre deben tener al usuario en mente. Es posible que el resultado final no use todas las tecnologías que desea, pero mejorará la experiencia del usuario.

Hacer que AJAX requiera en una tienda web

Aunque AJAX agrega grandes capacidades a un sitio web, no vale la pena el costo. El mayor costo es evitar que los usuarios usen un sitio porque no usan un navegador web lo suficientemente avanzado. Si bien es fácil decir “Por favor, actualice”, no siempre es posible hacerlo, especialmente si el usuario está usando un dispositivo móvil, como un PDA o un teléfono celular. Echemos un vistazo a un escenario ficticio para ver algunos de los problemas de usabilidad que pueden surgir al requerir AJAX. Una tienda basada en la Web actualizó su carrito de compras para usar AJAX; luego probó AJAX en todos los principales navegadores, y todo funcionó bien. Debido a que la tienda era compatible con todos los principales navegadores, decidió abandonar su versión no AJAX. Después de desplegar el nuevo carro de compras, un gran número de quejas ingresó en el correo electrónico de soporte de la compañía.

Este es un ejemplo ficticio, pero muestra puntos importantes. Aunque ninguna computadora nueva vendrá con un navegador que no se pueda usar con AJAX, muchos dispositivos móviles seguirán utilizándolo. Si su sitio tiene una amplia base de usuarios, requerir AJAX puede excluir a una parte considerable de su público.