Environmental design con la Device API

Cos’è la Device API?#section1

Lo sviluppo di Device API cominciò nel Luglio del 2011, quando Mozilla e il Dr. Andreas Gal crearono Boot2Gecko, un sistema operativo interamente basato sulle tecnologie web. La parte interessante di questo OS è che Mozilla aveva anche creato delle JavaScript API che permettessero l’accesso a livello del device dal browser.

Alcune API sono rimaste confinate all’interno del sistema operativo Boot2Gecko, ma molto di quel lavoro è stato trasferito al W3C per la standardizzazione. Oggi ci concentreremo su questo durante la nostra esplorazione di queste API e del potenziale che portano con sé per migliorare il modo in cui i nostri prodotti resistono alle condizioni di design del mondo reale e dell’ambiente.

Battery Status e Network Information#section2

Il responsive design ci ha risparmiato molti problemi, ma ci ha anche portato in primo piano nuove ed esaltanti questioni come l’asset management. Come gestiamo le immagini in maniera tale che si ridimensionino in ogni situazione, come ad esempio nel caso degli schermi piccoli o della banda limitata?

Se si trattasse semplicemente di una questione “i piccoli schermi ricevono piccole immagini”, il problema delle immagini responsive sarebbe praticamente risolto con l’elemento picture. Ma questo presume che ai piccoli schermi dovrebbero essere inviate immagini più piccole per accomodare la loro dimensione e le loro potenziali limitazioni di banda. Quello che cominciamo a realizzare, tuttavia, è che la dimensione di un display ha poco a che fare con la quantità di banda a disposizione.

In condizioni ottimali, tutti dovrebbero avere una connessione super-veloce con il 100% della batteria a disposizione. Più le persone usano i device mobile, è sempre più raro che ciò accada e sempre più spesso queste condizioni influenzeranno l’esperienza utente. Se un utente si trova casualmente a navigare su una connessione veloce, le immagini a bassa risoluzione non risulteranno nell’esperienza migliore. D’altro canto, se un utente ha una pessima connessione e poca durata della batteria a disposizione, il download di immagini enormi potrebbe lasciarlo senza telefono.

Sono situazioni come questa che rendono interessanti le API Battery Status e Network Information.

L’API Battery Status riporta il livello rimanente di batteria nel dispositivo, se il livello sta scendendo (si sta scaricando) o se il livello sta salendo (si sta ricaricando). Questa informazione non viene fornita solo come una descrizione sintetica al momento del caricamento, ma anche durante gli eventi che sono legati allo stato della batteria. Gli eventi che si trovano attualmente nella specifica includono: onchargingchange, onchargingtimechange, ondischargingtimechange e onlevelchange.

Tutto ciò diventa molto più interessante quando è accoppiato alla API Network Information, che vi permette di mettere sotto controllo l’informazione sulla banda di un device. Per come è attualmente scritta la draft, ritorna due informazioni: la velocità di connessione in MB al secondo e un valore booleano vero/falso che informa se la banda è regolata in qualche modo dall’ISP. Questa è tutta l’informazione di cui avete bisogno per filtrare gli asset e gestire la banda nel browser. Per tracciare quando un utente è offline, questa API può inoltre ritornare una connessione a 0.

Sebbene Network Information e Battery Status funzionino a meraviglia per conto proprio, la combinazione di queste due API ha il potenziale per aiutarvi non solo a gestire gli asset durante il caricamento iniziale della pagina, ma anche a modificare l’interfaccia man mano che cambiano nel tempo la connessione o lo stato della batteria. Potete anche fare dei test di energia per dare all’utente una stima su quando morirà la batteria nelle attuali condizioni (un po’ come i “km restanti” nell’auto). Non sarete in grado di avere informazioni specifiche come “Facebook sta succhiando la batteria”, ma saprete se c’è abbastanza energia per portare a termine un determinato task nella vostra applicazione.

Queste due API, e in particolar modo la combinazione delle due, saranno probabilmente le prime risorse con cui realizzare design meglio attrezzati per la gestione degli scenari del mondo reale. Ci permettono di rilevare i colli di bottiglia della performance e di realizzare un’esperienza attorno a questi (ricordate il problema della gestione delle immagini?). Tuttavia, c’è n’è un altro paio che si mette bene in evidenza nel gruppo: le API Ambient Light Sensor e Proximity Sensor, che portano l’esperienza un po’ al di fuori del browser.

Ambient Light Sensor#section3

L’API Ambient Light Sensor usa il sensore di luminosità di un device per darci informazioni sull’ambiente circostante. Ovviamente, la limitazione di questa API è che il device deve avere un sensore di luminosità, sia che la luce venga filtrata attraverso la fotocamera o attraverso un altro tipo di sensore. Non importa dove sia il sensore, purché esista. L’API funziona praticamente come Battery Status, ossia il livello di luminosità può essere catturato durante il caricamento iniziale e anche mediante un evento chiamato ondevicelight.

Questa API può apparire un po’ strana perché non usa un valore web normale come il pixel, la percentuale o gli em: l’API ritorna valori in unità lux (lx). Un’unità lux è una misura internazionale per l’intensità della luce, di sicuro non qualcosa che usiamo tipicamente sul web. In effetti, non avevo mai sentito parlare di lux prima di scoprire questa API, ma mi fa sentire super-intelligente quando ne parlo. Dal momento che è abbastanza innovativa, il supporto a livello di device per il valore lux è un po’ inaffidabile.

L’API Ambient Light Sensor migliorerà probabilmente l’esperienza di utilizzo di un e-reader, come ad esempio il Kindle, perché permette di accedere all’informazione riguardante la quantità di luce in una stanza. Con questa informazione, potete facilmente aggiustare i valori del colore, della tipografia o di altri elementi del design per fornire un’esperienza di lettura più confortevole.

Proximity Sensor#section4

L’API Proximity Sensor, che permette la comunicazione NFC (near field communication) dal browser, è probabilmente più lontana dalla nostra portata oggi, non perché la specifica sia rimasta indietro, quanto piuttosto perché la maggior parte dei device non dispone ancora dei sensori necessari. Un numero relativamente basso di smartphone contiene già ora la tecnologia NFC, e potrebbero volerci ancora un paio di release prima di vederlo in qualcosa come l’iPhone.

Se il device dell’utente contiene un sensore di prossimità, vi si può accedere per trovare gli oggetti con le informazioni NFC nelle vicinanze (fantastico, vero?). L’API contiene un evento chiamato ondeviceproximity, che viene lanciato quando un oggetto è nel range del sensore.

Il W3C non raccomanda di provare a misurare in maniera accurata la distanza di un oggetto a causa della volatilità dei sensori odierni, ma si possono comunque spingere i limiti della user experience solo con alcuni tasti rimuovendo sé stessi dall’ambiente limitante del browser e scatenando in un’interfaccia il mondo reale degli oggetti interattivi, della sensibilità alla luce, delle informazioni sulla connessione e del consumo di energia.

Insistere con l’environmental design#section5

L’environmental design sul web consiste semplicemente nel concetto di tenere presenti i fattori esterni, qualcosa di cui stiamo vedendo solo l’inizio con la Device API.

Ogni giorno abbiamo a disposizione nuove API che possiamo cominciare ad integrare nelle nostre applicazioni in maniera creativa, ma non dovremmo nemmeno sentirci limitati da queste. Sappiamo che un’esperienza non deve essere identica in tutti i browser, ma potrei anche aggiungere che non deve necessariamente essere la stessa in ogni stanza della vostra casa. Al cambiare delle connessioni, della durata della batteria e di altre situazioni, potrebbe anche cambiare l’esperienza che il vostro utente fa del vostro sito.

Avere a che fare con il caos dei browser è un lavoro a tempo pieno per la maggior parte di noi: è il motivo per cui esistono i test di quality assurance. La chiave per l’avanzamento del web e per la creazione di un’esperienza di successo è quella di abbracciare questo caos piuttosto che passare il tempo a combatterlo. Usare la pazzia a proprio vantaggio e fare sempre delle aggiunte alla cassetta degli attrezzi dell’UX assicurerà che noi tutti si lavori per far andare l’esperienza web nella giusta direzione.

Illustrazioni: {carlok}