The Checker, el blog de desarrollo

He estado pensando cómo podría diseñar la interfaz de forma que:

• fuera fácil de usar
• muestre suficiente información como para saber el estado de las listas

teniendo en cuenta que en esta vista se deberá de poder:

• crear nuevas listas
• editar las listas
• eliminar listas
• compartir una lista
• buscar sobre las listas
• ver información sobre ellas

A la hora de ponerme con esta vista,  tengo claro que habrá un listado con las distintas listas y que al lado de ella se indicará si está o no completa. Para eso son los circulos que hay junto a cada lista. Este será de color X cuando esté completa y de color Y cuando no (no se qué color usar para cada caso por eso pongo X e Y).

También tengo claro que la edición tiene que ser “inline”, es decir, al hacer doble click sobre el título de la lista, esta podrá editarse. Hasta aquí todo claro,  pero ¿cómo proporciono la posibilidad de borrar y compartir una o varias entradas?, se me ocurre que permitiendo seleccionar varias listas y teniendo un botón/icono que lance la acción de borrar/compartir (en la imagen de arriba se contempla esta idea).

Ahora me pregunto, ¿realmente va a merecer la pena hacer borrados y comparticiones simultáneas de grupos de listas cuando a lo sumo se van a tener 10 en pantalla (en cada página)? ¿Tan incómodo puede ser hacerlo una a una?

Con estas dudas en la cabeza  he planteado un prototipo en el que no se puedan realizar acciones a grupos de listas de forma que todas las listas tengan un icono para cada acción. Esto iconos aparecerían cuando se pasara el ratón por encima del título de la lista.

De esta forma se podría añadir la opción de indicar a qué categoría pertenece una lista, añadiendo un campo más, debajo del campo para indicar el título de la nueva lista.

Finalmente, me quedo con el segundo prototipo porque lo veo más limpio.

El árbol de navegación, es una forma de representar las opciones que el usuario tiene a la hora de navegar por el site/aplicación. Para este caso he optado por un diagrama de árbol hecho con la herramienta XMind

El nodo raiz representa la página de inicio, en la que se dará la opción de iniciar una sesión o registrarse en la aplicación. Por este motivo los hijos del nodo raiz son register y <username>, donde register representa el formulario de registro y <username> la página de inicio del usuario.

En la aplicación sólo los usuarios logados tendrán permisos para crear, editar y modificar las listas y sus elementos y por ello todas las urls caen por debajo del nodo <username>.

Una vez estamos en la página <username> a.k.a página de inicio del usuario logado, este podrá:

• editar su  datos referentes a la cuenta registrada en la aplicación, para ello deberá acceder a la ruta /<username>/edit.
• configurar la compartición de listas con otros usuarios a través de la ruta /<username>/share.
• ver sus listas, borrarlas, crear nuevas  y buscar sobre ellas a través de las rutas  /<username>/lists/add , /<username>/lists ,  /<username>/lists/<list name>/edit y /<username>/lists/<list name>/delete
• ver los elementos de una lista, editarlos, eliminarlos y añadir nuevos a través de las rutas /<username>/lists/<list name> ,  /<username>/lists/<list name>/<item>/edit , /<username>/lists/<list name>/<item>/delete y /<username>/lists/<list name>/add

Hay que tener en cuenta que  este esquema no se recoge los posibles saltos en la navegación, como por ejemplo el ir desde la ruta  /<username>/lists/<list name> a la página de inicio. Estas relaciones se darán en la aplicación pero añadirlas al esquema provocaría un poco de ruido, por este motivo solo pongo la navegación más relevante de cara al usuario y a las acciones que este puede realizar en la aplicación.

Todavía no he cerrado el prototipo del listado de listas (valga la redundancia), pero está la posibilidad que desde esa vista sea desde la que se creen las entradas. Si es así, el usuario no vería que cambia de url en el momento de creación de una lista, por lo que este esquema estaría mal, ¿no?. Pués desde mi punto de vista no lo estaría  ya que  Django necesita de una url para realizar una acción de forma que para poder añadir una lista habría que hacer la petición a través de la url definida en el esquema, pero sin que esta muestre un nuevo contenido HTML.

He subido al repositorio el documento de análisis funcional en el que describo los siguientes puntos:

• Finalidad y objetivos
• Usuarios del sistema
• Análisis de requisitos
• Modelo de datos
• Integración de Couchdb y Django

El documento no es muy extenso, ya que el desarrollo no requiere el uso de extensiones de Django que estén fuera de lo normal,  funcionalmente no es complejo (salvo la gestión de listas compartidas) y en el catálogo de requisitos se definen con detalle lo elementos que entran en juego en cada sección de la aplicación, aportando una descripción funcional suficiente como para afrontar el proyecto.

De los puntos mencionados anteriormente, hay uno que no tengo claro , Integración de Couchdb y Django, ya que no se con certeza cómo va a funcionar Django junto a CouchDB y lo que es más importate, nunca he afrontado un proyecto usando CouchDB ni bases de datos no relacionales.

A medida que vaya peleándome con CouchDB iré actualizando el documento con las decisiones que vaya tomando  en lo relacionado al modelo de datos y la integración con Django.

Pués eso, el nuevo prototipo para el formulario de registro:

Formulario de registro

Un formulario con los datos básicos para poder registar usuario y poder enviarles correos.

He estado dándole algunas vueltas al prototipo de la página de inicio y lo he dejado así:

Página de inicio

La página de inicio quiero que sea clara, que te diga para qué sirve la aplicación y cómo comenzar a usarla. Para ello

se me ha ocurrido mostrar varios casos de uso a través de historietas usando el formato de tiras cómicas. Se que puede ser un poco complicado, porque puede llegar a confundir al usuario si no lo hago bien, pero creo que puede ser una forma divertida de mostrar su uso, así que  lo voy a intentar.

A continuación de las historietas quiero indicar los distintos pasos que hay que seguir para que un usuario pueda usar la aplicación  usando un formato de lista de tareas(el que use la aplicación para mostrar una lista). Este listado indicará los siguientes pasos

• Registrarse en la aplicación
• Activar la cuenta para usar la aplicación
• Iniciar sesión en la aplicación
• Crear una lista
• Añadir entradas a la lista

En la página habrá un enlace para acceder al formulario de registro y otro para iniciar sesión. Este último desplegará el formulario de login (como el que se usa en twitter).

Página de inicio con login

¿Qué dudas/inseguridades tengo?

Pués algunas como por ejemplo:

• Los espacios: No se si la disposición de los componentes de la vista son los mejores para una aplicación. ¿Es mejor aprovechar el ancho completo de la pantalla o por el contrario definir unos márgenes?
• ¿Habrá suficiente información en esta página como para que el usuario comprenda su uso? Hay que tener en cuenta que esta aplicación no está pensada para usuarios expertos/avanzados, esta aplicación tiene que poder ser usada por todos.

¿Este proyecto sigue abandonado?…es la pregunta que ha rondado por mi cabeza el tiempo que no he ausente del proyecto. No porque lo fuera a abandonar sino porque la gente que sigue este proyecto lo pensara.

Creo que ha sido un mes, más o menos, lo que he estado sin escribir por aqui, ni publicar nada en la forja. Los motivos han sido varios, desde tener que apagar fuegos (véase apagar fuegos como el tener que resolver tareas contrarreloj en el curro), hasta estar enfermo durante una semana con uno de esos virus que la gente dice “todo el mundo lo tiene ahora”.

En la oficina hemos tenido varios cierres de proyectos simultáneos y hemos tenido que apretar un poco el cinturón para que todo fuera, como solemos decir en la ofi, peeeeerfe XD. A esto se le ha juntado un par de viajes a Ceuta como formador de Drupal, en los que durante 7 días he impartido un curso en el que explicaba un poco de  metodología para el desarrollo de sites en Drupal, así como también desarrollar módulos para Drupal. La experiencia fue muy buena pero también fue agotadora ( no valgo para ir en ferries :S)

Antes de irme a Ceuta, fui a Barcelona unos días  para asistir a la Drupalcamp 2010 y bueno… no pegaba ponerme con Django en mitad de una conferencia.

A pesar de haber estado ausente, avancé un poco en pequeñas tareas como la definición del árbol de navegación y los prototipos de la aplicación. Las tareas están en la forja [1] pero aún no están cerradas, tengo que darles un par de vueltas para estar seguro, sobre todo a los prototipos que no tengo muy claro que sean la mejor solución.

[1] repositorio svn

Si hace hace un par de días me hubieran preguntado por CouchDB o una base de datos orientada a documentos hubiese contestado WTF y me hubiese puesto a mirar en google porque solo he trabajado con las típicas (Postgresql, Mysql y sqlite).

La pasada semana llegó un correo a la lista [Tech] de emergya (empresa en la que trabajo) en el que se mencionaba a CouchDB y entonces entró a formar parte de mi vocabulario aunque sin saber muy bien de que iba el rollo (solo sabía que era una base de datos, por eso del DB :S).

Hoy mi compañero Juanje me comentó que podría usar CouchDB en The Checker porque veia que se le podría sacar partido  y bueno, tras comentarme un poco como iba el rollo y leer una entrada que escribió en el blog de emergya [1]  lo vi super interesante y ya que estoy en la fase de análisis y diseño, he decidido intentar integrar CouchDB en el proyecto.

[1] No todo es ralacional

Ya que tengo una primera versión del catálogo de requisitos he aprovechado para generar los primeros casos de pruebas de la aplicación. Cuando termine con el documento de análisis y diseño saldrán más casos de pruebas y por eso mismo quiero adelantar un poco la tarea. Es un poco aburrido tener que crear tropecientos casos de pruebas en la forja, creo que es mejor ir generandolos a medida que vaya cerrando documentos.

Cuando los casos de pruebas estén generados, los podré relacionar con las tareas de forma que tenga una matriz de trazabilidad y así pueda ver que funcionalidad tengo lista para testear y validar. No tengo muy claro si la forja lo permite sino pués hare una tabla con los datos que iré actualizando.

El track con los casos de pruebas están en [1] por si alguien los quiere ir viendo aunque por el momento solo tengo 7 definidos.

[1] Casos de pruebas

Un poco tarde pero la vesión 1.0 del catálogo de requisitos ya está lista. En este documento se contemplan los requisitos básicos para esta primera fase( hacer una aplicación muy básica para gestionar listas entre usuarios) a nivel funcional.

A partir de este documento podré generar el documento de análisis y diseño así como también los casos de pruebas para que el proyecto se de por finalizado y sin ningún fallo.

En este mismo instante, que escribo este post estoy pensando que podría dejar de escribir documentos y poner me a programar (que es lo que más me mola) pero creo que estos documento pueden servir a que otros desarrolladores que se interesen por el proyecto sepan de que va y cuales son sus objetivos…..así que toca aguantarse y escribir durante una semana más.

En [1] podeis acceder a la forja y ojear el documento.

[1] catálogo de requisitos