universita’ degli studi di...
Post on 25-Jun-2020
7 Views
Preview:
TRANSCRIPT
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
2
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.
Interazione Costruttore:
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.
Interazione Costruttore:
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.
Interazione Costruttore:
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
top related