Categoría 'interfaces'

Si diseñar interfaces fuera algo trivial, no existirían entonces las inconsistencias de las que hablaba (o, mejor dicho, dibujaba) Mauro Entrialgo en su blog hace ya algunos meses:

Tira de Mauro Entrialgo

Ya véis: diseñar una interfaz no es simplemente poner botones para todas las funcionalidades del aparato, sino que debe tenerse en cuenta el modelo mental del usuario de ese sistema.

¿Y qué es el modelo mental? Pues no, no consiste en imaginarse a Adriana Lima, sino que es la imagen del sistema que tiene el usuario en su cabeza; o, dicho de otro modo, cómo cree que funciona; los problemas vienen cuando el modelo mental no se ajusta al funcionamiento real. Y todo eso teniendo en cuenta que ese modelo no depende únicamente del diseño de la interfaz, sino también de experiencias anteriores.

Por eso, el modelo mental en el caso de la televisión es sencillo y se ajusta a su funcionamiento: "quiero que el volumen esté más alto [o más bajo]: si pulso el botón 'subir', subirá el volumen [si pulso el botón 'bajar', bajará el volumen]". Cuando el modelo mental se corresponde con el funcionamiento del sistema, no hay problemas.

En el caso del ascensor la cosa se complica un poco: "quiero ir al piso X: si está por encima, pulso el botón 'subir'; si está por debajo, pulso el botón 'bajar'". Esto obliga al usuario a hacer el (pequeño) esfuerzo mental de traducir el piso al que quiere ir (su verdadera intención) a la acción de subir o bajar. El modelo mental se ajusta bastante bien al funcionamiento del ascensor, en este caso muy reforzado por experiencias anteriores. Pero si nos encontráramos por primera vez ante un panel de botones de un ascensor, ¿tendríamos claro que el botón "bajar" es para ir hacia abajo, y no para que el ascensor baje?

El caso de la calefacción es el más complejo y estoy seguro de que muchos de nosotros nos encontraríamos con problemas ante un mando así. A no ser que tengas experiencias anteriores con sistemas parecidos, el usuario podría aplicar un modelo mental similar al caso de la televisión: "quiero que suba [baje] la temperatura: si activo el sol=calor [nieve=frío], subirá [bajará] la temperatura". Una interpretación incorrecta que, encima, será difícil de detectar debido a que la respuesta del sistema subiendo o bajando la temperatura no es inmediata.

Lo más llamativo de muchas interfaces poco usables, como esta última, es que detectarlas puede ser más o menos difícil, pero corregirlas puede ser muy sencillo. En la calefacción, como decía el dibujante de Dilbert, sería mucho más sencillo que el usuario simplemente indicara la temperatura que desea, y fuera el sistema el que decidiera si necesita subir o bajar la temperatura.

Seguro que recuerdas Supernanny, ese programa de TV en el que una psicóloga aconsejaba a diferentes padres (habitalmente al borde de la desesperación) en cuanto a la educación de sus hijos.

Quizás te sorprenda, pero podemos extraer algunas lecciones de su modo de actuar aplicables al desarrollo de software. Y si no, veamos cuál es la estrategia de Supernanny:

• Observar el funcionamiento actual, sin intervenir en él.
• Anotar los problemas detectados y su posible solución.
• Exponer y aplicar esas soluciones al caso real.
• Comprobar la efectividad de las soluciones.

¿Creéis que Supernanny sería tan efectiva si, en vez de proceder así, esperara a que los padres acudieran a su despacho, le expusieran el problema, y ella les diera una solución sin ni siquiera conocer a sus hijos? Parece obvio que no.

Entonces ¿por qué no seguimos el mismo esquema en el desarrollo de software? Habitualmente esperamos que el cliente nos cuente sus problemas, y nosotros desarrollamos la solución, muchas veces sin conocer en entorno de trabajo ni a los usuarios.

La técnica equivalente a lo que hace Supernanny en el ámbito del Diseño Centrado en el Usuario (y en otras muchas disciplinas) suele ser conocida como "estudio de campo".

Y es que, si bien es cierto que no hay dos niños iguales, lo mismo ocurre con los usuarios y sus situaciones. Y sí, seguro que Supernanny nos ayudaría con muchos clientes.

Leía la semana pasada en Menéame que Google ha conseguido la patente del diseño de su home (página inicial). Mucho se ha escrito ya sobre las patentes (los casos del software y los medicamentos son, valga la expresión, "sangrantes"), aunque podríamos decir como resumen que, si bien en teoría existen para proteger las ideas originales y a sus creadores, en la práctica se convierten en un obstáculo a la innovación:

La creencia que sustenta la necesidad de las patentes y los derechos de autor es que, si no se les da una protección, el creador no va a innovar. "Pero debería ser algo obvio que es la competencia, y no el monopolio de ideas, lo que sustenta la creación", añade el economista.

El problema añadido es que, en este tipo de patentes, existe un factor negativo más, y es el que afecta a la usabilidad de las aplicaciones web.

Es innegable que muchos de los estándares de facto en Internet provienen de ciertos portales representativos como son Amazon, Ebay y, sobre todo, Google; si un diseñador tiene que crear un sitio web de comercio electrónico, de subastas, o un buscador esas son sus referencias, y antes de crear una interfaz totalmente nueva seguramente se inspirará (cuando no copie directamente) esas otras páginas.

Esto tiene como efecto positivo (si no es la causa) que los usuarios ya saben cómo utilizarlas, y no necesitan aprender cómo funciona cada una de ellas, para lo cual probablemente no tengan suficiente tiempo y/o interés.

Pero ¿qué ocurre si Google y otros sitios web empiezan a patentar y a hacer valer sus derechos sobre esos diseños? Los responsables de sitios web similares podrán optar por pagar los correspondientes derechos por utilizarlos, o bien tendrán que crear una interfaz totalmente distinta. Y esas son las malas noticias: cada sitio web tendrá entonces un aspecto y/o funcionamiento diferentes, y los usuarios tendrán que aprender cómo funciona cada uno de ellos.

Teóricamente esas nuevas interfaces podrían ser mejores que las existentes, pero pocas veces las mejoras se consiguen a través de una ruptura radical con lo existente sino que habitualmente provienen de mejorar lo que ya funciona.

Parece, pues, que en este caso los efectos negativos de las patentes no serían únicamente para los desarrolladores sino también para los usuarios, es decir, todos nosotros.

¿Cómo nos afectarán en la práctica esas patentes?

El término "usabilidad" se ha convertido (no hace falta decir que por desgracia) en uno de esos que, sin conocer exactamente su significado, se le cuelga a cualquier producto tecnológico para que parezca lo suficientemente sofisticado; otros que le han precedido ya no nos dicen nada: alta fidelidad, modular, multimedia, 2.0, … Casi forman parte de eso que algunos llaman economía de la cancamusa.

Por eso es importante no perder de vista cuál es su verdadero significado. Es fácil encontrar definiciones más o menos oficiales de usabilidad, pero podemos quedarnos con que se trata, básicamente, de que los productos sean fáciles de usar. Aunque quizás sea más ilustrativo señalar algunos casos en los que el término no se utiliza con propiedad.

(sigue …)

Mucho (incluso más de lo habitual) se ha hablado últimamente de Facebook y su interfaz. En muchas ocasiones, para criticar su nuevo diseño, incluso llegándose a afirmar que habían bajado las visitas un 25% como consecuencia de su nuevo diseño, lo cual da pie a algunas reflexiones:

• Hay que tener cuidado con las conclusiones precipitadas. Parece que en realidad lo que han cambiado básicamente son los accesos a las aplicaciones más utilizadas, pero el número de visitas globales no ha sufrido grandes cambios. Ya se sabe que hay mentiras, grandes mentiras y estadísticas…
• Incluso si fuera cierto que el nuevo diseño provoca menos visitas, ¿es necesariamente un factor negativo? Cabría la posibilidad de que el nuevo diseño fuera más eficiente, de modo que los usuarios necesitaran menos visitas para obtener las mismas funcionalidades.
• Cualquier nuevo diseño en una aplicación con un número de usuarios tan elevado va a provocar comentarios en contra; la inercia y la costumbre de sus usuarios es un factor a tener en cuenta. Antes de hacer un cambio así es necesario decidir si las mejoras de la nueva interfaz son suficientes como para contrarrestar esos factores.

Sin embargo, personalmente creo que los últimos cambios de interfaz no resuelven algunos de los problemas más profundos que afectan a Facebook.

(sigue …)

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

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?

(sigue …)

Si tiempo atrás ya me quejaba de algunos problemas de usabilidad en la compra de entradas del Pamesa Valencia de baloncesto, ahora me he encontrado con otros errores que resultan igual de irritantes; tanto como sencillos de evitar con un poco de buena voluntad o con algo aparentemente igual de escaso como es el sentido común.

Intentemos comprar una entrada con cierta antelación; en la página de venta de entradas se ofrece el calendario completo de la temporada, indicando en todos ellos la fecha y la hora concretas, eso sí, con un asterisco que explica:

(*) Pueden existir variaciones en fechas por retransmisiones de tv. o necesidades de competición. NO SE ADMINTEN (sic) ANULACIONES NI DEVOLUCIONES DE ENTRADAS.  

Un aviso del que podría decirse que se queda bastante corto, sobre todo teniendo en cuenta que en el calendario se incluyen, además de la liga regular, los partidos de play-off; es decir, "partidos en potencia" que dependen de la clasificación final y de los que todavía no se sabe quién va a participar, ni cuándo, ni contra quién. ¿Demasiada antelación, quizás?

(sigue …)

La versión en inglés de iGoogle ha empezado a ofrecer nuevas funcionalidades que, como suele ser habitual, se trasladarán a otros idiomas en los próximos días/semanas.

Las novedades consisten, básicamente, en dos aspectos:

Gadgets en pantalla completa

Los gadgets (mini-aplicaciones) que aparecen ahora en iGoogle tienen un nuevo botón que permite maximizarlos hasta ocupar la práctica totalidad del navegador. Esto no permite únicamente mostrar más contenido, sino que las funcionalidades disponibles también pueden verse ampliadas respecto de la versión reducida; como ejemplo, el gadget para GMail:

Barra de navegación en la zona izquierda

Las pestañas de la zona superior han sido sustituidas por una barra de navegación en la zona izquierda; además, cada pestaña puede ser expandida para mostrar toda la lista de sus contenidos.

Algo más que simples cambios estéticos

Aunque podría parecer que estos cambios son simples mejoras de la interfaz, el sentido en el que se dirigen puede apuntar bastante más lejos. Como ellos mismos declaran (las negritas son mías),

But this new navigation also reflects our belief that, over time, the web in general and iGoogle in particular will become more personalized but also more social — more focused on connecting us with our friends through shared online activities. We're working on a number of new features that address this mission. For instance, we're planning on integrating a chat feature into iGoogle, and we think you'll want to have easy, persistent access to it, just like you have on your Gmail page today.

In short, we want iGoogle to grow right along with the web. The newest iteration of this evolution may seem jarring to some people today, but we believe that over time, a better-organized and more socially connected iGoogle homepage will be essential to helping us all make the most of all that the web has to offer.

Es decir: pretenden añadir más funcionalidades a iGoogle que compiten con aplicaciones de escritorio (correo electrónico, chat, lector de feeds). Si, como muchos afirman, Google pretende convertir su navegador Chrome en un verdadero sistema operativo, ¿no parece que iGoogle será su escritorio?

Muchos habremos sufrido las incompatibilidades de algunos navegadores; pero este caso es especialmente curioso (y difícil de solventar).

Visto en esta URL; ¿se tratará de algún tipo de enfermedad autoinmune?

No olvidemos lo importante que es proporcionar buenos mensajes de error a nuestros usuarios cuando algo va mal, o te puede pasar algo como esto o esto.

Hoy jueves, 13 de noviembre, se celebra el Día Mundial de la Usabilidad (que este año está especialmente dedicado al tema del transporte). ¿Qué es usabilidad? Existen diversas definiciones más o menos formales, pero en pocas palabras es lo fácil (o difícil) que es usar un determinado producto tecnológico. Es una disciplina que se suele referir a las interfaces software (sobre todo a la tecnología web), pero que se puede aplicar en muchos casos. Por ejemplo, en un acuario…

(sigue …)