Google Mail

Un email para gente mayor

Una interfaz ultra-sencilla para los programas de correo electrónico facilitaría que personas de edad avanzada utilizaran ese sistema de comunicación. ¿Existe algo así?

Scott Adams es conocido por ser el autor de las tiras de Dilbert; pero además es una de las mentes más brillantes de las que he leído en Internet, como demuestra a menudo en su blog.

Precisamente en su blog publicaba hace ya algún tiempo el artículo E-mail for Senior Citizens (“E-mail para ciudadanos mayores”) en el que proponía un software que actuara como una capa de interfaz sobre los sistemas habituales de correo (como Gmail), ocultando los innumerables detalles y funcionalidades de esos sitios, ofreciendo a los usuarios de edad avanzada una interfaz muy, muy simple. Estas son las características que proponía:

  • Tres grandes botones: “LEER”, “ESCRIBIR” y “OTROS”.
  • No necesitar doble-click para ninguna acción.
  • Recibir únicamente correos desde direcciones existentes en su agenda, evitando así el spam.
  • Abrir automáticamente los anexos.

Por supuesto, otros usuarios podrían realizar tareas de soporte, como por ejemplo incluir nuevas direcciones en su agenda.

Scott Adams no es ningún experto en accesibilidad, pero vemos que, con un poco de sentido común y buenas intenciones, es posible idear un sistema que facilitaría que gente de edad avanzada pudiera comunicarse con sus allegados mediante el correo electrónico. Estoy seguro de que casi todos podemos pensar en alguien que conocemos que no utiliza actualmente el e-mail, pero que posiblemente lo hiciera si pudiera utilizar un sistema como el descrito más arriba.

La cuestión es: no parece que un sistema de ese tipo fuera excesivamente complicado de implementar. Entonces, ¿por qué no existe todavía? Y si existe, ¿por qué no es más popular? A veces las ideas más sencillas son las más poderosas.

Una de las tiras de Dilbert, protagonizada por su madre

D’oh! The attachment! A simple solution

A simple and easy solution to those forgotten attachments in e-mails. Hasn’t it happened to you?

Has this ever happened to you? You want to send a file to someone, so you write a nice e-mail explaining what it is; then you click the send button, and some minutes later you receive the reply: “ok, very nice, but … where’s the attached file?”.

Yes, you forgot to attach the file. It’s a common but hard to avoid problem; a good rule is always attach the file before writing the e-mail, but aren’t there any better ways to avoid this?

Some systems, like GMail or Thunderbird, have options to alert you when you try to send an e-mail which includes specific words (“file”, “enclose”, “photo”, …) but has no attached files. It’s a nice idea, but far from perfect: you will still miss files if the system doesn’t detect these words, or you will get an annoying alert about an attachment you don’t want to send.

A simple solution

Here’s a simpler solution: the user gets notified of how many attachments the e-mail has when he/she is about to send the e-mail, not using annoying alerts but simply including that information in the send button, like this (GMail example):

Composing a message in GMail, with the button 'Send (0 attachments)' highlighted 

So when you are going to send the e-mail, you realize that the message has no attachments. Simple and effective, don’t you think so?

(more…)

Correo electrónico: esperamos más de ti

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

Símbolo de la arrobaRecuerdo 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”

(more…)

Usabilidad vs. accesibilidad: un debate vacío

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…

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.

'We care for usability' logo

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