Live Session

Le dinamiche di live session, sessione collaborativa in tempo reale, sono il punto di approdo più sperimentale di questo elaborato. Quello che si pregge di fare è trasformare lo spazio informativo personale di un utente, inteso come l'insieme degli ambienti di lavoro presenti nella piattaforma, in uno spazio informativo collaborativo. Ovvero si desidera trasformare PEUDOM così che possa diventare un editor multi-utente; si vuole garantire alla community la capacità di cooperare in tempo reale per la realizzazione di un mashup. Data la novità dell'approccio e le criticità incontrate, si è deciso di promuovere questo cambiamento a partire dalla Mashup Dashboard, secondo le modalità di interazione precedentemente previste. Questo ambiente, centrale per la piattaforma, è il luogo in cui avvengono la maggior parte delle interazioni e dove l'utente ha la possibilità di plasmare le proprie composizioni. Altro motivo è che, proprio in questa Dashboard, sono supportate pienamente gli altri meccanismi collaborativi. Questa decisione ha permesso non solo di riettere sullo sviluppo della sessione live, ma anche di come questa potesse integrarsi ed essere supportata dagli altri meccanismi di collaborazione (sia sincroni che asincroni). I fondamentali problemi riscontrati durante la fase di progettazione sono:

1. quali interazioni consentire in una live session e come risolvere le azioni concorrenti;

2. come orchestrare la collaborazione in modo da salvaguardarne le interazioni, prevenendo allo stesso tempo situazioni critiche o indesiderate;

3. come gestire lo spazio di lavoro in presenza di più utenti: ovvero in quale misura sia vantaggioso uniformare o diversicare le visualizzazioni delle Dashboard nel caso della collaborazione in tempo reale;

4. come convogliare le informazioni relative all'interazione multi-utente trami- te una visualizzazione che supporti la consapevolezza dell'utente (compren- sione delle interazioni in tempo reale e pregresse in unione alla comprensione del contesto);

4.3.7.2.1 Mutuo aggiustamento Vs Specica di una policy La prima questione da risolvere è stabilire quali azioni possono essere fatte dagli utenti e cosa succeda in caso di azioni concorrenti. È sicuramente auspicabile che tut- te le azioni, che un utente possa fare all'interno del proprio spazio personale, possano essere disponibili anche durante una sessione live. La manipolazione di componenti e binding è un concetto chiave, alla base del funzionamento della piattaforma, e deve continuare ad essere supportato. Allo stesso tempo è facile pensare ad un caso pessimo nel quale, a fronte di un gruppo di utenti che agisca in modo congruo, ci sia un utente che inizi a rimuovere senza ragione alcuni com- ponenti all'interno della composizione. O ancora: cosa succederebbe nel caso più

utenti eseguissero azioni concorrenti su uno stesso componente (es, rimozione del componente ed esecuzione di una ricerca sullo stesso)?

Nella maggior parte dei casi di interazione concorrente, la scelta di quale azio- ne debba avere la priorità è spesso non deterministica, alla luce delle informazioni di contesto possedute. Allo stesso modo in sistema non è in grado di discrimi- nare se sia meglio mantenere o rimuovere un determinato componente da una composizione. Sarebbe possibile una valutazione che consideri la numerosità dei binding presenti sul tal componente; tale informazione potrebbe però non essere comunque rilevante (es. l'utente sta sostituendo un vecchio componente con uno nuovo con simili funzionalità). Questo ci porta a riettere su quanto sia ragione- vole descrivere un modello di comportamento in fase di interazione, rispetto ad una soluzione meno vincolante.

A prescindere dalla complessità che una specica totale dei meccanismi di interazione concorrente comporti, è il caso di riettere sul signicato della colla- borazione. Interagire con altri utenti non può prescindere dal confronto con le idee altrui e dalla elaborazione di soluzioni dierenti. Si ricorda inoltre che tanto la comunanza, quanto la divergenza di intenti, sono gli attori che permettono un procuo sviluppo delle dinamiche collaborative. Nella maggior parte di tali situazioni conittuali si è optato per una soluzione che preveda il mutuo aggiu- stamento da parte degli utenti. Questa non costituisce solo la scelta più semplice, ma è quella che si ritiene salvaguardi la buona collaborazione.

4.3.7.2.2 I livelli della collaborazione Ciò nonostante esistono particolari situazioni in cui non è possibile adarsi incondizionatamente al mutuo aggiu- stamento; senza contare che è plausibile ritenere che gli utenti possano essere divisi in base alle loro conoscenze e competenze nei rispetti di una preciso servi- zio, componente o composizione. Si pensi per esempio ad una composizione in cui un componente contenga contenuti o dati specici sensibili di un utente, il quale desidera però il supporto della comunità per sviluppare il proprio mashup. La possibilità per quell'utente di nascondere tali contenuti sensibili deve essere garantita dalla piattaforma, anche in caso di collaborazione con altri utenti. In questo caso è necessario intervenire per abilitare un simile controllo.

Allo stesso modo è possibile pensare che nella maggior parte dei casi un utente desideri utilizzare soltanto la composizione e che esista un più circoscritto gruppo di utenti che abbia interesse e capacità nel modicare tale composizione (gli sviluppatori). In un simile caso appare ragionevole limitare le possibilità di coloro che desiderano solo sfruttare il mashup.

Altro ragionevole motivo per concedere un maggiore controllo sulle modalità di interazione riguardano il fatto che la collaborazione non deve poter snatura- re gli obiettivi che hanno motivato la creazione di tale lavoro. Esiste inoltre la possibilità che un utente desideri condividere il risultato nale dell'interazione con il mashup, per mostrare quanto conseguito ad un gruppo di interessati, ma

4.3 Lato Collaborative: supportare la collaborazione al tempo dei

mashup 69

garantendo solo al possessore delle composizione la possibilità di modicare i pa- rametri di ricerca. Per quanto ancora non si ritenga possibile agire a livello della singola azione, si ritiene plausibile fornire la possibilità al creatore di una compo- sizione di personalizzare l'interazione durante la collaborazione con altri utenti, associando a questi uno specico ruolo. In questo modo è possibile suddividere in categorie dierenti tutti coloro che condivideranno un determinato oggetto, asso- ciando dierenti permessi a gruppi distinti. Con questo meccanismo si permette di fatto di discriminare quale livello di collaborazione è associato ad un oggetto condiviso: dalla modica totale delle composizione alla sola visualizzazione, nella quale condivisione e collaborazione niscono per collidere. Il mutuo aggiusta- mento continua ad essere necessario, dato che le modiche concorrenti di utenti con gli stessi permessi continuano a dover essere risolte dagli utenti. Allo stesso tempo il buon senso del creatore della composizione deve guidare l'assegnazione dei ruoli agli utenti. Le gure previste a tale proposito, a livello di composizione, sono:

Owner: è il creatore della composizione sulla quale ha pieno controllo; ha inoltre la possibilità di specicare i ruoli per gli altri utenti con il quale condivide il proprio lavoro. Il ruolo di owner non è assegnabile o cedibile ad altri utenti. Super User: rappresenta un utente di ducia, un utente esperto oppure un

semplice utente che ha la possibilità di manipolare la composizione.

User: rappresenta l'utente standard, al quale interessa principalmente l'uso dei componenti presenti all'interno della composizione.

Viewer: utente al quale si concede solamente di vedere una istantanea dello stato di una composizione, ruolo utile per mostrare i risultati raggiunti nell'uso di una composizione.

In questo modo, in caso di necessità, un utente può limitare il livello di interazio- ne degli altri utenti, ma ancora non ha la possibilità di nascondere un particolare componente. A partire da questa necessità si è ragionato alla possibilità di ap- plicare i ruoli sopra elencati non solo alla composizione nella sua interezza, ma anche ai singoli componenti appartenenti ad una stessa composizione. Questo permetterebbe all'owner di specicare in maniera ancora più dettagliata le pos- sibili interazioni degli altri utenti. In un tale scenario sarebbe possibile tutelare la validità di un mashup, prevenendo la capacità di rimuovere un componente ritenuto essenziale, oppure sarebbe possibile nascondere uno o più componenti dalla visualizzazione. Si ripropongono i ruoli precedenti, declinati questa volta a livello di componente:

Super User: l'utente ha la possibilità di rimuovere il componente, in aggiunta all'uso e alla consultazione.

User: l'utente ha la possibilità di utilizzare il componente (interrogare i servizi presenti nel componente).

Viewer: l'utente può solamente consultare il componente.

Non-Viewer (Hide): l'utente non ha la possibilità di vedere il componente all'interno della composizione.

Ora, combinando a piacere l'applicazione di ruoli sia a livello di composizione che a livello di componente, è possibile specicare tutte le politiche desiderabili. Se da una parte con un simile meccanismo è possibile discriminare nel dettaglio il comportamento di ogni utente, dall'altra risulta evidente la necessità di presen- tare in una maniera sucientemente chiara tali possibilità all'utente. Si prevede quindi di fornire per gradi la capacità di specicare queste policy, prevedendo di specicare inizialmente solo, se desiderato, il ruolo da applicare a livello di composizione per tutti gli utenti. La possibilità di una specica ulteriore ver- rà garantita in uno spazio dedicato nella quale ogni nuova regola costituirà una eccezione alla policy generale.

Si vuole rimarcare come il meccanismo dei ruoli debba essere considerato come un utile supporto alla collaborazione e non come una sua immotivata limitazione. Infatti, fermo restando che i ruoli non inuenzino l'utilizzo degli altri meccanismi di collaborazione, è sempre possibile garantire una libera interazione garantendo di default i privilegi di super user, così come è sempre possibile per l'owner il modicare il livello di privilegio. Un utente durante una sessione live ha sempre la possibilità di richiedere all'owner che gli vengano garantiti privilegi dierenti. In ultimo, estendendo il meccanismo dei ruoli (per il solo livello di composizio- ne) anche al controllo di versione, è possibile gestire in maniera più eciente il salvataggio delle composizioni, così da regolamentare l'avanzamento di versione e permettere il salvataggio di una precedente versione in qualità di copia personale, eliminando allo stesso tempo la possibilità di una ridistribuzione non autorizzata della stessa, sempre tramite i ruoli. Anche in questo caso si rimanda al capitolo relativo all'implementazione per una visione più sistematica e schematica delle azioni corrispondenti ai determinati ruoli.

4.3.7.2.3 Sincronizzazione dello spazio di lavoro Il terzo problema ri- guarda la gestione dello spazio di lavoro durante una sessione multi-utente in tempo reale. In questo caso è necessario supportare la visualizzazione di istanze di Mashup Dashboard dierenti (una per ogni utente collaborante), che, sincro- nizzate tra loro, permettano agli utenti di lavorare contemporaneamente ad uno stesso mashup. Allo stesso tempo è però possibile che lo spazio di un singolo utente contenga delle personalizzazioni che costituiscono un ostacolo alla perfet- ta sincronizzazione tra gli utenti. L'ingenua soluzione di una riproduzione fedele di una stessa visualizzazione attraverso i diversi spazi personali degli utenti, per quanto si adatti in maniera impeccabile alle necessità del gruppo, che può così

4.3 Lato Collaborative: supportare la collaborazione al tempo dei

mashup 71

collaborare come se eettivamente ognuno avesse la possibilità di interagire con lo stesso oggetto, spesso entra in diretto contrasto con i bisogni dei singoli. Bisogna quindi individuare tali motivi di contrasto, la cui risoluzione permette di indivi- duare un modello per le interazioni in tempo reale, che nasca da un opportuno compromesso tra le necessità delle rispettive parti.

Prima di iniziare tale analisi si desidera specicare una assunzione che regola ogni interazione pensata nell'ottica dell'editing multi-user di una composizione. Così come nel caso di un singolo utente, si ritiene primaria la possibilità dell'uten- te collaborante di interagire con la piattaforma tramite la manipolazione diretta degli oggetti della UI. In accordo con le pratiche relative al Kinesthetic Learning [5] si ritiene che la possibilità di trascinare i componenti e di plasmare la propria composizione si una caratteristica essenziale, la quale permette di associare una sicità agli elementi all'interno dello spazio di lavoro, contribuendo così a rendere consapevole l'utente di quali saranno gli elementi target della collaborazione. Per delineare il modello sopra accennato, si espongono criticità e relative soluzioni secondo una classicazione sviluppata all'interno dell'ambito di studio del WY- SIWIS. Questo è stato uno dei primi approcci a mettere in evidenza vantaggi e relative criticità di una interazione multi-utente su un singolo oggetto condiviso. WYSIWIS è l'acronimo di What You See Is What I See, il quale allude appunto alla necessità di sincronizzazione e coesione tra le diverse visualizzazioni. Come mostrato in [36], tale paradigma, se applicato in maniera rigorosa, non permette di combinare ecacemente i bisogni del singolo con quelli del gruppo. Sono allo stesso tempo suggerite alcune linee guida, lungo le quali rilassare tale astrazione di interazione.

Nell'ambito di questa trattazione si useranno tali vincoli per classicare le criticità relative alla gestione dello spazio informativo condiviso, specicando per ognuno di essi quali siano le problematiche da arontare, queste ultime declinate nel caso specico della Mashup Dashboard di PEUDOM. Le direttrici di analisi corrispondono alle seguenti dimensioni: spazio, tempo, popolazione e congruenza. Spazio. Il vincolo di spazio impone la sincronizzazione di tutti gli elementi dello spazio di lavoro per l'adesione al modello WYSIWIS. All'interno della piat- taforma questo non costituisce un particolare problema. Infatti, per quanto la necessità di sincronizzazione si concretizzi nello specico soprattutto all'interno del workspace, inteso come luogo all'interno della Dashboard entro i conni del quale è possibile organizzare i propri componenti, i principali tool per la colla- borazione all'interno dell'ambiente continuano ad essere presenti attraverso i vari spazi di lavoro. Sebbene poi alcuni di questi elementi subiranno delle personaliz- zazioni in base ai ruoli, non esistono speciche aree dell'interfaccia che siano da escludersi totalmente dalla sincronizzazione.

Tempo. Il vincolo di simultaneità impone che la sincronizzazione di tutti gli elementi avvenga istantaneamente per l'adesione al modello WYSIWIS. Dal punto di vista delle interazioni è molto importante interrogarsi su quale sia la giu- sta granularità temporale da adottare. Tralasciando la discussione squisitamente concettuale circa la possibilità di interazioni istantanee, la scelta del giusto inter- vallo di tempo richiede di conciliare due posizioni contrastanti. Infatti la scelta di una granularità maggiore ha un positivo impatto sulle performance, a fronte di una minore frequenza di interazione dell'applicazione con il database e a fronte di un minor tasso di aggiornamento dei display degli utenti. Allo stesso tem- po il principale svantaggio è che una simile scelta aumenta concomitantemente la granularità dell'interazione durante la collaborazione. Questo introdurrebbe un ritardo nell'aggiornamento dei vari spazi di lavoro, rendendo più dicoltoso il coordinamento tra i soggetti impegnati nella co-creazione di spazi condivisi. Que- sto ritardo non solo rischia di alterare la percezione della collaborazione tra gli utenti, ma potrebbe anche portare il sistema in stati non consistenti. Si pensi ad esempio al tentativo di un utente di interagire con un componente, rimosso qual- che istante prima da un altro collaboratore. In questo caso risulterebbe necessario mantenere tale granularità temporale il più possibile prossima allo zero. Il siste- ma rischia però di collassare a causa di un eccessivo carico di richieste. La scelta di rilassare il vincolo di simultaneità è quindi una necessità dettata dai contin- genti limiti delle tecnologie utilizzate. A questo riguardo le scelte implementative appaiono cruciali ai ni di una accettabile realizzazione di dinamiche in tempo reale; per tali ragioni ampio spazio sarà dedicato ad una simile problematica all'interno del capitolo relativo all'implementazione.

Popolazione. Il vincolo di popolazione impone che ogni modica dello spa- zio condiviso sia propagato a tutti gli utenti per l'adesione al modello WYSIWIS. Sebbene a prima vista questo vincolo sembri del tutto lecito, anche in questo caso è necessario un suo rilassamento. Se da un lato è corretto sostenere la necessarietà della propagazione di ogni azione verso ogni utente, dall'altra l'introduzione dei ruoli, all'interno della collaborazione sincrona, apre la piattaforma a particolari scenari in cui l'aermazione precedente non è sempre vera. Infatti nel caso in cui esistano componenti nascosti all'interno della composizione (ruolo applicato a li- vello di componente = non-viewer) il vincolo di popolazione deve essere rilassato. In un simile scenario le azioni di pertinenza di componenti nascosti non devono raggiungere gli utenti ai quali si è imposta tale policy. Nel caso limite in cui non si abbiano gli elementi necessari per impedire la propagazione di tali azioni, si deve quanto meno prevedere un meccanismo che permetta di ltrare tali azioni, così che queste non raggiungano il livello di user interface.

Congruenza. Il vincolo di congruenza impone che l'immagine mostrata a ciascun utente sia identica per l'adesione al modello WYSIWIS. Non sono am-

4.3 Lato Collaborative: supportare la collaborazione al tempo dei

mashup 73

messe dierenti viste, così come non sono previste variazioni visuali all'interno dello spazio di lavoro. Anche in questo caso un rilassamento del vincolo appare necessario, in prima istanza alla luce dello scenario appena descritto per il vin- colo di popolazione. La possibilità di mostrare componenti dierenti introduce una asimmetria inconciliabile attraverso le viste visualizzate dagli utenti. Inoltre esistono altre ragioni che inducono a violare le restrizioni di congruenza. Infat- ti si ritiene utile concedere all'utente la possibilità di organizzare liberamente il proprio spazio di lavoro per quanto riguardi disposizione e dimensioni dei com- ponenti. Questo nasce da due semplici osservazioni: per prima cosa continua ad essere lecita la presenza di un diverso numero di componenti in base ai ruo- li deniti per ogni collaboratore. In questo caso una disposizione degli oggetti sullo schermo, identica per tutti gli utenti, potrebbe andare a sovrapporre alcuni componenti tra loro. In caso ciò avvenga per più di un utente, il conseguente tentativo concorrente di entrambi di risolvere i rispettivi problemi di visualizza- zione, rimbalzerebbe le loro visualizzazioni da uno stato consistente per il primo, ma non per il secondo, e viceversa.

Un secondo scenario problematico combina il precedente con la volontà di un utente di modicare la grandezza di un componente, magari in concomitanza con la necessità di visualizzare in maniera più chiara i risultati di una ricerca. Come in precedenza, tale situazione potrebbe portare a visualizzazioni sfavorevoli per un sottogruppo di utenti. Per questa ragione si desidera lasciare il pieno control- lo dello spazio di lavoro all'utente, limitando la sincronizzazione alle variazioni sostanziali della composizione: aggiunta/rimozione di componenti o binding ed esecuzione di nuove ricerche. Altro rilassamento necessario è ancora una volta riconducibile alla presenza di ruoli associati ai collaboratori: speciche limitazio- ni imposte ad un utente sono tradotte in opportune modiche dell'ambiente di lavoro. Nonostante si collabori sullo stesso mashup, azioni dierenti potrebbero essere disponibili per gruppi di utenti con ruoli dierenti. Ultima ragione che porta a violare la congruenza riguarda la volontà di fornire ad ogni utente delle informazioni di contesto, che permettano di ricostruire l'attuale stato di intera- zione degli altri partecipanti. Si pensi ad uno scenario che coinvolga due soli utenti: lo spazio di lavoro di entrambi sarà personalizzato con le informazioni