Mobile Web Best Practices 1.0

Le Mobile Web Best Practices (MWBP) sono un insieme di raccomandazioni fornite dal W3C per la costruzione di siti web adatti al web mobile, non solo dal punto di vista tecnico ma anche sotto il profilo dell'esperienza d'uso. In questo articolo presenteremo le principali caratteristiche di tali linee guida, ormai in dirittura d'arrivo per quanto concerne la loro pubblicazione ufficiale.

Il gruppo di lavoro W3C dedicato allo sviluppo e alla definizione di buone pratiche per il Web fruibile tramite dispositivi mobili (la Mobile Web Initiative) ha avuto come primo obiettivo la redazione di una raccolta di raccomandazioni indirizzata a tutti quei soggetti coinvolti nel processo di ideazione, realizzazione e pubblicazione di un sito mobile. Dopo una serie di premesse, che affronteremo nella prima parte del nostro articolo, le linee guida prendono in considerazione aspetti quali la gestione della navigazione, la struttura della pagina, il trattamento del dialogo tra l'applicazione e l'utente nonché alcune dimensioni più strettamente tecniche legate alla trasmissione dell'informazione verso i dispositivi mobili. L'aderenza alle linee guida diverrà il punto di partenza fondamentale per adottare il marchio mobileOK, una sorta di auto-certificazione che i gli autori dei siti web potranno applicare in caso di conformità (analogamente a quanto accade per l'accessibilità). I requisiti e le modalità di acquisizione di tal marchio, anche se in via di definizione, saranno basati sulle MWBP ed è in fase di sviluppo un validatore (http://validator.w3.org/mobile/) che permetterà di esaminare automaticamente l'aderenza delle pagine alle linee guida (se non altro relativamente alle dimensioni formali).

La prima parte del documento illustra una serie di premesse necessarie al lavoro di definizione delle linee guida, un'operazione necessaria per porre in contesto e comprendere la portata delle linee guida.

L'intenzione dichiarata è di fare delle MWBP uno strumento longevo e utile rispetto allo stato attuale e futuro del mobile web. Se, da un lato, alcune caratteristiche tecniche di questo ambito potranno cambiare ed evolversi (ad esempio le dimensioni degli schermi di consultazione potrebbero aumentare o avere maggiori performance), dall'altro si assume che alcune problematiche, come per esempio l'input di dati, resteranno costanti nel tempo. Le Best Practices, pertanto, vanno considerate un documento che può essere soggetto ad aggiornamenti senza perdersi - ora - in speculazioni circa quello che sta per accadere o che potrebbe verificarsi in futuro in questo ambito. Rispetto alle prime bozze del documento, si segnala quindi l'intenzione del MWI di acquisire un maggior livello di astrazione, meno legato all'hic et nunc della comunicazione wireless.

La parte introduttiva prosegue con l'indicazione di uno spettro di questioni che le MWBP debbono tenere in considerazione e che esse stesse dovrebbero permettere di soddisfare: una presentazione dell'informazione gradevole e funzionale, la semplificazione delle procedure di input, l'efficienza dal punto di vista della larghezza di banda e dei costi di trasmissione, la soddisfazione degli obiettivi dell'utente, garantire la presenza di annunci commerciali (a volte inopportuni ma spesso necessari per la sopravvivenza dei contenuti stessi!), il confronto con le limitazioni dei dispositivi e, last but non least, i vantaggi che un web portatile può garantire.

Le Best Practices per il Mobile non vanno intese, secondo il gruppo MWI, come istruzioni per realizzare solo siti esclusivamente per il mobile web. L'obiettivo da perseguire è identificato dall'espressione "One Web": in altri termini è necessario pensare a repertori informativi unici che si adattino di volta in volta ai contesti di distribuzione e di fruizione. Le MWBP, pertanto, illustrano rapidamente i concetti chiave delle procedure di adattamento, per altro approfondite da HTML.it in un apposito articolo. L'adattamento può avvenire sia in forma automatica (ad esempio mediante i profili CC/PP) oppure lasciando all'utente l'opportunità di scegliere a quale versione dell'informazione accedere.

In assenza di meccanismi di adattamento e data l'estrema variabilità di dispositivi e browser esistenti, il MWI ha fissato le caratteristiche di un device di base che dovrebbe fungere da termine di paragone per le attuali applicazioni mobili. Il profilo è costruito in funzione dei dispositivi attualmente prevalenti sul mercato e consta di:

• uno schermo largo al miinmo 120 pixel;
• supporto per XHTML basic profile (servito in modalità application/xhtml+xml);
• capacità di rappresentare immagini JPEG e GIF 89a (ossia non interfacciate, non trasparenti e non animate);
• capacità di gestire pagine di peso fino a 20Kbytes;
• rappresentazione di un minimo di 256 colori;
• supporto per i CSS 1 e, in aggiunta, la regola @media con i valori "handheld" e "all" propria dei CSS 2;
• nessun supporto per linguaggi di scripting lato client;

Le caratteristiche appena elencate si collocano chiaramente ad un livello medio-basso rispetto agli ultimi devices in commercio ma questa scelta è motivata da due aspetti. In primo luogo si preferisce portare l'attenzione degli sviluppatori su un piano più universale e accessibile (non a caso le raccomandazioni si pongono in relazione diretta con le WGAG) e, secondariamente, si intende proporre la descrizione precisa un modello di riferimento base da incorporare in ogni sistema di adattamento che dovrebbe fungere da default qualora l'adattamento stesso fallisca o non sia attuabile.

Come conseguenza di simile scelta, pertanto, viene escluso un insieme di caratteristiche che, sebbene ormai diffuse, potrebbero limitare le opportunità di accesso: per esempio non vengono presi in considerazione i linguaggi di scripting lato client, i contenuti mediati da plug-in (primi fra tutti le animazioni Flash e i documenti PDF) e i file audio e video. Ciò non significa che il W3C ignori queste tecnologie, ma semplicemente che preferisce privilegiare un profilo di accesso medio-basso e che demanderà a successive pubblicazioni la valutazione di applicazioni e contenuti più ricchi. HTML.it si è già occupata di questi aspetti nella guida alla realizzazione di siti web per dispositivi mobili.

La parte introduttiva del documento introduce, sebbene in forma piuttosto timida e limitata, la preoccupazione di costruire un modello di utente che, analogamente alle caratteristiche tecniche del device appena descritto, assolva il compito di chiarire in chiave generalizzata quali siano i comportamenti e le esigenze degli utilizzatori del mobile web. Se l'obiettivo delle linee guida è - fondamentalmente - il miglioramento dell'esperienza d'uso, allora non è possibile prescindere dall'acquisizione di maggiori conoscenze circa i destinatari.

Rispetto agli utilizzatori del web attraverso personal computer, questa classe di utenti possiede interessi differenti: ha necessità più immediate e guidate da precisi obiettivi, spesso connesse al contesto in cui il navigatore si trova. Cercare in breve tempo informazioni precise e pertinenti sembra essere quindi il comportamento più diffuso nel mobile web. In secondo luogo si annotano usi del mobile web a scopi meno finalizzati all'efficienza, come la ricerca di intrattenimento per colmare attese e tempi morti (per esempio un trasferimento su un mezzo pubblico).

Gli utenti del mobile web si contraddistinguono anche per una differente condizione di connettività: l'accesso wireless è spesso più lento e inaffidabile di una connessione via cavo. Vanno inoltre presi in esame gli aspetti più strettamente ergonomici: è più complesso interagire con un dispositivo mobile sia in fase di input sia dal punto di vista della leggibilità, dal momento che gli schermi sono spesso piccoli e a bassa risoluzione.

È interessante annotare che in questa occasione l'attenzione del W3C si concentra non tanto su questioni di ordine tecnico o architetturale, bensì sull'usabilità di questo genere di prodotti: la presenza di una dimensione più vicina alle esigenze operative e informative degli utenti è – a nostro avviso - un tratto molto positivo, che del resto si nota anche in altri gruppi di lavoro (come il WAI) e che va considerato prioritario se si desidera l'esplosione definitiva di simili tecnologie. Una simile prospettiva è andata tuttavia limitandosi nel corso delle successive rielaborazioni del documento, divenendo forse meno esplicita. In questo momento le MWBP mancano di una documentazione efficace circa il modo in cui sono state acquisite determinate conoscenze sugli utenti, rimandando l'approfondimento di tali argomenti a lavori precedentemente redatti da altri soggetti: se è di certo vero che lo scopo della documentazione W3C non coincide con la divulgazione scientifica, consigliamo di leggere la raccomandazioni in modo critico, cercando di trasferire le raccomandazioni di carattere generale al contesto di applicazione specifico con cui deve confrontarsi ogni singolo progettista/sviluppatore.

Concluse le necessarie premesse, il documento inizia quindi a definire le proprie indicazioni.

Le Best Practices sono ragguppate tematicamente in cinque sezioni:

1. comportamento generale;
2. navigazione e link;
3. layout e impaginazione dei contenuti;
4. definizione degli elementi delle pagina;
5. input degli utenti.

Il primo gruppo di linee guida concerne le problematiche a carattere più generale relative alla trasmissione di contenuti attraverso il mobile web. Queste raccomandazioni non erano presenti nei documenti preliminari ma sono stati aggiunti solo nelle ultime versioni in concomitanza con l'introduzione del concetto di One Web, a cui esse si indirizzano.

Innanzitutto, questa prima sezione invita gli sviluppatori ad assicurarsi che il contenuto fornito da un URI assicuri un'esperienza tematicamente coerente qualora sia fruito da diversi dispositivi, indipendentemente dalle capacità di questi. Ciò non significa solamente garantire la presenza delle medesime informazioni ma anche consentire all'utente di recuperare lo stato del sistema ottenuto su un altro device. Per esempio, se il sito possiede un'area riservata e personalizzata, l'utente dovrebbe potervi accedere anche se sta utilizzando un telefono cellulare.

Gli sviluppatori dovrebbero poi sfruttare le capacità dei dispositivi per generare esperienze d'uso avanzate: l'esistenza di un device di base non va infatti intesa come un freno agli autori di contenuti e servizi. Dopo essersi assicurati circa la fruibilità del proprio sito su un profilo base è possibile infatti utilizzare le capacità specifiche di una determinata classe di dispositivi per fornire una migliore esperienza di navigazione: per esempio si potrebbe cercare di avvantaggiarsi delle capacità di small screen rendering messe a disposizione dal browser Opera.

Il terzo aspetto su cui si chiede di porre attenzione è il modo di affrontare le carenze dei software di navigazione. Come è esperienza di molti web designer, i browser web spesso possiedono bug ed errate implementazioni delle specifiche tecniche. Il caso della rappresentazione dei fogli di stile su alcuni software di navigazione (Internet Explorer 5 per Windows, per esempio) ha creato non pochi grattacapi a tutti coloro che si sono cimentati nell'utilizzo di questa tecnologia. Le MBWP mettono in guardia gli autori di siti mobili: dobbiamo aspettarci un'analoga situazione anche per i sistemi portatili, aggravata dal fatto che il software - a differenza delle piattaforme desktop - è molto più difficile da aggiornare e correggere. Le linee guida, in questo frangente, autorizzano gli sviluppatori ad attuare work around che, anche se in contrasto con le Best Practices, possono risultare necessari per raggiungere quei browser con difetti di implementazione: un atteggiamento che è però accettato solo in forma transitoria e non accettato qualora i browser abbiano un comportamento corretto.

Il primo gruppo di raccomandazioni si conclude con l'invito ad effettuare test su dispositivi reali e su emulatori. In virtù dell'estrema variabilità di configurazioni hardware e software attualmente disponibili sul mercato è importante valutare la resa delle proprie pagine su una gamma più ampia possibile di terminali. Qualora non fosse possibile accedere alle apparecchiature fisiche è bene ricorrere a sistemi di emulazione. In un articolo pubblicato da HTML.it abbiamo esaminato l'emulazione dei sistemi pocket PC.

Il secondo gruppo di raccomandazioni ha per argomento la navigazione e il trattamento dei link, temi che non vanno sottovalutati quando la logica di interazione tra utente e sistema è limitata dalle configurazioni input e output del device. Nelle MWBP si osserva giustamente che a causa delle limitate capacità del display mobile e dei meccanismi di input, della possibile assenza di un dispositivo di puntamento e altre possibili limitazioni, bisogna porre una particolare attenzione alla definizione della struttura e al modello di navigazione di un sito pensato per il mobile Web. Come vedremo, le raccomandazioni a questo riguardo sono in alcuni casi molto specifiche e precipue del mezzo, mentre in altri riprendono molto da vicino le WCAG, le linee guida sull'accessibilità del W3C e i principi generali di usabilità del desktop Web.

La prima raccomandazione a riguardo osserva che gli URI (ossia gli indirizzi delle pagine web) del sito devono essere corti, dal momento che la loro digitazione su un dispositivo mobile può risultare un'attività difficoltosa. Anche se ci possono essere metodi alternativi per raggiungerli come seguire direttamente su un link presente su un'altra pagina Web (in una e-mail, in un sms) oppure essere rinviati ad un sito da un codice a barre, da una etichetta RFID o via Bluethooth, è importanti mantenere i nomi degli URI il più brevi possibile riduce le possibilità di errore e aumenta la soddisfazione degli utenti. Inoltre, sempre secondo questa raccomandazione, sarebbe meglio configurare il server Web che ospita il sito affinché sia possibile digitare il nome del dominio, o del sotto-dominio, senza dover specificare anche il nome del file che si riferisce alla pagina stessa (quindi http://www.esempio.org/ invece di http://www.esempio.org/index.html, e http://www.esempio.org/esempio invece di http://www.esempio.org/esempio.html).

Ove possibile - aggiungiamo personalmente - è consigliabile registrare un nome di dominio più corto e utilizzarlo come alias per la versione mobile. Per esempio il sito WordReference utilizza il dominio "wordreference.com" per il desktop Web, mentre per la versione mobile rimanda al più immediato "wrmob.com".

Il secondo punto di questo gruppo invita i progettisti a fornire solo una navigazione minimale ad inizio pagina. Una volta avuto accesso al sito, infatti, il visitatore dovrebbe poter visionare immediatamente il contenuto della pagina senza dover effettuare dello scrolling: pertanto è opportuno ridurre al minimo gli elementi decorativi e funzionali che potrebbero occupare più o meno inutilmente spazio sulla limitata superficie delle schermo. Se necessaria, una navigazione secondaria può essere posta a fondo pagina. Come sarà poi illustrato da una successiva linea guida, è importante che tutto ciò che ha un ruolo centrale nella definizione del significato della pagina abbia la precedenza su quanto ha un ruolo secondario.

Riflettendo su questa raccomandazione è evidente che siamo distanti dai requisiti relativi alla navigazione globale pensati per il desktop Web. Secondo i principi dell'Information Architecture dovrebbero questa dovrebbe sempre essere presente in tutte le pagine, ma difficilmente su una pagina per il Web mobile si riuscirà a condensare tutta la navigazione globale (ovvero quella per accedere alle sezioni principali). Una soluzione plausibile - suggeriamo - potrebbe essere quella di lasciare in alto un richiamo alla homepage, presente in tutte le pagine, e delle briciole di pane per orientare l'utente e fargli capire dove si trova. La homepage a sua volta potrebbe presentare la lista delle voci di navigazione globale, le quali a loro volta potrebbero portare alle voci locali e queste ultime alle pagine finali. Ad esempio il sito Torino Espresso utilizza proprio questo approccio alla navigazione.

La terza raccomandazione di questa sezione invita a cercare di bilanciare la presenza di molti link su una stessa pagina con il fatto di chiedere all'utente di seguire troppi link per raggiungere quello che sta cercando. La progettazione deve avere per obiettivo un bilanciamento tra l'avere molti link di navigazione su una sola pagina e il fatto di dover navigare tra molti link (sparsi tra più pagine) per raggiungere il contenuto desiderato. Quindi sostanzialmente si deve cercare un bilanciamento tra profondità e ampiezza della struttura gerarchica del sito. La raccomandazione chiede di progettare servizi tali per cui l'informazione che si ricerca più frequentemente sia raggiungibile attraversando il minor numero possibile di pagine anche se questo può significare l'allontanamento di altre informazioni dalla pagina iniziale. Secondo il MWI un utente preferirebbe non dover seguire più di quattro link per raggiungere il proprio obiettivo. Risulta palese che le modalità mediante le quali è possibile soddisfare questa linea guida sono funzione del contenuto e degli obiettivi del sito web.

Per un miglioramento dell'esperienza di navigazione si potrebbe pertanto adottare alcune strategie invalse nel campo della progettazione di siti web:

• valutare, attraverso un attenta analisi del file di log, quali sono i servizi più utilizzati dagli utenti della versione mobile, e porli in primo piano;
• valutare, sempre attraverso i log, quali sono i pattern di maggiore utilizzo, e ri-progettare la navigazione in tale ottica;
• progettare molto attentamente l'architettura di navigazione del sito ponendo molta attenzione alla comprensibilità delle categorie semantiche in cui i link sono raggruppati, in modo tale da favorirne il reperimento. A tal fine possono risultare utili sessioni di card sorting.

È bene sottolineare, tuttavia, che il comportamento degli utenti e il contesto d'uso mobile impongono necessità e bisogni assai differenti dall'esperienza desktop. Quindi i tre punti appena elencanti vanno calati assolutamente in tale prospettiva. Dal risultato di queste analisi potrebbe emergere l'esigenza di dotare il servizio mobile di un'architettura dell'informazione diversa da quella desktop: nell'ottica di uno One Web è importante quindi istruire i meccanismi di adattamento in modo tale che la navigazione sia differente in funzione del dispositivo di accesso. Il richiamo al device di base come default, tuttavia, imporrebbe che la stessa architettura del sito desktop sia improntata ad una semplicità d'uso anche quando fruita tramite un device portatile (senza adattamento).

Le successive raccomandazioni contenute nel secondo gruppo si richiamano a principi più generali di accessibilità e usabilità degli strumenti di navigazione. Innainzitutto la terza linea guida chiede che di fornire consistenti meccanismi di navigazione, ovvero utilizzare le stesse modalità di navigazione in tutte le pagine per aiutare gli utenti a orientarsi e consentire loro di identificare i meccanismi di navigazione più facilmente. Il W3C promuove una forma di raggruppamento intelligente attraverso il metodo drill-down che consiste nell'organizzare l'informazione secondo uno schema gerarchico (come titoli o raggruppamenti significativi) e fornire quindi un menu di accesso alle singole sezioni (con un link "torna su" per tornare all'inizio della sezione o della pagina).

La quinta raccomandazione richiama da vicino le WCAG e chiede di assegnare le access keys ai link dei menu di navigazione e alle funzionalità utilizzate più di frequente. Le scorciatoie da tastiera risultano particolarmente utili sui dispositivi mobili soprattutto quando non c'è un dispositivo per il puntamento. Con una pressione sul tasto corrispondente al link l'utente riesce a navigare utilizzando la tastiera evitando l'uso dei tasti direzionali per muoversi, circostanza che può non sempre essere intuitiva ed efficace.

Successivamente le MWBP ribadiscono di identificare chiaramente il target di ciascun link e indicare il formato del file a cui il link porta, a meno che si sia sicuri che il dispositivo lo supporta. Gli utenti di device mobili possono avere problemi di lunghi tempi di attesa e costi eccessivi dovuti al fatto di dover seguire molti link e di conseguenza navigare tra tante pagine. Come nel desktop Web, nel mobile Web forse è ancora più importante poter sapere in anticipo dove un link porta in modo tale da poter valutare se si è interessati a seguire il link o meno. Di conseguenza, da un lato è importante dare nomi significativi ai link e/o specificare la destinazione del link nell'attributo title e, dall'altro, se il link porta ad un file di grandi dimensioni e di formato inatteso (non HTML), è bene avvertire l'utente dando un'idea della dimensione della risorsa. L'accesso a file di grandi dimensioni o di formato non direttamente interpretabile dal browser dovrebbe essere possibile e lasciata alla scelta libera dell'utente, il quale potrebbe comunque voler scaricare una determinata risorsa per esaminarla tramite un'altro programma installato sul device oppure per averla a disposizione in vista di un prossimo trasferimento su una piattaforma più performante.

Il gruppo di raccomandazioni dedicato alle problematiche di navigazione prosegue con altre due raccomandazioni che affrontano modalità opzionali e alternative di navigazione, che a nostro avviso andrebbero, se non del tutto evitate, almeno utilizzate con molta cautela. In particolare si chiede di:

• non usare le immagini mappate a meno che non si sappia che il client è davvero in grado di supportarle: le immagini mappate non sono supportate da molti client ed inoltre possono causare difficoltà di interazione per coloro che non hanno a disposizione dispositivi di puntamento efficaci; se proprio si desidera utilizzare le image map sarebbe opportuno trattarle come forme geometriche (più facilmente navigabili con i tasti direzionali, presenti invece su moltissimi dispositivi mobili), oppure dividere un'immagine grande in tante piccole immagini e trattarle separatamente;
• Evitare di aprire delle finestre di pop-up o altre finestre che cambiano la finestra corrente senza avvertire l'utente, evitare il refresh automatico delle pagine a meno che l'utente ne sia informato e abbia un modo per fermare il refresh, e non utilizzare mark up che applicano un reindirizzamento automatico delle pagine (è meglio configurare il server affinché effettui il redirect attraverso codici HTTP 3xx);

Pop-up, refresh e reindirizzamenti sono attività che possono generare confusione nell'utente, aumentano i costi di connessione (per esempio effettuando download non richiesti di pagine) e ritardano complessivamente l'interazione. Va inoltre annotato che molti device mobili non riescono a supportare più di una finestra alla volta, pertanto sarebbe semplicemente inutile tentare di aprire una nuova finestra rispetto a quella corrente. Le pagine con l'auto-refresh presentano in generale già dei problemi di accessibilità e di usabilità, come il disorientamento dell'utente. In ambito mobile possono esporre l'utente a costi non previsti dovuti al fatto che queste pagine possono restare aperte e nascoste in background. Se nel sito esistono una o più pagine con auto-refresh, è buona pratica offrire all''utente la possibilità di far cessare il refresh e avvertirlo che esso potrebbe causare costi non previsti. Infine, il re-indirizzamento è una pratica piuttosto utilizzata nel Web ma è bene ricordare che questo meccanismo normalmente causa ritardi nella rete e rallenta i collegamenti.

La sezione relativa alla navigazione si conclude con una nota sulle risorse esterni, che dovrebbero essere ridotte al minimo. L'invito a ridurre il numero di collegamenti esterni va nella direzione di limitare le richieste HTTP separate (quindi aggiuntive) rispetto a quella della pagina stessa. Ogni collegamento esterno alla pagina, come immagini, fogli di stile e altri oggetti, richiede infatti una richiesta HTTP separata rispetto a quella della pagina stessa, e questo può aumentare il tempo di scaricamento. Quindi è bene ridurre il numero di immagini per pagina e inserire le informazioni di stile all'interno di in solo foglio per pagina.

Continuiamo la nostra rassegna critica sulle Mobile Web Best Practices (MWBP) occupandoci in questa parte dell'articolo dei consigli del W3C sul layout e i contenuti delle pagine per dispositivi mobili.

La serie di raccomandazioni su "Page layout and content" si propone di affrontare la percezione che l'utente ha dei contenuti e degli elementi della pagina cosi come li fruirà sul suo dispositivo, senza affrontare gli aspetti più squisitamente tecnici che sono invece discussi nella sezione “Page definition”.

La prima serie di raccomandazioni riguarda i contenuti:

• Assicurarsi che il contenuto sia adatto all'utilizzo in un contesto mobile
• Usare un linguaggio semplice e chiaro
• Limitare il contenuto a quanto l'utente ha richiesto

La prima e la terza raccomandazione sono, possiamo dire, particolarmente specifiche per la fruizione di contenuti web in ambiente mobile, in quanto date le limitazioni intrinseche del mezzo che ne influenzano l'utilizzo, e altri fattori specifici come i costi di connessione elevati, il contesto in cui si può trovare l’utente (fuori da casa o dall’ufficio, in ambienti affollati o rumorosi, mentre sta camminando, etc.) si dovrebbe cercare di inviare all'utente solo l'informazione specifica, il più possibile pertinente alle sue richieste. Offrire informazioni aggiuntive, come messaggi pubblicitari, potrebbe essere una scelta inappropriata per via del rallentamento dell'esperienza di navigazione e per la possibile crescita dei costi di connessione.

Difficilmente l'utente usa il Web mobile per navigare e passare il tempo (anche se in ogni caso questa possibilità non deve essergli preclusa), ma piuttosto per ottenere un'informazione aggiornata e spesso adattata al contesto in cui si trova (ad esempio, si pensi all'informazione localizzata in contesto cittadino come informazione in tempo reale sui parcheggi, sul traffico, sui film in programmazione, gli orari dei bus).

L'informazione dovrebbe essere sempre rilevante, o per lo meno l'informazione più rilevante dovrebbe essere in primo piano. Come del resto prescrivono anche le WCAG in materia di redazione di testi accessibili, si consiglia di adottare la tecnica del front loading che, sinteticamente, chiede di porre l'informazione più importante ad inizio di titoli, paragrafi, liste ecc. In questo modo per l'utente è più semplice capire rapidamente di quale argomento tratta il contenuto e valutare se è di suo interesse.

Qui entra in gioco la seconda linea guida (usare un linguaggio semplice e chiaro), che a differenza delle precedenti dovrebbe essere tenuta sempre in conto anche nel desktop Web (vedere ad esempio i consigli di Nielsen: Be Succinct! Writing for the Web, How Users Read on the Web.

Gli utenti di Internet non leggono, ma scorrono l'informazione. Dunque uno stile breve e diretto, di stampo giornalistico può aiutare nella fruizione del testo su Web.

Questo vale ancor più sul web mobile. Chi, che cosa, dove, quando e perché (le famose 5 W del giornalismo) dovrebbero sempre precedere brani più lunghi di informazione per mettere l'utente in condizione di decidere se approfondire l'nformazione presentata oppure no.

Le regole del web sulla scrittura e sulla quantità di informazione devono essere seguite ancora più rigorosamente nel web mobile, dove gli utenti sono irritati se spendono costi per connessioni rallentate a causa di elementi pubblicitari, o testi troppo lunghi e poco focalizzati.

Successivamente le raccomandazioni affrontano lo spinoso problema della dimensione delle pagine:

• Dividere la pagina in porzioni usabili, ma limitate
• Assicurarsi che la dimensione totale della pagina sia appropriata alle limitazioni di memoria del device (si veda ad esempio il sito Mobile Review per informazioni dettagliate e comparazioni tra dispositivi).

Se le pagine sono troppo lunghe, sono anche troppo pesanti da scaricare. D'altra parte se sono troppo corte si costringe l'utente a cliccare molte volte per raggiungere l'informazione desiderata.

Una giusta via di mezzo tra la paginazione e lo scrolling è in parte una questione di gusto, in parte una questione di necessità. I dispositivi con disposizioni di memoria molto rigide accettano solo pagine dalle dimensioni limitate. Ugualmente ci sono invece dispositivi lacunosi nell'offrire una buona esperienza di scrolling, ma ottimi nel recupero di pagine anche pesanti.

Alcuni esperimenti hanno dimostrato che gli utenti preferiscono fare scrolling, piuttosto che dover cliccare su molti link per raggiungere ciò che desiderano, altri hanno dimostrato il contrario. Si veda ad esempio lo studio di Segala su scrolling vs. paginazione.

Sempre allo scrolling si riferisce l'indicazione successiva:

• Limitare lo scrolling ad una direzione, a meno che lo scrolling secondario non possa non essere evitato

Le pagine dovrebbero proporre sempre lo scrolling lungo una medesima direzione, per facilitare l'esperienza dell'utente. Lo scrolling in senso verticale è da preferirsi, in linea di massima, in quanto più comodo e maggiormente vicino alle esperienze passate dell'utente. Tuttavia certi oggetti, come mappe e immagini, possono fare scrollare anche orizzontalmente la pagina. Sarebbe comunque meglio presentare immagini dalle dimensioni ridotte, e dare la possibilità all'utente di ingrandirle a piacere.

Le informazioni più rilevanti dovrebbero sempre essere a inizio pagina:

• Assicurarsi che il materiale centrale per la comprensione della pagina preceda il materiale che non lo è

La maggior parte delle pagine web sono progettate per ospitare gli elementi di navigazione nella parte superiore o laterale della pagina. Tuttavia nel caso di display dalle dimesioni limitate questo potrebbe causare un inconveniete: la navigazione appare prima del testo rilevante della pagina stessa, che può anche essere ragguinbile solo grazie allo scrolling. Cosa ci può essere du più brutto che navigare un sito sul mobile web e trovarsi ogni volta su una pagina che ci fa vedere solo gli elementi di navigazione?

Dal momento che l'utente si fa un idea della pagina dalle prime cose che vede, sarebbe bene limitare lo spazio dedicato ad elementi di navigazione, per non parlare di pubblicità e immagini decorative.

Tuttavia gli elementi di navigazione sono estremamente utili nell'interazione con un sito web. Il W3C propone alcune soluzioni: mettere un link in alto nella pagina che porti alle selezioni di navigazione poste da qualche altra parte, come in fondo alla pagina, oppure mettere una barra di navigazione di solo testo con le principali sezioni della pagina.

Le linee guida su "Page layout and content" danno in ultima battuta indicazioni su grafica:

• Non usare la grafica per spaziare gli elementi (utilizzare un elemento grafico di un pixel per il posizionamento assoluto non funziona su molti schermi)
• Non usare immagini che non possano avere una buona resa sul device. Evitare le immagini larghe o ad alta risoluzione eccetto il caso in cui dell'informazione critica andrebbe altrimenti persa (tuttavia la grafica ad alta risoluzione e un numero eccessivo di colori occupano troppa banda al momento del loro scaricamento)

Colore:

• Assicurarsi che l' informazione veicolata dal solo colore sia disponibile anche senza colore
• Assicurarsi che la combinazione tra i colori di sfondo e quello in primo piano fornisca un contrasto sufficiente

Immagini di sfondo:

• Quando si usano immagini come sfondo assicurarsi che il contenuto risulti leggibile sul device

Questo ultimi tre avvertimenti non dovrebbero essere nuovi per coloro che hanno familiarità con le WCAG .

Se ad esempio si vuole che il colore sottolinei oppure differenzi del testo ci si deve ricordare che non sempre gli utenti vedono il colore (pensiamo agli ipovedenti o agli utenti di dispositivi con schermi monocromatici). Un link, ad esempio, non dovrebbe essere solo differenziato da una scelta cromatica differente, ma anche dalla sottolineatura, perché alcuni utenti potrebbero non accorgersene.

Così come il contrasto tra lo sfondo e i colori di primo piano dovrebbe sempre essere controllato (ad esempio, per controllare ci si può avvalere di uno strumento apposito). Stesso discorso vale per le immagini di sfondo, che non dovrebbero interferire con il testo, e in ambiente mobile andrebbero usate con molta cautela.

Commentiamo brevemente le raccomandazioni su User Input. Come ci si può aspettare, in ambiente mobile si deve cercare di limitare al minimo l'attività di inserimento testuale da parte dell'utente: spesso manca infatti un dispositivo di puntamento e l'utilizzo della tastiera non è un'attività del tutto agevole.

• Fare si che l'utilizzo della tastiera sia ridotto al minimo
• Evitare, se possibile, l'immissione di testo libero
• Se l'utente deve inserire del testo, fornire, se possibile, del testo predefinito da selezionare (usare ad esempio liste di selezione, pulsanti radio, utilizzare i precedenti inserimenti come default, rendere possibile la selezione degli elementi della lista attraverso i tasti numerici o i pulsanti di direzione, etc.)
• Specificare una modalità di inserimento predefinita (sul linguaggio o sul formato di inserimento), se il device la supporta. Alcuni linguaggi di markup consentono di specificare modalità di input, cosa che può risultare particolarmente utile se le possilità di inserimento sono limitate, per esempio, solo ai numeri. È stato già anticipato che il nuovo linguaggio XHTML-Basic (http://www.w3.org/TR/xhtml-basic/) offrirà queste caratteristiche
• Creare un ordine logico di tabulazione attraverso i link, i pulsanti di controllo, gli oggetti presenti nella pagina. L'utente potrebbe non avere a disposizione un dispositivo di puntamento e muoversi nella pagina esclusivamente con i tasti direzionali. Quindi il passaggio tra i sopra-citati elementi deve avvenire seguendo un ordine logico, anche perché spesso il focus su un determinato elemento non è evidente e l'utente potrebbe non sapere dove si trova. A tal proposito ricordiamo che l'ordine di tabulazione si può forzare in HTML con l'utilizzo dell'attributo tabindex del tag <a>
• Etichettare i controlli dei form in maniera appropriata e associare esplicitamente le etichette ai controlli
• Posizionare le etichette dei controlli in maniera tale che si dispongano correttamente in relazione al controllo di riferimento. Questa linea guida, come la precedente, si riferisce al fatto di utilizzare correttamente il tag <label> in corrispondenza degli elementi del form a cui si riferisce. Ad esempio, dovendo riferire un elemento <label> ad un campo di testo per l'inserimento del nome si farebbe:

Questo garantisce la corretta associazione e la conseguente logica tabulazione tra le etichette testuali e i campi di input di riferimento.

Page definition

Questa ultima parte dell'articolo sulle MWBP del W3C è dedicata all'analisi delle linee guida su Page Definition.

Iniziamo subito affrontando la prima raccomandazione che riguarda il titolo della pagina:

• Fornire un titolo breve ma descrittivo per ogni pagina

Il titolo deve essere corto per ridurre il peso della pagina, ed inoltre potrebbe essere troncato dal browser, o addirittura non visualizzato. Inoltre, esso potrebbe venire utilizzato come etichetta del bookmark, e anche in questo caso valgono le precedenti considerazioni.

La seconda linea guida concerne l'utilizzo dei frame. Come ci si può aspettare l'utilizzo dei frame è assolutamente bandito:

• Non usare i frame

Come ampiamente dibattuto in discussioni concernenti l'usabilità dei siti web, (vedi ad esempio: Introduzione a XFrame del W3C o questo vecchio articolo di Jacob Nielsen), i frame causano diversi problemi agli utenti. Ad esempio, il titolo e l'indirizzo della pagina non cambiano nonostante le pagine all'interno del frame siano cambiate, i tasti direzionali non funzionano in maniera intuitiva, le pagine recuperate da un motore di ricerca risultano orfane se non sono collocate all'interno del frameset, ecc.

Per tutta una serie di motivate ragioni l'uso dei frame è altamente sconsigliato sia per i siti progettati per ambiente desktop e ancora di più per i siti per ambiente mobile, dove le limitate dimensioni dello schermo rendono il frameset ingestibile e assolutamente poco navigabile.

La terza raccomandazione ci parla di elementi strutturali.

• Utilizzare quelle caratteristiche del linguaggio di mark up per indicare la struttura logica del documento

Questa direttiva, che deriva direttamente dalle WCAG, dovrebbe, come la precedente, essere rigorosamente seguita sia nelle progettazioni per il desktop che per il mobile web, anche nei documenti più semplici.

Nella progettazione di una pagina HTML e' ritenuta essere una buona pratica quella di indicare la struttura logica della pagina (titolo, sottotitolo, paragrafo) con dei tag appropriati (ad esempio, H1, H2, P).

Utilizzare un markup strutturale, piuttosto che un markup di formattazione, consente un più facile adattamento del contenuto, quando questo deve essere suddiviso in più pagine, e un accesso più facile alle sezioni cui l'utente è interessato.

Inoltre, non va dimenticato che l'utilizzo logico dei tag strutturali facilita anche la semantizzazione del documento.

Le successive quattro indicazioni riguardano tutte il tema delle tabelle.

• Non usare le tabelle, a meno che non si sia sicuri che il dispositivo client le supporti
• Non usare le tabelle annidate
• Non usare le tabelle per l'impaginazione
• Dove possibile, usare sempre delle alternative alla presentazione tabellare

Le tabelle non funzionano bene con schermi dalle dimensioni limitate e potrebbero causare scrolling orizzontale in lettura. Inserire link di navigazione in una tabella potrebbe portare l'utente a scrollare sia orizzontalmente che verticalmente per vedere tutte le scelte di navigazione.

Inoltre, il device di base introdotto dalle MWBP non supporta le tabelle, e non supporta nemmeno gli script e gli oggetti incorporati all'interno della pagina, che sono sconsigliati anche dalle successive linee guida sugli elementi non testuali.

• Fornire del testo equivalente, per ogni elemento non testuale
• Non fare affidamento a oggetti incorporati o script

Scaricare un immagine da un device mobile può essere un'operazione costosa in termini di tempo e denaro. Il testo alternativo che viene visualizzato al posto o prima che l'immagine arrivi può aiutare l'utente a decidere se vale la pena di visualizzare l'immagine oppure no. In ogni caso è sempre meglio progettare le pagine in maniera tale che funzionino anche in modalità di solo testo.

Per quando riguarda gli oggetti incorporati (tag <embed>, <object>, ...) e gli script che si inseriscono all'interno del codice, è bene tenere a mente che essi spesso non sono supportati dai device mobili e né tanto meno è possibile installare i plug-in per la loro fruizione.

In aggiunta, anche se i dispositivi supportano gli script, questi causano un aumento nel consumo di energia e di conseguenza scaricano più velocemente le batterie. Per questo sarebbe bene evitarli (e in ogni caso se si usa del codice Javascript sarebbe meglio usare il trigger onclick piuttosto che onmouse e onkey, in quanto i meccanismi di input possono essere molteplici) a meno che essi siano l'unica via per raggiungere un certo obiettivo.

Di nuovo di immagini parla il sesto gruppo di linea guida:

• specificare la dimensione delle immagini all'interno del codice di markup (ad esempio negli attributi height e width di HTML), se esse hanno delle dimensioni specifiche. In questo modo il browser è in grado di calcolare in anticipo quanto spazio esse occuperanno.
• ridimensionare le immagini lato server, se queste hanno delle dimensioni specifiche. In questo modo il client non deve processare il ridimensionamento dell'immagine che rallenterebbe lo scaricamento della pagina.

Le successive specifiche affrontano ancora aspetti tecnici legati al codice

• creare dei documenti con del codice convalidato secondo le grammatiche formali presenti su web. Se la pagina contiene del markup non valido il suo aspetto potrebbe essere non prevedibile e incompleto.
• non usare come unità di misura i pixel, o altre unità assolute sia nel codice di markup che nei fogli di stile. Le unità relative consentono al browser di adattare la pagina ed i suoi elementi allo schermo del device richiedente. Un'eccezione a questa regola riguarda le immagini create con una dimensione specifica, apposita per il dispositivo richiedente, per le quali si devono usare i pixel nello specificare l'altezza e la larghezza.. Anche per le dimensioni dei bordi e del padding, i pixel consentono una migliore impaginazione, in quanto fissano dei limiti all'interno dei quali gli altri elementi andranno a disporsi di conseguenza.

Il nono gruppo di linee guida affronta nello specifico le tematiche inerenti i fogli di stile:

• usare i fogli di stile per il layout e la presentazione, a meno che si sappia che il dispositivo non li supporta
• organizzare il documento in maniera tale che possa essere letto anche senza fogli di stile. Non tutti i dispositivi supportano appieno le specifiche di stile (ad es., alcuni non supportano il tag <style>, altri supportano solo un foglio di stile per pagina, altri ancora non hanno meccanismi di caching per i fogli esterni, ecc.), quindi la pagina deve poter funzionare anche senza. Per questo il contenuto della pagina deve avere un ordine e un senso anche senza il foglio di stile. Se si sta progettano per il device di base bisogna utilizzare un foglio di stile esterno. Se si sa che il device per il quale si sta progettando supporta il tag style, si può disporre l'informazione di stile anche internamente alla pagina. Inoltre utilizzare sempre l'attributo media specificando sia il valore handheld che all (non tutti i browser interpretano correttamente handheld);
• fare si che le dimensioni dei fogli di stile siano piccole. Utilizzare quando possibile la ridefinizione dei tag HTML e non abbondare nell'utilizzo delle classi; inserire nel foglio solo gli stili davvero utilizzati; raggruppare gli elementi HTML che condividono lo stesso stile, ecc.

La decima linea guida è strettamente legata alla precedente.

• Utilizzare un markup pulito ed efficiente.

Questo comporta evitare linee e spazi vuoti (come quelli causati dall'indentazione) e l'utilizzo delle specifiche di stile inline (preferire le classi)

L'undicesimo gruppo affronta i tipi di contenuto da inviare.

• Inviare del contenuto che sia supportato dal device client
• Quando possibile, inviare il contenuto nel formato preferito

Per determinare quali tipi di contenuto un device supporta si può utilizzare una combinazione di informazioni sul profilo del device, come quelle contenute negli header http, e nei profili UAProf.

L'analisi degli header http risulta utile anche per la codifica dei caratteri (intestazioni su Accept-Charset), come specificano le successive raccomandazioni.

• assicurarsi che la codifica del carattere sia supportata dal device client
• indicare nella risposta il tipo di codifica utilizzata

Ad esempio attraverso il tag meta in HTML.

oppure in XML nella dichiarazion del tipo di codifica

La linea guida successiva è direttamente derivata da principi di usabilità per il desktop web:

• Fornire dei messaggi di errore informativi ed una via di uscita per tornare indietro verso l'informazione utile, come ad esempio "torna alla pagina precedente", "torna alla home", ecc.

Infine le ultime raccomandazioni hanno un tono più tecnico

• Non affidarsi ai cookie. Molti dispositivi mobili non supportano i cookie, o offrono un supporto solo parziale. Quindi è bene non affidarsi solo ai cookie per identificare l'utente e per salvare le sue preferenze, per la gestione delle sessioni, ecc.
• Fornire informazioni sull'utilizzo della cache nelle risposte http, e nei valori dei meta tag correlati (ad es., CACHE-CONTROL ed EXPIRE). E' importante che l'utilizzo della cache sia concesso, cosicché il client non debba ricaricare tutte le volte quei file che sono gia stati scaricati e che vengono riutilizzati tra una pagina e l'altra
• Non affidarsi allo stile dei font. Molti dispositivi mobili offrono supporto solo per pochi font e limitati effetti (solo grassetto, corsivo,..). Quindi l'utilizzo di font specifici ed effetti più sofisticati rischia di non essere supportato dal client