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.

Desde hace tiempo y con la aparición de Internet el esquema de desarrollo de software de las empresas ha cambiado. Aunque algunas aún siguen trabajando con los antiguos procesos en cascada en donde se dedica el 70% del tiempo a los procesos burocráticos y de documentación,  la realidad es que hay muchas empresas nuevas que basan el desarrollo en equipos pequeños y ágiles.

Así han aparecido multitud de metodologías de desarrollo ágil como pueden ser Extreme Programming o Scrum. Parte de la filosofía de estas metodologías consiste en reducir al mínimo el proceso de documentación y evitar mantener largas reuniones para tomar las decisiones necesarias.

Sin embargo, que el desarrollo se haga de manera ágil no significa que se deba obviar el proceso de captura de requisitos, testeo y documentación. Por el contrario, consiste en utilizar otro tipo de técnicas que permita realizar estos procesos de manera sencilla y productiva.

En 21projects y en muchas otras empresas de desarrollo se utiliza una herramienta de gran valor y potencial. Se trata de Trac. En la web de este proyecto open source se define a la herramienta de la siguiente manera:

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management.

Resumiendo, Trac es una herramienta que permite llevar un control de las funcionalidades y errores del código que se está implementando. Sin embargo, Trac es una herraminta mucho más completa que esto, pues está construido sobre una wiki que permite documentar todo el software sobre una única plataforma, integrando la documentación con el control de funcionalidades y errores a implementar así como también con el propio código a través de un repositorio de Subversion del cual ya se habló en un post anterior.

Conozco mucha gente que después de haber probado Trac en su equipo de desarrolladores han dicho frases como: “No se como puedo haber vivido hasta ahora sin una herramienta como Trac”. Y la verdad es que, aunque no se trata de una herramienta imprescindible, sí que resulta extremadamente útil. Además de las opciones básicas de Trac, también es posible instalar nuevos plugins que cubren desde la integración de repositorios Git hasta la gestión de metodologías ágiles como Scrum.

¿Pero qué significa todo esto a la hora de la práctica? Lo mejor es verlo con un ejemplo. Veamos como sería el proceso de creación de un nuevo proyecto en el equipo de 21projects (Trac puede utilizarse para cualquier tipo de lenguaje, ya sea una aplicación web, desarrollo para iPhone o Android o bien para gestionar documentación, imágenes o cualquier otro tipo de contenido).

Captura de requisitos:

En esta fase, nos reunimos todo el equipo de desarrolladores (y el cliente, si se trata de un proyecto para terceros) bien en persona o utilizando un documento compartido en GoogleDocs para definir cuáles son los requisitos de la aplicación. Normalmente, primero desarrollamos los casos de uso básicos de la aplicación y a partir de ellos creamos la lista de requisitos, siempre en colaboración directa con el cliente.

De esta fase saldrá una lista de requisitos funcionales con una descripción de cada uno, dejando claro qué es lo que se espera y que ha de tener para que se considere que ese requisito está “hecho”.

Integración de los requisitos en Trac:

A partir de este momento, procederíamos a ingresar en Trac cada uno de los requisitos como un nuevo Ticket. En Trac, cada funcionalidad a implementar o cada bug debe ser introducido como un Ticket, que estará asociado a una persona y a un Milestone del proyecto así como a una serie de propiedades adicionales como pueden ser la versión del desarrollo, el tipo de Ticket, o la severidad de este. Un Milestone es un hito de desarrollo que se propone. Dentro de Trac podemos crear tantos Milestones como queramos y ponerles una fecha límite. Así, se podría decidir crear un nuevo Milestone que representa el lanzamiento de la primera versión del producto y todos los Tickets de esta iteración serán agregados a este Milestone.

Interfaz de creación de Tickets

Trás haber ingresado todos los Tickets en el sistema, cada desarrollador participante podrá decidir en qué funcionalidad va a trabajar y asignarse ese Ticket, que quedará marcado con su nombre para que los demás sepan que él está trabajando en su implementación.

Mientras el desarrollo esté en curso, podremos utilizar la Wiki de Trac para ir documentando todo el proceso. Aunque esta Wiki tiene una sintaxis particular que viene reflejada en la documentación de la aplicación, sus posibilidades son muy amplias e interesantes, ya que por ejemplo, cada vez que pongamos el caracter “#” seguido de un número se creará un enlace automáticamente al Ticket que tenga asignado ese número (cada Ticket tiene un identificador numérico único).

En nuestro caso, utilizamos la página principal de nuestro Trac (que es una página wiki) para enlazar los diferentes documentos que utilizamos, mantener una lista de enlaces externos de interés y documentar los proyectos propios y de clientes así como las ideas de posibles proyectos futuros.

Página principal del Trac de 21projects

De esta manera, es posible ir documentando todo el proceso de desarrollo, incluir imágenes, enlaces y crear una documentación fácil de modificar y sobre todo, muy potente gracias a las funcionalidades de Trac.

Cada vez que un desarrollador acabe con la implementación de un Ticket, deberá marcar ese Ticket como resuelto y trás haber subido el código al repositorio Subversion, este cambio se reflejará en Trac a través de la sección que nos permite navegar por nuestro código.

Aunque existen muchas otras funcionalidades que vienen con Trac por defecto y muchas más que pueden añadirse a través de nuevos plugins, os dejamos que experimentéis con esta fantástica herramienta que permite mejorar la gestión de un nuevo proyecto software tanto a nivel de código como a nivel de documentación. Otra fantástica idea es abrir el Trac para que los usuarios u otras empresas puedan ver lo que hacemos e incluso colaborar añadiendo nuevos Tickets al encontrar un bug en la aplicación.

Si tenéis cualquier duda acerca de esta herramienta u os interesa utilizarla en vuestro negocio y no sabéis como empezar contactad con nosotros, estaremos encantados de ayudaros.

Comunicar una idea o proyecto en una presentación, diseñar el envoltorio de un producto, construir el escaparate de una tienda o realizar una página web o aplicación para el iPhone. Todos tienen algo en común. Queremos comunicar una idea o una sensación a nuestros clientes, y queremos hacerlo de la mejor manera posible. Nosotros cuando pensamos sobre nuestros proyectos o cuando escuchamos propuestas de clientes, siempre hacemos lo mismo. Entender lo que queremos, analizar todas las opciones, mezclar conceptos de diversos sectores o campos para expandir las posibilidades, dibujar lo que queremos hacer, coger la esencia y simplificar lo más posible para que sea obvio qué es lo que queremos mostrar en la web o qué permite la aplicación móvil. Es un proceso de experiencia, cuantas más veces lo hagas mejor te saldrá; pero también es de intuición, de creatividad.

Descubrí el otro día la presentación Thinking Visually de David Armano, y me produjo una buena sensación asi que busqué el vídeo de su charla en Chicago. Lo acabo de ver confirmando las buenas vibraciones y recibiendo los buenos consejos que da cuando quieres comunicar algo visualmente. Para empezar una frase que hace pensar:

Los ojos no son responsables cuando es la mente la que ve

Podéis ver en la presentación los 6 pasos que utiliza él, nosotros variamos y especializamos un poco su uso para nuestros proyectos. Lo voy a denominar la técnica OSEC, cuatro pasos para desarrollar una buena interfaz o envoltorio:

1. Observa. Ve el mundo con los ojos de un niño. Tienes que observar todo sobre el proyecto, preguntar todo lo que se te ocurra, ver qué hacen los competidores, qué esperan los clientes o cuáles son las tendencias.
2. Sintetiza. Analiza todo y con todo lo que has sacado, pregúntate cuál es la esencia; qué es lo que se quiere transmitir, qué es lo que se quiere hacer. Separa lo esencial de lo que no es necesario.
3. Esboza. Coge un papel y dibuja los esquemas, las interfaces de las pantallas principales expresando la esencia; constrúyete los casos de uso dibujándolos y comprueba que es eso lo que se quiere conseguir. Dibuja en papel tanto como quieras. Espera un día, y vuelve a pensar desde cero. Si ves que algo no cuadra, vuelve al punto 2 y pregúntate de nuevo qué es lo importante.
4. Construye. Ya sabes lo que quieres conseguir así que es hora de ponerse manos a la obra. Sé fiel a tus dibujos, pero no intentes hacerlo simétrico. A veces cuando dibujamos y pensamos no nos damos cuenta de ciertas dificultades. Rodea esos problemas para que se siga manteniendo esa sencillez.

Con estos 4 pasos conseguimos mejorar la idea inicial, potenciando lo diferencial y haciéndolo tremendamente intuitivo. Cada uno tiene su método así que estamos encantados de escuchar el vuestro y saber qué puntos añadiríais.

Como recomendación del autor me estoy leyendo ahora mismo el libro Don’t make me think! que es una referencia en el campo de la usabilidad web. No hay más que ver la media que tiene en Amazon (4,5/5 sobre más de 500 críticas). Ya comentaré más adelante sobre las conclusiones que estoy sacando.

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?

Acabamos de empezar nuestra empresa o vamos a lanzar nuestro producto al mercado, ¿cómo hacemos para conseguir los primeros fans, los primeros clientes? ¿Cómo hacemos para conseguir el ansiado boca a oreja que empuje el lanzamiento de nuestro servicio? Estas preguntas nos la hacemos todos, sobre todo si no tenemos dinero para hacer una campaña publicitaria en webs/papel/TV.

Con 21projects estamos todavía en las fases iniciales asi que estamos implementando las sugerencias que voy a proponer a continuación. Sin embargo, dichas sugerencias están basadas en artículos, en experiencias de conocidos y de marcas online, y por supuesto, en el sentido común.

1. No te dediques solo a vender, conoce a la gente

Cuando tenemos una tienda física, o cuando vamos a eventos; hablamos de todo tipo de asuntos, no sólo de promocionar nuestra empresa o producto. Lo mismo tenemos que hacer en Internet, ya sea en Twitter, redes sociales, foros o webs especializadas. Una mala estrategia es dedicarte solo a vender, tienes que darte a conocer, crear confianza, demostrar que no quieres solo ventas si no fans de tus productos. Aprende a escuchar, y ten conversaciones diversas como tendrías en la vida real.

Otra razón para poner en práctica esta forma de comunicación es la siguiente: puede que comiences una conversación con alguien que no va a ser cliente tuyo ahora mismo, pero tiene un círculo de amigos y conocidos a los que hablar de tu producto. Si eres muy pesado y sólo te preocupas de vender, no llegarás a ese círculo de gente; si eres transparente, agradable y le cuentas cosas interesantes, entonces estarás haciendo un gran trabajo para promocionarte, tanto a ti como a tu marca.

2. Presta atención a lo que dicen tus clientes y actúa

Gracias a Twitter o Google Reader podemos saber lo que dicen nuestros clientes o potenciales clientes prácticamente en tiempo real. No hace falta llegar al extremo de estar pendiente todo el tiempo, pero sí es muy recomendable dedicarle un rato cada día a seguir lo que dicen los blogs sobre tu producto, a seguir los twits y a responder a casi todo, agradeciendo el apoyo si es positivo, pidiendo consejo para mejorar en casi todas las ocasiones, y en analizar qué falla, si el comentario ha sido negativo.

Como bien se dice, es imposible controlar lo que se habla de ti; lo que tienes que hacer es seguirlo y si es negativo, intentar arreglarlo o saber cómo evitarlo para la próxima vez. Tampoco hay que pensar que todas estas acciones tendrán un beneficio inmediato, todo lleva su tiempo; pero si tu producto es bueno, ayudará a que se conozca cada vez más.

3. Participa en varias comunidades

Sabemos que tu tiempo es limitado, pero en cuantas más webs y redes sociales estés activamente, mejor. Por supuesto tendrás que elegir cuál te viene mejor. Yo elegiría Twitter y Facebook seguro. En España puede que Tuenti funcione en un futuro cercano si tu target es un público jóven, pero por ahora no es tan fácil. Luego iría a webs, blogs, foros o redes verticales de tu sector. Es básico que estés donde están los early adopters, aquellas personas que están dispuestas a ser los primeros en probar tu producto y ayudarte a mejorarlo. Tienes que moverte en foros, blogs; ir transmitiendo de forma natural tu opinión a muchos temas, compartiendo tu experiencia. Es importante recordar el punto 1, no hay que estar vendiendo en todos los mensajes. Si dejas un mensaje coherente e inteligente, la gente ya irá a tu web y te conocerá. Ganas más diciendo algo que aporte valor sin mencionar directamente tu producto, que poniéndolo (seguramente te borren el mensaje).

4. Comienza un blog de tu empresa

¿Por qué en vez de ir a Twitter a buscar potenciales clientes, no creamos nuestra plataforma donde comentar las novedades de nuestra empresa? Eso es lo que permite el blog, una herramienta donde comunicar los avances, los desarrollos y las novedades de tu empresa. Pero como ya he dicho antes, no te dediques solo a vender; comenta también acerca de las actividades que hacéis, o comparte vuestra experiencia en la tecnología o manera de enfocar las cosas. También es muy útil preguntar a vuestros lectores sobre cómo mejorarían vuestros productos o qué productos les gustaría tener.

Por último os dejo con 35 ejemplos de social media en empresas grandes, y una completa lista de cómo las empresas usan los blogs, crean comunidades o usan Facebook y Twitter para llegar a sus clientes. Y otro más de regalo con algunos ejemplos repetidos. Cada semana, intentaremos escoger un ejemplo de social media que ha tenido muy buenos resultados para explicar sus claves.