Molti analisti ritengono che le connessioni da dispositivi mobili aumenteranno fortemente durante il 2010, dopo anni di aumenti a due cifre. La progettazione di siti per dispositivi mobili passa però per una serie di sfide e di scelte tutt’altro che chiare.
Il primo problema è l’estrema variabilità dei dispositivi, con dimensioni di visualizzazione, compatibilità con linguaggi di marcatura, di plugin (flash e java supportati o meno) e di accoppiate sistemi operativi/browser diversi, ciascuno con le sue possibilità.
(si veda qui un’analisi delle dimensioni dello schermo. Il 240 × 320 è la baseline, con tendenze sempre crescenti, che si attesteranno probabilmente fra il 640 × 480 e addirittura l’800 × 600, in futuro).
Da una grande variabilità verso una maggiore uniformità?
La variabilità è persino superiore a quella dei computer desktop all’inizio del web. E’ difficile dare linee guida robuste in tale situazione, ed è forse per questo che molti ritengono decisivo il successo dell’iPhone per uniformare mercato e progettazione. Come risulta da nostre statistiche, il 75% circa dei visitatori da mobile viene da iphone. Il che non è una grande notizia in termini di concorrenza, vista anche la rigida politica di chiusura di Apple su tutto ciò che riguarda il proprio telefonino. Ma c’è da ritenere se non altro che l’esperienza d’uso dell’iPhone in termini di tipo di navigazione possa essere presa a modello da altri produttori. E che dunque potremmo arrivare ad una standardizzazione delle pratiche progettuali, pur fra dispositivi diversi, ma ispirati allo stesso modello di esperienza.
Molti browser per cellulari e smartphone hanno capacità di resa inferiori a quelli del nostro computer: la pagina viene ricostruita e visualizzata in maniera differente da come la si vede su computer. iPhone e altri dispositivi provano a rendere le pagine in modalità full-web, cioè riproducendo esattamente la pagina come sui computer desktop. Nonostante la risoluzione inferiore. Questo è reso possibile sostanzialmente dalla funzione di zoom: la risoluzione rimane inferiore, ma è possibile rimpicciolire e ingrandire la pagina in maniera da visualizzarla tutta intera, e poi orientarsi sul dettaglio ingrandendo la parte che ci interessa. Questa vista ingrandita sul dettaglio ricorda curiosamente il modo in cui navigano i disabili visivi ipovedenti, i quali però hanno, a differenza degli utenti da mobile, difficoltà a percepire l’insieme della pagina.
Il futuro iPad, inoltre, pur avendo il sistema operativo e il browser dell’iPhone, difficilmente potrà essere considerato alla stregua degli altri dispositivi mobili, dato che ha una risoluzione di 1024 × 768.
Css e mobile: sito parallelo o stesso sito (adattato o no?)
La scelta fullweb porta a chiedersi se il nostro sito si fruisce in maniera accettabile anche in quelle condizioni. O, viceversa, se non sia più opportuno scegliere di identificare un utente da mobile e dirottarlo automaticamente verso un sottodominio che riproduca, adattandolo, il sito ai dispositivi più piccoli.
Lo stesso sito, da mobile
Nel caso in cui vogliamo servire ai dispositivi mobili lo stesso sito, potremmo voler servire un foglio di stile specifico. Nell’adattare un sito ai telefonini, si è portati a ritenere che la scelta progettuale migliore sia quella di dotarsi di un foglio di stile con media=”handheld”
. Purtroppo questa scelta è tutt’altro che ottimale. Molti browser mobili, infatti, non solo non interpretano il foglio di stile handheld, ma di default comprendono solo quello con media=”screen”
. Proprio nel tentativo di simulare il più possibile la visualizzazione da computer. Il che ci obbliga a soluzioni abbastanza intricate, nel caso volessimo servire un foglio di stile specifico per i dispositivi mobili. (Alistapart riporta un articolo completo che affronta il problema e propone una tecnica originale, benché non a prova di tutti i dispositivi, per fornire un css specifico ai dispositivi web).
In assenza di soluzioni specifiche, il nostro sito verrà visitato dai dispositivi mobili fullweb con lo stesso foglio di stile che usiamo per i monitor grandi.
Un sito parallelo?
Sono in molti a sostenere infatti che riproporre lo stesso sito a chi usa il cellulare è inutile, perché l’uso che se ne fa è diverso. Non si naviga per bighellonare su un sito o leggere articoli lunghi da cellulare: si cercano rapide reference, si consultano orari, si vogliono le ultime novità in breve e, dunque, sono quelle le informazioni di un sito che vanno estratte e adattate per i dispositivi mobili (qui consiglio un articolo di Fabio Regina del LAU molto utile sulla progettazione per device mobili).
Dunque adattare semplicemente con un foglio di stile il contenuto può non essere la scelta migliore. Perciò molti optano per un adattamento del sito su un sottodominio specifico (come mobile.sito.com, o m.sito.com), verso cui reindirizzare automaticamente il browser mobile. In questa nuova versione spesso il sito è adattato: ad esempio:
- le colonne non ci sono più
- i testi sono ridotti
- la navigazione non completa o non ripetuta su tutte le pagine, e così via.
Alcuni esempi: Alistapart, Digg, Corriere.it.
Per creare una versione mobile parallela del vostro sito, adattandola e selezionando solo parte dei contenuti, se il vostro CMS non è predisposto, sono disponibili alcuni servizi, anche gratuiti, che estraggono i contenuti dal vostro sito e generano sul sottodominio le nuove pagine da voi create. Un esempio è mobify, un altro mofuse, ma ce ne sono vari, in parte gratuiti e in parte a pagamento. Un elenco e una rassegna di vari servizi del genere è disponibile qui.
Usabilità: un punto di partenza
Ma come navigano le persone da dispositivi mobili? Il NielseNorman Group ha condotto una ricerca (in report a pagamento) abbastanza estesa sull’uso dei dispositivi mobili nella prima parte del 2009. I risultati (riassunti in un alertbox ) sono interessanti anche se, ripeto, tutto cambia molto rapidamente. Prendiamo dunque questi risultati come un punto di partenza, anche per valutare i prossimi cambiamenti.
Il tasso di successo è più basso
Il tasso di successo medio dei compiti somministrati in questo studio su 36 siti web (con 48 utenti) è del 59% contro l’80% medio sul web normale. Nessuna differenza fra utenti americani e londinesi.
Le versioni mobili sono meglio
Alcuni dei siti analizzati avevano una versione specifica per il mobile: ebbene, questi siti avevano un tasso di successo medio del 64%, contro il 53% di quelli che presentavano l’identico sito della versione desktop. Questa, secondo Nielsen, è una buona ragione per preparare una versione specifica per il mobile (non è chiaro se qualcuno dei siti avesse solo un css specifico per il mobile, piuttosto che una versione parallela). Ulteriori problemi sono stati trovati per il passaggio dalla versione full a quella mobile. Il modo migliore, secondo Nielsen, dovrebbe essere quello di riconoscere automaticamente i dispositivi mobili e indirizzarli automaticamente alla versione mobile. Tuttavia, poiché si tratta di una versione ridotta del sito, e alcuni utenti potrebbero usare dispositivi più capaci di altri e voler usare il sito completo, è bene offrire in alto nella pagina i link alla versione intera, così come nella versione completa è bene inserire un link alla versione mobile, nel caso volessero tornare indietro.
In questo modo, tutti gli utenti mobili non avrebbero problemi a trovare la versione mobile, perché ci verrebbero portati direttamente. Ma d’altra parte quelli che, nonostante tutto, volessero la versione completa, potrebbero arrivarci facilmente. Questa è anche a mio parere la strategia più indicata.
Tre tipi di esperienze mobile
Il report distingue poi fra tre tipi di esperienze mobili, strettamente legate al tipo di cellulare.
- Cellulari normali, con schermi piccoli e tastierina numerica. In questi dispositivi il tasso di successo è solo del 38%
- Smartphone, etichetta vaga ma che qui intende comprendere i dispositivi con schermi di dimensione media e una tastiera completa. I blackberry, insomma. Il tasso di successo è del 55%.
- I touchscreen, come gli iphone. Il tasso di successo è il più alto: 75%.
L’ovvio consiglio è di comprare telefonini touch se si intende navigare molto. Lo avevamo capito anche dalle nostre statistiche, come detto sopra.
Più complicato, dice Nielsen, per i gestori dei siti decidere cosa e come supportare. E’ il caso di supportare i cellulari, o è meglio concentrarsi su smart e touch? La risposta dipende dal tipo di sito e da cosa gli utenti fanno. Quanto ci si può aspettare che il sito sarà usato per consultazione, per transazioni, per feature sociali. Alcuni siti potrebbero dover preparare versioni mobili multiple, ottimizzate per almeno i cellulari semplici e gli smart/touch. A mio parere, invece, è molto probabile che in breve tempo avrà senso progettare solo per smart e touch, o addirittura solo per touch, se continuerà il trend che vedrà questi dispositivi così maggioritari nell’utenza mobile.
Alcune linee guida elementari di progettazione mobile e touch
Fra le numerose ricerche e liste di consigli di progettazione per siti specifici per il mobile, queste sono quelle che sembrano avere una maggior robustezza empirica:
- Progettare funzioni e contenuti adatti al contesto web. Capire come l’utente userà il vostro sito, e scalare funzionalità e contenuti su quell’uso. Il più delle volte questo significherà:
- Ridurre il numero di opzioni: contenuti, link, bottoni, campi; ad esempio, riprodurre solo i titoli di un elenco di articoli di un blog o di un notiziario.
- Ridurre la dimensione e il numero delle immagini
- Usare layout semplificati, riducendo il numero delle colonne (spesso una sola colonna può essere sufficiente)
- Le interfacce touch hanno bisogno di aree cliccabili più grandi di quelle per dispositivi di puntamento come il mouse, e di aree di buffer più grandi. E’ incredibilmente facile, se i target sono piccoli, cliccare per sbaglio un’altra cosa. Non solo: è facile, anche se sono grandi ma troppo vicini, cliccare sul margine e selezionare un oggetto diverso da quello inteso. Perciò l’area di buffer è importante. Ne deriva ovviamente che, anche dato il poco spazio su schermo, la quantità di opzioni è ovviamente limitata.
- Tecnologie: benché xhtml e css (possibilmente ben strutturati e validi) siano un buon punto di partenza per funzionare sui browser mobili (non c’è più bisogno di markup apposito1, insomma), javascript o addirittura video e plugin vari sono meno supportati. E’ bene quindi progettare dei fallback, cioè accertarsi che in assenza di quella tecnologia il sito sia intelliggibile e magari ugualmente utile, se non usabile.
- Il peso delle pagine dovrebbe essere inferiore a quello usato per il sito principale, a causa di connessioni più precarie e con banda più ristretta. Il checker del W3C indica in 20KB il peso massimo.
- Testare. Sugli emulatori. Ma possibilmente sui dispositivi reali.
Ulteriori risorse
Per approfondire cito qui alcune utili risorse, ricordando ancora una volta come la materia sia soggetta a repentini cambiamenti e che la cosa più importante è testare le soluzioni sui dispositivi di riferimento.
- Best practice a cura del W3C
- Mobile web design trends for 2009 su Smashing Magazine, una miniera di link, come sempre su questo sito, inclusi esempi di siti per dispositivi mobili, strumenti di test e molto altro:
- Sebbene del 2005, questa guida di Andrea Crevola è ancora una lettura interessante per ampiezza e qualità.
- L’articolo già citato sopra del LAU del CSI Piemonte del 2008 (pre-iPhone, cioè), ma ancora attuale per moltissimi versi, e pieno di informazioni e link utili.
1 La storia dei markup per i dispositivi mobili è lunga e complessa. In sintesi, i dispositivi Wap 1.0 usavano WML. Il Wap 2.0 usa XHTML Mobile-Profile (o XHTML MP), con compatibilità all’indietro per WML. XHTML MP è una riscrittura fatta da alcune aziende del settore dell’XHTML Basic proposto dal W3C. cHtml è usato sui dispositivi iMode. iPhone e i dispositivi più recenti supportano XHTML e HTML 4.0, così come HTML5, nonché javascript. Cioè lo stesso markup del web desktop. Ma come saprete iPhone non supporta Flash (anche se un workaround in js sembra farlo funzionare. Qui una demo). Se dunque volete mantenere la compatibilità con tutti i dispositivi passati e futuri, le cose si complicano. Se volete invece mantenere la compatibilità con i dispositivi più avanzati, XHTML è la scelta più sicura. iPhone ha anche una serie di metatag e di altre possibilità specifiche, ma non è questa la sede per parlarne.
La mia esperienza avuta con la realizzazione della versione mobile di Bol.it mi dice che sostanzialmente l’articolo è corretto.
Sottolineo con forza che la ri-progettazione di funzioni e layout è il nucleo essenziale del passaggio dal sito alla versione mobile.
Complimenti per l’ottimo articolo.
Io penso, addirittura, che sia meglio progettare prima i contenuti per dispositivi mobili, poi – una volta individuato come dirigere l’esperienza utente- sfoltire le funzionalità touchscreen per la versione desktop dello stesso sito.
L’articolo che vi segnalo spiega quali vantaggi si ottengono con questo approccio.
http://www.hightechware.it/sharedtip.php?id=6
Articolo molto interessante, anche non ero a conoscenza di un cheker W3C online! E probabilmente in pochi lo conoscono! Un supporto anche se io preferisco i test direttamente via cellulare.
http://seowebmaster.it/frames/seo-wap-master.html
il mio contributo… unico link a risorsa esterna che parte dal mio sito personale, senza nofollow!
E sono un seo professionista 😉
Ormai tutti quelli che usano il cellulare per navigare in internet hanno uno smartphone, da cui è possibile visualizzare il sito in modo normale con l’unico problema che il display è più piccolo. Per questo credo che bisogna ottimizzare i siti web per cellulari solo se hanno “qualcosa di interattivo” ad esempio basta pensare a youtube…. ma per il resto non credo che vadano ottimizzati.