tentándote.com

Hay hitos que marcan puntos de inflexión en la Historia de la World Wide Web.

Tab Candy es uno de ellos

Por fin Mozilla está enseñando los dientes ante los apabullantes movimientos de sus competidores, especialmente de Chrome y de Opera, y su acelerado ritmo de desarrollo.

Y lo hace con estilo. Con una derrochadora muestra de creatividad, innovación, talento y diseño logrando que las novedades que presentan terceros navegadores parezcan no tener más que un carácter meramente anecdótico.

Tab Candy es mucho más que un simple add-on. Es el primer vistazo que nos permite echar Mozilla a lo que puede ser la base de la nueva generación de sistemas operativos que se nos vienen encima. Una generación de sistemas que se van a caracterizar por:

• Ser ubicuos: Podremos utilizarlos en cualquier momento, desde cualquier lugar con conexión a Internet. En lo que respecta a Firefox además de la versión para PCs, laptops y notebooks, está disponible para móviles la versión para Nokia, y en beta, para Android.
• La independencia de dispositivo: Podremos usarlos en, y con cualquier tipo de dispositivos, cada versión adaptada a las características del hardware correspondiente.
• Estar centrados en la Nube: Ser sistemas operativos nativos de, y concebidos para  la World Wide Web.
• Estar sincronizados y ofrecer escritorios virtuales: En el momento en que el dispositivo correspondiente tenga un punto de conexión con Internet la sincronización será automática y transparente para el usuario. Los documentos, las fotografías, las canciones, los libros se almacenarán en la nube en un espacio personal de cada individuo. Mozilla acaba de lanzar Firefox Home que permite sincronizar con el iPhone el historial, los bookmarks y las pestañas que estén abiertas en el ordenador o dispositivo de sobremesa. Por otra parte Sync, es un proyecto que se ha graduado en los Labs, que permite sincronizar toda la información personal entre navegadores instalados en diferentes equipos. En el momento actual y según declaran en la página del proyecto está sufriendo cambios de interfaz de usuario para su plena integración con Firefox 4.
• Ser la identidad digital. Lo estamos viendo en las últimas distribuciones de las diferentes versiones de Linux y lo vamos a ver en Firefox. El sistema operativo tiende a perder su carácter de sistema operativo (y por ende su nombre rémora de una época caracterizada por centrarse en el software y no en las personas) para convertirse en un sistema personal. El reto será gestionar la privacidad de la persona, su identidad digital, y aquí, Firefox tiene mucho que decir.
• Ser sociales:  Centralizarán la gestión de toda la actividad digital social de la persona. Una persona – un navegador – un mundo de relaciones sociales. Permitirán gestionar las redes sociales en las que estemos inscritos. En este sentido, insisto, es extraordinariamente excitante lo que puede llegar a surgir de una red social descentralizada, no controlada por nadie como puede llegar a ser Diaspora, y su posible y futura integración con Firefox. En el momento actual Mozilla está desarrollando Contacts, una extensión que permitirá gestionar los contactos personales de distintas redes sociales como Facebook o Yahoo.
• Herramientas de comunicación: Una de nuestras principales actividades como seres humanos que somos, es la comunicación. Los nuevos sistemas operativos tenderán a integrar de forma nativa y gestionar todos los servicios y herramientas de comunicaciones que usemos:
  • A corto plazo la comunicación que mantenemos a través de blogs, servicios de microblogging, correo electrónico, feeds, podcasts y vídeos.
  • A medio plazo: la comunicación con terceros mediante voz y vídeoconferencia, y la integración de servicios como la televisión o la radio.

  En este sentido, la apuesta de Mozilla para Firefox se llama Raindrop. Es un módulo que permitirá gestionar de manera conjunta el mail, los feeds y los servicios de microblogging como Twitter. Asimismo Thunderbird antes o después terminará igualmente integrándose en Firefox.

• Plataforma de Software como Servicio en un primer momento: Las aplicaciones ya no se instalarán ni en el dispositivo, ni en el sistema operativo. Las aplicaciones residirán en la nube. No obstante y de cara a cuando no haya conexión con Internet, es llamativo el desarrollo en el que desde hace ya unos cuantos años lleva trabajando Mozilla llamado Prism. Éste módulo permitirá idealmente utilizar las aplicaciones de la nube en local aun cuando no exista conexión con la Red.
• Herramientas de productividad en un segundo momento: Las aplicaciones como tales tenderán a evolucionar e integrarse de forma nativa e invisible con los navegadores. El futuro es Ubiquity. La barra de navegación se va a convertir en una línea de comandos o línea de lanzamiento de interacción. La barra de navegación pasará a ser el punto para comenzar a escribir un mail, buscar un libro, añadir un contacto a nuestra agenda, etc. Será una interfaz líquida que presentará una apariencia distinta de acuerdo al servicio invocado.  Lo que se venderá, o alquilará, o explotará mediante modelos freemiun basados en economía de escalas y en la Larga Cola serán servicios o funcionalidades. Para entender cuál puede ser el nuevo modelo de negocio que puede emerger es recomendable leer el artículo que publicó en su día Aza Raskin sobre la línea lingüística de comandos y el nuevo paradigma de interacción.
• Ser gratuitos. Los beneficios no vendrán del software como producto per-se. El software será un medio para la venta de productos físicos o de terceros productos: gagdets, ordenadores, etc, o vendrán derivados de la explotación y comercialización de funcionalidades concretas invocadas a través de la línea de interacción, de la explotación de datos estadísticos del uso de los mismos, de la explotación de los datos de las búsquedas que realicen los usuarios o, simplemente serán sistemas operativos basados en desarrollos de software libre u Open Source.

Firefox se está convirtiendo paulatinamente en un sistema operativo ubicuo y en la nube. Así, es interesante observar la evolución natural que está sufriendo su interfaz, comparándola con el sistema desktop por excelencia de hoy día: Windows.

Éste es el escritorio de Windows 7:

Ver imagen ampliada en Flickr

Esta, la interfaz de Firefox 4  Beta 3:

Llama la atención las similitudes que pueden establecerse. En Firefox 4 se está dando literalmente la vuelta a la interfaz de Windows 7. Quizá no de manera consciente e intencionada pero sí de forma natural conforme evoluciona el producto.

Tanto en el sistema operativo de Microsoft como en el navegador existe un botón principal que da acceso a las operaciones más comunes:

Botón de inicio de Windows 7

Windows tiene una versión centrada en el dispositivo de hardware local, en las herramientas de productividad (ofimáticas, tratamiento de imágenes, hojas de cálculo, etc) y en el ocio y entretenimiento local (mis imágenes almacenadas en mi disco duro, mis canciones almacenadas en mi disco duro… una concepción opuesta a la tendencia actual del mercado que es la de consumo del ocio bajo demanda -música, vídeos y películas- mediante streaming, y de la gestión de la identidad y de la vida digital centrada en la World Wide Web).

Por otro lado, no ha sido hasta la llegada de Vista cuando han incluido un box que facilita la búsqueda directa de programas y archivos en el ordenador local, o el lanzamiento de aplicaciones. No obstante no está integrado con la World Wide Web ni orientado a facilitar la búsqueda en la misma. Los resultados se abren en el explorador de Windows y no amplían el rango a la Web en caso de ser necesario o requerido por parte del usuario, algo que debería cambiar en próximas versiones de Windows.

En cuanto a Firefox 4 Beta 3 y a su botón de inicio, tiene una visión netcentrica orientada puramente a la gestión de las páginas web, del navegador y de la navegación realizada en una sesión concreta:

Botón de inicio de Firefox 4 Beta 3

Mozilla reserva estas funcionalidades para el botón de inicio mientras que planea una Home Tab o suerte de “escritorio” como pestaña que se abra al comenzar la sesión en Firefox y que contendrá accesos directos a las aplicaciones en la nube más utilizadas por el usuario, contactos, historial de navegación, etc.

Esta aproximación es similar a la de otro gran jugador que está por llegar a la vuelta de vacaciones, Chrome OS, aunque en este caso parece que el botón de inicio tendrá la misma apariencia que el resto de pestañas de aplicaciones en línea.

Llama la atención la imagen del avatar del usuario presente en la esquina inferior izquierda junto a su dirección de mail ¿nombre personal en el futuro?, y el botón para deslogarse o cerrar la sesión. Ello implica que en cualquier dispositivo sea nuestro o de terceros, en el que esté instalado Chrome OS podremos nada más logarnos, disfrutar de nuestro sistema operativo personalizado, documentos, música, etc.

No obstante y aun cuando constituyen avances significativos, con Tab Candy se está dando un nuevo paso en su conceptualización e interfaz:

Tab Candy es un metaescritorio. Algo parecido a los “Espacios” -Spaces- y al Expose de Leopard aunque no igual.

En su interior se crean lo que Aza denomina espacios de trabajo que no son sino agrupaciones o grupos de pestañas realizadas por el usuario de acuerdo a sus propias necesidades y a su forma de organizar y categorizar la información del mundo (cada uno, tenemos una visión particular y diferente que adquirimos en base a nuestras experiencias, nuestro conocimiento, vivencias cotidianas etc. El conocimiento que evoca un ítem en la mente de una persona y las asociaciones que realiza con otras entidades informativas son propias de cada uno y diferentes de las de los demás. Por ende, un buen sistema de recuperación de información debería facilitar la creación de forma natural de estas agrupaciones para cada usuario. Tab Candy lo hace).

Ver imagen ampliada en Flickr

La disposición espacial de los espacios de trabajo según quiera el usuario (puedo reordenarlos y asignarles la posición que quiera arrastrándolos donde le parezca oportuno) y la organización de las pestañas en los mismos, facilita su posterior búsqueda y acceso. Adicionalmente el usuario podrá nombrar los grupos como desee y, en el futuro, personalizar su apariencia, guardarlos, compartirlos con terceros, etc.

Por último, en la parte inferior tenemos disponible un acceso rápido a las últimas pestañas abiertas por el usuario.

Tab candy es un metaespacio informativo que va más allá de la metáfora actual de los escritorios de los actuales sistemas operativos y quizá lo más interesante, es que subsume en sí la World Wide Web. Es un prototipo funcional que convierte en realidad parte de la visión del Zoom World de Jef Raskin: una interfaz de zoom inmersivo cuyos únicos límites eran los de la World Wide Web.

Una posible, bellísima y potente visualización de la Red hipertextual de redes por excelencia, con un extraordinario potencial.

Tab Candy es algo nuevo y fresco. Firefox está tendiendo a convertirse en un sistema operativo personal, en la nube.

Por fin.

Y tenía que venir, como no, por parte de los chicos de Mozilla y de la innovación colectiva de los Concept Series. Bien por Aza y por el equipo de Experiencia de Usuario de Firefox y Mozilla Labs.

Con este post, esta casa cierra por vacaciones hasta septiembre. Disfrutar del verano, sed malos todo lo que podáis y a la vuelta queridos lectores, nos reencontramos.

A propósito de la propuesta de Jennifer Boriss para rediseñar/suprimir la barra de estado del navegador en Firefox 4 se está montando una de esas bonitas discusiones antológicas que me hacen morir de envidia y en la que se aprende lo que no está escrito sobre usabilidad.

Abajo os pongo unas capturas de cómo lucen las interfaces de los navegadores principales hoy día para que veáis cómo aparece (o no) la barra de estado:

• Minefield de Mozilla (la alpha de Firefox 4) muestra la barra de estado como siempre en la parte inferior.
• Opera también la tiene aunque presenta un curioso diseño visual, cuando el cursor del ratón se pone encima de un enlace, se muestra la URL en la parte inferior pero en una capa gráficamente integrada y al mismo nivel jerárquico desde un punto de vista de Diseño de Información que el resto de las utilidades en la esquina inferior izquierda.
• Chrome no muestra la barra de estado pero cuando el cursor se pone sobre un enlace, se enseña su URL en la parte inferior, en una capa emergente de color azul, en la esquina inferior izquierda . De la URL sólo se muestran los 59 primeros caracteres incluidos el http:// seguidos de puntos suspensivos.
• Safari opta por la solución más radical (y en mi opinión la peor) no muestra ninguna barra de estado.

Me gustaría conocer vuestros puntos de vista y opiniones:

• ¿Barra de estado sí / barra de estado no? ¿por qué?
• Estos días estoy trabajando sobre SEO y URLs amigables en el trabajo y me estoy dando cuenta de que todavía hay que hacer mucho, mucho trabajo desde un punto de vista de los usuarios para mejorar las actuales URLs. Seguimos con un sistema de nombres y direcciones artificioso, extraño y ajeno para una persona normal, con una nomenclatura durísima (http, : , // , ftp …  -¿pero qué demonios es eso?-) heredada ni más ni menos que de hace 16 años. La pregunta es ¿Qué se puede hacer para mejorar las URLs y ayudar a los usuarios a formarse un constructo mental del espacio de información (sitio web) por el que están navegando? ¿Qué deberíamos hacer con el http:// ftp:// y otras “rarezas tecnológicas” del pleistoceno carentes de significado para las personas?

Fijaros además en las capturas de abajo en como se construye la jerarquía informativa de la interfaz del navegador en base a la jerarquía semántica del documento que, a la postre, es lo que le importa al usuario dado que la interfaz del browser realmente es cuando menos, secundaria:

• En el área de las pestañas o tabs, se muestra sólo parte del título del documento (página web) que está visualizando el usuario con el problema evidente asociado: se está sacrificando espacio en aras a ganar píxeles verticales para representar una mayor cantidad de contenido. ¿Cómo resolvemos este problema de no poder visualizar el título completo del documento cuando es la entidad semántica de mayor nivel que sumariza idealmente el mismo?
• Dado que el título no se visualiza por completo por el pequeño espacio horizontal disponible en cada pestaña, en el box de la barra de navegación que puede (y que debería) funcionar como línea de comando e interfaz adaptativa se muestra la URL del documento que no transmite de manera satisfactoria en un gran número de ocasiones (todas aquellas en las que no es amigable y aun con URLs amigables tenemos problemas):
  • De qué trata el documento.
  • La estructura del espacio de información o sitio web (muestra tan sólo una rama jerárquica en la que está clasificado, categorizado o facetado el documento, pero nada más). Llegados a este punto una mejora importante que se podría implementar en futuras evoluciones de la interfaces de los navegadores para ayudar a los usuarios a navegar, es deplegar de alguna manera un mapa o representación visual del sitio que idealmente… ¿se podría construir en base a los sitemaps.xml?
  • Una semántica comprensible para una persona. Las URLs no están codificadas en un lenguaje amigable al utilizar signos y nomenclaturas ajenas al código lingüístico que hablamos, escribimos y utilizamos, nuestra lengua madre, castellano o la que sea. En las URLs no se habla el lenguaje de los humanos, se habla usualmente el lenguaje de las máquinas :-( lo cual es un gran fallo desde el punto de vista de la usabilidad y un área en la que hay trabajar para subsanar este problema.
• Al estar situada la barra de estado en la parte inferior del navegador se está separando espacialmente y rompiendo la relación semántica que existe entre el enlace inserto en el documento y sobre el que se posiciona en un momento dado el cursor del ratón, y su URL que se muestra en la barra de estado en la parte inferior.

Firefox Minefield- Tooltip que se muestra cuando el cursor se posiciona sobre un enlace. Nótese como se visualiza el título especificado en el atributo title del enlace y cómo está espacialmente separado el tooltip de la URL que aparece en la barra de estado en la parte inferior rompiéndose la relación semántica entre ambos.

• Como propuesta de posible mejora para los navegadores se podría testear si la URL debería enseñarse como un tooltip. Si existe un title como atributo en el enlace entonces deberían mostrarse ambos, título y URL para ofrecer toda la información posible al usuario sobre el documento que se encuentra detrás del enlace y ayudarle a decidir si desea o le interesa hacer clic para visualizarlo o no. En cuanto al problema de la longitud de la URL podría considerarse si en lugar de enseñar toda se podría poner algún límite en el número de caracteres que se visualizarían a priori mostrando tan sólo parte más relevante (¿el nombre de la página junto al último directorio – subdirectorio de la misma?) o plantear algún tipo de capa que se desplegase a demanda del usuario de manera más o menos similar a como sucede con la barra de utilidades contextual de Word 2007:

Word 2007. Aspecto del cursor cuando está sobre una palabra

Word 2007. Aspecto de la barra de utilidades cuando se ha seleccionado una palabra. Nótese como se muestra de manera sútil y prácticamente transparente la barra contextual de utilidades con las que el usuario puede formatear el texto como mejor le parezca.

Word 2007. Barra de utilidades contextual que aparece cuando el usuario mueve el cursor hacia el contorno semitransparente (ver captura anterior) que la representa. De la misma forma para no mostrar toda la URL en el tooltip junto al title que se visualizaría cuando el usuario posicionase el cursor del ratón sobre un enlace, se podría considerar la posibilidad de mostrar tan sólo parte de la URL inicialmente y, a demanda del usuario con algún gesto sobre un área del tooltip, desplegar la URL completa si fuera necesario.

Hay mucho campo de investigación aquí y mucho espacio para las mejoras.

La pregunta es relevante ¿mostramos la barra de estado? ¿Sí? ¿No? ¿Que os parece la propuesta de Jennifer Boriss?

Os dejo con las capturas de los navegadores para que veáis como muestran actualmente las barras de estado (y las URLs):

Barra de estado en la parte inferior de la Minefield (Alpha) de Firefox 3.7

Barra de estado en la parte inferior en Chrome. Aparece sobre una pequeña capa azul cuando el usuario posiciona el cursor sobre un enlace y muestra hasta 59 caracteres de la URL incluidos el http://

Opera. Barra de estado en la parte inferior. Cuando el usuario posiciona el cursor sobre un enlace se amplia la pequeña capa con las utilidades de la esquina inferior izquierda permitiendo visualizar la URL

Bueno, ya era algo que me empezaba a preocupar un poco ya que en las últimas nightly de Firefox no observaba ningún cambio, pero por lo que veo, la gente de @Mozilla como no podía ser de otra forma, en su cuidado obsesivo de los diseños al pixel, acaba de publicar una actualización de las maquetas de la interfaz de Firefox 4 para Mac de la próxima gran versión del navegador en la que empiezan a despejar las dudas.

Confieso que tenía franca curiosidad por ver cómo resolvían el tema en cuanto al diseño gráfico de los laterales de la barra de tabs. Mirar una captura de la nightly de hoy (16 de junio de 2010) de Firefox 4 para Windows 7 en la que los bordes por donde aparecen y desaparecen las tabs aparecen planos y sin una línea que los remarque:

Echarle un vistazo ahora a la maqueta del diseño gráfico de la interfaz que han publicado para Mac, concretamente a los puntos que marcan las flechas amarillas, los laterales de la “barra de tabs” por las que aparecen y desaparecen éstas (nota: a pesar de que se ven mal las imágenes en el blog porque aparecen por debajo del texto de la columna derecha, no he querido reducirlas para que se aprecien correctamente los detalles. Para ver bien cada imagen lo único que tenéis que hacer es posicionaros encima de ella, dar botón derecho del ratón y seleccionar la opción “Ver imagen” para verla a pantalla completa en el navegador sin que os moleste la barra lateral del blog):

Os pongo a continuación la maqueta sin las flechas amarillas para que podáis apreciar mejor el diseño gráfico de los bordes de la barra por los que aparecen y desaparecen las tabs:

Fijaros en cómo jerarquizan los elementos de la interfaz de mayor a menor importancia situándolos en diferentes capas de profundidad mediante el uso de las sombras para crear un efecto de oclusión (unos elementos delante de otros). Concretamente pueden distinguirse 4 capas de información o de elementos de la interfaz:

1. La capa de color amarilla: Tab activa que contiene los principales elementos de la interfaz del navegador:
   • Los botones de adelante y atrás para realizar las correspondientes operaciones a través del historial de páginas visualizadas.
   • La barra de navegación o “barra maravillosa” junto a los botones de recargar/parar que ahora han fusionado en uno, situados al final.
   • El box de búsqueda para ejecutar consultas contra los buscadores, que inexplicablemente, versión tras versión, siguen sin fusionarlo con la barra de navegación mientras que en Chrome ya sólo tenemos una única barra de navegación en la interfaz principal. ¿Las causas? ¿? supongo que será cuestión de dinero o que tengan especificado por contrato con los buscadores el hecho de que siga separada o no lo sé pero desde luego, debería tender a desaparecer y fusionarse con la barra de navegación principal en aras de mejorar la usabilidad y simplificar la interfaz principal. El referente en este aspecto es, como comento, Chrome.
   • El botón de los marcadores que posicionan en último lugar, a la derecha, otorgándole gran importancia de acuerdo al estudio que hicieron del uso de los menús y que se sumariza en el mapa de calor que generaron a partir de los datos obtenidos de los usuarios que tenían instalada su herramienta de testeo remoto Test Pilot (para más información, no dejéis de leer el post de Alex Faaborg al respecto). En el mapa de calor podéis observar cómo el menú bookmark y sus opciones son las más usadas (se indican mediante el color rojo). ¿Por qué posicionándolo en ese lugar le están otorgando una relevancia especial, en mi opinión por varias razones:
     • La mitad derecha de la pantalla es aquella en la que para los diestros, normalmente se suele encontrar con mayor frecuencia posicionado el cursor del ratón. Esta afirmación está basada en mi mera percepción por lo que debéis tomarla con pinzas (como todo lo que digo, por supuesto) hasta que no haya estudios formales que la corroboren.
     • Por tanto, es más rápidamente alcanzable por el cursor del ratón al tener que recorrer el mismo por término medio una distancia menor desde la posición original en la que se encuentre.
     • Está posicionado al final de la barra muy cerca del borde derecho de la pantalla. Cualquier cosa que esté situada cerca de los bordes de la pantalla va a poder ser alcanzada con mucha mayor rapidez por el cursor del ratón ya que el borde actúa como guía visual, límite, barrera y freno del cursor en su desplazamiento. El movimiento tiene que ser menos preciso y por tanto se ejecuta con mayor rapidez hasta alcanzar el objetivo -el botón del marcador-.
     • Esta situado en el lugar en el que termina el escaneado visual de la parte superior de la interfaz -la cabecera global del navegador- lo que significa un refuerzo cognitivo de su posición en nuestra memoria de corto plazo.
2. La capa de color rojo correspondiente al botón de la home, situada en segundo plano por detrás de la amarilla. Contiene el botón para volver a nuestra Home Tab o página que tengamos configurada por defecto en las preferencias. Se aprecia que está en una capa diferente de la amarilla por el borde inferior contínuo, negro, que lo separa de la misma (o la parte correspondiente del borde superior de la capa amarilla).
3. La capa marrón en la que están situados los controles de cerrar, minimizar y maximizar. El título de la tab activa centrado, los controles de desplazar a izquierda y derecha la barra de tabs, el control de nueva tab (el “+” situado a la derecha) y el control que despliega el menú con la lista de los títulos de las tabs abiertas en la barra de tabs. Todos estos controles están agrupados en la misma capa y aquí viene lo interesante porque… ¿cómo han resuelto el problema de la jerarquización de la capa de la barra de tabs respecto a las demás a través del diseño gráfico…¿?…pues aplicando una sombra en el lateral de la barra de tabs (lo que marcaba en la maqueta superior con las flechas amarillas). Ello crea el efecto de un bolsillo de un pantalón o de una página en la que con un cúter hiciéramos un corte y por el mismo pasásemos una tira de papel que pudierámos deslizar a uno u otro lado según nos conveniese. Vamos, exactamente el mismo efecto que aplicaba el equipo de UX de Monster para crear puntos focales de atención en su página, y concretamente, en cuanto a cómo diseñaban las tabs que daban acceso a los apartados de “Información personal”, “Experiencia”, “Formación”, y “Objetivos profesionales” (podéis leerlo bajando por el post, como al quinto pantallazo aproximadamente).Una solución de diseño gráfico la del equipo de UX de Firefox francamente inteligente.
4. La capa gris de la barra de tabs propiamente dicha que, con su diseño gráfico, se “introduce” y emerge de la capa marrón.
   

Por concluir, la jerarquización de los elementos de una interfaz no sólo se consigue mediante un buen uso de los colores (y remito nuevamente al post de Monster en el que hablaba de ello). Otro gran recurso además, que tenemos a nuestro alcance son las sombras que ayudan a crear un efecto de oclusión o superposición de los elementos de la interfaz y por ende, de capas de información.

Me encanta Firefox. En su equipo de diseño se respira y se vive la Experiencia de Usuario en mayúsculas. Y lo mejor, es que hay mucho de su trabajo cotidiano que hacen público para uso, disfrute y aprendizaje, de todos.

Apple acaba de publicar las Directrices para el diseño de Interfaz Humana del iPad y de elementos de interfaz de usuario de sus aplicaciones.

Navegando he ido a dar con la home del Aeropuerto Internacional de Kansai

El caso, es que me ha llamado la atención cómo han diseñado el menú de navegación principal. No es un diseño muy ortodoxo que se diga ya que añaden iconografía a cada sección junto al correspondiente rótulo.

Así, los iconos predominan visualmente frente a los nombres de cada sección convirtiéndose en puntos focales de atención, dificultando la legibilidad de los rótulos e impactando en la usabilidad.

Diseño del menú de navegación con iconos y rótulos:

Sólo iconos:

Sólo rótulos:

En el caso de los menús de navegación de un sitio web no creo que sea buena idea añadir los iconos por la problemática intrínseca que tienen. Y menos en el sitio web de un aeropuerto internacional.

Por ejemplo, el avión de la primera sección sí se asocia a vuelos, pero también a aeropuertos, con lo cual la interpretación ya es cuando menos ambigua. El coche cuesta distinguirlo como coche por ser tan cuadrado en lugar de utilizar formas más redondas. Esta línea gráfica supone una menor usabilidad al reconocerse el coche con mayor dificultad. El tercer icono sí se interpreta más como llegadas y salidas, aunque también puede indicar tránsito o viajeros en tránsito (haciendo escalas). El de la cuarta sección no sé por qué, pero lo asocio a una bolsa bursátil o, por su forma, al monumento de Lincoln:

Lincoln memorial - Monumento a Lincoln. Imagen de Wikimedia Commons

El quinto se interpreta bien, tiendas y comida (restaurantes) y los dos últimos no los entiendo (el concepto que me evoca el último es el de radio) y el icono del mapa, puede ser cualquier cosa menos un mapa. ¿El perfil de la terminal del aeropuerto quizá? ¿?

Entre otros problemas que presentan los iconos pueden apuntarse:

• Hay iconos que más o menos pueden ser indicativos de la información que hay en la sección, pero para otros, su interpretación puede variar de cultura a cultura, e incluso de individuo a individuo en base a sus experiencias y vivencias personales. Cada uno visualizamos el conocimiento y el lenguaje de forma, y con formas gráficas diferentes. Y aunque como individuos con estructuras cognitivas similares podemos deducir e identificar patrones universales que nos permiten reconocer más o menos las mismas formas, precisamente por esas diferencias, interpretar un icono y darle un significado correcto puede costarnos más o menos a cada uno (si  logramos darle el significado correcto, circunstancia que a veces no no es posible).
• Por ello, a, a menudo los iconos requieren de ayudas textuales (tooltips que aparecen al posicionar el cursor del ratón encima del icono, o directamente, rótulos asociados al mismo) para poder comprenderse sin dificultades. En tal caso, la pregunta que se plantea es ¿por qué utilizar iconos en lugar de texto? ¿Por qué y cuando utilizar ambos?
• Los diseñadores gráficos pueden encontrarse con serias dificultades para representar y sintetizar conceptos abstractos complejos mediante una imagen que no es más que una metáfora, y más, a través de un icono con un tamaño, diseño o color determinados -, dificultades que son extensibles a los usuarios a la hora de comprenderlos.
• No es lo mismo una aplicación que un sitio web. En una aplicación, predominan los “verbos ” en las barras de herramientas. Las tareas que permite acometer la aplicación al usuario (por ejemplo, en un procesador de texto, entre otras tareas podemos: poner en negrita un texto, en cursiva, centrarlo, disminuir o aumentar su fuente, encontrar y reemplazar texto, etc). En una aplicación se diseña más una ARQUITECTURA DE INTERACCIÓN (el término es mío, no es una incorrección) que una Arquitectura de Información. Los espacios que se diseñan, aunque similares, son diferentes. Al igual que se definen espacios de información en cualquier sitio web, en una aplicación definimos espacios de interacción. E igualmente que hacemos como entregable, el mapa de un sitio web, deberíamos hacer entregables que sean mapas de interacción, que expliciten el modelo de interacción que subyace en la interfaz de la aplicación.  En un sitio web, la navegación se construye en base a una organización y jerarquización de su información (un espacio de información), y dado que hablamos principalmente de contenidos y no de acciones (verbos) o tareas, el lenguaje textual puede funcionar mejor en ellos, antes que los iconos.
• Añadiendo iconos junto a los rótulos en la navegación del sitio del aeropuerto, aparte de empeorar la legibilidad de los rótulos, los iconos interfieren directamente con nuestra capacidad cognitiva para abstraer la estructura de información del sitio y poder hacernos un mapa mental de las secciones. Los iconos en este caso son superfluos, ocupan un espacio innecesario y no añaden un valor determinante a la interfaz que justifique su presencia.

¿Cuando está justificado el uso de los iconos? ¿Cuando conviene utilizarlos? ¿Sólos, o con texto?

La respuesta, como suele serlo en cuanto a cuestiones de usabilidad se refiere, es depende de la circunstancia y el contexto.

Los iconos, por su tamaño, permiten un extraordinario grado de plegado de información y una vez que se aprende su código (a qué corresponde cada icono, al fin y al cabo familiarizarnos con la iconografía y funcionalidad de cualquier aplicación es aprender un código y un lenguaje visual, específico para la misma) pueden facilitar la búsqueda visual de una función en una aplicación y en una interfaz que utilicemos de manera intensiva y cotidiana:

Ribbon de Microsoft Visio. Al utilizar de manera cotidiana la aplicación y ser consistentes los iconos principales con las funcionalidades asociadas a lo largo de todas las aplicaciones de la suite (Word, Excel, Power Point, etc) terminamos por aprender parte del código iconográfico de las mismas con lo cual visualmente resulta mucho más rápido localizar las funcionalidades.

Si tuviéramos que expresar con palabras por ejemplo, las funcionalides del grupo de “Fuente” de la pestaña “Inicio” de la Ribbon de Word 2007 quedaría algo similar a:

Nótense tres cosas:

• El texto de las funcionalidades de un sólo grupo (a pesar de que aquí no está en la misma escala en la captura de la imagen que en el prototipo en blanco y negro) ya permite darnos cuenta de que ocupa mucho mayor espacio que los iconos gráficos. La densidad informativa de la interfaz que se comunica por píxel de pantalla es mucho mayor. Al fin y al cabo con la Ribbon se ha hecho un ejercicio de deconstrucción. Estadísticamente se han determinado qué funcionalidades de los menús eran las más usadas y se han explicitado directamente en la interfaz, con apoyo, en su caso, de rótulos textuales al lado de los iconos, cuando la interpretación de éstos no era directamente explícita. Con ello se han logrado suprimir las jerarquías de interacción presentes en los menús desplegables, ahorrando tiempo al usuario tanto para acceder a los comandos buscados, como para, en algunos casos, ver directamente el resultado de la acción del menú antes de aplicarlo, dado que al posicionar el cursor encima del icono esto ya provoca un feedback y un cambio inmediato en el texto inferior seleccionado.
• A pesar de que el texto suprime ambiguedades a veces es difícil expresar de forma precisa y con la concisión posible a través de una o dos palabras, la acción que se ejecutará cuando se haga clic sobre él.
• Dado que requiere de su lectura, el texto conlleva una mucho mayor cantidad de tiempo para leerlo y decidir qué funcionalidad estamos buscando, que si se utilizan iconos. Visualmente el texto cuesta más de escanear.

Cuadro de diálogo para la personalización de la Ribbon en Microsoft Word 2007. Si se conoce la forma correspondiente del icono de la funcionalidad que se está buscando es mucho más rápido hacer un escaneado visual de los iconos que se están viendo, que ir leyendo uno a uno sus nombres textuales.

• En una interacción continua en un dilatado período de tiempo (por ejemplo, 8 horas como las que cotidianamente nos pasamos delante del ordenador en una jornada laboral típica) la suma de los tiempos de las microinteracciones es francamente importante y significativa, al igual que el esfuerzo cognitivo que tenemos que hacer para llevar a cabo las tareas con mayor o menor eficacia con la aplicación. Esto en definitiva, es de lo que trata la usabilidad, de optimizar la eficacia y la eficiencia de una aplicación para alcanzar unos objetivos específicos en un contexto de uso específico. Y uno de los modelos clásicos para evaluar una interfaz en términos de eficacia y eficiencia es el conocido como GOMS (por Goals = Metas, Operators = Operadores, Methods = Métodos, y Selection rules = Reglas de selección) desarrollado por Card, Moran y Newell. Este modelo permite medir de forma cuantitativa, el rendimiento y el coste en términos de esfuerzo cognitivo y tiempo, de una interfaz frente a otra (al respecto puede consultarse el capítulo 4  “Cuantificación” del libro de Jef Raskin: “The Humane Interface”). Dicho modelo parte del hecho de que el tiempo que lleva a un sistema usuario-ordenador el ejecutar una tarea, es la suma de los tiempos de los gestos elementales que hay que llevar a cabo para ejecutar la tarea.  Estos se sintetizan en una serie de tiempos típicos característicos que son:
  • K = 0,2 sec. Keying (tecleado): El tiempo que lleva al usuario pulsar una tecla en el teclado.
  • P = 1,1 sec. Pointing (apuntar): El tiempo que lleva a ul usuario posicionar el cursor en un lugar específico de la pantalla.
  • H 0 0,4 sec. Homing (mover la mano): El tiempo que lleva a un usuario desplazar la mano desde el teclado hasta el Dispositivo Gráfico de Interfaz, tal como un ratón, o desde éste hasta el teclado.
  • M = 1,35 sec. Mentally preparing (preparación mental): El tiempo que lleva a un usuario prepararse mentalmente para el siguiente paso después de una microacción.
  • R Responding (respuesta): El tiempo que un usuario ha de esperar para que el ordenador responda a su input.
• Conforme a estos parámetros puede medirse la eficacia y la eficiencia de utilizar sólo iconos, sólo texto o ambos elementos en la interfaz de una aplicación. A bote pronto, en el caso de usar sólo texto, lleva más tiempo su lectura y comprensión, que el visualizar un icono del cual ya se conoce la funcionalidad que desempeña. Por otro lado, el texto al ocupar mayor espacio, conlleva un menor tiempo para ser alcanzado por el cursor, y menor precisión para ser pulsado que un icono pequeño.

En cuanto a usabilidad se refiere, hay que medir el coste de lo que representa tomar una decisión de diseño de la interfaz u otra. O, como mínimo y dada la imposibilidad que tenemos en muchas ocasiones de testarlo o medirlo en laboratorio, ser al menos conscientes de ello y de cómo las decisiones que se toman impactan en el rendimiento de la aplicación o del sitio web.

Barra de funcionalidades de Zoho Mail. Utilizan iconos y rótulos

Barra de funcionalidades del cliente de correo Thunderbird. En este caso conviven iconos y rótulos ¿són lo suficientemente significativos y se entienden sin problemas los iconos? ¿El de "responder" y "responder todos"? Nótese que los botones de archivar y basura no llevan icono, y que el icono de la funcionalidad "eliminar" se asocia al de cerrar las ventanas de Windows lo que produce una disonancia cognitiva e impacta en la usabilidad

Barra de funcionalidades de GMail. En este caso Google opta por no usar iconos junto a los rótulos

En cuanto a la World Wide Web, y dado que en cada sitio web solemos estar de forma muy puntual, e interactuando con su interfaz durante tiempos muy reducidos, no es la mejor idea construir y utilizar un código iconográfico propio que conviva con los rótulos de las secciones, en la navegación principal, ni para facilitar la misma, ni para realzar el diseño desde un punto de vista gráfico.

Por cierto, un último detalle más en cuanto a la barra de navegación del aeropuerto, la pestaña “top” de la derecha es un elemento 100% superfluo 2.0).

¿Opiniones? ¿En qué contextos consideráis que los iconos juegan un papel importante y son recomendables y en qué ocasiones no? ¿Más ejemplos que conozcáis?

Pues el caso es que estaba navegando un rato y he ido a parar a la página de Hoteles.com. Curioseando he visto algunos componentes de la interfaz y patrones de diseño e interacción que me han llamado la atención.

El primero es la concepción y funcionamiento del buscador de la home. Me gusta cómo lo han planteado. Permiten búsquedas en base a cuatro criterios principales:

• Nombre de ciudad
• Punto de referencia
• Nombre de hotel
• Dirección de hotel

La faceta de “Punto de referencia” no es común ni habitual. Cuando menos me resulta curiosa y una buena idea si tu necesidad de información como consumidor no está predefinida y es más bien exploratoria. Si sabes la ciudad a la que quieres ir, el hecho de que te sugieran lugares con encanto o especiales de la misma se me antoja un valor añadido. Una forma de facetar la información que detrás tiene una reflexión pausada y una definición de un modelo mental de usuario que no suele ser muy habitual que se dé en los diseños de las webs.

Dicha faceta se ve bastante bien en la categorización que hacen en las autosugerencias. La forma en que están diseñadas comienza a ser un patrón de interacción estándar que se está imponiendo desde hace unos meses a ahora.

Facetas de información en las autosugerencias del buscador de Hoteles.com. Se observan cuatro tipos de facetas: Ciudades/Zonas, Puntos de referencia, Aeropuertos y Hoteles. Obsérvese la inconsistencia entre lo declarado encima del box y las facetas ofrecidas, las de "Zonas" y "Aeropuertos" no aparecen descritas encima del box de búsqueda

La idea es, cargar la inteligencia y el trabajo pesado de desarrollo en el background tecnológico y devanarse un poco los sesos pensando en las maneras en que podemos facetar nuestros contenidos para ayudar a los usuarios en sus búsquedas de información. Va siendo hora de comenzar a hacer un poco de trabajo de valor añadido en cuanto a la findability se refiere, definiendo unas buenas taxonomías de contenido y comenzando a enriquecer un área espacial interesantísima, la de las autosugerencias que se despliegan al introducir en el box una cadena o unos caracteres de texto, más allá del mero hecho de ofrecer como viene siendo común, las habituales palabras clave o ocurrencias coincidentes.

Otro componente que me gusta bastante y por lo que veo, que es más bien un estándar en las webs de hoteles, es el calendario:

Diseño del calendario desplegable en el buscador de Hoteles.com

Me gusta el diseño gráfico. El alto contraste con el fondo lo que focaliza la atención en el mismo. La adicción de una sombra para crear un efecto de oclusión y traerlo a primer plano respecto al resto de elementos de la interfaz, el hecho de mostrar dos meses en lugar de uno algo, que no termino de entender cómo no se establece ya de una vez y se generaliza como un estándar en todas las webs de reserva de hoteles, venta de billetes, etc. Dos meses considero que es lo mínimo que se debería plantear en un calendario de este tipo y creo que sería más que interesante y habría que medir el impacto en la venta de billetes o reservas, el hecho de mostrar incluso tres meses en lugar de dos.

Si queréis ver más diseños de calendarios podéis hacerlo en el album de calendarios que tengo en mi página de Flickr.

Tres pequeños detalles más en el calendario:

• Dado que no distinguen gráficamente con una tipografía superior el nombre de cada mes, pondría al menos la primera letra en mayúscula lo que ya sería suficiente para ofrecer una tensión visual elevada junto a su posición encima de las abreviaturas de los días. Tal y como está, cuesta distinguir el nombre del mes, lo que reduce la usabilidad. Curiosamente en el diseño de la versión estadounidense sí se observa que ponen en mayúscula el nombre de cada mes, fijaros en la diferencia entre utilizarla y no, aunque también se ve que siguiendo el mismo criterio, ponen también en mayúsculas la primera de la abreviatura de cada día lo que disminuye la legibilidad de los mismos e impacta asimismo en la usabilidad :-P

Diseño del calendario de la web estadounidense Hoteles.com. Llama la atención como frente a la española, ponen la primera letra del nombre del mes en mayúscula lo que redunda en una mejor escaneabilidad, focaliza sutilmente la atención en el nombre y mejora la usabilidad del calendario. No obstante, ponen igualmente en mayúscula la primera letra de la abreviatura de cada día lo cual supone una merma de esta.

• Me encanta la forma en que se ve el componente en Mac, con la flecha apuntando al box de texto resaltado en azul en lugar de la típica capa alineada con el borde izquierdo del campo de texto. Mucho más clara de esta forma y menos equívoca la relación que se establece entre el calendario y el campo. Fijaros por ejemplo en el calendario de Xpedia:

Calendario de Xpedia.com. la capa de los meses se alinea con el borde izquierdo del campo de introducción de la fecha lo cual suele ser un estándar común. El problema es que los únicos elementos que el usuario tiene para relacionar dicha capa con el primer campo, y no con el segundo, son el foco azul de la fecha cuyo efecto se pierde por ser el color predominante de fondo en la web, y el hecho de estar exactamente alineada con el borde izquierdo del campo. El diseño del calendario en Hoteles.com con la flecha apuntando el campo y la ligera separación respecto a la parte inferior del mismo es mejor desde un punto de vista de usabilidad ya que la relación que se establece es inmediata e inequívoca.

• No incluyen un botón de cerrar en la capa. ¿Mejora o empeora la usabilidad del componente éste hecho? Por un lado se observa que la capa permanece abierta hasta que el usuario hace clic en un día seleccionándolo momento en el que se cierra, o hace clic en cualquier otra parte fuera de la misma, hecho que igualmente la cierra. El único “pero” es que si el usuario se ha equivocado de día tiene que volver a pulsar sobre el campo para abrirla.
  Si se incluye un punto de interacción o botón de cerrar el usuario se verá más movido a desplazar el cursor hacia dicho botón para ocultar la capa con el consiguiente coste de tiempo y esfuerzo para llevar el puntero del cursor a dicho elemento y hacer clic en el mismo.
  ¿Lo incluimos entonces o lo quitamos? Google Maps por ejemplo incluye el botón de cerrar en los bocadillos aunque este desaparece igualmente si el usuario hace clic en cualquier otro punto del mapa que no sea el bocadillo abierto. El buscador de Google en su último rediseño de las autosugerencias elimino el enlace de cerrar que estaba en la parte inferior derecha. ¿Lo quitamos o lo dejamos? Particularmente yo sería de la opinión de quitarlo, el diseño queda mucho más limpio y el comportamiento es perfectamente predecible en cuanto el usuario lo utilice un par de veces.

Me gusta también el diseño visual del elemento de número de habitaciones. Un diseño gráfico muy limpio y muy visual. Eso sí, se les junta el “Mayores de 18″ con el otro rango de edad “0-17″ años lo que parece que es mayor de 180 años :-) En el diseño americano es mucho más claro –> “Ages 18+” y “0-17″:

Diseño visual del elemento para agregar habitaciones y especificar el número de ocupantes de las mismas

Por último me llaman la atención los filtros que hay mano derecha en la página de resultados:

Concretamente:

• Me resulta curiosísimo el diseño del deslizador para especificar el rango de precios de las habitaciones del hotel. Es la primera vez que veo uno así, demasiado recargado pero tiene algún detalle majo como el uso de líneas verticales más largas y otras más cortas para establecer cinco subrangos de precios.
• Me gusta mucho cómo han planteado el tema de las estrellas del hotel (toda vez que utilizar las estrellas fuera de un contexto específico como este y para otra cosa que no sean los favoritos puede dar lugar a un problema de usabilidad como apuntaba Diego Cano en otro caso en el que también hablábamos de deslizadores y estrellas en una web de viajes.
• Me encanta el detalle de la inclusión de la taza del desayuno en el filtro de “Servicios o comidas incluidas”, buenísimo.

Hay más cosas pero de momento, lo dejo ahí.

Me gusta el módulo de registro en la home de ZML.com

Para registrarse tan sólo es necesario que el usuario proporcione su cuenta de correo electrónico, que explícite cual va a ser su contraseña y que la confirme.

Y de momento nada más. Tan sólo se le requiere la información mínima e imprescindible. Simple, rápido y sencillo.

Uno de los aspectos críticos a tener en cuenta al lanzar una aplicación web, y especialmente en el contexto móvil, es reducir la fricción durante el registro de los usuarios. Joshua Porter le dedica un capítulo entero en su libro al tema. Y es que como comenta “tenemos alrededor de ocho segundos para realizar la conexión [con el usuario]” (capítulo 4, p. 65).

No creo que la cosa sea tan radical y que el tiempo sea tan corto, pero en cualquier caso, es muy muy reducido, al igual que la atención que se le presta al sitio en un momento dado.

Reducir la fricción para que se registren y prueben nuestra aplicación es vital dado que:

• Hay millones de aplicaciones y de sitios web a los que llegamos o descubrimos cotidinamente y que en un momento puntual puede interesarnos probar.
• Si llegamos a ellos porque estamos realizando una búsqueda estaremos más motivados para intentar registrarnos. Si los descubrimos por casualidad es posible que los guardemos para revisarlos posteriormente con tranquilidad y ver si merece la pena registrarnos o no. En ambos casos el tiempo y la atención que le dedicamos a un sitio o aplicación nueva es muy muy limitado.
• No malgastamos nuestro tiempo en aquello que no consideramos que sea de nuestro interés o que no nos vaya a ser útil o relevante.
• No damos a la ligera nuestra información personal, y mucho  menos en un sitio desconocido.
• En aplicaciones de móviles, cada carácter escrito cuesta, y mucho. Cada campo extra reduce las posibilidades de que los usuarios se registren o al menos que se lo piensen.

Cuanto más fácil lo tenga el usuario para registrarse más posibilidades existen de que se cree una cuenta y de que pruebe nuestro servicio para ver si le convence o no, que es de lo que se trata.

Con posterioridad, una vez que se ha registrado con unos datos mínimos, que ha utilizado la aplicación o el sitio, que le ha gustado y que le hemos conseguido fidelizar, ya habrá tiempo de que complete si es necesario su perfil.

Aunque no comulgo especialmente con las siguientes prácticas, comento cómo lo hacen algunos.

En LinkEdin por ejemplo cada paso adicional que el usuario da para completar su perfil le otorga un porcentaje extra hasta llegar al 100%. A nadie le gusta dejar las cosas a medio hacer, ni mucho menos tener un porcentaje bajo en su perfil profesional, circunstancias ambas que le impelen a completarlo con posterioridad en el momento en que mejor le convenga.

En Monster.com en lugar de utilizar un porcentaje otorgan una valoración al perfil del candidato en función de que esté más o menos completo. Cuanto más datos aporte mayor es la “Calidad del perfil”.

Por igual circunstancia que en LinkEdin, el usuario se encuentra incitado a completar la información de su perfil cuanto antes con el fin de aumentar la calidad del mismo.

Para terminar, existen más formas para reducir aún más la fricción durante el primer contacto del usuario con la aplicación y lograr que al menos la pruebe.

¿Cómo?

Una de las maneras más comunes es utilizando APIs de terceros para gestionar la identidad digital, por ejemplo la de Google o la de Facebook tal y como hacen en Ideeli.com (esta es una captura antigua, en estos momentos tienen cerrado el registro)

Otra es permitir directamente al usuario acceder a la aplicación y cuando desee realizar determinadas acciones, como publicar un mensaje (caso de Twitter) o votar (Digg, Menéame) por citar dos ejemplos, pedirle que se registre. En este caso es recomendable una vez que el usuario se ha registrado, devolverle al punto en el que comenzó el proceso.

Por cierto, un par de cosas que podrían mejorarse tanto en ZML.com como en Ideeli.com. En la primera se le podría pintar un rostro al icono del usuario. Los usuarios son personas y nos sentimos mucho más identificados con una persona que con “algo” que no tiene cara. El impacto emocional es importante. En cuanto al segundo, prefiero pedir la cuenta de correo electrónico antes que el nombre de usuario:

• La cuenta de correo electrónico no suele variar y es más fácil de recordar.
• Con los nombres de usuario existe el riesgo de que el usuario introduzca uno cualquiera para registrarse y probar el sitio o curiosear, y que posteriormente no recuerde el mismo con lo cual si luego se le pide como requisito para logarse, estaremos poco más que perdiéndolo.
• En cualquier caso, es una buena práctica

¿Se os ocurren más buenas prácticas, recomendaciones o consideraciones a tener en cuenta en cuanto al registro o el logado?

The Astonishing Tribe, más conocida como TAT, es una compañía sueca de la que ya hemos hablado antes por estos lares . Sus aplicaciones e interfaces no dejan indiferente a nadie y en buena medida, con cada una de ellas que lanzan introducen nuevos conceptos y patrones de interacción.

En esta ocasión acaban de presentar varios widgets para Android en los que la cinestesia (movimiento, animación) y los efectos “orgánicos” (por llamarlos de alguna forma) están a la orden del día. En mi opinión creo que incluso se está comenzando a abusar demasiado de ellos, pero bueno. Al fin y al cabo es un recurso -la animación- nuevo que tenemos y que estamos aprendiendo a utilizar.

Lo mejor que tiene el espacio digital es que es maleable lo que significa que podemos retorcerlo y hacer con él lo que nos dé la gana.

¿Qué hay detrás de una interfaz plana como la pantalla de un monitor?

Pues un espacio literalmente n-dimensional que podemos conceptualizar como queramos. La imaginación es el límite y propuestas como la de TAT para Android son precursoras de los nuevos patrones de interacción que están viniendo en las nuevas interfaces:

¿Dónde se pueden encontrar más fuentes de inspiración para nuevos modelos de interacción y espectaculares efectos de cinestesia…?

Pues en la naturaleza, por supuesto, que para algo ya ha hecho por nosotros un estupendo trabajo de diseño evolutivo desde hace millones de años  ;-)

Cambiando de tercio, ojeando sus otras propuestas veo que acaban de presentar asimismo una aplicación con una interfaz ya más pulida de su aplicación de realidad aumentada para el reconocimiento facial:

Ojalá tuviera proyectos en el que pudiera diseñar cosas como estas.

Actualización 31 dic 2009 (*)

Me gusta bucear por los webs de la Fundación Mozilla, por sus Wikis y sus grupos de discusión. Y me gusta porque son uno de los lugares donde más Diseño de Interacción y Diseño de Información aprendo.

El equipo de UX de Mozilla es francamente bueno y algunas de sus discusiones son antológicas y de libro. No hay muchos sitios en donde se pueda aprender interacción como en estos lugares en donde uno tiene la sensación de que realmente la Experiencia de Usuario se valora en lo que vale. Razones no les faltan. Con un público de 300 millones de usuarios, o lo haces bien, o pasas a ser jugador de segunda en nada de tiempo.

En España, aunque la UX ha avanzado muchísimo desde el 2000, todavía nos quedan un par de vueltas antes de que nos pongamos al mismo nivel que en otros países en cuanto a inversión de recursos en UX se refiere. Por aquí, no conozco muchos lugares donde de manera sistemática se hagan tests de usuarios como parte del proceso de diseño/rediseño de los sites o productos que se acometen y se haga diseño centrado en el usuario por mucho que se predique que se hace. El coste que conlleva tanto económico, como en tiempo y Recursos Humanos lo hacen inviable dado que, de momento, no hay muchos clientes que puedan o quieran asumirlo cuando pueden tener un producto “más o menos” aceptable desde un punto de vista de usabilidad con una rebaja de presupuesto del ¿30? ¿40%?

No obstante, poco a poco, se va abriendo brecha y algunas empresas punteras sensibilizadas van poniendo en marcha sus propios labs (que por cierto, a ver para cuando alguna consultora se anima a realizar la inversión y abre su propio dominio que empiece con labs.xxxxxx.xxx). El problema es una vez más el coste, aunque hay jugadores muy grandes que podrían acometer la inversión holgadamente. Todavía falta implantar realmente una cultura del I+D+i.

Y volviendo a la materia que da origen al título de este post, navegando por los Wikis de Mozilla he ido a dar con esta maqueta en donde se plantea el rediseño del sistema de notificaciones para Firefox 4.0.

Me gusta la forma en que se han utilizado los colores para comparar las características del antiguo rediseño y el nuevo por las siguientes razones:

• Los colores definen capas de información, relacionan elementos y permiten realizar con precisión comparaciones entre ellos.
• Permite hacer emerger el conocimiento implícito en el rediseño explicitándo gráficamente las razones por las que se lleva a cabo, para que sean entendidas sin ambiguedades y rápidamente por parte del cliente.
• Facilita juzgar fácilmente el peso que se le otorga a los distintos elementos de la interfaz y la mejora que supone en cuanto usabilidad.
• Facilita estudiar la interrelación semántica que se establece entre los distintos componentes de la interfaz y entrar a considerar cuestiones como la idoneidad de su posicionamiento espacial.

Sin el uso de los colores sobre un prototipo en blancos, negros y grises, no sería posible obtener una visión y realizar una comparación tan clara de la interfaz original y la propuesta como evolución como se consigue en el presente ejemplo. Una buena práctica que se puede utilizar en nuestro trabajo diario:

Propuesta de rediseño para las notificaciones de Firefox 4.0. Los colores definen capas de información delimitando y relacionando con claridad y sin ambiguedades los distintos elementos de la interfaz original y la propuesta. La maqueta es de Alex Faaborg

(*) Para ver otro buen ejemplo de comparación de interfaces y uso del color (en este caso se comparan estados) se puede echar un vistazo a: “A piece with a lot of screenshots about the close tab behaviour in Google Chrome”

Qué importante es el uso del color como elemento para separar capas de información, centrar la atención donde hay que centrarla, mejorar la usabilidad de una aplicación y, en este caso concreto, incrementar el número de descargas del navegador.

Una captura de la página de de Apple para la descarga de Safari 4.0:

Fijaros cómo se utilliza el color azul degradado para el botón de la descarga y el naranja en el rectángulo superior de la página para crear un punto focal de atención. Al igual que podemos establecer jerarquías de información durante el diseño de un componente con sus correspondientes elementos, podemos establecer jerarquías de información basadas en colores.

En este diseño creo que el uso del color no es óptimo y se puede mejorar. Como me comentaba un compañero el otro día, Fernando, para los botones en tiendas de comercio electrónico funciona mejor el color naranja-calabaza que el azul. Generalizando más, también para las descargas y las llamadas a la acción.

Fijaros en la diferencia entre la pantalla de arriba y la de abajo con el código de color del botón y del rectángulo de la esquina invertido:

Habría que testarlo pero apuesto a que este segundo tendría un ratio de número de clics mayor que con el actual botón azul. La jerarquía de color es óptima (el más cálido y llamativo es el elemento más importante en el que se quiere crear el punto focal de atención -el botón de la descarga-) y el azul para el otro elemento que crea un punto focal de atención secundario en la página tanto por su color característico frente al gris y al blanco que lo rodea, como por su forma triangular que rompe con todas las líneas rectas y bordes redondeados del diseño.

AOL, por ejemplo, también usa el naranja-calabaza para el botón de buscar del buscador de su home:

Botón de buscar del buscador principal en la home de AOL

Curiosamente en la pantalla de logado del webmail invierten el patrón y centran la atención en el botón de registrarse y crear cuenta frente al de logarse:

Botón de logado de color azul en AOL y naranja para el de registrarse y crear nueva cuenta

Yahoo España y Yahoo internacional siguen el mismo patrón de colores para los botones del buscador y de acción:

Botones de color calabaza en Yahoo España, del buscador y de quedarse en la versión local de la página del usuario

En Amazon.com usan el naranja como color para el botón de “Mostrar todos los departamentos” y el botón para lanzar la búsqueda con el rótulo “Go” que además lo hacen circular para convertirlo en un punto focal de atención por su forma (el círculo es un elemento que añade una fuerte tensión visual e interés a cualquier diseño):

Botones de color naranja de "Mostrar todos los departamentos" y ejecutar búsqueda de Amazon

En lugar del naranja-calabaza, Firefox utiliza un color verde para el botón de descarga, también admisible. Originalmente el verde que utilizaban era muy oscuro y con el paso del tiempo se ha ido aclarando mucho. Además incorporan la palabra “Free” al rótulo principal con lo que han conseguido, como comenta Yusef (no encuentro el enlace, si localizo la presentación donde lo ví lo pongo) incrementar el número de descargas del navegador.

En este caso particular es posible que la elección del color verde para el botón sea plenamente consciente e intencionada para potenciar el logotipo de Firefox y no robarle protagonismo. Los colores naranja, calabaza y amarillo otorgan gran predominancia al logotipo junto al hecho de que sea redondo frente al resto de elementos de líneas rectangulares (con excepción de las palomas, no entiendo el motivo de que figuren ahí al igual que el ¿altavoz? ¿biberón? de la cañería) convierténdolo en un punto focal de atención muy fuerte. En la página creo que hay demasiado ruido por el uso de la imagen de fondo lo que va en detrimento de la usabilidad de la tarea principal a la que está enfocada la página -la descarga del navegador- si la quitasen o planteasen otro diseño mucho más limpio como el de Apple posiblemente obtendrían un mayor número de descargas:

Botón verde de descarga de Firefox

El uso de los colores es un aspecto crítico para las webs.

Es necesario conocer los fundamentos básicos de la teoría del color para poder juzgar de manera mínimamente objetiva y con razones y argumentos de peso por qué funcionan unos diseños y otros no. De nuevo, queda pendiente publicar un post (otro) sobre colores y usabilidad. El tema es realmente fascinante y mucho más complejo de lo que uno podría pensar a priori, y lo más llamativo, es un aspecto al que prácticamente hasta hace muy poco no se le ha comenzado a prestar atención más allá de la pura faceta estética o emocional cuando en realidad, es un aspecto fundamental para la usabilidad de cualquier interfaz.