Lo que debemos y lo que queremos

El Viernes 30 de Julio liberamos en Ayerviernes uno de los proyectos más complejos y demandantes que nos ha tocado afrontar: Clerk, un sistema web-based para gestionar hoteles. Es difícil calcular el tiempo que ha transcurrido entre el sueño inicial que tuvo Jorge de tener una herramienta que le permitiera administrar su hotel sin depender de un proveedor de software de escritorio, al nervio y las ansias que teníamos todos de lanzar este proyecto que tanto nos ha costado.

Y es que pensar y realizar un proyecto propio, para un equipo que se dedica a pensar y realizar los proyectos de los demás es realmente complicado. Las metodologías que siempre aplicas para cada trabajo parecieran ser poco necesarias y toda planificación para llevarlo a cabo suele verse entorpecida o simplemente quedar de lado por los compromisos y las urgencias de los otros proyectos. A su vez, la autoexigencia por hacer el producto más bello, usable y 2.0 de todos también juega en contra y quedas en el limbo de los bugs y las mejoras, corregir lo eternamente corregible.

Pero a pesar de las complicaciones, ningún otro esfuerzo deja más aprendizajes y es más gratificante que el que se realiza en los proyectos propios. Me parece que Clerk es uno de los mejores productos que hemos creado en AyerViernes, una aplicación a nivel mundial. Pero además es uno de los que más sentido de compromiso, pertinencia y felicidad ha generado en el equipo.

1 año en AyerViernes

Sacando cuentas de un año más que bueno, profeccionale

El 2007 fue un año movido, estresante, agoviante, pero cool!!. Así que para que este año sea igual de dinámico, hay que plantearse metas:

  • Aprender RoR
    • Al menos programar una aplicación, andando
  • Llegar a ser usuario medio – avanzado de Linux
    • Solucionar problemas complejos
    • Configurar bien todo lo que quiera
    • Escritorio extendido incluído
  • Terminar la carpeta de mi proyecto de título
  • Aprender más sobre Diseño de Interacción
  • Hacer clases sobre Diseño Front (faena que ya comence, particularmente)

Interacción y diagramas de flujos

Cuando diseñamos sistemas transaccionales o aplicaciones sociales, donde tenemos módulos de interacción condicional y necesitamos asegurarnos que todas las posibilidades posibles están pensadas, es necesario construir diagramas de flujos de todos los factores que se involucran en el sistema que queremos desarrollar. Este es un paso importantísimo que puede ahorrarle muchas horas a los procesos de producción de una web, ya que a través de los diagramas se pueden prever la mayoría de los problemas de coherencia, solidez y concretividad de lo que queremos que el usuario realice, además de detallar claramente cuales son las acciones que se deben diseñar y programar.

Diagrama de flujo básicoLos diagramas de flujos o flowcharts representan la forma más tradicional y duradera para especificar los detalles algorítmicos de un proceso. Se utiliza principalmente en programación, economía y procesos industriales, sin embargo, su lenguaje estándar nos permiten utilizarlos para definir procesos no matemáticos.

Para la construcción de diagramas existe la estandarización ISO 5807 (texto en francés), que describe una gran cantidad de elementos gráficos que podemos usar para su construcción, además del correcto uso de ellos. Existe el vocabulario visual que hizo Jessie James Garret, sobre mapas de Arquitectura de información e Interacción, el que se encuentra más flitrado y está directamente vinculado a los mapas de AI.

La idea de los diagramas de flujos es que detallen todas las acciones que se plantean en el Diseño de Interacción y que, junto con la estructura de contenidos puesta por la Arquitectura de Información, permitan determinar los comportamientos y definir el QUE, CÓMO y CUÁNDO estará presente en nuestro sitio.

Links