“Los desafíos que tenemos delante son muy reales. Las plataformas móviles son más cerradas y centralizadas de lo que hemos visto en décadas. Como individuos estamos perdiendo la capacidad de actuar en la Web sin permiso de los grandes y centralizados actores [del mercado]. Estamos siendo rastreados, registrados, catalogados, monetizados y convertidos en productos para la venta. Estamos viendo fragmentarse la plataforma universal de la Web en múltiples y diferentes mundos.

A medida que la experiencia en Internet cambia, Mozilla cambia. Los productos y herramientas que utilizamos para dar cumplimiento a nuestra misión están ampliándose y evolucionando. Un navegador es necesario pero no suficiente…”.

Mitchel Baker. Presidenta de la Fundación Mozilla con motivo de la presentación del Informe anual y del estado financiero de Mozilla.

“The  challenges ahead of us are very real. Mobile platforms are more closed  and more centralized than we have seen in decades. As individuals, we  are losing the ability to act on the Web without permission from large, centralized gatekeepers. We are all being tracked, logged, cataloged,  monetized and turned into products to be sold. We’re seeing the  universal platform of the Web fragmenting back into multiple different  worlds.

As  the Internet experience is changing, Mozilla, too, is changing. The  products and tools that we use to advance our mission are expanding and  evolving. A browser is necessary but not sufficient”.

Mitchel Bakerr. Chair of Mozilla Foundation. State of Mozilla and 2010 Financial Statements.

Ante la realidad de la Web Móvil, la ubicuidad y la Nube, la consolidación de los smartphones y la llegada al mercado de los tablets que están configurando un nuevo ecosistema móvil cerrado, propietario y controlado por las grandes tecnológicas, la Fundación Mozilla ha puesto en marcha el desarrollo de un Sistema Operativo conocido como Boot to Gecko.

Prototipos como Webian Shell y discusiones como la del navegador ubicuo están sentado las bases desde el punto de vista de la Experiencia de Usuario y de la interfaz para tablets y smartphones.

Boot to Gecko compartirá un pequeño núcleo con Android para la comunicación y el control del hardware.

Aunque inicialmente eran tan sólo tres los ingenieros que estaban implicados en su creación a tiempo parcial, parece que Mozilla ha decidido dar prioridad al proyecto optando por desarrollar como aplicación nativa de Android el actual navegador móvil. Esta decisión podría estar estrechamente ligada a enfocar los esfuerzos en la creación del núcleo del nuevo Sistema Operativo.

¿Sera una realidad el día de mañana y posibilitará la creación, uso y disfrute de apps en igualdad de condiciones con independencia del dispositivo?

El tiempo lo dirá.

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.

En concreto la comunidad de prácticas se centrará en la Web móvil, aparición y evolución, aplicaciones y futuro, buscando como principales objetivos:

• Introducirse en los principales conceptos y características de la Web móvil.

• Nociones básicas sobre cómo adaptar la información a los dispositivos móviles.

• Conocer las opciones que ofrecen los distintos dispositivos móviles: realidad aumentada, geoposicionamiento, códigos bidimensionales, y otras aplicaciones como redes sociales móviles, servicios y juegos.

• Explorar las posibilidades que ofrecen las aplicaciones de la web móvil a las bibliotecas y el entorno educativo.

• Conocer e intercambiar conocimientos basados en la experiencia entre profesionales de la información, la documentación y la educación.

• Extraer conclusiones en común acerca de cómo afecta la web móvil a los profesionales de la información.

Podéis obtener la información completa de la convocatoria y cómo funcionará la actividad en la propia página de la comunidad en la web de SEDIC:

Toda la información sobre la comunidad de prácticas:
Utilidades de la Web móvil para profesionales de la información

Para inscribirse en la actividad:

Formulario de inscripción