Es fácil suponer que cualquier usuario de Windows ha sufrido en alguna ocasión problemas con ese sistema operativo que le han hecho sentir la necesidad de comprobar el valor de la aceleración de la gravedad mediante su ordenador. Uno puede preguntarse en esos casos “¿qué hará Bill Gates cuando le pasa algo así mientras utiliza Windows?“.

Eso es precisamente lo que se cuenta en seattlepi.com (comentado en español en Abadía Digital); el artículo incluye (también en un PDF de 5 páginas) un correo electrónico que, en 2003, Bill Gates hizo llegar a diferentes personas de Microsoft después de intentar él mismo instalar un determinado software (Windows Movie Maker); en él hace referencia expresa a la falta de usabilidad del proceso de instalación de software de Windows, y también del sitio web de Microsoft.

Es más, han incluido también un audio con la lectura dramatizada del correo, que es lo más parecido a escuchar al propio Bill Gates quejándose de Windows y de Microsoft. Imprescindible.

Cosas que llaman la atención

De toda esta historia, y suponiendo que no se trate de algo inventado (fake), me quedo con estos detalles:

• Bill Gates es humano, y a veces utiliza el ordenador para cosas tan mundanas como instalarse software. No tiene, como podríamos esperar de una de las personas más ricas del mundo, un grupo de esclavos que realicen esas tareas por él.
• No sólo es humano, sino que se interesa expresa y personalmente por temas de usabilidad. Eso está implícito en todo el contenido del correo, pero incluso hace mención explícita al final:

The lack of attention to usability represented by these experiences blows my mind. I thought we had reached a low with Windows Network places or the messages I get when I try to use 802.11. (don’t you just love that root certificate message?)

• La versión completa del mensaje (en el PDF) incluye los reenvíos y respuestas que se produjeron a partir del mensaje del “Gran Jefe”. También el resto de personal de Microsoft es humano, y la reprimenda llegada desde las alturas se traduce automáticamente en reparto de responsabilidades y de tareas a partes iguales (por supuesto, las “partes iguales” no incluyen al que hace el reparto). Casi estoy imaginándomelo como una tira de Dilbert.

¿Que hará Bill Gates ahora que se retira? ¿Comprarse un Macintosh?

Desde que realicé el proyecto final de carrera (Ingeniería informática en la UIB) sobre análisis de logs de servidores web (web data mining), me he preguntado por qué esa disciplina se trataba de un modo tan independiente (y habitualmente por expertos también independientes) al de la usabilidad web. Al fin y al cabo, ¿no se trata de conocer cómo utilizan los usuarios la web? Cuando se dicen cosas como “nuestros usuarios son así”, o “la mayoría de usuarios utilizan más esta funcionalidad”, ¿hasta qué punto se saben realmente?

Cualquiera que haya tratado mínimamente con las técnicas de análisis web sabe que extraer conclusiones del análisis de accesos es mucho más complicado de lo que podría parecer: filtrar bots, identificar usuarios únicos y sesiones,… Las técnicas que se utilizan son siempre heurísticas que dan resultados aproximados y que hay que saber interpretar.

Hasta que hace unos días he leído un artículo en el blog de Xperience Consulting que se plantea si ambas disciplinas son contrarias una a la otra. La respuesta es, obviamente, que no; no son opuestas, sino complementarias. Como dice Avinash Kaushik, la analítica web nos dice QUÉ están haciendo los usuarios, mientras la usabilidad web nos dice POR QUÉ lo hacen.

Por ejemplo, una herramienta de análisis web (como Google Analytics) nos puede indicar que un gran número de usuarios abandonan un proceso de compra de 4 pasos en el tercer paso, pero no nos dirá por qué. Para eso podemos hacer un estudio de usabilidad con usuarios reales y comprobar que no pasan de ese punto porque les obliga a introducir un dato que no entienden.

Sin embargo, en muchas ocasiones estas técnicas son explotadas de manera independiente: el departamento de Sistemas (o el de Márqueting) hace un análisis de los accesos, mientras que por otro lado el departamento de Desarrollo o Diseño web utiliza (si lo hace) técnicas de usabilidad web. Aunque parece que la cosa podría mejorar con nuevas metodologías de desarrollo.

(sigue …)

Leo un artículo en el blog de Ricardo Galli titulado Tratar al código fuente como un ensayo que me ha vuelto a crear una conexión entre dos temas que en principio parecen poco relacionados pero de los que se puede extraer alguna enseñanza común; en este caso, la programación y la redacción de textos para la web.

Ricardo habla de un libro (Beautiful Code) y, más concretamente, de un capítulo titulado como su artículo: Treating Code As an Essay. En él se señala la similitud entre el código fuente de un programa y un ensayo, en el sentido de que, si bien en ambos casos su propósito es lo fundamental (”¿de qué se trata?”; “¿qué hace?”), no debe descuidarse el estilo en que están escritos, ya que no sirven de nada si no pueden ser interpretados por seres humanos.

A continuación rescata algunas reglas generales para escribir código de calidad:

• Brevedad: La brevedad es una virtud, definitivamente hay un coste de lectura para el ojo humano, el código debe eliminar la información redundante
• Familiaridad: Las personas son más conservadoras de lo que pensamos. Las curvas de apredizaje elevadas creean estrés y reducen productividad. Un lenguaje no debe obligar a los progamadores a trabajar con conceptos nuevos y complejos. No ser demasiado innovador es también una ayuda para el “código bello”.
• Simplicidad: Si un programa es complicado de entender no puede tener belleza.
• Separar bloques: Separar los bloques lógicos en cada función, así se facilita la lectura más rápida y en “diagonal”.
• etc.

Inmediatamente me han venido a la memoria las reglas que da Jakob Nielsen para escribir para la web; de hecho, algunos de los puntos son prácticamente idénticos: simplicidad, brevedad, lenguaje familiar, etc. Y es que, pensándolo un poco, las situaciones no son tan diferentes:

(sigue …)

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 …)

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?”.

He hecho algunas modificaciones en los últimos días en la página; no son muy espectaculares ni de gran importancia, pero os las cuento.

El botijo

Para empezar, la más visible: he cambiado el logo de la página. El curioso botijo que podéis ver en la parte superior izquierda es una versión “regional” de la famosa tetera del libro de Don Norman, “The Design of Everyday Things“, y es una idea que le he tomado prestada a Juan Carlos García, de Úsalo. Se trata de un ejemplo exagerado de cómo los malos diseño nos complican la vida; imaginad el sinsentido de intentar utilizar una tetera o un botijo como esos.

Lo malo de no ser diseñador es que nunca consigues una realización tan buena como la que tienes en mente, pero para una página personal como esta me sirve de momento. Por supuesto, se aceptan opiniones

(sigue …)

Sometimes I have looked for an usability logo or icon, without luck. Hmmm, interesting! We have icons for almost every other issue, but why not for usability?

Let me suggest these:

Ok, usability specialists know icons and logos are overused in many sites, and they’re not really important for the user; it should be so natural than there’s no need to say “we care for usability”. Anyway, I think it would be a good idea having a logo to identify sites related to usability aspects, or maybe to identify sites that specially care about those issues.

The teapot is from Don Norman’s book ‘The Design of Everyday Things‘, and it’s sometimes used (with different designs) in presentations, web sites, etc. The ‘u’ is supposed to be the handle of the teapot so as to make it more usable. Wait! It’s not a great logo if I have to explain this

You get the idea, don’t you? Now, remember I’m not a graphic designer and leave your opinions in the comments (and feel free to use them if you want to, of course).

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.

Me escribe Jesús Hurtado, CEO de Kroonos, solicitándome que le ayude en la promoción de su web ya que pronto (el 31 de octubre) dejará de estar abierto el registro de usuarios; a partir de entonces, será necesaria una invitación. Una mención en este blog no le va a causar ninguna avalancha de visitas, pero aquí queda esto.

El sitio web se autodefine así:

Kroonos es una web 2.0 que te permitirá sacarle partido a tu tiempo libre. Un banco del tiempo global donde podrás dar y recibir ayuda de forma gratuita de otros miembros de la comunidad.

Por el momento no se puede acceder directamente a ninguna funcionalidad específica del sitio; ésta se puede intuir buceando en el foro, en el blog, etc.; pero la falta de algo más tangible posiblemente le resta cierto atractivo a la hora de registrarse. Eso sí; el concepto de una comunidad en la que los usuarios intercambian tiempo para obtener otras cosas a cambio suena lo suficientemente interesante como para tomar nota y seguir su evolución. Yo ya me he registrado.

En lo que respecta al diseño, sin hacer un análisis profundo (es decir, echando un vistazo), el aspecto de la página es bastante claro y agradable. En el caso de una web con un propósito tan original es de agradecer el texto que lleva por título “¿Qué es Kroonos?”, en el que se describe su objetivo, aunque como comenté anteriormente se echa de menos una visión más concreta de la funcionalidad que ofrecerá el sitio.

Por último, no puedo evitar que me venga a la memoria Momo, la novela de Michael Ende en la que unos misteriosos hombres grises se fumaban el tiempo de la gente. Seguiremos el desarrollo de Kroonos, aunque sea sólo para comprobar de qué otros extraños modos consume la gente su tiempo.

A menudo se dice que lo importante de lo que aprendes en la universidad no son los conocimientos técnicos concretos (esos que, sobre todo en informática, se convierten en obsoletos en cuestión de meses), sino una disciplina de trabajo, una base amplia de cultura, la experiencia…

Yo me quedo con unas pocas frases pronunciadas por los profesores, de esas que en el momento parecen triviales pero que tienen ocasión de volver a la memoria años después, acompañadas de un “pues sí que tenía razón, sí”.

Una de ellas fue durante una clase de Josep Miró Nicolau (catedrático emérito de la UIB y premio Ramon Llull de la Comunitat Autònoma de les Illes Balears), al que tuve como profesor de Inteligencia Artificial en diferentes años de mi Ingeniería en Informática; su mérito fue dar la mejor definición de progreso que conozco.

Durante una de sus clases, intentó escribir algo en una pizarra para apoyar su explicación. La pizarra consistía en uno de esos paneles blancos de plástico sobre los que se escribe con rotulador y, como suele ocurrir, el rotulador apenas tenía tinta. Lo intentó con un segundo rotulador de diferente color, pero tampoco escribía demasiado bien. Después de un tercer intento con otro color, sin éxito, se giró hacia nosotros, y nos dijo con tono resignado:

“¿Véis? Esto es el progreso. Antes escribíamos bien, pero con un único color. Ahora escribimos mal, pero con muchos colores.”

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!

Google Analytics has a nice new interface, much more intuitive and usable, but I still miss something I think it would be really usefull: an integrated calendar of events.

I can select a range of dates at Google Analytics and get different statistics: visits, unique users, etc. But there are many events (internal and external) that may affect that data. For instance:

• Changes at the site: contents, layout, etc.
• Changes in Google Analytics configuration (for instance, in filters)
• Google Adwords campaigns linking to that site
• etc, etc.

Any webmaster would be happy to know how those events are related to the statistics, wouldn’t they?

How could Google do that? We already have a solution: Google Calendar. So we simply would associate a site monitorized by Google Anlytics to a calendar in Google Calendar. A webmaster could add events to that calendar, and they would be shown at Google Analytics.

Here’s an example; this graph shows a decrease in the number of visits on June, 2nd:

Hmmm… What happened that day? Oh, maybe that new filter to exclude inner visits. With the feature I suggest, I would link the Google Analytics account with a Google Calendar which includes events related to the site, like this:

(sigue …)

Después de escribir sobre las características básicas de Twitter, voy a intentar dar un punto de vista más crítico sobre sus características.

Para empezar, el tagline de su web define perfectamente su propósito: “What are you doing?“; cualquiera sabe hacer eso: explicar qué está haciendo. Pero tengo la impresión de que su uso se está extendiendo más entre los usuarios técnicos y los interesados en analizarlo como fenómeno social, pero no tanto entre la gran masa de usuarios menos avanzados.

¿Por qué? Uno de los motivos parece obvio: no tiene soporte oficial para MSN Messenger. El cliente de Microsoft es el más extendido entre los usuarios “domésticos”; y a pesar de que el precedente inmediato de Twitter sea la línea de estado de Messenger, no parece sencillo que sus usuarios se pasen a otro programa de mensajería instantánea sólo por usar Twitter. Existen algunas alternativas third party para “twittear” desde MSN (como Twessenger), pero desconozco hasta qué punto funcionan correctamente.

Por supuesto, los usuarios de MSN Messenger pueden enviar y recibir mensajes de Twitter desde el navegador, pero es un acceso mucho menos directo que la mensajería instantánea. También utilizando el teléfono móvil, pero es menos sencillo de usar (y enviar SMS cuesta dinero).

Además de esto, hay algunas cuestiones de usabilidad en la web de Twitter que son mejorables.

(sigue …)