{"id":427,"date":"2014-01-04T12:07:03","date_gmt":"2014-01-04T11:07:03","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/progettare-web-app-offline-first\/"},"modified":"2014-01-04T12:07:03","modified_gmt":"2014-01-04T11:07:03","slug":"progettare-web-app-offline-first","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/progettare-web-app-offline-first\/","title":{"rendered":"Progettare Web App Offline-first"},"content":{"rendered":"
\n

Quando si tratta di creare delle app, spesso supponiamo che i nostri utenti siano molto simili a noi. Ce li immaginiamo con i device pi\u00f9 recenti, con software sempre aggiornato e con le connessioni pi\u00f9 rapide. Nonostante noi manteniamo un autentico zoo di vecchi dispositivi e vecchi browser per i test, passiamo la maggior parte del tempo a sviluppare dal comfort dei nostri device desktop moderni e sempre connessi.<\/p>\n

Per noi, una connessione che salta o un servizio lento \u00e8 un problema temporaneo che scaturisce in niente di pi\u00f9 di un semplice messaggio d’errore. Da questa prospettiva, c’\u00e8 la tentazione di pensare alla connettivit\u00e0, al mobile o ad altro come a qualcosa che si risolver\u00e0 da s\u00e9 nel tempo, man mano che aumentiamo la copertura di rete e acquistiamo servizi pi\u00f9 veloci. E questo funziona, fintanto che i nostri utenti rimangono sopra al livello del suolo in grandi citt\u00e0, ben sviluppate ma non troppo affollate.<\/p>\n

Ma cosa succede una volta che scendono nella metropolitana, quando si imbarcano su un aereo, si spostano sulla terraferma o vanno in campagna? Oppure quando sono nell’angolo sbagliato della stanza o semplicemente si trovano in mezzo a una grande folla? Le app experience che creiamo cos\u00ec attentamente diventano fonte di frustrazione, perch\u00e9 facciamo completo affidamento su quel collegamento effimero verso i server.<\/p>\n

Questa dipendenza ignora una verit\u00e0 fondamentale: essere offline succede. Se usate un dispositivo mobile, a un certo punto vi troverete offline. Comunque, va bene, ci sono dei modi per gestire questa situazione.<\/p>\n<\/div>\n

\n

Facciamo il punto della situazione<\/h2>\n

Una volta le web app erano completamente dipendenti dal server: faceva tutto il lavoro e il client mostrava semplicemente il risultato. Ogni interruzione della connessione era un problema enorme: una volta offline, non si poteva usare l’app.<\/p>\n

Quel problema \u00e8 parzialmente risolto con dei client pi\u00f9 capaci, in cui la maggior parte della logica dell’applicazione gira nel browser, come ad esempio Google Docs. Ma, per un’appropriata esperienza offline-first, sarebbe il caso di memorizzare i dati nel front end e dovreste sincronizzarli con i dati memorizzati sul server. Fortunatamente, i database in-browser stanno maturando e c’\u00e8 un numero crescente di soluzioni per gestirli, come derby.js<\/a>, Lawnchair<\/a>, Hoodie<\/a>, Firebase<\/a>, remotestorage.io<\/a>, Sencha touch<\/a> e altri, quindi risolvere gli aspetti tecnici sta diventando pi\u00f9 semplici.<\/p>\n

Ma abbiamo un problema pi\u00f9 grosso e pi\u00f9 strano da gestire: progettare app e relative interfacce per una connessione intermittente porta ad un’abbondanza di scenari e problemi.<\/p>\n

Ovviamente, ci sono alcuni precedenti di UX offline-first e uno di questi \u00e8 particolarmente diffuso: l’inbox e l’outbox dell’email. Le email finiscono nella outbox, anche quando si \u00e8 offline. Una volta che si ritorna online, vengono spedite. \u00c8 semplice, discreto e funziona.<\/p>\n

Per le email in arrivo, l’esperienza \u00e8 altrettanto delicata: una volta che vi ricollegate, le nuove email provenienti dal server appaiono in cima alla inbox. Nel frattempo, avete una copia locale pi\u00f9 o meno completa di tutte le email fino a quel punto, cos\u00ec da non essere bloccati in un’app vuota. Tutti e tre gli scenari (non funziona il “client push”, il “client pull\/server push” non funziona, non c’\u00e8 disponibilit\u00e0 dei dati locali quando offline) sono ben gestiti.<\/p>\n

Le email risultano essere semplici. Sono non editabili, facilmente elencabili, basate sul testo e “conflict-free”. La nozione di averne delle copie locali \u00e8 gi\u00e0 ben salda tra gli utilizzatori di email. Ma ci sono moltissime altre possibilit\u00e0. Come gestiamo questi scenari, ad esempio, in una app di disegno collaborativo? Cosa succede se abbiamo da gestire oggetti che non sono immutabili come le email, ma marker delle mappe con degli attributi che cambiano, tracce midi, problemi, task o azioni? Il browser \u00e8 il nuovo ambiente di runtime dell’applicazione e se prendiamo in considerazione la legge di Atwood<\/a> (“Ogni applicazione che pu\u00f2 essere scritta in JavaScript alla fine verr\u00e0 scritta in JavaScript”), quali altre cose mai sentite prima faremo nel browser in un paio d’anni? Vogliamo ancora trattare l’offline come un caso limite e ricorrere alle feature che non funzionano, ai template cos\u00ec fastidiosamente vuoti e ai messaggi di errore da panico?<\/p>\n

L’esperienza dell’utilizzo di un sito web o di un’app quando si \u00e8 offline dovrebbe essere migliore, meno frustrante e che dia pi\u00f9 possibilit\u00e0. Abbiamo bisogno dell’equivalente UX del responsive web design: un robusto catalogo di guide e pattern per il mondo disconnesso del multi-device.<\/p>\n<\/div>\n

\n

Il ciclo di vita della connettivit\u00e0<\/h2>\n

La maggior parte delle web app ha due punti di fallimento correlati alla connettivit\u00e0: “client push” e “client pull\/server push”. A seconda di quello che fa l’app, dovrete:<\/p>\n