Blist

From Idiki

Premessa

Credo che le scelte di progettazione, specialmente quando si parla di software sociale, siano sempre scelte politiche. Non mi piacciono i giudizi funzionalistici tipo "le liste funzionano bene / le liste funzionano male". Perciò quello che segue non è una proposta per uno stumento migliore o più avanzato di quelli già esistenti, ma una proposta per uno strumento più in linea col mio sentire.

Credo che chiunque si faccia carico della progettazione di software sociale debba tener conto che non sta predisponendo uno spazio di interazione neutro ma che le sue scelte influenzeranno e stuttureranno il modo di agire delle persone che ne faranno uso.

D'altra parte dovrebbe tenere anche presente che è sempre esistito ed esisterà sempre un conflitto tra progettisti e utenti: i progettisti concepiscono software pensando ad un utente modello e le aspettative vengono deluse o talvolta eccedute dal comportamento emergente dell'utenza. Si tratta di una dialettica che dovrebbe comportare una continua ridiscussione del software e la sua modifica in funzione delle manifestazioni tecno-sociali che avvengono al suo interno. Eppure ho notato che i progettisti e gli amministratori sono in genere restii ad accettare gli utilizzi devianti dello strumento. Di solito reagiscono con la repressione o, nel caso siano inguaribili idealisti, si dedicano all'eterno lamento indymediano: appellarsi in continuazione alle policy, custom essays alla netiquette, al buon senso e ai patti sociali impliciti, flammando coi troll o facendo sprofondare la piattaforma nell'entropia.

Tutto questo per dire che il ragionamento "gli stumenti che ci sono vanno benissimo, sono gli utenti che sbagliano" mi sembra estremamente deleterio. Forse peccherò di determinismo tecnologico ma buona parte di ciò che mi irrita della comunicazione mediata "di movimento" la attribuisco all'incapacità di immaginare nuovi mezzi in relazione a mutate condizioni. Mi riferisco in particolare ad un bacino di utenza che in pochi anni è enormemente cresciuto, composto da persone dotate di una disponibilità illimitata di connettività, un approccio antiecologico alla produzione e fruizione di informazioni e prive di qualsiasi background di etica hacker (ma non per questo meno valide politicamente!). Certo, poi ci sono il riflusso, gli scazzi, i personalismi, i troll, gli infiltrati...

Finisco il pippone e passo alla proposta che contrariamente alle pretese della premessa è abbastanza banale :-P

Cos'è?

Un software per l'interazione di piccoli-medi gruppi che integra le funzioni di discussione delle mailing list con la pubblicazione dei contenuti in un blog.

Perchè?

• Per evitare il frequente scollamento fra liste e siti di gruppi e collettivi - siti spesso poco aggiornati vs liste troppo trafficate.

• Per non lasciare che la crisi del movimento e la chiusura di indymedia provochi la migrazione su piattaforme più atomizzate come i blog. Insistere sugli strumenti di discussione collettiva.

• Per dare alle mailing list una presenza pubblica in rete, facile da pubblicare e facile da gestire.

• Per dare ai visitatori non iscritti un'idea di ciò che accade all'interno della lista e magari favorirne un ingresso più "soft".

• Per distribuire il peso dell'aggiornamento del Sito Ufficiale su tutto il gruppo, attività che in genere è a carico dei membri più internettari familiari con cms etc.

• Per un'archiviazione strutturata delle mailing list che gli strumenti attuali non consentono

Come funziona?

In teoria è semplice ma non semplicissimo, NON si tratta di un blog che include tutti i messaggi di una lista una lista NE' di un blog che manda i post ad una lista di indirizzi.

Il principio è coniugare la rapidità di ricezione della mailing list (non devo andare sul blog per vedere che succede) con la modalita di pubblicazione del blog. Non invio una email in lista attraverso il client di posta elettronica ma attraverso un form di pubblicazione (previo log). Ovviamente va scapito dell'immediatezza, si tratta di due click in più rispetto alla mailing list. Chi vuole intervenire è costretto ad abbandonare lo spazio per la comunicazione personale (client email, webmail) per andare su un sito, come a ricordargli il contesto in cui l'atto enunciativo avrà luogo. Mi auguro che cio stimoli un minimo di ecologia dell'informazione.

Esempio:

L'utente Tizio vuole spedire un messaggio alla sua lista X. Va sul sito X su cui è installato blist. Si logga con la sua utenza (presumibilmente salvata in browser dopo il primo accesso). Il form di pubblicazione gli permette di scegliere se mandare il suo intervento su:

• blog e lista
• solo su lista

Per consentire un'archiviazione folksonomica, in entrambi i casi gli è richiesto di taggare l'inserimento con una o più parole chiave. Sotto il campo tags appaiono le parole chiave più usate che a grandi linee sarebbero le "tematiche" della lista. Questo per evitare strutturazioni a priori che vanno spesso a farsi fottere.

Nel caso scelga *blog e lista* ha la possibilità di inserire un'immagine che accompagni l'inserimento nella sua versione online. L'immagine è uploadata, ridimensionata e ritagliata automaticamente per il layout. Sembra una stronzata ma la tortuosa gestione delle immagini nei cms è il principale ostacolo ai newbie. L'immagine non è solo una velleità estetica, in realtà facilita molto la lettura di un blog. Siamo nell'era del sovraccarico informativo e l'immagine è il modo migliore per capire in un secondo di cosa tratta il post.

Una volta postato, il contributo verrà pubblicato nello spazio dedicato del blog a seconda dell'opzione scelta. Anche nel caso *solo su lista*, il messaggio verrà pubblicato su blog, ma solo nell'area "archivio" visibile a tutti o solo agli utenti registrati a seconda della configurazione.

Contemporaneamente il contributo verrà postato in mailing list (senza immagine). Oltre al testo e al permalink sul blog e varie meta-informazioni, comparirà in calce alla mail un link per rispondere all'intervento.

L'utente Caio riceve l'email e decide di rispondere. Il link nella mail lo porta direttamente al form di commento contestuale all'articolo. I commenti inviati in questo modo possono essere visualizzati in maniera threaded e nested, possibilmente espandibili come avviene nei blog più avanzati [1].

Nel caso di discussioni molto articolate credo risulterebbe addirittura più comodo andare direttamente su blog dove sarebbe possibile seguire meglio le biforcazioni ed ignorare i thread che si avvitano su loro stessi. Questo si spera eviti anche i Re:Re:Re:Re: demenziali nell'oggetto e riduca la necessità di quotare il messaggio precedente per capire il contesto.

Altre funzioni graziose

Possibilità di postare solo su blog (riservato agli admin) in una categoria particolare "feature".

Molteplici possibilità di ricerca sul blog. Per data, autore, fulltext, parola chiave, numero di interventi e views etc...

Differenti possibilità di iscrizione:

• aperta

- l'utente si registra e conferma l'utenza via mail

• chiusa

- l'utente non registrato inoltra la richiesta di iscrizione e l'amministratore attiva l'utenza via mail oppure - l'amministratore "invita" un utente non registrato che deve confermare via mail

• fidata

- un utente già registrato "invita" un utente non registrato che attiva l'utenza via mail (opzione che include le funzioni della modalità "chiusa")

Per inciso, io non ho mai visto una lista funzionare in quest'ultimo modo. Perchè? Mi sembra il modo più democratico e sicuro di gestire una lista non moderata, spinge la diffusione virale e filtra in maniera naturale la crescita. Forse nessuno si è mai posto il problema di implementare una funzione del genere, forse le opzioni lista aperta/chiusa/moderata sono tanto radicate nel nostro immaginario che non pensiamo possano esistere altre possibilità?

Possibili sviluppi

Multiutenza (blister?)

Questioni pratiche

Non sono sceso volutamente nei dettagli ma ho gia vari schizzi di layout e wireframe logici che formalizzerò in bella copia se la cosa interessa a qualcuno. Tecnicamente penso si possa partire da un cms modulare e ben supportato tipo drupal o wordpress. Per quanto riguarda i contributi concreti io posso darmi da fare con la struttura logica e cimentarmi con usabilità/grafica/css. Posso anche metter le mani sul codice se si tratta di php e di cose poco complesse.