Ayer tuve la ocasión de experimentar sufrir un proceso de compra de entradas a través de Internet, de esos que te dejan la duda existencial:

¿Realmente les interesa que la mayor cantidad de usuarios puedan comprar por Internet, o piensan que no es justo que la cosa sea tan cómoda, y ponen algunas dificultades para que el usuario demuestre que merece el privilegio?

En concreto me refiero a la compra de entradas para el Pamesa Valencia de baloncesto. Además de algunas cuestiones más o menos obvias (por ejemplo, usar una dirección numérica en la URL no da mucha confianza a la hora de realizar una transacción económica), la selección de la zona del pabellón utiliza esta imagen como ayuda:

Sí, este es el tamaño real de la imagen, y sí, los números de la parte inferior de cada zona son los que sirven para identificarla a la hora de seleccionar las entradas. Difícil, ¿verdad? Ahora preguntad conmigo: ¿qué les costaba poner la imagen un poco más grande, o al menos, los dichosos numeritos? ¿Qué necesidad había de forzar a los usuarios a utilizar una lupa o dejarse varias dioptrías en el proceso de elegir la sección?

Y si al menos se pudiera seleccionar la zona haciendo click sobre ella… pero no. Es necesario leer intuir el número y utilizar el enlace correspondiente.

Y eso no es todo. (sigue …)

Leo en torresburriel.com una referencia a un artículo sobre los problemas de usabilidad que pueden provocar las aplicaciones o componentes software de terceros; es decir, piezas de software que no pertenecen a la plataforma original y que son desarrollados por separado. Por ejemplo, esa encuesta o ese juego que insertas en tu página web, o tus últimas fotos, etc.

En este caso el peligro es que normalmente tenemos menos control sobre esos componentes, y por tanto su usabilidad puede estar bastante más descuidada que la de la aplicación en la que están insertados, del que tenemos mayor control, y al que prestamos mayor atención.

Para evitar esos peligros, nos ofrecen 3 consejos:

1. Negociar en los acuerdos que se mantengan los estándares de usabilidad.
2. Incorporar tus estándares de usabilidad como requisito obligatorio para integrar aplicaciones de terceros.
3. Trabajar junto con tu proveedor para fomentar la usabilidad como requisito en su proceso de desarrollo.

Ambos artículos y los consejos (que, dicho sea de paso, parecen un tanto redundantes) me provocan algunas reflexiones: (sigue …)

Recuerdo cómo un compañero de trabajo, en medio de una conversación informal, se cuestionaba que habitualmente se incluya al correo electrónico dentro de las llamadas “nuevas tecnologías“, cuando es un sistema que tiene ya más de 40 años de existencia; razón no le faltaba.

Aún así, tengo la impresión de que el correo electrónico, a pesar de ser una herramienta de trabajo y entretenimiento básica para muchos millones de personas, está todavía lejos de ser una tecnología totalmente desarrollada en todo su potencial.

Las novedades más llamativas suelen ser más cuantitativas que cualitativas, ofreciendo más espacio o mejores buscadores (como en el caso de GMail), útiles pero no revolucionarias.

Y no me refiero ya al problema del spam (que puede ser desde curioso para algunos a exasperante para otros muchos), sino a que lleva muchos años funcionando básicamente del mismo modo, sin incluir avances o mejoras dignas de grandes menciones. Puede que no las echemos en falta porque estamos ya muy acostumbrados a su funcionamiento, pero considero que todavía están por implementarse las mejoras definitivas que harán del correo electrónico una herramienta mucho más útil y potente. Estas son algunas de ellas.

“Para” y “Cc:” parecen lo mismo, pero no lo son

En la práctica, ambos campos son utilizados de modo indistinto, ya que su efecto es el mismo: el destinatario recibe el mensaje. Pero los campos de destinatario (”Para:”) y con copia (”Cc:”) deberían estar más diferenciados, sobre todo en la “bandeja de entrada” de los receptores del mensaje. Los mensajes en los que eres el destinatario directo reclaman, en principio, mucho más tu atención que aquellos de los que simplemente recibes una copia. ¿Y si los primeros aparecieran resaltados o, simplemente en bandejas de entrada diferentes?

Ahora mismo, al enviar un mensaje para múltiples personas, no pensamos demasiado si colocamos una dirección en un campo u otro. Pero conocer que la recepción va a ser diferente en cada caso, nos permitiría distinguir claramente las personas que realmente son los destinatarios de la información, de aquellos que únicamente tienen que estar al corriente.

Casi podríamos simplificarlo así:

• Para: “tienes que leerlo” (y, posiblemente, contestar o hacer algo)
• Cc: “tienes que saber que se ha enviado”

(sigue …)

Más de una vez nos sorprendemos cuando, al buscar utilizando Google, los primeros resultados corresponden a páginas con contenidos escritos, no en inglés, sino en español (o en el idioma de la interfaz establecido en las preferencias de idioma de Google y que afecta al idioma de los consejos, de los mensajes, etc.).

Por ejemplo, busquemos ‘Firefox‘ en www.google.es, en páginas escritas en cualquier idioma, pero con la interfaz de Google configurada en español:

Vemos que aparecen antes los resultados de páginas en español que las del sitio oficial “central” en inglés. Sin embargo, en las opciones de búsqueda NO hemos limitado a páginas en un idioma concreto, y parece seguro que las páginas en inglés son más relevantes (cosa que se puede comprobar con esta búsqueda). Otros usuarios han destacado, en diferentes foros, ese mismo funcionamiento.

Al parecer, el orden de los resultados (en lo que respecta al idioma) puede depender tanto del idioma de la interfaz como del servidor Google concreto que se utiliza (google.com vs. google.es) e incluso, de la geolocalización del usuario (es decir, el orden de los resultados será diferente buscando desde un ordenador en España o desde uno en Estados Unidos). Y posiblemente también dependa de la localización geográfica del sitio que haya indicado su webmaster.

(sigue …)

Leo en los últimos días la enésima discusión sobre usabilidad vs. accesibilidad; sin ir más lejos, en Accesibilidad, Usabilidad y Estandares Web, en Inclusión, o en la lista de correo Cadius.

La cosa suele empezar con una afirmación o pregunta sobre si:

• La usabilidad es parte de la accesibilidad.
• La accesibilidad es parte de la usabilidad.
• Usabilidad y accesibilidad son complementarias.
• Usabilidad y accesibilidad apuntan, en ocasiones, en sentidos opuestos.

Y después siguen definiciones más o menos formales, casos prácticos y visiones personales que suelen acabar por agotamiento más que por llegar a alguna conclusión.

Sinceramente, creo que se trata de un debate poco productivo, del que se pueden sacar pocos resultados útiles o prácticos. Y lo creo porque la cosa es bastante más sencilla que todo eso.

¿Para quién?

Huyendo de definiciones universales y cuestiones metafísicas, hagamos un ejercicio de simplicidad y digamos que:

• accesible = que se pueda acceder a ello
• usable = que sea fácil de usar

A partir de ahí, las conclusiones son bastante sencillas:

• Accesible o usable son términos relativos. Cuando los veamos utilizados de modo absoluto (”la página X es accesible”, “el sitio web Y es poco usable”) deberíamos siempre hacernos la misma pregunta mental: “¿accesible/usable para quién?”
• Para que algo sea fácil de usar, es necesario que se pueda usar. Por eso, para un mismo perfil de usuario, usable implica accesible (pero no al revés). O dicho de otro modo, la accesibilidad es condición necesaria (pero no suficiente) para la usabilidad.

Así de sencillo.

Otra cosa es que se pueda discutir, por ejemplo, que una interfaz sea más usable para un perfil de usuario, pero menos accesible para otro perfil de usuario.

Por ejemplo, ¿es la interfaz AJAX de Google Mail más usable que la versión simple HTML? Casi todos estaremos de acuerdo en decir que sí, para los usuarios con navegadores que soporten JavaScript. Para el resto de usuarios no tiene sentido preguntar si es usable cuando simplemente no pueden acceder a ella (por eso necesitan una versión alternativa).

En resumen, muchas de esas discusiones pierden su sentido si no se responde a la pregunta “¿para quién?”.

La semana que viene asistiré a dos jornadas del User Experience 2007, que se celebra en Barcelona del 4 al 9 de noviembre. Este evento, organizado por el Nielsen Norman Group, es uno de los más importantes a nivel mundial en el tema de interfaces de usuario.

Resulta difícil elegir únicamente dos charlas de todas las que tendrán lugar, y que se antojan todas más que apetecibles; inicialmente, estas son a las que asistiré:

• El martes 6, Designing Multi-User Services: Lessons from Social Psychology (John Boyd). Puede ser interesante conocer cómo se comportan los usuarios ante los interfaces de usuario desde un punto de vista psicológico y no tanto técnico.
• El miércoles 7, Application Usability 2 (Chris Nodder). Por lo que he leído, es posible asistir a esta segunda parte (en la que se explicarán procesos de diálogo, tareas y workflows de interacción) sin hacerlo a la primera (en la que se tratarán los elementos de interacción individuales).

¿Nos vemos allí? Espero escribir algo sobre el evento en el blog del grupo SQUaC.

Casi todos los que nos hemos dedicado en algún momento al desarrollo de aplicaciones reconocemos la importancia de mantener separados el contenido y la presentación; es decir, independizar qué hace la aplicación de cómo lo muestra al usuario. Yendo un paso más allá, el patrón MVC propone una separación del software en tres partes:

• Modelo (model): la información con la que trabaja la aplicación (”los datos”). Habitualmente esta parte está soportada por un sistema de base de datos.
• Vista (view): cómo interacciona el usuario con la aplicación (”la interfaz”). En una aplicación web suele utilizarse HTML y CSS.
• Controlador (controller): las acciones que realiza la aplicación (”el comportamiento” o “la lógica”).

Muchos frameworks de desarrollo siguen este patrón, ya que las ventajas de esa separación son múltiples: la aplicación resulta más modular, más flexible, facilitando cambios en una de las partes sin necesidad de modificar el resto.

Por ejemplo, una aplicación desarrollada siguiendo ese patrón permitiría fácilmente cambiar el gestor de base de datos (el modelo) sin necesidad de modificar el resto de la aplicación; o desarrollar cada una de las partes de modo independiente; o acceder a la misma aplicación desde diferentes dispositivos como navegadores web o móviles, simplemente creando diferentes vistas.

¿Este patrón no queda del todo claro? ¿Sus ventajas no resultan tan evidentes? Puede que lo comprendamos mejor si establecemos un símil con algo que casi todos conocemos: la estructura de los teléfonos móviles.

(sigue …)

Usually, submit buttons in web forms should be clicked just once; but many users click them twice or more. Why?

• Because they’re used to launch actions by double clicking (as on Windows icons).
• Because the server doesn’t replies instantantly, and they click again “just to see if something happens”.

What’s the result? The form data is sent twice to the server, and users usually don’t realize it; they just get the response to one of the submits. Try this simulation to see what happens when submitting several times the form before the server response arrives:

This is not a big issue if it’s, for instance, a search form: the query is being launched twice but the user simply gets the result. It may be annoying if someone is receiving the same mail several times just because users are submiting several times the contact form. And it’s a real big problem when the user is submiting a payment (you can be pretty sure they don’t want to pay twice the same object!).

The solution

There’s an easy solution for that problem! Simply disable the button just after the form is submitted, and you can change the button text too. The result is something like this:

This is done using the onsubmit form event:

<form onsubmit="document.forms['formname'].submitbutton.disabled=true;
document.forms['formname'].submitbutton.value='Sending...';" action="action" name="formname">
<!-- some form controls -->
<input type="submit" value="Send" name="submitbutton" id="submitbutton" />
</form>

With this technique, you achieve two positive effects:

• avoiding the double submit problem; and
• giving feedback to the user confirming the submit

Of course, there’s no perfect solution. If JavaScript is disabled at the browser, it doesn’t works; if it’s really important avoiding multiple submits (for instance, when it’s an economical transaction), it should be done at server’s level.

It’s really simple to use and without negative effects. Try it if you are really tired of multiple submits and tell me how it goes!

Hace algunos días, buscando información sobre un libro, me encuentro con esta pantalla de error en una conocida librería virtual:

Un tanto intimidatorio, ¿no os parece? El mensaje de error es muy poco informativo; el usuario se encuentra bastante perdido: ¿”Razones técnicas”? ¿Qué puedo hacer ahora? ¿Volver a intentarlo? ¿Debo avisar a alguien?

Es fácil encontrar artículos y recomendaciones a la hora de diseñar pantallas y mensajes de error, y es conveniente tenerlos en cuenta en el diseño de una aplicación web, algo que muchas veces olvidamos; ¿cuántas veces nos encontramos, navegando en algún sitio de Internet, con las páginas de error por defecto que ofrecen información escasa y puramente técnica?

Sin embargo, para lo que no existen recetas mágicas es para la selección de las imágenes que acompañan a los mensajes. No es mala idea incluir un elemento gráfico que indique de manera casi instantánea y clara que algo no esperado ha ocurrido; pero la imagen elegida en este caso resulta casi agresiva. De hecho, parece más adecuada a un error de tipo “acceso no permitido”.

Más útil habría sido ofrecer al usuario, además del mensaje de error, más información y/o alguna acción alternativa: ir al “mapa del sitio”; contactar y comunicar el error; etc. Y una imagen algo más amable no sería una mala idea.

Tras una fase de pruebas, Microsoft ha lanzado su nuevo buscador. Para empezar, el nombre es confuso; su dirección es Live.com, y parece que ese es el nombre que se está extendiendo. Sin embargo, el nombre oficial (el que aparece en la página), parece ser Live Search (bajo la marca Windows Live).

Siempre es problemático utilizar un nombre que no coincide con la URL; los usuarios acaban ignorando el nombre oficial y usando directamente la URL para referirse al sitio. Además, no cabe duda de que los usuario se resistirán a utilizar el término “Windows” para un servicio web, que por definición no está sujeto a ningún sistema operativo en particular. ¿Pretende Microsoft “windowizar” Internet? Aunque eso es otra historia; veamos su interfaz.

(sigue …)

Me he dado cuenta de que en los 3 ó 4 ordenadores con Windows que utilizo habitualmente, he terminado por colocar la barra de tareas en vertical, en la zona izquierda del escritorio. Más o menos así:

Es cierto que, sobre todo al principio, resulta un tanto extraño no encontrar el botón de Inicio en la esquina inferior izquierda. Pero al final las ventajas se hacen notar, y yo diría que son las siguientes: (sigue …)

Leo que la semana pasada el Govern de les Illes Balears puso en marcha un nuevo portal para “realizar gestiones, pagar impuestos y multas municipales por vía telemática a través del portal de tributos locales”. La dirección es www.contribucions.org, y en la nota de prensa se destaca, entre otras cosas, su alto nivel de accesibilidad.

Dado que “en este mundo no hay cierto, salvo la muerte y los impuestos”, y como prácticamente todos somos posibles usuarios del portal, no está de más comprobar si es realmente usable y accesible.

(sigue …)

Esta semana se ha publicado en Usolab un artículo mío titulado Usando AJAX en la banca por Internet.

Usolab es una empresa consultora en usabilidad con la que mantengo contacto y he hecho alguna que otra colaboración.

El artículo en cuestión incluye una demo funcional como ejemplo de lo que podría ser un extracto de movimientos financieros en una aplicación de banca por Internet, utilizando la tecnología AJAX; también se anuncia el artículo en su weblog.

Para los menos iniciados, os cuento que AJAX es el nombre que recibe una combinación de tecnologías que permite que las aplicaciones web refresquen la información sin cargar páginas nuevas. Las aplicaciones más conocidas que utilizan AJAX son las de Google: Google Maps y GMail.

Os invito a que leáis el artículo, tanto a los iniciados en estas tecnologías como a los que seáis usuarios de la banca por internet o, simplemente, tengáis cierta curiosidad

NOTA: El artículo ha sido publicado en Barrapunto, y también Enrique Dans lo ha mencionado en su blog, sugiriendo la posibilidad de que las entidades bancarias utilicen estas nuevas tecnologías para, por ejemplo, personalizar la página de entrada o aumentar la seguridad de la banca online.

Una de las características fundamentales de lo que conocemos como World Wide Web (WWW o simplemente “la web”) es la posibilidad de relacionar información que se halla situada diferentes documentos o páginas. Y en un navegador web, la manera de indicar que los elementos tienen información relacionada en otros documentos es mediante los enlaces (vínculos, hipervínculos, links) que todos vemos y utilizamos en páginas de Internet.

A pesar de que no se definiera formalmente, desde el momento de la creación de la WWW el estándar “de facto” para la visualización de enlaces textuales es la utilización de texto azul subrayado como este:

En el origen de la World Wide Web los enlaces se mostraban azules y subrayados.

Adicionalmente es habitual que los enlaces cambien de color una vez han sido utilizados para que el usuario distinga qué páginas ha visitado anteriormente. De hecho, los estándares de usabilidad aconsejan utilizar ese formato para los enlaces de modo que sea fácil y rápido identificar qué elementos de la página tienen información relacionada (en otras palabras, “dónde se puede hacer click“).

No obstante, este estándar tan sencillo se ha quedado corto. El enorme crecimiento de la WWW tanto en tipos de contenido como en modos de interacción con el usuario hacen necesario (e inevitable) que aparezcan nuevas técnicas de visualización de enlaces.

(sigue …)

(esta es una actualización de un artículo anterior escrito hace algún tiempo)

Desde hace varias semanas varios meses, mi página de Google tiene más o menos este aspecto:

Más completo que la habitual, ¿verdad? Desde cualquier ordenador conectado a Internet (después de poner mi usuario y contraseña, claro), en una misma página puedo consultar mi correo electrónico, las noticias de los temas que más me interesan, el tiempo que hace en mi ciudad, las últimas entradas en los weblogs que consulto habitualmente… Ah, y por supuesto, puedo seguir buscando en Google.

Si todavía no conoces y/o utilizas este servicio de Google, puedes hacerlo fácilmente siguiendo estos pasos; (si eres muy impaciente, prueba directamente el paso 4):

(sigue …)