Nokia Web Browser Design Guide
Scritto da Andrea | 28.06.2007
Ideale complemento del messaggio precedente, sull’area del sito Nokia dedicata agli sviluppatori ho scovato questa guida alla realizzazione di siti web per il microbrowser presente come predefinito su i cellulari della serie S60.
Resource information: Nokia Web Browser Design Guide
Al di là di molti consigli utili, per altro derivati esplicitamente dalle Mobile Web Best Practices 1.0 (si legga come introduzione il mio articolo su HTML.it), sono davvero interessanti alcuni aspetti.
In primo luogo una descrizione precisa delle caratteristiche tecniche del browser in questione, informazioni utilissime e spesso difficili da scovare. Apprendo in tal senso che il Nokia Web Browser possiede un supporto per HTML 4.01, XHTML 1.0 comprese le immagini mappa, i frame, le immagini di background, il tag <meta> e il tag <object>; per CSS 1, 2 e (in parte) 3 compresa la possibilità di includere fogli di stile esterni; DOM 1 e 2; SVG-Tiny; JavaScript 1.5. Inoltre è garantito il supporto per la piattaforma Flash Lite.
Secondariamente si forniscono alcuni brani di codice molto utili per riconoscere le dimensioni dello schermo e quindi selezionare di conseguenza un CSS più adatto.
In terzo luogo si pone l’accento sull’adozione di una strategia orientata al progressive enhancement anziché ragionare in termini di una rinuncia di caratteristiche e contenuti che potrebbero andare incontro al miglioramento dell’esperienza d’uso.
Infine, una considerazione importante relativa al modo in cui Nokia intende il mobile web. Affrontando il problema dell’adattamento, la guida afferma che:
In general, implementing server-side solutions requires more initial work and assumes a level of server access and expertise that goes beyond the simple Web design skill set. For many smaller site owners, server-side scripting is something to be avoided, and many hosting companies charge additional fees for providing this service.
Adopting a client-side solution involves a different approach. The requested page is sent “as is” to the mobile device, and any possible tailoring of the content is done in the browser rendering engine. The Web developer can include JavaScript™ and alternative CSS styles to reorganize the content that is actually processed on the browser.
The Nokia Web Browser aims to deliver a full, desktop-like browsing experience. Web developer can be sure that the user will see the page as it is designed, without external reorganizing of the content. From the user’s point of view, this approach is quite simple and natural: a Web site has the same look and feel on all browsers. Branding and “sense of location” — both important elements to the success of a Web space — are properly maintained.
Riassumo per chi ha difficoltà con l’inglese: considerando che i processi di adattamento lato server sono spesso onerosi per gli sviluppatori, se vogliamo rendere davvero facile la pubblicazione di contenuti e servizi per il canale mobile dobbiamo far cadere quest’onere sul client. Piuttosto adottiamo tecniche, del resto molto semplici, che consentano al browser di adattarsi meglio alla pagina. Inoltre si favorisce la percezione dell’utente che il sito web sia uno solo: l’identità del sito e l’orientamento su di esso caratteristiche preservate.
Considerando anche le precedenti riflessioni su Opera Mini e Safari per
Opera e Safari privilegiano la sequenza overview -> zoom, lasciando libero l’utente di posizionarsi dove meglio crede dopo aver acquisito una panoramica della pagina. Nokia browser, invece, fa il percorso inverso: la finestra è collocata nella parte in alto a sinistra della pagina e, solo a seguito di un movimento, viene mostrata l’overview.
Resto pertanto dell’idea che forse va rivisto il concetto di CSS diverso per canale diverso. Forse non i differenti CSS non vanno considerati come alternativi, piuttosto come complementari.
Topics: Messaggi personali | No Comments »
Navigare con telefoni cellulari: il tema della user experience
Scritto da Andrea | 28.06.2007
Di link in link sono giunto su questa pubblicazione del Nokia Research Centre.
Web Browsing on Mobile Phones - Characteristics of User Experience
Si tratta della tesi di dottorato di Virpi Roto. In questo testo, molto recente e tutto sommato molto leggibile, si fa il punto sulle ricerche finora condotte in relazione all’esperienza d’uso dei fruitori del mobile web. Risulta parecchio interessante l’elenco dei fattori che contribuiscono a incrementare o peggiorare la qualità dell’esperienza d’uso. In sintesi, questi si possono riferire:
- al sito stesso: la sua architettura dell’informazione, la sua usabilità e utilità;
- alla connettività;
- all’ottimizzazione delle pagine (processi di adattamento)
- al microbrowser usato dall’utente
- alle caratteristiche hardware, software nonché l’usabilità del dispositivo mobile stesso;
- al contesto di fruizione / accesso
- all’utente stesso
Forse non serviva questa tesi a farmelo capire, ma è indubbio che nel caso della progettazione dei siti web per dispositivi mobili i fattori siano molti di più del solito. L’accesso all’informazione è una vera e propria “esperienza” d’uso, condizionata e motivata da una serie di variabili che nel contesto desktop sono spesso irrilevanti (oppure molto standardizzate).
Insomma consiglio la lettura.
Topics: Usabilità, Mobile | 1 Comment »
L’estate calda del mobile web: Opera Mini vs iPhone
Scritto da Andrea | 24.06.2007
Mentre finalmente il termometro comincia a salire anche qui a Torino, le libere navigazioni domenicali mi hanno portato a evidenziare un collegamento tra due soluzioni tecnologiche in arrivo sui nostri “più piccoli schermi”. Si tratta della nuova versione (la quarta) del browser Opera Mini per dispositivi mobili e del tanto pubblicizzato iPhone, che disporrà di un’installazione su misura di Safari. Si preannuncia un’innalzamento della temperatura sul territorio del mobile web. Prendete una bibita ghiacciata.
Sia l’uno che l’altro non sono ancora disponibili in modo definitivo. iPhone verrà venduto nel mercato USA a partire dal 29 giugno, mentre Opera Mini 4 è al momento disponibile solo in versione beta.
Opera Mini 4 è tuttavia già da subito scaricabile sul proprio terminale (basta recarsi con il browser del proprio cellulare su http://mini.opera.com/beta/ e seguire le istruzioni). Per chi non volesse / potesse seguire questa procedura, Opera ha pubblicato un video che illustra le principali innovazioni e caratteristiche del proprio prodotto. Chi volesse dargli una sbirciata, può recarsi all’indirizzo:
http://www.operamini.com/beta/demo/
Anche Apple ha messo in rete un video esplicativo delle caratteristiche di iPhone. Mentre il filmato di Opera si concentra su una semplice sessione di navigazione, il video dedicato all’iPhone esplica le varie caratteristiche del dispositivo, che vuole porsi come soluzione all-in-one che condensi un cellulare, un iPod e un internet device. Questo secondo video è rintracciabile presso:
http://www.apple.com/iphone/usingiphone/guidedtour.html.
Inoltre da oggi (mi pare) è disponibile anche la versione 3.0.2 per Windows e Mac della Beta pubblica (sono stati risolti i bachi di visualizzazione della versone Windows). Il link per scaricarla è http://www.apple.com/safari/download/.
Da un punto di vista tecnologico è necessario formulare due dovute osservazioni
La prima riguarda la tecnica di adattamento messa in atto da Opera Mini. Mentre Safari per iPhone si comporterà come tutti i normali browser (ossia andrà a richiedere le pagine ai rispettivi server e quindi ne fornirà una rappresentazione tramite il proprio motore di rendering), Opera Mini continuerà a sfruttare la tecnologia lato server Mini: la pagina viene filtrata da un server Proxy che utilizzando il motore di rendering di Opera Browser per desktop, genera una versione ottimizzata per dispositivi mobili (per esempio riducendo il peso dei file). Il funzionamento di questa tecnica di adattamento è descritto dall’immagine che segue, tratta dal sito web Opera.
La seconda osservazione, invece, è relativa al legame molto stretto che sussisterà tra Safari e iPhone. Sarà con ogni probabilità possibile utilizzare Safari come canale di comunicazione tra il web e il device, per poter accedere e sfruttare dati e applicazioni residenti sul dispositivo (per esempio la rubrica). Oppure ancora sarà possibile sfruttare all’interno della pagina web alcuni metodi di interazione legati alla tecnologia multi-touch, registrando nuovi eventi al momento non previsti dal DOM standard. In tal senso il rischio è che si venga a generare una sorta di walled garden non più legato a un operatore ma a un device. Sebbene queste opportunità sono ancora tutte da verificare e da esplorare, confidiamo di non dover mai accedere a un sito web mobile che ci bloccherà e ci comunicherà “sito web ottimizzato per Safari iPhone”. Grazie, ma abbiamo già dato…
Tornando al confronto tra i due prodotti, a vedere le due presentazioni sembrano emergere alcuni tratti comuni, in parte già designate dai concorrenti o da precedenti versioni.
Overview mode: fare un passo indietro per farne poi tre in avanti
Dal punto di vista della presentazione dei contenuti, sembra ormai uno standard la visualizzazione della pagina da un punto di osservazione più distanziato (”overview mode“): il browser effettua un ridimensionamento della pagina affinché questa possa essere interamente visualizzata come miniatura all’interno degli stretti confini del display. In questo modo l’utente può avere una vista unica sui contenuti della pagina. Tramite opportune funzionalità di zoom, quindi, è possibile avvicinarsi a una sezione specifica della pagina in modo tale da poterne leggere i contenuti.
Simile approccio ottimizza la ricerca di informazione all’interno della pagina e ha il merito di fornire un contesto all’informazione. Qualsiasi operazione di magnificazione di un oggetto implica un accrescimento delle informazioni disponibili in relazione al particolare ingrandito ma una parallela dismissione di tutte le informazioni contestuali e periferiche: pertanto è preferibile avviare la navigazione in modalità overview e poi effettuare uno zoom anziché avviare la sessione direttamente in forma ravvicinata. Altri microbrowser (come il Nokia browser presente sul mio E61) non hanno ancora incorporato tale funzionalità. Pertanto la navigazione è piuttosto efficiente in siti web che l’utente già conosce molto bene (ossia di cui possiede una mappa mentale piuttosto precisa), mentre in siti web mai visitati diventa un po’ più ostico riuscire a trovare la strada per i contenuti di interesse.
Il tema della familiarità è cruciale anche in relazione alla qualità della miniatura iniziale, che è necessariamente funzione delle dimensioni del display. E’ plausibile che l’importanza delle dimensioni della overview siano proporzionali al grado di conoscenza che l’utente ha del sito. Nei confronti di siti web già noti, l’utente non ha l’esigenza di effettuare una prima interpretazione dell’immagine per poi decidere dove far insistere l’azione di zoom: se sa che il tal box informativo è in alto a destra, non sarà importante poterne già comprendere il contenuto anche dalla modalità overview. D’altra parte su un sito web di nuova visita, in caso di display molto piccolo, potrebbe rendersi necessario un primo (casuale) zoom sulla pagina e quindi effettuare un’esplorazione ravvicinata.
Anche se la modalità “overview-zoom” incoraggia gli sviluppatori a disinteressarsi dall’idea di ottimizzare in chiave mobile la presentazione visuale dei propri siti (perché rivoluzionare il layout se l’utente potrà agevolmente spostarsi dalla miniatura allo zoom?), la possibilità di istruire il browser in modo da trattare i contenuti in modo particolare può restare allettante. Per esempio potrebbe essere interessante utilizzare un CSS con per media “handheld” al fine di esaltare le dimensioni di alcuni elementi della pagina affinché siano facilmente riconoscibili anche nella modalità overview. Probabilmente, prima di poter applicare idee di questo tipo, potrebbe essere necessario valutare con attenzione il supporto per le “media rules” da parte di questi browser nonché l’influenza di tecniche di adattamento intermedie basate su Proxy.
Mobile Ajax: la medicina che aspettavamo
La strada è segnata e si chiama Ajax. Dalla versione 4 di Opera Mini si avrà il pieno supporto per l’oggetto XMLHttpRequest, cruciale per questo tipo di soluzione. Safari è già una garanzia su questo fronte, al punto da esser stato designato dalla Apple come punto di accesso per gli sviluppatori terzi che vorranno realizzare applicativi per iPod.
L’esistenza di una piattaforma tecnica per servizi basati su Mobile Ajax è il requisito base affinché l’accesso al web in mobilità possa diventare un servizio pienamente diffuso e utilizzato dagli utenti. Ho parzialmente approfondito la questione le mio articolo precedente (http://andrea.3juice.com/2007/06/09/mobile-web-e-ajax/). Ribadisco in questa sede alcuni dei motivi per cui questa innovazione sarà probabilmente cruciale:
- rendendo più efficiente la comunicazione client-server, diminuiranno i tempi e i costi della comunicazione mediata dal mobile web;
- permettendo di ridurre il gap tecnologico tra mobile web e desktop web, gli utenti faranno dipendere la scelta del dispositivo di accesso non tanto dalla relativa usabilità dello strumento quanto piuttosto dalle proprie esigenze informative;
- si aprirà la via alla sperimentazione di servizi di collaborazione in tempo reale tra utenti in mobilità, decisamente allettante in ottica business
- per gli sviluppatori significherà non dover più pensare a forme “degradate” dei medesimi servizi: potrà finalmente prendere piede anche sul fronte mobile il paradigma del progressive enhancement, mantenendo fede al principio - di carattere più generale - di accessibilità dell’informazione.
In questi giorni anche Ajaxian si sta occupando di esplorare il supporto ad Ajax di iPhone:
http://ajaxian.com/by/topic/iphone/
Nota
per chi desiderasse un confronto meno serio, Opera ha diffuso questo secondo video, che fa un po’ il verso alle recenti pubblicità Apple e sottolineando in modo ironico alcune limitazioni del proprio concorrente:
Topics: Messaggi personali | No Comments »
Mobile web e Ajax
Scritto da Andrea | 9.06.2007
La possibilità di applicare in ambito mobile soluzioni tecnologiche come Ajax rappresenta un punto molto importante a favore della diffusione dell’uso dei dispositivi mobili come strumento di accesso al web. Attualmente esistono ancora diversi limiti (economici, sociali e tecnici) all’esplosione del mobile web, almeno in Italia. Il pieno supporto di Ajax permetterebbe infatti l’implementazione di servizi più efficienti ed efficaci. Tale necessità emerge con forza qualora si rifletta sulle modalità di utilizzo del mobile web da parte degli utenti.
Attualmente i siti web per dispositivi mobili sembrano soprattutto dei “fratelli minori” dei corrispondenti servizi pensati per il desktop. A questa situazione, ovviamente, concorrono numerosi fattori: l’assenza di un reale pubblico, i vincoli imposti dalle politiche tariffarie imposte da molte compagnie, la preferenza da parte dei carrier di proporre i cosiddetti “walled garden” anziché permettere un accesso senza limitazioni all’intero web, le scarse conoscenze da parte degli sviluppatori circa quali contenuti o servizi potrebbero essere davvero interessanti per destinatari in movimento.
Gli utenti del mobile web utilizzano il loro browser principalmente per tre obiettivi:
- Cercare (preferibilmente in modo rapido) una risposta precisa a un’esigenza informativa specifica;
- Proseguire / avviare un’attività che è iniziata / sarà conclusa su un altro device (tipicamente un Personal Computer da tavolo)
- Intrattenersi: leggere, guardare un video, sfogliare delle fotografie
Perché il mobile web sia in grado di soddisfare in modo efficace queste tre esigenze è ovviamente necessario siano introdotte alcune innovazioni tecnologiche e metodologiche che conducano - di conseguenza - a un miglioramento sul fronte dell’esperienza d’uso. Da un lato sono necessario entrare in possesso di terminali più capaci dal punto di vista delle opportunità di visualizzazione e di rappresentazione dell’informazione, nonché più maneggevoli in fase di input. Dall’altro sarà importante che i progettisti studino a fondo i possibili destinatari per poter produrre sistemi informativi orientati ai bisogni di questi ultimi sia per quanto riguarda i contenuti sia relativamente all’architettura dell’informazione.
Inoltre, esiste la necessità di disporre di soluzioni tecnologiche in grado di riprodurre anche le forme e le modalità di interazione che gli utenti hanno maturato e apprezzato accedendo al web tramite il proprio computer da tavolo. Finché il mobile web sarà considerato un’alternativa scomoda e lenta rispetto a quanto è possibile ottenere dal pc di casa o dell’ufficio, probabilmente gli utenti preferiranno rimandare le azioni pianificate in condizioni di mobilità.
Ajax permetterebbe di avvicinare l’esperienza d’uso del mobile web a quella consueta. Al momento non sono ancora molto diffusi i terminali / browser in grado di supportare questo mix di tecnologie. In rete, ho scovato questa interessante FAQ sul tema, utile a dirimere molte curiosità e dubbi in merito:
Oltre ad alcune utili definizioni (a cominciare da “Che cos’è Mobile Ajax“), questo articolo permette di capire la differenza tra Mobile Ajax e altre tecnologie (come Flash Lite o Java 2MEE), oppure di avere un quadro immediato dei dispositivi che attualmente supportano la tecnologia in questione. Chi scrive confida che nel tempo questa pagina venga arricchita da risposte ad altri interrogativi. Si segnala che gli autori delle FAQ sono aperti a suggerimenti da parte dei lettori.
Topics: Web 2.0, Mobile | 1 Comment »
La qualità di un sito web e il team di lavoro
Scritto da Andrea | 3.06.2007
La qualità di un sito web dipende dal grado in cui sono raggiunti obiettivi quali un’interazione usabile e accessibile, la trovabilità dell’informazione, la completezza, pertinenza, affidabilità dei contenuti, nonché la solidità tecnologica. In tal senso mi trovo molto d’accordo con il punto di vista di Peter Morville: la qualità di un sito web non può essere raggiunta solo ed esclusivamente insistendo su uno di questi versanti, piuttosto grazie ad un approccio olistico che tenga in dovuta considerazione i requisiti di ciascuno di questi assi.
Resta tuttavia un dubbio: come posso fare, in quanto progettista, a esser certo che le soglie raggiunte su tali versanti siano effettivamente di valore o - più semplicemente - accettabili? Lo spunto per questa riflessione (che già covavo) viene anche dalla lettura dell’ultimo articolo di Jackob Nielsen:
In questo testo, Nielsen afferma che un buon designer non è garanzia di raggiungimento di risultati di qualità dal punto di vista dell’usabilità del prodotto. Per l’autore, affidarsi esclusivamente alle capacità inventive di un progettista può portare anche a clamorosi fallimenti. Il rischio principale risiederebbe nella presunta impossibilità di considerare affidabili le posizioni e le scelte del designer. Il lavoro di questo dovrebbe piuttosto appoggiarsi su informazioni e attività più rigorose e metodologicamente controllabili. In altre parole, dovrebbero diventare familiari concetti quali
Le motivazioni per cui Nielsen trova rischioso affidarsi al designer-genio sembrano valere anche per il contesto italiano. Molto spesso si considera sufficiente affidare la progettazione di un’interfaccia web solamente al creativo / grafico di turno. Tranne che in alcuni casi, questo tenderà a mettere in primo piano i suoi valori (qualità grafica, impatto emotivo ecc.), trascurando di fatto quelle attenzioni necessarie nei confronti di altri temi come - per esempio - il supporto alla ricerca dell’informazione. Questo problema, a mio avviso, si riscontra soprattutto nei team di lavoro di ridotte dimensioni, nei quali si fa fatica ad attribuire in modo univoco le competenze di progettazione.
Si tratta principalmente di un problema di metodo di lavoro: presi singolarmente, i singoli professionisti coinvolti possono anche essere di buon livello, ma ciò che consente loro di raggiungere un risultato davvero ottimo sta nella metodologia che tutti seguono allo scopo di perseguire l’obiettivo comune.
Una schematizzazione molto semplice/semplificata di questa potrebbe essere la seguente:
- Analisi e user research: comprende le attività volte a comprendere meglio gli utenti (in particolare i loro obiettivi), i contenuti e il contesto di riferimento;
- Progettazione: sulla base delle informazioni raccolte con la fase precedente, si passa al design dello spazio informativo (architettura dell’informazione) e alla definizione delle componenti funzionali (algoritmi) e grafiche;
- Sviluppo: la traduzione sul versante applicativo delle scelte compiute in fase di progettazione;
- Valutazione: la verifica del raggiungimento degli obiettivi e dei requisiti raccolti in fase di analisi nonché la valutazione del raggiungimento delle soglie di usabilità e accessibilità desiderate;
- Pubblicazione e manutenzione.
Ovviamente si tratta di una semplificazione: il processo di produzione di un sito web è raramente così lineare, ma piuttosto prende la forma di un ciclo iterato tante volte quante sono necessarie per raggiungere un risultato pienamente soddisfacente (sempre che lo si voglia raggiungere…).
Perché tale metodologia sia effettivamente rispettata è necessario che il capo-progetto diventi l’ispiratore e il garante della sua attuazione. Le sue funzioni dovrebbero essere:
- interfaccia verso l’esterno (con il cliente);
- coordinamento dei ruoli professionali coinvolti;
- gestione delle risorse, in altre parole la valutazione delle opportunità in rapporto a tempi e costi;
- controllo iterativo.
Se tutte e tre le funzioni sono cruciali, l’ultima assume un certo significato dal punto di vista del design in senso stretto. Occorre infatti un punto di vista sovraordinato rispetto alle singole attività che sia in grado di far dialogare tra loro le necessità dei singoli in accordo alle finalità complessive del progetto. Ed eventualmente capace di valutare su quali versanti intervenire per correggere o limitare le criticità del caso.
Topics: Usabilità | No Comments »