Entries Tagged 'Usabiliad' ↓

Prototipo: Listado de listas

Listado de listas

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.

Listado de listas 2De 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.

Check 6: Árbol de navegación

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.