AJAX: Usabilidad Interactiva con Código Remoto (3ra Parte)

baluart15 Octubre 2005 - 1:51pm 3 comentarios
Enviar por Email Imprimir

El Scripting Remoto, conocido como AJAX, permite la interactividad rápida y poderosa de nuestras aplicaciones web, al poner en marcha una solicitud al servidor sin recargar la página web. Pero con este poder vienen las complicaciones en pro de la usabilidad.

Esto es lo que leeremos en este artículo, son 5 tips que hacen de nuestra aplicación ajax una aplicación más usable.

Este artículo es la traducción del mejor artículo de ajax que he leido hasta el momento. El artículo original lo tienes en el siguiente enlace:

AJAX: Usable Interactivity with Remote Scripting

Antes de leer este artículo te recomiendo leas:

  1. AJAX: Usabilidad Interactiva con Código Remoto
  2. AJAX: Usabilidad Interactiva con Código Remoto (2da parte)

Si todavía no tienes el código fuente, puedes descargar el archivo de ejemplo.

Ejemplo 2: Cree una interfaz usable con Scripting Remoto

El modelo de scripting remoto es absolutamente diferente de la interacción basada en una página común que se ve en la mayor parte de la Internet, y con esa diferencia vienen las nuevas habilidades de la usabilidad que se pueden introducir muy fácilmente en sus proyectos. Estas habilidades se muestran típicamente en la manipulación dinámica del interfaz mientras que el usuario está teniendo acceso, o de la necesidad de tener acceso a los datos que son externos a la página Web.

El ejemplo 1 usa el scripting remoto para validar el número del recibo, y para insertar automáticamente los datos que fueron recuperados de la base de datos; sin embargo, esta información no se utiliza correctamente, pues no es obvio para el usuario lo que esta ocurriendo. El ejemplo 2, en cambio, busca corregir esta y otras deficiencias, y brindar una experiencia más rápida, fácil y comprensible al usuario. Los cinco tips de abajo, explican algunos de los cambios que se pueden utilizar para convertir una mala experiencia en buena.

Tip #1: Diga a sus usuarios porqué están esperando

El scripting remoto no es instantáneo. Sin importar la velocidad de su conexión a Internet, el tiempo de comunicación con una fuente externa variará. Así pues, mientras transcurre la comunicación con el servidor, es imprescindible que usted diga al usuario porqué están esperando. (Por ejemplo PHP utiliza la función sleep()para provocar un período de espera en su código, causados por el gran tráfico de la red u otros factores.)

Como las aplicaciones de scripting remoto no hacen llamadas usando la interface común del navegador, la barra de estado – que usualmente notifica al usuario el estado y la actividad de las transferencias -- no funciona como lo hace normalmente, así tenemos que proporcionar nosotros mismos el feedback al usuario.

En el ejemplo 2, mientras el número de recibo está siendo verificado, explicamos la espera mostrando una etiqueta al lado del campo del número de recibo.

La etiqueta cambia indicando la culminación, una vez que la conexión XMLHttpRequest haya terminado.

El mensaje de estado se inicia justo antes de la conexión XMLHttpRequest, cuando el acontecimiento onchange para el campo de número de recibo es accionado:

receipt.onchange = onchangeReceipt;

function onchangeReceipt()
{
message(this, "loadingMessage", "Verifying receipt number");

/* Check for running connections */
if (requester != null && requester.readyState != 0 && requester.readyState != 4)
{
requester.abort();
}
...

Una vez que la operación de scripting remoto ha terminado, el mensaje se actualiza comunicando al usuario si el número del recibo fue válido o no:

function writeDetails()
{
if (requester.responseText.charAt(0) == "<")
{
message(receipt, "statusMessage", "Your receipt details were retrieved");
...

else
{
message(receipt, "errorMessage", "Please enter a valid receipt number");
...

La actualización del mensaje que indica el final es importante, pues proporciona el cierre para el usuario. Si el mensaje de carga simplemente desapareciera, los usuarios no estarían seguros de haber hecho lo correcto.

En los dos trozos de código anteriores, la función message es una función de encargo que dinámicamente crea una etiqueta de estado para un elemento del formulario, y se sitúa al lado del elemento conexo. Esta también acepta una clase para la etiqueta de estado, que permita usar estilos CSS para aplicarlos de manera diferente en los mensajes de carga, error y término:

function message(element, classString, errorMessage)
{
var messageDiv = document.createElement("div");

element.parentNode.insertBefore(messageDiv, element);
messageDiv.className = classString;
messageDiv.appendChild(document.createTextNode(errorMessage));

return true;
}

Cuando el proceso de XMLHttpRequest esta corriendo, la etiqueta se motiva a indicar que la acción está en curso y todavía viva. En el ejemplo 2, esto es realizado vía estilos CSS con un GIF animado, pero esto también podría ser efectuado usando una animación JavaScript.

La misma característica se aplica al botón de envío del formulario. Otra vez, esto alerta al usuario que se está arrancando una acción, y también les deja saber que presionaron el botón, lo que ayuda a desalentar a los usuarios a presionar el botón más de una vez:

Para alcanzar esto, cambie simplemente el valor y la clase CSS del botón Submit (Enviar):

submit.className = "submit loading";
submit.value = "Contacting server";

Tip #2: No interfiera con la interacción del usuario

Los usuarios se frustran con las interfaces que interfieren con el fin de su tarea. En el ejemplo 1, tal interferencia podría ocurrir después de que los usuarios hayan puesto el número del recibo: Si comienzan a llenar sus nombres y direcciones de correo electrónico antes de que se haya verificado el número del recibo, esos detalles serán sobreescritos una vez que sus datos de usuario se reciban en el servidor.

Para rectificar esto, el ejemplo 2 comprueba si el usuario ha cambiado los valores de los campos de texto antes de que el script incorpore cualquier dato de ellos. Los valores prefijados de los campos del texto se pueden detectar cuando la página se carga, y registrar usando la propiedad de encargo de DOM:

email.defaultValue = email.value;

El valor prefijado de un campo se puede comprobar en contraste de su contenido actual antes de que el script procure escribir cualquier dato en él:

if (email.value == email.defaultValue)
{
email.value = newValue;
}

Esto asegura que el usuario -- quién probablemente conoce mejor su nombre de lo que nosotros lo hacemos -- no tenga ninguna entrada que sobreescribir por la automatización entusiasta.

Algunos otros casos de interferencia que usted debe evitar incluyen el movimiento del cursor a otro campo mientras que el usuario está llenando uno, y el cierre del interfaz por el usuario (Este es el motivo por el cual el XMLHttpRequest se debe utilizar asincrónicamente).

Tip #3: Tome los errores temprano, pero no demasiado temprano

Es mejor coger los errores cuando estos ocurren. Muchos formularios que actualmente aparecen en Internet confían en el usuario para enviar el formulario antes de que se muestre cualquier mensaje de error, utilizando scripts de lado del servidor o alarmas de JavaScript poco elegantes (como en el ejemplo 1). Estos métodos tienen varias desventajas para el usuario:

  • El proceso de enviar el formulario requiere tiempo del usuario.
  • Las alarmas Javascript no marcan permanentemente todos los campos que requieren la corrección.
  • Indicar los errores después de que hayan sido enviados requiere que el usuario recuerde cual es el campo erróneo.
  • Incluso si los usuarios conocen los elementos del formulario que deben corregir, tendrán que enviar el formulario de nuevo, para averiguar si aquellos elementos han sido corregidos correctamente.

Por estos motivos, es mucho mejor informar a los usuarios de los errores en cuanto estos se produzcan. En el ejemplo 2, si los usuarios escriben una dirección de correo electrónico inválida, la aplicación les indica enseguida.

La indicación es colocada al lado del campo de correo electrónico, usando la función message() del Tip #1:

Sin embargo, usted no debe comprobar la validez en cuanto el usuario comienza a escribir, pues lo esta distrayendo – por no decir molestando - para decirle que ha cometido un error antes de que haya terminado de escribir sus datos. La comprobación del campo sólo debe realizarse una vez que el usuario haya escrito el último carácter, por ejemplo, cuando ellos se alejan del campo email. Para los campos de texto, este tipo de acción es mejor hacerla utilizando el evento onchange:

email.onchange = onchangeEmail;

La función que es activada por el evento puede comprobar el campo y asegurar que los datos que este contiene sean válidos para aquel tipo de datos:

function onchangeEmail()
{
if (!this.value.match(/^[\w\.\-]+@([\w\-]+\.)+[a-zA-Z]+$/))
{
field.valid = false;
message(field, "errorMessage", "Please enter a valid e-mail address");
field.className = "text error";
}

return true;
}

Tip #4: Avise al Usuario cuando haya cometido un error

Una vez que se ha encontrado un error en un campo y el usuario haya sido alertado del mismo, es igualmente importante avisarle cuando lo ha corregido, de otra manera el usuario estaría atrapado en el ciclo de envío del formulario.

En estas circunstancias, no es bueno esperar el evento “onchange” del navegador para activarlo, pues esto usualmente ocurre cuando el usuario “defocuses” (desenfoca) un elemento del formulario. Por lo tanto, lo mejor es usar el evento “onkeyup” para comprobar la corrección de un campo que estaba incorrecto:

email.onkeyup = onkeyupEmail;

La función onkeyupEmail() comprueba si el campo correo electrónico muestra un mensaje de error antes de proseguir a comprobar si el campo esta correcto o no. Así, en cuanto el usuario haga correcciones al campo, el mensaje de error desaparecerá; sin embargo, si el usuario escribe en el campo por primera vez, ningún mensaje aparecerá:

function onkeyupEmail()
{
/* If an error message is displayed */
if (this.message != null && this.message.className == "errorMessage")
{
if (this.value.match(/^[\w\.\-]+@([\w\-]+\.)+[a-zA-Z]+$/))
{
this.valid = true;

/* Remove error message */
message(this);

/* Remove error CSS class */
this.className = "text";
}
...

Estas líneas no niegan el caso en el que los campos obligatorios sean saltados. Es una buena idea permitir al usuario enviar un formulario incompleto, pues permite al programa destacar exactamente los campos que necesariamente debe n completarse, en vez de buscar detalles que aún no han sido llenados.

Tip #5: Proporcione una Interface de Feedback

La creación de una aplicación Web puede dejarte explorar nuevas funcionalidades que nunca hayan sido vistas en un navegador, por lo que debemos recordar los fundamentos de un diseño usable. Uno de los fundamentos es la provisión de una interfaz de feedback: Comunicar al usuario lo que ellos pueden hacer, y lo que ellos ya han hecho.

En el ejemplo 1, no es completamente claro los que los usuarios pueden hacer sobre las pequeñas gráficas ecard. Esto lo neutralizamos fácilmente si damos un contorno gris a la imagen sobre la cual el cursor es colocado encima.

La pseudo clase :hover es familiar a alguien que ha utilizado CSS. Esta pseudo clase CSS permite a un objeto cambiar su aspecto cuando el cursor es puesto sobre él. Aunque los efectos de mouseover teóricamente puedan ser logrados con CSS, algunas versiones de Internet Explorer no permiten ver los efectos :hover en ningún elemento excepto de los hiipervinculos. Por lo que para lograr el efecto sobre los elementos de imagen, en el ejemplo 2 utilizaremos los eventos onmouseover y onmouseout:

var cards = document.getElementById("ecardSet").
getElementsByTagName("img");

for (var i = 0; i < cards.length; i++)
{
cards[i].onmouseover = onmouseoverCard;
cards[i].onmouseout = onmouseoutCard;
}

Estos eventos pueden después cambiar la clase de cada imagen y permitir que proporcionemos la regeneración visual utilizando CSS:

function onmouseoverCard()
{
this.className = "hover";

return true;
}

function onmouseoutCard()
{
this.className = "";

return true;
}

Cambiar el cursor para indicar la posibilidad de hacerle clic, nos puede ayudar a proporcionar información al usuario. Esto se puede hacerse usando una regla simple en el CSS:

img.hover
{
cursor: pointer;
}

Conclusión

Después de la realización de todos estos cambios al ejemplo 1, el ejemplo 2 tiene una aplicación mucho más provechosa y usable.  

El tema común entre los tips ofrecidos aquí es siempre hacerle sentir al usuario más cómodo y en el control. Si los usuarios no poseen la información que necesitan para entender como proceder, ellos verán su aplicación con preocupación, y en consecuencia su performance se verá afectada.

Aunque este artículo esta enfocado principalmente sobre el proceso de scripting remoto y sus utilidades, también se debe tomar en cuenta la accesibilidad al momento de crear una aplicación Web.

El ejemplo 3 es una versión mucho más compleja del uso de ecard. Utiliza un código más poderoso y lo muestra de manera accesible a los usuarios que no utilizan JavaScript o sin XMLHttpRequest. Una vez que usted ha dominado las técnicas descritas, usted podrá echar una mirada a este último ejemplo y comenzar a hacer sus aplicaciones realmente sólidas.

Comentarios

Imagen de a677dar
a677dar

Excelente articulo!!Lejos, es el mejor articulo en español sobre AJAX que en este momento existe en la red. Los felicito!

Imagen de Eidher
Eidher

NO SE VEN LAS IMAGENES

Imagen de richard_s
richard_s

hola

Dejar comentario

Tutoriales

Cómo descargar videos de VK.com
En este artículo voy a explicar como descargar videos y películas...
Descargar Facebook Móvil Gratis
Por si aún no lo han hecho, es posible descargar Facebook Móvil...
Cómo generar tráfico web con las redes sociales - Paso a Paso
Muchas empresas están publicando contenidos como la forma de crear...

Artículo Recomendado

3 Tips cruciales para recuperar archivos eliminados
¿Te imaginas perder el trabajo de toda una semana en tan solo unos segundos? Todos hemos pasado por este problema. Quizás eliminamos por error un archivo importante o lo borramos sin pensar que era valioso para otro... más