Trabajo Fin de Carrera - Diseño y Desarrollo Del Sistema CitYsens para La Eparticipación Municipal

UNIVERSIDAD DE ALCALA
Escuela Polite cnica Superior

INGENIERI A EN INFORMA TICA
Trabajo Fin de Carrera
DISEN O Y DESARROLLO DEL SISTEMA CITYSENS
PARA LA ePARTICIPACIO N MUNICIPAL
PABLO A LVAREZ JIME NEZ
2014

UNIVERSIDAD DE ALCALA
Escuela Polite cnica Superior
INGENIERI A EN INFORMA TICA
Trabajo Fin de Carrera
DISEN O Y DESARROLLO DEL SISTEMA CITYSENS PARA LA
ePARTICIPACIO N MUNICIPAL
Autor: Pablo lvarez Jimnez
Director/es: Luis de Marcos Ortega y Pedro Prieto Martn
TRIBUNAL:
Presidente:
Vocal 1:
Vocal 2:
CALIFICACIN: .....................................................................................................
FECHA: ................................................................................

Agradecimientos

N

Music

Resumen
A pesar de la acogida masiva que han recibido las redes sociales en los ltimos aos, dichos
sistemas no proporcionan herramientas que favorezcan el beneficio social ni la participacin
ciudadana. Por ello, y acrecentado por el incipiente malestar social surge CitYsens, una plataforma de
software cvico online con todas las caractersticas de la Web 2.0 pero dedicada exclusivamente a
mejorar y facilitar la participacin ciudadana, la colaboracin y, en general, el beneficio social en
todos sus niveles. Este trabajo documenta los avances hechos en las fases iniciales de anlisis y
diseo para la creacin del sistema CitYsens.
Abstract
Even though social networks have received an overwhelming acceptance worldwide, these
systems dont have social benefit and civic participation as one of their goals. Because of that, and
inspired by the increasing social disagreement of our citizens arises CitYsens, a civic software online
platform with all the Web 2.0 features but with the only aim of improving and enhancing citizen
participation, collaboration and, ultimately, social betterment in every level. This piece of work
describes the initial stages of the analysis and design phases involved in the creation process of
CitYsens.
Palabras clave
CitYsens, Software Cvico, eParticipacin, Diseo Colaborativo y Wireframes

Resumen extendido
El presente documento describe las fases iniciales de anlisis y diseo llevadas a cabo para la
construccin del sistema CitYsens. CitYsens es una plataforma de participacin ciudadana municipal
basada en tecnologas y conceptos Web 2.0, que pretende acompaar, potenciar y dinamizar las
iniciativas de participacin cvica de la ciudad. Este sistema es un trabajo de la Asociacin KyoPol, una
organizacin ciudadana comprometida con el fortalecimiento de la participacin en el mbito
municipal y regional.
CitYsens pretende proporcionar un conjunto integrado de herramientas que permitan que los
ciudadanos se informen sobre las actividades participativas que se llevan a cabo en su ciudad, distrito
o barrio relacionadas con las temticas que sean de su inters. Se persigue que la plataforma provea
un soporte virtual a procesos participativos complejos, permitiendo que grupos numerosos de
ciudadanos puedan mantener discusiones y estructuradas y de calidad, as como identificar los
consensos existentes, presentar iniciativas legislativas y monitorear la ejecucin de los acuerdos
alcanzados.
Para ello se sigue un proceso de diseo e implementacin colaborativo, donde se cuenta con
grupos de usuarios con diferente grado de implicacin que construyen el sistema de manera
distribuida y coordinada. CitYsens es construido como software cvico; su programacin y
mantenimiento se realizar por un conjunto de programadores e instituciones que contribuirn al
proyecto desinteresadamente.
A lo largo de este trabajo se describirn las diferentes estructuras participativas de coordinacin
utilizadas, as como las herramientas utilizadas en el desarrollo de este proyecto. Se incluyen las
tareas de investigacin llevadas a cabo sobre tecnologas de desarrollo web y la interconexin de las
mismas.
Se llevar a cabo un anlisis exhaustivo de la Agenda del Henares, un sistema ya existente que
comparte varias caractersticas con CitYsens, aunque con un enfoque ms simplista en su
implementacin. Mediante este estudio se extraen los diferentes requisitos funcionales que deber
cumplir el sistema, as como los puntos fuertes y flojos que debern implementarse o mejorarse en la
construccin de CitYsens.
En la ltima seccin, se detallan los pasos seguidos en la fase de diseo del sistema. Se incluyen
los prototipos de pantallas creados, as como las caractersticas de los mismos. Se documenta todo el
proceso iterativo de generacin de distintas versiones donde se refinan las funcionalidades del
sistema, atendiendo a la interaccin con el usuario y a la usabilidad.
Este proyecto de fin de carrera describe los primeros pasos en el largo proceso de creacin de un
sistema tan complejo y ambicioso como es CitYsens.

ndice
AGRADECIMIENTOS.......................................................................................... 5
RESUMEN, ABSTRACT, PALABRAS CLAVE .............................................................. 7
RESUMEN EXTENDIDO ...................................................................................... 9
NDICE ........................................................................................................ 11
NDICE DE FIGURAS ........................................................................................ 13
INTRODUCCIN ............................................................................................. 17
CAPTULO I. METODOLOGA Y PASOS PREVIOS ................................................. 21
1. Grupos de trabajo .................................................................................................... 21
2. Herramientas .......................................................................................................... 22
2.1 Herramientas de difusin .......................................................................................................... 22
2.2 Herramientas de coordinacin .................................................................................................. 26
2.3 Herramientas de trabajo ........................................................................................................... 29
3. Iniciacin al desarrollo web ..................................................................................... 31
3.1 Entorno inicial, conexin a BBDD y operaciones CRUD ............................................................ 32
3.2 Interfaz de usuario .................................................................................................................... 35
3.3 Servidor local, AJAX y jQuery ..................................................................................................... 36
3.4 Conclusiones .............................................................................................................................. 39
CAPTULO II. ANLISIS Y DISEO ................................................................... 41
1. La Agenda del Henares (Agenda del Henares, 2013) ................................................. 41
1.1 Qu es la Agenda del Henares ................................................................................................... 41
1.2 Casos generales de uso ............................................................................................................. 47
1.3 Anlisis de funcionalidades ....................................................................................................... 55
2. Diseo con Wireframes ............................................................................................ 86
2.1 Balsamiq Mockups..................................................................................................................... 86
2.2 Intencin y forma de trabajo ..................................................................................................... 88
2.3 Evolucin y componente participativo ...................................................................................... 93
2.4 Wireframes ................................................................................................................................ 96

CONCLUSIONES ........................................................................................... 125
BIBLIOGRAFA ............................................................................................. 127

ndice de figuras
Captulo I. Metodologa y pasos previos
Figura I.1 Pgina web de la asociacin Kyopol (http://www.kyopol.net) ....................................... 23
Figura I.2. Blog Rumbo a Lrien (http://rumboalorien.kyopol.net/) ............................................... 24
Figura I.3. Perfil de Facebook de la asociacin Kyopol .................................................................... 25
Figura I.4. Grupo de trabajo en Facebook de la asociacin ............................................................ 26
Figura I.5. Grupos de Google de la asociacin ................................................................................ 27
Figura I.6. Tablero "Impulsores - Tareas" en Trello ......................................................................... 28
Figura I.7. Carpeta compartida en Dropbox para el equipo Impulsor ............................................. 29
Figura I.8. Wireframe de ejemplo creado con Balsamiq Mockups .................................................. 30
Figura I.9. SourceTree ...................................................................................................................... 31
Figura I.10. Curso de Codecademy para PHP .................................................................................. 33
Figura I.11. Firebug en accin, mostrando peticiones entre cliente y servidor ............................... 38
Figura I.12. Pgina creada durante el aprendizaje ......................................................................... 40
Captulo II. Anlisis y diseo
Figura II.1. Sitio web de Demosphere, mostrando los lugares donde se utiliza .............................. 42
Figura II.2. Lista de eventos de la Agenda del Henares ................................................................... 43
Figura II.3. Eventos resaltados utilizando el filtro de categora ...................................................... 43
Figura II.4. Filtros de bsqueda avanzados ..................................................................................... 44
Figura II.5. Resultados de una bsqueda ........................................................................................ 44
Figura II.6. Herramienta calendario ................................................................................................ 44
Figura II.7. Pgina para configurar la suscripcin ........................................................................... 45
Figura II.8. Formas de participacin en la Agenda .......................................................................... 45
Figura II.9. Formulario para un nuevo evento de la Agenda ........................................................... 46
Figura II.10. Criterios de publicacin de la Agenda del Henares ..................................................... 47
Figura II.11. Pgina de un evento .................................................................................................... 48
Figura II.12. Formulario para un nuevo comentario ....................................................................... 49
Figura II.13. Formulario para enviar un evento por correo electrnico .......................................... 49
Figura II.14. Controles para compartir el evento en Facebook o Twitter ........................................ 50
Figura II.15. Controles de bsqueda de la pgina principal ............................................................ 50
Figura II.16. Pgina con los resultados de bsqueda ...................................................................... 50
Figura II.17. Opciones de bsqueda avanzada ................................................................................ 51
Figura II.18. Control para filtrar eventos mediante una circunferencia en el mapa ....................... 51
Figura II.19. Eventos mostrados a travs de un enlace directo con criterios de bsqueda............. 52
Figura II.20. Grupo de Google para la coordinacin de la Agenda del Henares ............................. 54
Figura II.21. Control para iniciar la suscripcin desde la pgina principal ...................................... 55
Figura II.22. Configuraciones para la frecuencia de correos de la suscripcin................................ 57
Figura II.23. Configuraciones para los tipos de eventos de la suscripcin ...................................... 57
Figura II.24. Ms opciones para la configuracin de la suscripcin ................................................ 58
Figura II.25. Configuracin del widget de la Agenda para otras pginas web ............................... 59

Figura II.26. Opciones de presentacin del widget ......................................................................... 60
Figura II.27. Configuracin de la agenda personal ......................................................................... 61
Figura II.28. Ejemplo de agenda personalizada .............................................................................. 61
Figura II.29. Monitorizacin del estado del perfil de Facebook ...................................................... 63
Figura II.30. Formulario para proponer un evento en la Agenda del Henares ................................ 64
Figura II.31. Ejemplo de formulario completo ................................................................................. 65
Figura II.32. Mensaje informativo sobre la creacin del evento ..................................................... 65
Figura II.33. Pantalla de edicin de un evento para un usuario administrador de la Agenda ........ 67
Figura II.34. Panel de revisiones de un evento ................................................................................ 68
Figura II.35. Herramienta de comparacin entre revisiones de un evento ..................................... 68
Figura II.36. Gestor de repeticiones para eventos peridicos ......................................................... 69
Figura II.37. Herramienta para la edicin mltiple de repeticiones de eventos ............................. 70
Figura II.38. Panel de control de la Agenda para un usuario administrador .................................. 73
Figura II.39. Informacin de usuarios de la agenda ........................................................................ 74
Figura II.40. Informacin sobre cambios recientes sobre un evento concreto ................................ 75
Figura II.41. Eventos ms visitados ................................................................................................. 75
Figura II.42. Diferentes municipios de la Agenda del Henares ........................................................ 76
Figura II.43. Herramienta para la fusin de municipios .................................................................. 77
Figura II.44. Lista de eventos de la Agenda del Henares ................................................................. 77
Figura II.45. Lugares donde acontecen los eventos, relacionados con sus respectivos municipios 78
Figura II.46. Diferentes posts de la Agenda del Henares................................................................. 78
Figura II.47. Gestin de las temticas para un usuario administrador ........................................... 79
Figura II.48. Diferentes "trminos de la Agenda del Henares ....................................................... 79
Figura II.49. Informacin sobre un usuario concreto en formato de PHP Array ............................. 80
Figura II.50. Opcin para crear carpools ......................................................................................... 81
Figura II.51. Diferentes fuentes de eventos definidas en la Agenda del Henares ........................... 82
Figura II.52. Parseo de las pginas monitorizadas con potenciales eventos para la agenda ......... 83
Figura II.53. Estadsticas de la Agenda del Henares, utilizando AWStats ....................................... 84
Figura II.54. Interfaz de usuario de Balsamiq Mockups .................................................................. 87
Figura II.55. Enlazado de wireframes simulando la navegacin sobre una pgina real ................. 88
Figura II.56. Tarjeta para la coordinacin de los diferentes wireframes en Trello .......................... 90
Figura II.57. Ejemplo de wireframe con notas y comentarios descriptivos ..................................... 91
Figura II.58. Control de versiones de un archivo en Dropbox .......................................................... 92
Figura II.59. Post informativo en Facebook sobre el avance en el diseo ....................................... 93
Figura II.60. Tarea planteada a los pioneros en el grupo de trabajo de Facebook ......................... 95
Figura II.61. Resultados de bsqueda en Foursquare ..................................................................... 96
Figura II.62. Pgina principal de CitYsens en las primeras aproximaciones del diseo .................. 97
Figura II.63. Pgina mostrando resultados de bsqueda ................................................................ 98
Figura II.64. Barra superior para un usuario registrado en CitYsens .............................................. 99
Figura II.65. Pgina inicial de CitYsens. Versin 0 ......................................................................... 100

Figura II.71. Pantalla cuando el usuario hace clic sobre el control Ordenar por". Versin 3 ...... 107
Figura II.72. Control "Ordenar por". Versin 4 .............................................................................. 107
Figura II.73. Control "Ordenar por". Versin 5 .............................................................................. 107
Figura II.74. Eventos ordenados por temtica. Versin 3 ............................................................. 108
Figura II.75. Eventos ordenados por lugar. Versin 5 ................................................................... 108
Figura II.76. Vista del mapa al seleccionar un municipio adyacente ............................................ 109
Figura II.77. Vista del mapa al ampliar el zoom a nivel de municipio ........................................... 110
Figura II.78. Vista de la comunidad de Madrid y sus diferentes zonas ......................................... 110
Figura II.79. Pantalla con un evento seleccionado. Versin 5 ....................................................... 111
Figura II.80. Evento expandido. Versin 4 ..................................................................................... 112
Figura II.81. Evento expandido. Versin 5 ..................................................................................... 113
Figura II.82. Lista de eventos, ocultados los eventos peridicos. Versin 5 .................................. 114
Figura II.83. Barra de bsqueda ofreciendo sugerencias en base al texto introducido. Versin 5 115
Figura II.84. Sugerencia "Ir a" para otras zonas. Versin 5 ........................................................... 116
Figura II.85. Control de bsqueda avanzada. Versin 5 ................................................................ 117
Figura II.86. Resultados de bsqueda con la temtica "Sanidad". Versin 5 ................................ 117
Figura II.87. Resultados de una bsqueda por texto. Versin 5 .................................................... 118
Figura II.88. Pgina para proponer un evento en CitYsens. Versin 5 .......................................... 119
Figura II.89. Introducido un ttulo y desplegado el control de temtica. Versin 5 ...................... 120
Figura II.90. Editando la descripcin. Introducidas temticas, etiquetas, fecha y hora ............... 121
Figura II.91. Barra de bsqueda en el mapa sugiriendo localizaciones existentes. Versin 5 ...... 121
Figura II.92. Pop-up para seleccionar el lugar para el evento. Versin 5 ...................................... 122
Figura II.93. Formulario completado. Versin 5 ............................................................................ 123
Figura II.94. Pantalla de entidades. Versin 5 ............................................................................... 124

DISEO Y DESARROLLO DEL SISTEMA
CITYSENS PARA LA ePARTICIPACIN MUNICIPAL Universidad de Alcal de Henares
Pablo lvarez J imnez 17
Introduccin
A da de hoy, vivimos en una sociedad en la que el descontento de la poblacin es manifiesto.
Cada da es ms obvia la separacin entre los poderes legislativos y los ciudadanos de a pie, que
son los que sufren las injusticias sociales, los desequilibrios de poder y que sienten estar atados de
pies y manos al no poder hacer nada ms que votar una vez cada cuatro aos. A estos ciudadanos, no
se les consulta, ya que se asume que el gobierno electo tiene el respaldo absoluto por el simple
hecho de haber sido elegido en un proceso que se define como democrtico, a pesar de las claras
deficiencias que presenta.
Una sociedad que pretende evolucionar a la par con todos sus ciudadanos debe tenerles en
cuenta en la toma de decisiones a lo largo de todo el proceso de legislacin, y no pedirles
nicamente un visto bueno a unas propuestas iniciales, que luego apenas tienen relacin con las
decisiones que se acaban tomando. Y ese es el problema, que los poderes legislativos no quieren
evolucionar socialmente. No tienen intencin alguna de cambiar las cosas, o de hacer ms por todos
y por el bien comn, sino por s mismos. Si de verdad se deseara fomentar el cambio, decidir para la
mayora y afrontar todos estos problemas sociales, se habra hecho mucho ms por facilitar la
participacin del ciudadano.
Por otro lado, tampoco es todo problema de los que gobiernan; el ciudadano es muy cmodo y
fcilmente se desentiende de la poltica. Mientras yo pueda comer y acceder ms o menos a una
vivienda, no me interesa protestar. Adems, qu puedo hacer yo?. Esta actitud es la que facilita el
crculo vicioso de no intentar hacer nada porque no hay nada que se pueda hacer.
Si nos fijamos en los ltimos aos, observamos que el descontento es mayor, pero realmente es
mayor? O es que gracias a la facilidad de comunicacin y difusin de informacin somos todos ms
conscientes de lo que sucede realmente a nuestro alrededor? Internet y las redes sociales tienen
gran culpa del descontento ciudadano, en la medida en que han facilitado esa comunicacin y nos
han hecho darnos cuenta de que no todo funciona bien, de que no todos estamos contentos.
Pero si nos fijamos en las herramientas a nuestra disposicin, en los medios utilizados para toda
esta difusin de informacin, cules son? Facebook y Twitter han explotado y se han convertido en
los medios de referencia para la informacin, dejando de lado a peridicos y medios de
comunicacin en general, principalmente por que la informacin proviene de y se dirige hacia todos
los usuarios, cualquiera que sea su trasfondo social. De esta manera, es virtualmente imposible que
los ciudadanos sean censurados en la informacin que publican, y rpidamente se prende la mecha y
se enciende la ciudadana cuando sucede algo especialmente injusto o desafortunado.
Pero, en qu queda todo? La gente se entera de las injusticias y problemticas sociales, le da al
botn de Compartir o Me gusta (realmente irnico, si nos paramos a pensarlo) para que todo su
crculo cercano se entere de lo mal que van las cosas y sigue con su vida, ya que qu puedo hacer
yo? Todo queda en mucho flujo de informacin y mucha gente informada, pero sin una voluntad
activa de cambio en la mayora de los casos.
Estas herramientas de comunicacin no fueron hechas para fomentar la participacin ni para
resolver problemas. Ambas son aplicaciones destinadas al entretenimiento. Facilitan la
comunicacin, desde luego, pero de cualquier formato y contenido. Y as como hay mucha
informacin interesante que se propaga a travs de estos medios, hay mucha ms informacin con
otro tipo de contenido: entretenimiento puro y duro. La principal caracterstica de estos medios
(comunicacin masiva y a nivel global) es un arma de doble filo: La gente utiliza las redes sociales
para pasar el rato, compartir ocio y distraerse, lo cual acaba creando ciudadanos autmatas que
entran en las redes sociales para entretenerse, ver videos de gatitos y, cuando se les acaba el tiempo
libre, volver a sus vidas en las que sienten que poco pueden hacer por el cambio.
Por todo ello, se hace manifiesta la necesidad de algn medio/herramienta que facilite informar y
mantenerse informado, pero que a la vez potencie y fomente la participacin activa del ciudadano.
Que el usuario sienta que puede hacer cosas, que hay mucho en juego y que somos muchos los que
estamos en desacuerdo con muchas cosas y los que, juntos, podemos intentar cambiarlo.
eParticipacin y CitYsens
Si algo se puede hacer para intentar cambiar todo el esquema poltico-social actual es fomentar
la participacin ciudadana a travs de la eParticipacin. Las TIC e Internet han revolucionado
prcticamente todas las reas en los ltimos aos: comercio, educacin, comunicacin, relaciones
sociales y muchos otros mbitos se han visto radicalmente alterados en su forma, y por tanto en su
resultado final.
De manera similar, el uso de dichas tecnologas puede facilitar y proporcionar mtodos y
herramientas que realmente alteren la situacin actual, permitiendo a los ciudadanos involucrarse
con su entorno y a la vez percibir que lo que hacen tiene influencia y produce, en ltima instancia, un
cambio en su situacin social.
Si no se ha hecho antes es por todo lo descrito anteriormente: Ni a los que tienen poder les
interesa, ni los que quieren un cambio saben cmo o por dnde empezar o no disponen de los
medios necesarios.
Por todo esto, surgi CitYsens. CitYsens es el resultado de una ardua investigacin en el mbito
de la eParticipacin por parte de la Asociacin KyoPol (Prieto Martn). La asociacin lleva desde 2004
dedicada a la investigacin, promocin y educacin en el rea de la eDemocracia. Ha producido
varios artculos, documentos y tesis donde detalla todos los descubrimientos en esta rea y analiza
qu ha fallado en otros sistemas con similares ambiciones.
CitYsens supone el paso a la accin, tras la recopilacin de requisitos iniciales y anlisis del
problema a afrontar. CitYsens planea ser una red social de participacin ciudadana, que utilice todos
los conceptos de la Web 2.0 para el bien comn, para potenciar y facilitar el cambio. Que los usuarios
finales se vean motivados por la misma, ya que les une a su entorno y a las personas con las que
conviven y les facilita las herramientas de comunicacin, participacin e iniciativa con las que
producir un cambio manifiesto.
Mediante un proceso colaborativo en el que se vern involucrados usuarios finales de la
aplicacin, se irn generando prototipos utilizando metodologas giles de desarrollo software de
manera que la construccin del sistema no sea un proceso cerrado: en l participarn los propios
usuarios finales detallando sus necesidades, opiniones e inquietudes referentes al sistema para
hacerlo suyo desde el principio. De esta manera se evita crear un sistema con el que los usuarios
finales no se identifiquen, no entiendan o del que no extraigan utilidad.
Objetivos del trabajo
Este proyecto de fin de carrera pretende documentar dicho proceso inicial de anlisis y diseo
colaborativo de la aplicacin. Inicialmente cubrir la organizacin del equipo, as como la
investigacin sobre herramientas para el diseo y mtodos de comunicacin, consulta y validacin
con los usuarios de los prototipos creados y de las necesidades a cubrir por el sistema. Tambin se
incluye una seccin detallando la investigacin sobre las tecnologas web ms utilizadas y su estudio
con vistas al futuro desarrollo.
En su segunda parte, se realizar un anlisis exhaustivo de la Agenda del Henares, una pgina con
similitudes a lo que se pretende conseguir con CitYsens aunque de una forma mucho ms bsica y
sencilla, con el fin de determinar requisitos y analizar qu aproximaciones de la Agenda son
apropiadas para CitYsens y cules no.
Por ltimo se documentan los diferentes prototipos de pantallas creados con el fin de describir
las transiciones y flujos de la aplicacin para determinados casos de uso, cubriendo as las fases
iniciales del diseo colaborativo del sistema. A travs de un ciclo de vida evolutivo e iterativo, se irn
refinando las versiones hasta alcanzar un diseo preciso y claro con el que poder pasar a la fase de
desarrollo.


Captulo I. Metodologa y pasos
previos
1. Grupos de trabajo
Para llevar a cabo el desarrollo de un sistema tan ambicioso como CitYsens, se deben establecer
mtodos y organizaciones de trabajo de manera que la escala del proyecto no suponga un problema
a la hora de abordar fases crticas como el anlisis y el diseo de una aplicacin. Al tratarse de un
sistema abierto en el que se involucrar a los usuarios del mismo a lo largo de todo el proceso, es
necesario establecer una serie de mtodos y vas de comunicacin y elegir las herramientas
adecuadas para llevar a cabo la misma.
Basndose en investigaciones previas (Hernando Garca, 2013) , se establecieron una serie de
grupos de usuarios, en base al papel que desempean en el desarrollo de la aplicacin, definindose
as el Grupo Impulsor y el Colectivo de Pioneros.
El grupo impulsor ser el equipo principal y encargado del desarrollo tcnico, metodolgico e
institucional del sistema. Este equipo lo componen las personas que van a trabajar ms
estrechamente en el proyecto. Como impulsores, son los encargados de estimular y producir
movimiento e inters a la hora de crear el sistema.
Los componentes de este grupo cubren todos las reas disciplinares ms importantes en un
proyecto de estas caractersticas, dividindose as en grupo de desarrollo e infraestructura tcnica,
grupo de metodologas y recursos participativos, grupo de financiacin y marketing, grupo de
comunicacin y grupo legal. Para la correcta coordinacin de todos estos diferentes mbitos, se
requieren mecanismos de comunicacin efectivos y un apoyo sobre el carcter participativo del
proyecto all donde se pueda aprovechar (promocin, votaciones, encuestas, etc.).
Este equipo impulsor se ayuda de otras personas e instituciones colaboradoras para promover
las actividades de creacin del sistema y las actividades complementarias que la asociacin Kyopol
promueve (Kyopol Ciudad Simbitica). El grupo impulsor se caracteriza por que sus componentes
dedicarn mucho ms tiempo y esfuerzo al proyecto que cualquier otro grupo de colaboradores.
El colectivo de pioneros incluye agentes representantes de la comunidad y potenciales usuarios
del sistema. Sern personas que estarn ms implicadas durante el proceso de implantacin y
utilizacin del sistema o se vern afectados por l. Tambin aportarn su granito de arena revisando
y probando distintos diseos y prototipos del sistema con vistas a un refinamiento con feedback por
parte de los usuarios finales. Ejemplos de miembros del colectivo de pioneros son asociaciones
vecinales, personal de concejalas de participacin, organizaciones ciudadanas, escuelas, el
movimiento 15M, partidos polticos, etc. Los pioneros aportarn una participacin ms espordica y
reactiva al proceso de creacin del sistema.
Debe hacerse notar que los miembros del equipo impulsor pueden ser a su vez parte del
colectivo de pioneros, ya que pueden participar en los mismos mbitos que estos, adems de ser a su
vez parte del ncleo creador del sistema.
Para llevar a cabo la organizacin y comunicacin de todas las partes, se han utilizado una serie
de herramientas y mtodos, los cuales se detallan a continuacin.
2. Herramientas
Para poder llevar a cabo la creacin de un sistema tan complejo como el que se pretende, se
debe disponer de unas herramientas y mecanismos de comunicacin que faciliten dicha tarea. Las
herramientas deben ser de rpido aprendizaje, de manera que proporcionen ms utilidad al usuario
que el coste que le supone tener que aprender a utilizar la misma.
A da de hoy, en internet hay gran cantidad de herramientas a disposicin de los usuarios,
muchas de pago y muchas otras con modalidades gratuitas o periodos de prueba.
Para el desarrollo de este proyecto se han definido una serie de herramientas a utilizar, que
permiten tanto a impulsores como a pioneros informar, consultar y mantener informado al resto del
equipo de distintos acontecimientos.
Se han identificado tres grupos de herramientas, en base al mbito que cubren en el marco del
proyecto: Herramientas de difusin, herramientas de coordinacin y herramientas de trabajo.
2.1 Herramientas de difusin
Las herramientas de difusin permiten a los impulsores informar a todo tipo de personas
(conocedoras del proyecto o no) de los diferentes eventos, hitos del proyecto, consultas, etc.
Los pioneros disponen tambin de un grado de acceso a estas herramientas, aunque en menor
medida que los impulsores.
Por un lado, la asociacin Kyopol dispone de una pgina web y un blog donde se publican
regularmente las distintas informaciones que ataen a la asociacin o al proyecto CitYsens (entre
otros).
La pgina proporciona informacin sobre la asociacin, estudios realizados, proyectos y tesis,
proyectos en los que participa actualmente, informacin para los usuarios sobre cmo participar,
subscripcin a distintas redes sociales de la asociacin (Facebook, Twitter, Vimeo, Youtube) e incluso
permite subscripciones RSS para usuarios que deseen recibir la informacin en cuanto se publica va
email.
La pgina tambin enlaza con la Agenda del Henares, que es una agenda colaborativa online que
la asociacin instaur en la zona de Alcal de Henares para ir despertando el inters por CitYsens, ya
que aunque la idea es parecida, la Agenda del Henares tiene varios aspectos que son mejorables. La
asociacin tambin se encarga de estudiar el uso que hacen los usuarios de dicha agenda, para
extraer qu caractersticas son ms utilizadas por los usuarios y patrones de uso de la misma. Toda
esta informacin se tendr en cuenta a lo largo del proceso de creacin de CitYsens, que pretende
mejorar y superar en funcionalidad a la Agenda del Henares.

Figura I.1 Pgina web de la asociacin Kyopol (http://www.kyopol.net)
La pgina web de la asociacin tambin enlaza con un blog bilinge, Rumbo a Lorien, donde
Pedro Prieto, fundador de la asociacin y coordinador del proyecto publica regularmente noticias y
artculos referentes al proceso de creacin de CitYsens.

Figura I.2. Blog Rumbo a Lrien (http://rumboalorien.kyopol.net/)
Por otro lado, la asociacin tambin dispone de un perfil en la red social Facebook donde publica
enlaces a noticias interesantes, siempre con la temtica comn de participacin ciudadana e
iniciativas populares. Noticias relativas a la asociacin o al sistema como entrevistas en programas de
radio y menciones por parte de otras webs son algunas de las publicaciones que se llevan a cabo
desde dicho perfil.
Mediante este perfil se intenta ampliar al mximo el alcance de la iniciativa y de la asociacin, ya
que al ser una de las redes sociales con ms extensin, proporciona un potencial de captacin de
nuevos usuarios muy grande.

Figura I.3. Perfil de Facebook de la asociacin Kyopol
A su vez, existe un grupo de trabajo en Facebook para las labores de co-diseo y testeo del
sistema por parte del colectivo de pioneros. Este grupo se utiliza para realizar consultas, encuestas,
solicitar opiniones o llevar a cabo votaciones, de manera que todo pionero pueda realizar su aporte
de la manera ms sencilla posible (maximizando de esta manera el porcentaje de participacin). A
este grupo de trabajo se pueden apuntar todos los usuarios que as lo deseen solicitando formar
parte del grupo y detallando el porqu de su inters.

Figura I.4. Grupo de trabajo en Facebook de la asociacin
Por ltimo, el portal de vdeos/red social Youtube es utilizado por la asociacin para exponer
vdeos divulgativos sobre CitYsens, eventos a los que se ha asistido, campaas en las que participa o
incluso ver las reuniones que lleva a cabo el grupo de impulsores.
Todas estas herramientas permiten que la asociacin ample el alcance de sus movimientos,
llegando a ms usuarios de esta manera y facilitando el proceso viral de propagacin que se
necesita para que un sistema de estas caractersticas tenga xito en su implantacin. Todas ellas
buscan permitir la comunicacin interna, pero sobre todo provocar un inters en la gran masa de
ciudadanos para despertar la expectacin y anticipacin del sistema.
2.2 Herramientas de coordinacin
Las herramientas de coordinacin son utilizadas principalmente por el equipo impulsor para
llevar a cabo la gestin de todas las diferentes reas temticas del proyecto y hacer posible la
interaccin necesaria entre todas las partes.
Una de estas herramientas son los grupos de Google, que actan en unos casos como listas de
distribucin para hacer llegar un mensaje a todos los pioneros y en otros casos como blogs
privados para el equipo de desarrollo o el equipo impulsor. Estos grupos tambin se utilizan para
solicitar la colaboracin de pioneros en tareas relacionadas con la asociacin, como pueda ser la
realizacin del subtitulado de un vdeo promocional, elaboracin de una presentacin, etc.

Figura I.5. Grupos de Google de la asociacin
Otra de las herramientas, una de las que ms est demostrando su utilidad, ya que es de las que
ms actividad genera es Trello. Esta herramienta online facilita la gestin de proyectos de una
manera simple y para cualquier tipo de proyectos (grandes o pequeos). Mediante tableros y
tarjetas, se van planificando tareas que llevar a cabo, tareas canceladas, tareas ya realizadas, etc.

Figura I.6. Tablero "Impulsores - Tareas" en Trello
Para establecer reuniones y poder llevar a cabo una comunicacin en tiempo real, los impulsores
han utilizado primero Skype y luego Google Hangouts. Este ltimo es especialmente interesante, ya
que permite muchos participantes simultneamente e incluso permite a otros usuarios participar
como espectadores, caracterstica que se ha utilizado varias veces en la asociacin. Las reuniones se
planean en los grupos de Google o en Trello y cuando van a tener lugar, se proporciona un enlace
para espectadores por si alguien desea participar de oyente. Ms adelante se hace disponible el
vdeo de la reunin en la red Youtube para que todo el que desee consultar de qu se habl pueda
acceder al recurso.
Para compartir recursos, archivos, documentos y herramientas, se opt por utilizar Dropbox,
servicio de almacenamiento en la nube que permite carpetas compartidas y la sincronizacin
automtica de los contenidos, lo que proporciona una usabilidad muy alta a sus usuarios.
Actualmente se utilizan dos directorios, uno para los impulsores y otro para el equipo de
desarrollo, de manera que cada uno puede acceder a la informacin que le atae de manera sencilla.

Figura I.7. Carpeta compartida en Dropbox para el equipo Impulsor
2.3 Herramientas de trabajo
Herramientas de trabajo son todas aquellas que (sobre todo los impulsores) utilizan para
desempear su funcin, ya sea programar, disear, documentar o coordinar las partes.
A lo largo del proceso se han venido utilizando gran cantidad de herramientas distintas, algunas
de las cuales han seguido en el equipo y otras han sido descartadas por distintos motivos. A
continuacin se detallan algunas de las ms utilizadas y sobre todo aquellas que han tenido ms
relacin con la elaboracin de este proyecto de fin de carrera.
En Junio de 2008 se lanz Balsamiq, una herramienta para la construccin de mockups para la
interfaz de usuario de distintos tipos de aplicaciones (Balsamiq Mockups). Dispone de versiones web,
plugin para Google y versin de escritorio.
Permite crear fcilmente prototipos de pantallas de aplicacin para mviles, aplicaciones web o
aplicaciones de escritorio. Balsamiq Mockups pone a disposicin del usuario gran cantidad de objetos
como ventanas web, botones, mapas y en definitiva todos los elementos presentes en la gran
mayora de interfaces de usuario de aplicaciones en el mercado. Su objetivo es facilitar el diseo de
manera que se permita tener una visin de la aplicacin antes de comenzar el desarrollo,
caracterstica que permite afrontar la codificacin minimizando los riesgos y facilitando
cuantiosamente la especificacin de requisitos y funcionalidades que debe cumplir el producto a
crear.
Adems de todos los elementos que trae la aplicacin de serie, existe una gran comunidad online
con una ingente cantidad de recursos en forma de archivos bmml (formato de la aplicacin), que se
pueden utilizar a su vez en otros wireframes, de manera que si el usuario necesita por ejemplo un
grfico de barras y no se encuentra en la aplicacin, lo puede obtener en alguna de estas
comunidades y utilizar en sus wireframes como si fuera cualquier otro elemento.

Figura I.8. Wireframe de ejemplo creado con Balsamiq Mockups
Para la creacin de CitYsens, se ha utilizado Balsamiq de manera activa, creando distintos
wireframes para distintos casos de uso. Basndose en distintos escenarios en los que un tipo de
usuario concreto utiliza el sistema para extraer una funcionalidad especfica, se disearon distintos
flujos de pantallas con la ayuda de esta aplicacin, ayudndonos as a identificar problemas y
dependencias antes de comenzar la fase de construccin.
Comentada anteriormente en la seccin de Herramientas de Coordinacin, Dropbox fue
utilizada para ir compartiendo los distintos wireframes creados entre el equipo de desarrollo.
Trabajando directamente sobre un directorio compartido mediante Dropbox se consigue disponer de
los ltimos avances hechos por otras personas e ir as evaluando y comentando los trabajos de
manera concurrente, facilitando la coordinacin y, por lo tanto el avance del diseo del sistema.
Como herramientas de control de versiones, se han utilizado en distintos momentos tanto
GitHub, como Bitbucket. Ambas aplicaciones ponen a disposicin de sus usuarios repositorios de
cdigo distribuidos donde ir haciendo commits y hacer tracking de los cambios que se van
produciendo en el cdigo de la aplicacin. Quin hizo qu y cundo es principalmente la informacin
que se obtiene utilizando estos repositorios. Se diferencian de Subversion en que los repositorios son
distribuidos, mientras que Subversion trabaja con repositorios de cdigo centralizados. GitHub
permite crear repositorios de manera gratuita, abrindolos al pblico y permitiendo que solo los
usuarios autorizados realicen modificaciones. Si se desea trabajar con repositorios privados, GitHub
ofrece la posibilidad suscribindose a su modalidad de pago.
Bitbucket por otro lado, permite repositorios gratuitos para hasta cinco desarrolladores de
manera gratuita y da la opcin de aumentar el nmero de desarrolladores mediante distintas tasas
de pago.
Para trabajar con estos repositorios distribuidos, se utiliz la aplicacin SourceTree creada por
Atlassian, que es un cliente para repositorios distribuidos (tanto Git como Mercurial). De manera
sencilla, permite clonar repositorios, detectar cambios de archivos, y realizar commits, pulls y reverts
de los distintos proyectos.

Figura I.9. SourceTree
Como herramientas de edicin de texto para el desarrollo se han utilizado distintos editores,
desde Notepad++, NetBeans y Sublime Text 2. Este ltimo ha sido el ms empleado, dado el amplio
abanico de posibilidades que ofrece y plugins que tiene a disposicin de los usuarios. En una fase
inicial de desarrollo en PHP, Javascript y HTML (documentada ms adelante) se utiliz un plugin para
la sincronizacin de directorios con un servidor remoto de manera que al guardar un documento,
automticamente el editor sube los cambios al servidor permitiendo probar el cdigo de manera
rpida, cmoda y limpia.
Para disponer de un entorno de desarrollo web de una manera rpida y cmoda, se opt por
realizar una instalacin de WAMPServer (Windows Apache MySQL PHP). WAMP integra la
instalacin del servidor web Apache2, servidor de base de datos MySQL e intrprete de PHP de
manera automtica sobre el sistema operativo Windows. De esta manera se ahorra tiempo en
labores de instalacin y configuracin de todas estas herramientas.
3. Iniciacin al desarrollo web
Siendo CitYsens una aplicacin web, su desarrollo implicar la utilizacin de las ltimas
tecnologas de desarrollo web, vase PHP, Javascript, HTML, CSS, AJAX, etc.
Para realizar el diseo de una aplicacin, primero se deben conocer las tecnologas disponibles y
las tcnicas ms comunes para la correcta codificacin de la misma. No se puede disear un sistema
sin tener un mnimo trasfondo de qu se puede y qu no se puede hacer.
Por ello, previa a la fase de diseo se llev a cabo una tarea inicial de familiarizacin con las
tecnologas web que se van a utilizar. Las principales tecnologas involucradas son:
HTML (HyperText Markup Language): Lenguaje de marcado utilizado para la creacin de
pginas web. Mediante etiquetas, se estructura el documento (pgina web) para
conseguir la organizacin de los contenidos de la misma de acuerdo a lo requerido
1
.
CSS (Cascading Style Sheets): Lenguaje para definir hojas de estilo. Se utiliza para crear el
aspecto de una pgina web definida en un lenguaje de marcado (HTML). Permite definir
distintos estilos (fuente de letra, tamao, color, margen, etc) y aplicarlos sobre los
diferentes elementos de la pgina web
2
.
PHP (PHP HyperText Preprocessor): Lenguaje de scripting para servidores, PHP permite
embeber instrucciones PHP en la propia pgina web y utilizar los comandos disponibles
para crear y modificar la pgina web. PHP tambin se utiliza como lenguaje de
programacin de propsito general pero su uso ms extendido es el de procesado en
servidores
3
.
Javascript (JS): Lenguaje de programacin dinmico para scripting en el lado del cliente.
Utilizado en exploradores web para interactuar con el usuario, realizar modificaciones
sobre la pgina web y solicitar datos al servidor. Tambin ha sido utilizado para el
desarrollo de videojuegos, aplicaciones para mviles y aplicaciones de escritorio
4
.
AJAX (Asynchronous Javascript And XML): Conjunto de tcnicas de desarrollo web
utilizadas en el lado del cliente para crear aplicaciones que se comunican de manera
asncrona con el servidor, permitiendo actualizar la pgina web sin tener que recargar la
misma, bsicamente
5
.
3.1 Entorno inicial, conexin a BBDD y operaciones CRUD
Como tarea inicial, se estableci que el punto de partida sera repasar HTML y familiarizarse con
PHP y su sintaxis, as como las caractersticas ms importantes del lenguaje.

1
http://en.wikipedia.org/wiki/HTML
2
http://en.wikipedia.org/wiki/Cascading_Style_Sheets
3
http://en.wikipedia.org/wiki/PHP
4
http://en.wikipedia.org/wiki/JavaScript
5
http://en.wikipedia.org/wiki/Ajax_%28programming%29
Para ello, se siguieron una serie de cursos online ofrecidos por distintas pginas. El primero es el
curso online que ofrece Codecademy en su pgina (Codecademy). Dicho curso es interactivo: Consta
de una leccin donde se introduce el concepto terico y la sintaxis a utilizar, y un rea de cdigo
donde el usuario debe ir completando los ejercicios, de manera que el curso resulta mucho ms
ameno y consigue calar ms en el alumno, al tener ste que teclear las sentencias (familiarizndose
as con la sintaxis y los errores ms comunes).

Figura I.10. Curso de Codecademy para PHP
A continuacin se siguieron unas lecciones ms tericas y completas, pero que ofrecan ms
profundidad en los conceptos. Dicho curso es el ofrecido por W3Schools (W3Schools).
Entre ambos cursos se cubrieron lecciones bsicas como instrucciones de control de flujo,
estructuras de datos, funciones, orientacin a objetos, validacin de formularios, manejo de
archivos, uso de cookies y sesiones PHP, excepciones, conectores a bases de datos, etc.
Una vez conocida la sintaxis y las posibilidades de PHP, se estableci una primera iteracin en la
que aplicar los conocimientos adquiridos a un nivel bsico.
La tarea consisti en:
Crear una tabla con PHPMyAdmin (phpMyAdmin) con dos campos, nombre y email.
Introducir 10 registros (utilizando PHPMyAdmin).
Instalar SFTP en Sublime Text. Dicho plugin permite la sincronizacin con directorios
remotos va FTP.
Vincular un directorio local con un directorio en el servidor para poder trabajar de
manera local y replicar los cambios sobre el servidor.
Crear un script de PHP que lea dicha tabla de la base de datos y muestre los registros
utilizando una lista no ordenada de HTML.
Aadir nuevos registros a la base de datos y comprobar que se listan correctamente
mediante el script PHP.
Para llevar a cabo esta tarea, se dispuso un directorio en el servidor de la asociacin (donde se
aloja la pgina web y otros servicios) y se asoci una URL a dicho directorio para poder acceder a su
contenido a travs de un explorador de internet. Utilizando la URL palvji.citysens.org se acceda al
directorio /home/palvji/phptests de manera automtica.
Utilizando la instalacin de PHPMyAdmin del servidor, se crearon la base de datos y la tabla
requerida en el enunciado y se introdujeron los registros requeridos.
A continuacin, utilizando y configurando el plugin SFTP de Sublime Text, se crearon los archivos
index.html y list.php. La pgina inicial (index.html) incluye un enlace al script PHP (list.php), que es el
que se conecta a la base de datos y carga los usuarios para luego mostrarlos en la lista solicitada.
Mediante esta sincronizacin a travs de Sublime Text y su plugin SFTP se permite editar los
archivos html y php de manera local y al guardarlos, el editor de texto automticamente realiza una
copia de los archivos y la enva al servidor, al directorio previamente configurado. De esta manera,
basta con realizar cambios, guardar y acceder a la pgina en el servidor, que ya contiene las ltimas
modificaciones.
Una vez dispuesta la pgina que muestra la lista de usuarios, cargndola de la base de datos, se
verific que al insertar nuevos registros y refrescar la pgina, dichos registros eran mostrados.
El siguiente paso inclua:
Aadir un botn o enlace al lado de cada registro para eliminar dicha entrada. El
botn/enlace deber llamar por GET al archivo list.php.
Aadir un formulario al principio de list.php para buscar registros por nombre. Este
formulario enviar los valores utilizando el mtodo POST.
Aadir un formulario con dos campos (nombre y email) al final de list.php para insertar
un nuevo usuario utilizando POST.
Las operaciones CRUD son las operaciones bsicas a realizar en cualquier sistema informtico que
trabaja con entidades. Las siglas se corresponden con las operaciones de creacin (create), lectura o
consulta (read), actualizacin (update) y borrado (delete). En esta tarea se pretende aadir las
funcionalidades de creacin, consulta mediante filtro de bsqueda y borrado a la ya existente de
listar los registros. Adems, las operaciones se llevarn a cabo utilizando mtodos GET y POST para
familiarizarnos con el uso de ambos.
Para llevar a cabo estas modificaciones se hizo que list.php al cargar busque si tiene una accin
(delete/insert/search) que llevar a cabo. Si la accin es insertar o borrar, se llevan a cabo los cambios
sobre la base de datos y luego se cargan los registros (incluyendo el cambio realizado previamente).
Si la accin es de bsqueda se utiliza el valor introducido como filtro a la hora de mostrar los
registros, de manera que solo aparecen en el listado los usuarios que cumplen dicho filtro.
El principal objetivo de esta tarea era utilizar ambos mtodos para enviar informacin al servidor
desde formularios HTML, POST y GET para entender las diferencias entre ambos. La principal
diferencia es que utilizando el mtodo GET, los parmetros se envan en la URL, por lo que la
informacin es visible y se puede guardar como enlace vlido. El mtodo POST, por el contrario, no
incluye los valores del formulario en la URL, haciendo que la informacin enviada sea invisible al
usuario y por lo tanto, ms segura la transferencia de datos.
La URL generada utilizando el mtodo GET al eliminar un registro, tiene el aspecto
list.php?action=delete&id=167, donde podemos ver los parmetros que se envan (action y id) y los
valores que tienen asociados (delete y 167).
3.2 Interfaz de usuario
Para las siguientes modificaciones, el objetivo fue mejorar el cdigo para adaptarlo a un modelo
ms orientado al modelo vista controlador, as como mejorar la visualizacin de la lista de usuarios
creando un sistema de pginas.
Para el primer punto, se procedi a separar las funciones de carga y generacin de datos a otro
archivo (loadData.php), de manera que dicho script se encargara de interactuar con la base de datos
(modelo) mientras que el script list.php simplemente muestra los datos (vista) y llama a funciones del
otro script (controlador) en base a las acciones llevadas a cabo por el usuario (insercin, borrado y
bsqueda).
En esta leccin se utiliz la sentencia PHP include para referenciar unos archivos desde otros,
de manera que se pueda hacer una separacin lgica de las funcionalidades, aportando modularidad
y claridad a la aplicacin.
Adaptado el cdigo al modelo vista controlador, se definieron los cambios orientados a la
modularidad del cdigo y a la mejora de la interfaz de usuario:
Crear otro archivo, dbFunctions.php, que incluya todo el cdigo de consultas a la base de
datos y hacer que loadData.php simplemente haga llamadas a funciones de este nuevo
fichero. Dichas funciones debern devolver si se ha realizado bien la accin o no (en
casos de borrado o insercin) o un vector con los datos (en caso de consulta o bsqueda).
Hacer que el listado de los usuarios aparezca en pginas de diez elementos y que se
permita la navegacin por las pginas mediante enlaces a la pgina anterior y a la
siguiente.
Con esta tarea se consigue abstraer la capa de acceso a la base de datos. Esta prctica resulta
especialmente interesante si en algn momento se debe cambiar el motor de base de datos por otro,
ya que se modificara el archivo que contiene todos esos accesos de manera que al resto de la
aplicacin le resulta transparente el tratamiento de los datos y se evitan problemas que surgiran si
hay accesos a la base de datos repartidos por todo el cdigo de la aplicacin.
Mediante la funcin de paginacin, se consiguen seccionar los datos a mostrar y hacer que la
pgina tenga una apariencia con cohesin, independientemente de la cantidad de usuarios que hay
en base de datos. Para la correcta implementacin de dicha funcionalidad, se utilizaron funciones
auxiliares para determinar nmero total de elementos y pgina actual y as poder decidir si se deben
crear enlaces a pginas siguientes o anteriores.
3.3 Servidor local, AJAX y jQuery
Hasta este punto en el progreso de aprendizaje se haba estado trabajando sobre el servidor web
de la asociacin. Mediante SFTP en Sublime Text, se iban haciendo cambios sobre los archivos que
luego eran salvados en el servidor. Comenzando en esta tarea, se opt por trabajar de manera local,
montando para ello un servidor web local y olvidndonos as del servidor de la asociacin.
Utilizando WAMP (Windows Apache MySQL PHP) (WampServer), se realiz la instalacin sobre
una mquina con el sistema operativo Windows del servidor de pginas web Apache, del servidor de
base de datos MySQL y del intrprete de PHP. Realizadas todas las configuraciones pertinentes, se
puede acceder al directorio ofrecido por el servidor y a todo su contenido, permitindonos de esta
manera trabajar sobre los archivos alojados en la propia mquina.
WAMP incluye una serie de extensiones que resultan muy tiles al trabajar con PHP. XDebug
(XDebug) es una de ellas que permite detectar errores en la carga de la pgina como avisos de
variables no inicializadas, etc. Para completar las labores de depuracin y deteccin de errores se
utiliza el complemento de Firefox Firebug (Firebug) que permite distintas operaciones. Algunas de las
ms utilizadas son la posibilidad de mostrar el documento de la pgina web en todo momento,
estructurado en un rbol HTML, mostrar errores, warnings y llamadas de consola, etc.
Una vez trasladado el entorno de desarrollo a la propia mquina local, la siguiente tarea inclua
realizar las siguientes modificaciones:
Aadir un campo en la base de datos, Cdigo Postal, de valor numrico.
Permitir crear registros con y sin cdigo postal.
Permitir la bsqueda de usuarios por cdigo postal.
Para ello, primero se alter la estructura de la tabla en base de datos a travs de la consola de
MySQL (ya estbamos trabajando sobre el entorno local) para aadir el campo CP, al que se le dio
valor por defecto NULL para permitir la insercin de usuarios sin dicho atributo.
Posteriormente se modific el formulario de insercin de usuarios para contemplar la
introduccin de dicho valor.
Por ltimo hubo que crear dos cuadros de bsqueda, uno por nombre (ya existente) y uno nuevo
para buscar por cdigo postal. Esta parte requiri la integracin de todas las posibles combinaciones
de bsqueda a introducir por un usuario (buscar solo por nombre, solo por cdigo postal, por
nombre y cdigo postal o por ninguno de los dos) de manera que siempre se mostraran los
resultados que cumplen todas las restricciones.
Hasta este momento, nuestra pgina de gestin de usuarios era sncrona. Todas las
modificaciones sobre la pgina implicaban tener que recargar la pgina entera. Para evitar esto y
realizar actualizaciones asncronas de la informacin de la pgina se introduce AJAX. La tarea
consista en:
Hacer que en base a lo tecleado por el usuario en el cuadro de bsqueda, se ofrezcan
sugerencias de nombres de usuario que coincidan con el texto introducido.
Realizar las bsquedas de usuarios mediante AJAX, utilizando JSON
1
.
Realizar los borrados de usuarios utilizando AJAX, y que se actualice el listado de manera
automtica una vez eliminado un elemento.
Para utilizar AJAX, el primer paso es manejar Javascript. Utilizando este lenguaje de scripting en el
lado del cliente, se declara una funcin que se encarga de la comunicacin entre el cliente y el
servidor. Dicha funcin ser llamada cuando se d el evento onKeyUp sobre el cuadro de bsqueda
por nombre de usuario. La funcin enva al servidor la informacin introducida y cuando recibe una
respuesta, la procesa de la manera pertinente. El flujo es el siguiente:
1. En el cdigo HTML de la pgina, se aade la llamada a la funcin (Javascript) showHint
cuando se d el evento de soltar una tecla pulsada sobre el cuadro de texto donde se
teclea el nombre. Es decir, el usuario coloca el cursor sobre el recuadro y aprieta la tecla
a, por ejemplo. Cuando el usuario suelta esa tecla, se llama a la funcin showHint con
los caracteres escritos en ese momento en el cuadro de texto (en este caso a).
2. La funcin showHint crea un objeto del tipo XMLHttpRequest mediante el que realiza la
peticin al servidor. Para ello, se especifica a qu archivo del servidor se debe enviar la
peticin y los parmetros de la misma y luego se enva. En este ejemplo, la peticin se
hace utilizando el mtodo GET y se enva al archivo getHint.php. Los parmetros se
aaden tras el nombre del archivo en la URL. En este caso se enva la cadena tecleada por
el usuario como parmetro con nombre q.
3. Lo primero que se hace en el archivo getHint.php es cargar todos los usuarios de base
de datos (utilizando las funciones creadas para ello en dbFunctions.php). Una vez
cargados, se obtiene el parmetro de la URL en el que viene la cadena tecleada por el
usuario (q) y se recorren todos los usuarios buscando coincidencias. La salida del
archivo es una cadena de texto donde se incluyen todos los usuarios que coinciden con lo
tecleado o la cadena No hay sugerencias si el nombre de ningn usuario comienza con
la letra a (en este ejemplo).
4. Volviendo a la funcin showHint, se debe crear una funcin a ejecutar cuando se reciba
respuesta por parte del servidor. En esa funcin ser donde se trate la respuesta del
servidor a la peticin, en este caso la respuesta es una cadena de texto. La funcin busca
en el documento de la pgina el div donde colocar las sugerencias y muestra ah la
respuesta del servidor.
5. Para eliminar las sugerencias cuando el cuadro de texto queda vaco, en la funcin
showHint se contempla que si la longitud de la cadena tecleada es cero (cadena vaca),
se eliminan las sugerencias y no se enva peticin al servidor.

1
http://en.wikipedia.org/wiki/JSON
Una vez realizada la parte inicial (sugerencias en base al nombre de usuario), el borrado y listado
de usuarios es ms o menos similar. Se debe primero definir cundo se debe llamar a la funcin, es
decir, qu accin del usuario es la que provoca la llamada. En la funcin se elabora la peticin y se
lleva a cabo el tratamiento de la respuesta. Por ltimo se debe crear el archivo del servidor que se
encarga de procesar la peticin y elaborar la respuesta pertinente.
En el caso de bsqueda, el servidor no devuelve una cadena de texto, sino que devuelve un
conjunto de usuarios. Para ello, el servidor codifica la respuesta (vector de usuarios ms el nmero
total de usuarios) con formato JSON y en el procesado de la respuesta, el cliente decodifica el objeto
JSON mediante las instrucciones Javascript que permiten extraer objetos y vectores de la misma.
Durante este proceso, result especialmente til el uso de Firebug, al mostrar por consola las
peticiones enviadas y recibidas, parmetros de la misma, datos en JSON y en HTML, etc.

Figura I.11. Firebug en accin, mostrando peticiones entre cliente y servidor
En la imagen se pueden apreciar las distintas peticiones de consulta y de borrado enviadas al
servidor utilizando AJAX, gracias a Firebug.
jQuery
1
es una librera que envuelve Javascript de manera que pone a disposicin del usuario
una sintaxis ms compacta y rpida de utilizar. Facilita enormemente tareas como la manipulacin
del documento HTML, manejo de eventos, transiciones y peticiones AJAX.
La ltima tarea tena como objetivo incluir jQuery y utilizar el efecto de fadeOut sobre un usuario
al borrarlo.
Para familiarizarse con la sintaxis y las caractersticas ofrecidas, se sigui una leccin de jQuery
disponible en W3Schools. Tras ello, se sustituyeron instrucciones tan largas como puedan ser los
getElementById de Javascript por instrucciones jQuery mucho ms cortas, como $(#id#),
haciendo el cdigo ms manejable y legible.
Por ltimo, se aadi el efecto fadeOut sobre toda la fila de un usuario, en el momento en que se
hace clic sobre el botn para eliminar el mismo. Con un efecto tan simple como este y tan sencillo de
usar gracias a jQuery, se consigue mejorar enormemente el aspecto de la aplicacin.
3.4 Conclusiones
Todas las tareas llevadas a cabo en este proceso de iniciacin al desarrollo web tenan un
objetivo claro y conciso. Se puede observar el carcter incremental de las lecciones y cmo se va
construyendo cada leccin en base a algo nuevo y a lo aprendido en las lecciones anteriores, de
manera que cada paso es necesario e importante en el camino hacia el fin.
Gracias a estas tareas de formacin se consiguen unos conocimientos bsicos pero ms robustos
que si nos hubiramos limitado a hacer una lectura de la sintaxis de cada lenguaje. Es con estos
conocimientos con los que se puede abordar un proceso de anlisis y diseo del sistema en sus
primeras versiones.
Las tareas en s y el producto obtenido (la pgina para la gestin de usuarios) no son lo
importante, sino el proceso de aprendizaje y los conocimientos obtenidos a lo largo del mismo, que
permitirn afrontar el diseo tcnico y la construccin de CitYsens de una manera efectiva y
conociendo la tecnologa a utilizar, as como las posibilidades que sta ofrece.

1
http://en.wikipedia.org/wiki/JQuery

Figura I.12. Pgina creada durante el aprendizaje
Captulo II. Anlisis y diseo
Introducidas la forma de trabajo, las herramientas a utilizar y las tareas previas de estudio y
familiarizacin con las tecnologas web, procedemos detallar las fases de anlisis y diseo llevadas a
cabo para la construccin de CitYsens.
En la fase de anlisis se pretende unificar por un lado los requisitos ya establecidos que debe
cubrir CitYsens con las funcionalidades que proporciona la Agenda del Henares. Llevando a cabo un
anlisis exhaustivo de las caractersticas de la Agenda, su modo de funcionamiento y los flujos que
siguen los distintos procesos que implementa, se pretenden extraer buenas ideas y extrapolar
aquello que se pueda aplicar al sistema CitYsens. La Agenda del Henares fue instaurada, aparte de
para proporcionar el beneficio social que aporta, para ir captando potenciales usuarios de CitYsens,
para estudiar qu uso hace la gente de la misma y, en definitiva, para mejorar todo aquello que sea
posible y hacer de CitYsens la mejor herramienta en lo que a participacin ciudadana se refiere.
1. La Agenda del Henares
AgendaDelHenares.org es una agenda compartida que informa de los eventos y convocatorias
cvico-polticos en los municipios del valle del Henares. El objetivo de esta agenda es doble:
1. Disponer de un sitio de referencia donde se puedan consultar y difundir las actividades y
convocatorias del valle del Henares.
2. Crear una herramienta de coordinacin para la ciudadana y para las propias
asociaciones, colectivos ciudadanos y movimientos sociales del valle del Henares.
As responde la Agenda del Henares a la pregunta Qu es la Agenda del Henares? en su pgina
web (Quines somos?, 2013).
1.1 Qu es la Agenda del Henares
La Agenda del Henares es una agenda colaborativa. Es una agenda orientada al mbito local que
se construye de la mano de todos los ciudadanos y participantes. Para la Agenda del Henares, se
utiliza un software, Demosphere, creado en Francia y que tras varios aos desde su creacin se
empieza a utilizar y extender a distintos lugares.

Figura II.1. Sitio web de Demosphere, mostrando los lugares donde se utiliza
Demosphere es un software gratuito y de cdigo abierto para sitios web de calendarios de
eventos. El software incluye tanto un frontend (interfaz visible al usuario) como un backend que
proporciona a los administradores la capacidad de bsqueda y de introduccin de eventos.
Demosphere acta como una herramienta para mejorar la productividad a la hora de gestionar un
nmero grande de eventos que proceden de distintas fuentes. Algunas de las caractersticas ms
importantes que ofrece son:
Frontend: Incluye una vista de calendario, un mapa interactivo de eventos, distintos
widgets configurables para mostrar calendarios en otras pginas web, suscripcin a RSS,
suscripciones por email configurables, seleccin personalizada de eventos, formularios
de eventos sencillos y directos, etc.
Backend: Incluye un lector de email para encontrar eventos duplicados en listas de
correo muy voluminosas, un gestor de fuentes que ayuda a buscar eventos y duplicados
entre artculos publicados en otras webs, un componente de vigilancia que permite
recibir avisos cuando se modifica una pgina web, una extensin de Firefox que permite
resaltar fechas futuras y palabras clave en otras pginas web para facilitar la creacin de
eventos copiando y pegando informacin y varias otras herramientas para mejorar el
flujo de trabajo cuando se pretende gestionar gran cantidad de eventos.
La Agenda del Henares muestra eventos de carcter cvico-poltico agrupados en base al da en
que suceden. Los eventos estn geolocalizados, de manera que permiten consultar la situacin
exacta donde va a tener lugar un evento concreto. Para impulsar la viralidad la pgina se ha
vinculado con perfiles en Facebook y Twitter y permite difundir eventos a travs de cualquiera de
dichas redes sociales.
La pgina principal tiene distintas secciones:
1. rea central donde se van incluyendo tarjetas, una para cada da de manera que cada
una contiene los eventos que tienen lugar en dicha fecha. Esta rea sufre las
modificaciones aplicadas por los distintos filtros de bsqueda y muestra la informacin
pertinente.

Figura II.2. Lista de eventos de la Agenda del Henares

2. Filtros de bsqueda en base a categoras predefinidas. A cada evento se le asocian
durante el proceso de creacin unas categoras que pretenden describir los mbitos con
los que se corresponde. Mediante este widget se permite iluminar los eventos de una
categora concreta, facilitando la lectura de un usuario interesado en alguna temtica.

Figura II.3. Eventos resaltados utilizando el filtro de categora
3. Se pueden aplicar otros filtros como el municipio en el que tiene lugar el evento. Si el
usuario hace clic sobre el cuadro de opciones, aparecen una serie de filtros adicionales
que tiene a su disposicin.

Figura II.4. Filtros de bsqueda avanzados
4. Cuadro de bsqueda que permite introducir un texto cualquiera de mano del usuario y
mostrar los eventos que coinciden total o parcialmente con el trmino de bsqueda. Esta
opcin lleva a la pgina de bsqueda, abandonando as el rea central de la Agenda.

Figura II.5. Resultados de una bsqueda
5. Calendarios para acceder con rapidez a fechas concretas. Si el usuario hace clic sobre un
da que se muestra en el rea central, la pgina hace scroll hasta dicha entrada, haciendo
la lectura y bsqueda mucho ms rpida y accesible. Si el da es antiguo o no aparece en
el rea central, la Agenda muestra el mes anterior, de manera que adems de ver qu va
a suceder, el usuario puede consultar qu aconteci en fechas anteriores.

Figura II.6. Herramienta calendario
6. Opcin a suscribirse para recibir la agenda por correo electrnico. El usuario puede
introducir su direccin de correo, lo que le llevar a la pgina de edicin del perfil y le
permitir configurar distintas caractersticas de la subscripcin.

Figura II.7. Pgina para configurar la suscripcin
7. La Agenda ofrece al usuario distintas opciones de participacin dando sugerencias sobre
cmo difundir la pgina (hablar sobre ella, crear enlaces en tus pginas webs, incorporar
la agenda en otros sitios web, dar a conocer la agenda en redes sociales, imprimir
carteles y flyers, etc.), adems de dar opciones de contacto y enlaces directos para seguir
a la Agenda del Henares en Twitter o Facebook.

Figura II.8. Formas de participacin en la Agenda
8. La opcin Propn un evento permite a cualquier usuario intentar dar de alta un nuevo
evento.

Figura II.9. Formulario para un nuevo evento de la Agenda
Todo evento debe ser comprobado para cumplir una serie de caractersticas especficas y
poder ser aprobado.

Figura II.10. Criterios de publicacin de la Agenda del Henares
1.2 Casos generales de uso
El funcionamiento de la Agenda se puede describir en cinco casos de uso principalmente:
1.2.1 Consulta
En este escenario, el usuario accede a la Agenda del Henares para informarse de los eventos, sin
tener mayor vinculacin con el sistema. Simplemente accede a agendadelhenares.org y tiene
disponibles los distintos eventos, agrupados por da, que estn registrados en el sistema.
Si el usuario hace clic sobre uno de los eventos, accede a la pgina de dicho evento, que consta
de distintas secciones:

Figura II.11. Pgina de un evento
Temas. Muestra las temticas asociadas a este evento. El usuario puede hacer clic en
cualquiera de las temticas, lo cual le llevar directamente a ver todos los eventos con
dicha etiqueta asociada.
Organizador. Se muestra el organizador del evento. Si existe en el sistema como entidad,
se puede clicar para actuar como filtro de bsqueda y ver todos los eventos relacionados
con dicho organizador.
Dnde. El usuario dispone de un mapa donde ver la direccin del evento. La Agenda del
Henares permite hacer clic sobre la palabra Dnde y sobre la direccin para acceder a
la pgina del lugar. En dicha pgina se muestran eventos pasados y futuros que tuvieron
y tendrn lugar en esa localizacin.
Municipio. El evento se asocia con un municipio, el cual tambin sirve como enlace a una
pgina de bsqueda en la que se utiliza dicho municipio como filtro y se listan todos los
eventos asociados con el mismo.
Mapa. Si el usuario hace clic sobre el mapa se le redirige a Google Maps, donde se
muestra la direccin sobre el mapa completo.
Comentar. Los eventos tienen una seccin de comentarios donde cualquier usuario
(incluso annimo) puede participar y hacer preguntas o manifestar una opinin. Al igual
que los eventos, los comentarios son revisados para evitar faltas de respeto o contenidos
no tolerables en la Agenda.

Figura II.12. Formulario para un nuevo comentario
Enviar. La Agenda dispone de un sistema para enviar eventos por correo de manera
rpida. Si el usuario hace clic, ser llevado a la siguiente pgina:

Figura II.13. Formulario para enviar un evento por correo electrnico
Desde esta pgina puede enviar el evento utilizando una plantilla de correo electrnico
que puede personalizar con nombre y mensaje.
iCal. La Agenda permite descargar un archivo con extensin ics, que corresponde a un
formato para el intercambio de informacin de calendarios.
Compartir. Desde esta opcin, el usuario puede acceder a su cuenta de Facebook o de
Twitter para compartir en dicha red social la informacin del evento. Demosphere opta
por una verificacin en dos pasos, de manera que los usuarios deben iniciar sesin en la
red social para poder publicar el evento. Esto permite mantener la privacidad y evitar
que Facebook o Twitter tengan acceso a informacin de las pginas visitadas por los
usuarios, como podran hacer si se hubiera incluido un botn de like o tweet que
directamente se conectara con la pgina en cuestin. Por otro lado, esta tediosidad en
el proceso provoca que prcticamente ningn usuario de la Agenda est utilizando la
funcionalidad. CitYsens aspira a crear toda la viralidad posible para aumentar la
visibilidad del sistema.

Figura II.14. Controles para compartir el evento en Facebook o Twitter
Si el usuario desea buscar un evento concreto o consultar eventos que cumplan cierto criterio,
dispone de un cuadro de opciones. Se le permite buscar a travs de una palabra clave o texto que el
usuario introduzca en el cuadro de bsqueda o bien filtrar utilizando alguno de los filtros disponibles.

Figura II.15. Controles de bsqueda de la pgina principal
Si el usuario introduce un texto, se le redirecciona a una pgina de bsqueda donde aparecen
todos los eventos que contienen el/los trmino/s utilizado/s.

Figura II.16. Pgina con los resultados de bsqueda
Si por el contrario, el usuario utiliza el botn opciones, se despliega una nueva seccin en la
pgina que contiene todas las opciones de filtrado a su disposicin.

Figura II.17. Opciones de bsqueda avanzada
Las opciones ms sencillas permiten filtrar por:
Temtica. Eventos asociados con una etiqueta concreta.
Municipio/Barrio. Eventos que acontecen en un municipio concreto.
Lugar. Eventos que tienen lugar en una localizacin concreta. Se listan todos los lugares
que existen en el sistema en ese momento.
Eventos ms visitados. Permite seleccionar el nmero de eventos a mostrar, ordenados
por nmero de visitas. Permite elegir desde los cinco ms visitados hasta los ciento
sesenta ms visitados.
Nmero mximo de eventos al da. Limita la cantidad de eventos que se muestran por
da, seleccionando los ms visitados de cada da.
New events since. Los eventos creados o modificados en un intervalo de tiempo. Permite
desde hace seis horas hasta hace treinta das.
Cambios recientes en primero. Ordena todos los eventos colocando primero los ms
recientemente creados o modificados.
Elegir eventos cerca de un lugar, seleccionando ese lugar en un mapa. Este control
habilita el mapa que se encuentra a la derecha y las opciones inmediatamente debajo:

Figura II.18. Control para filtrar eventos mediante una circunferencia en el mapa
El usuario puede entonces modificar los valores de latitud y longitud para centrar el
marcador en una posicin del mapa concreta. Tambin puede hacerse arrastrando con el
ratn dicho marcador hasta la localizacin deseada. A continuacin se elige el radio de la
circunferencia, medido en kilmetros, utilizando el control de distancia.

Ms opciones. Este enlace, despliega un nuevo conjunto de opciones de filtrado
disponibles para el usuario:
o Nombre de la regin. Demosphere permite crear una regin utilizando un archivo
KML o un archivo de texto plano con las coordenadas de un polgono que defina
una regin a monitorizar.
o Trmino. Palabra clave para buscar.
o Lista de trminos. Buscar por varias palabras.
o Nmero mximo de eventos a mostrar.

Enlace directo. Haciendo clic en este enlace, el usuario es dirigido a una pgina en la que
se muestran los eventos que cumplen los distintos criterios aplicados. En esta nueva
pgina, los parmetros de bsqueda se encuentran en la URL, de manera que el usuario
puede guardar un enlace con sus criterios preferidos y utilizarlo para consultar los
eventos que le interesan de manera automtica.

Figura II.19. Eventos mostrados a travs de un enlace directo con criterios de bsqueda
Se puede observar que se han buscados eventos con la temtica Educacin, en el municipio
Alcal de Henares y que se muestren nicamente los diez eventos ms visitados. En la URL
aparecen los parmetros Topic, selectCityId y mostVisited, de manera que dicho enlace
ser siempre vlido al contener los parmetros de bsqueda en la propia direccin.

El caso de uso de consulta es el escenario ms sencillo y que ofrece la funcionalidad ms bsica
de informar al usuario (un usuario no registrado en el sistema, i.e. cualquier usuario) en cuanto a los
eventos que tienen lugar en su entorno.
1.2.2 Suscripcin
Sucede que si un usuario pretende mantenerse informado, debe estar recordando visitar la
pgina con cierta frecuencia para consultar la informacin al respecto de los eventos. Por ello, en
este escenario un usuario pretende sacar provecho de la suscripcin, introduciendo su direccin de
correo electrnico y configurando la frecuencia con la que se reciben los correos y otras opciones de
la subscripcin.
De esta manera, el usuario recibe un correo con la lista de eventos y das en los que suceden, y
puede hacer clic en cualquiera que sea de su inters para ir a la pgina de la agenda y consultar sus
detalles, sin tener que estar acordndose de visitar la pgina de la agenda regularmente.
1.2.3 Colaboracin
El siguiente caso de uso involucra una participacin ms activa, en la que un usuario desea dar de
alta un evento sobre el que ha odo hablar o del que forma parte de una manera directa.
Para llevar a cabo dicha accin, el usuario pulsa el botn Propn un evento y accede al
formulario a rellenar para el evento en cuestin.
El usuario debe rellenar cierta informacin bsica (tema, lugar, fecha, hora, ttulo, descripcin) y
otra informacin con carcter ms opcional (correo de contacto, pginas web donde aparece dicho
evento, mensaje para los moderadores de la agenda, etc.).
Una vez rellenada la informacin, el evento se enva y los moderadores deben aprobar, modificar
o rechazar el evento en base a los criterios de la Agenda del Henares. Dichos criterios dicen que
todos los eventos (Criterios de Publicacin, 2013):
Deben tener una intencin cvico-poltica, entendida en sentido amplio como una
preocupacin por el bien comn y por el bienestar general, as como la reflexin sobre
las acciones que entre todos, como individuos y como sociedad, debemos realizar para
promover ambos.
Estar alineados con las nociones de progreso social y de desarrollo incluyente de nuestra
sociedad.
Ser participativos, con una actitud inclusiva y respetuosa, permitiendo a todos expresar
sus opiniones.
No promover ninguna forma de discriminacin (por motivos de raza, etnia, nacionalidad,
clase, religin o creencias, sexo, orientacin sexual, identidad de gnero, edad, estado de
salud, opinin poltica o de otra ndole, o cualquier otra condicin).
Estar abiertos a todas las personas sin discriminacin (por ejemplo, si hubiese de pagarse
una entrada, su precio debe siempre ser razonable para no excluir a personas con bajos
ingresos).
Desarrollarse en los municipios del valle del Henares o tener que ver especialmente con
esta regin.
Estos requisitos se establecieron para no hacer de la Agenda del Henares una agenda cultural ni
una agencia institucional, del ayuntamiento. Para ello se deben validar los nuevos eventos, tarea que
supone una de las partes ms tediosas del trabajo de los administradores del sistema.
1.2.4 Implicacin
El ltimo escenario describe una asociacin o colectivo que se compromete con el proyecto de la
Agenda y pasa a tener capacidad de publicacin directa y edicin de sus eventos sin tener que
mediar los administradores en el proceso.
En cualquier momento se pueden conceder permisos totales o aumentar el nivel de privilegios de
determinadas cuentas para permitir este tipo de implicaciones, que hacen de la agenda un sistema
abierto y colaborativo en el que todo el mundo tiene cabida.
Para gestionar esta implicacin de asociaciones y colectivos existe un grupo de Google Agenda
del Henares Coordinacin en el que los distintos implicados discuten sobre los eventos a publicar,
los criterios que deben seguir los eventos, difunden informaciones relacionadas y resuelven todo tipo
de cuestiones.

Figura II.20. Grupo de Google para la coordinacin de la Agenda del Henares
De esta manera, la aprobacin de los eventos se dinamiza y se hace de forma colaborativa,
permitiendo que la Agenda del Henares sea realmente por y para todos.
1.2.5 Gestin
La gestin del sistema se hace tanto a nivel tcnico como a nivel de contenido. Los
administradores gestionan, mantienen y configuran los aspectos ms tcnicos del sistema. Tambin
actan como usuarios implicados, participando activamente en el grupo de Google resolviendo
conflictos y manifestando opiniones.
La principal diferencia entre los administradores de la Agenda del Henares y el colectivo de
implicados es que los primeros tienen total acceso al sistema, tal y como lo provee Demosphere
mientras que el segundo grupo tiene capacidad de publicacin directa y de aprobacin de eventos,
sin disponer de ese grado ms tcnico que poseen los administradores.
1.3 Anlisis de funcionalidades
La Agenda del Henares fue instaurada en un primer momento con el objetivo de despertar
inters en la poblacin por las tecnologas web aplicadas al beneficio social y a la participacin
ciudadana, adems de para servir al valle del Henares y a sus movimientos sociales e instituciones.
A partir de la agenda, la asociacin puede extraer patrones de uso, funcionalidades interesantes,
funcionalidades prescindibles y en definitiva una primera aproximacin al qu se necesita para
poder enfocar correctamente el diseo y la codificacin de CitYsens.
Adems de proporcionar toda esta informacin, la agenda tambin sirve para ir recaudando
usuarios que ms adelante sern probablemente usuarios del sistema final CitYsens y que, al haber
participado en la Agenda del Henares, pueden dar un feedback ms exhaustivo y riguroso que
conduzca a un diseo ms pulido y refinado.
Para extraer todas estas caractersticas, tanto buenas como malas, y tener claras las necesidades
a cubrir por CitYsens, se lleva a cabo el siguiente estudio del funcionamiento de la Agenda. Se
pretende entender e identificar lo mejor, aquello que merece la pena mantener como
funcionalidades de CitYsens. El anlisis cubrir todos los pasos en los distintos flujos de interaccin
con la agenda para extrapolar mtodos efectivos y otros mejorables a utilizar en CitYsens. No se trata
de copiar, sino de basarse y mejorar algo ya existente. Como aadido, el estudio sirve para identificar
pequeos errores o bugs a tener en cuenta y no cometer durante la implementacin final del
sistema.
Atendiendo a los casos de uso expuestos anteriormente, existen tres flujos principales que lleva a
cabo el sistema que resultan especialmente interesantes en su interaccin con el usuario:
Registro/subscripcin de un usuario, alta y validacin de un nuevo evento y administracin de
eventos.
1.3.1 Registro y subscripcin de un usuario
La funcin de registro permite a un usuario recibir de manera automtica (va correo electrnico)
las noticias sobre eventos de la Agenda del Henares. En la pgina principal de la Agenda se muestra
lo siguiente:

Figura II.21. Control para iniciar la suscripcin desde la pgina principal
Desde el punto de vista del diseo de la interfaz del usuario, el poner a disposicin del usuario la
opcin de registro desde el primer momento y de una manera tan sencilla (sin formularios
complicados, enlaces a otras pginas, etc.) es un gran acierto, ya que todos los usuarios tendrn la
opcin en primer plano, y muchos lo probarn aunque slo sea porque el nico requisito es escribir
la direccin de correo electrnico.
El hacer tan sencillo el formulario, provoca a muchos usuarios a utilizarlo por lo simple que
parece. Es una opcin que facilita el servicio ofrecido al usuario (informacin) y de una manera
rpida, limpia y configurable.
1.3.1.1 Validacin de la direccin de correo
La Agenda realiza una comprobacin/validacin de la direccin introducida por el usuario, de
manera que si la direccin no es vlida, se resalta el recuadro en color rojo para avisar al usuario de
que no fue aceptada la direccin. Como mtodo de aviso resulta un poco desconcertante, ya que la
pgina sufre un cambio discreto (recuadro rojo), pero no se produce ningn aviso ni alerta al usuario
que de manera explcita detalle el problema.
La Agenda toma por direcciones vlidas aquellas con formato name@domain.xxx" donde
domain.xxx exista y responda a una conexin SMTP (Simple Mail Transfer Protocol). Sucede que la
Agenda no verifica si el usuario concreto existe en dicho dominio de correo electrnico, por lo que
permite registrar direcciones falsas siempre y cuando el dominio exista.
Existen distintos servicios online para la verificacin/validacin de direcciones de correo, que
permiten incluso la verificacin en grupo de un conjunto de direcciones. Muchas se ofrecen como
servicio a otras empresas. Algunas detectan correctamente si el usuario existe o no, mientras que
otras slo aportan informacin sobre el dominio. Por ello, parece que sera sencillo reforzar esta
validacin del email para discernir qu cuentas de correo se dan por vlidas y cules no.
1.3.1.2 Creacin de un usuario
Una vez introducida una direccin de correo validada, el usuario es llevado a una pgina donde
configurar su subscripcin, donde puede seleccionar distintas caractersticas de la misma:
Recibir eventos por correo (s/no).
Frecuencia de los correos. Desde todos los das hasta cada dos semanas.
Hora de envo de los correos.
Cundo empiezan los eventos enviados (Principio del da del correo, momento en que se
enva el correo o da siguiente al envo del correo).
Cuntos das de eventos se reciben en cada correo. Todos los das o desde un da hasta
treinta das de eventos.
Recibir nicamente eventos nuevos o modificados recientemente (esta opcin anula la
anterior). Permite seleccionar eventos nuevos desde el ltimo correo, desde hace seis
horas, o desde hace un da hasta desde hace treinta.
Recibir un correo extra para eventos urgentes.

Figura II.22. Configuraciones para la frecuencia de correos de la suscripcin
Temtica de los eventos a recibir (todas o alguna en concreto).
Municipio/Barrio sobre el que recibir los eventos. Todos, uno concreto o municipios no
definidos.
Seleccionar los eventos cercanos a un rea geogrfica. Permite configurar un punto
geogrfico sobre un mapa y un radio de distancia que ser utilizado para recibir eventos
dentro de dicha rea. Funciona igual que el filtro de bsqueda equivalente. Al activar la
opcin, se permite definir un punto geogrfico y un radio en kilmetros que defina la
circunferencia del rea a monitorizar.

Figura II.23. Configuraciones para los tipos de eventos de la suscripcin
Crear una regin utilizando un archivo KMS.
Nmero mximo de eventos por a mostrar por da. Permite seleccionar desde uno hasta
diecinueve eventos por da. Sern los ms visitados de cada da.
Mostrar los N eventos ms visitados. Se mostrarn tantos eventos como la cifra
seleccionada, independientemente del da en que acontecen.
Recibir eventos que contengan un trmino de bsqueda.
Asunto del correo que se recibe.

Figura II.24. Ms opciones para la configuracin de la suscripcin
Una vez realizada la configuracin, el usuario puede guardarla e incluso enviar un correo de
prueba, para comprobar que est satisfecho con el formato especificado y la configuracin de la
suscripcin o modificarla en caso contrario.
Guardada la configuracin, el usuario recibe un correo donde se pone a su disposicin un enlace
donde configurar su perfil. Dicho enlace funcionar nicamente en las 48 horas siguientes a la
recepcin del correo y tan slo una vez. Si el usuario no lo utiliza a tiempo (no configura su perfil),
puede acceder a la Agenda del Henares utilizando la opcin Olvid mi contrasea, cuyo enlace
tambin se incluye en este primer correo electrnico recibido.
Tambin incluye una seccin final donde indica que para reportar un uso abusivo de este servicio
de envo de correos, el usuario se puede poner en contacto con la Agenda del Henares utilizando
contacto@agendadelhenares.org como direccin de contacto.
1.3.1.3 Edicin del perfil de usuario y agenda personalizada
En cualquier caso, el usuario no necesita utilizar el correo mencionado anteriormente, ya que en
la propia pgina de configuracin de la suscripcin, existe un enlace a otra pgina donde le es posible
modificar su perfil. Dicha pgina, le permite personalizar su nombre de usuario (necesario para iniciar
sesin), contrasea y direccin de correo electrnico.
En este punto, la Agenda no verifica la direccin de correo electrnico ms all de la sintaxis de la
misma (debe tener el formato x@x), de manera que se pueden registrar usuarios con direcciones
de correo falsas o inexistentes.
Adems de poder editar el perfil y las caractersticas de la suscripcin, el usuario dispone de otras
caractersticas de configuracin. Por un lado, dispone de una seccin para configurar un widget que
muestre la Agenda (o la porcin configurada de la misma) en otro sitio web.

Figura II.25. Configuracin del widget de la Agenda para otras pginas web
Esta opcin pone a disposicin del usuario cdigo HTML para que lo utilice en otra pgina web. El
usuario dispone de opciones de configuracin que alteran automticamente el cdigo, de manera
que puede elegir configuracin de colores, tamaos, fuentes y que estas se vean reflejadas en el
cdigo HTML generado automticamente, as como multitud de opciones sobre eventos,
agrupaciones de los mismos, etc.

Figura II.26. Opciones de presentacin del widget
En el momento de redaccin de este documento, dicha opcin de embeber la Agenda en otras
pginas web no ha tenido mayor uso ni repercusin; la funcionalidad ha pasado inadvertida.
Otra funcionalidad que tampoco ha sido utilizada es la de crear una vista personalizada de la
Agenda del Henares y hacerla pblica. La Agenda permite configurar qu muestra la agenda del
usuario X y le facilita un enlace pblico para que otra gente pueda ver una instancia de la Agenda
del Henares, personalizada por dicho usuario X.

Figura II.27. Configuracin de la agenda personal
Los criterios para elegir qu eventos se mostrarn son los mismos que a la hora de la suscripcin
a la Agenda del Henares. El usuario que personaliza la agenda tiene a su disposicin los filtros de
bsqueda detallados anteriormente (tema, municipio, rea en un mapa, etc.), as como otras
opciones para configurar el aspecto de la agenda (nmero de eventos por das, slo los N eventos
ms visitados, etc.) tambin descritas previamente. Tambin puede seleccionar eventos a mostrar de
manera individual, marcando qu eventos concretos quiere incluir en su agenda.
El usuario recibe un enlace pblico que puede difundir para que otros usuarios (registrados o
annimos) puedan acceder a su instancia de la agenda, con los filtros configurados ya aplicados de
manera automtica.

Figura II.28. Ejemplo de agenda personalizada
Aunque podra tener cierta utilidad esta funcionalidad, lo cierto es que no resulta demasiado til
al usuario que busca informarse, y eso queda demostrado en el uso que hacen los usuarios de la
Agenda del Henares.
1.3.1.4 Conclusiones
La Agenda del Henares comparte muchas funcionalidades con las que desea cubrir CitYsens, por
lo que en el rea de registro de usuarios encontramos varias funcionalidades a mantener. Siempre se
deben salvar las distancias y no duplicar el comportamiento, pero s basarnos en algo que funciona y
pulir los aspectos ms speros del mismo, adaptndolos a lo que se pretende conseguir con CitYsens.
La funcin de registro es una que se debe mantener, ya que impulsa al usuario a seguir utilizando
el sistema y evita que este abandone la aplicacin por tener que estar recordando acceder a la
misma una y otra vez. La funcionalidad ampla y mejora la utilidad que los usuarios desean extraer
del sistema, por lo que es requisito imprescindible.
El situar en la propia pgina principal la opcin de suscripcin del usuario es la mejor forma de
hacer el acceso sencillo y rpido. Si el paso inicial nicamente requiere de una direccin de correo
electrnico, el usuario no se ver abrumado con una infinidad de campos a rellenar y conseguiremos
que ms usuarios realicen el registro en su totalidad, por lo que la sencillez del acceso es tambin un
requisito deseable.
La forma en que se validan las direcciones de correo electrnico para realizar el registro (tanto al
principio del proceso como en la modificacin del perfil) se debera mejorar. No se debera permitir
tener usuarios que utilizan cuentas de correo no existentes, ya que es la nica forma de contacto que
se tiene de los usuarios. Como se mencion anteriormente, existen pginas que validan direcciones y
llegan a saber si el usuario existe en ese dominio, por lo que se debera llegar hasta ese nivel para
exigir siempre direcciones de correo existentes.
El usuario siempre podr introducir una cuenta que no sea suya, pero eso se puede controlar
enviando un correo de confirmacin como hace la Agenda del Henares. El uso de un correo inicial
informando al usuario de las opciones que dispone y con enlaces directos a distintas funcionalidades
es un acierto que sirve tanto al usuario (para ir conociendo el sistema y sus posibilidades) como al
sistema (para confirmar que el usuario se corresponde con la direccin de correo), por lo que debera
mantenerse en CitYsens.
La Agenda permite al usuario configurar gran cantidad de opciones de la suscripcin desde el
primer momento. Tanto el nmero de opciones a configurar como el momento en que se le plantean
al usuario suponen un arma de doble filo; por un lado, cuantas ms opciones de configuracin tenga
el usuario mejor, ya que podr adaptar el sistema a sus necesidades de una manera ms exhaustiva.
Pero por el otro lado, si un usuario tiene que rellenar o seleccionar demasiadas opciones la primera
vez que est usando el sistema se puede ver abrumado e incluso abandonar el registro. La pantalla a
la que accede un usuario cuando decide llevar a cabo el registro por primera vez es crtica e influye
directamente en la cantidad de usuarios que acabarn utilizando el sistema.
Con CitYsens se pretende tener presente siempre un componente de gamificacin
1
que incite al
usuario a seguir adelante con el sistema, que le vaya capturando. De manera similar a lo que hace
Facebook, el registro debera irse completando a lo largo del uso de la aplicacin, y no solicitar toda

1
http://en.wikipedia.org/wiki/Gamification
la informacin en un primer momento. Facebook utiliza un componente de progreso con mensajes
como el siguiente:

Figura II.29. Monitorizacin del estado del perfil de Facebook
De esta manera, el usuario es incitado a facilitar toda su informacin al ver que existe un
porcentaje y que puede conseguir el 100%, quiz incluso conseguir alguna recompensa por ello. Es
una idea simple y muy sencilla conceptualmente, aunque quiz algo ms complicada de llevar a la
prctica. Resulta claro que las opciones de la suscripcin deben hacerse al configurar la misma, pero
siempre se pueden dejar campos con valores por defecto o incluso rselos habilitando a los usuarios a
medida que realicen tareas con el sistema y consigan ciertos logros. El diseo colaborativo de
CitYsens permitir ir refinando todo este componente de gamificacin all donde se necesite, pero la
idea es hacer algo ms ambicioso que la Agenda del Henares en esta rea y conseguir mayor nmero
de usuarios a travs de ello.
Funcionalidades como la creacin de una instancia personal de la Agenda o integracin de la
misma en otros sitios web no resultan de utilidad en CitYsens y no sern implementadas, al menos en
los diseos iniciales.
1.3.2 Alta y validacin de un nuevo evento
En la Agenda del Henares, cualquier usuario puede proponer un evento a aadir, incluidos
usuarios no registrados. Para ello, desde la pgina principal se permite acceder al formulario para
crear un nuevo evento.
1.3.2.1 Formulario de creacin
Todo usuario que desee aadir un evento a la Agenda del Henares, debe rellenar el siguiente
formulario:

Figura II.30. Formulario para proponer un evento en la Agenda del Henares
El formulario se compone de una serie de campos requeridos (informacin mnima necesaria
para describir el evento) y otros opcionales para aadir informacin adicional. El formato es sencillo y
la informacin requerida es la mnima posible.
Muchos de los campos del formulario son desplegables donde el usuario elige entre los valores
que se le ofrecen, evitando as posibles errores en la informacin. Las temticas de un evento son
elegidas de esta manera, lo cual facilita la bsqueda y filtrado posterior de los eventos al no permitir
otras etiquetas ms que las creadas en el sistema.
Para la fecha, al usuario se le presenta un calendario donde slo se permiten fechas futuras,
evitando as la creacin de eventos ficticios que nunca acontecieron.
Para la localizacin del evento, al usuario se le proponen una serie de lugares (utilizados
anteriormente en otros eventos o recurrentes en la Agenda) o se le permite crear uno nuevo
introduciendo direccin y municipio. Es ms adelante, en el proceso de validacin del evento, cuando
se establece la ubicacin en el mapa del evento o se corrige en caso necesario y se crea el lugar en
cuestin, si es que no exista en el sistema. Si el usuario selecciona uno de los lugares que ya existen
en el sistema, aparece la localizacin del mismo en un mapa para que el usuario vea el aspecto que
tendr su evento una vez publicado y a la vez compruebe que la situacin es correcta.
El campo en el que se introduce una direccin de correo electrnico de contacto contiene una
verificacin en tiempo real, de manera que si el texto escrito no tiene el formato x@x se colorea en
rojo. En cuanto el formato se cumple, el texto pasa a ser negro. Es un sistema muy claro de verificar
sintaxis en campos de texto que requieren un formato especfico, como puedan ser direcciones de
correo electrnico o direcciones de sitios web.

Figura II.31. Ejemplo de formulario completo
Una vez que el usuario pulsa el botn Validar, la propuesta de evento es enviada y al usuario se
le muestra un mensaje en pantalla informndole de que el evento ser publicado una vez ledo y
aprobado, generalmente en un intervalo de veinticuatro horas.

Figura II.32. Mensaje informativo sobre la creacin del evento
El usuario puede hacer modificaciones posteriores que tambin sern guardadas. Si la direccin
de contacto no fuese vlida, en este mensaje se detalla que la direccin no es correcta. No supone un
error crtico (el evento puede ser aprobado), pero no se dispondr de una forma de contacto con el
usuario creador del evento a menos que ste la corrija.
1.3.2.2 Validacin de un evento
Los eventos propuestos a travs del formulario descrito anteriormente son guardados en el
sistema y los administradores del mismo reciben acceso inmediato a los mismos. Un usuario
administrador, puede ver el evento, editarlo, consultar revisiones del mismo y utilizar el gestor de
repeticiones del mismo.
La opcin de ver un evento lo muestra tal y como se encuentra actualmente, con los campos en
el ltimo estado guardado. Esta visualizacin sirve para que el administrador detecte posibles errores
o escasez de informacin, as como para que lo analice desde el punto de vista del contenido para
poder decidir si se aprueba o no. Ya se detall con anterioridad que los eventos a publicarse en la
Agenda del Henares deben cumplir una serie de requisitos de contenido. Es trabajo de los
administradores de la Agenda decidir qu eventos cumplen estos requisitos y cules no.
La pestaa de edicin de un evento, permite al usuario con privilegios editar y modificar el
evento. Puede modificar los mismos campos que tiene a su disposicin el usuario que lo cre, as
como otros que existen para definir los distintos estados de un evento. El evento puede estar en
espera y no publicado, publicado pero incompleto, publicado, rechazado y oculto, etc.

Figura II.33. Pantalla de edicin de un evento para un usuario administrador de la Agenda
Si el lugar que defini el usuario creador para el evento no exista en el sistema, el administrador
puede modificar la geolocalizacin del evento sobre el mapa, en base a la direccin y municipio
especificados por el usuario que lo cre, y crear as un nuevo lugar que estar disponible para futuros
posibles eventos.
El administrador puede adems aadir una serie de organizadores del evento que se guardan en
el sistema, as como los lugares para relacionarse con los eventos. Tambin puede enviar un correo
electrnico utilizando una plantilla para detallar si el evento se est publicando, si le falta
informacin, si ha sido rechazado, etc.
Otros campos disponibles para el administrador incluyen metadatos para buscadores como
puedan ser ttulo, descripcin del contenido, palabras clave, etc.
El administrador dispone de una pestaa donde puede consultar las distintas revisiones de un
evento. Puede consultar la fecha y hora de una revisin concreta, comparar revisiones para consultar
los cambios realizados en cada una o restablecer el evento a una revisin anterior. Todo este control
de versiones de los eventos supone mucho registro de informacin por parte del sistema, pero
permite hacer un seguimiento exhaustivo de lo que acontece en el mismo, lo cual es requisito
imprescindible para los administradores.

Figura II.34. Panel de revisiones de un evento
El administrador dispone de un botn mostrar que le lleva a la pgina del evento y un botn
restablecer que le permite devolver el evento al estado en que se encontraba en dicha revisin.
Esta caracterstica proporciona un mtodo rpido y controlado de deshacer cambios y corregir
errores en los eventos.
El botn mostrar dif. muestra las diferencias entre ambas revisiones del evento, para detectar
rpidamente los cambios. Las diferencias se marcan en rojo.

Figura II.35. Herramienta de comparacin entre revisiones de un evento
El gestor de repeticiones es la cuarta pestaa de la que dispone un administrador en lo que a un
evento concreto se refiere. Mediante esta herramienta, el administrador dispone de distintas
opciones para duplicar el evento seleccionado, pudiendo as crear repeticiones de distintos tipos.
El administrador puede:
Crear N copias exactas del evento y luego editar cualquier campo en el que deban diferir
las copias (fecha, hora, lugar, etc.).
Crear copias diarias desde el da del evento hasta una fecha concreta.
Crear copias semanales (el mismo da de la semana que el evento original) hasta una
fecha concreta.
Crear copias mensuales el mismo da de la semana (seleccionando primer, segundo,
tercer, cuarto o ltimo da del mes) hasta una fecha concreta.
Aadir repeticiones en una serie de fechas concretas. Introduciendo una fecha por lnea,
se crearn repeticiones en esas fechas.
Aadir un evento existente al grupo de repeticiones del evento concreto.

Figura II.36. Gestor de repeticiones para eventos peridicos
Creadas las copias, el administrador dispone de otra pestaa donde puede visualizar todas las
copias de un evento y puede restaurar campos de varios eventos a la vez, permitindole as una
edicin mltiple de todas las repeticiones. De esta manera, si se desea cambiar algn campo en
comn como la descripcin de los eventos, se puede editar una copia y luego replicar el cambio a
todas las instancias de la misma.

Figura II.37. Herramienta para la edicin mltiple de repeticiones de eventos
El sistema muestra en verde el evento actual (del que se van a copiar los valores de los campos) y
en gris todas las repeticiones de dicho evento. Los campos que coinciden entre una repeticin y el
evento seleccionado (el verde) aparecen sombreados en gris. Los campos cuyos valores difieren
respecto al evento seleccionado aparecen en rojo y con un checkbox disponible al lado. Si el usuario
desea copiar el valor de un campo del evento verde a una (o varias) de las repeticiones, debe utilizar
dicho control. Una vez marcado un campo de los que diferan, aparece un recuadro amarillo
alrededor para indicar que ese valor ser reestablecido al que tiene el evento principal. De esta
manera rpida y sencilla, los administradores pueden realizar modificaciones sobre gran cantidad de
eventos simultneamente en cuestin de minutos.
Ateniendo al manejo que hace la Agenda del Henares de los eventos y su creacin y
administracin observamos varias funcionalidades tiles que merece mantener en las primeras
versiones de CitYsens.
Dado que todos los eventos deben ser validados con posterioridad, permitir su creacin a
cualquier usuario sin necesidad de estar registrado en el sistema es una opcin vlida. La proposicin
de eventos abierta a cualquier usuario puede ser problemtica si se empiezan a recibir eventos sin
control o si los eventos recibidos no son reales. El hecho de que las propuestas de evento de los
usuarios no se incluyan de manera definitiva en la Agenda permite filtrar los eventos falsos y
controlar que la Agenda siempre est en un estado consistente para con los usuarios. Dado el
carcter colaborativo y abierto que defiende la Agenda, es un acierto permitir la proposicin abierta
de eventos.
En CitYsens, sin embargo se aspira a jugar con la gamificacin y un sistema de roles para la
aprobacin y gestin de los eventos propuestos. La idea ser recompensar a los usuarios con una
participacin activa, de manera que vayan ganando una serie de puntos o reputacin que les
permitir desbloquear el acceso a distintas caractersticas avanzadas del sistema. Una forma de
fomentar esta participacin ser solicitando la ayuda de los usuarios en una serie de tareas, una de
las cuales pasara por estudiar eventos propuestos y aprobarlos o sealar posibles inconvenientes de
los mismos. A los usuarios se les ofrecern eventos a analizar o aprobar alejados geogrficamente de
su propia zona de inters y de manera aleatoria para evitar as potenciales conflictos de intereses.
Se pretende evitar esa centralizacin que tiene la Agenda del Henares en la que solo usuarios con
permisos pueden validar eventos. Lo que se desea es por un lado distribuir la gestin del sistema, a la
vez que se consigue fomentar e incentivar la participacin de los ciudadanos.
El acceso al formulario de proposicin de eventos se encuentra en la pgina principal, lo cual
facilita el acceso a un usuario que va a proponer un evento por primera vez. Caracterstica deseable
por ello y que se deber mantener en CitYsens.
El formulario para la creacin del evento es sencillo y mantiene la informacin mnima sin ser
excesivamente simple. El rea central donde incluir la descripcin del evento pone a disposicin del
usuario un editor de texto con el que poder describir correctamente el evento y todas sus
caractersticas. El control de los valores a introducir para los distintos campos es correcto y no
permite errores por parte del usuario. Limitar las etiquetas asociadas a una lista de posibles etiquetas
o gestionar las fechas mediante un calendario hacen por un lado ms sencilla la labor del usuario, a la
vez que proporcionan ese control necesario sobre los datos de entrada al sistema. La verificacin en
tiempo real detallada para el email de contacto resulta muy intuitiva y sencilla, por lo que debera
aspirarse a ese tipo de validacin de datos siempre que se pueda (los datos requieran un formato
concreto), restringiendo de una manera ms exigente los formatos aceptados. Habra que sopesar si
se deben poder crear eventos sin una forma de contacto vlida o si se desea tener un control ms
riguroso de los eventos que finalmente se muestren en el sistema.
El tener que validar los eventos propuestos tiene los alicientes sealados anteriormente, pero
tambin puede suponer una sobrecarga de trabajo para los administradores de la Agenda. La
validacin de eventos se podr siempre descentralizar creando permisos a distintos administradores
por rea geogrfica o por temtica, de manera que el control de la Agenda no sea llevado a cabo por
una nica cabeza pensante sino que sea un control colaborativo y distribuido real. Esta distribucin
del trabajo atiende siempre a la cantidad de eventos recibidos, cantidad de municipios gestionados,
etc.
Los administradores disponen de un control total sobre las entidades que conciernen a lugares y
a organizadores de eventos. Es un acierto mantener estructuras de datos para esta informacin,
aunque no sean entidades accesibles al usuario. De esta manera se pueden establecer las relaciones
necesarias entre eventos, organizadores y lugares, evitando as la duplicidad y la inconsistencia de la
informacin en lo que a estos campos se refiere. A pesar de ello, en la Agenda del Henares hay varias
entidades (lugares, organizadores, reas geogrficas, etc.) que se crean automticamente al
introducirse un evento que las menciona por primera vez y que son representadas nicamente por
un nombre.
En CitYsens estas entidades tendrn especial importancia, por lo que se aspira a realizar un
modelo de datos coherente y exhaustivo que permita una estructura de la informacin ms
profunda. A travs de modelos relacionales, habr que definir cuidadosamente las distintas
entidades y las relaciones entre ellas para poder tener un control absoluto sobre todos los datos
involucrados, sin dejar cabos sueltos o implementaciones menos rigurosas.
Las herramientas de control de versiones son indispensables a medida que aumenta el mbito
del sistema y los datos gestionados crecen. Se debe mantener dicha caracterstica para poder
siempre acceder a los cambios realizados y mantener el control total sobre el sistema.
Las herramientas que la Agenda del Henares pone a disposicin de los administradores del
sistema para crear repeticiones de eventos y hacer modificaciones mltiples sobre los mismos
resultarn de gran utilidad si la cantidad de eventos repetidos en el tiempo es grande. En la Agenda
del Henares existen varias repeticiones de eventos, pero tambin muchos otros que acontecen una
nica vez o con fechas irregulares. Para un prototipo inicial de CitYsens, no es una funcionalidad
necesaria ni bsica, pero desde luego sera deseable incluir ms adelante dichas caractersticas para
hacer la gestin del sistema ms rpida y efectiva.
1.3.3 Administracin de la Agenda
La Agenda del Henares, pese a ser simple desde el punto de vista del usuario y su interaccin con
la misma, posee un potente conjunto de herramientas para gestionar todo el backend del sistema.
Estas herramientas no proporcionan funcionalidad a la Agenda para los usuarios, pero permiten a
administradores y gestores del sistema tener un control absoluto sobre la aplicacin y poder hacer
las modificaciones pertinentes all donde sea necesario.

Figura II.38. Panel de control de la Agenda para un usuario administrador
1.3.3.1 Panel de control
En la vista del panel de control, los administradores tienen a su disposicin distintas secciones
donde se encuentran los controles agrupados en diferentes categoras.
En el panel de administracin se encuentran las configuraciones ms importantes a realizar sobre
el sistema. Este incluye:
Configurar Demosphere. A travs de esta opcin se accede a todas las posibles
configuraciones que ofrece Demosphere para personalizar la instancia de la aplicacin.
Verificar configuracin. Test automatizado que permite detectar errores en la
configuracin del sitio.
Borrar cach. Permite eliminar archivos temporales de la cach del sistema.
Alias y bandejas de correo. Gestiona las distintas cuentas de correo electrnico de la
Agenda y los aliases asignados a ellas. Permite tambin realizar configuraciones del
gestor de correo electrnico.
Usuarios y estadsticas. Permiten mostrar la lista de todos los usuarios del sistema junto
con sus atributos (fecha de creacin, ltimo acceso, permisos, etc.) y estadsticas sobre
los mismos.

Figura II.39. Informacin de usuarios de la agenda
Textos y traducciones. Permite gestionar las traducciones del programa, que por defecto
incluye textos en ingls en el cdigo fuente.
Temas. Permite listar, modificar, aadir y eliminar las temticas disponibles para
etiquetar los eventos.
Municipios. Ciudades que monitoriza la Agenda del Henares y donde tienen lugar los
eventos. Al igual que las etiquetas, los eventos slo pueden utilizar municipios creados
por los administradores.
Lugares. Adems del municipio, un evento tiene lugar en una localizacin concreta. Esta
seccin permite gestionar los distintos lugares que existen en la Agenda.
Regiones. Demosphere permite crear formas geomtricas sobre un mapa que definan
una regin. Desde este apartado se gestionan las regiones.
Artculos. Aqu se incluye la gestin de distintas pginas como puedan ser la pgina de
suscripcin o de informacin acerca de la Agenda.
Data backend. Desde aqu se pueden gestionar todas y cada una de las entidades que
componen la Agenda del Henares. Supone una capa transparente a las modificaciones
sobre la base de datos utilizada por el sistema. Esta seccin se documentar ms
exhaustivamente en el punto siguiente.
En el panel de control tambin se incluyen las operaciones registradas por el sistema como ms
frecuentes, para facilitar el acceso a tareas que se repiten con una frecuencia elevada.
Se incluyen tambin paneles con estadsticas de eventos y actividad de los usuarios en la Agenda
del Henares. Adems de todas estas secciones relativas a la configuracin se incluye un panel con
cambios recientes donde se detallan los eventos, el usuario modificador y el momento de la
modificacin. Esta seccin dispone de un pequeo control de cambios mediante el que los
administradores pueden consultar para un determinado evento los cambios que ha sufrido, quin los
ha llevado a cabo y a qu hora se produjeron.
Haciendo clic sobre el botn situado a la izquierda del evento se puede consultar la lista de
cambios. Tambin se muestran a la derecha de cada evento el tiempo transcurrido desde la ltima
modificacin y el ltimo usuario autor de la modificacin.

Figura II.40. Informacin sobre cambios recientes sobre un evento concreto
Por ltimo se muestra una seccin donde se listan los eventos ms visitados, junto con una serie
de estadsticas de cada uno. En la parte superior se muestra el nmero total de visitas, el nmero de
visitas previstas (basndose en estadsticas de datos anteriores) y las visitas recibidas ayer. De esta
manera, un administrador puede ver rpidamente qu eventos estn despertando mayor inters.

Figura II.41. Eventos ms visitados
Demosphere es un software bastante completo en lo que al backend se refiere. Plantea la agenda
colaborativa de manera diferente a lo que pretende ser CitYsens, y contiene varias limitaciones
adems de estar anticuado en varios mbitos.
Por ello, si bien ser necesario disponer de las herramientas de gestin que permitan administrar
CitYsens de manera efectiva, su implementacin tendr poco que ver con la que utiliza la Agenda del
Henares.
1.3.3.2 Backend
El backend representa la parte del sistema encargada de gestionar y tratar los datos con los que
el usuario interacta, as como de gestionar la lgica y flujo de la aplicacin. El frontend es
simplemente un interfaz de usuario que trata los datos del usuario para darles una forma que el
backend entienda y pueda tratar.
Demosphere provee una seccin entera para el backend que se conforma de todos los datos con
los que el sistema trabaja. A partir de esta seccin, podemos inferir las distintas entidades con las
que trabaja el sistema, as como la exhaustividad con la que se almacena la informacin
perteneciente a cada una de ellas. Este anlisis es de vital importancia para nuestro objetivo, ya que
el diseo de datos de CitYsens debe ser exhaustivo y minucioso en sus fases iniciales para evitar
grandes problemas y conflictos que puedan surgir ms adelante en el proceso de creacin.
Dentro de la seccin Backend, Demosphere nos lista las distintas entidades y nos permite
acceder a cada una de ellas para consultar los campos, gestionar las ya existentes y realizar otras
operaciones. A continuacin se detallan las entidades ms relevantes del sistema y que susceptibles
de cobrar gran importancia en el proceso de diseo de CitYsens.
1.3.3.2.1 Ciudad
En esta seccin se listan todas las ciudades que existen en la Agenda del Henares. Demosphere
nos informa de que las ciudades no utilizadas se eliminan una vez al da y que las ciudades que no se
usan o que no estn publicadas no se muestran a los usuarios. Las ciudades nuevas se crean cuando
se declaran en un formulario de evento o lugar.
Al lado de cada ciudad se muestra un campo que guarda un nombre corto para la ciudad y otro
campo que se corresponde con la cantidad de eventos que tienen lugar en dicha ciudad. De esta
entidad se guardan nicamente tres campos, lo cual puede resultar deficiente en cuanto a la
representacin de la informacin se refiere.

Figura II.42. Diferentes municipios de la Agenda del Henares
Demosphere permite unificar ciudades que han sido dadas de alta varias veces con distinto
nombre como seran Alcala de Henares y Alcal de Henares.
La opcin Fusionar municipios permite especificar la ciudad correcta y la mala, de manera que
la ciudad mala ser reemplazada en todos los sitios donde aparezca por la buena y luego ser
eliminada. Gracias a esta funcionalidad se puede mantener el estado de los datos consistente e ir
puliendo las distintas deformaciones de los datos que vayan surgiendo. Mediante un proceso
automatizado se actualizarn todas las relaciones y la ciudad mala podr ser eliminada sin perder
informacin relacionada con dicha entidad.

Figura II.43. Herramienta para la fusin de municipios
1.3.3.2.2 Evento
Los eventos representan la parte central de la Agenda del Henares y como tales, se guarda
mucha ms informacin de ellos.

Figura II.44. Lista de eventos de la Agenda del Henares
En esta seccin se listan todos los eventos y sus campos, permitiendo editar, visualizar o borrar
los eventos existentes en el sistema. Los eventos aparecen relacionados con otras entidades como
puedan ser el lugar donde suceden (place_id), el usuario que lo cre o el usuario que lo modific por
ltima vez.
Todas las operaciones relativas a eventos ya se han analizado en secciones anteriores del
presente documento.
1.3.3.2.3 Lugar
Los lugares representan las direcciones donde acontece un evento. Existen variaciones de un
mismo lugar, que se ligan mediante el campo reference_id. Cada evento pertenece a una ciudad o
municipio, guardndose el id del mismo como atributo del lugar. Otros campos son la latitud y la
longitud, utilizadas para mostrar el lugar sobre un mapa.
Podemos observar que existen lugares idnticos que tan solo se diferencian por el nivel de zoom
que muestran sobre el mapa. Esta situacin representa una duplicidad de la informacin innecesaria,
ya que las entidades estn representando el mismo punto geogrfico.

Figura II.45. Lugares donde acontecen los eventos, relacionados con sus respectivos municipios
Los lugares no utilizados se borran automticamente al cabo de un mes. Los lugares que se
utilizan nicamente en eventos no publicados o rechazados se eliminan al cabo de un mes. Estos
lugares son los menos, ya que los lugares se dan de alta al introducir sus datos en el formulario de un
evento nuevo.
1.3.3.2.4 Post
En esta seccin aparecen los distintos posts de los que consta la Agenda del Henares. Pantallas
como la de contacto, la de los criterios de publicacin y otras se listan aqu. Desde esta pgina se
pueden crear tambin nuevos posts.

Figura II.46. Diferentes posts de la Agenda del Henares
El campo body guarda la pgina en formato HTML. Los posts que tienen un asterisco en el
campo box aparecen en la pgina principal como una caja en la seccin derecha.
Para crear un nuevo post tan solo hay que incluir los campos para el ttulo, el cuerpo y si el post
est publicado o no. Para el cuerpo se utiliza un editor de texto que genera el cdigo HTML. El resto
de campos son actualizados automticamente por la aplicacin en el momento de su creacin.
1.3.3.2.5 Tema
Las temticas asociadas a un evento sirven para clasificar y filtrar los eventos. Dado el carcter
social-poltico de la Agenda del Henares, algunas etiquetas son Salud, Educacin, Ecologa, etc.
Cada temtica lleva asociado un color para que se identifiquen ms rpidamente los eventos al
ver el color de su temtica principal en la lista de eventos. Tambin se incluye en la pgina principal
un control para filtrar una determinada categora y que aparezcan nicamente los eventos
relacionados.

Figura II.47. Gestin de las temticas para un usuario administrador
En la creacin de una temtica, se pueden especificar un color o bien un icono mediante una
imagen de 13x18. Las temticas disponen de una serie de campos para especificar si aparecen en la
pgina de un evento o en la pgina principal.
1.3.3.2.6 Trmino
Esta seccin est dedicada a entidades propias que no provee Demosphere. Se pueden crear
vocabularios que representan un conjunto para agrupar trminos. En el caso de la Agenda del
Henares, el nico vocabulario definido es Supervisor, por lo que los nicos trminos que se pueden
crear pertenecen a dicho vocabulario.
En la creacin de un nuevo trmino, se debe seleccionar el vocabulario al que pertenece. En la
Agenda slo se puede utilizar supervisor. Una vez seleccionada la categora, se procede a rellenar
los datos, que consisten en un nombre y una descripcin (el campo asociado al vocabulario toma
valor en el primer paso de la creacin, al seleccionarlo).

Figura II.48. Diferentes "trminos de la Agenda del Henares
Supone una forma sencilla de dar cabida a otros datos, aunque de manera bastante pobre, ya
que slo disponen de un nombre y una descripcin.
1.3.3.2.7 Usuario
Los usuarios representan una entidad importante en el sistema, ya que se debe guardar mucha
informacin sobre cada uno de ellos, adems de estar intrnsecamente relacionados con otras
entidades.
En la lista se muestran todos los campos, que incluyen campos bsicos como el nombre de
usuario, la contrasea (cifrada), el rol del usuario, fechas de ltimo acceso. Se hace referencia a un
campo data, detallando un nmero entero. Si accedemos a un usuario concreto, obtenemos una
vista de perfil donde podemos desplegar el contenido de dicho campo data:

Figura II.49. Informacin sobre un usuario concreto en formato de PHP Array
Como se observa en la imagen, el campo data contiene datos relativos a la suscripcin del
usuario, configuraciones de la agenda personal y otras, mostradas como un array PHP.
1.3.3.2.8 Carpool
Curiosamente, Demosphere provee una entidad para guardar viajes compartidos en coche para
acudir a un evento (del ingls, carpool). O al menos esto se puede inferir viendo los campos
necesarios para la entidad:

Figura II.50. Opcin para crear carpools
Se solicitan como campos el identificador de evento y de usuario, as como punto de salida y hora
de partida. Adems se especifica si es viaje de ida y vuelta (isRoundTrip).
Aunque original, esta entidad no se utiliza en la Agenda del Henares.
1.3.3.2.9 Artculo
Los artculos que se guardan representan posts de otras pginas que contienen eventos.
Demosphere permite guardar fuentes con potenciales eventos (las fuentes pueden ser otros sitios
web o correos electrnicos). Estos artculos se corresponden con uno de estos posibles eventos, y se
relacionan con el identificador de la fuente a la que pertenecen (feedId).
1.3.3.2.10 Fuente
En ingls Feed, son pginas o sitios web que contienen publicaciones con informacin
susceptible de transformarse en un evento para la Agenda del Henares.

Figura II.51. Diferentes fuentes de eventos definidas en la Agenda del Henares
Actualmente en la Agenda del Henares se monitorizan 4 pginas como posible fuente de eventos,
pero el mayor volumen de eventos proviene de las asociaciones participantes o de los eventos
propuestos por cualquier usuario. Esta entidad no tiene gran relevancia en la Agenda del Henares.
1.3.3.2.11 Comentario
Esta entidad representa todos los comentarios creados en relacin con algn evento. En la pgina
de un evento, existe un botn para comentar que pueden utilizar tanto usuarios registrados como
usuarios annimos.
Para cada comentario, se guarda el evento en el que se realiz dicho comentario, as como el
estado, la direccin IP desde la que se hizo, el ttulo, el cuerpo del comentario y la fecha de la ltima
modificacin.
1.3.3.3 Pendiente
Los usuarios administradores de la Agenda del Henares tambin disponen de una seccin
Pendiente donde se listan eventos y su estado. De esta manera, los administradores pueden
consultar los eventos que necesitan aprobacin, que han sufrido cambios, que son nuevos en el
sistema, etc.
Mediante un cdigo de colores se hace muy intuitivo detectar qu eventos requieren la atencin
del administrador y cules no. Esta seccin facilita enormemente sobre todo la labor de gestin de
eventos nuevos, ya que todo evento propuesto por los usuarios pasar a estar pendiente de
aprobacin de manera automtica.
1.3.3.4 Correo
La seccin correo permite semi-automatizar la creacin de eventos a partir de informacin
recibida va correo electrnico. Demosphere incluye esta herramienta que escanea los emails
recibidos en distintas fuentes de correo en busca de campos concretos que extrapolar como nuevos
eventos y los lista en esta seccin.
Cada entrada en esta seccin supone un posible evento, y muestra la informacin contenida en el
correo, as como eventos con los que tiene alguna relacin (en base a palabras clave), fecha y hora,
etc.
Mediante un botn de importar se pueden transformar los correos con potenciales eventos en
un evento del sistema, momento en el cual se puede editar para completar la informacin necesaria.
La herramienta ahorra mucho tiempo en trminos de copiar, pegar y formatear la informacin de
acuerdo a la estructura de un evento del sistema.
1.3.3.5 Fuente web
De manera similar al punto anterior, Demosphere provee una herramienta que detecta nuevos
posts en distintas pginas web en busca de potenciales eventos a incluir en la Agenda.
En esta seccin se muestran los potenciales eventos con un formato similar al de la seccin
correo, aunque con la informacin correspondiente (sitio web de la publicacin, fecha, hora, etc.).

Figura II.52. Parseo de las pginas monitorizadas con potenciales eventos para la agenda
Cada potencial evento incluye el botn para importarlo como nuevo evento, ahorrando a los
administradores el trabajo de formatear la descripcin del evento, el ttulo y otras tareas que
suponen un consumo de tiempo innecesario.
1.3.3.6 Estadsticas web
La ltima seccin de la que disponen los administradores incluye todas las estadsticas sobre el
sitio web. Para ello, utiliza el analizador AWStats (AWStats) que se puede integrar con Apache para
mostrar las distintas pginas que conforman el log de las estadsticas. Permite personalizar las
estadsticas que se desean consultar con una gran cantidad de posibilidades agrupadas en categoras:
Cundo. Histrico mensual, das del mes, das de la semana, visitas por horas.
Quin. Pases, lista completa, servidores, ltima visita, direccin IP no identificada, visitas
de robots/spiders.
Navegacin. Duracin de las visitas, tipos de ficheros, descargas, lista completa, accesos,
pgina de entrada, sistemas operativos, versiones, navegadores.
Enlaces. Origen de la conexin, enlaces desde buscadores sitios de enlace, bsquedas por
frases clave, bsquedas por palabras clave.
Otros. Miscelneos, cdigos de error HTTP, pginas no encontradas.


Figura II.53. Estadsticas de la Agenda del Henares, utilizando AWStats
Todos estos datos son de gran utilidad tanto a nivel tcnico como a nivel de contenido. Permiten
detectar errores de pgina, patrones de acceso, reas ms utilizadas, etc.
Con toda esta informacin se pueden extraer datos sobre el uso que hace la gente de la Agenda
del Henares y detectar las funcionalidades ms usadas y, de manera anloga, las menos tiles para
los usuarios. Es con este conocimiento en mente con el que se abordar el diseo de CitYsens y toda
su posterior refinacin, ya que el sistema a construir pretende superar y mejorar a la Agenda del
Henares en mbitos de usabilidad y utilidad para los ciudadanos.
La Agenda del Henares posee herramientas de gestin del backend muy potentes, provistas por
el software utilizado, Demosphere. Si bien es cierto que todas estas caractersticas son muy tiles, no
son requisito para unos primeros prototipos funcionales donde ir dando forma al sistema en base al
feedback de los usuarios.
CitYsens pretende ser construido entre todos, de manera colaborativa y siguiendo siempre un
ciclo de vida iterativo en el que constantemente se revisan, corrigen y aaden funcionalidades para ir
aproximndose a un sistema que satisfaga todas las necesidades y expectativas que los ciudadanos
tienen en lo que se refiere a un sistema de estas caractersticas.
Herramientas de administracin que convendr tener como punto de partida en CitYsens son la
gestin de todas las entidades utilizadas por el sistema y las estadsticas.
La gestin de las entidades permitir un control ms sencillo y ms rpido de los datos, sin tener
que trabajar directamente con la base de datos del sistema. Demosphere es un claro ejemplo de
cmo, con un sistema de gestin sencillo, se pueden manejar los datos de manera rpida e intuitiva.
CitYsens debera como mnimo a igualar algo as en sus primeras versiones, para luego desarrollar
nuevas y ms potentes funcionalidades para su gestin. Hablando de prototipos iniciales, las
herramientas debern ser muy sencillas y no consumir demasiado tiempo de codificacin, ya que es
muy probable que sufran modificaciones a medida que las distintas entidades cambien y se ajusten a
nuevas funcionalidades.
Del modelo de entidades que utiliza la Agenda del Henares para su backend podemos extraer
algunas que resultarn de especial inters, ya que su presencia en CitYsens ser prcticamente
obligada.
CitYsens deber mantener una entidad para los eventos, si bien su versin de la entidad y los
datos a guardar de la misma sern muy dependientes del diseo del sistema. Con los usuarios sucede
lo mismo, aunque en este caso el nivel de profundidad ser mucho mayor que en la Agenda, ya que
se pretende hacer un seguimiento del perfil para crear el sistema de gamificacin descrito
anteriormente. Las ciudades tambin debern recibir un mayor nivel de detalle, ya que en la Agenda
simplemente son una cadena de texto. Para relacionarse con las ciudades y los eventos, deber
pensarse una entidad intermedia equivalente a los lugares de la Agenda, pero intrnsecamente ms
compleja, a nivel de barrios, distritos y zonas. Los eventos tambin se debern clasificar atendiendo a
unas temticas o caractersticas, pero no de una manera tan rgida como en la Agenda donde se
tratan unas etiquetas predefinidas. Se podran desarrollar unos niveles de peso de cada temtica,
de manera que un evento tenga unas temticas centrales y otras menos decisivas, pero tambin
relacionadas. Con un sistema de este tipo, se pueden mejorar mucho los procesos de bsqueda,
clasificacin de los eventos e incluso el seguimiento de los intereses de cada usuario para poder
hacerle sugerencias en base a su experiencia con CitYsens.
Otras entidades que encontramos en la Agenda del Henares como puedan ser los lugares, los
trminos, los artculos y las fuentes no tendrn una traduccin inmediata en CitYsens, si bien se
tendrn en cuenta a la hora de pensar e incorporar nuevas funcionalidades que tomen como punto
de partida la Agenda.
La funcionalidad de estadsticas proporcionara otra forma de feedback en las fases iniciales de
CitYsens, permitiendo detectar patrones de uso que hacen los usuarios del sistema. Posteriormente y
con un feedback abierto por parte de los usuarios se pueden obtener razones y explicaciones a esos
patrones de utilizacin y hacer ms efectiva la labor de refinamiento del sistema. Se deber, al
menos como punto de partida, integrar AWStats con las primeras versiones de CitYsens para
disponer de toda la informacin concerniente al uso que se hace del sistema posible.
Una caracterstica muy interesante a tener presente en el sistema ser el control de versiones
sobre las distintas entidades. El sistema deber registrar quin cambia qu, cundo y cmo. De esta
manera se controla todo el flujo de modificaciones que sufre la aplicacin en cuanto a datos se
refiere, a la par que se permite deshacer cambios y volver a un estado de los datos previo a las
modificaciones.
2. Diseo con Wireframes
Realizado el anlisis exhaustivo de la Agenda y sus caractersticas, se dispone de informacin
suficiente para ir abordando las distintas funcionalidades que debera poseer un primer prototipo de
CitYsens.
Los requisitos nos dicen qu debe proporcionar el sistema, qu acciones nos permite llevar a
cabo, pero no nos dicen el cmo. Para comenzar a plasmar las ideas en una serie de pantallas
prototipo que describan el aspecto y el funcionamiento que seguir el sistema, se implementaron
una serie de bocetos, asociados a cada funcionalidad concreta, que permiten esa primera
materializacin de la aplicacin.
Mediante todas estas pantallas se pretenden decidir de manera colaborativa los distintos flujos
que seguir el sistema en cada caso de uso. Siguiendo un ciclo de vida iterativo, las distintas
versiones se irn juzgando por los grupos impulsores y colaboradores para ir retocando y refinando
el diseo all donde sea necesario. El producto final ser un diseo que permitir al equipo de
desarrollo disponer de unos requisitos claros y concisos de qu es lo que hay que implementar,
extrapolando as los modelos de datos necesarios y cmo se relacionan entre ellos.
Como herramienta principal para la creacin de estas pantallas se utiliza Balsamiq Mockups.
2.1 Balsamiq Mockups
Balsamiq Mockups se define como a rapid wireframing tool that helps you work faster and
smarter (una herramienta para crear wireframes de manera rpida e inteligente). La propia
palabra wireframe sugiere la idea de estructura bsica (marco de alambre, literalmente). A su vez,
mockup en ingls se puede traducir como maqueta, esbozo.
El propio nombre de la herramienta ya est dndonos una idea de la utilidad que proporciona. La
aplicacin permite dibujar rpidamente pantallas prototipo del sistema, que facilitan la creacin de
los flujos a seguir con cada funcionalidad. Al tener una representacin grfica de los elementos, se
obliga a los diseadores a mantener una coherencia, cohesin y usabilidad a lo largo de todo el
proceso de creacin de la interfaz de usuario.
Los distintos wireframes creados, sirven tanto para analizarlos en grupo y seguir procesos de
tormenta de ideas de manera rpida y sencilla como para guiar a los programadores en la estructura
y funcionamiento de la aplicacin. De esta manera, proporcionan el nivel de especificidad necesario
de cara a definir unos requisitos claros y concisos.
La aplicacin pretende sustituir al tradicional sketch en papel o en una pizarra, acelerando el
trabajo y aportando todas las ventajas de una versin digital: copia, duplicidad, modificacin,
facilidad para compartir/enviar, etc. Es por ello que los distintos elementos de los que consta para
crear los wireframes tienen un aspecto de trazo a mano, de esbozo. Este estilo bsico y cercano
proporciona un aspecto agradable que adems ayuda a que los prototipos no sean malinterpretados
como versiones finales del producto.

Figura II.54. Interfaz de usuario de Balsamiq Mockups
La aplicacin dispone de un rea principal blanca, que es el rea de trabajo a modo de lienzo. En
la parte superior dispone los distintos controles disponibles agrupados por categoras en una lista
horizontal. Se pueden filtrar por tipos (botones, contenedores, formularios, multimedia, etc.).
El funcionamiento es tan sencillo como seleccionar el control deseado y arrastrarlo al rea
central. Una vez ah se puede modificar el control para que tenga el aspecto necesario, cambiando
tamao, posicin, color, texto, profundidad y muchos otros atributos, siempre dependientes del tipo
de control.
Para redimensionar controles, encuadrarlos, centrarlos y otras operaciones, Balsamiq provee un
sistema de rejilla que automticamente permite colocar un elemento dentro de otro coincidiendo en
una esquina, con un marco de 10x10 pxeles, centrndolo, etc. Este sistema se puede desactivar
temporalmente para realizar ajustes de manera manual, si as se desea.
Balsamiq tambin proporciona una barra de bsqueda para un rpido acceso a los controles,
simplemente tecleando su nombre (o parte del mismo) y pulsando la tecla entrar, el control es
aadido al rea central.
La aplicacin incluye una gran cantidad de controles, siempre los ms comunes y necesarios en
cualquier aplicacin web (sobre todo, aunque tambin incluye controles orientados a aplicaciones
mviles). En cualquier caso, Balsamiq dispone una carpeta assets (del ingls, recursos) donde se
pueden incluir imgenes e iconos que estarn disponibles como si se tratase de controles propios de
la aplicacin.
En esta carpeta de recursos, se pueden incluir tambin archivos de Balsamiq (que tienen la
extensin bmml) y aparecern como controles disponibles para otros proyectos con acceso a esa
carpeta. De esta manera, siempre se puede ampliar la lista de controles disponibles con todos
aquellos que sean necesarios. Para ello existe una comunidad muy activa de usuarios y
colaboradores que ponen a disposicin pblica distintos controles, implementados siempre
utilizando Balsamiq.
Otra posibilidad que ofrece Balsamiq es enlazar distintos archivos para emular la navegacin por
pantallas que hara un usuario en el sistema real. Cada control puede ser enlazado con alguno de los
otros wireframes (archivos .bmml) que haya en el mismo directorio del wireframe actual. De esta
manera, cuando se visualiza el wireframe en modo presentacin, el control enlazado acta como un
enlace de una pgina web (cambia el cursor e indica a qu wireframe va dirigido) y permite pasar de
uno a otro como si del sistema real se tratase.

Figura II.55. Enlazado de wireframes simulando la navegacin sobre una pgina real
Utilizando esta funcionalidad de Balsamiq se puede mostrar el flujo de pantallas de manera
dinmica, permitiendo mostrar algo mucho ms cercano al sistema final. Esta caracterstica permite
detectar fallos e inconsistencias en el diseo, mucho antes de comenzar la fase de codificacin, lo
que minimiza el impacto que tendr su resolucin.
Balsamiq permite utilizar una serie de controles de markup para hacer anotaciones sobre los
wireframes. Estos controles incluyen flechas, cruces para tachar, notas, etc. Pretenden aportar esa
caracterstica de los diseos a mano o pizarra, en los que se puede tachar, sealar, marcar y en
definitiva hacer anotaciones.
Por ltimo, Balsamiq permite exportar los wireframes en formato de imagen png o como
documento pdf. Esta posibilidad permite hacer accesibles los wireframes a otros miembros del
equipo, que quiz no utilicen la aplicacin y por lo tanto no puedan visualizar los archivos en su
formato nativo bmml.
2.2 Intencin y forma de trabajo
Para abordar la tarea de creacin de los wireframes y poder con ellos describir todas las
funcionalidades del sistema, se decide asociar cada wireframe a un caso de uso concreto. De esta
manera, descrita una situacin en la que un usuario utiliza el sistema para extraer una utilidad (caso
de uso), se procede a disear una serie de pantallas que describan cmo va respondiendo el sistema
ante las interacciones con el usuario (wireframes).
Utilizando este mtodo de describir cada caso de uso se cubrirn todas las situaciones que
experimentar el sistema, por lo que resulta la mejor organizacin a seguir para no olvidar ningn
mecanismo que deba ser descrito.
En CitYsens, una de las principales diferencias que encontraremos en cuanto a funcionalidades
reside en el tipo de usuario. Existirn usuarios registrados, que tendrn un tratamiento mucho ms
complejo (seguimiento de intereses, perfil a completar, tareas asociadas, etc.) que los usuarios no
registrados. CitYsens pretende, al igual que la Agenda del Henares, permitir que usuarios que no
quieren registrarse puedan acceder a la informacin y utilizar las herramientas de bsqueda,
localizacin y otras. Obviamente, estos usuarios tendrn a su disposicin muchas menos
caractersticas que los usuarios registrados, pero aun as podrn llevar a cabo las tareas de consulta,
bsqueda, suscripcin, etc.
CitYsens pretende ser un sistema de todos y para todos. El habilitar un funcionamiento mnimo a
usuarios que, a efectos tcnicos, no forman parte del sistema es dejar una puerta abierta para que
todo el que quiera utilizarlo pueda hacerlo. Potencialmente, si estos usuarios encuentran til el
sistema y extraen el servicio que pretenden, acabarn registrndose en el sistema.
Para empezar a crear los wireframes, se opta por describir primero las funcionalidades bsicas, es
decir, aquellas que tiene a su disposicin un usuario no registrado. A medida que se estudian y
modifican los distintos wireframes asociados para resolver los problemas detectados, se va refinando
el diseo y se acotan las posibilidades a manejar cuando se describan los casos de uso de un usuario
registrado en el sistema. Mediante el ciclo de vida iterativo e incremental, el grueso de los problemas
ser detectado y resuelto en las primeras fases de diseo, haciendo que las ltimas iteraciones del
diseo sean meros refinamientos, representando cambios mnimos sobre el funcionamiento del
sistema. Se sigue este enfoque para resolver los primeros problemas sobre los casos de uso del
usuario ms simple (no registrado) y as poder afrontar el diseo de los casos de uso del usuario ms
complejo (usuario registrado) con una base slida y trabajada.
Utilizando Trello, se cre una tarjeta donde llevar a cabo la coordinacin de los distintos
miembros del equipo. La tarjeta contiene una lista de los distintos casos de uso a describir, asociando
un nmero a cada uno de ellos. El nombre de cada wireframe debe ser descriptivo de la entidad
sobre la que se centra, el caso de uso que describe, y si hay variantes del mismo, se aadirn letras
sobre el nombre, diferenciando el porqu de las variaciones.

Figura II.56. Tarjeta para la coordinacin de los diferentes wireframes en Trello
Cuando se implementa un wireframe nuevo se marca en la lista, de manera que todo el equipo
puede ver el avance y las tareas en curso en cada momento. Tambin se utiliza dicha tarjeta para
plantear cuestiones o dudas que van surgiendo en el momento y solicitar ayuda u opinin en
referencia a un asunto concreto.
Utilizando los controles de markup de Balsamiq, sobre los wireframes se anotan descripciones
sobre el flujo del funcionamiento de algn elemento en concreto, as como dudas o cuestiones que
surgieron en la creacin del mismo.

Figura II.57. Ejemplo de wireframe con notas y comentarios descriptivos
Estas dudas y cuestiones se comentan posteriormente en la propia tarjeta de Trello, en un
meeting por Google Hangouts o como se considere oportuno.
Para trabajar con los wireframes, se dispuso un directorio especfico en el Dropbox compartido
por el equipo de desarrollo. Trabajando sobre ese directorio, los cambios realizados y los archivos
aadidos son inmediatamente sincronizados online, de manera que el trabajo est ms seguro y se
pueden incluso restaurar versiones anteriores de los archivos. Tambin permite que todos los
miembros del equipo dispongan de las ltimas versiones en todo momento, sin tener que estar
intercambiando archivos con las ltimas modificaciones.
Dropbox guarda una serie de versiones anteriores para todos los archivos, de manera que se
pueden restaurar archivos modificados a versiones anteriores de manera rpida y sencilla. Esta
funcionalidad resulta muy til en un proyecto de estas caractersticas, donde los cambios se
producen constantemente y es esperable que se cometan errores con cierta frecuencia.

Figura II.58. Control de versiones de un archivo en Dropbox
Trabajando sobre el directorio compartido en Dropbox, se cre el directorio Diseo-UI, donde
se fueron colocando los distintos wireframes. Ms adelante en el proceso de diseo, se decidi que
se iban a ir separando las distintas evoluciones de los wireframes como versiones diferentes, por lo
que se cre una subcarpeta para cada versin.
Cada carpeta asociada a una versin contiene a su vez una subcarpeta assets donde colocar
todos los recursos externos utilizados por Balsamiq. De esta manera se comparten los recursos en
todos los wireframes y no hay que disponer los archivos por repetido.
Por ltimo, para mantener despierta la anticipacin por CitYsens de todo el grupo de
involucrados (impulsores, pioneros, colaboradores, etc.) y mantenerles al corriente del estado del
diseo, con cierta frecuencia se van publicando los avances a travs del grupo de Facebook de
CitYsens.
Aunque en las fases iniciales no se pretenda recibir feedback, s que se recibieron varios
comentarios y propuestas. Es un poco ms adelante en el proceso cuando se pretenden recabar
todas las opiniones posibles para refinar el sistema.

Figura II.59. Post informativo en Facebook sobre el avance en el diseo
Utilizando el servicio online de Balsamiq (myBalsamiq) se pueden ofrecer enlaces a los
wireframes que permiten la navegacin a travs de la funcin para enlazar los wireframes
mencionada anteriormente. Gracias a esta caracterstica, todas las personas involucradas o
interesadas en el sistema pueden ver el diseo de cada wireframe, adems de navegar por las
distintas pantallas implementadas. Haciendo estas publicaciones peridicas e informativas,
permitimos que los usuarios sigan da a da el diseo y que, cuando solicitemos su feedback, hayan
tenido tiempo de estudiar el sistema, familiarizarse con l y proponer las mejoras que se les ocurran
de manera cuidadosa y elaborada.
2.3 Evolucin y componente participativo
A lo largo del proceso de diseo, se fueron identificando problemas complejos, cuya resolucin
implicaba replantearse varios aspectos del sistema. Estos cambios propiciaron la separacin en
versiones de los wireframes, de manera que comenzando en la versin 1, se fueron creando
versiones, consolidando versiones cada vez que se mezclaban varios cambios complejos a la vez.
Esta separacin permite echar un vistazo rpido atrs, para repasar porqu se tomaron ciertas
decisiones e incluso permiten ir entregando versiones a los usuarios para su revisin, teniendo en
cuenta que entre versin y versin se detectan y mejoran cosas, por lo que el feedback de los
usuarios de una versin anterior puede resultar obsoleto.
El proceso de diseo se estructur en tres fases distintas. La primera incluye al equipo de
desarrollo pensando, identificando y resolviendo los distintos problemas encontrados en el diseo
del sistema. En este punto se pretenden afrontar y solucionar la mayor parte de los problemas, ya
que el coste es mucho menor al estar en las primeras fases. Adems, al ser analizados y resueltos por
el equipo de desarrollo (que tiene un perfil ms tcnico) se consigue que el diseo inicial tenga
siempre presentes las posibilidades que ofrece la tecnologa y no se diseen soluciones inviables en
su fase de desarrollo.
El segundo paso pretende llevar a cabo una validacin por parte de todo el grupo impulsor,
incluyendo no ya solo a personas con un perfil tcnico, sino a todos los miembros. Los ms allegados
a CitYsens, que colaboran y trabajan en los distintos aspectos que un proyecto como este requiere
(comunicacin, gestin, difusin, coordinacin, participacin en eventos, etc.) tendrn en esta
segunda fase la voz y el voto para buscar problemas sobre el diseo presentado. Manifestar
inquietudes, sealar posibles problemas derivados y en definitiva presentar todas las pegas posibles
para conseguir que durante la fase de desarrollo la mayora de los problemas (o al menos los ms
importantes) hayan sido detectados y prevenidos.
El ltimo paso del proceso pretende contar con el tiempo y la dedicacin del grupo pionero,
compuesto por personas que representan a los primeros usuarios potenciales del sistema. Personas
de distintas asociaciones, con un inters en la participacin ciudadana o incluso con conexiones que
permitan la difusin e implantacin del sistema prestarn su tiempo para llevar a cabo los primeros
talleres de uso, seguir verificando y validando los requisitos y seguir refinando el proceso de creacin
de CitYsens.
A pesar del proceso descrito anteriormente, el equipo de desarrollo tambin plantea distintas
tareas y consultas al grupo de pioneros cuando la situacin as lo requiere. Un ejemplo de esta
colaboracin, que hace que el diseo sea ms abierto y colaborativo es la consulta hecha a travs del
grupo de Facebook para identificar qu campos son ms importantes de cara a la creacin de un
evento.

Figura II.60. Tarea planteada a los pioneros en el grupo de trabajo de Facebook
En este ejemplo de consulta colaborativa se planteaba qu campos consideran importantes los
pioneros a tener en cuenta de cara a guardar informacin sobre un evento. Los miembros del grupo
de pioneros podan votar los campos que consideraban importantes, as como aadir campos nuevos
que no hubieran sido propuestos.
Esta interaccin permiti al equipo de desarrollo validar el diseo que se estaba haciendo en ese
momento, as como sopesar las propuestas e incluso aadir alguno de los campos que resultaba
importante de acuerdo a las votaciones.
A travs de estos procesos de consulta y de interaccin con los grupos de usuarios interesados en
CitYsens, se propicia la anticipacin por el mismo, ya que la gente observa el avance y adems siente
que es parte de l. El equipo de desarrollo, por otro lado, tiene mucha informacin con la que
trabajar y en base a la que decidir qu aproximacin tomar. Se trata de un diseo colaborativo en
todos los niveles.

2.4 Wireframes
Aunque como se coment en secciones anteriores los wireframes se han creado en base a los
distintos casos de uso a definir, previamente se haban adoptado ciertas ideas iniciales y stas fueron
plasmadas en mockups como punto de referencia.
Estos wireframes corresponden a una fase previa al anlisis de la Agenda del Henares y sirvieron
para establecer un punto de partida de la idea inicial del sistema. Se contemplan aqu para contrastar
la evolucin en el diseo y cmo a travs del ciclo de vida iterativo se han ido refinando y mejorando
hasta la situacin actual.
2.4.1 Diseos iniciales
En las primeras aproximaciones, se tomaron como punto de referencia distintas pginas web que
ofrecan servicios con alguna caracterstica similar al propsito de CitYsens. Una de estas pginas es
https://es.foursquare.com/.

Figura II.61. Resultados de bsqueda en Foursquare
Esta pgina permite buscar distintos servicios locales como bares, restaurantes, cines, teatros, y
todo tipo de lugares de ocio. La disposicin que hacen del mapa y de los distintos establecimientos,
la vinculacin con Facebook y su barra de bsqueda resultan muy intuitivos y sencillos de usar, por lo
que su extrapolacin a CitYsens resultaba atractiva.
En estos primeros wireframes se parti del interfaz de Foursquare y se adapt al contexto de
CitYsens. En vez de ofrecer establecimientos de ocio, se ofrecen eventos e iniciativas que tienen lugar
en algn municipio. Se incluye una barra de bsqueda y un mapa donde aparecen los distintos
eventos registrados.

Figura II.62. Pgina principal de CitYsens en las primeras aproximaciones del diseo
En la figura anterior se muestra la pantalla de bienvenida, donde aparecen una serie de
estadsticas sobre la actividad reciente del sistema, as como comparativas entre municipios y sus
usuarios registrados y no registrados.
La barra de bsqueda representa el elemento central y punto de partida para que los usuarios
comiencen a interactuar con la aplicacin. Tambin se permite navegar directamente sobre el mapa
para acceder manualmente a alguna zona concreta, de manera que al hacer clic sobre el mapa se
desplaza la barra de bsqueda a un lateral y aparecen los controles del mapa.
Realizada una bsqueda, se muestra la pantalla con los resultados de bsqueda. La barra de
bsqueda dispone de diferentes filtros de bsqueda a aplicar por el usuario. Utilizando dichos filtros
se pueden mostrar u ocultar los eventos que aparecen en el mapa y en la lista de la izquierda.


Figura II.63. Pgina mostrando resultados de bsqueda
En el mapa se utilizan diferentes marcadores para sealar los eventos que se encuentran en la
zona mostrada. El mapa dispone de un control temporal que se utiliza para definir el periodo de
tiempo del que se muestran eventos. Si el control se desplaza a izquierda o derecha, se cargarn
eventos ya acontecidos en el pasado o eventos que tendrn lugar en el futuro, estableciendo las
fechas lmite a mostrar (fecha inicial y final).
En el rea de la izquierda aparecen los eventos a modo de tarjetas con la informacin bsica de
cada evento. Para cada evento se muestra un pequeo icono que seala la categora a la que
pertenece el evento. Se incluye adems el ttulo, la fecha, la hora, una breve descripcin y una serie
de indicadores de popularidad y seguimiento del evento, en base a la relacin de los usuarios con el
mismo. Cada evento dispone tambin de botones para vincularlo con otros sistemas (email,
Facebook, Twitter, etc.). Por ltimo existen botones para seguir el evento (se guarda en tus intereses
y tienes acceso desde tu perfil) y para guardar el evento en tu lista de eventos.
La pantalla se corresponde con la de un usuario no registrado, por lo que las acciones para seguir
un evento, guardarlo o participar llevarn a una pantalla de registro o inicio de sesin para poder
continuar con la accin. En la barra superior no aparecen datos del usuario, al tratarse de un usuario
no registrado. Para usuarios registrados se dise una pantalla similar en la que la barra muestra
distintos enlaces para el perfil actual.

Figura II.64. Barra superior para un usuario registrado en CitYsens
Esta barra contiene iconos para indicar notificaciones nuevas para el usuario. Modificaciones
sobre eventos que el usuario sigue, tiene guardados, de los que es participante o interacciones que
mantiene con otros usuarios. Se presentan controles para editar el perfil, llevar a cabo
configuraciones o ir a su pgina de inicio personal.
2.4.2 Casos de uso
Como se coment en secciones anteriores del documento, a la hora de afrontar el diseo se
decidi organizar los wireframes en base al caso de uso que representan. De esta manera, es posible
ir definiendo los flujos que seguir la aplicacin de manera ordenada y coherente.
En el momento de la redaccin de este proyecto de fin de carrera, existen 6 versiones de
wireframes (de la 0 a la 5) en las que se puede observar cmo se fueron modificando y aadiendo
wireframes a medida que se consolidaban las distintas versiones. Por motivos de claridad, en la
siguiente seccin se utilizar un punto para describir cada wireframe de la versin actual (Versin 5).
Dentro de la seccin de cada wireframe, se detallar la evolucin del mismo a lo largo de todas las
versiones en las que ste aparece.
Todos los wireframes descritos a partir de esta seccin del documento presentarn casos de uso
para un usuario no registrado en el sistema. Existirn diferentes variantes en los flujos de la
aplicacin cuando el usuario est registrado en CitYsens, pero no forman parte del mbito de este
documento.
2.4.2.1 Eventos Listado
En este caso de uso, el usuario no registrado acaba de acceder a la pgina web de CitYsens. Este
wireframe forma parte de todas las versiones, al ser el punto de partida y el caso de uso principal.
Versin 0
Tras el anlisis del uso que hacen los usuarios de la Agenda del Henares, se observ que el mapa
era poco utilizado por lo que se opt por reubicarlo no ya como el rea central, sino como otro panel
que aporta informacin sobre los eventos.
En esta versin se dispuso un rea para la lista de eventos, un rea para el mapa y una nueva
zona para mostrar detalles del evento seleccionado.
Existe a la izquierda del mapa un panel con distintos filtros a aplicar para determinar qu eventos
se muestran, tanto en el mapa como en la lista de eventos.

Figura II.65. Pgina inicial de CitYsens. Versin 0
Versin 1
En su versin 1, este wireframe sufri las siguientes modificaciones:
La barra superior se adapt para la de un usuario no registrado.
El control con los filtros se oculta, de manera que para mostrarlo se debe pulsar el botn
Filtros situado en la barra superior al lado del cuadro de bsqueda.
Ya que es la pgina de bienvenida y por lo tanto no se ha seleccionado ningn evento, se
muestran estadsticas de los municipios y su actividad en CitYsens.

Versin 2
En esta versin, el wireframe sufri numerosas modificaciones:
Se reubica por ltima vez el mapa, haciendo que la lista de eventos ocupe toda la parte
izquierda de la pantalla, mientras que el mapa se desplaza a la esquina superior derecha,
con un panel de usos mltiples debajo.
Desaparece el botn Suscribirse de la barra superior, para situar un control justo
debajo de dicha barra, por encima de la lista de eventos (Recibir por correo).
Se aade un control para reordenar los eventos atendiendo a distintos criterios. Por
defecto los eventos se ordenan por fecha, agrupados en das, pero mediante este control
se pueden reordenar los eventos en base a la Temperatura (actividad del evento),
Afinidad (para usuarios registrados), Temtica y Lugar.
Aparece un control debajo de la barra superior y encima de los eventos que implementa
distintos filtros. El primer botn sirve para cambiar el modo de visualizacin entre
eventos o entidades. El control de eventos permite mostrar eventos puntuales (rojo),
eventos peridicos (azul) o iniciativas (amarillo). Los eventos en la lista aparecen
coloreados de acuerdo a estos criterios, para una rpida identificacin.
Aparece el botn para proponer un evento bajo la lista de eventos.
Cada evento en la lista incluye botones para expresar apoyo o desinters de manera
general. Tambin disponen de un icono (termmetro) que mide la temperatura de
dicho evento. La temperatura ser un indicador calculado a partir del nmero de
visualizaciones, votos a favor y en contra, nmero de veces compartido en redes sociales,
seguimiento y otros factores. Por ltimo se detallan hora, municipio, ttulo, descripcin y
una pequea imagen.
El mapa gravita en torno a un territorio central que ha sido seleccionado. Cada municipio
presenta un nmero que representa la cantidad de eventos que tienen lugar en dicho
municipio (y que cumplen los dems filtros y criterios activos). Se muestran los eventos
para todos los municipios colindantes al seleccionado.
En el panel situado debajo del mapa se mostrarn los detalles de un evento seleccionado,
as como mensajes de ayuda y otras informaciones.

Versin 3
Esta versin del wireframe trajo consigo algunos cambios menores:
Centrada la barra de bsqueda para que los filtros que se apliquen aparezcan justo
debajo, en el rea blanca entre los controles de eventos/entidades y el botn Recibir
por correo.
Reubicado el control para reordenar los eventos. Ahora aparece junto a los controles de
eventos/entidades.
El mapa incluye un nuevo botn para mostrar una vista ampliada del mismo.

Versin 4
En esta nueva versin se incluyeron los cambios:
El control para reordenar eventos est ahora ubicado en la barra superior, al lado del
cuadro de bsqueda.
El control para filtrar eventos/entidades ha sido dividido para mayor claridad. Ahora se
incluyen en la barra superior tres botones, Eventos, Procesos y Orgs. Si se hace clic
en alguno de ellos se muestran las entidades correspondientes:
o Eventos muestra la lista de eventos y despliega sus opciones, que ahora
incluyen eventos puntuales y peridicos.
o Procesos muestra eventos que tienen forma de iniciativas (larga duracin en el
tiempo).
o Orgs despliega las entidades responsables de algn evento, que pueden ser
instituciones, organizaciones o colectivos.
El botn de Propn un evento se coloca junto al botn de Recibir por correo con un
formato similar.
Se colocan los botones para apoyar o rechazar un evento debajo del indicador de
temperatura del evento con iconos de flecha hacia arriba o hacia abajo.
Los eventos indican su tipo (puntuales o peridicos) mediante una barra de color a la
izquierda, en vez de coloreando el evento entero.


Versin 5
Para la ltima versin se implementaron los siguientes cambios:
Se cambian los iconos para el filtrado de eventos, entidades e iniciativas para ser ms
descriptivos, as como los iconos de los tipos de evento (puntual y peridico).
Se incluye en cada evento el icono que representa el tipo de evento. De esta manera
queda mucho ms claro qu hace el control y se ve a simple vista de qu tipo es cada
evento. Se mantiene el cdigo de colores de momento.
Desaparece el botn para rechazar un evento. Se opta por dejar nicamente el botn
para apoyar eventos y evitar as posibles conflictos que puedan surgir por el mal uso de
dichos controles.


2.4.2.2 Eventos Botn Ordenar Por
En este caso de uso, el usuario no registrado hace clic sobre el control Ordenar Por para
establecer un criterio de ordenacin de los eventos. Este wireframe aparece por primera vez en la
versin 3 con el fin de definir el comportamiento de dicho control. Las variaciones entre versiones
son mnimas, el wireframe evoluciona para mostrar el resto de la pantalla de manera coherente a
cada versin.
Versin 3
Al ser pulsado, el botn muestra una lista desplegable con las distintas posibilidades,
Temtica o Lugar.

Figura II.71. Pantalla cuando el usuario hace clic sobre el control Ordenar por". Versin 3
Versin 4
El control se encuentra al lado de la barra de bsqueda. Se eliminan los iconos para hacer
ms compacto el diseo y se aade la opcin Fecha (para volver a la ordenacin por
defecto).

Figura II.72. Control "Ordenar por". Versin 4
Versin 5
Esta versin no presenta diferencias con la anterior, en lo que a este control se refiere.

Figura II.73. Control "Ordenar por". Versin 5
Existen dos variantes de este wireframe, que se corresponden con la pantalla de listado de
eventos una vez que se ha seleccionado uno de los criterios de ordenacin. Estos wireframes no han
sufrido cambios desde la versin 3 hasta la 5.

Figura II.74. Eventos ordenados por temtica. Versin 3

Figura II.75. Eventos ordenados por lugar. Versin 5
2.4.2.3 Eventos Mapa
En este caso de uso, se agrupan varios wireframes que hacen referencia a la utilizacin de los
controles del mapa por parte del usuario no registrado. Este wireframe aparece por primera vez en la
versin 3 con el fin de definir el comportamiento de dicho control. No existen diferencias entre las
versiones, por lo que se muestran a continuacin los distintos wireframes.
Clic en otro municipio
Este wireframe muestra cmo el mapa se centra en otro municipio cuando el usuario hace clic
sobre uno de los municipios adyacentes. El crculo que muestra el nmero de eventos pasa a
oscurecerse, indicando en qu municipio se est centrando el mapa. Tambin se actualiza el
breadcrumb situado encima del mapa, indicando que se muestra un municipio y sus alrededores
(denotado por el smbolo +).

Figura II.76. Vista del mapa al seleccionar un municipio adyacente

Clic en control +
Cuando el usuario hace clic para incrementar el nivel de zoom, el mapa ampla la vista del
municipio, y pasa mostrar distritos del mismo, junto con la cantidad de eventos de cada uno. El
control de zoom in (+) se pinta gris para indicar que no se puede ampliar ms la vista. Se actualiza
el breadcrumb.

Figura II.77. Vista del mapa al ampliar el zoom a nivel de municipio
Clic en control -
Cuando el usuario hace clic sobre el control - para reducir la vista del mapa, es llevado a un
nivel superior, en este caso, de zonas de Madrid. Este wireframe an plantea dudas al equipo de
diseo de cara a la visualizacin. Con esta representacin no queda demasiado claro el mapa.

Figura II.78. Vista de la comunidad de Madrid y sus diferentes zonas
2.4.2.4 Eventos Seleccionado un evento
En este caso de uso, el usuario no registrado hace clic sobre uno de los eventos de la lista.
Aunque este wireframe existe desde la versin 3, no es hasta la versin 5 cuando se refina y adeca
su aspecto. En las versiones anteriores se mantena la vista de evento de los primeros diseos
borrador.
Versin 5
El wireframe dispone los siguientes controles:
El evento seleccionado en la lista se muestra en color azul, y aparece en el mapa un
marcador sealando su localizacin. Si el usuario sigue moviendo el ratn sobre otros
eventos, estos se colorean de un azul ms claro y el marcador del mapa para estos
eventos tiene el color acorde.
El evento contiene un rea principal donde se muestran todos los detalles y un control a
modo de ndice a la derecha, que permite navegar por las secciones as como indicar la
seccin mostrada en cada momento.
La seccin Resultados aplicar a eventos que ya han acontecido.
Existe un botn para maximizar el evento y disponer de la informacin a pantalla
completa.
El evento incluye su ndice de temperatura, as como el botn para apoyar el evento.
Se disponen tambin botones para compartir el evento en distintas redes sociales, as
como botones para guardar el evento en la lista personal (usuarios registrados) o
seguirlo.
Para eventos peridicos, se mostrar cada cunto acontece el evento (cada semana, cada
mes, etc.).

Figura II.79. Pantalla con un evento seleccionado. Versin 5
2.4.2.5 Eventos Expandido un evento
En este caso de uso, el usuario no registrado hace clic sobre el control para expandir un evento
seleccionado y pasar de su vista reducida a una vista a pantalla completa. Este wireframe aparece en
las versiones 4 y 5.
Versin 4
En esta versin se crea el wireframe, de manera que la vista expandida consiste en un pop-up
que se muestra con la misma informacin que la versin reducida.

Figura II.80. Evento expandido. Versin 4
Versin 5
En referencia a la versin anterior, esta muestra los siguientes cambios:
Se introduce un mini mapa, utilizando un marcador para sealar la localizacin del
evento.
Se sita el icono indicando el tipo de evento (puntual o peridico) en la esquina inferior
izquierda, as como el control para apoyar el evento.
Se actualizan los controles para redes sociales, mostrando ahora la cantidad de veces que
ha sido compartido el evento en cada una de ellas.

Figura II.81. Evento expandido. Versin 5
2.4.2.6 Eventos Ocultar eventos peridicos
Este wireframe pretende describir la situacin en la que el usuario hace clic sobre el botn de
ocultar eventos peridicos. El control adquiere un tono transparente cuando estn ocultos dicho tipo
de eventos, y su color normal cuando stos se muestran. La finalidad de la pantalla es describir el
funcionamiento general de los botones para mostrar u ocultar los distintos tipos de eventos o
entidades.
Aunque el wireframe aparece por primera vez en la versin 3, no sufre cambios en las siguientes
versiones. Existe en versiones posteriores a la 3 para adaptar el diseo de la pantalla a las
modificaciones generales sufridas.
Versin 5
Las principales caractersticas son:
El botn de eventos peridicos pasa de ser completamente visible a tener cierto grado de
transparencia, indicando que dicho tipo de eventos no se incluyen en la lista.
En la lista de eventos, al final de cada grupo de eventos (pueden estar agrupados por
fecha, por temtica o por municipio) se indica la cantidad de eventos peridicos que
contiene, aunque no se muestren. De esta manera al usuario le resulta ms claro percibir
que no est listando dicho tipo de eventos.
Al pulsar el botn, los eventos desaparecern con una transicin para hacer an ms
obvio el cambio que provoca dicho control sobre la pgina.

Figura II.82. Lista de eventos, ocultados los eventos peridicos. Versin 5
2.4.2.7 Eventos Barra de bsqueda
Este conjunto de wireframes pretende definir el funcionamiento que tendr la barra de bsqueda
y todas las posibilidades que ofrece. Aunque las primeras variantes aparecieron sobre la versin 4, es
en la siguiente versin donde se definen todos los flujos posibles de manera exhaustiva, por lo que se
mostrarn todos los wireframes de esta ltima versin.
Versin 5
El primer wireframe describe el funcionamiento de la barra de bsqueda cuando el usuario
comienza a escribir:
A medida que el usuario escribe, se van ofreciendo posibles categoras, etiquetas,
lugares, entidades y trminos de bsqueda. Cada sugerencia va precedida de un icono
descriptivo que indica si es trmino de bsqueda, temtica, lugar, etc. Al seleccionar
alguna se aplicar como un filtro y se mostrarn solo aquellos eventos que incluyan el
texto buscado en su ttulo o descripcin, o afecten a la organizacin seleccionada, tengan
lugar en el territorio seleccionado, etc.
Se dispone un botn X para borrar el trmino de bsqueda.
Se permite navegar por las sugerencias utilizando el teclado para hacer ms rpido el
control.

Figura II.83. Barra de bsqueda ofreciendo sugerencias en base al texto introducido. Versin 5
Las sugerencias son contextuales, estn relacionadas con el mbito en el que se encuentra el
mapa. Por ello, solo se ofrecern lugares, municipios y organizaciones incluidas dentro del rea
monitorizada. Si el texto que comienza a escribir el usuario se corresponde con el nombre de un
territorio que no corresponde con el mbito seleccionado, se incluir una celda especial Ir a X que
equivale a navegar en el mapa para ir hasta el territorio en cuestin.

Figura II.84. Sugerencia "Ir a" para otras zonas. Versin 5
Si el usuario pulsa sobre la flecha ubicada a la derecha en el cuadro de bsqueda cuando esta se
encuentra vaca, se despliegan las opciones de bsqueda avanzada:
El desplegable permite aplicar varios criterios de bsqueda simultneamente. Si se haba
introducido algn texto antes de mostrar el control, ste se pre-inserta en el campo
contiene palabras.
Los campos de Organizador, Lugar y Temtica / Etiqueta ofrecen sugerencias a
medida que se va escribiendo en ellos. Si se selecciona alguna de las sugerencias, sta
aparece en el cuadro seguida de una coma, y el usuario puede seleccionar otras.
El campo en edicin actualmente se resalta en color azul.
El control temporal aparece en la parte inferior. Permite desplazar dos controles para
seleccionar fechas inicial y final como criterio de bsqueda.
El desplegable de bsqueda avanzada se puede cerrar haciendo clic sobre el botn X
situado en la esquina superior derecha.


Figura II.85. Control de bsqueda avanzada. Versin 5
Por ltimo, se crearon diferentes wireframes para describir el aspecto de la pantalla para los
resultados de bsqueda:

Figura II.86. Resultados de bsqueda con la temtica "Sanidad". Versin 5

Figura II.87. Resultados de una bsqueda por texto. Versin 5
Los resultados de bsqueda se aplican a la lista de eventos y a la informacin representada en el
mapa, de manera que ambas informaciones son afectadas por los filtros.
2.4.2.8 Eventos Botn Propn un evento
El presente wireframe pretende describir el flujo que sigue la aplicacin una vez que el usuario
hace clic sobre el botn para proponer un evento. La funcionalidad de este botn es similar a la del
de la Agenda del Henares; los usuarios son los que proponen los eventos que, una vez aprobados,
sern publicados.
Para este caso de uso se utilizan distintos wireframes que describen los controles involucrados. El
grupo de wireframes aparece por primera vez en la versin 5.
Versin 5
El botn despliega un pop-up que muestra el formulario con los campos a rellenar, necesarios
para un nuevo evento:
Por defecto todos los campos se encuentran vacos y en color rojo, indicando que no han
sido editados an.
El pop-up se puede cerrar pulsando fuera del mismo, utilizando el botn Cancelar o el
botn X (situado en la esquina superior derecha).

Figura II.88. Pgina para proponer un evento en CitYsens. Versin 5
Cada vez que se hace clic sobre un campo, este cambia su fondo a blanco para indicar
que se est editando el mismo.
El campo de ttulo es un texto sin mayores restricciones.
El campo Temtica permite introducir temticas de las que existen en el sistema o
teclear textos nuevos a modo de etiquetas. Al hacer clic sobre dicho campo se despliega
una lista con las temticas disponibles y, a medida que el usuario va tecleando, se van
filtrando las temticas que coinciden con el texto.

Figura II.89. Introducido un ttulo y desplegado el control de temtica. Versin 5
Las temticas y etiquetas se van aadiendo en el rea debajo del ttulo. Cuando se ha
aadido al menos una temtica, el campo aparece con lnea discontinua y de color
blanco para indicar que ya no se tienen que aadir ms (de manera obligatoria), pero que
es posible.
Las temticas seleccionadas de entre las predefinidas aparecern con su icono
correspondiente, mientras que las etiquetas introducidas manualmente irn precedidas
del smbolo #.
Para seleccionar la fecha del evento, al hacer clic en el campo Fecha se despliega un
calendario en el que se pueden seleccionar nicamente fechas futuras.
La hora de finalizacin del evento es un campo opcional que no tiene por qu estar
definido. Se aadi atendiendo a la encuesta realizada con los pioneros en el grupo de
Facebook sobre los campos a guardar de un evento.
Cuando se hace clic sobre el campo Descripcin aparece una herramienta para la
edicin del texto de manera cmoda y sencilla.

Figura II.90. Editando la descripcin. Introducidas temticas, etiquetas, fecha y hora
Los campos inferiores para el sitio web del evento y el correo de contacto contienen
comprobaciones sintcticas para verificar direcciones web y de correo electrnico.
El usuario puede buscar un lugar sobre el control del mapa. A medida que teclea, se le
ofrecen lugares de entre los que ya existen en el sistema.
Si el usuario hace clic sobre el mapa o alguno de sus controles, el cuadro de bsqueda se
desplaza para no entorpecer la navegacin.

Figura II.91. Barra de bsqueda en el mapa sugiriendo localizaciones existentes. Versin 5

Tanto si el usuario busca una direccin nueva como si navega por el mapa y hace clic
sobre una direccin concreta como si selecciona uno de los lugares existentes, aparecer
un marcador en dicha ubicacin. En este punto, se despliega un pop-up que pregunta al
usuario si desea utilizar ese lugar para el evento.
Hecha una bsqueda, el cuadro de bsqueda se desplaza a la parte superior.

Figura II.92. Pop-up para seleccionar el lugar para el evento. Versin 5
Si el usuario pulsa S en el pop-up del wireframe anterior, el lugar se establece,
quedando el marcador en dicha localizacin y actualizndose el panel con la direccin
para el evento.
Si el usuario pulsa No, el pop-up desaparece y se permite la navegacin/bsqueda por
el mapa nuevamente.


Figura II.93. Formulario completado. Versin 5
2.4.2.9 Entidades Listado
Este caso de uso describe a un usuario que hace clic sobre el botn Entidades de la barra
superior y llega a la pantalla de entidades. Se trata de un listado, similar al que se hace con los
eventos, pero mostrando las distintas instituciones, organizaciones y colectivos registrados en el
sistema.
Aunque existe desde la versin 2, las modificaciones que ha ido sufriendo este wireframe han
sido en cuanto al aspecto general de la pantalla, sin nuevas funcionalidades. Se procede por lo tanto
a describir el wireframe en su ltima versin.
Versin 5
Las caractersticas de esta pantalla son:
Al igual que suceda con los eventos, las entidades se dividen en una serie de tipos
(Instituciones, Organizaciones y Colectivos), que se asocian con un color. Tanto las
entidades de la lista como los iconos para filtrar se corresponden con el color para una
rpida identificacin.
Cuando el usuario hace clic sobre el botn Entidades de la barra superior, accede a la
lista de entidades y se despliegan los tres botones para mostrar/ocultar algn tipo de
entidad. El funcionamiento es similar al de los eventos, cuando se oculta algn tipo, su
icono aparece transparente.
Las entidades dispondrn de un parmetro Karma o alguna nocin que permita
determinar qu entidades son ms activas, tienen ms movimiento, seguidores, etc. Es
una nocin similar a la temperatura de un evento, pero aplicado a las entidades.
Las entidades se muestran ordenadas por este atributo Karma por defecto, aunque se
pueden ordenar en base a afinidad (usuarios registrados), temtica (los eventos
relacionados con la entidad) y lugar.
El mapa pasa a reflejar la cantidad de entidades de cada zona visualizada, manteniendo
el mismo control de mbito que tuviera antes.

Figura II.94. Pantalla de entidades. Versin 5

Conclusiones
Resumen
A lo largo del presente documento se han descrito la organizacin, las herramientas y los
procesos seguidos en las fases de anlisis y diseo para la construccin de CitYsens. Si bien el sistema
objetivo es muy ambicioso en sus mbitos y objetivos, con un desarrollo abierto y colaborativo se
pueden conseguir los objetivos fijados, en un proceso de constante mejora y renovacin.
Al ser un sistema creado para ayudar a la sociedad y a los ciudadanos, el modelo de cdigo
abierto y software libre en el que se desenvuelve el mismo resulta la opcin ptima, prescindiendo
as de organizaciones o empresas privadas, que puedan tener distintos intereses en la codificacin
del sistema ms all del beneficio social.
Esta misma caracterstica provoca a su vez que el avance sea ms lento, al complicarse un poco la
coordinacin y al disponer de recursos muy limitados. Con una cabeza pensante detrs del proyecto
con una visin clara y una dedicacin y motivacin absoluta como la de Pedro Prieto Martn
(presidente fundador de la Asociacin Ciudades Kyosei), los esfuerzos no resultan en balde, y el
equipo de personas del que dispone para gestionar los distintos mbitos del proyecto hacen que
todo resulte mucho ms sencillo an.
Para el anlisis se ha dispuesto un objetivo bsico a cumplir con los primeros prototipos de
CitYsens; superar a la Agenda del Henares. Superarla en funcionalidad, utilidad, usabilidad, nmero
de usuarios, difusin y en todos los aspectos donde sea posible mejorar. Se ha llevado a cabo por ello
el anlisis exhaustivo del funcionamiento de la Agenda, as como de los mtodos que emplea para
llevar a cabo dicho funcionamiento. Este anlisis permite tener un punto de partida para disear
CitYsens, mejorando puntos que no resultan del todo claros o correctos en su implementacin a la
par que innovando en las reas donde se cree necesario y pertinente.
La fase inicial de diseo se ha centrado siempre en la interfaz del usuario, teniendo como
objetivo mximo la usabilidad y utilidad del sistema. Es a partir de estos diseos, mejorados
iterativamente en diferentes versiones, desde donde se podr comenzar un diseo ms tcnico en
cuanto a la codificacin del sistema se refiere. Aunque el diseo grfico definitivo se ponga en manos
de personal cualificado a tales efectos, este diseo inicial permite concretar cmo se pondrn a
disposicin de los usuarios las distintas funcionalidades, construyendo as una visin del sistema ms
concreta y especfica, no tanto as como de qu servicios se quieren ofrecer, sino de cmo ofrecerlos.
Grado de cumplimiento de los objetivos
La finalidad de este documento era describir y documentar los procesos seguidos en el marco de
un desarrollo abierto para la construccin del sistema informtico CitYsens.
Los objetivos han sido cumplidos con un alto grado de satisfaccin por parte del autor, al haberse
llevado a cabo de acuerdo a la planificacin y a la satisfactoria experiencia que ha supuesto la
elaboracin de este proyecto de fin de carrera. Se han vivido los distintos problemas a ir solventando
en un desarrollo informtico de estas caractersticas, as como la gratificacin de ir completando las

distintas fases de construccin del sistema. Los retos que plantea un sistema como el aqu descrito,
poco tienen que ver con los que se encuentran en un diseo de software propietario, donde se
dispone de gran cantidad de recursos, se persigue un fin monetario por lo general y por lo tanto se
tiene especial atencin y rigurosidad en la especificacin y verificacin de los requisitos.
La experiencia de haber sido parte del proceso de creacin resulta muy realizadora, y no
terminar con la elaboracin del presente documento. An queda un largo camino por recorrer en la
creacin de CitYsens, y debemos construirlo con ayuda de todos.

Bibliografa
Quines somos? (2013). Recuperado el Mayo de 2014, de Agenda del Henares:
http://agendadelhenares.org/quienes-somos
AWStats. (s.f.). Recuperado el Mayo de 2014, de Pgina oficial de AWStats: http://awstats.sourceforge.net/
Balsamiq Mockups. (s.f.). Recuperado el Mayo de 2014, de Pgina oficial de Balsamiq: http://balsamiq.com/
Codecademy. (s.f.). Recuperado el Mayo de 2014, de Pgina oficial de Codecademy:
http://www.codecademy.com/tracks/php
Criterios de Publicacin. (2013). Recuperado el Mayo de 2014, de Agenda del Henares:
http://agendadelhenares.org/criterios-publicacion
Firebug. (s.f.). Recuperado el Mayo de 2014, de Pgina oficial de Firebug: https://getfirebug.com/
Hernando Garca, S. (2013). Kyopol Ciudad Simbitica. Recuperado el Mayo de 2014, de Kyopol Ciudad
Simbitica: http://www.kyopol.net//docs/TFC-ConstruccionColaborativaSistemaKyopol.v.7.pdf
Kyopol Ciudad Simbitica. (s.f.). Recuperado el 2014, de http://www.kyopol.net/
Kyopol Ciudad Simbitica. (s.f.). Recuperado el Mayo de 2014, de Pgina oficial de la Asociacin Ciudades
Kyosei: http://www.kyopol.net/la-asociacion/quien-somos/colaboradores/
Pgina principal de la Agenda del Henares. (2013). Recuperado el Mayo de 2014, de Agenda del Henares:
http://agendadelhenares.org/
phpMyAdmin. (s.f.). Recuperado el Mayo de 2014, de Pgina oficial de phpMyAdmin:
http://www.phpmyadmin.net/home_page/index.php
Prieto Martn, P. (s.f.). Kyopol Ciudad Simbitica. Recuperado el 2014, de Kyopol Ciudad Simbitica:
http://www.kyopol.net/proyectos/proyecto-kyosei-polis/
W3Schools. (s.f.). Recuperado el Abril de 2014, de Pgina oficial de W3Schools: http://www.w3schools.com/PHP/
WampServer. (s.f.). Recuperado el Febrero de 2014, de Pgina oficial de WampServer:
http://www.wampserver.com/en/
XDebug. (s.f.). Recuperado el Abril de 2014, de Pgina oficial de XDebug: http://xdebug.org/

Trabajo Fin de Carrera - Diseño y Desarrollo Del Sistema CitYsens para La Eparticipación Municipal

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Trabajo Fin de Carrera - Diseño y Desarrollo Del Sistema CitYsens para La Eparticipación Municipal

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDAD DE ALCALA

Escuela Polite cnica Superior

Anda mungkin juga menyukai