27 Giugno ’06

Sommario

Questo documento spiega quali sono le Pratiche Migliori da adottare per distribuire contenuti tramite dispositivi mobili. L'obbiettivo principale è di migliorare L'esperienza degli utenti che accedono al Web tramite i dispositivi mobili.

Le raccomandazioni si riferiscono soltanto al contenuto che viene inviato e non al processo col quale viene creato, non si riferiscono neanche hai vari dispositivi o agenti con i quali può essere distribuito.

Il documento è rivolto principalmente agli operatori, creatori e manutentori dei siti Web. Chi leggerà il documento dovrà conosce bene i processi di creazione dei siti web, e avere familiarità con le tecniche/tecnologie che riguardano queste operazioni, come ad esempio l'HTTP e i Server Web. Tuttavia non è necessario aver conoscenza delle tecniche specifiche per il mondo Mobile.

Condizione del documento

Questa parte del documento descrive a che stato si trova la realizzazione di questa pubblicazione. In altri documenti, questa parte, può non essere presente. Trovi una lista delle pubblicazioni del WC3 e le ultime revisioni su questa tecnica di pubblicazione nel resoconto tecnico del W3C a questo indirizzo http://www.w3.org/TR/ .

Il W3C ha pubblicato Candidate Reccomandation ad indicare che il documento si può considerare stabile e per incoraggiare l’implementazione da parte degli sviluppatori. Il gruppo Mobile Web Best Practices Working Group crede che il direttore porterà questo documento alla fare Proposed Reccomandation non appena:

Saranno forniti un numero sufficiente di Report per dimostrare che le Mobile Web Best Practices siano state implementate e interpretate nella maniera giusta. Per fare questo, il gruppo di lavoro dovrà valutare i contenuti web (siti, pagine) che sono stati creati usando queste linee guida. Per passare l’esame devono essere analizzate almeno due pagine per ogni Best Practices purché esse non siano a puro scopo dimostrativo.
è stato creato un Implementation Report per indicare i risultati dell’uso di ciascuna delle best practices considerate nei siti/pagine web.

Nessuna metodologia adottata è stata identificata come a rischio fino a questo punto, per cui il gruppo crede di poter passare a Proposed Reccomandation ma non prima del 27 Agosto 2006.

E’ disponibile un archivio pubblico di mailing list per spedire prove di implementazione sul documento disponibile nel template per i feedback. Per favore madate tutti i commenti su questo articolo alla mailing list del gruppo a questo indirizzo: pubblic-bpwg-comments@w3.org

La pubblicazione come Candidate Reccomandation non implica l’approvazione del documento da parte dei membri del W3C. Questo documento è una bozza e potrebbe essere aggiornato, rimpiazzato o reso obsoleto da altri documenti.

Inoltre il documento è parte di: Mobile Web Iniziative.

Questo documento è stato realizzato da un gruppo che opera sotto le regole del W3C Patent Policy 5 Febbraio 2004. Questo documento è puramente informativo. W3C mantiene una liste delle discussioni ufficiali realizzate sulla base degli sviluppi del gruppo. Chiunque sia a conoscenza di un brevetto su cui si possano avanzare delle pretese deve rendere nota l’informazione in accordo con la Section 6 del W3C Patente Policy.

1 - Introduzione

1.1 - Obbiettivo del documento

Questo documento dispone una serie di raccomandazioni create per migliorare l’esperienza di navigazione sui dispositivi mobili per il web.

Queste raccomandazioni sono rivolte agli operatori, creatori e manutentori di Siti Web e sono da intendersi come le norme basi per l’assegnazione del Trustmark (marchio di veridicità) “mobileOK”, che è descritto nel Mobile Web Best Practices Working Group Charter e non viene descritto in questo documento. Durante la stesura di questo documento il Trustmark mobileOK è in corso di definizione e le tecniche per implementare delle raccomandazioni Best Practices sono in corso di realizzazione

1.2 - Organizzazione del materiale

Il documento è organizzato come segue:

L’introduzione. Descrive il target, i propositi e lo scopo del documento.
Requisiti. Vengono illustrati i problemi che le Best Practices vogliono migliorare.
Recapito dei contenuti. Discussioni sull’ambiente nel quale l’accesso dei dispositivi è realizzato, con particolare riferimento agli adattamenti da adottare.
Panoramica delle Best Practices. Una discussione sull’organizzazione delle Best Practices e sulle fonti dalle quali son state ricavate.
Best Practices. La dichiarazione vero e propria.
Conformità col mobileOK. Un breve statuto di conformità e i riferimenti alla documentazione del mobileOK
Appendice, Sorgenti, Letture correlate, Riconoscimenti, Riferimenti

1.3 - A chi si rivolge

Chi leggerà il documento dovrà conosce bene i processi di creazione dei siti web, e avere familiarità con le tecniche/tecnologie che riguardano queste operazioni, come ad esempio l'HTTP e i Server Web. Tuttavia non è necessario aver conoscenza delle tecniche specifiche per il mondo Mobile.

Il nostro intento è far conoscere a tutte le persone coinvolte cosa sono le Best Practices e quindi stabile con loro una base comune di conoscenze. Quindi vorremmo rendere il documento chiaro a tutti e chi è già coinvolto nella realizzazione di contenuto per mobile, potrebbe trovare alcune definizioni ovvie o inutili.

Il documento non è rivolto soltanto agli sviluppatori, ma anche ad altri come ad esempio grafici e designer che sono incoraggiati a leggerlo.

1.4 - Scopo

Lo scopo delle Best Practices è descritto nel “Scope of Mobile Web Best Practices”. Nel sommario, questa parte si riferisce principalmente alle estensioni del Web Browsing nel dispositivi Mobile.

I consigli delle Best Practices si riferiscono ai contenuti che vengono inviati. E quindi sono rilevanti nel processo di creazione e visualizzazione dei contenuti sui diversi device.

Come da obbiettivi proposti, tutti ciò che non ha una specifica rilevanza nel campo del Mobile, non è incluso. In cùparticolare, molte linee guida sull’accessibilità valgono in generale per ogni forma di accesso al Web e quindi non vengono ripetute in questo documento a meno che non abbiano un’interpretazione specifica. Un esempio di norma generali che hanno una specifica applicazione nel mobile sono i “messaggi di errore” e il “colore”.

A questo proposito si consiglia di leggere le B Related Reading per informazioni sugli argomenti correlati all’Internazionalizzazione, all’accessibilità e all’indipendenza dei device

1.4.1 - Programmazione fase per fase

Si sono molti aspetti da analizzare. Ora, ad esempio, il design e la realizzazione di molti Web Site e pagine porta a esperienze deludenti se visualizzate su dispositivi mobili.

La qualità della visualizzazione via mobile dipende in modo significativo dall’usabilità del sito, dai browsers e naturalmente dal dispositivo stesso. D’altronde l’usabilità dei dispositivi e dei relativi browser è molto importante (per la lettura, la navigazione, e l’interattività), quindi questo documento pone l’attenzione principalmente sulle Best Practices (migliori pratiche) per ottimizzare l’usabilità.

In fasi future si potranno considerare altri aspetti ed estendere l’analisi al di là del tradizionale Web Browsing verso l’interazione multimodale.

1.5 - Relazioni con altre Best Practices e raccomandazioni

I consigli qui riportati son derivati in gran parte dalle Web Content Accessibilità Guidelines [WCAG].

Questo documento si fonda su alcuni concetti descritti dal Device Independence Working Group (DWIG) nel Device Independence Principles [DIP]. Il BPWG stà invece sviluppando un documento che descrive delle tecniche con le quali le Best Practice di questo documento possano essere implementate.

1.6 - Longevità e versioni

Le Best Practices son state scritte ad un livello così generale che permette di applicarle ad un range molto ampio di linguaggi di Markup. Son state scritte con l’intento di farle durare nel tempo. Infatti, mentre fattori come le dimensioni dello schermo cambieranno nel tempo, sembra che altre come il costo e le difficoltà di imput rimarranno. Il documento sarà comunque rivisitato e quando necessario, sarà rilasciata una versione aggiornata con la relativa documentazione sui cambiamenti introdotti.

2 - Requisiti

Questa sezione, parla dei requisiti dei requisiti del Mobile Web Best Practices nella sezione 5.
Quanto viene riportato è più illustrativo che esaustivo o completo.

2.1 - Preparazione per la pubblicazione

Oggi, molte pagine sono progettate per essere visualizzato su display ampi, come quelli dei computer desktop e per sfruttare le capacità dei software di Browsing dei PC.
Accedere a pagine del genere con un dispositivo mobile, spesso diventa difficile, a volte inutile. Purtroppo molto del contenuto delle pagine và perso, un po’ per le dimensioni ridotte dei display, un po’ perché il dispositivo non riesce a elaborare tutto il materiale.
Spesso visualizzare il soggetto principale del sito richiede un bel po’ di scrollino, specialmente se la parte alta della pagina è occupata da immagini e menu di navigazione.
È molto importante nei contenuti mobile, aiutare l’utente a creare un’immagine mentale del sito. Questo può essere facilitato creando uno stile consistente, ma può essere reso difficoltoso utilizzando uno stile irregolare.

2.2 - Input

L’input in questi dispositivi è spesso difficoltoso specialmente se comparato ai device desktop che hanno la tastiera. Spesso i device mobili, hanno un piccolo blocco di tasti, che sono spesso di dimensioni ridotte e spesso non c’è neanche un dispositivo di puntamento come il mouse.

Un’altra difficoltà è che gli URL son molto difficili da digitare. Specialmente se sono molto lunghi e contengono caratteri strani.

Allo stesso modo i form son difficili da compilare. Spesso questo è dovuto alle difficoltà di digitazione ma anche allo scorrimento da un campo all’altro che non sempre segue l’ordine che ci si aspetta.

Molti dispositivi hanno un pulsante per tornare alla pagina precedente, ma altri no e in molti casi, quando questa funzionalità esiste, gli utenti potrebbero non saper come usarla. Questo significa che spesso è molto difficile rimediare ad errori di navigazione o uscire da una pagina inesistente.

2.3 - Banda e costo

I collegamenti mobili possono sembrare lenti se comparati a quelli dei computer fissi e spesso hanno una latenza molto superiore. Questo porta a lunghi tempi di recupero delle informazioni, specialmente per contenuti molto lunghi e per quelli che richiedono di passare velocemente da una pagina all’altra.

Il trasferimento di dati, spesso è costoso. A volte questi dispositivi supportano soltanto alcuni formati di file e l’utente potrebbe cliccare su links che gli faranno scaricare files inutilizzabili sul suo dispositivo.

E poi anche se il file può essere interpretato dal dispositivo e aperto, esso potrebbe comunque non essere adatto, Ad esempio immagini molto grandi possono essere visto soltanto un pezzetto alla volta e questo richiede l’uso dello scrollino.

Le pagine potrebbero contenere delle cose che l’utente non ha specificatamente richiesto, come ad esempio pubblicità ed altro. Questo materiale nel mondo mobile può limitare tantissimo l’usabilità e amplificare il costo della navigazione.

2.4 - Gli obbiettivi dell'utente

Gli utenti di dispositivi mobili hanno di solito interessi molto diversi dagli utenti dei computer fissi. Vogliono delle interazioni più immediate e dirette verso l’obbiettivo. Le loro intenzioni sono spesso di trovare una parte specifica di informazione the è rilevante nel loro contesto. Un esempio possono essere gli utenti che hanno bisogno di un’informazione specifica sull’itinerario di un viaggio che stanno facendo.

L’ergonomia stessa dei dispositivi spesso rende difficile la navigazione di contenuti molto lunghi e spesso gli accederanno a queste informazioni con un dispositivo mobile soltanto come ultima risorsa, giusto perché non c’è a disposizione un accesso più conveniente.

2.5 - Pubblicità

Gli sviluppatori di siti commerciali dovrebbero notare che quando gli utenti accedono al sito tramite un dispositivo mobile entrano in gioco modelli di commercio completamente diversi se comparati con quelli degli utenti fissi. Per esempio, alcuni meccanismi che son comunemente usati per presentare materiale pubblicitario per i computer fissi non funzionano per i piccoli device e perciò son contrari alle Best Practices Reccomandation.

Non è intenzione del MWI limitare o restringere i metodi pubblicitari, ma piuttosto che l’intera esperienze del web, inclusa la pubblicità, sia il più efficace possibile.

2.6 - Limiti dei device

Come detto sopra, le restrizioni imposte dall’assenza di una tastiera completa e dagli schermi ridotti chiedono un approccio un po’ diverso per la realizzazione delle pagine. Queste limitazioni hanno un forte impatto sull’usabilità.

Spesso i browser dei dispositivi mobili non supportano lo scripting o i pugh-in, questo significa che la gamma dei contenuti che possono supportare è abbastanza limitata. Spesso gli utenti non possono proprio navigare e non possono neanche aggiornare il loro software.

Alcune attività per il rendering delle pagine web hanno bisogno di un intenso lavoro computazionale (della CPU) ( per esempio, l’uso di tabelle per il layout, l’elaborazione di lunghi e ridondanti fogli di style magari con markup non valido)[T-MOB]. I dispositivi mobili hanno un di solito un potere di elaborazione limitato che allunga i tempi per il rendering. E porta ad un ritardo notevole, specialmente se l’elaborazione richiede più tempo che non lo scaricamento dal server.

Altri dispositivi hanno una memoria limitata, e superare la loro memoria può portare ad una visualizzazione incompleta o ad altri problemi.

2.7 - I vantaggi

Discutere sulle limitazioni di questi dispositivi fa facilmente perdere di vista il fatto che sono estremamente popolari e molto comuni.

La loro popolarità, attualmente, li porta ad essere:

Personali
Personalizzabili
Portatili
Connessi
Incredibilmente multi-funzionali se si prescinde il loro intento comunicativo

In aggiunta a questi fattori, i vantaggi dei dispositivi mobili sono anche:

Consapevolezza della loro posizione
Si possono usare con una sola mano
Restano sempre accesi
Son sistemi universali per gli avvisi

Senza contare questi altri fattori: Il web può seguirti ovunque tu sia. Non hai bisogno di ricordarti di vedere una cosa sul web quando tornerai a casa. Puoi farlo subito, all’interno del contesto che ti ha spinto a cercare una certa informazione nel web.

Inoltre, Con il fatto che questi dispositivi ormai hanno l’aspetto e le forme più disparate, che implementano le più svariate tecnologie, come il GPS, telecamere, riconoscimento vocale, touch screen ecc. Il web può raggiungere un sempre maggiore audience, a in ogni momento per ogni situazione. Può seguirci in posti dove i cavi non possono arrivare, posti che una volta erano impensabili, e accompagnare chiunque, in modo facile come portare l’orologio e la propria valigetta.

Infine, oggi, molte persone utilizzano i dispositivi mobili in sostituzione dei desktop. Questo è molto significativo, specialmente nelle nazioni che si stanno sviluppando, dove i dispositivi mobili che si possono connettere al web potrebbero prendere il ruolo che hanno avuto per noi i telefonini nel passaggio dal vecchio servizio telefonico al GSM.

3 - Distibuzione di contenuti

Distribuire contenuti è inteso con lo stesso senso e significato definito nel Device Independence Glossary[DIGLOSS].

3.1 - Web unico

Come detto nello scopo del documento [SCOPO], Web Unico, significa, rendere disponibili le stesse informazioni e servizi a tutti gli utenti indipendentemente dal dispositivo che stanno usando, finché questo è ragionevole. Comunque, non significa che la stessa informazione è disponibile con la stessa rappresentazione su tutti i device.Molte cose hanno effetto sulla rappresentazione dei contenuti: Il contesto stesso in cui usiamo il dispositico mobile, le diverse capacità di banda e di visualizzazione. Inoltre alcune informazioni si adattano meglio ad un certo target di utenti o per essere usate in certi contesti (vedi 5.1.1 Thematic Consistency of Resource Identified by a URL)

Alcuni servizi hanno forti riscontri soltanto nel mobile(il GPS, per esempio). Invece alcune applicazioni per il web hanno il loro fascino soltanto in ambiente Desktop (lunghe guide e siti ricchi di immagini, per esempio).

La cosa migliore sarebbe che i designer e i service provider fornissero l’esperienza migliore nel contesto nel quale i solo servizi hanno la massima attrattiva. Comunque, dato che certi servizi possono essere sperimentati in qualunque contesto, è ragionevole e sarebbe una buona pratica fornire la migliore esperienza possibile con ogni dispositivo, senza escluderne una classe, tranne per i device più limitanti.

Nella prospettiva di questo documento questo significa che i servizi dovrebbero essere disponibili con la stessa struttura HTML per tutti i dispositivi che utilizzano il protocollo HTTP.

3.2 - Parola d’ordine adattamento

Le numerose e differenti caratteristiche dei dispositivi mobili, può rendere difficile per un sito fornire la stessa esperienza visiva su una larga gamme di dispositivi. Ad esempio dispositivi diversi supportano diverse caratteristiche di markup, inoltre diverse dimensioni del display richiedono immagini di grandezza diversa. Quindi è abbastanza comune dover cambiare il formato, le dimensioni, la profondità di colore e tante altre caratteristiche delle immagini in modo che si adattino alle caratteristiche del dispositivo in questione. Questo processo di alterazione per migliorare l’esperienza utente su un particolare dispositivo si chiama Content Adaptation (adattamento del contenuto).

In questo documento non sara descritto il processo di adattamento in dettaglio. Per una descrizione più dettagliata si rimanda al Device Independence Principles [DIP].

In aggiunta, il nostro gruppo fratello , il Device Description Working Group, stà definendo i requisiti per tutta un ricettacolo di dispositivi mobili che sono rilevanto per l’adattamento dei contenuti.

3.3 - Implementazione del modello

Ci sono tanto modi per implementare l’adattamento dei contenuti. Da un lato, l’adattamento può essere abbastanza semplice e consistere nel determinare il tipo di device e scegliere il più appropriato set di contenuti che vada bele per le caratteristiche di quel dispositivo. Dall’altro canto questo si può realizzare in maniera completamente dinamica, con il contenuto che viene formattato al momento del downlaod, tenendo conto non soltanto delle proprietà statiche, come la dimensione delle schermo, ma anche delle proprietà dinamiche, come per esempio la possibilità di utilizzare temporaneamente una tastiera completa, attaccata al dispositivo.

L’adattamento lato server, implica che il contenuto sia fruito dal server che origina i contenuti.

L’adattamento In-Network è quello in cui il contenuto è modificato dopo esser passato attraverso uno o più componenti network. Alcuni operatori, per esempio, comprimono le immagini prima di passarle nell’aria hai dispositivi mobili.

L’adattamente Lato Client consiste nell’accettazione del contenuto da parte del dispositivo e la visualizzazione nel modo più appropriato per le sue caratteristiche.

In qualunque modo esso lavori, il processo di adattamento non dovrebbe mai diminuire l’accessibilità.

3.4 - Premesse sull’adattamento

Nella prima fase (vedi 1.4.1 Programmazione fase per fase) si dà per assunto che l’adattamento dei contenuti, se fatto, sia lato server. In fasi future si può considerare l’applicazione dell’adattamente in un altro modo. Fasi successive possono anche indirizzare verso adattamenti multipli, cioè la possibilità di applicare l’adattamento in più modi simultaneamente o più di una volta.

Si dà anche per assunto che sia possibile creare un sito che vada bene per le specifiche Best Practice senza fare alcun tipo di adattamento. E’ chiaro che se usato, l’adattamento porta da una più sofisticata e abbellita esperienza utente.

3.5 - Stabilire il contenuto

Fornire variazioni sull’esperienza sull’esperienza degli utenti che siano appropriate nei diversi casi significa che il provider debba conoscere un bel po’ di cose sulle caratteristiche del dispositivo, le proprietà del browser in uso e la visualizzazione della connessione da parte del device.

Ci sono molti modi con i quali un provider può scoprire informazioni sul contenuto che deve fornire, come ad esempio CC/PP, UAPROF, CSS Media Queries e vari output del Device Independence Working Group. Un documento tecnico descrive i metodi da adottare.

3.6 - La scelta dell'utente

Nel contesto di un Web Unico, il provider può scegliere di permettere agli utenti di selezionare uan visualizzazione per Mobile o per Desktop. Se invece il tipo di visualizzazione è determinata automaticamente, il provider può scegliere di permettere all’utente di ignorare la scelta automatica per una manuale. Quando l’utente avrà fatto la sua scelta, sarebbe meglio registrare questa preferenza e permettergli di modificarla in futuro.

Per permettere hai provider di condividere lo stesso sistema di visualizzazione dell’esperienza mobile il BPWG ha definito il Default Delivery Context. Esso permette hai provider di fornire un’esperienza appropriata anche in assenza di adattamento e fornendo una visualizzazione di base quando l’adattamento c’è. I dispositivi che non si adattano a queste specifiche possono fornire un’appropriata visualizzazione soltanto di altri servizi che non siano basati sul WEB.

3.7 - Modello di dispositivo

Dato che i dispositivi mobili sono così diversi tra loro, il Best Practices Working group ha definito un modello (Default Delivery Context).

Se il contenuto che viene inviato non è soggetto ad alcun adattamento (il contenuto è staticamente definito da files HTML, allora il contenuto dovrebbe essere appropriato per il Default Delivery Context e dovrebbe conformarsi alle Best Practices).

Se è usato un adattamento, le informazioni conosciute sul contenuto dovrebbero essere variate per renderlo più appropriato e fornire un’esperienza utente superiore.

Il Default Delivery Context è il seguente:

Larghezza dello schermo: 120 Pixel, minimo.
Linguaggio di markup supportato: XHTML – Basic Profile [XHTML-Basic]
Character encoding: UTF-8 [UTF-8]
Formato immagine supportato: JPEG - GIF 89° (non-interlaced, non-trasparent, non-animated).
Maximum Total Page Weight: 20 kilobytes
Colors: Web Safe. (Componenti Rosso/verde/blue che possono scegliere tra:0,52,102,153,204,255)
Supporto hai fogli di stile (CSS): External CSS Level 1 [CSS]
HTTP: HTTP/1.0 o il più recende HTTP/1.1

4 - Struttura del resocondo Best Practice

Qui ha inizio il nucleo centrale del documento.
Questa perte è in corso di traduzione

My Digital WorkFlow - Home