{"id":345,"date":"2013-03-04T11:13:06","date_gmt":"2013-03-04T10:13:06","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/environmental-design-con-la-device-api\/"},"modified":"2013-03-04T11:13:06","modified_gmt":"2013-03-04T10:13:06","slug":"environmental-design-con-la-device-api","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/environmental-design-con-la-device-api\/","title":{"rendered":"Environmental design con la Device API"},"content":{"rendered":"

Se anche voi vi siete seduti su una sedia tenendo in alto il telefono per ricevere un segnale migliore o se avete fatto il refresh di una pagina bloccata per 30 secondi, allora sapete gi\u00e0 che le esperienze utente di oggi hanno un immenso buco. Passiamo migliaia di ore a realizzare interfacce che sono il risultato di infinite conversazioni, test con gli utenti e dati statistici accumulatisi davanti ai nostri (virtuali) occhi, solo per vedere poi la nostra esperienza penalizzata da un segnale poco potente.<\/p>\n

Forse l’utente \u00e8 passato dal 3G al WiFi. Forse ha poca batteria. O forse fuori \u00e8 buio. Qualunque sia lo scenario, i fattori della vita reale possono facilmente rovinare le vostre migliori intenzioni, con il risultato che gli utenti saranno frustrati e arrabbiati.<\/p>\n

Non \u00e8 nuovo il concetto di prendere in considerazione i fattori del mondo reale durante la progettazione: possiamo trovare tracce dell’environmental design<\/a> almeno nel 500 a.C., quando gli antichi Greci cominciarono a creare case riscaldate con l’energia solare. Si basa su due semplici verit\u00e0: il mondo reale esiste e non lo si pu\u00f2 controllare.<\/p>\n

Non si possono controllare tutti i fattori quando un utente interagisce con il nostro design, ma si pu\u00f2 certamente pianificare cosa fare quando si presentano certe situazioni semplicemente ammettendo che esistono. Le definisco condizioni di design<\/em>. Alcune condizioni di design, come il device che una persona utilizza, rimangono invariati per una singola visita o interazione con il nostro prodotto. Ma altre condizioni di design, come il consumo dell’energia, la luce e la potenza del segnale, potenzialmente possono (e hanno la tendenza a) cambiare durante il corso di una singola visita o anche tra un page load e l’altro.<\/p>\n

Solo un anno fa, non avrei avuto molte risposte a questi problemi di user experience perch\u00e9 le necessarie API a livello di device non erano ancora pronte. Ma oggi, possiamo cominciare a fare qualcosa per migliorare le esperienze degli utenti, perfino sotto queste condizioni dinamiche, grazie al recente lancio della Device API<\/a>.<\/p>\n

\n

Cos’\u00e8 la Device API?<\/h2>\n

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

Alcune API sono rimaste confinate all’interno del sistema operativo Boot2Gecko, ma molto di quel lavoro \u00e8 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\u00e9 per migliorare il modo in cui i nostri prodotti resistono alle condizioni di design del mondo reale e dell’ambiente.<\/p>\n<\/div>\n

\n

Battery Status e Network Information<\/h2>\n

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?<\/p>\n

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

In condizioni ottimali, tutti dovrebbero avere una connessione super-veloce con il 100% della batteria a disposizione. Pi\u00f9 le persone usano i device mobile, \u00e8 sempre pi\u00f9 raro che ci\u00f2 accada e sempre pi\u00f9 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.<\/p>\n

Sono situazioni come questa che rendono interessanti le API Battery Status<\/a> e Network Information<\/a>.<\/p>\n

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<\/code>, onchargingtimechange<\/code>, ondischargingtimechange<\/code> e onlevelchange<\/code>.<\/p>\n

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

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\u00e0 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’\u00e8 abbastanza energia per portare a termine un determinato task nella vostra applicazione.<\/p>\n

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’\u00e8 n’\u00e8 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.<\/p>\n<\/div>\n

\n

Ambient Light Sensor<\/h2>\n

L’API Ambient Light Sensor<\/a> usa il sensore di luminosit\u00e0 di un device per darci informazioni sull’ambiente circostante. Ovviamente, la limitazione di questa API \u00e8 che il device deve avere un sensore di luminosit\u00e0<\/a>, sia che la luce venga filtrata attraverso la fotocamera o attraverso un altro tipo di sensore. Non importa dove sia il sensore, purch\u00e9 esista. L’API funziona praticamente come Battery Status, ossia il livello di luminosit\u00e0 pu\u00f2 essere catturato durante il caricamento iniziale e anche mediante un evento chiamato ondevicelight<\/code>.<\/p>\n

Questa API pu\u00f2 apparire un po’ strana perch\u00e9 non usa un valore web normale come il pixel, la percentuale o gli em<\/code>: l’API ritorna valori in unit\u00e0 lux (lx<\/code>). Un’unit\u00e0 lux \u00e8 una misura internazionale per l’intensit\u00e0 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 \u00e8 abbastanza innovativa, il supporto a livello di device per il valore lux \u00e8 un po’ inaffidabile.<\/p>\n

L’API Ambient Light Sensor migliorer\u00e0 probabilmente l’esperienza di utilizzo di un e-reader, come ad esempio il Kindle, perch\u00e9 permette di accedere all’informazione riguardante la quantit\u00e0 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\u00f9 confortevole.<\/p>\n<\/div>\n

\n

Proximity Sensor<\/h2>\n

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

Se il device dell’utente contiene un sensore di prossimit\u00e0, vi si pu\u00f2 accedere per trovare gli oggetti con le informazioni NFC nelle vicinanze (fantastico, vero?). L’API contiene un evento chiamato ondeviceproximity<\/code>, che viene lanciato quando un oggetto \u00e8 nel range del sensore.<\/p>\n

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

\n

Insistere con l’environmental design<\/h2>\n

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.<\/p>\n

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.<\/p>\n

Avere a che fare con il caos dei browser \u00e8 un lavoro a tempo pieno per la maggior parte di noi: \u00e8 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 \u00e8 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\u00e0 che noi tutti si lavori per far andare l’esperienza web nella giusta direzione.<\/p>\n

Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Alcuni fattori del mondo reale come le batterie scariche e il segnale scarso possono far diventare un incubo anche un’eccellente esperienza digitale. Questi fattori esulano dal nostro controllo e, fino a poco tempo fa, non c’era nulla che potessimo fare, mentre adesso potrebbe esserci. Tim Wright ci spiega in che modo migliorare le esperienze utente in condizioni che cambiano costantemente (e che a volta sono orribili), riflettendo sull’environmental design e sulle Device API.<\/p>\n","protected":false},"author":818,"featured_media":7000689,"comment_status":"open","ping_status":"open","template":"","categories":[269,270,279,271,273,84],"tags":[],"coauthors":[386],"class_list":["post-345","article","type-article","status-publish","has-post-thumbnail","hentry","category-application-development","category-il-server-side","category-interaction-design","category-javascript","category-mobile-multidevice","category-numero-69-5-marzo-2013"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/345","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=345"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000689"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=345"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=345"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=345"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=345"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}