El Valle inquietante del diseño de interfaces de usuario, por Bill Higgins

Cyborg_2009_9,.jpgHay una teoría llamada “El valle inquietante” sobre la respuesta emocional de los humanos hacia los robots “casi humanos”. De la entrada de la Wikipedia: La teoría del valle inquietante es un principio de la robótica sobre las respuestas emocionales de los humanos hacia los robots y otras entidades no humanas. Fue descrito por el robotista japonés Masahiro Mori en 1970 […].

Este principio dice que la respuesta emocional de un humano hacia un robot hecho en apariencia y comportamiento muy similar al humano, incrementará positivamente y de forma empática, hasta alcanzar un punto en el que la respuesta emocional se vuelve de repente fuertemente repulsiva. Cuando la apariencia y comportamiento (del robot) se vuelven indistinguibles al ser humano, la respuesta emocional vuelve a crecer de forma positiva y se va aproximando a niveles de empatía como los de entre humanos.

Este bache o valle de respuesta repulsiva entre un robot con apariencia y comportamientos “casi humanos” y una entidad “totalmente humana” es lo que llamamos valle inquietante. El nombre surge de la idea de que un robot que es “casi humano” es visto de forma general por un ser humano como “extraño” y por esto resulta imposible alcanzar el requisito de una respuesta empática para la necesidad de una interacción humano-robot productiva.

finalfantasy1.jpgAunque la mayoría de nosotros no interactúa con robots de aspecto humano tan a menudo como para aceptar o rechazar esta teoría, muchos de nosotros hemos visto películas como Polar Express o Final Fantasy: The Spirit Within, que utilizan personajes humanos realistas generados por ordenador (por oposición a los de estilo dibujo animado). Aunque los cineastas ponen mucho cuidado en hacer que las expresiones y movimientos de los personajes repliquen aquellas de los actores humanos, muchos espectadores encuentran estos casi-pero-no-del-todo-humanos desasosegantes o incluso escalofriantes.

El problema es que nuestros cerebros tienen un modelo de cómo los humanos deberían comportarse y los pseudo-humanos, ya sean robóticos o generados por ordenador, no encajan en ese modelo, produciendo una sensación inquietante – en otras palabras, sabemos que hay algo que no es correcto – incluso aunque no sepamos articular exactamente qué es lo que está mal.

homero-simpsons-homer.jpg¿Por qué no sentimos la misma incomodidad cuando vemos unos dibujos animados como Los Simpsons, en el que los personajes están aún más lejos de nuestro concepto de humanidad? Porque en el entorno de los dibujos animados, aceptamos que los personajes no son en absoluto humanos – son personajes de dibujos animados y son consistentes con su entorno animado. Igualmente, sería irritante que un humano entrara en el fotograma y se pusiera a interactuar con los Simpsons, porque dieciocho años de dibujos de los Simspons y ochenta años de animación en general han condicionado que no esperemos que ocurra tal cosa [Nota al pié 1].

Aquí tenemos una lección para los diseñadores de software, y una de la que he hablado recientemente – debemos asegurarnos de que nuestro diseño de aplicaciones es consistente con el entorno en el que funciona nuestro software. En términos más concretos: una aplicación para Windows debería tener el aspecto y comportamiento de una aplicación para Windows, una aplicación para Mac debería tener el aspecto y comportamiento de una aplicación para Mac, y una aplicación web debería tener el aspecto y comportamiento de una aplicación web.

¿Te parece obvio? Estoy de acuerdo en que los diseñadores de software y desarrolladores generalmente observan esta regla excepto en medio de un cambio de paradigma tecnológico. Durante periodos de rápida innovación y exploración, es tentador y más aceptable violar las expectativas de un entorno particular. Sé que es una afirmación genérica y abstracta, así que dejadme respaldarla con algunos ejemplos.

¿Alguien recuerda Active Desktop? Cuando Bill Gates se dio cuenta de que la web era algo importante, dirigió todo Microsoft a integrar la web en todos los productos de software de Microsoft. Active Desktop fue una característica que hacía que el escritorio de Windows pareciera una página web y permiera a los usuarios iniciar la acción por omisión en un archivo o carpeta, a través de un único clic en una especie de hipervínculo en vez del tradicional doble clic. Uno de los problemas con Active Desktop era que rompía las expectativas de los usuarios sobre interactuar con archivos y carpetas. Cambiar del doble clic al clic sencillo cambiar sutilmente otras interacciones como arrastrar y soltar, seleccionar y renombrar. La única razón por la que recuerdo esta característica es porque hubo montones de personas que me pidieron que la desactivara.

desktop2xr.jpg

Otra tecnología que cambiaba las reglas del juego en la década de 1990 fue la plataforma Java. La atracción de Java fue que la sintaxis del lenguaje se parecía mucho a C y C++ (que muchos programadores conocían) pero era (en teoría) “escrito una vez, funciona en todas partes” – en otras palabras, multiplataforma.

Aunque Java conquistó el mundo de los servidores, nunca despegó en los escritorios como muchos predijeron que haría. ¿Por qué no despegó en los ordenadores de escritorio? Mi propia experiencia usando las aplicaciones con interfaz GUI de finales de la década 1990 es que eran muy lentas y que tenían un aspecto y comportamiento irregular frente a la aplicación estándar de Windows (o Mac o Linux). Esto ocurría porque no eran auténticas aplicaciones para Windows/Mac/Linux. Eran aplicaciones de Java Swing que emulaban aplicaciones Windows/Mac/Linux. A pesar de los hercúleos esfuerzos de los diseñadores e implementadores de Swing, no podían escapar del Valle inquietante de los interfaces de usuario emulados.

Eclipse y SWT utilizaron un acercamiento diferente a las aplicaciones de escritorio basadas en Java [Nota al pie 2]. En vez de emular widgets nativos de escritorio, SWT favoreció la delegación directa a los widgets nativos de escritorio [Nota al pie 3], resultando en aplicaciones que parecían aplicaciones de Windows/Mac/Linux en vez de aplicaciones Java Swing. La parte mala de esta decisión de diseño es que los desarrolladores de widgets de SWT debían portar manualmente un nuevo widget a cada entorno de escritorio soportado. Este plan de tiempo de desarrollo y de mantenimiento sólo sirve para enfatizar la importancia que los diseñadores de Eclipse/SWT atribuían al aspecto y al comportamiento nativo de las aplicaciones.

Al igual que las aplicaciones de Windows/Mac/Linux tienen un aspecto nativo, también deben tenerlo las aplicaciones basadas en navegador. Los widgets nativos de la web son elementos de HTML estándar – hiperenlaces, tablas, botones, campos de introducción de texto, selección de cajas y “span” y “div” coloreados. Hemos tenido herramientas para crear aplicaciones web más ricas desde los DOMs y Javascript 1.0 pre-estándar, pero hasta que no se han combinado la (semi)estandarización del DOM, la estandarización de-facto del XHR, las librerías emergentes, y aplicaciones de última generación ejemplares como Google Suggest y Gmail que han llevado a un segmento no trivial de la comunidad de desarrolladores de software a intentar UIs web más ricos, que nos hemos podido aglutinar bajo la bandera de ‘Ajax’ (¿o se llaman ‘RIA’ -Rich Internet Application?). Como la web y Java antes, la disponibilidad de la tecnología Ajax está provocando que algunos desarrolladores diverjan del aspecto y comportamiento de la web en favor de un estilo de interfaz de usuario que yo llamo “aplicación de escritorio en un navegador web”. Para ver un ejemplo de este estilo de aplicación Ajax, dedica unos minutos a ver esta demostración Flash de la suite de colaboración Zimbra.

gmail_image_2009.pngPara mi, Zimbra no recuerda en modo alguno mi modelo mental de aplicación web; recuerda a Microsoft Outlook [Nota a pié 4]. Por otro lado Gmail, que también es una aplicación de correo electrónico basado en Ajax, prácticamente corresponde exactamente con mi modelo mental de cómo debería comportarse y qué aspecto debería tener una aplicación web (capturas de pantalla). ¿Prefiero el aspecto y comportamiento de Gmail más que el de Zimbra? Sí. ¿Por qué? porque en los pasados doce años, mi mente ha desarrollado un modelo muy específico de cómo debería ser una aplicación web, y como Gmail se alinea con este modelo, puedo empezar a usarlo inmediatamente y lo experimento de una forma natural. Gmail usa Ajax para acelerar operaciones comunes (p.ej. autocompletado de direcciones de correo electrónico) y para activar la transferencia de datos sin necesitar refrescar la página (p.ej. refrescar los contenidos del buzón de entrada) pero el núcleo de su aspecto y comportamiento sigue siendo muy similar al de una página web tradicional. Desde mi punto de vista, esto no es una limitación; es una inteligente decisión de diseño.

Así que te recomiendo que si estás pensando en crear o estás creando aplicaciones Ajax/RIA, deberías tener en cuenta el Valle inquietante del diseño de interfaces de usuarios y reconocer que cuando creas una aplicación de “escritorio en el navegador“, estás violando las expectativas no escritas de los usuarios sobre qué aspecto debe tener y cómo debe comportarse una aplicación web. Esta elección puede tener un impacto significativamente negativo en la velocidad de aprendizaje, disfrute en el uso y en la adopción. El hecho de que puedas crear aplicaciones web que se parecen a aplicaciones de escritorio no implica que debas; sólo quiere decir que tienes una opción más y un conjunto subsecuente de compromisos a considerar cuando tomes decisiones de diseño.

  • [Nota al pié 1] Quién engañó a Roger Rabbit es una excepción notable.
  • [Nota al pié 2] Trabajo para el grupo de IBM (Eclipse/Jazz) que creó SWT, así que no soy imparcial.
  • [Nota al pié 3] Aunque SWT favorece la delegación a widgets nativos de la plataforma, a veces usa widgets emulados si en una plataforma en concreto no existe un widget nativo aceptable. Esto hace que sorteemos el problema del ‘mínimo común denominador’ de AWT.
  • [Nota al pié 4] Soy injusto con Zimbra porque hay un escenario en el que su aspecto tipo Outlook realmente brilla. Si yo fuera un CIO pensando en abandonar Exchange/Outlook a una alternativa multiplataforma más barata, Zimbra sería muy atractiva porque como Zimbra es funcionalmente consistente con Outlook, podría esperar que los usuarios de Outlook hicieran la transición a Zimbra bastante rápidamente.

Publicado originalmente en el blog de Bill Higgins el 17 de Mayo de 2007. Traducido y publicado con autorización del autor.

0 0 votos
Article Rating
Subscribe
Notify of
0 Comments
Opiniones Inline
Ver todos los comentarios
0
Me encantaría saber tu opinión, por favor, deja un comentariox
()
x