Diseñar aplicaciones para el iPhone, iPod Touch e iPad, parte II: el flujo de trabajo

Ya hemos sentado las bases de qué va a hacer nuestra aplicación para el iPhone, iPod Touch o iPad: sabemos que hay un punto de origen y un punto de destino.

En el medio, claro, pueden pasar muchas cosas y en función de como diseñemos las opciones del tránsito de la información podremos haber dado muchos pasos adelante (o atrás) en el éxito de nuestra aplicación: es el flujo de trabajo, de cómo fluirán los datos entre el inicio y el final (o resultado).

Es el momento de coger lápiz y papel, al menos para los primeros bocetos y comenzar a dibujar.

El diseño de flujo de trabajo es el auténtico esqueleto de tu aplicación: es la hoja de ruta que seguirá la información desde un punto a otro y como será modificada, distribuida o desviada en función del interés del usuario. Eso quiere decir que nos podemos encontrar fácilmente con una auténtica pirámide que conforme va pasando por cada una de las fases de transformación de datos promovidas por las decisiones del usuario (inmediatas o introducidas en las preferencias de la aplicación) derivarán los resultados hacia una forma de presentar los datos u otra.

Así que partiremos desde un punto “superior” y comenzaremos a establecer capas de decisión, de forma que en cada capa añadiremos un operador que permite modificar los datos en función de una preferencia específica del usuario. Estas preferencias pueden ser variadas: pueden venir de un panel general de opciones que se aplican a todo el flujo (las preferencias generales de la aplicación y por ejemplo, trabajar con una determinada métrica de unidades como centímetros o pulgadas) como en decisiones puntuales en medio del proceso de obtención de datos (obtención, por ejemplo, de un punto geográfico que puede ser variable o una barra de menús, un listado o un menú rotatorio).

Diseñar un flujo de trabajo no es precisamente fácil: hay muchas decisiones en el tratamiento intermedio de los datos que pueden abrir otros muchos árboles de subprocesos o de tratamiento de los datos, así que hay que seguir una serie de normas generales para no perdernos:

  • Tu flujo de datos ha de ser sencillo y debe tratar de eliminar cuantos pasos superfluos sean posibles. No hay que entretener al usuario con múltiples opciones una detrás de otra cuando pertenecen a un único grupo de decisión que puede solucionarse en una sola pantalla. Simplifica, simplifica y cuando creas que no puedes simplificar mas, elimina aún mas pasos intermedios.
  • Debes recordar que tu flujo es navegable: si no planificas bien el flujo de trabajo te puedes dar cuenta muy tarde que llegados a un punto en el que el usuario quiere modificar una opción algún paso más atrás (o incluso se ha equivocado) no podemos obligarle a empezar todo el proceso desde el principio: el usuario que utiliza nuestra aplicación debe poder desplazarse adelante y atrás cambiando los condicionantes que modificarán los datos finales sin perder la información previamente introducida.
  • Mantén informado al usuario en que punto del flujo de trabajo se encuentra. No sería la primera vez en que un usuario no sabe a ciencia cierta, tras un despiste, si está decidiendo una cosa u otra dentro del flujo de datos.
  • En la medida de lo posible, los resultados han de ser comparables, cosa que con frecuencia se olvida entre los desarrolladores: si yo creo una aplicación que me permite navegar por el metro de Londres, ¿porqué no puedo almacenar una ruta para compararla con otra similar para poder establecer una ruta mejor?

    Esta característica se omite frecuentemente en las aplicaciones para móviles y suele forzar al usuario a tener que repetir una y otra vez un proceso para poder comparar datos. El guardado de flujos completos es otra opción interesante en una aplicación: poder guardar rutas dentro del proceso y poder modificarlas es una interesante opción que tampoco se utiliza con cierta frecuencia en las aplicaciones y utilidades.

  • En esta fase no tienes que dibujar elementos de interfaz tan siquiera: es una declaración de intenciones de cómo se va a comportar la aplicación de forma que podamos establecer una estructura general del movimiento de datos. Pero preparemos un esquema para una aplicación, en concreto, por ejemplo, un sencillo editor/gestor de textos para bitácoras para ejecutar en en un dispositivo móvil. Veremos muchos ejemplos de cómo funciona un flujo de trabajo.

    flujo_app_iphone.jpg
    Click para ampliar

    Ni tan siquiera necesitas crear este flujo con el ordenador: posiblemente te será mas cómodo usar un lápiz y papel al principio para poder borrar o redireccionar ciertos flujos de información (en negro de acceso, en rojo, de retorno) lo que te va a poder permitir construir una aplicación cuya usabilidad sea al menos, sólida.

    Mañana jueves empezaremos a construir un prototipo de la aplicación y os suministraremos herramientas para ello de forma que sin tan siquiera programar una línea de código tengas “algo” que se parece a la aplicación que quieres construir.

    0 0 votos
    Article Rating
    Subscribe
    Notify of
    2 Comments
    Oldest
    Newest Most Voted
    Opiniones Inline
    Ver todos los comentarios
    Anónimo
    Anónimo
    13 years ago

    Muchas gracias por este artículo, sois fantásticos.

    --414627--
    --414627--
    13 years ago

    Muy interesante, espero los siguientes.

    2
    0
    Me encantaría saber tu opinión, por favor, deja un comentariox
    ()
    x