UNIVERSITA’ DEGLI STUDI DI...

UNIVERSITA’ DEGLI STUDI DI TRENTO Facoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea

INFORMATICA

Final Thesis

PATTERN DIDATTICI PER LAVAGNE INTERATTIVE

MULTIMEDIALI: UN AMBIENTE PER LO SVILUPPO DI

WIDGETS

Relatore/1st Reader: Laureando/Graduant:

RONCHETTI MARCO MARCHESONI MICHELE

Anno accademico 20102011

1

Indice

Introduzione...................................................................................................5Capitolo 1 - Quadro generale........................................................................7

La nuova didattica multimediale.......................................................................8Le LIM e WIILDA..................................................................................8I LO.........................................................................................................9Software per LIM....................................................................................10

Strumenti per la Didattica..................................................................................13I Pattern Educativi...................................................................................13La ricerca e la scelta di pattern educativi................................................14

Organizzazione del progetto...............................................................................14Interoperabilità degli strumenti...............................................................14Widget, Template e costruttore di Widget...............................................16Configurazione Manuale di Widget........................................................17Configurazione Guidata di Widget..........................................................17

Scelte Architetturali.............................................................................................18Javascript per Widget e Costruttore.........................................................18Costruttore di Widget..............................................................................19Il ToolKit GWT.......................................................................................20Frameworks e librerie per GWT.............................................................20APIs Google............................................................................................21

Capitolo 2 – Pattern e Strumenti.................................................................23Interfaccia comune a tutti i Widget...................................................................24Pattern Concetto-Contenuto...............................................................................25

Widget Parola-Contenitore .....................................................................25Widget Immagine-Contenitore................................................................28

Pattern Hot-Spot Image......................................................................................31Widget Hot-Spot Image...........................................................................31

Pattern Complete-Story......................................................................................34Puzzle....................................................................................................................37

Pet-Square...............................................................................................37Pattern Grafico....................................................................................................39

Widget Grafico a Torta............................................................................40Widget Grafico a Linee...........................................................................41Altri Grafici.............................................................................................43

Altri Strumenti.....................................................................................................43Easy Sum.................................................................................................43External Web-App...................................................................................44

Altri Pattern.........................................................................................................45Ordinamento logico sequenza ................................................................45Analisi morfologica o Sintattica..............................................................45Analisi oggetto........................................................................................46

Capitolo 3 – Implementazione....................................................................47I Widgets...............................................................................................................48

Configurazione per Sankorè 3.1..............................................................48

3

Configurazione per Google-Chrome ......................................................49Configurazione per Firefox.....................................................................50Una base comume per lo sviluppo di Widget..........................................50Dati..........................................................................................................51Dati Aggiuntivi........................................................................................51

Il costruttore di Widgets.....................................................................................52MockUp...................................................................................................53Il pannello comune..................................................................................54Il Back Button.........................................................................................55La struttura collettiva dei WidgetBuilder................................................56La gestione dell'Utente............................................................................56Operazioni Utente....................................................................................57La Comunicazione Client-Server............................................................58Il metodo SendXmlPattern......................................................................59La sessione utente....................................................................................60La gestione dei file..................................................................................61I Templates sul server..............................................................................62La creazione del Widget..........................................................................62L'Upload..................................................................................................63

Caricamento da Locale................................................................................64Caricamento da Web....................................................................................65

Distribuzione e Installazione dell'applicazione.......................................66Conclusioni e Next Steps............................................................................68Bibliografia..................................................................................................70

4

IntroduzioneLa diffusione nelle scuole italiane di lavagne interattive multimediali è un fenomeno che

da alcuni anni risulta in forte crescita, supportato anche dall'introduzione di nuovi

sistemi a basso costo, come ad esempio quello che sta promuovendo nelle scuole

primarie trentine il progetto Wii4dida, del quale andrà a far parte tutto il lavoro svolto e

descritto nel seguente elaborato.

Come prima cosa si è deciso di iniziare con la ricerca di concetti educativi,

schematizzabili in pattern specifici dai quali sono poi stati sviluppati vari Widgets

Didattici. Quest’ultimo termine sta ad indicare un'applicazione grafica interattiva

pienamente funzionante, sia su una piattaforma Interactive Whiteboard, che su un

semplice personal computer. La nuova tendenza del Web 2.0 che permette di portare le

funzionalità e l'interattività di un'applicazione desktop sul web, con il vantaggio di

renderne l'esecuzione indipendente dal sistema operativo, ha direzionato la scelta

architetturale dei Widget verso l'HTML e Javascript.

In realtà questo non è stato l'unico motivo, l'obiettivo principale era infatti quello di

sviluppare degli strumenti caricabili ed utilizzabili come Learning Object all'interno di

un ambiente per la creazione e la presentazione di lezioni in una lavagna interattiva

multimediale. L’applicazione che più di ogni altra corrisponde ai requisiti richiesti è

risultata essere Sankorè 3.1, un progetto francese opensource ed in continuo

aggiornamento, che presenta nel core un browser web e offre quindi la possibilità di

caricare LO in formato web application.

Gli obiettivi che mi sono prefissato di raggiungere con la stesura di questo elaborato

consistono nella descrizione dettagliata delle politiche di scelta dei Patterns e dei relativi

Widgets, nella discussione delle scelte architetturali ed implementative dei componenti

utilizzati e nell’offrire degli spunti al lettore per delle possibili espansioni future.

Nella prima parte della tesi ho cercato di fornire tutti i concetti necessari per una

migliore comprensione del progetto, il tutto ad un livello piuttosto superficiale, senza

entrare nei dettagli. Dopo una panoramica sulle LIM e sui software a loro associati, ho

quindi analizzato il criterio con cui si sceglie un pattern e la struttura di un Widget,

soffermandomi in particolare sulla sua divisione in Template+Dati e sulla necessità di

5

fornire un software che ne permetta la personalizzazione: il Costruttore di Widgets.

L'ultimo paragrafo è dedicato alle tecnologie utilizzate nell'implementazione di tutti i

componenti necessari: Template, Dati, Widget e Costruttore di Widget.

Nella sezione centrale ho cercato di approfondire più in dettaglio ogni singolo pattern

didattico ideato: ne descrivo le caratteristiche e analizzo i vari Widgets da esso derivati,

specificando funzionalità, interattività, specifiche implementative, servizi offerti

all'utente e un'anteprima della user-interface.

Abbassando sempre di più il livello di astrazione e affrontando l’argomento sotto un

punto di vista molto più pratico, si arriva al capitolo più tecnico della tesi in cui sia i

Widget che il Costruttore vengono smontati pezzo per pezzo e vengono rivelate le

funzionalità di ogni loro singola parte, spiegando perché è stato scelto quel tipo di

percorso implementativo piuttosto che un altro. La maggior parte del capitolo è dedicata

al Costruttore, che svolge un ruolo centrale nel progetto poiché permette una

personalizzazione guidata di tutti i Widget Didattici sviluppati.

Il mio lavoro si conclude con il capitolo quarto, nel quale vengono proposte delle

possibili espansioni future dell’applicazione per ampliare la gamma di strumenti

realizzabili e in cui vengono esposti i prossimi passi da compiere dallo stato attuale del

software verso un futuro di miglioramenti ed evoluzioni.

6

Capitolo 1 - Quadro generale

Nel seguente capitolo andrò a discutere i concetti di base sui

quali oggi si sta muovendo la nuova didattica multimediale,

concentrandomi in particolare sulla LIM e sui LO.

Successivamente focalizzerò la mia attenzione su quello che sarà

l’argomento principale di questo progetto, i Widget per la

didattica , definendo quindi il concetto di pattern e

analizzandone lo sviluppo nell’ambito degli strumenti didattici e

le politiche scelte per la loro realizzazione.

Nell’ultima parte del seguente lavoro cercherò infine di discutere

le scelte architetturali, sia dal punto di vista

dell'implementazione dei Widget che da quello del Costruttore di

Widget, analizzando l’argomento un po’ più nel dettaglio.

7

La nuova didattica multimediale

Le LIM e WIILDAUna lavagna interattiva multimediale (LIM) è uno strumento didattico di notevole

potenza, derivato da un computer e da un proiettore. Il suo obiettivo principale consiste

nel migliorare la qualità dell’insegnamento all’interno delle scuole da parte dei

professori e nel rendere più efficace il processo di apprendimento da parte degli

studenti. Grazie alle possibilità offerte da questo strumento, la lezione scolastica può

essere supportata da oggetti multimediali di qualsiasi tipo, garantendo un livello di

attenzione più duraturo e continuo e facilitando notevolmente la comprensione degli

alunni. L’insegnamento risulterà quindi molto più interattivo e la partecipazione alle

lezioni sarà ulteriormente facilitata dalla possibilità degli studenti di interagire in modo

diretto sui contenuti, con il semplice uso delle dita o di penne ad inchiostro digitale.

Tipicamente una LIM proietta l'output video di un computer su una superficie dalle

dimensioni di una lavagna classica, sulla quale è possibile disegnare o simulare le azioni

del mouse utilizzando dei pennarelli ad infrarossi o un sistema “touch screen”.

Possiamo quindi facilmente intuire che la gamma di possibilità offerte da questo

strumento è davvero vastissima: con un solo strumento possiamo infatti rimpiazzare

registratori, stereo, televisori, lavagne luminose e quant'altro veniva utilizzato in classe

nell'insegnamento multimediale. La LIM può essere utilizzata per riprodurre video e

audio, per visualizzare immagini, testi o presentazioni, per navigare tra contenuti web e

avviare applicazioni di qualsiasi genere, con la possibilità di interagire con i contenuti

ogni qual volta lo si desideri.

La nascita del primo modello di LIM risale al 1991, già qualche anno dopo in stati come

gli USA e il Regno Unito sono stati avviati dei progetti statali per favorirne la

distribuzione nelle scuole, da questo momento in poi molti altri paesi hanno iniziato ad

adottare questo tipo di supporto da affiancare l'insegnamento. Tra questi paesi non si

può purtroppo annoverare l'Italia, dove la loro diffusione è stata avviata con dei progetti

regionali in cui lo stato è intervenuto stanziando dei fondi solo nel 2007.

Tra questi progetti in Trentino troviamo il cosiddetto SLIM4DIDA (Supporto

8

all'introduzione di lavagne interattive multimediali per la didattica), che ora è diventato

Wii4DIDA. Quest'ultimo sta promuovendo negli istituti primari trentini l’utilizzo della

WiiLD (WiiMote Lavagna Digitale), un tipo di lavagna molto economica, che utilizza

come elemento principale di funzionamento il telecomando della console Wii di

Nintendo. Oltre alla caratteristica di economicità, questa lavagna si distingue per la

capacità di funzionare utilizzando solamente software libero, dettaglio che la rende uno

strumento molto adattabile e che favorisce anche la diffusione di programmi OS (open-

source), che nelle scuole italiane è ancora molto limitata.

Sarà proprio al suddetto progetto che andrà successivamente ad agganciarsi il lavoro che

descriverò in questo elaborato.

Andiamo ora ad analizzare un altro termine ormai di uso comune nell'ambito della

nuova didattica (Learning Object) e che ci servirà per comprendere meglio il capitolo

successivo, dedicato al software per LIM.

I LOI Learning Object (LO) si possono definire come delle risorse digitali che vengono

utilizzate nell'insegnamento, e devono rispettare le seguenti regole:

• devono essere formati da uno o più elementi minimi, i quali possono essere un

immagine, un video, del testo, etc. (Autoconsistenza);

• devono essere aggregabili con altri LO (Modularità);

• devono essere reperibili attraverso l'utilizzo dei metadati (Reperibilità);

• devono essere riusabili;

• e infine devono essere in grado di funzionare su diverse piattaforme.

Come vedremo in seguito anche i Widget in Javascript essendo dei LO dovranno

sottostare ai punti sopra citati.

Può essere definito “Learning Object” ogni tipo di risorsa digitale che può essere

riutilizzata per l'insegnamento.

Andiamo ora ad analizzare più nel dettaglio come deve essere strutturata una risorsa per

poter essere definita riutilizzabile.

Una caratteristica chiave è la presenza di metadati, e cioè di informazioni esterne al

contenuto didattico ma che risultano essere necessarie per la sua descrizione e per la sua

9

classificazione. Essi forniscono le indicazioni necessarie per la ricerca dei contenuti: ad

esempio nel caso di un libro, l'autore e il titolo ci rinviano a un ben definito LO libro,

ecco quindi che autore e titolo possono essere considerati dei metadati.

Oltre ad informazioni sul contenuto questi particolari dati ci permettono di reperire gli

oggetti didattici all'interno dei Repository di LO. Questi sono degli archivi digitali che

hanno la funzione di immagazzinare e catalogare, utilizzando appunto i metadati,

qualsiasi oggetto didattico descritto correttamente. Ovviamente sarà poi possibile

ricavare uno specifico strumento attraverso una ricerca all'interno di questi descrittori,

senza dover entrare per forza nel contenuto.

Il punto di forza di un LO sta quindi nella sua riusabilità, che supera il precedente

concetto di e-learning dove la creazione di materiale didattico era vista in modo

monolitico, il docente crea un corso, lo sviluppa e lo utilizza. Ora invece possiamo dire

che il docente cerca un corso, lo sviluppa e lo utilizza oppure crea un corso, lo sviluppa

e lo condivide.

Software per LIMCome dicevo in precedenza la LIM per funzionare ha bisogno di un computer;

solitamente si tratta un normale lap-top e di conseguenza qualsiasi programma che

funziona sul pc in questione verrà anche riprodotto dalla lavagna interattiva, con l’unica

limitazione data dal fatto che interazioni complesse come il “doppio-click” o il “click-

destro” del mouse possono venire interpretate in modo sbagliato o non essere

considerati.

Per ovviare a questo problema esistono quindi dei software appositamente studiati per

funzionare solo con interazioni semplici e che permettono al docente di creare la propria

lezione multimediale dandogli la possibilità di inserire svariati tipi di Learning Object e

mettendo a sua disposizione delle palette di strumenti (marcatore, pennarello,

zoom,ritaglio, interazione) per modificare, prendere appunti o evidenziare delle parti

durante la lezione.

Per facilitare la comprensione dell’argomento ho deciso di supportarlo con un esempio

pratico, confrontando brevemente due di questi software: il primo, il più diffuso

nell’ambito scolastico è Smart Notebook e si tratta di un software proprietario, mentre

10

l'altro, Sankorè 3.1 (ex Uniboard), è un progetto open-source, ed è proprio questo che

ho scelto come ambiente dove utilizzare i Widget in Javascript. Sankorè è anche il

programma scelto dalla Francia per supportare un progetto di l'alfabetizzazione e di

educazione in Africa, che mira a distribuire delle lavagne multimediali economiche

basate proprio sull’utilizzo di Sankore 3.1.

Dopo aver installato ed eseguito i due SW per LIM risulta subito evidente la maggiore

differenza tra i due: l'interfaccia grafica. Il prodotto Smart infatti si presenta sullo stile

di Windows, come un editor dove prima si crea la lezione e poi si lancia la sua

presentazione, un po’ come avviene nel caso di PowerPoint. Per quanto riguarda

Sankorè invece, è evidente una forte impronta dello stile Mac nella grafica delle icone e

l’interfaccia grafica del programma appare più come una sorta di globale integrazione

tra l’azione di creazione e quella di presentazione. È ancora presente il menu con i suoi

vari strumenti ma tutto risulta essere più accorpato all’interno della pagina/lavagna

(nera o bianca a scelta), proprio come se le palette fossero il porta gessetti di una

lavagna tradizionale.

Tralasciando le varie funzionalità di base, le palette contenenti marcatori, pennarelli,

zoom e la possibilità di vedere il desktop con una palette di strumenti che, anche se

organizzati diversamente permettono di fare cose molto simili, andrei ad approfondire i

tipi di Learning Object supportati da entrambi.

Riporto il confronto nella tabella sottostante:

Formato LO Smart Sankorè Note

Testo SI SI

Entrambi offrono la possibilità di scegliere colore, carattere, dimensione e stile. Smart permette anche di inserire formule matematiche.

Immagini SI SI Entrambi supportano gli standard più comuni per le immagini, in più Smart permette anche di importare immagini da uno scanner.

11

Formato LO Smart Sankorè Note

Video SI SI Smart supporta solo video in formato flash, mentre Sankorè accetta qualsiasi tipo di video, purchè sia presente il codec sulla macchina utilizzata.

Testi PDF SI SI Entrambi permettono l'importazione di documenti PDF.

Grafici SI NO In Smart è presente una procedura guidata per la creazione di grafici di vario genere.

Suoni SI NO In Sankorè non è possibile inserire suoni, nonostante supporti l'inserimento di video.

App. Flash SI SI Smart presenta di default una gran quantità di applicazioni in flash. Anche in Sankorè ce ne sono alcune di predefinite ma non molte.

Pagine Web NO SI Sankorè dispone di un browser integrato che permette di visualizzare pagine web come strumenti all'interno della lavagna.

Widget Javascript o Html

NO SI Sankorè, disponendo di browser integrato, supporta delle applicazioni scritte in Html o Javascript, se configurate correttamente.

Esaminando i dati riportati sopra va sicuramente segnalata una nota a favore di Smart

per quanto riguarda la raccolta di strumenti personalizzabili fornita di default, che è

sicuramente notevole: tra questi troviamo la classica domanda a scelta multipla,

immagini con “hot-zone”, cruciverba e molti altri ancora. Sankorè invece offre ancora

poco di default. Detto questo devo aggiungere che, a mio avviso, l'ex Uniboard risulta

molto più espandibile e meglio adattabile a sviluppi futuri, orientati sempre di più a web

2.0, il browser integrato permette infatti la visualizzazione di contenuti dinamici, sia

caricati da locale utilizzando la funzione Widget, che remoti, semplicemente

incorporando la pagina web nella lavagna digitale. Ovviamente in quest'ultimo caso si

12

dovrà disporre di una connessione ad internet attiva in fase di presentazione.

E' proprio qui che entrano in campo i Widget per la didattica in Javascript che, come

vedremo, saranno supportati non solo dai più comuni browser ma anche da Sankorè.

Per concludere ho trovato il software open-source molto più semplice ed intuitivo da

utilizzare rispetto a quello di Smart dove, in alcuni casi, l’eccessiva quantità di opzioni

su di uno strumento lo rendono più configurabile, ma anche più complesso e difficile da

utilizzare, rischiando quindi di far perdere del tempo al docente sia in fase di creazione

che di presentazione della lezione.

Strumenti per la Didattica

I Pattern EducativiUno dei punti principali che hanno caratterizzato questo progetto è stato quello di

definire dei pattern da utilizzare come base per lo sviluppo dello strumento o degli

strumenti didattici.

Per pattern si intende uno schema ricorrente, ovvero una regolarità che si riscontra

all'interno di un'insieme di oggetti osservati. Nel caso dei pattern educativi questi

oggetti osservati possono essere dei metodi di insegnamento, delle tipologie di esercizi

sia per un determinato argomento sia per argomenti diversi ma che presentano qualche

caratteristica comune e ricorrente. Ad esempio, l'associazione di un concetto ad un

contenuto potrebbe essere un esercizio utilizzato in qualsiasi corso o materia scolastica

pertanto potrebbe essere un buon candidato come pattern educativo. L'analisi di una

proposizione potrebbe essere visto invece come un pattern più specifico, adatto ad una

materia sola, in questo caso grammatica.

Una volta realizzato il modello di pattern che si desidera seguire bisogna decidere se

implementare uno strumento solo oppure più strumenti diversi. Utilizzando per

chiarezza all'esempio precedente: si potrà quindi decidere di sviluppare uno strumento

che associ una parola ad un concetto, un altro che ci associ un'immagine e magari un

altro ancora che ci associ un video. Oppure si potrà creare un unico strumento che

permetta all'utente di scegliere il tipo di file da utilizzare.

13

La ricerca e la scelta di pattern educativiPer affrontare in maniera più completa possibile lo studio dei nuovi modelli ricorrenti

ho cercato di lavorare su tre piani differenti:

• In primis ho cercato di raccogliere delle informazioni basandomi sulla mia

esperienza personale, facendo quindi un passo indietro di qualche anno e

rivedendo i vari metodi di insegnamento e gli esercizi a cui ero sottoposto

quando ero uno studente delle scuole elementari e medie;

• successivamente sono andato a cercare in rete il programma formativo italiano

in riferimento agli istituti primari e secondari di primo grado, con lo scopo di

analizzarne gli obiettivi e i contenuti per riuscire a trovare dei concetti comuni,

schematizzabili in un pattern;

• infine, come ultima risorsa, ma forse quella che ha dato i risultati migliori, mi

sono servito di un documento fornitomi dagli insegnanti impegnati nella

promozione del progetto WiiDIDA, nel quale hanno elaborato alcuni abbozzi di

pattern, aventi come target i ragazzini delle scuole elementari. Da alcuni di

questi schemi, apportando le giuste modifiche ne ho ricavato diversi utili

strumenti.

Organizzazione del progetto

Interoperabilità degli strumentiParlando di Learning Object abbiamo precedentemente detto che uno degli attributi

obbligatori è la loro capacità di girare su diverse piattaforme, intese sia come Sistemi

Operativi (Windows, Unix, Mac) che come software applicativi.

Durante la fase iniziale del progetto abbiamo dovuto scegliere con quale tecnologia

sviluppare questi Widget didattici. Sicuramente delle applicazioni stand-alone in Java o

C sarebbero risultate non integrabili in nessun software per LIM e poco compatibili su

piattaforme diverse.

Un buon candidato sarebbe stato Flash, le cui proprietà avrebbero fatto funzionare i

Widget su qualsiasi browser con il plugin Flash installato oltre che in Notebook e in

Sankorè. Anche questa possibile soluzione è stata però scartata in quanto né durante il

14

corso di studi né fuori da esso ho mai avuto occasione di avvicinarmi al mondo di Flash.

Infine, dopo alcune prove, Javascript è risultato essere il miglior candidato, vedremo in

seguito come è stato utilizzato, in quanto i Widget così creati sono facilmente

visualizzabili in ogni browser e in Sankorè. Inoltre risulterà semplificata anche la

creazione di un nuovo strumento partendo da un Template vuoto in Javascript e/o

andando a personalizzare un semplice file di testo.

Il principio di funzionamento è lo stesso, indipendentemente dal tipo di ambiente si

andrà ad utilizzare per la visualizzazione perché sarà sempre un browser ad interpretare

il codice Javascript, ci sono però delle piccole discordanze nel metodo di caricamento a

seconda che si usi Firefox piuttosto che Google Chrome o Sankorè.

Nel primo, Firefox, è sufficiente aprire la pagina HTML dell'applicazione, la quale

andrà a caricare lo strumento al suo interno rendendolo subito utilizzabile dall'utente.

A questo punto apro una piccola parentesi per capire meglio il problema riscontrato con

Chrome. Javascript, per questioni di sicurezza, non permette il cross-domain, ovvero

non accetta operazioni che vadano a caricare risorse prendendole da domini diversi da

quello dove sta girando il codice. Se l'applicazione gira da locale senza essere caricata

in nessun server web, il browser di Google interpreta ogni cartella del Widget come se si

trovasse in un dominio differente, rendendo quindi impossibile il caricamento dei dati e

di conseguenza la corretta visualizzazione dello strumento.

Per risolvere questo problema sarà sufficiente caricare il Widget come estensione per

Chrome, procedimento molto semplice che richiedi pochi passi e che ci permette di

avere lo strumento sempre presente e facilmente avviabile direttamente dal browser.

Per quanto riguarda invece l'importazione in Sankorè, se si utilizza il Costruttore di

Widget, che vedremo nel prossimo capitolo, non bisogna fare altro che aprire il software

per LIM e aggiungere l'archivio scaricato alla biblioteca. Se invece si decide di

personalizzare a mano il Template sarà necessario prima di tutto editare un file di

configurazione, successivamente comprimere il Widget e rinominarlo “.wgt” e infine

importarlo nel programma.

Specifico di aver menzionato questi tre ambienti diversi perché, allo stato attuale, sono

stati fatti test funzionali solo su di loro.

15

Widget, Template e costruttore di WidgetNei paragrafi precedenti ho utilizzato molto spesso la parola Widget senza specificarne

il significato: con questo termine si intende lo strumento grafico finito, ovvero

l'applicazione Javascript pronta ad essere incorporata in Sankorè o in un altro Web-

Browser. Un esempio pratico di Widget potrebbero essere delle immagini di bandiere e

una serie di contenitori, etichettati con i nomi di vari stati ai quali bisogna associare,

attraverso qualche tipo di interazione, la bandiera corretta.

Possiamo dire che un Widget è formato da un Template vuoto e da una configurazione.

Il Template definisce la sagoma, l'ossatura generale dell'applicazione in termini di “user

interface” e andrà quindi a decidere come dovranno essere disposti i vari oggetti grafici

e che tipi di interazioni si potranno utilizzare. La configurazione invece contiene i dati

veri e propri definiti dal docente, che possono essere di vario tipo: da semplice testo, a

file multimediali più complessi. Unendo dati e Template si otterrà quindi lo strumento

finale. La parte “Data” è composta da più file, come vedremo ci sono due documenti di

testo per configurare il Widget, un file XML per metadati e personalizzazione e degli

eventuali oggetti multimediali se previsti dallo strumento.

L'utente che vuole creare un nuovo strumento didattico può scegliere tra due sistemi

diversi:

16

L'unione di un Template vuoto a dati in formato XML e ad eventuali contenuti multimediali definiscono il Widget Didattico.

• il primo, più complesso e avanzato, che richiede maggiori conoscenze da parte

dell'utilizzatore, consiste nel creare o modificare manualmente la parte dati del

Widget;

• il secondo invece offre un supporto grafico alla creazione, durante il quale si

dovrà prima scegliere il Template tra quelli disponibili e poi personalizzarlo in

modo interattivo e guidato.

Quest'ultimo strumento è appunto il Costruttore di Widget che verrà approfondito nei

capitoli seguenti.

Configurazione Manuale di Widget

Se ci troviamo davanti ad un Template vuoto, possiamo procedere con la configurazione

manuale nel seguente modo.

Lo strumento vuoto non è altro che una cartella, al suo interno troveremo un file XML,

solitamente “data.xml”, e come è facile intuire sarà proprio questo che dovremo andare

a modificare. Aprendolo con un semplice editor di testo troveremo lo scheletro

strutturale già pronto e dei commenti su come andare a riempire i vari Tag che

inizialmente si presenteranno vuoti. Ad esempio, nello strumento “associazione di

parole” ci saranno dei tag <contenitore>, dove si dovrà inserire il nome del contenitore,

aventi dei figli <parola> dove invece inseriremo le parole appartenenti a quel container.

La prima parte del file di configurazione è sempre riservata ai metadati per lo specifico

strumento che si verrà a creare, vedremo in seguito di quali si tratta.

Se nel Widget saranno presenti file multimediali, quali immagini, suoni o video,

nell'XML dovranno essere inseriti i collegamenti opportuni e aggiungere il file vero e

proprio all’interno delle cartelle Images, Videos o Sounds.

La configurazione necessaria per rendere il Widget compatibile per Sankorè o Chrome

avviene editando o creando altri due file: “config.xml” e “manifest.json” che verranno

descritti in dettaglio nell'ultimo capitolo.

Configurazione Guidata di WidgetCome già accennato in precedenza, ho sviluppato un software che guida l'utente durante

la creazione dei Widget. Le specifiche tecniche e tecnologie utilizzate verranno discusse

17

in seguito, cerchiamo ora di approfondire il principio di funzionamento e il risultato

finale.

Questo “Costruttore”, presentato tramite un'interfaccia web, consente all'utente di

scegliere il Template (o anche più di uno) e di configurarlo attraverso la compilazione di

forms, il drag and drop di oggetti e mettendo a disposizione interfacce per upload di file

multimediali. Completata questa parte, l'utilizzatore dovrà riempire dei campi

obbligatori (univoci in tutti i Template) per la formazione dei metadati, dopodiché,

utilizzando la funzione “Crea Strumento”, potrà scaricare il Widget, che gli verrà fornito

nel formato per Sankorè.

Come interfaccia comune a tutti gli strumenti c'è anche la possibilità di scegliere

l'aspetto che avrà l'applicazione in Sankorè, e cioè la dimensione di default, il titolo,

l'icona, l'autore ecc. Alcuni di questi parametri verranno utilizzati anche qualora si

volesse importare il Widget in Google Chrome.

Scelte Architetturali

Javascript per Widget e CostruttoreCome ho già spiegato, i Widget e parte del Costruttore vengono sviluppati in Javascript.

Questo termine indica un linguaggio di scripting orientato agli oggetti, utilizzato

soprattutto per arricchire pagine web. La sua caratteristica principale è quella di essere

un linguaggio interpretato, non viene infatti compilato, ma semplicemente dato in pasto

ad un'interprete, presente ormai in ogni web browser. Risulta quindi evidente che non è

possibile creare applicazioni stand-alone come con Java o C, ma sarà necessario un altro

programma in cui integrare lo script JS.

Non è possibile eseguire un'applicazione Javascript che non sia caricato all'interno di

una pagina web, per questo sarebbe più corretto dire che Widgets e Costruttore sono

stati sviluppati in HTML+JS in quanto ognuno di essi presenta almeno una pagina

HTML per porte lanciare lo script.

Le interfacce che consentono a Javascript di integrarsi col browser sono chiamate DOM

(Document Object Model). Quando viene visitata una pagina web con al suo interno

uno script, esso viene portato in memoria ed eseguito dall'interprete. Questo permette al

18

server di delegare del lavoro ai Client e di non appesantirsi troppo.

Nonostante le DOM siano imposte dagli standard definiti dal W3C, spesso queste non

vengono rispettate dai vari browser, con la conseguente differente interpretazione di

alcuni metodi o oggetti dello script. Per questo motivo anche nei Widget didattici, in

qualche occasione, si presentano delle leggere differenze di visualizzazione, a seconda

dell'ambiente ospite che si sta utilizzando.

Costruttore di WidgetA parer mio, le qualità fondamentali che dovevano caratterizzare questo strumento sono:

facile reperibilità o installazione e aiutare il docente nel modo più interattivo e veloce

possibile.

Per questo motivo ho scelto di svilupparlo come applicazione web costituita per la

maggior parte da codice JavaScript, che ne migliora di molto la dinamicità, inserita in

un leggero server embedded, per agevolare notevolmente la fase di installazione.

L'applicazione, installata come servizio web, è poi raggiungibile da tutte le altre

macchine connesse alla stessa LAN/WAN. Ad esempio, il costruttore potrebbe venir

caricato sul server di un istituto scolastico e quindi essere messo a disposizione di tutti i

docenti.

Ovviamente non c'è solo Javascript, ma anche HTML per poter inglobare gli script e

AJAX per una comunicazione asincrona col server composto da alcune Servlet Java.

La necessità di avere una parte server è dovuta alle limitazione del linguaggio di

scripting, il server infatti gestisce le sessioni utente, permette l'upload di file

multimediali, crea i Widget e fornisce il link per scaricarli.

La comunicazione tra le due parti, client e server, avviene sempre attraverso l'uso di

AJAX (Asynchronous Javascript and XML).

Questa è una tecnica di sviluppo per la creazione di applicazioni web interattive, basata

sullo scambio di dati in background tra le due parti. La sua peculiarità sta nel permettere

l'aggiornamento dinamico di una pagina web, senza l'esplicito ricaricamento della

stessa. Solitamente, anche se come vedremo nel mio caso avverrà spesso in modo

trasparente, informazioni e dati vengono passati in linguaggio XML.

L'elaborazione dei dati lato server viene effettuata da alcune Servlet, delle speciali classi

19

Java in grado di processare le richieste Http.

Il ToolKit GWTProgrammare script Javascript complessi scrivendo codice Javascript può risultare

abbastanza difficile, sia per come è strutturato il linguaggio di per se, che per la

mancanza di un buon ambiente di sviluppo.

Ed è proprio qui che entra in gioco il potente toolkit sviluppato da Google, appunto

Google Web Toolkit, il quale permette di creare complesse applicazioni o pagine

JS+HTML scrivendo codice Java. Tutto ciò che è Java, tranne alcune librerie native,

può essere compilato su qualsiasi piattaforma con i file Ant inclusi.

GWT accentua la riusabilità del codice e permette di utilizzare AJAX attraverso delle

Named RPC (Remote Procedure Calls o Chiamate a Procedure Remote) che risultano

essere molto semplici da usare se si hanno delle Servlet dall'altro lato. Inoltre offre

anche una gestione della storia del browser, che risulta molto comoda quando, come nel

costruttore di Widget, tutto il codice gira su una sola pagina web. Pieno supporto al

debugger Java, una facile internalizzazione, Junit, la possibilità di aggiungere codice

nativo JS, un supporto alle API Google e una vasta gamma di librerie opensource per

espandere le sue funzionalità di base.

Nella libreria di base sono presenti un gran numero di Widget personalizzabili come

griglie, pulsanti e pannelli per creare la User Interface senza dover scrivere codice

HTML.

Grazie a questo toolkit si riesce a portare lo stile e, quasi sempre, anche le funzionalità,

di un'applicazione desktop in una pagina internet, spostando di un altro passo avanti il

concetto di Web 2.0.

Le grandi potenzialità di questo framework, le sue proprietà e le qualità sopra elencate

mi hanno portato ad utilizzarlo sia per il Costruttore di Widget che per i Widget stessi.

Frameworks e librerie per GWTHo creato l'interfaccia utente sfruttando le vasta gamma di estensioni dei Widget base di

GWT (pulsanti, pannelli, finestre), messe a disposizione dal framework SmartGWT.

Quest’ultimo, oltre agli strumenti grafici, fornisce una più ricca gestione degli eventi e

20

una buona libreria per il drag-n-drop.

E' presentato sia in una versione open-source (utilizzata nel progetto) sia in una

enterprise, entrambe offrono una comunicazione più semplice ed efficiente tra i

componenti grafici user-side e i dati presenti sul server, cosa che solitamente gli altri

frameworks lasciano a discapito dell'utente.

Ho trovato utili alcune librerie opensource, “gwt-upload” mi permette di gestire l'upload

dal computer dell'utente, sempificando alcune operazioni e fornendomi un'interfaccia

grafica dinamica.

“gwt-voices” sfrutta i nuovi tag html5 per la riproduzione di contenuti audio

multimediali, per il momento utilizzati essenzialmente come segnale acustico alla fine

di una particolare interazione, ma in futuro si potranno creare strumenti che prevedono

la riproduzione di musica o suoni con l'aiuto di questa libreria.

Le librerie derivate dalle API di Google saranno descritte nel prossimo capitolo.

APIs Google

La famosa casa di Mountain View ha creato una suite di librerie in Javascript per

l'integrazione di molti dei loro prodotti in applicazioni web, con lo scopo di espanderle e

di migliorarne la funzionalità.

Alcuni sviluppatori Google hanno poi adattato o riscritto questi tools come librerie Java

da utilizzare con GWT.

Per citarne alcuni:

• Maps provvede l'accesso e l'incorporamento delle famose mappe digitali nel

proprio sito, dando pieno controllo alla loro personalizzazione;

• Google Chart Tools non è altro che la versione per GWT di Visualization,

strumento per creare grafici dinamici ed interattivi di qualsiasi genere, come

torte e mappe GeoChart.

• Google Search è un tool molto potente con il quale è possibile effettuare ricerche

sfruttando il motore di ricerca Google. Quest’ultimo non si limita alla ricerca di

pagine web, ma è anche possibile cercare immagini, video, news, libri e blog

con l'aggiunta di un'anteprima già formattata dei risultati.

Ho menzionato queste librerie perché sono state utilizzate nel Corstruttore e anche nei

21

Widget Didattici. Search permette di cercare e caricare immagini direttamente dal Web

senza doverle prima salvare sul proprio computer, Visualization è stato usato negli

strumenti confacenti alla costruzione di grafici, mentre Maps non ha ancora preso parte

al progetto, ma in un prossimo sviluppo potrà venir integrato in un oggetto che permetta

di interagire con una mappa.

Il loro uso permette di aumentare sia la dinamicità che la funzionalità del progetto.

Vorrei puntualizzare però che alcuni di loro, come ad esempio Search, hanno come

punto a sfavore l'impossibilità di lavorare senza una connessione ad internet attiva. Ad

esempio in un'aula non connessa alla rete esterna risulterà impossibile utilizzare uno

strumento supportato da Google Maps.

22

Capitolo 2 – Pattern e Strumenti

Abbiamo già visto in precedenza che la funzione primaria di un

pattern educativo consiste nell’indicare una soluzione

consolidata ad un problema ricorrente. Questa parte della tesi

sarà dedicata all'approfondimento di tutto ciò che sta dietro

alla scelta di un pattern e all'implementazione degli strumenti

ad esso collegati. Cercherò quindi di chiarirne il

funzionamento, spiegandone le modalità di utilizzo e le

specifiche tecniche, aiutandomi di tanto in tanto con un esempio

pratico.

Per motivi di chiarezza riporterò le descrizioni seguendo lo

stesso schema per ogni strumento: se il pattern prevede un solo

strumento verrà presentata una scheda unica pattern-widget, se

invece il pattern prevede più strumenti ognuno di essi verrà

discusso in una scheda differente.

Oltre agli strumenti già pronti e funzionanti ho deciso di

inserire anche alcuni pattern che per il momento sono solo stati

ideati, ma che prossimamente andranno ad ampliare la scelta di

oggetti utili al docente.

Nei primi paragrafi andrò ad esporre le caratteristiche comuni

a tutti gli strumenti, mentre nella seconda parte troverete la

descrizione di certi utensili didattici che, a differenza degli

altri, non sono derivati da un pattern.

23

Interfaccia comune a tutti i Widget

L'elemento che accomuna obbligatoriamente tutti gli strumenti didattici, essendo

anch'essi dei LO, è sicuramente la definizione dei metadati.

Questi dati descrittori risultano utili e indispensabili sia per la ricerca all'interno di un

eventuale repository di Learning Object in cui l'oggetto è memorizzato, che come

informazioni aggiuntive, visualizzabili in fase di utilizzo.

Possiamo quindi affermare che tutti i Widget hanno in comune lo scheletro, e cioè

l'interfaccia.

I dati utili, selezionati per questa funzione sono: il titolo dello strumento, la sua

descrizione, l'autore, la materia o argomento e il livello di istruzione. A questi va

aggiunta la data di creazione che però viene settata automaticamente in fase di

creazione.

Questi metadati vengono inseriti nel file di configurazione in formato XML come

riportato nel seguente esempio.

Per far lavorare in modo corretto i Widget su piattaforme e ambienti diversi, sono

necessari altri oggetti da aggiungere ad ognuno di loro. In generale si necessitano alcuni

dati per la configurazione dell'aspetto, come ad esempio altezza, larghezza e icona, e

24

I metadati di un Widget Didattico i quali vanno a riempire la prima parte del file "data.xml"; all'interno dei tag <pattern> verrà inserita la personalizzazione dello strumento.

altri per la descrizione, che però di default utilizzano quelli presenti nei metadati.

Pattern Concetto-ContenutoDa piccoli. Definendo “piccoli” come l'età delle elementari, ci sarà capitato spesso di

trovarci davanti ad esercizi del tipo: “Collega con una riga la parola alla definizione

corretta”, oppure “Descrivi le immagini utilizzando le seguenti parole” piuttosto che

“Completa la tabella inserendo i termini sottostanti”. Inoltre questo tipo di esercizi è

molto utilizzato anche nell'insegnamento delle lingue straniere.

Il principio di base che accomuna tutti questi esercizi è il collegamento di uno o più

contenuti a dei concetti. Questi ultimi li possiamo generalizzare come dei qualsiasi

oggetti multimediali che, nell’eventualità più semplice corrispondono ad una parola, ma

si possono anche evolvere in frasi, immagini, collezioni di figure, suoni o video.

Ci può essere un solo contenuto o più di uno per ogni concetto e viceversa, si possono

infatti avere più concetti descritti dallo stesso contenuto. Più precisamente tra i due

possiamo avere relazioni 1 -> 1, 1 -> N, N -> 1 e N -> N.

Viene così ideato il primo pattern educativo con l'obbiettivo di migliorare le capacità di

apprendimento dell'alunno attraverso l’utilizzo di contenuti multimediali (che catturano

molto di più l'attenzione) e interattivi.

Widget Parola-Contenitore Questo strumento è caratterizzato da un numero arbitrario di insiemi vuoti, ognuno di

essi rappresenta un contenitore ed è identificato da un titolo che può essere composto da

una o più parole. Oltre a questi viene visualizzato un altro insieme che raccoglie tutti i

contenuti sotto forma di parole, disposti in ordine casuale al suo interno.

L'obiettivo dell'esercizio è quello di riempire i contenitori con i concetti dati in modo

corretto; se l'associazione è errata l'operazione verrà annullata e sarà incrementato il

numero di errori fatti. L'esercizio terminerà quando tutti i contenitori saranno

correttamente descritti. L'ultima operazione di associazione, se corretta, porta ad un

messaggio di terminazione e alla visualizzazione del numero di errori.

Multimedialità: Il Widget presenta del testo composto da singole parole o frasi.

25

Interazione Widget:

All'utente viene presentata una paletta contenente tutte le parole da associare a dei

contenitori. Questi li troviamo posizionati in un'altra area dello schermo e saranno

composti da un titolo e da un'area bianca riservata al trascinamento dei contenuti

corrispondenti.

Lo studente interagisce con l’applicazione attraverso una semplice operazione di

pressione sulla parola scelta, trascinamento e rilascio della stessa nel box del

contenitore. Una corretta associazione incolla la descrizione al container, mentre una

errata riporta la parola alla posizione iniziale.

Interazione Costruttore:

La personalizzazione di questo template attraverso l’utilizzo del costruttore è

un’operazione molto semplice. Nell’interfaccia troviamo un form composto dai campi

parola e container con i relativi pulsanti per l'accorpamento. L'aggiunta di una

descrizione formatta la parola inserita e la posiziona in una palette praticamente identica

a quella presente nel Widget. L'inserimento di un nuovo concetto invece andrà a creare

il box con relativo titolo e lo allegherà alla finestra dei container.

Una volta eseguita questa operazione è possibile riempire i contenitori con i contenuti,

26

Uno strumento Word-Container; la palette in alto presenta le parole ancora disponibili da associare al giusto contenitore attraverso un'interazione del tipo drag-n-drop.

interagendo nello stesso modo precedentemente descritto.

Schema XML:

Specifiche Tecniche:

I dati che rappresentano lo strumento in se, vengono memorizzati nella configurazione

XML come rappresentato nell'esempio qui sopra. Da questi vengono poi creati due

oggetti. Il primo è una lista di stringhe, ottenuta passando tutti i dati nei campi

association, che andrà a fornire gli elementi per creare la palette dei contenuti. Il

secondo invece è una Map, i cui dati corrispondono ai valori ottenuti dai tag keyword e

dal loro contenuto, e grazie alla quale posso formare i container ed effettuare le

27

Creazione di uno strumento Word-Container; la form in alto permette di inserire parole e contenitori. Trascinando la parola nel contenitore si crea l'associazione.

operazioni di controllo sulle associazioni.

Widget Immagine-Contenitore

Essendo derivato dallo stesso pattern, questo Widget riporta più o meno le stesse

funzionalità di quello precedentemente descritto.

I contenitori sono identici, sia come concetto che come user-interface, la differenza

sostanziale sta invece nei contenuti che, mentre prima erano rappresentati da semplici

parole, ora sono sostituiti da immagini. Ogni immagine dovrà essere inserita nel giusto

container, continuando fino a quando non rimarranno più immagini libere e a quel punto

l'esercizio sarà terminato.

Interazione Widget:

Anche per quanto riguarda questo aspetto possiamo fare riferimento al Widget

precedente dato che l'interazione risulta pressoché identica. Questa volta al posto delle

parole si devono trascinare delle immagini, per poi rilasciarle nel contenitore corretto.

Ogni immagine può essere anche integrata da un promt descrittivo, che apparirà

semplicemente passandoci sopra col cursore( vedi esempio sottostante).

Multimedialità:

28

Widget Image-Container; dalla palette in alto si trascinano le immagini nel contenitore corretto.

Testo composto da una o più parole per definire i concetti e da immagini di piccole

dimensioni per integrare i contenuti.


La differenza principale, o meglio, l'unica differenza tra questo strumento e quello

precedente la troviamo nella form per l'inserimento degli oggetti. I contenitori si creano

nello stesso modo, ma le immagini devono essere caricate dal proprio computer oppure

direttamente, utilizzandone di già presenti in rete.

Le immagini vengono caricate in una palette riportandoci allo stesso scenario presentato

nel Widget precedente. Qualora risultassero poco chiare si possono completare con

l’aggiunta di una breve descrizione.

La soluzione adottata per il caricamento di contenuti multimediali, caratterizzati non

unicamente da testo, è descritta in modo dettagliato nel capitolo riguardante la parte

tecnica.

Specifiche tecniche:

Ho deciso di imporre una dimensione massima fissa alle immagini caricate, senza però

modificarne le proporzioni. L'immagine caricata viene quindi automaticamente

29

Creazione di uno strumento Image-Container; la form in alto permette di aggiungere contenitori e immagini, l'associazione viene creata attraverso un'interazione drag-n-drop dell'immagine nel contenitore.

ridimensionata utilizzando una libreria che descriverò nel prossimo capitolo. La scelta è

stata di 100x100 pixel massimi per immagine, sia per permettere la creazioni di

strumenti supportati da molte immagini, che per rendere più leggero il Widget finale.

Un effetto negativo derivante da questa scelta sarà la visualizzazione di un'immagine

poco dettagliata e particolareggiata. Per questo motivo è consigliato l'utilizzo di

immagini semplici e ben definite.

Lo schema XML utilizzato è riportato qui sotto. Una volta parsato vengono costruiti

due oggetti. Il primo consiste in una lista di oggetti immagine, ognuno dei quali

contiene nome, link, altezza, larghezza e descrizione e con cui si realizza la palette dei

contenuti iniziale. Il secondo invece è una Map, che presenta dei concetti come chiave

e una lista di immagini che descrivono quel concetto come valori. Quest'ultimo, come

avveniva nello strumento precedente, viene usato per produrre i contenitori e controllare

che le operazioni di associazione siano corrette.

Schema XML:

Altri Strumenti

Questo pattern fornisce la base per lo sviluppo di altri strumenti simili a quelli già

prodotti che però utilizzano altri tipi di contenuti multimediali come suoni o video. Per

esempio ogni contenitore è identificato da un video, visibile direttamente all'interno del

box, una volta guardato il filmato, o mentre si sta guardando bisogna descriverlo

taggandolo con le parole della palette.

30

Pattern Hot-Spot ImageIl concetto educativo che sta dietro a alla scelta di questo pattern consiste nello

stimolare sia l'attività mnemonica che quella associativa dell’alunno attraverso l'uso di

immagini e definizioni.

In questo caso ci troviamo davanti ad un pattern più specifico, dal quale è stato

estrapolato un solo strumento.

Nel Widget è prevista la presenza di un'immagine, che può rappresentare qualsiasi cosa:

una cartina muta, la sezione di un motore, un paesaggio o quant'altro. Oltre ad essa

all'alunno vengono fornite delle parole o delle definizioni che descrivono o identificano

una specifica area dell'immagine. Lo scopo dell'esercizio è quello di associare ogni

concetto all'area corrispondente all’interno della figura, che viene chiamata appunto

“Hot-Zone”. Questa “Zona Calda” circoscrive una regione rappresentante un particolare

della figura, alla quale è possibile collegare degli oggetti. Il risultato sarà composto

dalla foto o dal disegno completo di tutte le descrizioni per ogni sua zona.

Widget Hot-Spot Image

Multimedialità: Testo e Immagini, parole per le definizioni e un'immagine dove

collegarle.

Iterazione Widget:

Consiste in un'interfaccia utente suddivisa in due parti. Nella prima, posta in alto, si

trova un box, all’interno del quale vengono raccolte tutte le descrizioni. Nella seconda,

al centro, viene disegnata l'immagine (una sola per strumento) sulla quale sono presenti

dei marcatori che identificano le varie “Hot Zone”. Si troveranno tanti marcatori quante

sono le definizioni.

Per ora presentano uno stile unico e predefinito e non è possibile cambiare il loro

aspetto. In un prossimo aggiornamento, come suggerito dai promotori di WiiDIDA,

verrà aggiunta un'opzione per permettere all'utente di cambiarne forma, colore e

dimensione.

L'alunno interagisce con lo strumento attraverso il trascinamento della definizione sul

marcatore della “Zona Calda”; questa operazione, se corretta, rimuove la parola dal box

in alto e la collega all'identificatore di quella parte di immagine.

31

L'esercizio finisce quando tutte le zone della figura vengono completate.


Si inizia scegliendo l'immagine da caricare e impostando la dimensione massima che

dovrà occupare in pixel. Anche in questo caso il ridimensionamento avverrà senza

distorcere la figura e mantenendone le proporzioni originali. Una volta caricata,

l’immagine viene visualizzata in dimensioni reali al centro dello schermo e, a questo

punto, la pressione del mouse in un punto all'interno della figura farà apparire il pop-up

per l'aggiunta del marcatore in quella posizione. Una volta inserita la descrizione e

confermato con l’ok, l'hot-spot apparirà in foreground sulla figura. E' possibile

modificarlo o eliminarlo semplicemente selezionandolo col mouse.

Non esiste un limite massimo al numero di punti aggiunti.

Specifiche Tecniche:

Ho posto un limite massimo alla dimensione dell'immagine a quota 1024x1024px, che

corrisponde anche alla grandezza di default massima per un Widget. Gli hot-spot non

possono essere posizionati troppo vicini, evitando in questo modo il rischio di

32

Widget Hot-Spot Image, l'immagine è divisa in zone identificate da un'ancora la quale permette il collegamento della parola associata a quella zona.

sovrapposizione delle definizioni durante l'utilizzo dello strumento. Al momento il

marcatore viene presentato come un quadrato dal lato di 12px e colorato con 2 colori

differenti, per essere visibile su qualsiasi background. Nel file di configurazione dello

strumento troviamo la descrizione dell'immagine (link, dimensione, titolo) e le

informazioni di ogni hot-spot (coordinate sull'immagine, nome). Da questi dati viene

estrapolata una lista con tutte le descrizioni delle hot-zone, utilizzata per creare la

palette, l'oggetto immagine e una lista di punti.

Schema XML:

33

Creazione di uno strumento Hot-Spot Image; dopo aver caricato l'immagine basta un click del mouse al suo interno per creare un "hot spot " in quel punto.

Pattern Complete-StoryLe funzionalità di questo pattern consistono nel migliorare sia le capacità di logica nel

discorso che quelle mnemoniche, facilitando notevolmente il processo di

memorizzazione di nuovi vocaboli o definizioni, grazie anche all'integrazione in un

esempio pratico.

Anche questo strumento prende spunto da esercizi classici come ad esempio: “Utilizza

le parole date per completare il testo” oppure “Associa alle seguenti definizioni il

termine corrispondente”. Le possibilità di utilizzo dell’applicazione sono molto ampie e

può risultare utile per una grande varietà di materie.

A livello pratico, allo studente verrà presentato un testo sotto forma di storiella o anche

semplicemente delle singole frasi, all’interno delle quali mancheranno alcune parole,

sostituite da gap bianchi.

L'obiettivo sarà quello di riempire tutti gli spazi bianchi con le parole mancanti che

verranno fornite in ordine casuale insieme al testo. Queste parole potranno essere una

parte qualsiasi del discorso: articoli, congiunzioni, nomi, avverbi, verbi, preposizioni,

punteggiatura etc.

Per questo pattern è stato implementato un unico strumento.

Widget Complete-Story

Multimedialità:

Solo testo, con una o più parole come oggetti da posizionare nella storia, composta da

frasi e paragrafi.

Interazione Widget:

Si presenta all'utente una palette contenente le parole chiave, disposte in ordine casuale

e il testo incompleto dove i gap bianchi sono marcati da un rettangolo tratteggiato.

Attraverso l’ormai comune operazione di trascinamento bisogna portare la parola

all'interno del gap corrispondente. Nel caso l’associazione risultasse corretta, questa

diverrà parte integrante del testo e verrà quindi tolta dalla palette. L'esercizio termina

quando il testo viene completato.

Per aumentare la dinamicità dello strumento sono stati aggiunti degli avvisi sonori e dei

34

cambi di colore in caso di corretto posizionamento della parola.


L'operazione di costruzione è molto semplice: l'utente deve riempire una text-area di

grandezza dinamica con la storia o le frasi alle quali desidera togliere successivamente

le parole.

Le parole chiave devono essere marcate direttamente nel testo e per fare questo si

utilizza un carattere di l'identificazione, da posizionare all'inizio e alla fine della parola;

il carattere che ho scelto è la barra verticale “ | ” e sarà quest’ultimo a delimitare i

confini del termine mancante.

Non c’è bisogno di fare altro, sarà poi il Widget stesso in fase di parsing a togliere

queste parole, e a sostituirle con gap bianchi.

Specifiche Strumento:

La decisione di lasciare al Widget il compito di fare il parsing del testo e togliere i

termini chiave è stata presa con lo scopo di rendere più semplice per l’utente

un’eventuale configurazione manuale dello strumento.

Il procedimento svolto dal Widget è il seguente:

35

Widget CompleteStory; Le parole contenute nella palette in alto vengono trascinate nel gap tratteggiato corretto.

Scorre il testo e salva ogni parola in una lista (LP)

Quando trova una parola chiave la aggiunge ad LP assieme ad un identificatore e

alla sua lunghezza per esempio, |chiave| → KEY_6_chiave

La stessa parola è salvata anche in un'altra lista senza identificatore (LPC)

La lista LP viene scorsa per produrre il testo visualizzato, in cui ogni parola

chiave viene sostituita con un oggetto GAP_BIANCO.

Con gli elementi della lista LPC si andrà a riempire la palette dei termini.

Schema XML:

36

Creazione di uno strumento CompleteStory; Dal testo presente nella Text-Area vengono selezionate le parole da togliere delimitandole con il carettere speciale '|'.

PuzzleTutti ben conosciamo il classico e centenario gioco del puzzle, in cui la raffigurazione di

qualche immagine viene spezzettata in tessere, che poi bisogna unire per ricomporre la

figura originale. Questo è lo stesso meccanismo che sta alla base del pattern in

questione, che ha lo scopo di accrescere le capacità di osservazione e il collegamento

logico delle varie parti in un unico concetto.

L'esercizio di per se viene recepito come un gioco da parte dell'alunno, caratteristica che

in molti casi può far aumentare notevolmente la sua attenzione nei confronti della

lezione.

Al ragazzo viene presentata la figura tagliata in parti regolari e distribuite in modo

casuale. Il docente può scegliere o meno di presentare anche un'anteprima

dell'immagine finale come aiuto.

Lo studente dovrà riordinare le tessere all'interno di un riquadro fino a completare

l’immagine originale.

Pet-Square

Multimedialità: Immagini: l'immagine intera e tutte le tessere in cui è stata

suddivisa.

Interazione Widget: Anche in questo caso lo strumento è composto da 2 parti: una

palette con gli oggetti/strumenti e un piano di lavoro.

Il primo si presenta come una lista orizzontale scorrevole, avente come elementi le

tessere del puzzle, ognuno dei quali ha la proprietà di essere “draggabile”, ovvero può

venir spostato sia all'interno della palette che nel piano di lavoro.

Quest'ultimo viene visualizzato inizialmente come una griglia tratteggiata vuota, dove il

numero di celle è pari al numero di tessere, e che si riempie mano a mano che l'utente

importa le tessere dalla palette. In qualsiasi momento è possibile spostare una tessera da

un riquadro all'altro della griglia. Qualora le tessere fossero tutte disposte all’interno del

piano di lavoro e correttamente collegate tra di loro, l'esercizio gioco sarà terminato.

Per facilitare la composizione e per rendere lo strumento più realistico, nel caso il

numero di tessere fosse abbastanza alto, si presenta la possibilità di aprire un'anteprima

del risultato finale, proprio come se si stesse guardando la scatola reale del puzzle.

37

Interazione Strumento:

Le operazioni di configurazione sono molto poche, in quanto il lavoro di ritaglio viene

svolto completamente dal software.

All'utente vengono chieste le informazione sull'immagine (altezza e larghezza massime)

e sul numero di righe e di colonne in cui dovrà essere tagliata la figura (massimo 8 righe

x 8 colonne). Fatto questo si dovrà procedere con l’usuale operazione di upload che,

oltre a caricare l'immagine, andrà anche a scomporla in un numero di tessere pari al

prodotto di righe per colonne.

Con questi semplici passi abbiamo ottenuto uno strumento pet-square.

Specifiche strumento:

L'operazione di ritaglio viene effettuata da una libreria grafica lato server e le tessere

vengono salvate con lo stesso nome dell'immagine, più degli identificatori di riga

38

Widget Pet Square; Si deve ricomporre la figura trascinando le tessere nel riquadro al centro e rilasciandole nella posizione corretta, è possibile vedere un'anteprima del risultato finale attraverso il pulsante Vedi Immagine.

colonna.

Nel file di configurazione vengono salvati i dati relativi all'immagine intera e a tutte le

fette create, quindi si terrà traccia di: url, riga, colonna e dimensione.

Da ognuno di questi campi tessera il parser andrà a creare un oggetto Slice e lo

aggiungerà alla lista delle tessere.

Ogni cella della griglia viene identificata da una riga e da una colonna e ogni volta che

una tessera viene aggiunta o spostata partirà automaticamente un controllo per vedere se

il puzzle è completo.

Schema XML:

Pattern GraficoSpesso accade che durante una lezione vengano forniti dei dati o delle statistiche. Questi

possono essere integrati in un discorso, visualizzati in una tabella oppure esposti,

attraverso l'uso di un grafico opportuno. Solitamente una presentazione che utilizza dei

grafici li esporne come delle semplici immagini statiche.

L'obiettivo di questo pattern è quello di fornire al docente un supporto interattivo per la

visualizzazione di dati sottoforma di grafici dinamici.

A differenza degli altri pattern presentati fino ad ora questo non permette la creazione di

esercizi, ma risulta invece molto utile nell'arricchimento dei contenuti di una lezione.

39

Inoltre un grafico interattivo può far aumentare il livello di attenzione della classe,

molto più di un'immagine statica.

Possiamo quindi intuire che ogni strumento sviluppato da questo pattern corrisponderà

ad un diverso tipo di grafico. Per ora ho implementato solamente due tipi di grafici: a

torta e a linee. La libreria JS offerta da Google (Visualization) mi ha aiutato

notevolmente nella parte di presentazione.

Widget Grafico a Torta

Multimedialità: Testo e il componente grafico a torta fornito da Google.

Interazione Widget: Il Widget presenta semplicemente il grafico interattivo il quale

risponde ad alcuni eventi del mouse con delle piccole animazioni dello stesso come per

esempio il cambio di colore della fetta sulla quale si sta passando col puntatore e la

comparsa di un pop-up con le informazioni relative ai dati e alle percentuale di quella

parte.

Interazione Costruttore: Si presenta all'utente una form per impostare la struttura

del grafico (altezza e larghezza) e il titolo. Attraverso una tabella posta al centro della

pagina è possibile aggiungere i dati del grafico quali: nome del campo, quantità ( un

numero intero o reale) e una eventuale descrizione per quel campo. Per questo

WidgetBuilder è attiva la funzione anteprima per visualizzare il grafico corrispondente

ai dati inseriti fino a quel momento.

40

Widget Grafico a Torta

Specifiche Tecniche: E' la libreria Visualization che si preoccupa di creare lo

strumento grafico, il lavoro svolto in fase di costruzione del Widget prevede solamente

il parsing dello schema XML dal quale estraggo una lista di PieChartField: delle

strutture dati composte da nome, valore e descrizione. Questi dati vengono poi dati in

pasto all'oggetto PieChart e utilizzati per creare il grafico a torta.

Schema XML:

Widget Grafico a Linee

Multimedialità: Testo e il componente grafico a linee fornito da Google.

Iterazione Widget: Identica al precedente con sola la differenza che muovendo il

41

Costruttore Grafico a Torta; I dati inseriti nella tabella aggiornano automaticamente il grafico una volta inseriti.

puntatore lungo una linea ogni qual volta si passa sopra al punto corrispondente ad un

valore definito sull'asse delle ascisse appare un pop-up con la descrizione del punto.

Interazione Costruttore: Anche la costruzione avviene in modo simile allo

strumento precedente. Una form permette di impostare la dimensione del grafico ed il

titolo mentre un'altra aggiunge nuove linee e valori per le ascisse (per esempio delle

date). Attraverso una tabella è possibile selezionare una specifica combinazione di linea-

punto e dargli un valore. Anche in questo caso è presente il pulsante anteprima.

Specifiche Tecniche: Come per il Widget Pie Chart anche qui i dati estrapolati dalla

personalizzazione XML vengono dati in pasto all'oggetto LineChart della libreria

Visualization. In questo caso però la struttura dati ottenuto è un po più complessa: si va

a creare una lista di LineChartField. Questi oggetti contengono: il nome della linea e

una Map di associazioni punto (Stringa) valore (numero reale).

Schema XML:

42

Line Chart Widget; ogni punto di una linea è selezionabile per vederne i dettagli.

Altri GraficiQuesto pattern è ancora molto espandibile in quanto la libreria offerta da Google offre

molti modelli di grafico diversi. Si potranno quindi creare strumenti utilizzanti grafici

diversi da quelli presentati per esempio: istogrammi, grafici ad area, grafici a punti o

magari anche qualcosa di più complesso come grafici GeoChart dove si presenta una

cartina del globo suddivisa in stati ai quali si attribisce un valore che andrà a colorare

l'area in una certa maniera.

Altri Strumenti

Easy SumNon ho inserito questo Widget nella sezione precedente perché non deriva da un vero e

proprio pattern, Easy-Sum si presenta più come un semplice gioco che intrattiene lo

studente nella risoluzione di semplici operazioni algebriche di somma e sottrazione.

Anche la personalizzazione dello stesso da parte del docente si limita solamente a

scegliere il numero di espressioni e il livello di difficoltà, si va quindi a perdere il

concetto di Template + Dati = Widget.

Si possono scegliere quattro difficoltà diverse:

43

EASY → espressioni nella forma 5 + ? = 12

MEDIUM → espressioni nella forma ? + ? = 12

HARD → espressioni nella forma ? + ? + ? = 20

VERY-HARD → espressioni nella forma 10 - ? + ? = 12

Dopo aver scelto numero di espressioni e livello di difficoltà il Widget si compone in

due pannelli, il primo contiene l'espressione generata casualmente dove la cifra o le

cifre incognite sono coperte da un punto di domanda e il secondo rende visibile tutte le

cifre da 0 a 9 disegnate sotto forma di carta da gioco.

Lo studente deve prendere una cifra e trascinarla sul punto di domanda, se l'espressione

risulta corretta si passa alla domanda successiva. Ho implementato anche un sistema di

punteggio calcolato in base al numero di errori fatti. Per semplificare sia l'interazione

che la difficoltà delle espressioni ogni numero mancante è composto da una sola cifra.

External Web-AppQuesto strumento come vedremo risulta utile solamente se associato a Sankorè poiché

permette di creare un Widget utilizzando come dati un Learning Object già presente in

rete. Non ha molto senso farne uso in un browser dove posso raggiunge la risorsa

44

Widget EasySum livello difficile.

direttamente scrivendo l'indirizzo nella barra di navigazione.

Ogni pagina HTML presente in rete, pura, che ingloba Javascript, animazioni Flash o

applets Java può venire importata nella lavagna di Sankorè attraverso questo strumento.

Il funzionamento è molto semplice, in fase di creazione si aggiunge il link alla pagina

(Learning Object ) in questione la quale viene poi inserita in uno speciale tag HTML5

<iframe> all'interno del Widget.

Altri PatternQui di seguito riporto la descrizione di alcuni pattern ideati, ma non ancora

implementati, che andranno ad arricchire la possibile scelta di Widget per l'insegnante.

Ordinamento logico sequenza

All'utente viene presentata una lista di oggetti in ordine casuale, appartenenti ad uno

stesso insieme concettuale. Questi possono contenere un tipo qualsiasi di formato

multimediale e deve inoltre esistere un unico collegamento logico che li lega l'uno

all'altro.

Attraverso un'operazione di ordinamento si andrà quindi a riassemblare la sequenza

originale scelta dallo sviluppatore dello strumento. Per fare un esempio pensiamo ad

una frase che viene scomposta in singole parole (gli oggetti) le quali a loro volta

vengono mescolate e disposte in ordine casuale, oppure pensiamo ad una storia da

ricostruire, raccontata tramite immagini mescolate in ordine sparso.

Si può pensare anche di creare strumenti che permettano l'interoperabilità di oggetti

multimediali diversi, per espandere il range di utilizzo di questo pattern.

Analisi morfologica o SintatticaQuesto pattern riporta sotto forma di Widgets i famosi esercizi di analisi logica e

grammaticale che interessano rispettivamente ragazzi delle scuole elementari e medie.

In generale l'alunno si trova ad affrontare una proposizione suddivisa in parti alle quale

si deve associare un tag che la identifichi. Nel caso dell’analisi logica, la frase è divisa

in sintagmi e ad ognuno di essi deve venir associato il complemento corretto. L'analisi

grammaticale invece risulta essere più complessa in quanto la proposizione viene divisa

45

in singole parole, ad ognuna delle quali lo studente non solo deve collegare una delle 9

parti del discorso, ma deve anche analizzare più nello specifico il tipo di parola in

questione. Per esempio la parola “Mario” si tagga come “nome” e si scende più nel

dettaglio specificando “nome proprio maschile”.

La realizzazione di Widgets che permettono di affrontare questo tipo di esercizi è

caratterizzata da palette riempite con i vari complementi, con le parti del discorso, e con

le descrizioni più specifiche.

Analisi oggettoQuesto pattern riassumere una tipologia di esercizi molto utilizzata nell'istruzione ad

ogni livello. All'utente viene presentato un oggetto multimediale, (testo, immagine,

suono, video) visibile all'interno dello strumento in modo permanentemente oppure solo

per un certo intervallo di tempo. Tutto ciò è seguito da alcune domande a scelta

multipla, alle quali bisogna rispondere.

Il numero di domande, di risposte e di numero di oggetti da analizzare è arbitrario e a

totale discrezione del docente. Un’ulteriore aggiunta potrebbe essere caratterizzata da

un sistema per calcolare un punteggio finale in base alle risposte date.

Un esempio di Widget che utilizza questo pattern può essere definito come un testo da

leggere e da comprendere, per poi rispondere alle domande che lo seguono.

46

Capitolo 3 – ImplementazioneOra che disponiamo di una panoramica generale sugli obiettivi

del progetto, sulle scelte fatte sia in termini di selezione dei

pattern che per quanto riguarda la scelta degli ambienti di

sviluppo e l’utilizzo dei Widgets, è giunto il momento di

abbassare il livello di astrazione e concentrarsi sul dettaglio

implementativo.

In questo capitolo si discuteranno principalmente le soluzioni

proposte nello sviluppo in GWT e Java di Widgets e

Costruttore.

Vedremo che il costruttore è diviso in molti WidgetBuilder, uno

per ogni strumento, e che le strategie adottate per renderlo più

scalabile in previsione di eventuali aggiunte di altri pattern e

relativi Strumenti.

Per garantire una comprensione più approfondita

dell’argomento ci sarà spazio per una breve

descrizione/tutorial che spiegherà come far funzionare

correttamente i Widgets nei vari ambienti supportati.

47

I WidgetsNel primo capitolo ho dato una definizione generale del termine Widget, mentre nel

secondo ho descritto le caratteristiche di ogni strumento sviluppato; in questa parte

invece andrò ad analizzare in che modo si crea, da cosa è formato e come si utilizza un

Widget.

In primis, l'ambiente di sviluppo è Java con Toolkit GWT, del quale sono stati utilizzati

solamente oggetti e metodi che producono codice client-side. Il risultato finale è

un'applicazione Javascript in quanto questo framework compila il codice Java in JS. La

libreria grafica utilizzata mi permette di ottenere una user-interface più fluida e

interattiva ma ha il difetto di rendere più pesante l'applicazione che solitamente si aggira

intorno ai 10-12 megabyte e può crescere se è caratterizzata da molti contenuti

multimediali.

Ogni applicazione, una volta compilata, si presenta come un file .war pronto per essere

caricato su un web server, caratteristica che a noi non interessa poiché abbiamo già

chiarito che gli ambienti in cui l’applicazione deve funzionare non sono tomcat, jetty,

glassfish o quant'altro.

Estraendo l'archivio otteniamo il Widget vuoto o meglio il Template, al quale si

dovranno aggiungere i dati e la configurazione per l'ambiente in cui si vuole utilizzare.

Configurazione per Sankorè 3.1

Il Widget necessita della seguente particolare configurazione per essere utilizzato come

Learning Object in Sankorè.

Configurazione e formato strumento:

il Widget dovrà essere visualizzato come archivio zip con estensione .wgt,

altrimenti non verrà riconosciuto e ne risulterà impossibile l'importazione;

l'archivio dovrà contenere una configurazione a top-level “config.xml” in cui

vengono specificati i seguenti paramentri: id, versione, altezza, larghezza,

possibilità o meno di poter modificare le dimensioni, titolo, sito e indirizzo e-

mail dell'autore, nome dell'autore, descrizione e Url della index page. Tutte

queste informazioni dovranno essere aggiunte dal costruttore qualora si

48

modifichino alcuni campi preimpostati di default;

nell'archivio Widget dovrà inoltre essere presente un’icona “icon.png” (il

costruttore la aggiunge sempre a dimensione fissa 125x125px), nel caso

quest’ultima dovesse risultare mancante Sankorè permetterà ugualmente

l’importazione dello strumento ma, a causa di un piccolo bug, non sarà possibile

utilizzarlo.

Di default, e allo stato attuale anche come unica opzione, il Costruttore permette di

scaricare i Widget nel formato per Sankorè. Una volta caricato nell'ambiente per LIM si

presenterà come una finestra dalle dimensioni impostate, all'interno di una lavagna

virtuale.

Configurazione per Google-Chrome

Abbiamo già accennato che l'esecuzione di uno strumento nel browser di Google

avviene tramite il suo caricamento come estensione. Questa operazione è resa possibile

da una corretta formattazione del Widget.

Configurazione e formato strumento:

il Widget si presenterà come una semplice cartella, quindi sarà necessario

estrarre l'archivio zip .wgt;

il file di configurazione richiesto è “manifest.json”, già presente di default nello

49

Esempio di config.xml; nella configurazione per Sankore viene specificato l'autore, il nome dello strumento, la sua descrizione, le dimensioni, la versione e il link alla pagina principale del Widget

strumento e personalizzabile tramite il costruttore o anche a mano. Questo file

contiene informazioni molto simili a quelle del “config.xml” sopra descritto;

un'icona , “icon.png”, che identifica il Widget insieme al titolo nella schermata

delle estensioni installate .

Dopo averlo caricato e lanciato, lo strumento verrà visualizzato in una comune finestra

web, estendendosi su tutto lo spazio possibile.

Configurazione per Firefox

Questo browser non creerà problemi nell'esecuzione da locale di applicazioni Javascript,

anche senza l'utilizzo di un web server. Sarà quindi sufficiente estrarre l'archivio .wgt e

lanciare la pagina HTML dell'applicazione (solitamente “welcomeGWT.html”).

Una base comume per lo sviluppo di Widget

I vari Pattern danno le direttive per creare strumenti che spesso, sia dal punto di vista

funzionale che di user.-interface, sono molto diversi tra loro. Tuttavia essi condividono

alcuni aspetti fondamentali quali ad esempio i metadati e la configurazione per

l'esecuzione nei vari ambienti ospiti.

Per questo motivo ho creato un'applicazione di base, che possa poi essere utilizzata da

tutti i Widget come punto di appoggio per la loro implementazione. L’applicazione

andrà a fornire:

50

Esempio di manifest.json; nella configurazione per Google-Chrome viene specificato il nome dello strumento, la sua descrizione, il link alla pagina principale del Widget e il link all'icona da utilizzare nell'anteprima.

un Template standard di base per la visualizzazione dei metadati, con relativo

parser per il caricamento degli stessi in una struttura dati;

la configurazione di default, compresa l’icona per Sankorè e Chrome;

la libreria grafica “smartgwt” utilizzata in tutti gli strumenti,

e infine l’'oggetto LearningObject

Ogni Widget verrà poi sviluppato partendo da questo primo livello e andando ad

aggiungere: il template personale, una struttura dati ad hoc ed il parser per caricare le

specifiche date nel config.xml.

Dati

Ogni Widget memorizza i dati, o il riferimento ai dati che lo caratterizzano, in due

oggetti java. Il primo (Learning Pattern) è comune ad ogni tipo di strumento e serve a

contenere tutte le informazioni relative ai metadati e alla configurazione per Sankorè o

per Chrome.

Il secondo è specifico per ogni Pattern ed estende il primo. Quest’ultimo ha il compito

di memorizzare tutte le informazioni specificate nello schema XML, che ho descritto

nel capitolo precedente. Ovviamente se sono presenti dei dati multimediali aggiuntivi ne

verrà memorizzato il riferimento, e non il dato fisico.

In alcune occasioni è risultato necessario implementare altri oggetti di supporto per

memorizzare dati complessi. Ad esempio le immagini sono mappate in un oggetto

Image che ne racchiude la dimensione, il titolo e l'Url.

Dati Aggiuntivi

I dati multimediali sono memorizzati all’interno dello strumento in aree specifiche: le

immagini nella cartella Images, i video nella cartella Videos, i suoni nella cartella

Sounds.

Questa disposizione viene impostata automaticamente dal costruttore in fase di

creazione dello strumento, mentre invece dovrà essere svolta manualmente nel caso in

cui si voglia procedere con una configurazione manuale del Widget.

Nel primo caso i formati supportati dai vari tipi di contenuto multimediale vengono

51

specificati nel costruttore durate la fase di upload dello stesso, nel secondo invece

l'utente viene informato attraverso dei commenti nel file “data.xml”.

Il costruttore di WidgetsL'applicazione web è stata ideata con lo scopo di essere il più possibile dinamica,

intuitica e semplice da utilizzare. La scelta fatta è stata quella di dare uno stile

“Desktop” al software, cosa resa possibile da GWT che tra la moltitudine di Widgets

grafici che mette a disposizione ci sono anche finestre, palette e pulsanti.

Come la grande maggioranza di web-applications presenta sia una parte client-side che

una server-side. Vista la semplicità con cui il toolkit di Google rende possibili molte

operazioni che altrimenti risulterebbero complesse, il più del codice scritto va a

implementare la parte client-side, cosa che rende il tutto più dinamico ed evita inutili

comunicazioni col server che portano a fastidiose attese.

Javascript presenta però delle limitazioni, sopratutto perL'applicazione web è stata

ideata con lo scopo di essere il più possibile dinamica, intuitiva e semplice da utilizzare.

La scelta fatta è stata quella di dare uno stile “Desktop” al software, il che è stato reso

possibile da GWT, toolkit che mette a disposizione, oltre ad una moltitudine di Widgets

grafici, anche finestre, palette e pulsanti.

Come la maggior parte delle web-applications presenta sia una parte client-side che una

server-side. Vista la semplicità con cui il toolkit di Google rende possibili molte

operazioni che altrimenti risulterebbero decisamente più complesse, una gran parte del

codice scritto andrà ad implementare la parte client-side, rendendo il tutto più dinamico

ed evitando inutili comunicazioni col server che porterebbero a fastidiose attese.

Javascript presenta però delle limitazioni, soprattutto per quanto riguarda l'upload, la

gestione di file e la persistenza di dati, per questo motivo è stato necessario aggiungere

alcune funzionalità al server.

Tutte le operazioni di scelta e personalizzazione di un Widget (tranne il caricamento di

file multimediali) sono svolte client-side. Tutta l'applicazione/script Javascript sta in un

unica pagina HTML, il che significa che viene scaricato tutto il codice con la richiesta

della stessa al server. Non sempre questo è necessario poiché accade molto spesso che

52

dopo il primo accesso l'applicazione venga salvata in cache dal browser. Qualora lo

script JS diventasse troppo pesante, rendendo il caricamento molto lento nella fase

iniziale, GWT permette il cosiddetto code-splitting, ovvero offre la possibilità di

spezzare lo script in più parti, che verrano scaricate sul client dinamicamente

all'occorrenza. Allo stato attuale non è necessario utilizzare questa tecnica poiché il

costruttore presenta ancora dimensioni piuttosto ridotte.

MockUp

La user-interface del costruttore è divisa in tre parti. La prima andrà ad occupare una

colonna ridimensionabile alla sinistra della pagina e si estenderà per tutta la sua altezza.

Questa presenta un menu ad albero in cui i nodi definiscono i pattern e le foglie i vari

Widgets. Le foglie rispondono all'evento on click del mouse.

La seconda parte è un pannello posto in alto contenente delle tab identificate da delle

label. Tra queste ce n'è una fissa, la Main-page, mentre le altre corrispondono ai Widget

aperti che si stanno modificando. La selezione di un elemento dal menu di sinistra andrà

a creare una nuova tab, se questa non era ancora stata aperta, altrimenti si posizionerà su

quella precedentemente aperta. Non è quindi consentito personalizzare più Templates

53

Costruttore di Widget; come si presenta l'applicazione all'avvio: il menu degli strumenti disponibili sulla sinistra e una breve guida all'uso nella parte centrale.

uguali contemporaneamente.

La terza parte corrisponde invece alla finestra principale, che andrà a prendere posto in

tutto lo spazio restante della pagina. Quest’ultima presenta generalmente il contenuto

della tab selezionata, se ci troviamo sulla tab Main vedremo il contenuto della pagina

iniziale, dove si espone all'utente un breve tutorial per l'utilizzo del sito. Se invece

avremo selezionato uno strumento, l’applicazione si dividerà a sua volta in due. Sulla

destra andrà a crearsi un menu comune a tutti i Widget, le cui funzionalità verranno

descritte in seguito, mentre nello spazio rimanente troveremo invece gli strumenti che ci

permettono di costruire quello specifico Widget, i cui strumenti sono stati descritti nel

secondo capitolo, nelle sezioni dedicate all'interazione dei costruttori.

Il pannello comune

Questo menu è stato diviso in quattro parti logiche che presentano la stessa user-

interface e le stesse funzionalità (uguale comportamento, ma implementazione specifica

per ogni strumento) per tutti i Widgets. Ad ognuna di esse è adibita una sezione di un

menu a finestre scorrevoli per evitare che occupino troppo spazio e che creino problemi

di visualizzazione nel caso di schermi piccoli.

Le parti in questione sono le seguenti:

una descrizione/tutorial sulle caratteristiche dello strumento e sulle modalità di

utilizzo o personalizzazione;

una form in cui l'utente è obbligato a riempire i campi relativi ai metadati per il

Learning Object che si sta creando;

una form facoltativa i cui dati, se inseriti, andranno a modificare la

configurazione di default per quello strumento;

e infine una serie di funzionalità presentate sotto forma di pulsanti per

permettere all'utente di: salvare il lavoro fatto fino ad ora, creare lo strumento,

visualizzare un'anteprima del risultato finale, svuotare il Template per poter

iniziare una nuova configurazione e caricare dei dati già esistenti per modificare

un Widget già presente.

54

Il Back Button

Le applicazioni Javascript che, come in questo caso, girano sulla stessa pagina web, la

quale viene creata e rigenerata dinamicamente, presentano il problema del back-button.

Se un'utente prova a tornare indietro alla “pagina-precedente” utilizzando il pulsante

indietro del browser il risultato non sarà quello aspettato. Si rischia di venir “buttati

fuori” dall'applicazione e di ritrovarsi su un sito precedentemente visitato, trovandosi

una situazione piuttosto spiacevole.

Fortunatamente il toolkit Google presenta una classe History, tramite la quale è

possibile interagire con i comandi avanti e indietro del browser in modo completamente

trasparente agli occhi dell'utente.

Senza entrare nello specifico, vediamo in che modo è stato utilizzato nel progetto. Per

distinguere una configurazione della pagina dall'altra ci si deve associare un token,

55

Pannello Comune; menu e form comunitari a tutti i WidgetBuilder, la descrizione è diversa per ogni strumento.

ovvero un identificatore. Ogni Widget presenta un suo token che viene visualizzato in

fondo all'Url nel browser; per fare un esempio, quando sto personalizzando il Widget

parole-contenitori la pagina è identificata da un gettone “#parole-contenitori”. E' proprio

questo che permette alla classe History di mantenere traccia delle varie configurazioni

delle pagine passate e di ricaricarle qualora si utilizzino i pulsanti back e forward.

Supponiamo che per errore l’utente abbia chiuso la tab dello strumento che stava

creando, grazie a questa funzionalità sarà sufficiente utilizzare il pulsante back per farla

ricomparire e continuare a modificarla. Se invece la pagina verrà chiusa o ricaricata, il

problema che si verrà a presentare è un altro e sarà analizzato in seguito.

La struttura collettiva dei WidgetBuilder

Dividiamo il costruttore in tante parti, ognuna delle quali gestisce la personalizzazione

di un singolo Strumento e identifichiamole come WidgetBuilder.

Ognuno di questi estende la classe astratta CommonPanel, la quale ha il compito di

gestire non solo la comunicazione con il server, ma anche tutta la parte di user-interface

e elaborazione dati che risulta essere uguale in tutti gli strumenti.

Tutto il resto lo delega tramite metodi astratti ai vari WidgetBuilder, i quali dovranno

provvedere all'implementazione. Per fare un esempio concreto, il metodo

getViewPanel() dichiarato nel CommonPanel e ridefinito nel WidgetBuilder deve

contenere tutta l'interfaccia grafica relativa ai componenti necessari per la

personalizzazione dello strumento in questione.

Questa soluzione è stata adottata con lo scopo di evitare inutili copie dello stesso codice

in tutti i WidgetBuilder e per migliorare la scalabilità del programma, qualora si

volessero aggiungere nuovi Template o nuove funzionalità comuni, come ad esempio la

modifica di un Widget attraverso l'upload dello stesso.

La gestione dell'Utente

L'utente viene gestito da una classe condivisa tra client e server, la UserWorks. In

quest’ultima è implementata una lista di “lavori attivi”, ovvero i Widget che si stanno

modificando in quella precisa sessione. Come già detto un utente può modificare un

56

solo strumento per Template alla volta; quando viene aperta una nuova tab Widget,

l'applicazione va a cercare in questa classe se esiste già una configurazione per quello

strumento, e in caso positivo ne carica i dati, mentre in caso negativo aggiunge una

nuova istanza per quel template ai lavori dell'utente.

In che modo questa interagisce col server è descritto nel capitolo riguardante le

caratteristiche del server.

Operazioni Utente

Ogni WidgetBuilder riscrive i metodi che permettono all'utente di: salvare il lavoro,

svuotare il Template, vedere l'anteprima e creare il Widget. Nel seguente paragrafo si

tratterà solo la parte client-side, in quanto ciò che accade lato server lo descrivo nello

spazio a lui dedicato.

Operazioni:

SALVA: ogni volta che l'utente fa una modifica questa viene automaticamente

salvata all’interno degli UserWorks, risulterà quindi inutile la presenza di un

pulsante per il salvataggio. Cosa accade però se l'utente ricarica o chiude e riapre

la pagina? I dati erano tutti salvati lato client e quindi andrebbero persi. Il

compito di questa funzionalità sarà quindi quello di persistere l'UserWorks sul

server con lo scopo di evitare questo tipo di problemi. Durante il caricamento

iniziale della pagina lo script controlla se sul server siano già presenti dei lavori

ed eventualmente aggiorna la UserWorks.

SVUOTA il TEMPLATE: operazione molto semplice che resetta la

configurazione per il template in questione, sia lato client che lato server.

ANTEPRIMA: Alcuni WidgetBuilder (non tutti), in cui la presentazione degli

oggetti durante la configurazione è diversa da quella di utilizzo (per esempio nei

pattern Grafici), implementano una funzione anteprima per dare modo al

docente di farsi un'idea sul risultato finale.

CREAZIONE WIDGET: Questa operazione è la più complessa, poiché va a

creare una stringa XML da inviare al server contenente: i metadati dello

strumento, i dati relativi alla personalizzazione in questione e la configurazione

del Widget. A questo punto la domanda sorge automatica: perché non inviare

57

semplicemente l'oggetto relativo allo strumento, contenente già tutte le

informazioni? La risposta al quesito è legata alla scalabilità del software, in

particolare per facilitare l'aggiunta di nuovi WidgetBuilder senza dover

aggiungere codice server-side. Il server è generico e non conosce quindi i pattern

dei singoli strumenti. Esso presenta un unico metodo che riceve un documento

XML e ne estrapola le informazione necessarie per la creazione del Widget..

Questo XML viene scritto in parte dal CommonPanel (metadati e wgtcfg) e in

parte dal WidgetBuilder (configurazione strumento). Vedremo poi come il server

processerà queste informazioni.

La Comunicazione Client-Server

Uno dei più potenti tool forniti da GWT è il Remote Procedure Calls (RPC), che

permette di unire client e server-side code insieme. RPC ha la facoltà di rendere

praticamente invisibile la connessione tra le due parti, anche se presenta alcune

limitazioni: ad esempio un oggetto per essere trasferito da una parte all'altra deve essere

serializzabile. La differenza maggiore tra RMI, (Remote Method Invocation ) utilizzato

in Java, e RPC è che il primo è sincrono, ovvero blocca il programma finché il server

non risponde, mentre il secondo è asincrono e quindi offre la possibilità fare altro

mentre si attende la risposta.

Solitamente, e anche nel caso del progetto, RPC viene usato per comunicare con delle

Java servlet. Questa operazione avviene tramite la chiamata di metodi definiti in una

classe servlet sul server.

Il Costruttore di Widget andrà ad utilizzare due di queste classi: la prima (User Service)

contiene i metodi per il recupero dei lavori utente (backup) e per la creazione del

Widget. La seconda invece (Server Service) verrà utilizzata per la gestione dell'upload

di risorse già presenti in rete.

L'RPC non è l'unico sistema usato da GWT per contattare il server, è possibile anche

inviare delle richieste HTTP asincrone a delle servlet, a cui il server risponderà con testo

XML o JSON facilmente parsabile. Questa tecnica l'ho utilizzata nel progetto per

l'upload di file da locale.

58

Il metodo SendXmlPattern

All'azione Crea Strumento lanciata dall'utente ne consegue l'invocazione del metodo

sendXmlPattern(String XML) che attraverso l'RPC invia al server la configurazione

completa del Widget sottoforma di stringa in formato XML. Analizziamo ora più in

dettaglio la composizione di quest'ultima basandoci su un esempio concreto.

I° Parte – Configurazione Widget

In questo ritaglio all'interno del tag <wgt-config> si trovano tutte le informazioni

necessarie alla configurazione del Widget.

II° Parte – Additional Data

Contenute nei tag <additional-data> sono racchiuse tutte le informazioni necessarie al

server per sapere quali dati multimediali precedentemente caricati sono stati utilizzati

dal Widget. Con questi dati il server è in grado di aggiungere allo strumento finale

solamente gli oggetti che l'applicazione andrà realmente ad utilizzare. Per ogni risorsa

viene specificato: l'URL, il tipo (immagine, video,suono), il nome e l'impiego

(attraverso un campo booleano).

59

III° Parte – Metadata

Questa parte è molto simile al primo pezzo del file “data.xml” al quale verranno infatti

aggiunti questi metadati.

IV° Parte – Pattern Config

I tag <pattern-config> racchiudono la personalizzazione vera e propria del Widget.

Come già detto il server è strutturato in modo da lavorare alle stessa maniera con ogni

tipo di strumento (non riesce a distinguere un pattern da un altro); è per questo che le

caratteristiche del Widget sono trasportate tra client e server come commento. Il parser

lato server prende tutto il commento come se fosse una singola informazione e va ad

aggiungerlo al file “data.xml” dello Strumento in questione.

L'informazione template permette al server di associare i dati al giusto archivio.

La sessione utente

Approfondiamo ora come i lavori utente vengono salvati, modificati e messi a

disposizione dal server. L'evento salva lavoro sollevato dal client porta alla chiamata di

un metodo che, attraverso l'RPC, contatta il server e gli passa tutto l'oggetto

UserWorks. A questo punto il server controlla se esiste già una sessione attiva per

quell'utente; se non ne è ancora stata creata una la crea e ne imposta un time out di

60

quattro ore, quindi andrà ad aggiornare o ad aggiungere il riferimento alla UserWorks

attuale alla sessione.

Ogni volta che l'utente ricarica il costruttore oppure chiude e riapre il browser verrà

fatto un controllo sul server per vedere se ci sono dei lavori salvati che, eventualmente,

verranno restaurati.

L'operazione Svuota Widget invece aggiorna la UserWorks, sostituendo il vecchio

lavoro con una nuova istanza per quel pattern e ne invia le modifiche al server per

mantenerlo sincronizzato.

La gestione dei file

Il caricamento di file multimediali e la creazione di un Widget portano dei nuovi dati sul

server che dovranno essere salvati e mantenuti almeno per tutta la durata della sessione

utente. Questi dati, o più precisamente questi files sono personali e dovranno risiedere

in uno spazio dedicato, diverso per ogni utilizzatore. E' assolutamente impensabile

salvarli tutti nella stessa cartella condivisa, senza mantenere un riferimento al

proprietario in quanto non è possibile stabilire quando eliminare un file ormai vecchio e

si andrebbero a creare dei problemi di conflitto nei nomi se due docenti caricano lo

stesso file multimediale oppure se danno lo stesso nome allo strumento.

Per risolvere questo problema si è deciso di adottare un sistema a cartelle. Ogni utente

che corrisponde ad una sessione attiva avrà la sua cartella temporanea sul server, nella

quale verranno salvati i suoi caricamenti e i suoi lavori. Questa cartella avrà come nome

il codice di sessione e risulterà quindi impossibile averne due con lo stesso

identificativo. Cosa succede però se un docente carica due file con lo stesso nome? In

questo caso il server opera una sovrascrittura del primo portando ad una situazione di

inconsistenza dei dati. Per questo motivo, ogni oggetto caricato verrà quindi rinominato

aggiungendo al nome anche il tempo in millisecondi dal 1980 in poi.

A questo punto rimane ancora un quesito da risolvere, supponiamo che il server sia

sempre on e che quindi ogni sessione crei la sua cartella e ci salvi i contenuti, che

magari possono arrivare anche a 10-20 megabyte. Se l'applicazione è molto utilizzata in

poco tempo il server può raggiungere grandi dimensioni e continuare a crescere. I

61

contenuti vecchi (quelli associati ad una sessione non più presente) diventano inutili ed

è quindi necessario eliminarli definitivamente. A questo scopo sul server è presente un

SessionListener, il quale ha il compito di controllare le sessioni attive e di riscontrarle

con le cartelle degli utenti; ogni volta che l’applicazione si imbatterà in una cartella che

non è più associata ad una sessione, la eliminerà.

In questo modo la dimensione del server rimane controllata e vengono mantenuti in

memoria solamente i contenuti utili.

I Templates sul server

Il costruttore associa la configurazione fornita dall'utente al Template corrispondente. Il

server ha memorizzato nella cartella “templates/“ tutti i template vuoti associati agli

strumenti i quali sono salvati come archivio .zip.

La creazione del Widget

Il procedimento per la creazione dello Strumento è la parte più elaborata svolta dal

server e necessita di una classe statica che utilizza un parser XML per trovare tutte le

informazioni contenute nell'XML ricevuto dal client, e anche di una libreria che

permette di lavorare con gli archivi zip.

Il server procede con la creazione nel seguente modo:

1. ricezione dell'XML dal client e successivo invio alla classe che ne effettua il

parsing;

2. recupero del nome del template utilizzato e del titolo del nuovo strumento;

3. copia del template in questione da /templates a tmp/SessionId e rinomina del file

con titolo scelto dall'utente;

4. estrazione del template utilizzando la libreria sopra citata in una cartella

omonima;

5. entro nella nuova cartella, apro il file config.xml (parametri per la

configurazione per Sankorè) di default e lo aggiorno con i nuovi dati presi

dall'XML;

6. entro nella nuova cartella, apro il file manifest.json (parametri per la

62

configurazione per Chrome) di default e lo aggiorno con i nuovi dati presi

dall'XML;

7. creo un nuovo file data.xml utilizzando i dati presenti nell'XML e lo sostituisco

a quello di default presente nel template;

8. leggo i riferimenti ai dati aggiuntivi (contenuti multimediali) presenti nell'XML

e aggiungo i vari file fisici al template;

9. comprimo il nuovo Widget e lo rinomino .wgt;

10. ritorno al client il link per scaricare il nuovo strumento.

NOTA: nella stringa XML passata al server, la configurazione specifica è diversa per

ogni strumento ed è stata aggiunta come commento per non venire parsata in quanto il

server non conosce tutti i pattern e non sa come interpretare i vari tag. L'intero blocco

commentato verrà preso e aggiunto al file data.xml, togliendo i caratteri di commento.

L'Upload

Sono stati implementati due tipi diversi di upload, il primo consiste nel classico

caricamento di contenuti presenti localmente sulla macchina dell'utente, il secondo

invece sfrutta una parte della libreria Search fornita da Google per la ricerca di

immagini sul web. Quest'ultimo permette solamente il caricamento di immagini.

Entrambi permettono il ridimensionamento, sia con deformazione che non, e il ritaglio

dell'immagine; i parametri per usufruire di queste funzioni vengono passati insieme al

file da caricare dal client.

63

Finestra presentata all'utente una volta terminata l'operazione di creazione dello strumento dalla quale è spossibile scaricare il Widget.

Una volta completato l’upload, il server ritorna le informazioni per poter reperire

quell'oggetto appena salvato nella cartella utente sul server.

Si è cercato di rendere queste operazioni il più generiche possibili per permettere ai vari

WidgetBuilder di usare gli stessi oggetti per il caricamento, in particolare sono state

create due versioni della form di upload: una per il caricamento di un file singolo e

l'altra per l'upload di più file contemporaneamente.

Caricamento da Locale

Dopo aver sollevato l'evento upload, il server riceve il file su di una servlet assieme ad

alcuni parametri, per il momento queste opzioni sono legate esclusivamente al

caricamento di immagini poiché gli strumenti presenti non necessitano di altri file

multimediali.

Operazioni svolte dalla servlet:

1. recupero dei parametri passati via GET riguardanti: dimensioni massime,

mantenimento proporzioni, massimizzazione immagini, ritaglio immagine;

2. controllo se la cartella utente è già presente, altrimenti la creo;

3. aggiusto il nome del nuovo file aggiungendo il time in millisecondi dal 1980 e lo

salvo;

4. se devo ridimensionare l'immagine chiamo un metodo statico che svolge il

lavoro e sovrascrive il vecchio file;

5. se devo ritagliare l'immagine chiamo un altro metodo statico che crea i ritagli e

li salva nella cartella utente;

6. torno al client un XML contenente le informazioni sull'oggetto caricato, quali

nome, url, dimensione e, nel caso in cui abbia ritagliato l'immagine in più parti,

torno una stringa più complessa per descrivere ogni singola zona.

Non è detto che il WidgetBuilder utilizzi tutti i dati caricati, per questo essi non vengono

aggiunti di default allo Strumento durante il processo di creazione, bensì è il client che

informa il server sui file che devono essere trasferiti o meno nel momento in cui gli

passa la configurazione tramite XML.

64

Caricamento da Web

Mentre nel caso precedente si trattava di una Servlet invocata tramite una semplice

richiesta http con alcuni parametri GET che svolgeva il lavoro, in questo caso la

situazione è gestita da altri metodi invocati tramite una richiesta RPC. Queste funzioni

permettono di fare le stesse cose descritte in precedenza, con la differenza che alla

servlet, oltre ai parametri di configurazione aggiuntivi, arrivava anche il file fisico,

mentre ora ai metodi viene passata l'Url del file presente in rete.

Il server dovrà quindi aprire una socket, richiedere l'immagine al server web che la

ospita, ed infine processarla seguendo gli stessi punti precedentemente descritti.

Un'altra differenza rispetto al caricamento da locale è che, una volta terminata

l'elaborazione, il server torna al client un oggetto già pronto con tutte le informazioni

necessarie e non una stringa XML da parsare.

65

Caricamento di più immagini da locale; viene effettuato l'upload multiplo di immagine dal proprio Pc al web server.

Elaborazione di Immagini

La classe ImageProcessing aiutata dalla libreria Graphics2d si occupa di modificare

l'immagine in base ai parametri passati. L'editing prevede:

Scalo dell'immagine mantenendo le proporzioni e massimizzandone le

dimensioni nell'area definita

Scalo dell'immagine senza mantenere le proporzioni e massimizzandola nell'area

definita

Entrambi i punti precedenti senza però massimizzare l'immagine, se la figura è

più piccola del riquadro ne vengono mantenute le dimensioni.

Ritaglio dell'immagine in più parti ognuna identificata da una riga ed una

colonna

Distribuzione e Installazione dell'applicazione

Distribuire un'applicazione web che necessita di un server specifico supportante le Java

66

Caricamento multiplo da Web utilizzando il motore di ricerca di immagini fornito da Google.

Servlet per funzionare e la cui installazione risulti semplice ed intuitiva da parte di un

utente con capacità informatiche nella media ha richiesto la presenza di un componente

aggiuntivo: una versione embedded del leggero web server Jetty.

Non viene quindi distribuita l'applicazione web .war ma si fornisce all'utente un classico

eseguibile Java .jar e un file di configurazione se eventualmente si vuole modificare il

nome e la porta che identificano la web app.

Questo programmino una volta lanciato avvia il web server che si mette in ascolto sulla

porta specificata nel file di configurazione, carica il Costruttore di Widget e, se presente

sulla macchina, apre il browser predefinito all'indirizzo dell'applicazione web.

Da questo momento e finché il server resta attivo sarà possibile raggiungere il

programma per la creazione di strumenti ogni qual volta si voglia e da qualsiasi host

della rete attraverso un comune browser.

Ovviamente è necessario avere una Java Virtual Machine (JRE) installata sul PC che fa

da server per poter installare il programma.

67

Conclusioni e Next Steps

Questo lavoro è il risultato di uno studio riguardante la ricerca e l'individuazione di

Patterns Didattici, seguito dallo sviluppo di applicazioni da essi derivate.

L'obiettivo della tesi era quello di realizzare degli strumenti interoperabili in diverse

piattaforme ed ambienti, al fine di supportare e facilitare l'insegnante nell'esposizione di

contenuti, mediante l'uso di una Lavagna Interattiva Multimediale.

Ho discusso di come il Costruttore semplifichi notevolmente il lavoro di

personalizzazione di un Widget Didattico, seguendo l'utente passo per passo durante la

fase di creazione, azione che altrimenti, se fatta manualmente, richiede delle abilità

informatiche che superano decisamente il livello medio di conoscenza di un insegnante.

Il suddetto Builder è stato ideato e sviluppato per permettere al programmatore

l'aggiunta di nuovi strumenti nella maniera più semplice possibile e fornendo anche

delle funzionalità generiche come ad esempio l'upload di contenuti multimediali e la

gestione dell'utente.

Questa facilità di espansione lo rende già proiettato verso un domani in cui si deciderà

di implementare nuovi Widget Didattici, magari con un target di riferimento diverso da

quelli descritti in questo elaborato. L’obiettivo principale che si è cercato di raggiungere

con la creazione di questo strumento era infatti quello di fornire una base comune alla

quale possano essere aggiunte facilmente nuove tessere.

Successivamente sono passato ad analizzare i Widget che possono essere visti come dei

Learning Object i quali, come ho accennato nel primo capitolo, devono risultare

facilmente reperibili all'interno di un repository grazie alla presenza dei metadati.

Attualmente non esistono repository in rete che riescano ad estrapolare i metadati in

automatico da questo tipo di oggetti a causa del loro particolare formato, per questo

motivo sarà compito dell'utente inserire le informazioni riguardanti lo strumento

caricato in modo manuale. Questo problema è stato risolto nel repository per LO,

sviluppato anch'esso per il progetto Wii4Dida da un mio collega, che è in grado di

ricavare i metadati in automatico dopo il caricamento della risorsa.

Per quanto riguarda invece la parte relativa al test, il Costruttore di Widget è stato

68

passato ad un membro del progetto Wii4Dida, il quale ha riscontrato alcuni problemi e

mi ha quindi consigliato di apportare delle modifiche software per rendere sia Strumenti

che Costruttore maggiormente User-Friendly. In questo momento il progetto si trova

ancora in questa fase, alla quale seguirà poi una prima distribuzione ad insegnanti e

maestri coinvolti nel progetto Wii4Dida con lo scopo di ottenere feedback e consigli per

apportare eventuali modifiche o espansioni al software.

L'augurio per il futuro è quello di un uso utile e produttivo delle applicazioni presentate

in questa tesi, nell'ambito del progetto regionale di introduzione di Lavagne Interattive

Multimediali nelle scuole, con la speranza di osservare una crescita positiva

dell'iniziativa che porterà ad un nuovo livello di qualità l'istruzione delle scuole

Trentine.

69

Bibliografia Articolo sulle LIM, http://www.pianetascuola.it/didattica/articolo/lim-la-lavagna

-interattiva-multimediale

Articolo sulle LIM, http://it.wikipedia.org/wiki/ Lavagna_interattiva _multi med iale

Articolo sui LO, http://it.wikipedia.org/wiki/Learning_object

Articolo sui LO, http://www.indire.it/content/index.php?action=read&id=1183

Sito web di SMART, http://smarttech.com/

Sito web di Sankorè, http://sankore.org/

Sito web progetto Wii4Dida, https://sites.google.com/site/wii4dida/

Tesi sulle LIM con WiiMote, http://latemar.science.unitn.it/wiki_lavagne/ images/e/ea/Tesi-limwii-alessio-giori.pdf

Federico Kereky, Essential GWT building for the Web with Google Web Toolkit (2010)

Documentazione di GWT, http://code.google.com/webtoolkit/doc/latest/ DevGuide.html

Showcase di SmartGwt, http://www.smartclient.com/smartgwt/showcase/

Google Api Libraries for GWT, http://code.google.com/p/gwt-google-apis/

XML parsing in Java, http://www.java-tips.org/java-se-tips/javax.xml.parsers/ how-to-read-xml-file-in-java.html

70

http://www.pianetascuola.it/didattica/articolo/lim-la-lavagna

http://www.java-tips.org/java-se-tips/javax.xml.parsers/how-to-read-xml-file-in-java.html

http://www.java-tips.org/java-se-tips/javax.xml.parsers/how-to-read-xml-file-in-java.html

http://www.java-tips.org/java-se-tips/javax.xml.parsers/

http://code.google.com/p/gwt-google-apis/

http://www.smartclient.com/smartgwt/showcase/

http://code.google.com/webtoolkit/doc/latest/DevGuide.html

http://code.google.com/webtoolkit/doc/latest/DevGuide.html

http://code.google.com/webtoolkit/doc/latest/

http://latemar.science.unitn.it/wiki_lavagne/images/e/ea/Tesi-limwii-alessio-giori.pdf

http://latemar.science.unitn.it/wiki_lavagne/images/e/ea/Tesi-limwii-alessio-giori.pdf

http://latemar.science.unitn.it/wiki_lavagne/

https://sites.google.com/site/wii4dida/

http://sankore.org/

http://smarttech.com/

http://www.indire.it/content/index.php?action=read&id=1183

http://it.wikipedia.org/wiki/Learning_object

http://it.wikipedia.org/wiki/Lavagna_interattiva_multimediale

http://it.wikipedia.org/wiki/Lavagna_interattiva_multimediale

http://it.wikipedia.org/wiki/

http://www.pianetascuola.it/didattica/articolo/lim-la-lavagna-interattiva-multimediale

http://www.pianetascuola.it/didattica/articolo/lim-la-lavagna-interattiva-multimediale

UNIVERSITA’ DEGLI STUDI DI...

Documents

Transcript of UNIVERSITA’ DEGLI STUDI DI...