Diseñar aplicaciones para el iPhone, iPod Touch e iPad, parte I

Cuando se piensa en crear una aplicación para los dispositivos móviles de Apple generalmente se tiende a abrir las herramientas de desarrollo de Apple y comenzar a trabajar (o a guarrear) para acabar un par de horas después con un proyecto a medio comenzar que acabará en una carpeta abandonada en cualquier esquina del disco duro.

Ese no es el comienzo.

Aunque no seas desarrollador, programador, especialista en código, etc … no quiere decir que no puedas crear una aplicación para los dispositivos móviles de Apple: realmente, cuando se inicia un proyecto de este tipo hay mucho trabajo previo antes de comenzar a escribir código para crear la aplicación.

Primero la idea

Lo primero que necesitas es la idea: una aplicación ha de hacer “algo” y hay que plantear una idea para el desarrollo. Es quizás la parte mas difícil de un proyecto así porque hay mucha gente pensando en paralelo a ti y en general tenemos cierta tendencia a ser recurrentes al respecto de software para dispositivos: seguramente te has planteado en una ocasión lo que crees una “buena idea” para darte cuenta que alguien ya ha desarrollado algo que cumple con los requisitos básicos de tu objetivo (o incluso los ha superado) y te entra la desesperación (y el abandono).

Ese es el primer error. Que alguien haya tenido una idea “como la tuya” con anterioridad no quiere decir que esa idea se haya llevado a la práctica en óptimas condiciones. También había teléfonos móviles antes del iPhone y eso no ha sido un obstáculo para que Apple triunfara en este segmento del mercado.

Si crees que tu idea es buena toca en este momento hacer un análisis de mercado y examinar el software que va a ser o es tu competencia. Esta tarea se hace con una libreta: una hoja por aplicación, una raya vertical y una columna por lo bueno de ese software y otra por sus defectos o vicios. Con este trabajo previo vas a tener un panorama amplio e que hay en el mercado, cuales son sus puntos fuertes y cuales sus elementos mas débiles, que serán posiblemente los que tendrás que atacar: igualando o superando las ventajas y mejorando esos puntos en los que las aplicaciones de la competencia no han cubierto de forma diligente.

Una vez hayas hecho este estudio de mercado, identificando los puntos específicos donde vas a necesitar un mayor esfuerzo para superar a la posible competencia, es la hora de decidir la lista de objetivos de forma precisa: exactamente donde quieres llegar con tu aplicación. Esto es importante porque en muchas ocasiones se comienza un desarrollo con una meta difusa y al final se acaban llegando a puntos no establecidos en el desarrollo inicial porque uno ha ido tambaleando empujado por los diferentes problemas que nos vamos a encontrar a lo largo del flujo de trabajo que va entre la idea inicial y la aplicación terminada.

Se extremadamente específico en determinar el punto final de la aplicación respondiéndote a estas preguntas: ¿Qué obtengo de la aplicación?,¿Cómo utilizarán los usuarios el resultado de la aplicación? y sobre todo ¿Será lo suficientemente útil ese resultado como para que vuelva a utilizarse la aplicación?. Si crees que puedes responder estos tres puntos ya has dado un paso de gigante. Si alguno de estos tres puntos no te queda lo suficientemente claro, quizás necesites el consejo de un Consultor.

Un Consultor no es específicamente un desarrollador: generalmente es una persona que conoce el proceso de desarrollo de una aplicación desde que se genera la idea hasta que esa idea está en la tienda y es capaz de determinar cuales serán los puntos fuertes y débiles de esa aplicación, donde va a haber problemas en el flujo de trabajo y cómo avanzar una solución antes de llegar a un nudo gordiano que interrumpa o detenga totalmente el proceso. A veces un usuario experto puede realizar esa tarea, pero generalmente vas a necesitar una persona con un alto nivel de conocimientos en el mundo de las aplicaciones porque no solo se trata de hacer una aplicación, también hay que comercializarla, una fase en la que muchos desarrolladores no se encuentran cómodos porque lo suyo es programar. Los consultores, sin embargo, cobran (es lo justo) así que si es necesario llegar a este punto es porque tu idea es buena pero necesita un desarrollo adicional que tu como promotor de la aplicación no sabes darle. El empujón de un consultor puede hacer que una utilidad aparentemente sencilla y que pasaría sin pena ni gloria por la App Store se convierta en un superventas.

Una vez tengas el punto de origen y el punto de destino establecido de una forma lo mas determinista posible, es el momento de empezar a bosquejar la aplicación De nuevo, aún no es el momento de sentarse con el código sino de establecer el flujo de trabajo de la misma: la transformación de los datos.

Una aplicación, cualquiera, parte de una serie de datos que la alimentan y que son transformados para obtener un resultado final. Cómo se haga ese proceso es importante porque determinará el éxito de la aplicación. Tres palabras que no has de olvidar durante esa fase: sencillez, claridad y rapidez.

El usuario tiene que comprender de forma clara que datos va a usar y en qué se van a convertir: el proceso a lo largo de esa transformación ha de ser sencillo y las decisiones que tome el usuario para la transformación de esos datos han de ser comprensibles y que no generen dudas al no estar claramente explicadas: no hay nada peor que quedarse delante de una pantalla porque no se sabe que botón se tiene que pulsar en un proceso de transformación de datos. Sencillez y claridad.

El tercer punto es la rapidez. Los datos se han de transformar en un tiempo razonable para su volumen y la complejidad del proceso de cálculo necesario. Ponte como ejemplo el tiempo necesario entre que carga una página web y decides que el contenido vale la pena la espera. Si abandonas la carga de la página, es que el resultado no es tan importante como el tiempo necesario para obtenerlo. Lo mismo ocurre con las aplicaciones móviles: un tiempo excesivo acabará siendo totalmente contraproducente y el usuario se echará atrás y no dará una segunda oportunidad a la aplicación. Si este proceso, por las circunstancias que sean, ha de ocupar cierto tiempo, al menos, apunta que en esta parte del flujo de trabajo el usuario ha de estar informado constantemente de la cantidad de datos procesados para poder estimar un tiempo específico para el resultado final: a veces el temporizador rotatorio de Apple no es lo mas satisfactorio de su interfaz porque uno no es consciente de cuánto tiempo queda para obtener un resultado.

Mañana diseñaremos el flujo de trabajo de una aplicación para poder tener un esquema completo de cómo va a funcionar y poder un esqueleto sobre el que, ahora si, poder ponernos a programar.