Strumenti per la collaborazione asincrona

La collaborazione asincrona è sicuramente il paradigma più largamente diuso negli ambienti collaborativi noti. Come si è potuto notare dall'analisi delle ap-

plicazioni Web, nominate in precedenza, quando si parla di collaborazione, allora si parla di una interazione asincrona. Una simile interazione ha infatti il grande vantaggio di essere meno stringente e consente all'utente di interfacciarsi con gli altri in maniera più libera e indipendente. Infatti, l'interazione non avviene in un tempo limite stabilito a priori: i contributi degli utenti possono alternarsi con una frequenza non meglio specicata. Questo è molto comodo per l'utente, soprattutto nel caso in cui abbia una limitata possibilità di interagire con l'ap- plicazione. Soggetti, che in normali condizioni non riuscirebbero ad interagire tra loro, dierendo nel tempo il loro dialogo, hanno la possibilità di confrontar- si. Come accennato in precedenza, la maggiore essibilità è a discapito di tempi potenzialmente molto più lunghi. Per questo motivo non si vuole aermare la su- periorità delle dinamiche sincrone, ma si desidera evidenziare come queste ultime permetterebbero di raggiungere obiettivi più ambiziosi, oppure gli stessi traguar- di ma in un tempo inferiore, in modo più ecace e incisivo. Inoltre la scelta di logiche asincrone è giusticata da precise limitazioni tecnico-implementative, motivo per il quale risulta più semplice optare per tali meccanismi. E' da speci- care che, allo stesso tempo, tali interazioni sono ormai entrate a far parte della quotidianità delle persone: tale fatto assicura che, se implementati, tali strumenti di collaborazione appaiano familiari ed intuitivi all'utente.

4.3.6.1 Notiche

Al meccanismo di si associano implicitamente schemi di interazione, che ormai possono considerasi come consolidati per l'utente medio; un esempio su tutti so- no le notiche di Facebook oppure le notiche di un client di posta elettronica. Le notiche, con il loro carattere minimamente intrusivo e puntuale, rendono consapevole l'utente di una precisa interazione, pur senza distogliere l'attenzione dell'utente dal task corrente. Per questi motivi anche in PEUDOM simili dina- miche appaiono interessanti. Infatti il numero di operazioni, così come il numero di ambienti di lavoro, è sucientemente vario.

Le azioni importanti da noticare spaziano da informazioni relative agli inviti per i gruppi di interesse, alla condivisione di un nuovo oggetto, arrivando inne anche alla notica di modiche apportate a servizi, componenti e composizioni che attualmente si condividono. Seppure esistono diversi ambienti, si prevede che l'utente passi la maggior parte del proprio tempo all'interno della Mashup Dashboard. Ciò ha portato alla scelta di gestire in maniera centralizza le noti- che, anche in maniera da non mettere in dicoltà l'utente in caso necessiti di consultare tali messaggi, incorporando allo stesso tempo il centro di notica in ogni pagina, così da tenere l'utente sempre aggiornato. Si ha così la possibilità di tenere sotto controllo in ogni istante i fatti più rilevanti delle realtà di proprio interesse, mantenendo uno storico delle interazioni a livello di piattaforma. In questo modo, ogni qualvolta si acceda alla piattaforma, così come ogni qualvolta lo desideri, ogni utente può controllare lo stato delle interazioni con gli altri uten-

4.3 Lato Collaborative: supportare la collaborazione al tempo dei

mashup 63

ti su progetti condivisi. Si consente quindi agli utenti online di essere informati, avendo però la possibilità di continuare nel proprio lavoro, mentre si conservano le notizie potenzialmente di interesse per coloro che sono oine, presentandole prontamente al loro prossimo accesso.

Al momento non si prevede un meccanismo esplicito tramite il quale un utente possa iscriversi alla ricezione di determinate notiche. Il sistema infatti registra implicitamente tutte le informazioni che permetteranno in caso di necessità di inviare le notiche potenzialmente rilevanti per ogni utente. Banalmente sup- ponendo che un utente sia interessato alle notiche relative ad eventi, generatisi all'interno di un gruppo ai cui è iscritto.

4.3.6.2 Annotazioni

Una particolare dinamica di collaborazione che si è scelto di introdurre sono le annotazioni, in quanto si ritiene che esse possano contribuire positivamente alla collaborazione. Anche in questo caso l'idea è sempre quella di supportare lo scambio di idee tra gli utenti: ad un livello base le annotazioni si congurano come dei commenti, i quali ciascun utente può liberamente inserire all'interno della piattaforma. Questo rappresenta l'elemento di continuità presente all'interno delle annotazioni. L'elemento innovativo sono invece le modalità con le quali si supporta questo speciale meccanismo di commenti, nonché l'uso particolareggiato che si attribuisce a tali strumenti.

La volontà di supportare la collaborazione tramite l'uso di annotazioni ha dei precedenti in letteratura, soprattutto considerando l'ambito delle applicazioni che si rivolgono in maniera privilegiata agli end-user [10]. Anche in questo caso l'idea è quella di permettere all'utente di poter contribuire in maniera sempre più pervasiva al meta-sviluppo della piattaforma stessa che l'utente sta utilizzando, generando commenti con richieste di modica e customizzazione delle piattaforme in base ai loro scopi specici. Questo permette in primo luogo di raccogliere preziosi feedback dell'utente, contributi che andrebbero persi in caso contrario. A tale scopo risulta essenziale la capacità di predisporre una infrastruttura che permetta di catturare tali suggerimenti in maniera tempestiva.

A maggior ragione in un ambiente come PEUDOM, dedicato allo sviluppo di mashup da parte dell'utente, le annotazioni saranno utili tanto agli svilup- patori della piattaforma, quanto agli utenti nali. Infatti, ciò che rende questo strumento ancora più importante, è che in PEUDOM sono gli utenti stessi ad assumere il ruolo di sviluppatori; a maggior ragione tali contributi potrebbero rivelarsi essenziali per il buon esito della creazione di componenti e composizioni (si ricordino gli esempi di scenari presentati precedentemente). Infatti durante la realizzazione collaborativa di spazi condivisi, grazie alle annotazioni, l'utente ha la possibilità di:

• ricordare o sintetizzare l'attuale stato dei componenti, ragionando sullo scopo della composizione;

• riettere e proporre modiche da eettuare su uno specico componente, esporre le proprie idee circa i possibili miglioramenti dello stato attuale (componenti e binding);

• chiedere delucidazioni circa perplessità sull'uso di composizione e compo- nenti, ricevere supporto da altri utenti che condividono l'oggetto e chiarire tramite l'interazione le proprie idee e i propri requisiti;

Un simile meccanismo abilita il libero scambio di idee e di informazioni ed idee tra gli utenti per il miglioramento del risultato nale. Proprio perché si trat- ta di un meccanismo asincrono, si ritiene importante la possibilità per l'utente di consultare lo storico delle interazione scambiate, così da ricordare i risultati pregressi, nel caso in cui tali interazioni avvengano in un intervallo di tempo sucientemente lungo.

Un punto cruciale è la discussione circa quali siano i soggetti per i quali sia interessante supportare il meccanismo di annotazione. La granularità prescelta è quella del componente all'interno di una composizione: motivo di tale scel- ta è in primo luogo il desiderio di mantenere una implementazione essenziale, ma funzionale. Un'altra ragione è il desiderio che le annotazioni siano quanto più contestuali all'elemento al quale si riferiscono. Questo, sebbene contribuisca all'immediatezza dell'interazione con l'annotazione, pone il problema della rap- presentazione della nota all'interno dello spazio di lavoro, luogo per sua natura dinamico e possibilmente personalizzato in base all'utente. In questo caso la solu- zione ideale sarebbe che le annotazioni siano sempre visibili e riferite all'elemento di loro pertinenza, ma che allo stesso tempo queste non vadano ad interferire in maniera controproducente con l'utilizzo di composizione e componenti. Questi due requisiti sono però in contrapposizione tra loro ed è necessario elaborare una strategia che permetta ad entrambi di coesistere. Anche in questo caso si riman- da al capitolo relativo all'implementazione per il dettaglio delle scelte fatte per risolvere tale problema.

4.3.6.3 Controllo di versione

Per quanto uno degli scopi fondamentali della piattaforma sia quello di abilitare la composizione dei mashup da parte dell'utente nale, lo scenario di interazione più frequente è verosimilmente il semplice uso di una composizione precedente- mente costituita. Oltre allo sviluppo, in PEUDOM è necessario anche tutelare la possibilità di utilizzare una determinata composizione: la creazione stessa del mashup è ovviamente nalizzata al suo uso. Il problema non sussiste qualora si consideri un oggetto privato: il proprietario è l'unico a poter lavorare su ta- le progetto e di conseguenza non va incontro a particolari criticità. Tuttavia, sempre usando come riferimento una composizione collaborativa, si pensi al caso in cui la collaborazione tra più utenti porti ad una trasformazione signicativa. Siccome le azioni in uno spazio condiviso sono concorrenti e hanno impatto sullo

4.3 Lato Collaborative: supportare la collaborazione al tempo dei

mashup 65

spazio di lavoro di ogni utente in condivisione, sono possibili situazioni in cui un utente, per le più svariate ragioni, preferisca l'utilizzo della composizione, così come sviluppata ad uno degli stadi precedenti. Tale utente avrebbe la possibilità di forzare il ritorno ad uno stato pregresso della composizione, però una simile azione andrebbe a distruggere ogni sforzo collaborativo nella direzione di un cam- biamento. Lo scenario di interazione ottimo sarebbe il caso in cui parallelamente si riesca a promuovere lo sviluppo collaborativo del mashup, salvaguardando il diritto degli utenti di utilizzare lo stesso mashup, ma nello stato di sviluppo che più gli è congeniale.

A questo ne sono state introdotte delle politiche di versioning. In questo modo il sistema ricorda ogni singolo passo incrementale nello sviluppo di un de- terminato oggetto, generando una nuova versione ad ogni salvataggio del proprio lavoro. In accordo con quanto aermato in precedenza si è scelto di dare la possibilità all'utente, in fase di caricamento, di decidere quale revisione di un determinato oggetto si desidera utilizzare. Inoltre nel caso l'utente si ritrovi a utilizzare ripetutamente una vecchia versione, sarebbe una buona pratica fornire la possibilità a quest'ultimo di poter salvare tale revisione di tale oggetto come propria copia personale. Qualora l'utente non specichi nulla in proposito, vie- ne caricata la versione più recente, ovvero la versione che raccoglie i frutti di eventuali sforzi di sviluppo. Un sistema di versioning si dimostra vantaggioso anche nel caso di una composizione personale (non condivisa). Grazie a questo strumento, in caso di errori o ripensamenti, è ancora una volta possibile navigare attraverso le precedenti revisioni dell'elemento in questione, al ne di ripristinare il proprio lavoro ad un precedente stato desiderato.

Un'altra osservazione rilevante è che il controllo di versione è il primo strumen- to di collaborazione che fa sorgere esplicitamente i problemi dovuti all'interazione concorrente tra utenti dierenti. Questo meccanismo si pone come primo tentati- vo di contenere eventuali eetti collaterali della collaborazione. Allo stesso modo sono evidenti i limiti di un simile approccio, qualora non venisse complementato con ulteriori dinamiche: ogni utente ha potenzialmente la capacità di stravolgere e snaturare un qualsiasi lavoro, a patto che questo gli sia condiviso. Inoltre la possibilità di salvare una propria copia locale, se non vincolata, permetterebbe a chiunque di appropriarsi indebitamente del lavoro altrui. Questa discussione circa la necessità di una regolamentazione delle politiche di interazione tra gli utenti sarà a breve ripresa e sviscerata nel dettaglio.