tentándote.com

Una de las aplicaciones que más utilizo en mi HTC Magic con Android es el cliente de Twitter Twidroyd.

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.

Pues ya está aquí la siguiente gran actualización del sistema móvil de Google y parece que está orientado y optimizado para tablets.

La pregunta que se plantea es ¿es Honeycomb una evolución de Chromiun OS o un sistema operativo aparte orientado específicamente para tablets?

Si son dos sistemas operativos o si es uno ¿cómo convivirá/n con el propio de Google TV?

Demasiadas interfaces, demasiados interrogantes abiertos ¿Veremos algunas respuestas en los próximos meses a estas preguntas? Seguro que sí, mientras tanto, a degustar lo que podemos ir viendo.

Tengo ganas de tener un tablet en mis manos con Honeycomb.

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.