La mobilizzazione di un sito web, consiste nel far fruire lo stesso contenuto sui più device mobili, cercando di sfruttare al meglio le potenzialità del device che accetta.

Catalogazione di siti

Tecnologia adottata

La tecnologia con cui il sito è stata sviluppata potrebbe costituire un forte vincolo dell’applicativo che vogliamo utilizzare per la mobilizzazione.

Per esempio se il sito è scritto in linguaggi interpretati come Perl,TCL, PHP la mobilizzazione può essere fatta utilizzando prodotti opensource ma che non hanno raggiunto una stabilità nel mondo mobile.

.NET di Microsoft fornisce la soluzione .NET Mobile, il quale permette tramite il suo ambiente di sviluppo “Microsoft Visual Studio .NET” di sviluppare siti verso il mondo mobile.

JAVA è l’ambiente di sviluppo sulla quale sono state sviluppate la maggior parte del software più avanzato, partendo dal Opensource (per es. Wurfl) a quelli proprietari (Mobileaware, Infogin, Volantis, etc. etc.). Questi oggetti in genere sono integrabili con i portalframework più in uso (struts, Vignette Application Portal, Bea Portal, Websphere etc. etc.)

Macromedia sta sviluppando un Player Flash per device mobile (vedi allegato)

Architettura tecnologica

Anche questo aspetto è molto importante in quanto bisogna analizzare se si il sito da analizzare ha una fonte dati unica o più di una (VCM, DB, Ldap, Active Directory). Se adotta qualche sistema per la sicurezza (criptazione dei dati, cerificati digitali, otp etc.).

Analisi dei contenuti

La navigazione di un sito che si vuole mobilizzare può essere un vincolo, se non un limite. L’uso per esempio di menu dinamici, di frame, mappe “cliccabili” sono esempi di oggetti non trasportabili in maniere automatica quindi necessitano di soluzioni custom.

Inoltre bisogna analizzare se i contenuti provengono da un solo sito oppure da altri siti esterni (come avviene per www.i.tim.it).

Individuazione dei contenuti/servizi che hanno senso ad essere mobilizzati, e una volta individuati cercare di farli raggiungere con pochi click per non rendere il servizio poco utilizzabile.

Vi sono molteplici aspetti del contesto di distribuzione capaci di influenzare quale rappresentazione di un contenuto web vada meglio trasmessa in risposta ad una richiesta. In questa sezione, suggeriamo un insieme di potenziali caratteristiche che potrebbero essere espresse nel contesto di distribuzione. Comunque, tale insieme è aperto, cosicché questo elenco è solo illustrativo.

• Interazione
  • modalità di presentazione (output) e relativi parametri
  • modalità di inserimento (input) e relativi parametri
• Capacità dei programmi di navigazione
  • capacità di elaborazione (scripting etc)
  • formati accettati e generati (e.g. MIME types)
• Connessione
  • larghezza di banda, tempi di risposta
  • reti e protocolli
  • informazioni associate agli operatori di telecomunicazione
• Locazione
  • coordinate geografiche
  • prossimità ad altre risorse
  • ora del giorno
• Localizzazione
  • lingua del luogo
  • fuso orario del luogo
• Ambiente
  • temperatura
  • illuminazione
  • rumore
• Livello di discorso
  • complessità del contenuto testuale
  • livello di dettaglio dei contenuti
• Affidabilità
  • riservatezza e sicurezza
  • restrizioni sui contenuti

Tecnologia per la mobilizzazione

Premessa (fonte W3C)

Vi sono già vari approcci per definire il contesto di distribuzione, o almento alcuni aspetti di esso. Del resto, il bisogno di negoziare quale versione di un documento debba essere inviato ad un utente è stato riconosciuto fin dai primi giorni del Web [HTTPneg].

In questa sezione sono esaminati i principali approcci che sono già in uso sul Web.

HTTP headers

Il protocollo HTTP [HTTP] è alla base della trasmissione di informazione via Web. Esso definisce un numero di intestazioni di accettazione standard che possono essere utilizzate per far incontrare le capacità di un dispositivo richiedente (o, in particolare, il suo programma utente di navigazione) con l'informazione veicolata da un server di origine. Le intestazioni standard di HTTP 1.1 includono:

Accept: i tipi di media (MIME types) accettati dal programma di navigazione

Accept-Charset: i set di caratteri accettati dal programma di navigazione

Accept-Encoding: la codifica (compressione) preferita dal programma di navigazione per la risposta

Accept-Language: i linguaggi naturali preferiti dagli utenti

In aggiunta alle intestazioni di accettazione , le intestazioni dei programmi di navigazione contengono usualmente una stringa che contiene informazioni circa il programma di navigazione stesso. Tipicamente essa include il nome del produttore, il numero di versione e il nome del programma. Per i dispositivo mobili essa include spesso informazioni sull'hardware del dispositivo e sul browser in uso. Non ci sono standard sul modo in cui queste informazioni sono costruite. Ciononostante, sofisticati algoritmi possono essere utilizzati per cercare di identificare il dispositivo o il browser utilizzato. L'adattamento del contenuto può quindi essere basato sulla conoscenza di queste capacità.

Sebbene le intestazioni HTTP siano attualmente le informazioni sul contesto più diffusamente utilizzate, esse sono difficili da estendere e hanno (in particolare nel caso delle intestazioni dei programmi di navigazione) libere forme di espressione che sono difficili da interpretare.

CC/PP

Il W3C ha specificato una struttura di dati e un vocabolario esemplificativo per definire profili per la trasmissione di informazioni relative al contesto di distribuzione. L'attuale Composite Capabilities/Preferences Profile (CC/PP) [CCPP-struct-vocab] è basato sulla tecnologia XML Resource Description Framework (RDF) [RDF].

La struttura di CC/PP è indipendente dal vocabolario e consente di usare uno o più vocabolari che possono essere descritti opzionalmente utilizzando RDF Schema.

Dal momento che CC/PP è indipendente dal vocabolario, esso consente che siano sviluppati differenti vocabolari dalle comunità coinvolte nella realizzazione di applicazioni, dispositivi e browsers. Esso, inoltre, permette la composizione dinamica di un profilo del contesto di distribuzione a partire da frammenti di informazioni sulle capacita che possono essere distribuiti in più di un punto sul web.

CC/PP è l'approccio preferibile per comunicare informazioni sul contesto di distribuzione tra client, intermediari e server di origine. Esso è alla base di UAProf, che è attualemente utilizzato per esprimere le capacità di molti dispositivi mobili. Esistono numerose implementazioni [CCPP-implem] che elaborano i profili CC/PP, e vi è anche una definizione di interfaccia della Java Community per gli utilizzatori dei profili [JSR188].

La CC/PP Recommendation [CCPP-struct-vocab] offre una struttura e un vocabolario di esempio basato sulla versione di RDF corrente al momento del suo sviluppo. Ci si aspetta venga aggiornata con l'ultima revisione di RDF [RDF-concepts] e di RDF Schema [RDF-schema], e che sia estesa per includere il supporto per capacità asserite da intermediari come proxies e gateways. Ulteriore lavoro è inoltre richiesto per specificare un protocollo di scambio dei profili CC/PP, nonché per specificare come un profilo debba essere elaborato e usato all'interno un meccanismo per l'adattamento del contenuto.

UAProf

La Open Mobile Alliance (OMA, in precedenza WAP Forum) ha definito lo User Agent Profile [UAProf] come implementazione di CC/PP per i terminali abilitati al WAP, realizzando una convergenza tra le tecnologie per il mobile web con quelle del Web.

WAP 1.2.1 raccomanda il trasporto delle informazioni UAProf via Internet utilizzando lo HTTP Extension Framework [HTTPex] inizialemente suggerito per CC/PP [CCPP-exchange]. WAP definisce il protocollo WSP, che include una codifica compressa per usi tra il telefono e il gateway su Internet. A causa di mancanze di implementazioni di HTTPex, WAP 2.0 definisce quindi un'estensione di HTTP 1.1 come protocollo Internet (W-HTTP) che si avvale di intestazioni personalizzate.

Il WAP Forum ha inoltre definito un vocabolario per UAProf, basato su CC/PP, che include le caratteristiche hardware e software cosi come le caratteristiche WAP del terminale mobile e le relative informazioni sulla rete di trasporto. Successivi aggiornamenti, a UAProf V2.0, da parte di OMA sono basati sulla definizione dell'ultima versione di RDF e di RDF Schema.

Wurfl

WURFL , [WURFL], è un progetto opensource che offre una fonte di informazioni alternativa a UAProf. Esso cerca di fornire una comprensiva risorsa di informazioni sui dispositivi e contiente informazioni su circa 4500 varianti di dispositivi. Poiché WURFL è opensoucre, tutti possono correggere queste informazioni, non solo i produttori. WURFL possiede un proprio formato XML per la descrizione delle caratteristiche dei dispositivi.

Media Queries

Nelle raccomandazioni W3C, come CSS e HTML, il codice di stile può essere condizionato dal contesto di distribuzione facendo uso delle Media Queries [MQ]. Queste introducono un altro vocabolario per accedere alle caratteristiche dei dispositivi.

Media Queries sono costruite sull'uso dei 'media types' così come definite CSS2 [CSS2], che consentono agli stili di essere subordinati ad un numero di denominate categorie di dispositivi: aurali, braille, embossed, palmari, stampanti, proiettori, schermi, mezzi a carattere di dimensione fissa e televisori. Nelle Media Queries, le caratteristiche dei dispositivi ('media features') possono essere interrogate e combinate utilizzando una ristretta sintassi. Lo stile usato per presentare un elemento HTML, XHTML o XML può perciò essere condizionale rispetto alle caratteristiche del dispositivo finale. Facendo uso della proprietà CSS 'display', è così possibile includere o escludere interi elementi dalla presentazione in funzione del dispositivo.

In futuro, dovrebbe perciò essere possibile aggiungere uno stile dipendente dal dispositivo ad un contenuto che ne è indipendente, fino al punto in cui i tipi di media CSS e le caratteristiche dei media lo consentiranno.

Come CSS, le Media Queries sono tipicamente elaborate direttamente dal programma di navigazione, in base al locale contesto di distribuzione. In ogni caso, esse possono anche essere pienamente o parzialmente elaborate dai server o da intermediari lungo il processo di risposta, in base ad informazioni sul contesto passate come parte della richiesta di un contenuto. Questo sottolinea il bisogno di un vocabolario da usare per le capacità dei dispositivi che corrisponda al vocabolario usato all'interno delle Media Queries.

SMIL

Un altro standard W3C, il Synchronized Multimedia Integration Language (SMIL) introduce un ulteriore vocabolario per accedere ad un limitato insieme di caratteristiche dei dispositivi.

SMIL 2.0 [SMIL] è definito come un insieme di moduli di markup che possono essere integrati in specifici profili di lingaggio. In particolare, esso definisce un BasicContentControl Module che specifica determinate caratteristiche di sistema che possono essere utilizzate per controllare le presentazioni SMIL. Queste caratteristiche possono ricevere valori dinamici in accordo all'ambiente di esecuzione. Come le Media Queries, esse consentono ad un programma di navigazione che supporti le caratteristiche SMil dinamiche di accedere ad informazioni locali sul contesto di distribuzione.

Le caratteristiche di test del sistema incluse come parte del BasicContentControl Module coprono le capacità associate alla presentazione dei contenuti, come le dimensioni dello schermo, la larghezza di banda, le intestazioni testuali e audio, così come caratteristiche relative al sistema come l'identità della CPU e del sistema operativo.

TCL, Perl e PHP

Per questo tipo di tecnologia, che si basa su delle engine che in genere risiedono direttamente nel web server e quindi in una architettura basata a due strati (2-tier).

Sono stati sviluppati dei moduli (per es. wall) che aiutano lo sviluppatore a implementare dei siti mobili, mettendo all’interno del codice comandi ad hoc.

In genere i questi moduli si basano su tecnologia DTD (formattazione del xml), XML (per i contenuti) e XSLT (per il layout) che permette facilmente ad un utente esperto di gestire speratamene il contenuto dal layout.

.Net Mobile

E’ la tecnologia sviluppata da Microsoft che permette tramite la sua interfaccia di sviluppo, di implementare siti mobili, esso si basa su un “transformation engine” proprietario che a seconda del dispositivo che accede espone il contenuto più apropriati.

Il framework net si comporta decentemente con quasi tutti i dispositivi (molto male , ovviamente si comporta in maniera egregia con i dispositivi mobili che utilizzano S.O. Microsoft.

Non ha una base dati con i dispositivi mobili e quindi come soluzione si può adottare il WURFL, che tra l’altro fornisce già dei moduli .NET per l’accesso al suo xml (wurfl.xml).

L’unico neo è che funziona solo su S.O. Microsoft.

Java

Questa tecnologia è ormai affermata a livello mondiale, ed ha come caratteristica di essere portabile su qualsiasi S.O.

Le applicazioni girano su degli application server ormai consolidati Tomcat, Bea, WebSphere, JRun.

L’approccio alla soluzione mobile sono differenti, vanno dati tag jsp proprietari (soluzione adottata per es. wall, mobileaware, volantis), renderizzazione dinamica di siti web (per es. infogin, cisco) alla soluzione XML, XSL (es. Cocoon, Oracle Mobile).

Device Detection

Un buon software mobile non può fare a meno di risolvere il problema della Device Detection.

La problematica della identificazione dei device è una delle tematiche chiave per poter dare il corretto contenuto per un determinato device, in altre parole voglio sapere questi informazioni:

• chi sei (Motorola,Nokia, iPhone, iPod)
• come sei fatto (dimensione dello schermo)
• che linguaggio parl (WML, XHTML, AJAX etc. etc.)
• che tipo di navigazione hai (tastiera, pennino, finger)

Ci sono diversi tool/API che aiutano a identificare i dispositivi mobili.

WURFL API (WURFL)

Fondamentalmente da prendere in considerazione quelle Java e quelle PHP. Ovviamente si basano su WURFL

Device Atlas API (DeviceAtlas)

Device Atlas è una società nata nel 2008 nella quale milita Andrea Trasatti (ex WURFL).

Detect Right

che ha un sistema di servizio remoto per l'identificazione dei dispositivi, in altre parole il DB è centralizzato e Detect Right fornisce le API per accedervi

Apache Mobile Filter

E' un mio progetto, e di fatto sta diventando un nuovo metodo per risolvere il problema della Device Detection, è un modulo per Apache che permette di risolvere l'identificazione dei device mobili restituendo come variabili d'ambiente le caratteristiche dei device. Il vantaggio di tale soluzione è che non ci sono vincoli tecnologici nella realizzazione di un sito mobile.

Tool per la mobilizzazione

Premessa

In questo capitolo verranno esposte le soluzione più presenti sul mercato del mobile e basate su tecnologia Java, in quanto è quella che offre obiettivamente i pacchetti software più avanzati.

WALL-NG (Wurfl)

Prodotto Opensource utilizza tag jsp per facilitare l’utilizzo nel gestire i vari layout a seconda dei device.

Utilizza un XML (wurfl.xml) con le caratteristiche dei device, alimentato da diversi utenti/operatori sparsi nel mondo.

MIS (Mobileaware)

Esso si basa su JSP servlet filter 1.2, che è il transformation engine. Il pacchetto può trasformare si pagine JSP (utilizzando i tag jsp proprietari), oppure i tag html, quindi possono rendere mobile pagine statiche, oppure tramite un modulo che chiamano MIS Proxy possono mobilizzare anche siti esterni i quali contengono i tag del MIS.

Per la parte di sviluppo fornisce dei tool di amministrazione dei dispositivi e di diagnostica.

E’ parte integrante di Bea Portal.

Il MIS è dotato di un proprio DB dei dispositivi mobili.

La sua particolarità è la semplicità e la facilita d'uso.

Volantis

Prodotto che utilizza oltre tag jsp proprietario, anche di un client per la gestione dei layout. Il tag proprietari “sezionano” la pagina in diversi blocchi che poi tramite il client Volantis dispongono graficamente sulla pagina mobile, in questa maniera si può avere un quadro visivo su come vengono erogati i contenuti secono i vari device.

Anche Volantis ha un proprio DB

Il prodotto è diventato dal 2008 Open Source, ma è il segno dei tempi e delle difficoltà che il prodotto ha avuto

Infogin

Prodotto che permette la renderizzazione automaticamente o attraverso una sua interfaccia manualmente, di un sito web ad un sito mobile adattando “on the fly” il contenuto.

E’ uno strumento consigliato per avere un ottimo time to market molto, come tutti gli strumenti di questo genere è sconsigliato utilizzarlo sui set il cui layout cambia continuamente, essendo un vincolo del prodotto.

Non ci sono documentazioni disponibili su internet