Diferencias

Muestra las diferencias entre dos versiones de la página.

--- datospoder:blv_auzolanean [2019/06/28 11:10] – marnunez
+++ datospoder:blv_auzolanean [2019/06/29 13:01] (actual) – [ALGUNAS PREGUNTAS Y ¿DECISIONES?] ricardo_amaste
@@ Línea 1: / Línea 1: @@
 ====== BLV Auzolanean ======
+Breve presentación de BLV Auzolanean[[https://docs.google.com/document/d/10lnxrz0A1MJaGyFBjP2bsvlhihuRFhOiMMNdDE5oRIY/edit|Breve presentación de BLV Auzolanean]]
 Proyecto para el diseño de una infraestructura digital barrial para:
   * identificar + visualizar
   * conectar + compartir
 entre agentes, vecinas y recursos en el barrio de //Bilbao la vieja//
@@ Línea 10: / Línea 11: @@
 **Componentes en el grupo:**
-Ricarddo Antón\\
-Mar Núñez\\
+Ricarddo Antón (ColaBoraBora)\\
+Mar Núñez (noez | oficina de diseño para la innovación social)\\
 Rossana\\
 Jongo\\
-Ekaitz Zárraga
+Ekaitz Zárraga (EllenQ)
 ===== OBJETIVO =====
-==== ¿Cómo haríamos para fomentar los lazos y la intercooperación entre agentes y vecinas en el barrio mediante el uso de herramientas digitales? ====
+==== ¿Cómo haríamos para fomentar los lazos y la intercooperación entre agentes y vecinas en el barrio mediante el uso de herramientas digitales? (Lo digital cualifica y facilita, no suplanta)====
 ===== RETO =====
-Conseguir que más gente utilice estas herramientas más allá del momento de su presentación. O dicho de otra forma, conseguir que las herramientas aporten valor a las formas físicas de relación sin erosionar estas: \\  -
+Conseguir que más gente utilice estas herramientas más allá del momento de su presentación.
+O dicho de otra forma, conseguir que las herramientas aporten valor a las formas físicas de relación sin erosionar estas: \\
   - Las herramientas no deben sustituir al encuentro
   - Conservar los puntos de "roce" humano
+===== USUARIAS TIPO =====
+Contemplar la diversidad de gentes, sobre todo en dos niveles: Vecinas y colectivos.
+===== ESTADO ACTUAL DE LA CUESTIÓN =====
+** Herramientas ya en uso**\\
+RIE: listado de recursos para compartir, escrito en un wordpress + una lista de correo.\\
+BANCO DE TIEMPO: Time Overflow (herramienta de gestión específica)
+**Herramientas deseables**\\
+MAPA: ubicar agentes sobre base cartográfica + directorio (fichas correspondientes a cada agente) + Filtros de búsqueda.
+AGENDA COMÚN: podría tener la forma de un calendario de actividades conjunto, quizá con capas que filtren tipologías de eventos o de agentes.
+**Necesidades estratégicas**\\
+Liberar al menos a una persona para:\\
+  * gestionar la herramienta
+  * dinamizar la interacción entre usuarias
+  * formar a usuarias en el uso y administración de sus fichas/calendario etc.
+===== 1ª APROXIMACIÓN TECNOLÓGICA =====
+Exploramos dos vías posibles:
+a) INTEGRAR \\
+Tender a reunir todas las funcionalidades deseadas en una herramienta única:
+  * Desarrollar sobre estándares para asegurar el mantenimiento en el tiempo
+  * Hacer pequeños desarrollos "ad hoc" para funcionalidades específicas y/o integración
+Vemos dos niveles "presupuestarios":
+  - En un entorno medio:
+    - trabajar sobre wordpress, implementando plugins, algunos libres y otros bajo licencia, para resolver algunas funcionalidades como el **Mapa/Directorios/Filtros** o el **calendario compartido**
+^ Plugin Mapas    ^
+| Geo Directory   |
+| WP Map    |
+(Se citan otras soluciones de mapeado como CIVIS, USHAIDI, UMAP. Se necesita exploración específica)
+  - (continua)
+    - Puede haber puntos de salida del wordpress a otras herramientas específicas para gestión de Banco de tiempo o Biblioteca de las cosas.
+    - El repositorio podría tener una expresión interna en WP, en forma de catálogo.
+    - PUNTOS FUERTES: usabilidad y curva muy suave de aprendizaje en wP (muy amable para usuarias no expertas) y contención presupuestaria.
+  - En un entorno de presupuesto alto (por definir):
+    - Trabajar sobre Drupal, implementando plugins y programando a demanda
+    - PUNTOS FUERTES: Robustez del sistema de usuarias, mayor escalabilidad.
+    - RETOS: sería estrategico desarrollar (programando) un "dashboard" o panel de usuaria para mejorar la usabilidad de Drupal (claramente inferior que la de wordpress)
+a) ARTICULAR LO QUE YA HAY (CON ADICIONES) \\
+En otra aproximación más sencilla, con poco presupuesto, se podría anteponer una página distribuidora (a la manera de un PORTAL) al conjunto de herramientas dispersas, bien en servidor propio o bien en servicios de terceros (google, OpenStreetMaps, etc).
+===== VISIÓN DEL PRODUCTO =====
+Nos aproximamos al producto atendiendo al objetivo de poner las formas de encuentro humano en el centro.
+**Situaciones/ lugares de encuentro físico**
+  * Locales de asociaciones
+  * Espacio público (calles, plazas, etc)
+  * Bares
+  * - - -
+  * Préstamo de materiales (P2P)
+  * Asistir a la actividad de otro colectivo (unidireccional)
+  * Organizar una actividad conjunta (P2P)
+  * Organizar las fiestas del barrio (múltiples agentes)
+  * Banco de tiempo (relación circular)
+**Casos de uso**\\
+(A modo de ejemplo, un uso que protege la relación por encima de la "prestación de servicio" de una forma más clientelar)
+  - E. dispone de un conjunto de sillas para prestar
+  - M. tiene una asociación y necesita 10 sillas para un acto público en su local
+  - M. entra en la web, localiza el recurso puesto a disposición en el catálogo y quiere ponerse en contacto con E. (En este punto la utilidad podría ser un proceso semejante a un carro de la compra para reservar o un calendar donde bloquear fechas, etc; pero esto enfríaria el punto de conexión entre M. y E.)
+  - M. abre una ventana de mensajería instantánea (p.e.) que presupone:
+    - M. está identificada por su @user de modo que E. puede conocer (yendo a la ficha) quién le pide el recurso.
+    - M. redacta un par de líneas para presentarse, contará para qué y cuándo usará las sillas y quizá incluso invitará a E. al acto público de su asociación.
+    - E. podría recibir adicionalmente una notificación en su panel con el mensaje, responder a M. para confirmar o intersarse por la actividad y un botón que facilita bloquear el recurso en esas fechas.
+    - M. queda con E. para ir a recoger las sillas.
+En las siguientes ocasiones en que M. vuelva a necesitar las sillas, si ya se conocen, si han intercambiado teléfonos, es posible que no utilice la web para este fín. Podríamos considerar esto un éxito.
+Pero la herramienta puede cubrir otras necesidades en derivadas de este mismo caso:\\
+  * Si la comunicación por teléfono no es posible en el momento, M. puede volver a recurrir al canal web para dejarle la información precisa a E. en espera de respuesta.
+  * M. podría usar su teléfono para hacerlo en cualquier lugar (web responsive, quizá empaquetada para móvil)
+  * M. y E. encuentran en la herramienta un espacio de representación de la identidad de barrio (reconocimiento entre vecinas) a través de la capa de diseño visual.
+**Personas implicadas y tipo de implicación**\\
+ **Ekaitz** -> Presta -> Bloquea en el Calendario \\
+ **Mar** -> Solicita -> Anota tiempo a E. en el B.T (una posibilidad para premiar a quien comparte) \\
+ AMBOS QUEDAN
+===== ALGUNAS PREGUNTAS Y ¿DECISIONES? =====
+**¿Cuantas funcionalidades integrar en una única herramienta?**\\
+  * Por un lado las funcionalidades ligadas a Mapeado/Directorio + Agenda + Noticias
+  * Por otro lado las funcionalidades de compartir: Recursos materiales / Recursos inmateriales (tiempo).
+  * Un imaginario común (visual, tipo de lenguaje...)
+**¿Qué PERFILES de usuarias? ¿Con qué ROLES?**\\
+  * El ecosistema barrial como red social.
+  * Capa física + capa digital.
+  * Si sólo se quiere ver no hace falta registrarse / Si se quiere interactuar, acceder a recursos, publicar información, hay que registrarse.
+  * Tratar de que haya un único perfil para las distintas funcionalidades-herramientas.
+**¿Queremos forzar a la gente a que utilice la herramienta o nos da igual que una vez establecido el víncuilo se mantenga la relación offline? ¿Qué incentivos encuentran las usuarias en utilizar el canal digital, mantener sus perfiles actualizados y asumir cierto nivel de burocracia?**\\
+  * La tecnología debe sistematizar algunas funcionalidades y hacerlas más sencillas y útiles.
+  * El acostumbrarse al uso de la plataforma y sus protocolos de relación debería servir para generar rutinas colaborativas más estructuradas en el entorno offline.
+===== RECOPILACIÓN DE REFERENCIAS =====
+  * Time Overflow (Bancos del Tiempo) https://www.timeoverflow.org/
+  *   Sharetribe Flex - La solución flexible del mercado. https://www.sharetribe.com/flex/ Una aplicación de esto es COMMUNIFY (desde Canarias) https://market.communify.es/
+  *   Comoodle, recursos compartidos comunidades locales. https://www.comoodle.com/
+  *   miplaza – Recupera una vida de barrio. https://miplaza.es/
+  *   Comunidad interna de Lagunkoia (muy sencilla, desarrollada por Lotura) http://lagunkoia.net/
+  *   La Escalera, dinamización comunitaria off-line (pegatinas) http://www.proyectolaescalera.org/