Hay quienes admiran el iPhone de Apple y hay quienes piensan que no es tan maravilloso, que hay muchas restricciones y que no fomentan la aparición de aplicaciones disruptivas. Sin embargo, hay algo en lo que todo el mundo parece estar de acuerdo: han hecho un excelente trabajo al crear los elementos por defecto que conforman las interfaces de las aplicaciones para iPhone.

Por un lado, un usuario que se enfrenta por primera vez a una aplicación iPhone se encuentra con elementos intuitivos y sencillos de utilizar. Por otro lado, cuando este usuario vaya avanzando en su proceso de aprendizaje irá descubriendo que la mayor parte de las aplicaciones disponibles para este terminal comparten esos elementos de la interfaz, y por tanto, utilizar una nueva aplicación no le supondrá tener que aprender a manejarla.

Hay unas cuantas aplicaciones disponibles que en su afán por diferenciarse del resto han intentado reinventar la rueda. Con esto solo han conseguido tirar a la basura todo el excelente trabajo hecho por Apple y como resultado han obtenido una aplicación poco intuitiva para el usuario acostumbrado a una serie de elementos comunes en todas las aplicaciones de iPhone.

Muchas veces, no es necesario reinventar los elementos existentes para poder hacer algo diferente. Un ejemplo bastante típico es el de Postage de la empresa RogueSheep quienes han sabido hacer una aplicación que parece diferente pero que utiliza los elementos característicos (y alguna innovación como es la selección de tipografía).

Fijaros como gracias a un cambio en la tonalidad y la utilización de iconos nuevos han conseguido un diseño diferente pero intuitivo. Al fin y al cabo mantienen la barra de navegación superior y también utilizan “tabs” o pestañas en la parte inferior, dos patrones muy típicos en las aplicaciones para iPhone.

Las aplicaciones para móviles deben ser sencillas. Hay que pensar que la plantalla es pequeña y por tanto tendremos que tener especial cuidado con el tamaño del texto que no debe ser ni muy grande ni muy pequeño, con la cantidad de elementos que mostramos y con la disposición que hacemos de estos. Ha de haber un balance general. Veamos un ejemplo de lo que no se ha de hacer:

A la derecha podemos ver la primera versión de la aplicación TripLog. En este caso se observan varios errores de diseño de los que hemos hablado antes. Por un lado se han utilizado demasiados elementos, por el otro, estos no están alineados dando una sensación de desorden y confundiendo al usuario. A la izquierda, podemos ver la versión actual de la aplicación. En este caso a pesar de que hay demasiados elementos estos están mejor alineados y mejoran un poco la percepción que se tiene.

Como ya hemos dicho, siempre tiene que haber un balance. Cuando el contenido de una vista es excesivo y observamos que sobran elementos, tenemos que replantear el flujo de trabajo de la aplicación. La mejor manera de conseguirlo es tener en mente los modelos o patrones por defecto que Apple ofrece. Haciendo un repaso de ellos veremos que el 99% de las aplicaciones existentes se basan en uno de estos patrones o elementos.

Barra de navegación / Navigation bar

Barra con elementos de control

Barra con elementos de navegación

Barra multisegmentos

Barra con título sin elemento

Barra de herramientas / Toolbar

Permite ejecutar acciones sobre la vista actual, normalmente se coloca en la zona inferior

Un ejemplo

Barra de pestañas / Tab bar

Permite cambiar de vista

Un ejemplo: En la aplicación Clock de iPhone la barra de navegación permite cambiar entre los diferentes modos

Aun quedan muchos otros elementos por mostrar: tablas, botones, alertas, etc. Sin embargo, estos son los principales elementos de control sobre las diferentes vistas y son los que ayudan a definir el flujo de nuestra aplicación. Haced el ejercicio de ver cuántas de las aplicaciones de iPhone que utilizáis se basan en alguno de estos controles y veréis que la gran mayoría los utilizan. Como ya hemos dicho, son la clave para conseguir una experiencia de usuario agradable y un proceso de aprendizaje sencillo e intuitivo.

Como usuario de Android he tenido que meter contraseñas en el móvil unas cuantas veces, y con el teclado virtual de vez en cuando te equivocas y toca escribirla de nuevo. Por eso creo que para mejorar la usabilidad de las versiones móviles debemos desterrar el ocultar contraseña. Esta idea no es nueva, la propuso Jakob Nielsen hace unos cuantos meses. Cuando ocultas una contraseña creas dos problemas:

• Los usuarios cometen más errores porque no ven lo que escriben y por tanto se sienten menos confiados.
• Cuando la gente comete errores suele escoger contraseñas fáciles de escribir o copia y pega de un archivo. Ambas opciones hacen que haya riesgos de seguridad importantes.

Asi que el propósito inicial de ocultar la contraseña a ojos ajenos provoca que escojamos contraseñas más fáciles de romper. En el ordenador puede ser más necesario ocultar la contraseña aunque Jakob propone tener un checkbox donde cambiar si la mostramos o la ocultamos (plugin de jquery).

Sin embargo en el móvil no lo veo necesario ya que es un aparato personal con una pantalla que ves tu solo, y por lo tanto no supone tanto riesgo de seguridad. La comodidad que le das al usuario de ver lo que está escribiendo supera con creces los posibles peligros de ojos ajenos. Esta es una opinión personal que intento compartir con nuestros clientes, pero supone un cambio en la mentalidad de seguridad.

Ahora bien, si entramos en el aspecto técnico y el campo de contraseña se convierte en un simple input los navegadores o el sistema operativo en el caso de los móviles puede guardar en caché la contraseña y mostrarla la próxima vez que teclees. Algo totalmente erróneo como bien apunta Mike Andrews. La mayoría de los usuarios que comentan en este artículo no creen que esto deba aplicarse a la Web. Incluso sería vulnerable a los virus que hacen capturas de pantalla de tu ordenador.

Aún así, no soy el primero que lo ve bien para los móviles (especialmente aplicaciones). En el GAP (una especie de guía de desarrollo para webs en versión móviles) tratan este mismo tema y recomiendan que se muestre el campo de contraseña.

Do not use password masks
Reading what is on the screen of a mobile device is often hard enough for the user of the device. Peeking over the shoulder of the user is less likely to disclose a password than observing the user’s keypress sequence.
For this reason, hiding user input to users themselves by replacing each character with a ‘*’ (star) symbol (or similar) will do very little to protect privacy, while making it generally harder to use the service. For this reason, users should be made enter passwords in clear text.
This practice does not detract from the aforementioned practice to avoid login and find alternative ways to identify users.
Caveat: In case of highly sensitive application (such as ‘Net Banking’), security requirements may force you to overlook this practice. For example, some users may perceive the lack of password obfuscation as a sign of slack security practices.

Y ya que hablamos de contraseñas varios consejos a la hora de diseñar vuestro servicio web:

• Las preguntas de seguridad son un arma de doble filo, porque mucha gente escribe respuestas muy fáciles de adivinar; como se ha podido demostrar con Britney Spears, Sarah Palin, etc. Yo no las recomiendo e intento evitarlas.
• No se debe enviar la contraseña al email cuando el usuario se registra. La razón es que si entran al email de ese usuario le pueden encontrar las contraseñas y producirse un robo en cadena. Las opciones son, o bien dejar al usuario que escoja su contraseña al registrarse (mi opción preferida) o mandarle una aleatoria al email pero obligarle a cambiarla nada más conectarse a la web (más trabajo para el usuario).
• También nos podemos plantear la duda de si obligar al usuario a escribir dos veces su contraseña. Desde este artículo rechazan esta convención. Argumentan que porque un 1% de los usuarios se equivoque al escribir la contraseña no tenemos que perder tiempo el 99% restante. En ese punto yo prefiero mostrarlo dos veces y compararlo mediante javascript antes de que dé a enviar. Si no lo hacemos así, puede que perdamos a ese 1% que se encuentre desorientado porque no funciona la contraseña que acaba de poner.
• Respecto a escribir dos veces el email, ahí si que no. El usuario puede ver lo que escribe, muy poca gente se debería equivocar.

Una situación curiosa se produjo en una web cuyo formulario de registro consistía en solo su email como nombre de usuario y la contraseña que querían poner. Notaron que mucha gente no se registraba y haciendo un test de usabilidad descubrieron que la gente creía que les estaban pidiendo la contraseña de su email. Por eso la gente no se fiaba y no se registraba. Algo parecido puede ocurrir ahora con las conexiones a Flickr, Google, Del.icio.us, etc. Si es posible no hay que pedir al usuario la contraseña de estos sitios, si no usar el protocolo OAuth para conseguir el permiso y dar mayor sensación de control a nuestros usuarios.

¿Qué opináis? ¿Cuáles son vuestras experiencias?