Breve presentación de BLV AuzolaneanBreve 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

Propuesta de Ricardo Antón

Componentes en el grupo:

Ricarddo Antón (ColaBoraBora)
Mar Núñez (noez | oficina de diseño para la innovación social)
Rossana
Jongo
Ekaitz Zárraga (EllenQ)

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:

1. Las herramientas no deben sustituir al encuentro
2. Conservar los puntos de “roce” humano

Contemplar la diversidad de gentes, sobre todo en dos niveles: Vecinas y colectivos.

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.

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”:

1. En un entorno medio:
   1. trabajar sobre wordpress, implementando plugins, algunos libres y otros bajo licencia, para resolver algunas funcionalidades como el Mapa/Directorios/Filtros o el calendario compartido

(Se citan otras soluciones de mapeado como CIVIS, USHAIDI, UMAP. Se necesita exploración específica)

1. (continua)
   1. Puede haber puntos de salida del wordpress a otras herramientas específicas para gestión de Banco de tiempo o Biblioteca de las cosas.
   2. El repositorio podría tener una expresión interna en WP, en forma de catálogo.
   3. PUNTOS FUERTES: usabilidad y curva muy suave de aprendizaje en wP (muy amable para usuarias no expertas) y contención presupuestaria.
2. En un entorno de presupuesto alto (por definir):
   1. Trabajar sobre Drupal, implementando plugins y programando a demanda
   2. PUNTOS FUERTES: Robustez del sistema de usuarias, mayor escalabilidad.
   3. 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).

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)

1. E. dispone de un conjunto de sillas para prestar
2. M. tiene una asociación y necesita 10 sillas para un acto público en su local
3. 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.)
4. M. abre una ventana de mensajería instantánea (p.e.) que presupone:
   1. M. está identificada por su @user de modo que E. puede conocer (yendo a la ficha) quién le pide el recurso.
   2. 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.
   3. 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.
   4. 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

¿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.

• 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/