Home » n. 25 marzo 2004

ITCOLE: breve storia di una piattaforma web per l’apprendimento collaborativo cross-nazionale

25 marzo 2004 | Maria Beatrice Ligorio (b.ligorio@haroldnet.org)

Introduzione

Studiare e potenziare modalità di collaborazione a distanza e tra partecipanti culturalmente diversi è un obiettivo ambizioso per chi si occupa di educazione. Recentemente, grazie agli sviluppi della tecnologia basata su web, questo tipo di studio ha ottenuto un notevole impulso soprattutto perché gli strumenti di comunicazione e condivisione delle informazioni si propongono come artefatti capaci di sostenere la creazione di nuove culture che funzionino come cerniera tra diversi contesti e ambienti e tra una certa varietà di partecipanti, pur prevedendo, contemporaneamente, spazi e modalità di espressione delle identità nazionali e individuali. Qui saranno delineati brevemente alcuni aspetti teorici, metodologici e pratici relativi alla progettazione ed utilizzazione di una piattaforma telematica destinata a sostenere comunità di lavoro e di discorso composte da membri eterogenei sia per provenienza culturale che per i contesti entro cui operano. Si tratta di una esperienza europea denominata ITCOLE che ha coinvolto molti paesi e ha visto la partecipazione attiva di studenti ed insegnanti di diverso grado, ricercatori con competenze differenziate (dagli sviluppatori software agli esperti psicopedagogici e della comunicazione mediata) e vari altri stakeholders interessati a sfruttare le potenzialità educative delle piattaforme basate su web.

Aspetti teorici
Dal punto di vista teorico, i progetti di comunità mediati da piattaforme telematiche sono in linea con gli sviluppi più recenti della psicologia culturale che studia i reali contesti in cui le persone vivono e si incontrano (anche virtualmente), alla ricerca dello specifico e del peculiare, piuttosto che delle leggi universali e dei principi astratti (Cole, 1996; Ligorio, in stampa). In contesti complessi e per lo svolgimento di attività sofisticate occorre utilizzare strumenti (nel nostro caso piattaforme web) che aiutino le persone a svolgere le loro attività quotidiane; attività che in conseguenza dell’uso di nuovi strumenti, risulteranno inevitabilmente modificate. In questo senso le piattaforme web vanno considerate come artefatti culturali che mediano sistemi di attività complessi e regolano l’implementazione dell’esperienza condivisa nel contesto locale, declinando così obiettivi comuni all’interno delle risorse e dei limiti di ciascun contesto.
Studiare l’esperienza di progetto europeo dedicato alla progettazione e all’uso di una piattaforma web cross-nazionale significa osservare la creazione di un artefatto in grado di avviare nuovi sistemi di attività (Engeström, Miettinen e Punamäki, 1999), che emergono dal dialogo a molte voci tra i vari partecipanti (Bachtin,1986), eterogenei per diversi aspetti ma accomunati da un medesimo obiettivo generale.
Gli ambienti telematici permettono facilmente di documentare l’intersercarsi tra attività e dialogo (Ligorio e Mancini, in stampa) intrecciando così l’analisi dei sistemi di attività, che dedica particolare attenzione allo sviluppo storico-culturale di sistemi di attività complesse (Engeström, Miettinen e Punamäki, 1999), con la tradizione dell’approccio narrativo e discorsivo (Edwars e Mercer, 1987, Fasulo e Pontecorvo, 1999; Bruner, 1997).
Uno dei risultati ottenuti da questo intreccio è quello di veder potenziate sia le modalità di discorso all’interno dei contesti educativi, che le strategie di apprendimento e di costruzione della conoscenza. Il discorso in classe diventa facilmente (grazie alla comunicazione mediata) discorso tra classi e si può assistere all’incontro di “voci” diverse per background, livelli di conoscenza e competenza, attitudini e opinioni e, a volte, diverse anche per lingua ed accenti. Infatti, l’uso di piattaforme web facilita enormemente il lavoro collaborativo a distanza allargando la “rete” di interazioni, fino ad includere paesi e lingue diverse. Il contributo di Bachtin ci consente di considerare i processi di costruzione della conoscenza come fondamentalmente dialogici e i significati prodotti all’interno della comunicazione come fortemente connotati socialmente.
Dall’altra parte, la costruzione di conoscenza si colloca all’interno di comunità estese dove le strategie di collaborazione risultano accresciute e aumentano esponenzialmente le risorse utilizzate durante il processo di costruzione di conoscenza. Per esempio, si possono attivare modalità di collaborazione a distanza tra studenti e adulti di gradi diversi, utilizzando risorse tipicamente telematiche e sfruttando le dimensioni ludiche proprie di certi ambienti virtuali (Ligorio, 2002a).

Il progetto ITCOLE
Il progetto ITCOLE (Innovative Technology for Collaborative Learning) ha visto la partecipazione sei paesi Europei (Finlandia, Olanda, Italia, Grecia, Spagna e Germania) per due anni. In ciascun paese sono stati coinvolti enti di ricerca (in Italia, sono state coinvolte le Università di Roma e di Salerno), istituti di vario tipo (il Centro per la Formazione degli insegnanti del Comune di Helsinki, vari Laboratori per lo sviluppo di tecnologie in rete) e scuole di diverso ordine e grado. Alcuni degli enti partecipanti (in particolare le università) hanno avuto il compito di sviluppare modelli psicopedagogici di utilizzo del software e hanno lavorato a stretto contatto con le scuole; altri enti invece (è il caso del Media Lab di Helinski e dei centri informatici tedeschi e spagnoli) si sono occupati dello sviluppo del software e della piattaforma web.
Obiettivo principale è stata la costruzione di una piattaforma basata su web da utilizzare in diversi contesti educativi (dalla scuola primaria alla formazione universitaria di Paesi Europei diversi) e che servisse anche per la comunicazione tra i ricercatori coinvolti e per la costruzione dei documenti richiesti dalla Commissione Europea. Il software sviluppato nell’ambito di questo progetto si traduce in una piattaforma web, denominata Synergeia, pensata con una interfaccia facile da usare e in grado di supportare modalità di lavoro progettate in funzione dei principi pedagogici condivisi dal gruppo di ricerca. Inoltre, si voleva che il software fosse sviluppato in modo da riflettere bisogni ed esigenze degli utenti finali (studenti ed insegnanti). Per ottenere questo risultato si è utilizzata una metodologia di lavoro definita Participatory Design (progettazione partecipativa), che prevede diverse fasi di testaggio (tre nel nostro caso), a partire da un prototipo iniziale da cui si otterranno delle versioni successive sulla base dei feedback ottenuti da un gruppo di utilizzatori che possono rappresentare gli utenti finali (Talamo e Zucchermaglio, 2003). Nella prima fase di testing si è distribuita una versione ‘zero’ del software, costruita sulla base dei principi pedagogici del progetto, in particolare l’apprendimento collaborativo (Crook, 1994; Dillenbourg, 1999), l’indagine progressiva (Hakkarainen, 1998) e il sostegno allo sviluppo di comunità virtuali di apprendimento (Ligorio, 2002; Renninger e Shumar, 2002). Si sono poi raccolte storie d’uso, commenti, interviste e questionari circa il funzionamento del software in modo da poter comprendere le aspettative degli utenti e punti di forza e aree di miglioramento da loro individuate. Queste informazioni sono state classificate, clusterizzate e successivamente elaborate dal gruppo di ricerca psicopedagogico per consentire agli sviluppatori del software di implementare i cambiamenti richiesti dagli studenti ed insegnanti. Si è così ottenuto un ambiente virtuale modulare, flessibile e adatto ad utenti di diverse età ed interessi.

Metodologia di analisi
L’analisi qui effettuata riguarda le interazioni avvenute nell’ambito del gruppo di ricerca allo scopo di sviluppare ed implementare una piattaforma web condivisa, chiamata Synergeia. Si tratta di un’analisi squisitamente qualitativa che si pone l’obiettivo di analizzare i processi in corso d’opera, piuttosto che i prodotti finali (Young, Kulikowich e Barab, 1997). In particolare, si è fatto ricorso all’analisi del discorso individuando topic (Sacks, Schegloff e Jefferson, 1974) attinenti gli obiettivi di questo studio, vale a dire l’emergere di polifonie più o meno armoniche, di “voci” capaci di “incarnare” punti di vista diversi e che inducono alla costruzione di nuove modalità di rappresentazione del lavoro svolto e, quindi, di una specifica cultura che caratterizzi il progetto stesso. L’interpretazione dei dati mira a rinvenire le ragioni e gli obiettivi che portano gli interlocutori ad intervenire e direzionare il discorso (Ghiglione, 1988; Van Dijk, 1993). Si tratta di un tipo di analisi che prende le mosse dall’etnografia e mette in primo piano l’importanza del contesto socioculturale, considerando come unità di analisi l’evento linguistico tipico di un certo contesto (Duranti, 1992; Goffman, 1981).
Le domande che hanno guidato l’analisi dei dati sono le seguenti: quali e quante “voci” sono state espresse durante le interazioni analizzate? Quale impatto ha avuto il fatto di lavorare con e per partner distanti e di altri paesi? Che ruolo hanno avuto le diversità culturali e di competenze tra i vari partner? Quali sono gli elementi che caratterizzano la cultura che emerge dal sistema di attività determinato dal progetto ITCOLE?

Risultati
Nell’ambito delle interazioni del gruppo di ricerca è emerso che spesso questi si fanno portavoci anche di un punto di vista altrui, dando voce a persone e strumenti che non partecipano in prima persona al dibattito ma che sono intitolati ad essere rappresentati.
La “voce” riportata più spesso dal gruppo di lavoro è quella degli insegnanti e degli studenti, in particolare lo fanno i ricercatori di matrice psicoeducativa; mentre i tecnici si fanno più spesso portavoci del “software” che assurge a strumento con esigenze e caratteristiche specifiche. Vediamo innanzitutto le differenze emergenti tra i vari partecipanti relativamente alle modalità di dar voce allo strumento in via di sviluppo.

Dov’è il software?
Lo sviluppo di un software comune, in grado di rispecchiare e rappresentare le esigenze di diverse comunità con specifiche modalità culturali non implica solo un continuo processo di confronto sul come costruire interfaccia e funzionalità, ma anche una diversa interpretazione di cosa si intenda per software. Questo aspetto emerge in modo chiaro quando i partner italiani si preparano ad avviare la sperimentazione della prima versione del software con tutti gli insegnanti coinvolti.

Dear all, (expecially technician partners)on January 17 we have a meeting with all Italian teachers in Rome. They come from Bari, Salerno and Milano in order to have a meeting for organizing the school testing that will begin in the last week of january.We must train them with the BSCL software (Synergheia or whatever it is). But is the software ready? can we have access to it?
Dxxxx
Cari tutti (specialmente i partner tecnici) Il 17 Gennaio abbiamo un incontro a Roma con tutti gli insegnanti italiani. Vengono da Bari, Salerno e Milano allo scopo di fare un incontro durante il quale organizzare il testing a scuola che comincerà l’ultima settimana di Gennaio. Dovremmo addestrarli ad usare il software BSCL (1) (Synergeia o qualunque altra cosa sia). Ma il software è pronto? Possiamo averci accesso?
Dxxxxx

La richiesta è molto semplice: prima di addestrare gli insegnanti i ricercatori hanno bisogno di familiarizzarsi con il software, capire come funziona e preparare una sorta di training, di addestramento per gli insegnanti, durante il quale non solo si dovranno mostrare gli aspetti tecnici ma si appronteranno delle esemplificazioni dell’utilizzo didattico del software. Insomma, i ricercatori pensano che occorra loro un po’ di preparazione prima di mostrare il software agli insegnanti e per poter preparare esempi concreti ed adeguati di uso del software durante il lavoro in classe. La risposta da parte di uno dei tecnici non tarda ad arrivare.

The first prototype is ready since Dec 24th. There are little bugs and more will appear on the testing, they will be correct on the fly. I think that Txxx was preparing the testing also in Helsinki.
Anxxxx
Il primo prototipo era pronto già dal 24 Dicembre. Ci sono ancora dei piccoli problemi e forse altri ne appariranno durante il testing, saranno corretti al volo. Credo che Txxx stesse anche lui preparando il testing ad Helsinki.
Anxxx

Il prototipo era già pronto da tempo, ma i ricercatori italiani non lo sapevano. Hanno, quindi, sprecato del tempo prezioso per poter provare il software prima dell’incontro con gli insegnanti.

Dear all we just discussed on teacher training between all italian partners, and this message from Anxxx about the software released already 20 days ago came in. There will be a meeting next week with all Italian teachers and we were thinking of skipping the presentation of the software as it seemed it was not ready yet.We have now only a few days to look at the software ourselves before we can train adequately teachers; it could have been evidently better if we knew it was already available last month.
Alxxx
Cari tutti avevamo appena discusso del training per gli insegnanti tra tutti i partner italiani, quando è arrivato questo messaggio di Anxxx sul fatto che il software era pronto già 20 giorni fa. Ci sarà un incontro la settimana prossima tra tutti gli insegnanti e noi stavamo pensando di non presentare il software visto che non era ancora pronto. Adesso abbiamo solo pochi giorni per guardarlo prima di poter adeguatamente addestrare gli insegnanti; evidentemente sarebbe stato meglio se avessimo saputo che era già disponibile il mese scorso.
Alxxx

I ricercatori Italiani esprimono un certo grado di frustrazione per non poter mantenere l’agenda di lavoro prestabilita (addestrare gli insegnanti all’uso del software) a causa del semplice fatto di non essere stati informati in tempo sulla disponibilità del software.
Insomma, emerge una certa ambiguità nell’usare termini ormai entrati a far parte di un repertorio condiviso oltre che una diversa rappresentazione delle competenze reciproche. I ricercatori italiani parlano di una versione del software utilizzabile e il loro punto di vista, strettamente legato all’addestramento degli insegnanti, non consente loro di prendere in considerazione versioni del software non utilizzabili con semplici “click”. Invece, per gli sviluppatori del software, legati agli aspetti tecnici della piattaforma, la versione utilizzabile dagli utenti finali è frutto di diverse tappe intermedie di lavoro. Quando gli italiani chiedono se vi è una versione del software, essi intendono una versione già utilizzabile con gli insegnanti, mentre i tecnici intendo semplicemente una versione esistente, e fanno riferimento al lavoro da loro già svolto che si è dipanato attraverso diverse fasi. In seguito, un tecnico finlandese precisa meglio le fasi di lavoro intercorse prima di avere un software usabile.

In the software development process where we are simultaneously working in three levels (design, technical implementation and testing) is pure logistics: (1) to feed design we need testing; (2) to feed technical implementation we need design; (3) to feed testing we need technical implementation. The chain must be started from one of the stages, and in the ITCOLE we started it from the stage 2 (design). The design was based on earlier testing of similar systems (done not it this project),theoretical studies, earlier empirical studies etc.The design rationality behind the sketches, mockups and prototypes is that on some functionality we already hold hypothesis on how the things could be. Many of these hypothesis can be tested with sketches, mockupsand prototypes which are faster to build than a real functional system.The mockups and prototype are versions made for “crash test” where we may try different design solutions in a “safe environment”.
Txxx
Nel processo di sviluppo del software stiamo lavorando a tre livelli (progettazione, implementazione tecnica e testing) puramente logistici: (1) per sviluppare la progettazione abbiamo bisogno di testing; (2) per sviluppare l’implementazione tecnica abbiamo bisogno di progettazione; (3) per sviluppare il testing abbiamo bisogno di implementazione tecnica. La catena deve pur cominciare da qualche parte, e per ITCOLE abbiamo cominciato dalla fase 2 (progettazione). La progettazione si basava su testing precedenti effettuati su sistemi simili (non effettuati in questo progetto), studi teorici ed empiri precedenti, etc. La logica della progettazione dietro queste bozze, mockup (2) e prototipi è che per qualche funzionalità noi abbiamo già delle ipotesi sul come dovrebbero essere. Molte di queste ipotesi possono essere testate attraverso schizzi, mockup e prototipi che si possono costruire più velocemente che le reali funzionalità del sistema. Mockup e prototipi sono versioni fatte per i “crash test” dove possiamo provare diverse soluzioni di progettazione in un “ambiente sicuro”.
Txxx

I ricercatori psicoeducativi immaginavano una prima versione del software, diciamo, “vergine” dal punto di vista teorico e sembrano immaginare che gli informatici aspettassero i loro feedback per dare un contenuto educativo alle varie funzionalità. Scoprono invece che quella che sarà per loro la prima versione del software, è costruita sulla base di studi e risultati di ricerche precedenti e, cosa ancora più sorprendente, che le funzionalità potevano essere testate anche senza avere il software on-line.

BTW we are rather surprised discovering that the design of the new version of the program is already discussed before we are able to see officially at least its first version.
Alxx
In ogni caso ci siamo piuttosto stupiti di scoprire che la progettazione della nuova versione del programma veniva discussa ancora prima che noi potessimo ufficialmente vedere persino la prima versione.
Alxx

Lo sconcerto e la confuzione dei ricercatori italiani è chiaramente legata ad un senso di esclusione da una fase di lavoro in cui pensavano di ricoprire un ruolo fondamentale. La loro aspettattiva era che gli insegnanti da loro formati venissero coinvolti nella progettazione del software da subito e, pertanto, loro dovessero svolgere un ruolo di mediazione, in qualità di esperti pedagogisti, tra gli utenti e gli sviluppatori del software.

Le modalità di pensiero
I paesi coinvolti nella sperimentazione del software sono caratterizzati da una discreta differenziazione dei sistemi scolastici nazionali, che riflette la situazione europea più generale. Infatti, in Europa per quanto riguarda la scuola, esistono pratiche diverse e modi dissimili di intendere la professionalità docente, emergono persino differenze di ordine pratico, relative al calendario dei giorni di lavoro, ai ritmi e tempi di attuazione del curriculum (Lakkala, Rahikainen e Hakkarainen, 2001). Quindi, anche i modelli pedagogici che medieranno l’inserimento del software nei vari siti sperimentali sono diversi, o almeno sono attuati sulla base di pratiche e modalità di lavoro diversificate. In alcuni paesi (soprattutto in Finlandia) prevale un modello di didattica basato sul ragionamento progressivo, di tipo scientifico, che procede per domande sempre più sofisticate e messa a punto di ipotesi caratterizzate da una sempre maggiore potenza esplicativa, illustrato nel contributo di Cesareni contenuto in questo stesso numero. In altri paesi (tra cui soprattutto l’Italia) il modello educativo e formativo prevalente (almeno nella letteratura scientifica specializzata) è notevolmente influenzato dalla prospettiva culturalista, dove l’accento è sulla costituzione di comunità più o meno estese e ne consegue una visione del software come strumento di lavoro tra classi della stessa scuola o addirittura di scuole diverse (Ligorio, Cesareni, Mancini e Talamo, 2001).
Queste differenze di impostazione teorica emergono anche nel momento in cui si progettano le funzionalità didattiche del software, ad esempio quando si discute circa i così detti Thinking Type, ovvero dei descrittori delle modalità di pensiero messe in atto quando si preparano le note da inserire negli ambienti di discussione strutturati. In pratica si tratta di etichette che occorre assegnare alle note da inserire nel forum di discussione, l’uso di queste etichette “forza” la riflessione sulle strategie metacognitive di chi scrive e facilita il processo di comprensione da parte di chi legge. La definizione del set dei thinking type (appunto le etichette da accludere a ciascuna nota) da inserire nel software ben riflette le differenze in termini di modelli di apprendimento e di didattica tra i vari paesi. Ad esempio, sulla base del testing locale, studenti e docenti italiani propongono un set di thinking type diverso da quello inserito nel prototipo sperimentato.

Dear Rxxx and all, here is the Italian proposal for two sets of thinking types. We have already sent it but now we add icons and colours (It is the best we can do as wehave no technicians or designers…) We didn’t prepare prompts because we think that sometimes prompt should be confusing for students. If you agree we can use these sets testing them now with students, deciding after if it is necessary to give them prompt.
Best wishes
Dxxx Cxxxx
Caro Rxxx e tutti, qui c’è la proposta italiana di usare due set di thinking type. L’avevamo già spedita ma ora aggiungiamo icone e colori (questo è il massimo che possiamo fare visto che non abbiamo nè tecnici né disegnatori …) Non abbiamo preparato frasi di avvio perché pensiamo che a volte possono confondere gli studenti. Se siete d’accordo potremmo già testare questi set con gli studenti e decidere successivamente se è necessario inserire le frasi di avvio.
Cordiali saluti
Dxxx Cxxxx

I thinking type proposti dai finlandesi riflettono molto evidentemente le modalità di pensiero tipiche della soluzione di problemi, che modellizza infatti il ragionamento progressivo, assunto come modello pedagogico dai finlandesi. Ciascuno dei thinking type disponibili nella versione sperimentata contiene una frase di avvio che serve a chiarirne la natura, ad esempio un tipico thinking type è “Il mio problema” e quando lo si seleziona compare la frase “Vorrei scoprire come/perché…”. Gli italiani trovano il set predisposto dai finlandesi limitante e non soddisfa la loro abituale tipologia di interventi. Inoltre, la presenza della frase di avvio sembra addirittura essere confondente, piuttosto che costituire un aiuto, cosa comprensibile se si pensa che il modello pedagogico sottostante, da parte degli italiani, è radicalmente diverso rispetto a quello dei finlandesi.

Conclusioni
Studiare lo sviluppo di piattaforme di comunicazione on-line utilizzabili da comunità internazionali significa analizzare il momento in cui diverse culture e prospettive si incontrano e il dialogo che ne scaturisce costituisce il momento privilegiato di indagine. Il progetto ITCOLE costituisce un sistema di attività che potremmo definire glocale in quanto capace di offrire una cornice di lavoro condivisa ma anche di divenire contemporaneamente un luogo dove le differenze dei vari contesti locali emergono in modo strategico.
E’ stato analizzato parte del discorso intercorso all’interno del gruppo di ricerca, individuando momenti critici e cruciali da cui emerge la capacità dialogica dei partecipanti di dare voce a punti di vista e rappresentazioni che, senza le occasioni di dialogo offerte dal progetto, sarebbero rimaste inespresse.
Emerge così come il software stesso, quello che noi abbiamo definito l’artefatto intorno al quale si crea e si sviluppa la comunità di ITCOLE, subisca diverse concettualizzazioni, rappresentazioni non sempre condivise e diversi modi di essere inteso. In particolare, la sua inizializzazione è oggetto di percezioni contrastanti: per i ricercatori psicopedagogici il software nasce nel momento in cui è usato dai suoi utenti finali, mentre per gli sviluppatori il software ha radici più lontane e quando è disponibile ai suoi utenti ha già subito diverse rielaborazioni e fasi di lavoro intermedie.
Abbiamo anche visto come alcune diversità di prospettiva riflettono le differenze nei modelli pedagogici di base che sarebbero rimaste inespresse senza l’occasione di dover creare degli strumenti di lavoro specifici (è il caso dei thinking type).
L’analisi delle “voci” dei partecipanti, delle parole e dei discorsi che avvengono nei momenti d’incontro ci permette di svelare processi, angolature e sfumature altrimenti non accessibili alla riflessione del ricercatore.

Note
(1) Si tratta della versione zero del software.

(2) I mockup sono delle schermate in cui si presenta come sarà l’interfaccia e dove le funzionalità non sono implementate ma semplicemente collegate ipertestualmente a pagine-web successive che permettono di visualizzare il contenuto.

Bibliografia
Bachtin, M. (1986) The problem of speech genres (V. McGee, Trans.). In C. Emerson & M. Holquist (a cura di Speech genres and other late essays (pp. 60-102). Austin: Univ. of Texas Press.

Bruner, J. (1997) The narrative model of self-construction. In J.G. Snowdgrass e R.L. Thompson (a cura di) The self across-psychology. In The New York Academy of Sciences, 818, pp.145-161.

Cole, M. (1996). Cultural Psychology. Harvard: Harvard University Press.
Crook, C. (1994). Computers and the collaborative experience of learning. London: Routledge.

Dillenbourg, P. (1999). Introduction: What do you mean by “collaborative learning”? In P. Dillenbourg (Ed.), Collaborative Learning: Cognitive and computational approaches (pp. 1-19) Amsterdam: Pergamon, Elsevier Science.

Duranti, A. (1992) Etnografia del parlare quotidiano. Roma: La Nuova Italia Scientifica.

Edwards, D., Mercer, N.M. (1987). Common Knowledge: The development of understanding in the classroom. London: Routledge.

Engeström, Y., Miettinen, R., Punamäki, R. L. (1999). Perspectives on Activity Theory, Cambridge University Press.

Fasulo, A., Pontecorvo, C. (1999). Come si dice. Roma: Carocci

Ghiglione, R. (1988). La comunicazione è un contratto. Napoli: Liguori.

Goffman, E. (1981) Forms of Talk. Philadelphia: University of Pennsylvania Press.

Hakkarainen, K. (1998). Epistemology of scientific inquiry in computer supported collaborative learning. PhD dissertation, University of Toronto.

Lakkala, M., Rahikainen, M., Hakkarainen, K. (2001). (a cura di) Perspectives of CSCL in Europe: A Review. Deliverable WP2 per il Progetto Europeo ITCOLE.

Ligorio, M.B. (2002). Guida alla comunicazione virtuale. Napoli: Idelson-Gnocchi.

Ligorio, M.B. (2002a). Apprendimento e Collaborazione in ambienti di realtà virtuale. Roma: Garamond.

Ligorio, M.B. (in stampa) Tecnologia basata sul web per una ricerca cross-culturale dialogica. In M.B. Ligorio (a cura di) Psicologie e Cultura: Contesti, identità ed interventi. Roma: Firera Publish Group.

Ligorio, M.B., Mancini, I. (in stampa) Discu.

ere per costruire in rete. In M.B. Ligorio (a cura di) Modelli formativi e tecnologie in rete. Numero speciale di Rassegna di Psicologia.

Ligorio, M.B., Cesareni C., Mancini I., Talamo, A. (2001). Collaboration, Constructivism, Community: the three “C” for the CSCL in Italy. Deliverable WP2 per il Progetto Europeo ITCOLE.

Renninger, K.A., Shumar, W. (2002). (a cura di), Building virtual communities: Learning and change in cyberspace. New York, NY: Cambridge University Press.

Sacks, H., Schegloff, E. A., Jefferson, G. (1974). A simplest systematic for the organization of turn-taking for conversation. Language, 50, pp. 696-735.

Talamo, A., Zucchermaglio, C. (2003). Inter@zioni. Gruppi e tecnologie. Roma: Carocci.

Van Dijk, T.A. (1993). Principles of Critical Discourse Analysis. Discourse and Society, 3, (1), pp. 87-108.

Young, M. F., Kulikowich, J. M., Barab, S. A. (1997). The unit of analysis for situated assessment. Instructional Science, 25, pp. 133-150.


<< Indietro Avanti >>