• Non ci sono risultati.

Capitolo 2 La nostra proposta: Teatrino, il teatro dei burattini

N/A
N/A
Protected

Academic year: 2021

Condividi "Capitolo 2 La nostra proposta: Teatrino, il teatro dei burattini"

Copied!
22
0
0

Testo completo

(1)

Capitolo 2

La nostra proposta: Teatrino, il teatro dei burattini

L'attività artistica teatrale, rappresenta uno strumento espressivo molto forte perché presenta i sentimenti umani per quello che sono. Lo spettatore è rapito dai dialoghi, dalle musiche dalle scenografie e dai gesti degli attori. Ognuna di queste caratteristiche del teatro, richiede grandi sforzi affinché possa essere messa in atto durante lo spettacolo. Dietro uno spettacolo teatrale, infatti, c'è il lavoro di molte persone le quali si occupano di organizzarlo suddividendosi i compiti in base agli ambiti di competenza. Il teatro scolastico, quello delle recite, mantiene questa forma di suddivisione dei compiti e di solito non rinuncia ad alcuno dei canali attraverso cui avviene la comunicazione con il pubblico: musica, luci, costumi e scenografie mantengono un ruolo importante. In questa prima implementazione dell'attività teatrale virtuale di Teatrino, abbiamo scelto di semplificare il dominio di applicazione del teatro a quello dei burattini. Il teatro diventa quindi un teatrino e i suoi attori sono i burattini con la testa di legno e le due braccia ricavate dalla veste. I movimenti dei personaggi sulla scena sono quindi limitati e la scenografia è essenziale, come nel teatrini dei burattini appunto. La validità didattica di tale applicazione è data non solo dall'esperienza teatrale che già in sé è molto forte, ma anche dall'utilizzo di concetti e strutture tipiche dell'informatica. Come vedremo, Teatrino dà la possibilità di programmare alcuni movimenti dei personaggi che essendo quelli dei burattini, risultano essere abbastanza semplici. Inoltre gli utenti possono comporre questi movimenti per creare delle procedure che possono essere richiamate mentre il personaggio è in scena.

2.1 L'applicazione

Il teatrino virtuale è un'applicazione web (un sito internet) attraverso la quale è possibile scrivere, allestire e mettere in scena un semplice spettacolo di burattini in maniera collaborativa. Per collaborativo s'intende la possibilità, da parte degli utenti di collaborare in maniera concorrente al fine di portare avanti un preciso compito. Lo spirito di Teatrino è quello di unire insieme nell'attività teatrale utenti a distanza, cercando di mantenere intatti i metodi attraverso cui avviene la messa in atto di un piccolo spettacolo teatrale. Il risultato è un ambiente grafico con due dimensioni in cui ogni oggetto è un'immagine opportunamente disegnata in maniera ombreggiata in modo tale da aumentare il senso di profondità. Teatrino avrà poi le schermate necessarie a costruire una storia in rete ed un vera e propria interfaccia grafica che possa rappresentare il palcoscenico dei burattini. Gli utenti target dell'applicazione sono i bambini delle scuole elementari e medie. Ogni utente del

(2)

sito, forma insieme agli altri utenti una sorta di compagnia teatrale virtuale. Tale compagnia di utenti virtuale è costituita da dei sottogruppi di utenti che si trovano nello stesso luogo e davanti alcuni terminali collegati a internet. Si immagina che tali gruppi reali di utenti siano formati da classi delle scuole o da gruppi di gioco-studio delle ludoteche. Ogni gruppo di utenti forma un

gruppo di lavoro che è coordinato al suo interno da un educatore adulto e lo accompagna durante

lo sviluppo della storia e durante la sua messa in scena. Si suppone quindi, che la compagnia teatrale virtuale sia composta da almeno due gruppi di lavoro a distanza.

L'esperienza con Teatrino incomincia quando uno degli educatori dei gruppi di lavoro si fa carico di creare un account sul sito e di pubblicare un titolo per la storia che vuole sviluppare con la sua compagnia teatrale virtuale. Da questo momento tale educatore diventa il coordinatore o regista della storia. Questi si occupa anche di registrare ogni utente bambino specificando a quale gruppo di lavoro appartiene. Non tutti gli educatori dei gruppi devono avere necessariamente un account sul sito come i bambini stessi non devono avere necessariamente tutti un account. Affinché sia permesso ai gruppi di procedere è necessario che un educatore si sia iscritto al sito come coordinatore e che abbia iscritto almeno un utente per gruppo di lavoro – la gestione degli utenti in questa prima realizzazione di Teatrino verrà implementata in maniera minimale.

A questo punto, i gruppi di lavoro interagiscono con l'applicazione in quattro modi differenti. Il primo modo consiste nello scrivere la storia. In questa fase, tutti gli utenti del gruppo di lavoro hanno il ruolo di autori. Ogni gruppo si trova davanti un terminale diverso e possono comunicare con gli altri gruppi di lavoro che sono in remoto attraverso un microfono. Infatti essi potranno ascoltarsi a vicenda e discutere sul tema che si vuole affrontare nella storia. Immaginiamo quindi che i gruppi di lavoro si trovino intorno allo stesso tavolo con un solo foglio di carta vuoto. Su questo foglio verrà scritta la scaletta della storia. Questo foglio condiviso, rappresenta la struttura dati principale dell'applicazione, la storia appunto, che all'inizio è come un foglio bianco che bisogna riempire con dei contenuti. A questo punto, bisogna pensare all'algoritmo che possa raccogliere tutti gli input e organizzarli nella forma di una storia. Ciò che viene naturale pensare, è che l'algoritmo dia a turno la possibilità ad un gruppo di scrivere sul foglio, a partire dall'ultima parte inserita dal gruppo precedente, così come se i gruppi fossero insieme davanti allo stesso foglio. Quindi possiamo immaginare che l'applicazione usi l'algoritmo Round Robin nel dare l'autorizzazione ad un gruppo di aggiungere una parte della storia. Questa autorizzazione è a livello di gruppo di lavoro e non di singolo utente. Sarà quindi compito dei bambini del gruppo di lavoro, decidere chi raccoglierà l'invito di aggiungere un contenuto, con l'aiuto dell'educatore che con loro si trova nello stesso luogo. Un gruppo può anche decidere di non scrivere nulla e di passare il turno. Il contenuto che viene aggiunto può essere una nuova scena o una nuova battuta per un personaggio già esistente. Per ogni personaggio, l'utente ne sceglie anche l'aspetto grafico ossia il burattino che lo rappresenterà. Per ogni scena, l'utente può decidere di inserire un testo descrittivo iniziale e una immagine che verrà usata come sfondo. Questo modo di interagire con l'applicazione termina quando la compagnia teatrale decide che la storia è conclusa. Il coordinatore si occupa di aiutare gli utenti e eventualmente di correggere errori introdotti dagli utenti involontariamente. Il secondo modo di interagire con l’applicazione, consiste nel personalizzare le animazioni dei burattini che gli utenti hanno scelto nella fase precedente per rappresentare i personaggi della storia. La personalizzazione delle animazioni consiste nel comporre i comandi testuali che ogni burattino sa interpretare e che provocano un particolare movimento di una parte del suo corpo. L'applicazione, dà la possibilità in questa fase, di scegliere le dimensioni del burattino e da quale lato del palcoscenico esso entrerà in scena. Il coordinatore non ha alcun ruolo in questa fase.

Il terzo modo di interagire con l'applicazione e con gli altri utenti, è la messa in scena della storia. I bambini, in questa fase attori, si connettono al sito per recitare la storia. Durante ogni scena, i burattini saranno al massimo quattro1. Ognuno di essi sarà animato da un terminale diverso che sarà

in un gruppo di lavoro diverso. Con questa ipotesi, per ogni scena, ogni gruppo di lavoro animerà un personaggio. Tuttavia è possibile pensare che in qualche scena ci sia un numero minore di

1 Questa è solo una scelta di progetto ma che potrebbe dipendere anche dai limiti della rete. Ad ogni burattino in scena corrisponde anche un flusso audio che deve essere supportato dalla rete.

(3)

personaggi rispetto al numero dei gruppi, e in questo caso vorrà dire che alcuni gruppi staranno a guardare. Quindi, se in una scena ci sono n personaggi con n <= M, dove M è il numero massimo di personaggi, al massimo n – 1 saranno animati da utenti di uno stesso gruppo di lavoro. L'altro personaggio dovrà essere animato necessariamente da un terminale di un altro gruppo. Non avrebbe senso che tutti gli n personaggi venissero animati dallo stesso gruppo di lavoro, ossia da terminali che sono nello stesso luogo. In questa fase il coordinatore ha il compito di controllare attraverso l'applicazione che tutti gli utenti siano in linea, e di dare inizio allo spettacolo tramite un apposito bottone. Sarà anche responsabile di far avanzare lo spettacolo di scena in scena, aprendo e chiudendo il sipario. Prima dell'inizio della scena successiva l'applicazione caricherà lo sfondo ed i personaggi della scena in base alle impostazioni scelte nella fase precedente dagli utenti. Gli utenti hanno la possibilità di muovere i burattini attraverso la tastiera e di digitare i comandi del proprio burattino, solo dopo che il sipario sarà aperto.

Si considera possibile un terzo tipo di utente che sarebbe lo spettatore che si connette al sito con un apposito account e assiste alla scena in maniera passiva. Questo utente non ha la possibilità di partecipare alle altre fase di sviluppo della storia ma solo alla messa in scena avendo tuttavia la possibilità di ascoltare gli altri utenti e di usare il microfono per commentare o semplicemente applaudire.

2.2 Descrizione del sito: diagrammi delle attività e casi d'uso

Consideriamo che Teatrino sia usato da tre tipi diversi di utenti: i bambini, il coordinatore e gli spettatori. Supponiamo quindi che un certo numero di classi, vogliano usare Teatrino per un'esperienza di recita on line. Ogni classe forma un gruppo di lavoro e sarà seguito da un educatore. Uno di questi educatori deve allora iscriversi al sito con il ruolo di coordinatore. La figura 1 mostra i casi d'uso di Teatrino da parte dell'utente coordinatore.

(4)

L'attività di pubblicare la storia può essere schematizzata come in figura 2.

Figura 2

Il secondo caso d'uso del coordinatore consiste solo nell'assistere gli altri utenti nella fase di costruzione della storia attraverso l'audio conferenza e eventualmente potrà cancellare parti della scena inserite erroneamente. A differenza degli utenti bambini, il coordinatore può cancellare qualunque parte della storia mentre i bambini possono cancellare solo le parti che hanno creato personalmente. All'inizio il sistema concede in automatico il turno agli utenti di un gruppo di lavoro e dopo di ché ogni utente passa il turno a quello successivo. Vedremo più dettagliatamente più avanti questa situazione.

Nel terzo caso d'uso il coordinatore verifica che tutti gli utenti si siano connessi e a quel punto, ha a disposizione un bottone con il quale può far aprire il sipario. Il coordinatore decide quando una scena è conclusa in base al copione della storia ed è responsabile dell'avanzamento della recita.

(5)

Gli utenti bambini, svolgono anch'essi tre compiti principali che sono riassunti nel caso d'uso di figura 4.

Figura 4 Caso d'uso degli utenti bambini

Il primo caso d'uso dei bambini corrisponde alla fase in cui i bambini costruiscono scena dopo scena la storia. La figura 5 mostra questo caso d'uso scomposto in attività. Inizialmente l'utente attende che sia il proprio turno. Quindi può decidere in base allo stato attuale della storia se aggiungere un'altra battuta per la scena corrente oppure aggiungere una scena nuova. Queste ultime due attività sono descritte nelle figure 6 e 7.

(6)

Figura 6 Aggiungere una scena alla storia, significa scrivere il testo descrittivo e scegliere uno sfondo

Figura 7 Ricevuto il turno, l’utente bambino aggiungere un numero di battute a piacimento .La

prima volta, egli deve specificare anche il nome del personaggio che recita quella battuta.

La scelta della scena consiste nell'aggiungere un altro paragrafo alla storia, insieme ad uno sfondo e ad un testo che può essere necessario a descrivere meglio cosa sta succedendo nella scena. Lo sfondo sarà una semplice immagine di un’ambientazione, che l'applicazione mantiene sul server come risorsa da scaricare. Aggiungere una battuta prevede invece più azioni. Come mostrato nella figura 7, il bambino aggiunge una battuta inserendo il nome del personaggio a cui si riferisce la battuta e il testo della battuta. Poiché un utente anima lo stesso personaggio nel corso della stessa scena, l'utente dovrà inserire il nome del personaggio solo la prima volta. L'utente poi sceglie il burattino con il quale rappresentare il personaggio. Quindi può scegliere di aggiungere una nuova battuta, oppure cedere il turno.

Nel secondo caso d'uso, l'utente gioca con il burattino, provando tutti i comandi che esso sa interpretare. Inoltre può scegliere le dimensioni del burattino e da quale lato del palcoscenico esso apparirà.

Infine, il terzo caso d'uso per il bambino è la recita. Questa fase è semplicemente schematizzata nella figura 8.

(7)

Figura 8

Per quanto riguarda l'utente spettatore si limita invece a partecipare solo alla terza attività, ossia la messa in scena della storia. In questa fase l'utente spettatore assiste passivamente alla scena in corso. Può partecipare però all'audio conferenza avendo appunto un ruolo da spettatore.

(8)

2.3 I burattini

Ogni personaggio della storia creata con Teatrino è rappresentato da un burattino. I burattini degli spettacoli per bambini sono comunemente dei pupazzi fatti con un pezzo di stoffa dentro cui il burattinaio infila la mano. Teatrino implementa i suoi burattini sul modello di quelli reali, come oggetti grafici in due dimensioni. Ogni burattino è un oggetto che è legato ad una serie di immagini che rappresentano tutte le parti del suo corpo in ciascuno dei punti di vista previsti. Un burattino può mostrarsi sia di profilo che di fronte che da dietro. Nella figura 10, si considera il modello di un burattino visto di profilo.

Figura 10 Il burattino è formato da cinque immagini sovrapposte come in figura

Il corpo del burattino è diviso in cinque parti: le due braccia, la testa, il busto e la gonnella che corrisponde quest’ultima a quella parte di stoffa che serve a nascondere il braccio del burattinaio. Ogni componente è come se fosse un giunto che ruota intorno ad un perno e ogni giunto è associato ad una risorsa grafica, un’immagine che disegna la parte del corpo in questione su uno sfondo trasparente. Si vuole che il modello sia il più aderente possibile a quello dei burattini, in modo che l’utente sia cosciente della natura del personaggio che sta animando e quindi non si senta frustrato dai pochi movimenti che esso può compiere. Il braccio allora sarà disegnato come un corpo rigido, che non può piegarsi in due come quello di una persona. Ed infatti nel modello proposto, l’intero braccio viene rappresentato da un solo giunto e quindi da una sola immagine. Tuttavia, si può pensare di disegnare il braccio in modo tale da farlo sembrare già parzialmente piegato. Esso sarà associato comunque ad una sola componente rigida del modello. Perciò, la sua forma rimarrà

(9)

costante. Ognuna di queste parti del burattino può essere mossa con il mouse e la tastiera oppure tramite una serie di comandi testuali. I movimenti possibili riflettono quelli possibili da un burattino vero. Ogni componente del burattino, ruota intorno al proprio perno con un solo grado di libertà (come la maniglia delle porte per fare un esempio). Quindi i comandi testuali saranno due per ogni componente, ed ognuno di essi produce la rotazione di una particolare parte del corpo in un verso intorno al suo perno. Ad esempio l'istruzione “alza_braccio_destro” indica la rotazione del braccio destro in senso orario se il burattino mostra il suo profilo sinistro, e in senso antiorario viceversa. Dato che l’ambiente di sviluppo è 2D, le rotazioni avvengono solo su un piano e i perni attorno cui avviene la rotazione sono perpendicolari al piano dello schermo.

Ogni comando fa riferimento ad una precisa parte del corpo ed il suo nome deve essere univoco. Nel caso in cui il burattino mostra il profilo destro, si immagina di avere i seguenti comandi:

•alza_braccio_destro: fa ruotare il braccio destro fino a farlo puntare verso l’alto, •abbassa_braccio_destro: fa ruotare il braccio destro fino a farlo puntare verso il basso, •alza_braccio_sinistro,

•abbassa_braccio_sinistro,

•alza_testa: ruota la testa in modo che lo sguardo del burattino sia rivolto verso l’alto, •abbassa_testa,

•piegati_in_avanti, piega il busto in modo da far pendere la testa per terra. •piegati_indietro, piega il busto all’indietro.

Se il burattino mostra il profilo sinistro, i comandi hanno lo stesso effetto. Ma cosa succede se il burattino è visto frontalmente? Innanzitutto, le varie componenti grafiche vanno sostituite con quelle che ritraggono le rispettive parti del burattino frontalmente. Ciò richiede che il burattino abbia uno stato che conservi questa informazione e che in base ad esso vengano visualizzate le corrette immagini che ritraggono le varie componenti del corpo dal punto di vista corrente. Quindi se il burattino si mostra di profilo, allora le componenti grafiche visualizzate saranno quelle di profilo altrimenti quelle frontali etc. Inoltre, alcuni comandi come “alza_testa” o ”piegati_indietro”, nel caso in cui il burattino sia visto frontalmente, non sono più riproducibili attraverso la rotazione di un'immagine. In questo caso allora, il burattino non potrà compiere alcun movimento di questo tipo. Tuttavia la potenza dell'ambiente di sviluppo scelto per implementare teatrino - Macromedia Flash - ci permette di usare un artificio che consiste nell'usare dei filmati al posto di immagini statiche. Si considera quindi che la testa del burattino possa essere disegnata frame per frame mentre si abbassa in avanti e che l'esecuzione di questo comando, consista nel riprodurre quel filmato. Nell'implementazione attuale, si è pensato di usare questo meccanismo per le braccia che si chiudono.

(10)

Figura 11 Lo schema delle immagine che ritraggono il burattino frontalmente.

Il burattino sarà capace di eseguire una sequenza di comandi divisi da punti e virgola. Alcuni di essi hanno dei parametri, come ruota_braccio_destro che sono in questo caso il numero di gradi e il verso della rotazione da applicare al braccio destro del burattino.

Componendo opportunamente questi comandi, si possono creare delle animazioni. La sintassi per definire le procedure è:

Procedura ::= to nomeproc: listadicomandi end Nomeproc ::= [a-zA-Z0-9]+

listadicomandi ::= comando; {comando} comando ::= alza_braccio_destro |abbassa_braccio_destro |alza_braccio_sinistro |abbassa_braccio_sinistro |alza_testa |abbassa_testa |piegati_in_avanti |piegati_indietro |ruota_braccio_destro( numero,numero) |ruota_braccio_sinistro( numero,numero) numero ::= [0-9]+

(11)

Una procedura ben definita può essere: to LaMiaAnimazione: alza_testa; alza_braccio_destro; abbassa_braccio_destro; ruota_braccio_sinistro(-45,-1); abbassa_testa; ruota_braccio_sinistro(0,1); end

Il burattino non ha però visibilità delle procedure. Esso riceve solo una lista di comandi che vengono eseguiti in sequenza nel caso in cui riguardino la stessa parte del burattino. Altrimenti, verranno eseguite contemporaneamente. Le rotazioni avvengono con una certa velocità che in alcuni comandi può essere impostata. Nella lista di istruzioni vista sopra, ruota_braccio_sinistro viene svolto con la velocità uguale a -1 – il segno indica il verso della rotazione. Consideriamo la seguente lista di comandi:

1. alza_testa; 2. alza_braccio_destro; 3. abbassa_braccio_destro; 4. ruota_braccio_sinistro(-45,-1); 5. abbassa_testa; 6. ruota_braccio_sinistro(0,1);

Il comando 3 introduce una dipendenza logica sul comando 2, perché per essere eseguito deve attendere che il comando numero 2 sia terminato. Lo stesso vale ad esempio per il 6 con il 4 e per il 5 con il comando 1. L’esecuzione di questa lista di comandi avviene come se venisse scomposta in tre liste di comandi.

I comandi delle tre liste vengono eseguiti contemporaneamente ma all’interno di una lista, ogni comando deve attendere che sia terminato quello precedente. Le tre liste risultanti dall’esempio sono:

1. alza_testa; <- abbassa_testa;

2. alza_braccio_destro; <- abbassa_braccio_destro;

3. ruota_braccio_sinistro(-45,-1); <- ruota_braccio_sinistro(0,1);

che possiamo visualizzare in forma di matrice in questa maniera:

alza_testa abbassa_testa

alza_braccio_destro abbassa_braccio_destro ruota_braccio_sinistro(-45,-1) ruota_braccio_sinistro(0,1)

(12)

comando di una riga, dipende da quello della riga precedente.

2.4 Un modello per rappresentare la storia

Possiamo definire una recita come una successione di scene, ognuna delle quali è caratterizzata da una scenografia, un insieme di personaggi e per ognuno di essi, una serie di battute. La figura 12 mostra come tutto ciò può essere schematizzato con una struttura ad albero.

Figura 12 Una storia rappresentata in maniera schematica.

Possiamo considerare l'albero della figura 12 come lo schema dei metadati necessari a rappresentare in maniera sistematica una recita. Facciamo un esempio considerando lo stesso schema della figura 12 con un semplice testo che potrebbe essere la parte iniziale di una storia.

C'erano una volta Teddi e Pegghi, due simpatici pinguini della terra Strabiliosa. Un giorno come tanti altri, Taddi e Pegghi s'incontrarono in campagna.

Allora Taddi disse:”Ciao Pegghi come stai?”

Pegghi rispose:”Bene Teddi. Sai che sto per andare alla ricerca di un tesoro?” Taddi:”Davvero?”.

Pegghi:”Sì, sono in possesso di una mappa segreta...”

Taddi e Pegghi partirono insieme alla volta della terra del Sud. Il cammino fu duro e pieno di insidie....

Teddi disse:”Eh! Che stanchezza!”

Poi aggiunse:”Propongo di fermarci e riposare.”

E Pegghi rispose:”Sono d'accordo. Non ce la faccio più” ...

(13)

Figura 13 Albero della storia di cui sopra.

Nella figura 13, il testo diventa una serie di nodi che modellano le entità del dominio, con al loro interno i dati della storia.

XML è la soluzione più facile e flessibile da usare per definire i metadati. Il seguente DTD genera un linguaggio, chiamiamolo Storie, che viene usato da Teatrino per descrivere una storia.

<?xml version="1.0" encoding="UTF-8"?> <!ELEMENT tale (scene+)>

<!ATTLIST tale

xmlns CDATA #IMPLIED label CDATA #IMPLIED coordinator CDATA #IMPLIED storyId CDATA #IMPLIED maxId CDATA #IMPLIED>

<!ELEMENT scene (backimage, text, cue+, characters)> <!ATTLIST scene

label CDATA #REQUIRED id CDATA #REQUIRED> <!ELEMENT backimage EMPTY> <!ATTLIST backimage

label CDATA #REQUIRED filename CDATA #REQUIRED id CDATA #REQUIRED> <!ELEMENT text (#PCDATA)> <!ATTLIST text

label CDATA #REQUIRED id CDATA #REQUIRED> <!ELEMENT cue (#PCDATA)> <!ATTLIST cue

label CDATA #REQUIRED owner CDATA #REQUIRED id CDATA #REQUIRED> <!ELEMENT characters (character+)>

(14)

<!ATTLIST characters

label CDATA #REQUIRED id CDATA #REQUIRED> <!ELEMENT character (action+)> <!ATTLIST character

label CDATA #REQUIRED owner CDATA #REQUIRED filename CDATA #REQUIRED side CDATA #REQUIRED scale CDATA #REQUIRED id CDATA #REQUIRED> <!ELEMENT action (#PCDATA)> <!ATTLIST action

id CDATA #REQUIRED label CDATA #REQUIRED>

Una storia è quindi una sequenza di nodi scena, ognuno dei quali ha come figli i nodi backimage, text, cue e characters. Il nodo characters contiene i tag character che servono a contenere l’informazione riguardante il burattino scelto per rappresentare il personaggio, e alcune caratteristiche come le dimensione ed il lato dello schermo da cui il burattino deve entrare durante la recita. Queste informazioni possono cambiare di scena in scena ed è per questo che il nodo characters è presente per ogni scena. I nodi battuta - cue – sono generalmente più di uno per ogni personaggio.

Il linguaggio Storie contiene anche i comandi che i burattini comprendono. Questi comandi sono in formato testuale e sono contenuti dentro il tag action. Ricapitolando, i nodi XML sono:

• <tale label=”NomeDellaStoria” >, è il nodo radice che contiene tutta la storia • <scene label=”NomeDellaScena” >, il nodo scena

• <backimage label=”Sfondo” filename=”NomeFile” >, il nodo che descrive lo sfondo attraverso il nome del file dell’imamgine.

• <text>testo</text>, contiene il testo introduttivo alla scena

• <cue label=”” owner=”NomeUtente”>testo</cue> , contiene il testo della battuta ed è associato ad un personaggio della scena tramite la label e all’utente che l’ha recita attraverso owner.

• <characters>, raggruppa i nodi dei personaggi nella scena corrente. • <character label=”NomePersonaggio”

owner=”NomeUtente”

filename=”NomeBurattino”

side=”latoDellaScena”

scale=”scala”> ,

il nodo che descrive il personaggio attraverso il nome del burattino, il lato della scena da cui esso deve apparire e le dimensioni espresse in percentuale.

• <action label=”NomeAnimazione”>lista di comandi</action>, contiene una lista di comandi in forma di testo separati da punti e virgola, eseguibili dal burattino.

(15)

L’esempio visto nella figura 13 viene quindi rappresentato in XML come:

<talelabel='Favola' > <scenelabel='Prima scena' >

<backimagelabel='Sfondo' filename='Notte' /> <textlabel='Testo di Intro' >

C'era una volta Teddi e Pegghi, due simpatici pinguini della terra Strabiliosa. Un giorno come tanti altri s'incontrarono. ( Si apre il sipario )

</text>

<cuelabel='Teddi' owner='Andrea' > Ciao Pegghi come stai? </cue> <cuelabel='Pegghi:' owner='Marco' >

Bene Teddi,sai che sto per andare alla ricerca di un tesoro? </cue>

<cuelabel='Teddi' owner='Andrea' > Davvero?! </cue> <cuelabel='Pegghi' owner='Marco’ > Sììì!! </cue> <characters label=Burattini' >

<characterlabel=' Teddi ' owner='Andrea' filename='PinguBlue' side='right' scale='50' /> <characterlabel='Pagghi' owner='Marco' filename='PinguNero' side='left' scale='50' >

<actionlabel='Stupisciti'>

piegati_indietro;alza_braccio_1;alza_braccio_2; </action> </character> </characters> </scene> </tale>

2.5 Le user interface e le metafore dell'applicazione

Vediamo ora come le attività fino ad ora descritte vengono implementate attraverso le interfacce. Nella figura 14, è riportato uno schema logico delle interfacce che servono per realizzare Teatrino.

(16)

Figura 14 Mappa del sito Teatrino.

Ci occuperemo nei prossimi paragrafi di scendere nei dettagli delle interfacce per la recita e la stesura della storia.

2.5.1 Creare una storia: il Tale Editor

L'interfaccia della stesura della storia, che d'ora in avanti chiameremo TaleEditor, è quella su cui viene costruita la sceneggiatura della recita. TaleEditor ricorre all'artificio dell'albero per schematizzare la storia in costruzione: ogni nodo dell'albero rappresenta un'entità del dominio delle recite, e ne modella le proprietà.

L'interfaccia TaleEditor si occupa di gestire gli input degli utenti al fine di creare:

testo di introduzione: l'utente può inserire un testo che serve da introduzione alla scena e che

verrà letto dall'utente coordinatore.

sfondo: l'utente può sfogliare una serie di immagini e sceglierne una da applicare come fondale

per la scena.

battute dei personaggi: l'utente sceglie di aggiungere quante battute vuole per il suo

personaggio

i personaggi: l'utente sceglie il burattino che rappresenterà il suo personaggio nella recita.

(17)

Possiamo quindi definire una recita come una successione di scene, ognuna delle quali è caratterizzata da una scenografia, un insieme di personaggi e per ognuno di essi, una serie di battute. Nella figura 12 abbiamo visto come una storia può essere schematizzata con una struttura ad albero. Usando Teatrino, non è necessario che il testo della storia venga scritto per intero come si è visto nell'esempio di Teddi e Pegghi. S'immagina che gli utenti inventino estemporaneamente una storia e senza scriverla, la traducano nel linguaggio ad albero che viene visualizzato dall'interfaccia. TaleEditor assiste l'utente in questa attività, scomponendo il processo di traduzione dal testo all'albero, in passi semplici. Ecco la sequenza dei passi svolti dall'interfaccia:

0. inizialmente, mostra l'albero della storia con il nodo radice denominato con il nome della storia. Questo nodo non ha ancora figli perché non è stata creata alcuna scena.

1. Consente di aggiungere una scena. L'interfaccia aspetta che l'utente immagini una scena da aggiungere alla storia. Per ogni nuova scena creata, la maschera permette all'utente di inserire un titolo, un 'immagine che faccia da fondale scenografico, e se necessario anche un testo introduttivo alla scena.

2. Consente di aggiungere una battuta. L'interfaccia chiede di inserire il nome del personaggio che recita la battuta solo la prima volta. Se il nome non è stato usato precedentemente, allora significa che l'utente sta introducendo un nuovo personaggio nella storia. Ciò implica la creazione di un nuovo nodo character per quel personaggio nella cartella corrispondente da parte di TaleEditor. Il nome del personaggio viene richiesto solo all’inserimento della prima battuta perché per ogni scena l’utente può creare soltanto un solo personaggio. Quindi, nelle volte successive, TaleEditor userà il nome già inserito in precedenza per etichettare le battute.

a)Se l'utente vuole aggiungere un'altra battuta, l'interfaccia glielo permette ritornando al passo 2.

b)Se l'utente vuole aggiungere una nuova scena, si ritorna al passo 1.

Bisogna tuttavia considerare che questa è un'attività che non viene svolta da una sola interfaccia ma da tante quante sono i client che partecipano alla creazione della storia. Questo richiede che venga aggiunto un altro passo che l'interfaccia deve eseguire e che corrisponde all'implementazione dell'algoritmo di collaborazione. Aggiungiamo quindi un altro passo:

3.Consente all'utente di passare il turno

Inoltre è necessaria una condizione preliminare al passo 1 ossia verifica che l'utente abbia il turno di aggiungere alla storia.

(18)

Figura 15

Tale Editor è composta quindi da:

•un albero che visualizza la storia come nella figura 14

•un area di testo per inserire il titolo della scena o il nome del personaggio

•un'area di testo per inserire il testo introduttivo per una scena o il testo di una battuta

•un'area per visualizzare le immagini degli sfondi e dei burattini.

(19)

Figura 16 Interfaccia di visualizzazione della Storia o Tale Editor. In alto a destra si può vedere un icona che mostrerà se il client ha il turno per scrivere sulla storia.

Questa interfaccia modifica la storia utilizzando i seguenti bottoni:

Aggiungi Scena: il bottone si attiva solo se l'utente ha selezionato il nodo “scene” nell'albero.

Una volta premuto, il bottone aggiunge una scena in coda alla storia.

Aggiungi Battuta: il bottone si attiva quando l'utente ha selezionato un nodo “scena”

nell'albero. Ciò implica che se non esistono ancora nodi scena, non è possibile aggiungere battute. Supponendo che ci sia quindi un nodo scena selezionato, il tasto “Aggiungi Battuta”, se premuto, attiva le due aree di testo che servono per inserire il nome del personaggio che recita la battuta (nota: il nome del personaggio è indipendente dal nome dell'utente), e il testo della battuta. Se è la prima volta che si inserisce una battuta per quel particolare personaggio, allora la maschera creerà un nodo burattino nella cartella Burattini.

Tutti i nodi inseriti possono essere modificati o cancellati solo dall'utente che li ha creati ad eccezione dell’utente coordinatore che può invece cancellare tutto.

(20)

2.5.2 Animare i burattini

Teatrino offre un’interfaccia per provare e giocare con i comandi dei burattini prima che avvenga la recita vera e propria. L'interfaccia che si chiama CharaceterEditor, viene invocata dopo aver scelto un burattino nel TaleEditor e sarà organizzata come in figura 17.

Figura 17 Il character Editor.

L’interfaccia è un semplice editor dove possono essere digitati i comandi dei burattini. La lista dei comandi viene mostrata in un menù a tendina. Si può pensare che tutti i comandi vengano presentati in una lista, con al fianco una breve descrizione del comando. Attualmente non è necessario perché i nomi dei comandi sono stati pensati per essere auto esplicativi.

L’interfaccia quindi prende come parametro il nome di un burattino da visualizzare e scarica il personaggio dal server visualizzandolo sullo schermo. L’utente poi usa questa interfaccia per esplorare e provare tutte i comandi di cui il burattino dispone. L’interfaccia si occupa di leggere i comandi che l’utente scrive nell’area di testo e di invocare il metodo del burattino che interpreta i

(21)

comandi.

L'utente può scrivere e salvare le procedure formate da una lista di comandi del burattino.

Abbiamo visto che queste procedure vengono memorizzate dentro il nodo action di Storie. L’interfaccia infatti crea un nuovo nodo XML per ogni procedura definita dall’utente. Il nodo creato viene inserito dal CharacterEditor come un figlio del nodo character corrente.

2.5.3 Recitare la storia

La recita di una storia avviene attraverso tre maschere diverse. Ogni client infatti specializza la propria interfaccia per la recita, in base al ruolo che ha l'utente corrente nella storia. I tre ruoli sono quello dell'attore, del coordinatore e dello spettatore. A questi tre ruoli corrispondono quindi tre interfacce che presentano lo stesso aspetto grafico e cioè un teatrino. Le interfacce avranno anche dei controlli per gestire il microfono che cattura l'audio e verrà riprodotto sugli altri client attraverso il server.

Il coordinatore ha il compito del regista della recita ed è colui che apre e chiude il sipario. L'attore è colui che anima un burattino in una scena e l'interfaccia che usa è mostrata nella figura seguente:

(22)

L'utente attore muove il burattino attraverso la tastiera e il mouse solo dopo che il sipario si è aperto. Tutte le battute della scena corrente sono riportate in un area di testo non modificabile. L'utente può inviare comandi al burattino tramite dei tasti oppure può scriverli in un'area di testo analoga a quella del CharacterEditor. Nel menù a tendina sono riportati i comandi e anche tutte le procedure definite per quel burattino dall'utente attraverso il CharacterEditor.

La figura 18 mostra l'aspetto dell'interfaccia a sipario chiuso. L'apertura del sipario è controllata dall'interfaccia del coordinatore che è analoga a quella dell'attore tranne che presenta dei bottoni per controllare l'avanzamento della scena. Il sipario viene aperto e chiuso per ogni scena. Si prevedono quindi nell'interfaccia del coordinatore due bottoni per aprire e chiudere il sipario insieme ad altri due pulsanti per far avanzare la storia alla prossima scena o per sospendere definitivamente la recita. S'immagina infatti che sia possibile riaprire il sipario senza cambiare scena in modo tale da ripeterla nel caso si ritenga necessario.

Figura 19 Dettaglio dell’interfaccia per la recita del coordinatore. In basso a sinistra, si vedono i pulsanti per controllare l’andamento della recita.

Dato che il coordinatore non anima nessun burattino, l'interfaccia non ha controlli specifici che riguardano i burattini.

L'utente spettatore è colui che interagisce durante la scena solo attraverso il microfono. Assisterà alla recita potendo commentare e applaudire. L’interfaccia per la recita dello spettatore sarà priva di controlli.

Indipendentemente dal ruolo dell’utente corrente, l’interfaccia per la recita avrà un pulsante per gestire l’audio conferenza, potendola attivare e disattivare.

Figura

Figura 1 Caso d'uso dell'utente coordinatore.
Figura 4 Caso d'uso degli utenti bambini
Figura 13 Albero della storia di cui sopra.
Figura 18 L’interfaccia per recitare la storia detta ActorStage.
+2

Riferimenti

Documenti correlati

Con queste due pietre miliari si può confrontare il primo spettacolo citato in apertura, l’Iliade vista al Teatro Libero: un collage di versi omerici, con ‘raccordi’ aggiunti

According to Directive 2003/88/EC, the Member States have to ensure the entitlement of every worker to a minimum rest period of 11 consecutive hours per 24-hour period, a

The project addresses the role of civil society organizations (CSOs) in democratization processes, bridging social science approaches to social movements and democracy. The

caine induced rhabdomyolysis is caused by either va- sospasm with muscular ischemia, hyperpyrexia, seizures, coma with muscle compression or direct myofibrillar damage

Assenza congenita di uno o entrambi gli arti Assenza congenita di uno o entrambi i piedi Anomala brevità delle dita di mani e piedi Arto incurvato Flessione permanente mediale

E proprio per non esser-si placato, perché l'incontro con la 'vergine dissoluta' non si era trasformato nel letterale godimento 'dissoluto' di una relazione extraconiugale; proprio

“Dai negozianti alle forze dell’ordine, dagli operatori specializzati alle associazioni, dai volontari alle comunità sorte intorno ai luoghi di culto, dagli studenti fino a

L’obiettivo della tesi è stato quello di realizzare un’applicazione didattica per permettere a utenti in rete di collaborare al fine di inventare una storia, e metterla in