Si quieres estar al tanto de lo último que van haciendo descárgate la Canary Build de Chrome escribe about:flag en la barra de navegación y experimenta con los últimos cambios que van a añadiendo los ingenieros de desarrollo y UX de Google. En concreto, están evaluando la posibilidad de ocultar la barra de navegación para dar aun más espacio a la visualización del contenido. Esta sólo se mostraría al hacer clic sobre la tab. Un cambio extremadamente relevante en la interfaz y en cuanto a la usabilidad del navegador. Estoy ansioso por ver si lo implementan en la versión estable o pasará como un experimento de interfaz más.

¿Opiniones al respecto? ¿Mejor o peor usabilidad?

Información vía: Genbeta

Asimismo han desarrollado un prototipo de ordenador flexible:

Aunque en el artículo del paperphone que van a presentar reconocen que todavía queda mucho trabajo por hacer para alcanzar el grado de usabilidad con el que cuentan actualmente las pantallas rígidas, manifiestan que el futuro pasa por interficies flexibles que nos permitan interactuar de una manera más próxima a la interacción que mantenemos con los documentos de papel (p. 2 del artículo) y que tienen entre otras ventajas el:

1. Ser muy delgadas y ligeras pero resistentes, lo que permite una portabilidad superior frente a la forma de cualquier ordenador móvil actual.
2. Tener múltiples formas. Esto facilita diferentes affordances físicos que se relacionan con funcionalidades específicas: leer un periódico responde a un propósito diferente que leer la etiqueta de un producto, e implica un estado físico o forma distinto.
3. Proporcionar un espacio de pantalla variable real en el que se enmarca el contexto actual de uso.
4. Tener muchas páginas físicas, cada una de ellas pertenece sólo a una tarea y a un contexto físico delimitado.
5. Usar gestos físicos con una gran respuesta cinestésica y táctil para una navegación eficiente.

Estos aspectos son algunos de los críticos (además de muchos otros) de los que adolecen los actuales libros electrónicos para su adopción y popularización masivas y esta investigación abre la vía comercial al desarrollo de dispositivos que permitan una interacción háptica más natural con nuestros objetos cotidianos.

Combinando estas investigaciones con las que parece que se están llevando a cabo en otros laboratorios como los de Nokia sobre el desarrollo de superficies capaces de adoptar texturas y formas de acuerdo a la interacción háptica que se mantenga con las mismas, se plantea un futuro de dispositivos ciertamente espectaculares:

¿Tendremos que comenzar a adoptar un enfoque más integral para el Diseño de Interacción e Información y la Experiencia de Usuario?

La respuesta es sí

Podéis descargaros los artículos del Paperphone y del Snaplet y ver la información original de la noticia en la nota de prensa publicada por el Human Media Lab de la Universidad de Queen o de los siguientes enlaces:

• Artículo científico del Paperphone para CHI 2011 (pdf)
• Artículo cientifico del Snaplet para CHI 2011 (pdf)

Hace poco estaba prototipando una interfaz que permitía al usuario gestionar las etiquetas asociadas a una imagen. Concretamente estaba pensada y diseñada para que el usuario pudiese llevar a cabo dos tareas:

• Borrar una etiqueta concreta
• Visualizar las imágenes asociadas a una etiqueta para, con posterioridad, añadir más etiquetas a dichas imágenes o realizar otras operaciones sobre ellas.

Después de un rato salieron dos opciones:

Alternativa A:

Alternativa B:

En la alternativa A las etiquetas se agrupan alfabéticamente por la primera letra. El objetivo es facilitar la búsqueda de una etiqueta concreta para lo que se recurre a una doble solución:

• Por un lado se utiliza el espacio en blanco para introducir una separación visual entre letras que sea lo suficientemente significativa para que rápidamente se perciba la “ruptura” de cada bloque,
• Por otro, se añaden las letras del alfabeto en mayúsculas, agrupando en conjuntos las etiquetas que empiezan por la misma. Con ello se pretende crear un punto focal sobre las letras mayúsculas de inicio de cada bloque para facilitar la búsqueda de las etiquetas una vez localizado rápidamente el grupo.

En la alternativa B por el contrario se eliminan las letras mayúsculas agrupadoras y se usa el espacio en blanco como único recurso para separar los conjuntos de etiquetas.

Aunque lo mejor para un escaneado más rápido y una lectura óptima es tener una sola columna con la relación de todas las etiquetas, se optó por distribuirlas en tres paralelas con el fin de evitar un excesivo scroll vertical.

El caso es que después de estar un rato mirándolas se me planteó la pregunta de cual de las dos opciones sería la mejor por usabilidad.

¿?

ATENCIÓN, LOCUS DE ATENCIÓN E IMPLICACIONES PARA LA USABILIDAD DE LAS INTERFACES

En su libro The Humane Interface (me encanta este libro y lo voy a seguir utilizando como fuente de inspiración para futuros posts) Jef Raskin reflexiona sobre dos conceptos que vienen al caso, la atención y el Locus de Atención.

En cuanto a la atención Fernández-Abascal, Dolores Martín y Domínguez Sánchez (1) (2009, p. 52) la definen como:

• Un estado de concentración en algo.
• Capacidad de procesamiento que puede distribuirse o compartirse en el tiempo entre las diversas tareas y estímulos que exigen atención.

Ahondando en la definición, Tejero (2) menciona que:

“La atención puede definirse como el mecanismo cognitivo mediante el que ejercemos control voluntario sobre nuestra actividad perceptiva, cognitiva y conductual, entendiendo por ello que activa/inhibe y organiza las diferentes operaciones mentales requeridas para llegar a obtener el objetivo que pretendemos y cuya intervención es necesaria cuando y en la medida en que estas operaciones no pueden desarrollarse automáticamente”.

Los procesos en los que media nuestra atención son procesos conscientes. La atención nos permite centrarnos en parte de la información que recibimos a través de nuestros órganos sensoriales y controla y orienta nuestra actividad de forma consciente para conseguir un objetivo concreto. Por el contrario hay ocasiones en que las tareas las llevamos a cabo guiadas por un hábito, las hacemos de forma automática o insconciente.

No obstante, ambos procesos, no se dan plenamente por separado sino que puede haber un cierto grado de interacción entre los mismos.

Un buen ejemplo es el el de escribir en el ordenador. Si hemos aprendido mecanografía ejecutamos esta acción de manera inconsciente. Una vez que posamos las manos sobre el teclado no sómos conscientes de dónde se encuentran posicionadas las teclas que corresponden a los caracteres del alfabeto. Cuando pensamos en una palabra nuestros dedos se mueven de manera automática presionando las que hagan falta y como resultado aparece la palabra en pantalla. El proceso de escribir está guiado por nuestro hábito adquirido a través de un proceso de aprendizaje. Y si el hábito está mal adquirido, los errores tenderán a repetirse.

Por el contrario,si tuviésemos que pensar en los caracteres que conforman una palabra determinada, por ejemplo -g-a-z-p-a-c-h-o- y decidiéramos escribirlos uno a uno, en el proceso entraría en juego nuestra consciencia: En tal caso las operaciones serían:

• ¿Cuál es el primer carácter de la palabra que estamos escribiendo? –> la “g”
• ¿Dónde está la tecla que se corresponde con el carácter “g”– > en la parte central del teclado, la localizamos –> y la presionamos continuando la tarea con el resto de caracteres en un proceso recursivo hasta completar la palabra.

Raskin sumariza las diferencias entre los procesos cognitivos conscientes e inconscientes de la siguiente forma (3):

Por último, en cuanto al concepto de Locus de atención comenta que (4):

“Uso el término locus porque significa un lugar, o en el sitio. El término foco, que a veces se utiliza de forma similar, se puede entender como un verbo, por lo que transmite una falsa impresión sobre cómo trabaja la atención. Cuando uno está despierto y consciente, el Locus de Atención es una característica, un rasgo de, o un objeto en el mundo físico, o una idea sobre la que está pensando activamente y con atención”

¿Cómo influye la atención y el locus de atención en el desempeño de las tareas que acometemos cuando interactuamos con el ordenador?

Volvamos a la interfaces planteadas al principio del post.

Considerando el ejemplo A, cuando el usuario busca una etiqueta específica como por ejemplo “invertebrado” el locus de atención se centra en la búsqueda de palabras que empiecen por “i”. Este proceso lo ejecutamos en un primer momento de manera inconsciente. La separación de las etiquetas en grupos usando el espacio en blanco no interfiere con la tarea, no añade “ruido”, ni visual, ni cognitivo, sino más bien lo contrario, aporta una pista sutil y que, de manera insconsciente, nos ayuda a diferenciar unos grupos de otros rápidamente.

El problema se presenta cuando la persona se topa con la letra mayúscula que abre cada grupo de etiquetas. -¿?- -¿Qué es esto…?- piensa. En ese momento se rompe el proceso inconsciente al encontrarse el usuario con algo inesperado que le lleva a tener que razonar e interpretar lo que está viendo. A partir de ahí el proceso requiere de su consciencia y atención:

• ¿Una letra mayúscula? ¿? –> ha de interpretar que las letras mayúsculas agrupan conjuntos de etiquetas que empiezan por las mismas.
• A continuación pasa a preguntarse por qué letra empieza la etiqueta buscada –> por “i” –> pasa a buscar el grupo de la “I” mayúscula –>una vez que lo ha localizado –>
• ¿Qué etiqueta estaba buscando y cuál es el siguiente carácter de la misma? –> “invertebrados” –> busca la palabra invertebrados en el conjunto de etiquetas identificado.

El diseño con letras mayúsculas para separar los grupos de etiquetas rompre nuestro locus de atención e interfiere directamente con la acción que se está llevando a cabo.

La altenativa de diseño B es más óptima dado que se juega con los espacios en blanco y no se incluyen terceros elementos como las letras mayúsculas que desencadenen un proceso de razonamiento consciente. La mirada fluye de manera natural por el listado, los espacios en blanco organizan las letras marcando los diferentes conjuntos de etiquetas y el locus de atención no se rompe, siendo el proceso mucho más rápido. La interfaz es más óptima.

REPENSAR LA INTERACCIÓN Y LAS METÁFORAS DE LOS SISTEMAS OPERATIVOS: DECONSTRUIRLOS

Las metáforas que utilizamos para dar forma a, y modelar los espacios de información, y los procesos de interacción de los actuales sistemas operativos requieren de un importante esfuerzo por parte del usuario para comprenderlos o llevarlos a cabo.

Las interrupciones son parte inherente de cualquier actividad. No obstante podemos optimizar los flujos de interacción de los actuales sistemas operativos para disminuir el esfuerzo cognitivo necesario para realizar las tareas que ejecutamos con ellos.

Si quiero modificar una imagen que estoy viendo en el navegador antes, tengo que llamar a una aplicación para llevar a cabo dicha actividad rompiéndose nuestro locus de atención ¿Por qué tenemos que usar una “aplicación” para editar una imagen si mi tarea es modificar una imagen, no lanzar una aplicación? ¿? A continuación tengo que pensar qué aplicación he de utilizar para ello. Ésta podría ser por citar una Photoshop. La siguiente tarea para conseguir nuestro objetivo sería dilucidar cómo lanzarla ¿Tendría que acudir al escritorio o al menú de inicio? En el menú de inicio, en Windows ¿debería buscarla en el box de búsqueda o ir a la lista de “Todos los programas” para localizarla. Si opto por esta última opción… ¿bajo qué carpeta -grupo de programas- la encontraría? ¿Carpeta? ¿? ¿Por qué usamos la metáfora de una carpeta del mundo real para representar algo que guarda una “aplicación” utilizando la misma metáfora para agrupar aplicaciones y documentos? ¿? Cuando he localizado la carpeta con la aplicación tengo que hacer clic en el icono que la abre, esperar a que se abra lo cual lleva un tiempo variable de ¿15 – 40 segundos…? ¿más? con la consiguiente distracción del usuario hasta que se abre. A continuación he de abrir la imagen que previamente debería haber salvado en el disco duro haciendo clic con el botón derecho del ratón sobre la misma en el navegador, de seleccionar la “carpeta” donde guardarla, y de pulsar el botón “Guardar” del correspondiente cuadro de diálogo.

El proceso y el tiempo que media desde que el usuario decide modificar la imagen que está viendo en el navegador hasta que empieza a editarla puede ser de… ¿3 minutos? ¿5? El proceso de modificar la imagen que estamos viendo en un navegador se termina subdividiendo en multitud de tareas con constantes interrupciones para llevar a cabo toda la serie de pasos intermedios que finalmente nos permitan dar cumplimiento a lo que queremos.

Opciones del menú secundario que se abre al pulsar el botón derecho del ratón sobre el icono de una imagen en el escritorio de Windows 7. Un total de 27 tareas posibles sin contar las que hay detrás de los submenús como el de la opción “Abrir con” de la captura de la imagen. El usuario tiene que hacer el ejercicio de identificar cuál es la tarea adecuada para modifica la imagen: “Abrir” “Edita con Fireworks” “Editar” “Abrir con” > “Adobe Fireworks CS4″, “Adobe Photoshop CS4″,  “Microsoft Picture Manager”, “Paint”, “Snagit Editor” ¿Cuál elijo y a qué coste cognitivo? ¿?

De todas las opciones que se me ofrecen sólo me interesa una: la editar.

¿Cómo podemos diseñar interfaces más optimizadas? ¿Interfaces más orientadas al modelo mental de las personas y no condicionadas por las limitaciones impuestas por el software o el Sistema Operativo?

Una posible solución es lo que Donald Norman denomina”Informática basada en actividades” (Activity-Based Computing, ABC) (5) :

“La idea básica es sencilla: tener a mano todo el material necesario para una tarea, con poco o ningún esfuerzo mental”

Sencillo de explicar, muy difícil hacerlo realidad…

Al menos hasta hoy día sólo se ha conseguido en parte, y sólo ahora comienzan a verse interfaces más centradas en las personas que en la propia tecnología.

Captura de pantalla del “Control por voz” del iPhone
Ahora… ¡¡podemos hablar con nuestros móviles para decirles lo que queremos que hagan…!! Ya iba siendo hora de que por fin podamos comunicarnos por voz con un dispositivo pensado para hablar por voz con otras personas… y aún así… ¿por qué se rotula la pantalla como “Control por voz”?
¿Por qué no mejor algo como… ¿Qué quieres hacer?? ¿? … La complejidad se carga en la tecnología, no en la interfaz.
También se puede prescindir del botón de “Cancelar” dado que ya tenemos el propio del teléfono para volver a la “Home” o “escritorio”.

Todavía hoy estamos anclados por el paradigma de las interfaces de unas máquinas y unos lenguajes de programación conceptualizados hace tres décadas y unos modelos de negocio empresariales orientados a maximizar la obtención de beneficios económicos antes que el beneficio para las personas, ejemplo del cual, por citar tan sólo uno, es el actual modelo de aplicaciones que se ha desarrollado para los nuevos móviles “inteligentes”, una oportunidad de oro perdida para centrar de verdad la informática en donde tiene que estar centrada, en las personas, no en la forma de hacer dinero.

Norman (6) establece una jerarquía en los procesos que está conformada por (desde la más alta a las más bajas):

• Actividades: conjunto de tareas dirigidas a unos objetivos concretos -poner al día las cuentas de casa- -llamar a un amigo- son dos posibles ejemplos de actividades.
• Tareas: aquellos pasos que seguimos para llevar a cabo los objetivos subordinados de las actividades.
• Acciones: conjunto de operaciones que llevamos a cabo para ejecutar una tarea, por ejemplo, una operación al escribir una palabra puede ser teclear un carácter y la acción, escribir la palabra.

La Interfaz Humana (prefiero éste término al de Sistema Operativo, ajeno a las personas) ha de estar centrada en las actividades, no en las tareas. No en tener que pensar en qué programas o aplicaciones “estancas” necesito para llevarlas cabo.

No en algo llamado Mozilla Thunderbird sino en escribir un mensaje y en mandárselo a mi hermana.

Aza Raskin explica muy bien un nuevo modelo de negocio que podría convertirse en una alternativa al de la informática actual (que está basado en aplicaciones y programas, algo que entra en constante conflicto con nuestro modelo mental que tenemos como personas que somos) y que es igualmente viable desde un punto de vista económico y más centrado en las personas.

Un ejemplo de ello es la evolución que están sufriendo los navegadores. El navegador se está transformando en una capa que está envolviendo a los sistemas operativos convirtiéndolos en interfaces “más humanas” orientadas a responder nuestras actividades cotidianas:

• las necesidades de interrelación social -redes sociales –> Facebook, Tuenti-
• las necesidades de comunicación –> Twitter, Skype, Google Voice, GMail, Hotmail…-
• las de productividad -búsqueda y localización de información –> Google, Bing-
• para servirnos como memoria –>almacenamiento en la nube –> Google Docs, Dropbox-
• y para la recuperación, gestión y aprovechamiento de la información –> Google, Bing, Google Docs…

Y lo están empezando a hacer de forma bastante más eficaz que los sistemas operativos. Integrando todo ello en una interfaz deconstruida que se centraliza en un campo de entrada de texto que está dejando de ser “barra de navegación” para convertirse en “barra de interacción”:

La AwesomeBar HD permite seleccionar un comando para, a continuación, escribir la necesidad de información.
Pulsando a continuación retorno se ejecuta la acción (por ejemplo, se presenta la página de resultados de Amazon
con los títulos de los libros que coinciden con las palabras escritas

El binomio Web-navegador está reemplazando a los sistemas operativos por algo más cercano a nosotros y ha de seguir evolucionando.

Un posible camino para ello y hacia una interfaz más humana puede ser el proyecto en el que está trabajando MozillaLabs –> AwesomeBar HD que no es sino una pequeña adaptación de algo mucho más potente, Ubiquity, una metainterfaz que se sitúa por encima del sistema operativo y que se integra plenamente en el navegador. La comunicación tanto con la AwesomeBar HD como con Ubiquity se da mediante palabras escritas y comandos muy específicos aunque el día de mañana quizá podra darse también a través de la voz y en un lenguaje natural. Una interfaz como Ubiquity permitiría simplificar el proceso de editar una imagen para que fuese algo así como seleccionarla en el navegador, hacer clic en la barra de navegación, escribir “modificar”, y lanzar la interfaz en la misma ventana para llevar a cabo la acción. Compararlo con el anterior proceso descrito…

Desde un punto de vista cognitivo mucho mejor.

La AwesomeBar HD da continuidad al proyecto Ubiquity, un éxito tan rotundo y algo tan innovador e importante que posiblemente lo estarán desarrollando internamente. La AwesomeBar HD no es más que un vistazo a lo que veremos a medio plazo.

Google podría hacer algo similar y la verdad, es que es sorprendente que todavía no lo hayan hecho, evolucionar su interfaz para pasar de un buscador a un asistente personal que guíe al usuario en su interacción con la Web. Medio trabajo ya lo tienen hecho, la pregunta que deberían plantearse los ingenieros de Google es la de cómo podrían unificar las funcionalidades de los diferentes box de búsqueda-interacción de los distintos servicios que ofrecen: Gmail, Google Docs, Google Calendar, Google Translate… en el box del buscador principal.

Recuperar la idea del sistema operativo, ubicuo, multimodal y humano, vamos

Quizá mañana, Mozilla, Google, Microsoft o Apple vuelvan a sorprendernos.

Seguro que sí.

–O–

BIBLIOGRAFÍA:

1. Fernández Abascal, Enrique G.; Martín Díaz, María Dolores; Domínguez Sánchez; Javier. Procesos psicológicos. Madrid : Ediciones Pirámide, p. 52. ISBN 978-84-368-1605-1
2. – Ibid. p. 36.
3. Raskin, Jef. The Humane Interface: New directions for designing interactive systems. Boston : Addison Wesley, p. 16, ISBN: 0-201-37937-6
4. – Ibid. p. 17.
5. Norman, Donald. El ordenador invisible. Paidós : Barcelona, p. 101. ISBN 84-493-1089-X
6. –Ibid, p. 102.

De los que conozco es el que más me gusta por lo rápido que actualiza el timeline,  por su capacidad para previsualizar imágenes y por la posibilidad de acortar URLs dentro del propio cliente. No obstante en cuanto a su interfaz, tiene algunas serias limitaciones que causan el que, día sí, día también, la interacción no sea lo que se dice eficiente provocando entre otros errores:

• Envío de tweets que tengo a medio redactar.
• Envío de tweets con erratas ortográficas que estoy corrigiendo cuando pulso accidentalmente el botón de envío.
• Envío de tweets con URLs incorrectas al tener que copiarlas a mano dado que el cliente de Twitter no es un navegador y no se puede obtener en el mismo la URL corta de una página web. Para ello si utilizamos el móvil, hay que acudir a un navegador externo ya sea el del propio Android u otro instalado por nosotros, entrar en la página, dirigirse al historial o a la barra de navegación si se utiliza Opera, seleccionar la URL, ir a Twidroyd, pegarla, pulsar sobre el botón de acortar URL, editar el resto del tweet y enviarlo. La alternativa a este despropósito es hacer las operaciones equivalentes en el ordenador -si se está delante de uno- obtener la URL corta en cualquier servicio que lo posibilite y escribirla a mano en el tweet que se está editando en Twidroyd asegurándose uno muy bien de que está correctamente escrita para no cometer errores.

Ésta es la interfaz de Twidroyd:

Figura 1. Interfaz de Twidroyd, un cliente de Twitter para Android

Algunos de sus elementos son:

1. Botón para escribir un tweet: Al pulsarlo despliega el teclado y el áera para escribir (3) y oculta el timeline.
2. Actualizar: Refresca el timeline y carga los últimos tweets.
3. Área de texto para escribir el tweet.
4. Acortador de URLs: al escribir una URL larga en el área de texto y pulsar sobre el mismo el cliente la acorta automáticamente.
5. Botón que permite adjuntar un enlace a un vídeo, hacer o seleccionar una foto de la galería de nuestro móvil y añadirla al tweet o insertar un vídeo que tengamos.
6. Botón de publicar el tweet.

Fijaros que entre los botones (1) y (2) no existe separación, están uno al lado de otro y entre el (4) (5) y (6) existe un espacio muy pequeño de separación.

Debajo de estos últimos hay otra barra justo encima del teclado un poco más oscura con más botones que corresponden de izquierda a derecha a:

1. Visualizar el timeline (lleva a la pantalla “home” de la aplicación).
2. Mostrar tweets enviados o que le mencionan a uno.
3. Mostrar la bandeja de entrada con los mensajes directos.
4. Buscar en Twitter.
5. Mostrar el resto de las funcionalidades de la aplicación: perfil, contactos, etc.

Este es el aspecto que tiene Twidroyd cuando se está redactando un tweet:

Figura 2. Interfaz de Twidroyd con texto en el área input. Obsérvese la proximidad entre el final del texto del tweet (la palabra “funciones”) y el botón de publicación del mismo, justo debajo.

Figura 3. Interfaz de Twidroyd. Áreas destino o sobre las que la yema del dedo hace clic
para pulsar el botón que corresponda

Uno de los principales problemas de usabilidad que tiene la interfaz de Twidroyd y que se puede extrapolar a otras aplicaciones móviles es el escaso espacio que suele existir entre los diferentes botones de acción de la aplicación lo que suele causar que, en ocasiones, se lance una función determinada que no es la que el usuario quiere, en lugar de la deseada.

En cuanto a la separación horizontal de botones un problema que tiene Twidroyd es que queriendo escribir un nuevo tweet se suele pulsar sin desearlo el botón de actualizar el timeline (A, figura 3) lo que refresca el mismo y muestra los últimos tweets. En este caso el error de usabilidad no tiene un mayor impacto.

Al estar tan próximos los botones, el área de interacción sobre ellos cuando se usa un dedo (que puede ser más o menos gordo), puede montarse ya que, aunque el punto de interacción se calcula como el punto medio del área sobre la que toca la yema, dicha superficie puede variar en función de la presión que se ejerza sobre la pantalla o de la precisión con la que se toque. Si uno está andando o se hace con un toque rápido a veces es difícil acertar pudiéndose llegar a pulsar el botón que no se quiere.

Figura 4. El punto de interacción donde se toca la pantalla se calcula en el punto medio
de la superficie de la yema del dedo que toca la misma.

El problema de la separación de botones se da tanto en horizontal como en vertical.

Esto es lo que sucede en el segundo gran problema de usabilidad que tiene Twidroyd.  Cuando se alcanza el final del área de texto en la que se está escribiendo el tweet, la última palabra queda muy próxima al botón de publicación (B, figura 3). Si como sucede muy habitualmente se ha escrito mal la palabra (el teclado virtual del Magic es muy pequeño por las dimensiones de la pantalla y da problemas) o si el sistema de autocorrección la sustituye por otra incorrecta (lo cual es también muy común) hay que pulsar sobre la pantalla para posicionar el cursor en la letra que se desea corregir. Al encontrarse la palabra al final del área de texto e intentar tocar ahí con el dedo, en buen número de ocasiones se pulsa el botón de envío que está debajo publicándose el tweet sin querer. A partir de entonces la experiencia de usuario queda totalmente machacada ya que:

• Hay que esperar a que Twidroyd publique el tweet lo que en ocasiones puede tardar bastante por la lentitud de la conexión 3G.
• Cuando se ha publicado hay que copiarlo al portapapeles si no se quiere tener que escribirlo nuevamente entero.
• Hay que borrar el tweet incorrecto.
• Hay que pegar el texto del portapapeles en un nuevo tweet y editarlo (y ojo con no equivocarse y  no pulsar accidentalmente donde no se debe no haya que empezar otra vez todo el proceso).
• Finalmente hay que publicarlo.

No he hecho el cálculo de cuanto tiempo puede llevar todo esto pero grosso modo, en torno a 4 minutos. Pensad lo que eso supone desde un punto de vista de Experiencia de Usuario y las consecuencias que tiene :-P

Resumiendo, un aspecto crítico para una buena usabilidad de las aplicaciones en móviles y más concretamente en Android es el tamaño y posicionamiento de los botones. Al respecto se han de tener en cuenta las siguientes directrices generales:

• El tamaño de los botones tiene que ser suficientemente grande y alto como para que puedan ser pulsados por un dedo sin problemas:
  • Apple establece que el área donde se toque la pantalla (área destino) ha de ser como mínimo de 44 x 44 píxeles 44×44 puntos y que los botones no han de estar demasiado juntos para evitar problemas al pulsarlos (página 95 de las Directrices de Interfaz Humana del iOS: Experiencia de Usuario).
  • Microsoft por su parte en la Guía de Interacción y de diseño de Interfaz de Usuario para Windows Phone 7, página 38, recomienda que el área destino no sea más pequeña de 9 milímetros o no inferior a 34 x 34 píxeles proporcionando además, y al menos, 2 milímetros u 8 píxeles de espacio entre botones.
• El tamaño de los botones tiene que ser asimismo suficientemente largo como para que puedan ser pulsados sin problemas: Haciéndolos más largos que altos se atenúa y disminuye el problema en cuanto al área de pulsar horizontal. No obstante hay que tener en cuenta también que hay que dejar una buena separación vertical.
• Por último, no se han de pegar los botones a los márgenes de la pantalla del dispositivo, especialmente en el caso de los móviles ya que se pulsan con mayor dificultad dado que, a menos que la pantalla esté al mismo nivel que los bordes del dispositivo, la yema del dedo puede quedar a caballo entre pantalla y borde del dispositivo y no terminar de pulsarse correctamente el botón.

ANALÍSIS DE CALENDARIOS

Una de las cosas que me llama particularmente la atención desde hace ya unos años y cuyas tendencias me gusta observar para ver cómo evolucionan, es el diseño, tanto desde un punto de vista gráfico como de interacción, de los calendarios de las páginas de compañías áreas, agencias de venta de billetes de vuelos, webs de aeropuertos, hoteles, alquiler de coches, transportes públicos o privados o cualesquiera otras de comercio electrónico que por una u otra razón de acuerdo a su negocio incluyan en su home calendarios para acotar el tiempo de estancia, viaje, desplazamiento o actividad similar del usuario.

Por citar tan sólo algunos a título de ejemplo de los miles que pueden encontrarse en la Web y tratar de extraer algunos patrones más o menos generales a día de hoy en cuanto a su diseño, pueden citarse los siguientes:

Calendario de BestWestern.com

El componente del calendario “Encontrar un hotel” de BestWestern.com tiene como elementos interesantes:

• Se despliega cuando el usuario hace clic directamente en el campo de la fecha de entrada.
• Aparece alineado con la línea base del campo de fecha de entrada, con la esquina izquierda.
• No incluye ninguna sombra para crear un efecto de oclusión y traerlo a primer plano lo que resulta en un diseño completamente plano. Esto supone un menoscabo de su usabilidad dado que por su diseño gráfico y los colores elegidos cuesta distinguirlo visualmente del fondo.
• Presenta como valor por defecto la fecha del día actual.
• Junto a los campos de entrada de las fechas muestra un icono de calendario cuyo diseño es más o menos estándar a lo largo de la Web reconociéndose sin problemas como tal.
• En la esquina superior derecha incluye un botón de cerrar que por su diseño y color pasa prácticamente desapercibido.
• Debajo de la barra de cabecera presenta un listado horizontal de los 12 meses siguientes al actual pudiendo el usuario seleccionar aquel que desee. Su utilidad es interesante aunque el horizonte de 12 meses de cara a realizar una reserva en un hotel puede ser excesivo. Habría que testear y ver estadísticamente cuáles son los rangos de fechas más comúnmente utilizados por los usuarios para limitar los meses que aparecen en esta barra a ellos.
• Por defecto en el calendario se muestra el mes en curso y al lado, en horizontal, el mes siguiente, ambos con su correspondiente encabezado identificativo del nombre abreviado y resaltado en negrita.
• Debajo se muestran los días de la semana. Aparecen en mayúsculas y con una sóla letra para identificar el nombre de cada día.
• A continuación se muestran los días del mes comenzando desde el primero y dejando en blanco los espacios correspondientes a los días del mes anterior (lo mismo sucede con los últimos días del mes que tampoco se muestran).
• Los días aparecen recuadrados. Los que están por venir con un borde azul, y los que han pasado con un borde gris claro. La presencia del borde recuadrándolos supone una ayuda visual adicional para marcar el área dónde se puede hacer clic para seleccionarlo. Esto mejora el foco pero añade un ruido excesivo desde un punto de vista visual que menoscaba la escaneabilidad de los números y la usabilidad general del calendario. Demasiada “tinta” superflua.
• El día actual se destaca en rojo.
• El día seleccionado como fecha de entrada (por defecto el siguiente al actual) se destaca con una cama de color azul, en negrita y con un borde azul oscuro para resaltarlo de los demás.

Calendario de HalcónViajes.com

Del calendario de HalcónViajes.com se pueden citar las siguientes características:

• El tamaño es muy superior a lo que suele ser habitual en el diseño de este tipo de componente, quizá demasiado lo que impacta en la correcta escaneabilidad de los días.
• Sólo muestra el mes en curso lo que disminuye la usabilidad.
• Desde un punto de vista gráfico presenta un ruido visual excesivo mostrando explícitamente una cuadrícula gris en cuyos recuadros encajan los números. Su gran tamaño los hace más difíciles de leer.
• Los días del mes que ya han pasado hasta la fecha actual se presentan en un estado atenuado en color gris claro. El día actual se presenta destacado en una cama de color gris más oscuro. Los días disponibles para hacer la reserva se presentan en un crema suave. El día seleccionado seleccionado se muestra en un calabaza, color que también se usa para el hover del ratón a medida que se va desplazando por encima de los días del mes.
• Incluye una leyenda de los colores en la parte inferior.
• Permite cambiar de mes haciendo clic en el botón amarillo junto al nombre del mes actual que sirve como minicabecera del calendario. El diseño de esta cabecera no es óptimo ya que tal y como está resuelta gráficamente parece a priori un campo de entrada de texto en el que se puede escribir, cuando no lo es. La única forma de cambiar de mes es haciendo clic en las flechas a derecha e izquierda del nombre del mes.
• El botón de cerrar tiene una forma y diseño llamativo, circular con una X. Está situado en la parte superior, a mano derecha y a la misma altura que el encabezado general del componente.
• Al desplegarse el calendario se tapa por completo el módulo inferior para la selección de la reserva y se presenta una capa semitransparente que oculta la página web de debajo lo que centra la atención en el mismo y no en otros elementos de la interfaz.
• El calendario se cierra al seleccionar una fecha en el mes o mediante el botón de cerrar.

Calendario de Hoteles.com

El calendario de Hoteles.com es quizá uno de los más limpios e interesantes de los que aquí se han analizado. De él se pueden reseñar las siguientes características:

• Se despliega con un efecto de rápida animación hacia la derecha al hacer clic en cualquiera de los campos de fecha de llegada o salida lo que a priori transmite al usuario un feedback de rápidez y eficacia de su funcionamiento asi como de la página.
• Incluyen un icono de calendario al lado de dichos campo que cuando se pulsa despliega asimismo el calendario.
• Incluyen al lado de los dos campos de fecha de llegada y salida el número de noches correspondiente a las fechas que el usuario ha escogido. Un buen detalle diferenciador que no se ve en otros sitios.
• Su diseño es minimalista utilizando un número muy reducido de colores en la escala de blancos y grises lo que impacta de forma positiva en su usabilidad al ser fácilmente escaneables todos los elementos que lo componen.
• Utiliza una sombra para crear un efecto de oclusión lo que ayuda a diferenciarlo del fondo, centra la atención en él y lo trae a primer plano.
• Utilizan una flecha sólida en la parte superior izquierda como elemento de diseño que rompe la linealidad del componente y lo conecta al campo de entrada algo que no suele ser habitual pero que constituye un diseño elegante en línea con las tendencias que se pueden observar en las últimas versiones de determinados elementos de interfaz de Firefox o  del sistema operativo Leopard de Apple.
• La tipografía utilizada es muy clara, limpia y legible así como los cuerpos de letra usados.
• No utilizan ninguna letra capital sino que ponen todas en minúsculas lo que mejora la escaneabilidad de los textos y los iguala jerarquicamente. Sería interesante ver si convendría destacar los meses poniendo su primera letra en mayúsculas para crear un punto adicional de tensión visual.
• El botón azul con la flecha blanca de la derecha para mostrar otros meses tiene un buen diseño percibiéndose como un elemento sobre el que se puede hacer clic.
• Presenta el mes en curso y el mes siguiente, en horizontal uno al lado del otro y separados por una fuerte línea gris al medio.
• En cada mes sólo muestra los días correspondientes al mismo, no los de antes ni los de después dejando los espacios en blanco.
• Los días del mes que han transcurrido desde el primer día hasta la fecha actual se presentan atenuados en color gris claro y no son seleccionables.
• El día de la fecha seleccionada de llegada se muestra destacado en una cama de color gris claro con el día en color inverso (blanco) para un óptimo contraste.
• El día de la fecha de salida se muestra en un patrón de color inverso – recuadrado en gris y fondo blanco. El período seleccionado no termina de quedar del todo claro al no guardar el día de entrada y el de salida el mismo color (ver captura algo más abajo). Puede suponer un problema de usabilidad ¿Hasta qué día está seleccionado realmente? ¿Hasta el 14 ó el 15?
• Por defecto cuando se despliega el calendario aparece seleccionado el día siguiente al actual, tanto en el campo de entrada sin haber desplegado el calendario como al mostrarse el mismo.
• Para cerrar el calendario basta con hacer clic en cualquier parte de la interfaz que no sea el propio calendario.

Período de días selecionados en Hoteles.com. Existe un problema de usabilidad entre el uso de los calendarios, la forma de destacar
el día de entrada y el de salida y los campos superiores para especificar las mismas.

Calendario de Expedia.com

El diseño del calendario de Expedia.com está muy en la línea del de Hoteles.com y es igualmente un diseño limpio. Como características interesantes caben citar:

• En el campo de entrada no figura la fecha del día actual sino expresada en formato dd/mm/aa. Lo positivo de expresarla así es que no entra en conflicto mental con la fecha o día que el usuario tiene en la cabeza en un primer momento al observar el elemento. Si su objetivo fuera por ejemplo seleccionar el período del 15 de diciembre al 18 de enero y se encuentra a priori como fecha de entrada la del día actual necesita un tiempo para darse cuenta de por qué está ahí esa fecha que no es la que quiere y no otra. Poner la fecha en formato de día, mes, año – dd – mm – aa tiene la desventaja de que al no ser una fecha real requiere un  esfuerzo cognitivo para interpretar que se refiere a una fecha y no a otra cosa, no obstante al ser una manera habitual de expresarla es preferible a priori que poner la fecha actual por defecto. No poner fecha tiene el inconveniente de cara a accesibilidad  de que los lectores de pantalla para invidentes se encontrarían con un campo vacío y sin ninguna indicación de cuál sería el formato que tendrían que usar para introducirla.
• No utilizan ningún icono de calendario junto a los campos de fecha de salida y vuelta. Con la fecha en formato dd/mm/aa y el rótulo de Salida / Vuelta encima de cada campo es suficiente indicio de qué tipo de dato se está pidiendo en el mismo.
• El calendario se despliega debajo del campo de entrada de fecha correspondiente, pegado al mismo, alineado en la esquina inferior izquierda.
• No tiene una sombra debajo pero solucionan el problema de la superposición de capas y su diferenciación del fondo mediante un borde de un píxel de un azul más saturado que el resto de azules de los demás elementos lo que lo singulariza y lo destaca frente a ellos.
• Tiene una cabecera muy clara y fácilmente distinguible que funciona como agrupadora de toda la información inferior. Dicha cabecera incluye el nombre del mes en curso y del siguiente mes, asi como una flecha a mano derecha que permite avanzar de mes a medida que se pulsa.
• El botón para avanzar de mes tiene un buen diseño percibiéndose como tal.
• Resuelven la doble cabecera de los nombres de los meses y los días de la semana poniendo estos últimos debajo de la cabecera superior pero en el mismo color que el de fondo de la cabecera con el nombre de los meses. Asimismo ponen las abreviaturas de los días de la semana en mayúsculas. Ello tiene dos efectos a) vincula semánticamente a través del código de color cabecera principal con el nombre de los meses y cabecera secundaria con las abreviaturas de los días y b) potencia estos últimos respecto al resto de elementos del calendario.
• El diseño es minimalista y no utilizan ningún tipo de cuadrícula ni enmarcado en los números de los días. No obstante emplean el recurso de ofrecer un recuadro de color beige claro amplio encuadrando el número del día a medida que el cursor se desplaza por encima de ellos lo que constituye una potente ayuda y feedback visual adicional junto al cambio de cursor en forma de mano, para ofrecer un feedback al usuario del área que es clickable.
• Utilizan un código de color para los números del calendario muy similar al de BestWestern.com. a) Para los días transcurridos del mes desde el primero hasta el actual usan un gris claro que los hace aparecer como atenuados o no seleccionables (cuando el cursor se posiciona sobre ellos no hay un efecto hover de recuadrado). b) El día actual lo ponen en negrita y en color rojo lo que lo hace destacar respecto a los demás. c) El resto de días del mes va en color negro y negrita. Quizá sería interesante ver una prueba de diseño de los números sin negrita para ver cómo quedan. d) El día seleccionado se muestra con una cama de color gris cuadrada de fondo y el día en negrita y negro para señalarlo como activo.

Calendario de ChoiceHotels.com

ChoiceHotels.com plantea un diseño del buscador diferente a lo que suele ser habitual (echarle un vistazo) que llama la atención. En lugar de ser un gran módulo vertical lo plantean en horizontal todo a lo largo de la pantalla lo que resulta en una menor usabilidad dado que a la distancia habitual a la que el usuario suele estar sentado respecto al monitor (en torno a aproximadamente a 60 centímetros – 1 metro) no se puede abarcar todos sus elementos con la mirada. El área sobre la que se centra nuestra mirada y nuestra atención es menor, en torno a unos 10 – 15 centímetros lo que resulta en que, para comprobar que todos los datos introducidos en el buscador se corresponden con los que desea, el usuario debe realizar constantes barridos con la mirada de izquierda a derecha y viceversa impactando de forma severa en la usabilidad. En cuanto al diseño de los elementos propios del calendario caben reseñar las siguientes características:

• Incorporan tanto en el campo de fecha de entrada como de salida una indicación de cómo debe escribirse (en el formato estándar -mm/dd/aa-).
• Al hacer clic en cualquiera de los campos se despliega la capa con el calendario de forma inmediata.
• El calendario está alineado con la línea base del campo correspondiente, con la esquina inferior izquierda y pegado al mismo sin dejar ni un pixel de separación lo que refuerza la relación entre campo y calendario.
• Su fondo es totalmente blanco con un tenue borde gris que lo recuadra y lo realza respecto a la imagen de fondo. Este borde además produce un curioso efecto:

El color gris del borde del calendario es el mismo para toda la capa pero se percibe de forma diferente en la parte superior y en la parte inferior:

En la parte superior, en los trozos en los que la capa coincide con los campos de fecha de entrada, de salida, habitaciones, número de adultos, niños y categoría de hotel el calendario se percibe con un efecto de hundido debido a que se da una interesante ilusión óptica por el contraste simultáneo de dos tonos de gris, el más claro de la parte inferior de los campos y el más oscuro del borde de la capa del calendario.

Por el contrario en la parte inferior se produce el efecto inverso, el gris oscuro del borde junto al blanco de fondo aislan la capa del calendario respecto a la imagen de fondo haciéndolo aparecer como en relieve. Un efecto llamativo que ayuda a realzar su usabilidad.

• La capa de calendario está “conectada” al campo de fecha de entrada sin dejar un sólo pixel de separación entre campo y capa.
• Llama la atención el diseño de la cabecera de los meses en la que se utiliza la Ley de cierre de la Gestalt para “dibujar” un rectángulo imaginario que sirve como agrupador, que va desde las esquinas de las flechas de avanzar – retroceder de mes y que incluye los nombres de cada mes.
• Este diseño de la cabecera de los meses “al aire” deja fluir la mirada por los elementos del calendario aportando una sensación de ligereza. La negrita refuerza los nombres de los meses como puntos de atención focal que asimismo aparecen con una fuente tipográfica un punto mayor que la utilizada para los nombres abreviados de los días de la semana. Estos aparecen igualmente en negrita y tanto nombres de meses como días de la semana tienen la primera letra en mayúsculas lo que crea en cada uno de ellos un punto focal que disminuye la legibilidad.
• Cómo en los diseños de otros sitios, dejan en blanco los espacios correspondientes a los días que no se corresponden con los del mes, tanto al principio como al final.
• Recuadran todos los días con dos tonos de grises. Para los transcurridos desde el primer día del mes utilizan un gris claro que los hace aparecer como atenuados o no seleccionables.
• El día actual lo recuadran con un borde gris más oscuro que los demás y con una cama de color gris claro sutil que lo destaca.
• El día seleccionado se muestra con una cama de color beige y con el número en negro para un óptimo contraste. No se utiliza negrita y el borde va en un naranja más fuerte el color sólido de fondo y que lo hace aparecer como activo. Es una combinación óptima de colores.
• Llama la atención el hecho de que alinean los días al borde derecho del recuadro que los enmarca lo que crea una sensación de movimiento del componente hacia la derecha.

Calendario de Hotwire.com

El calendario de Hotwire.com aporta un diseño que se sale igualmente de lo habitual:

• Dejando de lado características ya analizadas en los anteriores calendarios (formato de fecha de entrada, huecos en blanco para los días de la semana de principios y finales de mes, días atenuados en gris claro para los transcurridos desde el inicio del mes hasta el día actual y que no son seleccionables, día actual resaltado -en este caso con un recuadro gris claro, días del mes en negrita para que destaquen más… etc, la principal característica es que presenta los meses en vertical, uno encima de otro, lo que mejora la legibilidad y escaneabilidad de los mismos.
• No obstante tiene el inconveniente de que cada mes lleva una cabecera muy marcada en gris con su nombre, y debajo las abreviaturas en negrita de los días de la semana, sin cama de color. Esto interrumpe y “parte” el flujo natural de lectura de los días de un mes a otro menoscabando la usabilidad.
• Muestra una leyenda en la parte inferior con el color verde que usan para marcar los días de la fecha de entrada y salida.

Calendario de Hotwire.com con las fechas de entrada y salida seleccionadas

• Otro problema es que sólo marcan los días correspondientes a estas fechas (entrada y salida) y no el período completo de estancia de la persona en el hotel.
• Para cerrar el calendario no incorporan ningún botón. Haciendo clic en cualquier parte de la interfaz fuera del mismo desaparece.

Uno de los inconvenientes que presentan los benchmarkings es que aunque pueden ayudar a innovar mediante el estudio de las característics de los diseños de los competidores pueden suponer asimismo un marco restrictivo de cara a  la innovación dado que los clientes en muchas ocasiones se ciñen a lo que hace la competencia para evolucionar sus sitios. Por ello es interesante investigar soluciones de diseño de otros ámbitos. En este caso concreto, uno de los diseños más interesantes de calendario que he visto lo tiene Google Analytics:

Calendario de Google Analytics

• Frente a todos los anteriores, Google Analytics presenta un único punto de interacción para desplegar el calendario (campo con las fecchas o flecha a mano derecha del mismo)  y para seleccionar tanto la fecha de inicio como la de final en el mismo sin necesidad de desplegar dos distintos, uno para la fecha y otro para la de salida, como sucede en todos los demás diseños.

• Presentan tres meses por defecto para la selección de las fechas.
• Tienen una doble cabecera compuesta por los nombres de los meses, que lleva una cama de color gris y el nombre del mes con la primera letra mayúscula. Además van sin negrita.
• A mano izquierda y derecha de esta cabecera muestran flechas que permiten mostrar los meses siguientes o los anteriores. Destaca el hecho de que, al igual que en el diseño de Hotwire.com, ponen las dos flechas desde el principio aunque en un primer momento no podemos ir más hacia el futuro que el mes actual. En este caso debería presentarse la flecha como deshabilitada para dar a entender que en ese punto no se puede interactuar con ella.
• Los meses están separados entre sí visualmente y a mano izquierda de cada uno de ellos aparecen medios círculos en las filas de cada semana. Haciendo clic en estos medios círculos se selecciona la semana entera. Aunque esta característica puede tener sentido en una herramienta como Analytics no interesa tanto en los calendarios de páginas de comercio electrónico dado que la diversidad de períodos no suele ceñirse a una semana concreta.
• Incorporan un enlace rotulado como “Cancelar” que tiene un funcionamiento que puede dar lugar a dudas. Por defecto las fechas que aparecen seleccionadas cuando se entra en una cuenta específica de Analytics van desde el día actual hasta justo un mes antes. Si el usuario hace otra selección se pierden dichas fechas. Al contrario de lo que podría pensarse al estar al lado del botón de “Aceptar” el enlace de “Cancelar” no cierra el calendario desplegado y cancela la selección de fechas realizada sino que borra la selección hecha por el usuario y pone la que el sistema da por defecto.
• Al contrario que el resto de calendarios en el de Google Analytics no se dejan espacios o huecos en blanco al inicio o final de los meses. Se ponen los días del siguiente mes o del anterior pero en un gris muy claro, como atenuados.
• Para seleccionar un período el patrón de interacción es el siguiente:
  • El usuario puede escribir directamente la fecha de inicio y la fecha de fin en los box de los campos rotulados como “intervalo” o hacer clic directamente en un día del calendario. Este primer clic marca la fecha de inicio y el segundo la fecha final.
  • Una vez marcada una fecha como de inicio todos los días anteriores a él se muestran en gris claro y no son seleccionables.
  • Cuando el usuario marca a continuación la fecha de fin el período completo seleccionado se muestra con una cama de color azul para resaltarlo de forma inequívoca de los demás.
  • En el período seleccionado utilizan dos tipos de azules, uno fuerte para marcar los días del mes seleccionado y otro más clarito para marcar aquellos que corresponden al mes siguiente. El diseño en este punto es confuso.

PROPUESTA DE DISEÑO DE CALENDARIO

En base a las características analizadas se plantea la siguiente propuesta de diseño para mejorar la usabilidad de los calendarios de páginas de comercio electrónico. Como ejemplo se tomará una página de reserva de hoteles:

1. El usuario accede al sitio web y observa el módulo para buscar hoteles y reservar habitaciones.
2. Hace clic en el campo de “Fecha de entrada – Fecha de salida” y se despliega el calendario.
   • Éste tiene una sombra para crear un efecto de oclusión que lo trae a primer plano y lo singulariza del fondo. Con ello se centra la atención en el calendario respecto al resto de elementos de la página y se mejora su usabilidad.
   • El campo de las fechas está vacío a priori dado que el funcionamiento que se desea en este punto es el de desplegar lo más rápidamente posible el calendario. Al aparecer vacío el usuario no tiene que pensar un segundo analizando qué puede significar un valor como dd/mm/aaaa.
   • Cuando se hace clic en el campo de fechas el calendario que se despliega se vincula a al mismo por medio de una flecha a mano izquierda que apunta al medio del box (ver paso 3)
   • El hecho de que exista un único punto para desplegar el calendario como sucede en Google Analytics es una mejora importante de usabilidad. Uno de los principales problemas que tiene el actual modelo de interacción que se tomar como un estándar a lo largo de la web para seleccionar las fechas es que el proceso de seleccionar un período se divide en dos partes: a) selección de la fecha de entrada y b) selección de la fecha de salida, cuando ambas deberían seleccionarse actuando sobre un único calendario tanto por economía de clics como para facilitar la correcta visualización del período seleccionado.
3. El calendario tiene en la esquina superior derecha un enlace y botón de cerrar por accesibilidad. A continuación y por defecto, el cursor se encuentra en el box del campo de “Fecha de entrada” que aparece bordeado de color naranja para indicar su estado activo.
   • Ahora sí, como valores por defecto tanto en el campo de fecha de entrada como en el de salida aparece la fecha en formato estándar pero sin seleccionar ningún día concreto: día, mes, año -dd/mm/aaaa-.
   • Para especificar el año se utilizan cuatro dígitos con el objetivo de distinguirlo de forma únivoca tanto de los días como de los meses aunque ello suponga dos pulsaciones más de teclado para introducir los datos. A la hora de maquetar el componente será necesario controlar correctamente el orden del foco del cursor al pulsar el tabulador para garantizar una usabilidad y accesibilidad óptimas.
   • El usuario puede optar por escribir las fechas directamente en los campos correspondientes  o seleccionar la fecha de entrada y de salida con el cursor del ratón haciendo clic sobre los días correspondientes.
   • Por defecto se presentan hasta 3 meses incluyendo el actual, no obstante habría que monitorizar cuál es el tiempo medio que los usuarios eligen como periódo para ver si se pueden mostrar tan sólo dos. Mostrar un mes menos simplifica el diseño y lo hace más fácil para el usuario.
   • Los meses se muestran en vertical, unos encima de otros, de forma similar a como se hace en Hotwire.com lo que supone asimismo una mejora importante de usabilidad ya que facilita el escaneado visual de los días, no interrumpe el flujo visual al separar en diferentes áreas los meses, suprime la necesidad de que haya espacios en blanco tanto al principio como al final de cada mes y mejora la densidad informativa del calendario.
   • Para distinguir dónde comienza y dónde finaliza cada mes se utiliza una línea gris clara punteada que marca  tanto el inicio como el final de cada mes. La línea quebrada en el primer día del mes supone un punto de ruptura visual actuando como foco de atención lo que ayuda a mejorar la escaneabilidad de la información. Los días de los 3 meses fluyen de forma natural unos detrás de otros sin interrupción visual alguna.
   • Estas líneas que separan los días correspondientes a cada mes se conectan a mano izquierda con el nombre de cada mes que va en un rectángulo sólido de color gris más fuerte, con los nombres de los meses en minúsculas y la primera letra en mayúscula para actuar como atractor visual sutil. Se ha hecho la prueba de centrar el rectángulo conforme al punto medio de la línea pero la conexión queda más clara alineando la parte inferior del rectángulo con dicha línea en la esquina inferior derecha.
   • Encima de los nombres de los meses, dos flechas permiten ir avanzando en el tiempo o retrocediendo para mostrar los meses anteriores o siguientes. A priori se muestra el mes actual y los dos siguientes. Dado que no tiene sentido retrocer más allá de la fecha actual para realizar una reserva, en un primer momento la flecha de ver meses anteriores se encuentra desactivada y aparece en un color más claro.
   • Los días transcurridos desde el primero del mes hasta el actual aparecen en un color gris más claro, atenuados y no son seleccionables.
   • El día actual no se resalta de ninguna forma. El cambio de color entre los días anteriores al actual y el día presente es suficiente para dar un feedback al usuario de cual es la fecha actual. No tiene sentido destacar la fecha actual ya que al usuario lo que le interesa es seleccionar los días en los que quiere hacer su reserva.
   • Cierra el componente un botón de “Aceptar” que sirve para confirmar las fechas seleccionadas o escritas en los campos correspondientes y cerrar el calendario. El color es naranja para transmitir acción y dar sentido de transición.
4. El usuario escribe la fecha de entrada en el campo superior correspondiente o selecciona directamente el día que desee haciendo clic sobre el mismo. El día se marca con una cama de color naranja, el mismo color que el campo activo y que el botón para establecer una relación semántica entre todos los elementos.
5. Una vez escrita la fecha de entrada el foco pasa al campo de fecha de salida que aparece resaltado, bordeado en naranja, para indicar su estado activo.
6. El usuario escribe la fecha de salida en el campo correspondiente o selecciona el día que desee en el calendario. La fecha se muestra en el campo y el período seleccionado se muestra de color naranja para marcar de forma clara e inequívoca los días escogidos. Como posible mejora se podría valorar la posibilidad de, al igual que realiza Hoteles.com mostrar el número de noches escogidas a la derecha aunque en principio es un dato secundario.
   • Para modificar las fechas se pueden escribir directamente en los campos superiores o, con el ratón. En este caso cuando ya hay un período seleccionado, para cambiar las fechas, al hacer clic en cualquier nuevo día, el período seleccionado desaparece y el día sobre el que se ha hecho clic pasa a ser el de fecha de entrada.
   • A continuación el usuario hace clic en otro día para la fecha de salida mostrándose el nuevo período resaltado.
   • También se pueden modificar las fechas de entrada y salida escribiéndolas directamente en los campos superiores.
7. El usuario pulsa sobre el botón de “Aceptar” y se muestran las fechas de entrada y salida en el campo del componente principal. Para modificarlas el usuario hace clic sobre ellas desplegando el calendario.

Esta propuesta está incompleta dado que le faltan los colores. Lo que aquí se presentan son tan sólo prototipos. El diseño gráfico es crítico y condiciona de manera crítica y fundamental la usabilidad así que si algún diseñador gráfico se anima a ponerle color aunque sea tan sólo a un par de pasos (el 5 y el 6 estarían majos) sería estupendo ;)

¿Conocéis algún calendario distinto de los analizados con algún patrón interesante?

ACTUALIZACIÓN (28/12/2010):

Una actualización del diseño del calendario de acuerdo a los comentarios del post de Álvaro y a las propuestas de más que HTML y RoninRojo:

1. En la gran pestaña superior de “Hoteles” se suprime la línea divisoria con el módulo inferior relacionándose mejor ambos elementos.
2. Se añade un icono de calendario en el campo de “Para las fechas… – Fecha de entrada – Fecha de salida” del formulario para que sirva como pista visual para indicar al usuario que se va a desplegar el mismo al hacer clic sobre el box.
3. Se deja únicamente el botón de cerrar y se suprime la palabra “Cerrar”.
4. La flecha en la parte inferior izquierda del calendario para avanzar de meses se pone en naranja para denotar estado activo mientras que la superior para ver meses anteriores en un primer momento permanece en gris, en un estado inactivo.
5. Se suprimen las camas de color de los meses. Se alarga la línea divisoria de los meses hacia la izquierda y se posiciona el nombre debajo de ella lo que delimita mejor dónde empieza y acaba cada mes.
6. Se añade un enlace de “Borrar” en la parte inferior del calendario cerca del botón de “Aceptar” para borrar la selección de los días hecha por el usuario si lo necesita.

Amazon: En la cabecera principal la opción de salir está oculta detrás del enlace de ayuda (Help)

Similar diseño puede observarse en Linkedin donde la opción de salir queda oculta tras un menú desplegable que se visualiza cuando el cursor del ratón se posiciona encima del nombre del usuario:

Igual patrón se da en redes sociales como Facebook (en este caso la opción de salir está oculta en el menú desplegable que aparece al posicionar el cursor encima de la opción de “Cuenta”):

En Tuenti:

O en Twitter:

La pregunta a tenor de lo visto es:

¿Es una buena práctica de cara al usuario o es un patrón de diseño de interacción sucio?

Poniéndonos en la piel de un usuario podemos escribir el siguiente escenario:

Un usuario se loga en una aplicación o sitio web. Interactúa en la misma durante un rato tras lo cual decide abandonarla. Para ello pulsa sobre el botón cerrar de la pestaña del navegador y sale.

Ante esto se plantean los siguientes…

Pros:

• Ocultar la opción de salir supone un coste cognitivo en esfuerzo y tiempo que el usuario tiene que dedicar a “averiguar” dónde está la opción de salir. No es un patrón de diseño uniforme dado que unas veces la opción de deslogarse se encuentra oculta detrás del nombre del usuario, otras detrás de opciones como “Mi cuenta” o “Cuenta” o incluso detrás del enlace de ayuda. No existe una uniformidad en cuanto a donde se debe localizar.
• Ante esta situación es probable que el usuario tienda a realizar la opción más fácil: pulsar sobre el botón de cerrar pestaña del navegador. Cierra la pestaña y se acabó el problema.
• El modelo mental al que estamos acostumbrados impuesto por el uso diario e intensivo de los navegadores es cerrar una pestaña para abandonar un sitio o página web. Desde este punto de vista ocultar la opción de salir se alinea con dicho modelo lo que puede suponer una mejora de usabilidad de cara al usuario.
• La existencia de una opción de “Salir” o “Cerrar sesión” entra en conflicto con el botón de cerrar pestaña del navegador que “supuestamente” ya hace dicha acción.
• Al no estar explícitamente visible y considerarse por tanto una opción secundaria no tenemos que dedicar un espacio de la interfaz a ponerla.

¿Es por tanto una mejora de usabilidad o no?

Contras:

• El usuario se loga en la aplicación: Amazon, Facebook, Tuenti… A continuación para salir pulsa sobre el botón de cerrar pestaña del navegador y la abandona.
• Dependiendo del tipo de cookie utilizada puede suceder que el usuario con posterioridad siga navegando por la Web y tiempo después abra de nuevo una pestaña escriba el nombre de la aplicación o sitio en la barra del navegador, pulse retorno y vuelva a la misma. En este caso puede pasar que la cookie mantenga abierta la sesión con lo cual el usuario ya no tiene que logarse de nuevo. ¿¿?? se puede preguntar el usuario. El comportamiento no es predecible y rompe el modelo mental usual –> accedo a una web, introduzco mi nombre de usuario y clave y entro.
• Los problemas de seguridad son evidentes dado que si nuestro usuario está accediendo a su red social desde una terminal pública si no cierra la sesión de manera oportuna alguien que venga detrás puede ver su perfil y hacer lo que quiera en el mismo abriendo una pestaña y tecleando el nombre del sitio en la barra del navegador.
• En algunos casos como Amazon, la sesión ni siquiera expira cuando se cierra totalmente el navegador y se vuelva a entrar lo que agrava aún más el problema.

Ante los problemas de seguridad y el falso feedback que recibe el usuario lo aconsejable es:

• Poner la opción de cerrar como enlace o botón explícitamente visible en la interfaz principal de la aplicación o sitio web y además
• hacer que la sesión caduque cuando el usuario cierre la pestaña de la aplicación del navegador o el navegador mismo.

Querer mantener logado al usuario y mantener la sesión abierta hasta que no se pulse el botón de salir, sea por la razón que sea: monitorizar el comportamiento del usuario durante el mayor tiempo posible para conocer sus hábitos de navegación o cualquier otro uso, “facilitar” su retorno, etc es cuando menos una mala práctica y cuando más un patrón de diseño de interacción sucio.

Si el usuario quiere abandonar nuestro sitio que lo abandone, y que lo abandone con seguridad. Ya volverá cuando quiera si quiere.

“El 20% de nuestro tiempo con una suite de productividad lo pasamos usando las opciones de copiar y pegar…”

Twitter de MSBlogspain

El tamaño de los botones de copiar, pegar y cortar en el nuevo menú de Firefox 4 es muy pequeño. Si el porcentaje de uso de estas funcionalidades es similar en Firefox al que tienen en Office su tamaño debería ser mayor.

–0–

“20% of our time with a productivity suite we had using the options to copy and paste …”

Twitter de MSBlogspain

The size of the buttons to copy, paste and cut on the new menu of Firefox 4 is too small. If the percentage of use of such features in Firefox is similar to that of Office then its size should be larger.

]]> http://www.tentandote.com/2010/10/12/mejora-deusabilidad-para-firefox-4-aumentar-el-tamano-los-botones-de-cortar-copiar-y-pegar-es-en/feed/ 3 http://www.tentandote.com/2010/06/27/two-ideas-for-humanized-and-improve-the-information-visualization-of-the-urls-in-firefox-4-5/ http://www.tentandote.com/2010/06/27/two-ideas-for-humanized-and-improve-the-information-visualization-of-the-urls-in-firefox-4-5/#comments Sun, 27 Jun 2010 18:51:33 +0000 tentandote http://www.tentandote.com/?p=840

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

Escenario de uso:

Un ciudadano quiere presentar su declaración de la renta. Va a la página web de la Agencia Tributaria y se descarga el programa de ayuda para hacer la renta PADRE 2009.

Se lo instala, lo ejecuta y accede a la pantalla de bienvenida donde comienzan los problemas:

¿Y ahora qué? se pregunta el ciudadano

¿?

El módulo central es pasado por alto completamente por su pinta de publicidad y por tener el fondo de color gris lo que parece que indica que tiene información que es más verborrea que otra cosa. El layout es de pena y la jerarquización de la información nula al tener los encabezados:

• “Dar de alta una nueva declaración”
• “Ayuda” y
• “Declaraciones recientes”

el mismo tamaño y tipografía que el inicial, inmediatamente debajo del logotipo de:

• “Programa de ayuda para la declaración del impuesto sobre la Renta de las Personas Físicas correspondiente al ejercicio 2009″

y que el teléfono de información a la derecha junto con el rótulo:

• 901 33 55 33
• “Información tributaria”

El punto de acción que interesa resaltar para que el usuario comience a realizar la declaración, el enlace “Modelo 100 IRPF” es obviado completamente por nuestro ciudadano quien se ve las caras de tarde en tarde con Hacienda y no termina de entender/saber del todo bien qué es eso del “Modelo 100 IRPF” (es que es un poco torpe, qué se le va ha hacer, ya se sabe lo de los usuarios de a pie de calle es que no dan para más… ) a pesar de haber presentado la declaración ya desde hace unos cuantos años.

Al final, después de un rato, escaneando visualmente la interfaz encuentra el icono superior izquierdo con pinta de documento y signo “+” al lado del icono de la puerta.

- ¡Ah! – piensa…

- que va a ser esto mira tú… -

y va y pone el cursor encima y lo deja unos momentos encima y ¡¡albricias!! le aparece un tooltip que le dice “Nueva declaración”

- jeje -

piensa nuestro confiado ciudadano que ufano acaba de encontrar la manera de comenzar a dar de alta su nueva declaración. Hace clic (menos mal que no sufre de parkinson y no se le va el cursor al icono de al lado porque si no lo de salirse de repente del programa, pufff… ) y…

- estoooooo… -

- estoooooooooooooo   ¿¿?? -

- ¿Y cómo doy de alta una nueva declaración? -

piensa nuestro ciudadano desconcertado.

¿Cómo se da de alta una nueva declaración?

Pensadlo unos momentos antes de continuar leyendo por favor.

¿?

• El ciudadano intenta hacer clic en el enlace azul subrayado que pone “Nueva declaración” dado que es un enlace con pinta de enlace de los que ve (o veía) antes habitualmente todos los días al navegar por la Web, y cuyo patrón de interacción tiene más que interiorizado. Hace clic sobre el enlace a pesar de estar un poco mosqueado ya que el icono de la izquierda que lo acompaña no tiene esa pinta gráfica con esos colores tan bonitos que tenía antes. Ahora, aparece como apagado, como desactivado, al igual que el resto de los iconos que acompañan los enlaces de “Abrir declaración” “Borrar” “Duplicar” y “Renombrar” pero es que el enlace azul con su azul es tan cautivador que…  nada, a hacer clic.¿Resultado?Nada, intenta hacer varios clics sobre el enlace y que aquello no va. Y no entiende por qué, porque pinta de enlace sobre el que se puede hacer clic, desde luego que tiene.Gran y severo fallo de usabilidad. La disonancia cognitiva es importante y rompe el modelo de interacción que conoce y tiene interiorizado el usuario. Por un lado tenemos un icono con apariencia de no activado y por otro un enlace azul con apariencia de activo.
• Como el único punto de interacción que hay en la pantalla aparte de los iconos de la barra de tareas en la que ahora, el icono de “Nueva declaración” aparece como desactivado, es el ¿¿box de búsqueda?? ¿¿?? debajo del rótulo de “Índice de declaraciones”, hace clic en el mismo y el puntero del cursor se pone parpadeante… y sigue sin suceder nada…
• Como ya no sabe que hacer, escribe una palabra en el teclado y…¡¡VAYAAA!!¡¡QUE AHORA SE ME ACTIVA POR FIN EL ICONO DE NUEVA DECLARACIÓN JUNTO A SU ENLACE!!

que por cierto… ¿y cómo es que hay dos iconos con la misma apariencia y el mismo nombre que supuestamente hacen lo mismo en dos posiciones diferentes de la pantalla, uno en la esquina superior izquierda y otro en el centro, a la derecha del box de ¿búsqueda? ¿de entrada de texto? ¿de…? ¿?

Resumiendo: Para comenzar a dar de alta una nueva declaración el proceso es:

• El usuario accede al programa y cierra el mensaje de bienvenida que le aparece.
• Hace clic en el enlace de “Modelo 100 IRPF” (rótulo que es de todo menos intuitivo para el usuario) o en el icono de “Nueva declaración” de la esquina superior izquierda.
• Se le presenta la segunda pantalla con el famoso campo input de texto.
• Hace clic en dicho campo y escribe el nombre que quiere dar a la nueva declaración para lograr que se le active el icono de “Nueva declaración” a la derecha del campo input.
• Pulsa sobre el enlace de la derecha, ahora sí, activo de “Nueva declaración”
• Comienza el proceso de crearla rellenando sus datos personales.

Pregunta:

¿Cuantos ciudadanos no habrán sido siquiera capaces de empezar a rellenar su declaración de la renta por no haber averiguado cómo crearla?

¿?

Me gustaría saber la respuesta pero creo que me voy a quedar con la duda.

Creo que para el año que viene, al menos este aspecto del programa PADRE se debería mejorar radicalmente rediseñando por completo esas dos pantallas, fusionándolas si es necesario, suprimiendo funcionalidades duplicadas y racionalizando la barra de tareas (si se desea plantear así) del programa.

Año tras año, la Agencia Tributaria hace un gran esfuerzo para mejorar las cosas y hacernos la vida un poco más fácil a los ciudadanos…

pero todavía le queda trabajo, algo normal y natural en cualquier proyecto, vamos.

LA DE ARENA:

• Mucho, muchísimo mejor el acceso al apartado de la información de la campaña de la Renta 2009 con dos módulos grandes bien destacados en la home de la Agencia, categorizados por perfiles: “Ciudadanos” y “Empresas y profesionales” y con el primer enlace rotulado como “Renta 2009″. Muy fácil de encontrar, muy bien situado.

• Aunque se puede trabajar más la landing page de la campaña de la Renta 2009, es bastante escaneable visualmente e incluye enlaces directos a las opciones más buscadas (programa PADRE, borrador de la declaración, cita previa, faqs, enlaces y manuales de ayuda y servicio de atención teléfonica). Orientada a las tareas. Cambiaría los rótulos de algunos contenidos o agruparía quizá la información de otra manera para evitar alguna duplicidad como los enlaces de “Datos fiscales” y “Borrador de la declaración” que aparecen con iguales literales en diferentes epígrafes lo cual puede dar lugar a algún equívoco, pero vamos, que la página es lo que tiene ser: útil.

• Y por último y para terminar, lo más importante, por primera vez en no se cuantos años que llevo haciendo la declaración, he podido entrar en el apartado de “Tramitación de los servicios de ayuda disponibles > Confirmación del borrador” que previamente me había mandado la Agencia sin el DNI electrónico. Sólo con el número de referencia que este año ponían más clarito en la carta que envían, no como en años pasados que no sabías que número te estaban pidiendo. A pesar de los problemas de visualización en Firefox tanto en Windows 7 como en Mac, he podido revisar el borrador más o menos con facilidad. Algunas cosas hay que cambiar como la gestión de pop-ups (¿veremos Ajax más adelante y procesos de edición contextualizados en lugar de abrir pop-ups en el futuro?). He podido comprobar que todo estaba correcto, dar al botón de confirmar y andando. Imprimirme la página resultante como comprobante y cumplir con mi obligación de buen ciudadano, etc, etc :-P :-P

Están haciendo un esfuerzo encomiable y en la buena dirección. Lo que hace falta es que sigan en ella y sigan invirtiendo y mejorando en la usabilidad tanto de la web, como del programa PADRE, que buena falta le hace.