Sì, quel progetto web dovrebbe essere una PWA

Sembra sia passata un’eternità da quando Frances Berriman ha coniato il termine “Progressive Web App” nel tentativo di descrivere una nuova classe di siti web. Ma c’è molta confusione su cosa sia esattamente una Progressive Web App (PWA), nonostante suo marito, Alex Russel, abbia messo insieme una pratica guida alle caratteristiche di una PWA e siano state oggetto di un mucchio di documentazione, dozzine di blog post e altrettante conference talk.

Nonostante ci siano così tanti contenuti accessibili e ben scritti sulle PWA disponibili gratuitamente, abbonda la disinformazione. Probabilmente vi sarete imbattuti in una o più affermazioni come queste:

• Se state creando una PWA, dovete usare un framework JavaScript.
• Per realizzare una PWA, cominciate con una single page app.
• Le PWA hanno senso solo per quelle “app” che gli utenti vogliono installare.
• Le PWA hanno senso solo nel mobile.
• Le PWA sono una cosa di Android.

Niente di tutto ciò è vero, ma come per molta disinformazione di questi tempi, ognuna contiene un briciolo di verità che è stata deformata in falsità. Se state prendendo in considerazione di creare una PWA, potreste usare un framework JavaScript o crearla come una app single page, ma non è affatto necessario. C’è un’opzione per creare una PWA esattamente come c’è un’opzione per ogni altra progetto web. Dopo tutto, ogni PWA è (o perlomeno dovrebbe essere) un sito web. Le PWA hanno solo alcune feature che permettono loro di fare più di quello che i siti web sono stati tradizionalmente in grado di fare… come installarli. Ma, in maniera simile, l’installazione non è la raison d’être di ogni PWA. E, mente molte delle prime PWA si focalizzavano sul mobile e funzionavano solo su Android, le PWA non sono più limitate solo ai device con piccoli schermi. Inoltre, sono anche più di una cosa di Google: Microsoft, Mozilla, Opera e Samsung sono tutti nella squadra. Apple ha dichiarato recentemente di aver intenzione di implementare Service Workers (uno dei pilastri tecnici delle PWA), ma solo il tempo dirà se supporteranno aspetti come l’installazione. Nessun problema, visto che le Progressive Web App funzionano comunque molto bene in Safari!

Purtroppo, una tale disinformazione ha convinto molti designer e developer (e i loro management team) che le PWA non sono appropriate per i loro progetti. Lo sono! Il vostro sito, ogni sito, dovrebbe essere una PWA. Questo approccio offre dei benefit per ogni progetto sul web, ma ci arrivo tra un minuto. Prima di ciò, voglio che siamo tutti sulla stessa pagina su quello che, esattamente, fa di una PWA una PWA. Se avete osservato da vicino per un po’ le PWA o se ne avete già realizzata una, potete scorrere rapidamente o saltare la prossima sezione. Se non avete una grande familiarità o se non pensate di aver capito bene cosa sono, non preoccupatevi, la prossima sezione è un’introduzione molto breve che vi farà partire in fretta.

Quindi, cos’è una PWA?#section1

Come ho detto prima, una PWA è un sito web con poteri speciali. Il termine “app” in “Progressive Web App” non è indicativo del tipo di contenuto o dell’esperienza che gli utenti dovrebbero aspettarsi con una PWA. Non dovreste concentrarvi su questo: “Progressive Web App” è un termine di marketing. Le PWA hanno l’abilità di connettersi al sistema operativo (e, quindi, ai suoi utenti) a un livello più profondo attraverso l’installazione e le API che offrono capacità come le notifiche, l’accesso alla rubrica contatti e molto altro. Non tutte queste API richiedono l’installazione per accedervi, ma alcune sì. Potrebbe essere utile pensare a una PWA come a un website++.

Cosa rende una PWA una PWA. Non molto, in realtà: ci sono solo tre requisiti:

1. Dovete usare HTTPS. Alle PWA si possono garantire un’ampia gamma di privilegi extra in un sistema operativo, quindi è essenziale che la connessione al web server sia sicura. Se vi serve aiuto in merito, potete guardare il servizio SSL gratuito Let’s Encrypt.
2. Vi serve un Web App Manifest. È molto meno spaventoso di come suona. È un file JSON con informazioni sul vostro sito. Potreste addirittura averne già uno scarno se avete usato un favicon generator. Assicuratevi di farvi riferimento usando un link nella head delle vostre pagine web così che browser e search spider possano trovarlo.
3. Vi serve un Service Worker. Probabilmente, questo è lo step più complicato, ma ci sono migliaia di guide passo a passo là fuori per creare Service Workers su misura per il tipo di lavoro che volete che facciano. Questa, di Mozilla, è particolarmente buona.

Questo è quanto. Una volta che avrete messo a posto queste cose, il vostro sito web sarà una Progressive Web App. Almeno tecnicamente. Perché queste condizioni? Beh, qui è dove le cose assumono più sfumature.

Nel 2015, quando il concetto di PWA fece il suo debutto, Alex Russell delineò dieci caratteristiche che le PWA condividevano (o di cui erano perlomeno capaci). La maggior parte di queste caratteristiche sono, senza dubbio, come si dovrebbe costruire per il web. Altre non sono così universali e non avrebbero senso in ogni tipo di progetto. Sospetto che questa potrebbe essere una delle fonti di confusione per le persone che considerano di adottare l’approccio PWA ed è la ragione per cui ho deciso di scrivere questo articolo.

Esperienze di qualità e benefici universali delle PWA#section2

Nelle sezioni successive, discuterò di vari archetipi di progetti web e del modo in cui adottare alcune di queste caratteristiche di PWA potrebbe dare benefici gli utenti. Dopo tutto, questo è proprio il motivo per cui lo facciamo. Ma prima di fare ciò, voglio discutere delle sette caratteristiche delle PWA che sono utili in ogni progetto web.

Come ho citato, ci sono delle caratteristiche delle PWA che forniranno assolutamente valore ai vostri utenti e che valgono il vostro tempo e la vostra considerazione. In effetti, tutte sono considerate best practice nel web design e development.

Primo, le PWA devono essere sicure. Come ho citato nella mia discussione sui loro requisiti tecnici, le PWA devono girare su HTTPS. Punto. Fortunatamente, il costo di far girare il vostro sito su HTTPS è sceso a zero. Ovviamente, ci sono legittime sfide nel convertire dei grandi siti web esistenti, ma ne vale la pena per moltissime ragioni. La prima è che protegge i vostri utenti dagli attacchi “man in the middle” fatti da ISP, negli hotel e negli aeroporti, da router infetti o da altri con accesso alla rete. HTTPS assicura che sia il codice sia il contenuto che mandate ai vostri utenti arrivino effettivamente intatti. Non è a prova di bomba, ma è un passo importante nel proteggere i vostri utenti e i vostri dati. Usare HTTPS è anche un prerequisito per accedere a molte delle più nuove (e più sensibili) API, incluse Geolocation e Service Workers e per tecnologie che migliorano le prestazioni come HTTP/2 e Brotli compression. Vale anche la pena notare che molti browser stanno cominciando a segnare i siti non HTTPS come “insicuri” e SSL influenza anche il search ranking.

Prima ho detto che le PWA non sono mai state intese come un approccio mobile-only. Le PWA sono per tutti. Mettere a disposizione di più persone su più device con sistemi operativi, capacità di browsing, API di sistema e dimensioni di schermo estremamente variabili farà solo aumentare il vostro ”reach” e creerà più opportunità per avere successo. Qui è dove entrano in gioco il progressive enhancement e il responsive design. Creando layout responsive, i vostri design si adatteranno a fornire il layout più appropriato data la quantità di schermo con cui dovete lavorare, sia che dipenda dalle dimensioni del device o dalla dimensione della finestra impostata dal vostro utente. Il progressive enhancement permette ai vostri progetti di adattarsi a una gamma di differenze ancora più ampia, sia nell’ambiente di esecuzione (device, OS, etc.) sia, soprattutto, ai vostri utenti.

Il progressive enhancement vi aiuta anche ad evitare situazioni in cui gli utenti non possono accedere ai vostri progetti perché usano un device o browser con cui non avete familiarità o su cui non avete fatto test. Assicura che il vostro sito funzioni su ogni device che possa accedere al web, indipendentemente dalle sue capacità, permettendovi di usare il vostro tempo prezioso per ottimizzare quell’esperienza per i browser e i device più moderni. È anche un approccio più economico sul lungo periodo.

Un’altra qualità che Alex ha identificato è che molte PWA sono simili ad app. Si noti il simile. Non sono app, ma piuttosto, forniscono esperienze simili alle app che agli utenti – posso dirlo? – piace usare. Più potete fare per fornire una user experience consistente, senza soluzione di continuità, senza sforzi (che è quello che in realtà significa ”simile ad app” qui), più sarà probabile che vediate visite che si ripetono, aumento delle vendite, etc.. Vale la pena notare che questo non implica che dobbiate usare JavaScript: significa solo che dovreste pensare al flusso che seguiranno i vostri utenti nel sito e che dovreste sfruttare ogni opportunità di rimuovere la frizione dal loro processo di raggiungimento dei loro obiettivi.

Se avete creato qualcosa, probabilmente volete che la gente lo trovi. Le PWA, per definizione, sono semplici da scoprire. Il contenuto del vostro sito dovrebbe essere scritto in maniera tale che appaia organicamente quando le persone cercano degli argomenti correlati. Non cedete allo spam ma abbiate cura di realizzare contenuti in maniera ponderata, appropriata e chiara.

In relazione con la discoverability c’è che le PWA sono ”linkabili”. Se i vostri utenti possono raggiungere un certo punto nel vostro sito attraverso la navigazione naturale, dovreste fare del vostro meglio per assicurarvi che possano salvare la loro posizione mettendola nei segnalibri o quando rilanciano il loro web browser e il tab del vostro sito viene riaperto. Questo ha anche un ruolo su quanto sia condivisibile il vostro progetto. Fatevi anche un favore e passate del tempo a mettere insieme alcuni meta tag Open Graph e dei JSON-LD per rendere ancora più condivisibile il vostro contenuto.

Ultima, ma di sicuro non meno importante, c’è la network independence. Questo è il grande aspetto che eccita gli sviluppatori. È da un po’ che le capacità offline e lo storage persistente sono, in una certa misura, possibili: diamine, Microsoft ha debuttato con il client-side data storage nel lontano 1999! Ahimé, mentre lo storage dei dati lato client —IndexedDB, localStorage, etc.— è decisamente maturato negli ultimi anni, il vero controllo del caching delle risorse è stato piuttosto terribile. Poi sono arrivati Service Workers e la Cache API. Queste due tecnologie lavorano in concorso con la Fetch API per fare, intercettare, aumentare e memorizzare richieste di risorse fatte dall’interno del vostro sito, il che significa che i vostri utenti possono ancora accedere al vostro contenuto anche se la connessione di rete è interrotta.

C’è una tonnellata di fantastiche risorse che coprono i dettagli di Service Workers, quindi salterò i dettagli tecnici e parlerò solo di alcune delle cose eccezionali che potete farci:

• Prefetch e cache delle risorse che sapete che serviranno ai vostri utenti. Questo migliora drasticamente la performance.
• Mettere in cache ogni pagina e asset richiesta dal vostro sito così che non debbano essere recuperati dal server ogni volta che viene caricata una nuova pagina. Questo migliora la performance durante la navigazione ma anche nelle visite di ritorno.
• Definire una pagina “offline” personalizzata. Questo evita che gli utenti vedano il messaggio generico del browser “Connessione assente”.
• Cercare prima una connessione di rete e fornire la copia “live” di una data risorsa se è disponibile, usando la versione “vecchia“ precedentemente messa in cache come fallback se non è disponibile. Anche questo può evitare che gli utenti vedano i messaggi “Connessione assente.
• Rispondere alle richieste per immagini JPEG con versioni WebP (che tendono ad essere considerevolmente più piccole) di quelle immagini se il browser le supporta. Questa strategia vi consente di fornire delle sorgenti di immagini alternative che migliorano la performance senza dover modificare il vostro markup.

Service Workers può fare molto di più (e in parte ne parlerò tra poco) e ed è probabile che gli vengano garantite molte feature più incredibili e utili in un futuro non troppo distante. Hanno già dato prova del loro valore e portano valore ad ogni progetto sul web. Per un’utile lista di ricette, date un’occhiata a questo cookbook di Mozilla o a questo del team di Chrome.

Altri vantaggi delle PWA per tipo di progetto#section3

Ora che abbiamo visto le qualità universalmente vantaggiose delle PWA, cambiamo marcia. Ogni progetto è diverso, ma c’è una manciata di archetipi in cui tende a ricadere la maggior parte dei progetti web. E ognuno di questi archetipi può trarre benefici reali dal girare come PWA.

Informativo#section4

Quando penso ai siti informativi, intendo quel tipo di siti a cui molti di noi del settore fa riferimento come “siti brochure“. I siti promozionali ne sono un buon esempio. Un altro esempio sono i siti di piccole aziende la cui interattività ha il suo culmine in una form di contatto o in un numero di telefono cliccabile. Anche i siti portfolio ricadono in questa categoria così come molti siti di ristoranti.

Nella maggior parte dei casi, progetti come questi esistono per servire gente che vuole saperne di più su di voi, sul vostro business, su un progetto o qualcosa di simile. Nella maggior parte dei casi, non vedranno una tonnellata di visite ripetute. La gente va sul sito cercando una specifica informazione, a cui si spera possano accedere rapidamente e semplicemente, per poi andarsene. Potrebbero tornare, ma anche no, quindi i miglioramenti di performance dati dal caching offline di Service Workers potrebbero essere utili, ma probabilmente non avranno quel livello di impatto che avrebbero su un sito che ha visite ripetute frequenti. È anche altamente improbabile, se non impossibile, che qualcuno installi effettivamente un progetto come questo.

A seconda del tipo di sito che state costruendo, potreste prendere in considerazione di integrare alcune device API. Se il sito è per un business del mondo reale, aggiungete il supporto per Geolocation. Se avete delle vendite o delle offerte speciali di cui vorreste informare i vostri visitatori, potreste considerare di integrare Notifications (Web o Push).

Sebbene due dei “maggiori“ vantaggi di essere una PWA (l’essere installabile e le capacità offline) sono meno applicabili ai siti informativi, rendere PWA progetti come questi ha ancora dei vantaggi. Quelli non sono che due aspetti dell’essere una PWA: i vostri utenti vi ringrazieranno per aver creato un sito che funziona su tutti i loro device, che è facile da usare, che risulta nelle ricerche e che è facilmente condivisibile con i propri amici.

Periodico#section5

I siti periodici comprendono tutto ciò che va dal blog alla newsletter, dal podcast ai fumetti online, ai magazine, ai quotidiani fino ai programmi video. Questa tipologia di progetti è come quella dei progetti informativi, con l’eccezione che vengono aggiornati regolarmente (o quasi regolarmente). Hanno anche un pubblico che presumibilmente ritornerà (ahem) periodicamente per leggere un nuovo articolo, guardare un nuovo video o ascoltare un nuovo episodio del podcast. Dal momento che condividono gran parte del loro DNA con i siti informativi – che diamine, un periodico può addirittura far parte di un sito informativo – tutte le qualità di cui beneficiano i siti informativi sono le stesse dei siti periodici. Ci sono tuttavia alcune capacità che le PWA offrono perfettamente adatte ai periodici.

Nel parlare di promozioni o offerte, ho detto che Push Notifications potrebbe essere un’opzione per i siti informativi. Per i siti periodici, dovrebbero essere un dato di fatto. Push Notifications fornisce un meccanismo per cui il server manda un update a ogni istanza del vostro Service Worker installato sulle macchine dei vostri utenti. E, presumendo che vi abbiano dato il permesso, questi aggiornamenti possono essere mostrati ai vostri utenti anche se non hanno installato la vostra PWA o non hanno un tab del browser aperto sul vostro sito.

Non prendetela come un’opportunità per spammare i vostri utenti, perché è molto probabile che perdereste la loro attenzione e il loro tempo. Al contrario, scegliete dei momenti appropriati per avvisarli. Se il vostro sito viene aggiornato solo una o due volte alla settimana, notificarli dei singoli post probabilmente va bene e può fornire un’alternativa carina per le persone che non usano un feed reader. Se avete aggiornamenti frequenti, considerate un avviso giornaliero o settimanale. Questo potrebbe addirittura essere un buon candidato per dei test A-B.

Potreste anche alzare il livello del gioco offrendo un facile tool ”in-page” per salvare un articolo per la lettura offline. Perché dovreste farlo invece che mettere tutto quello che l’utente vede in cache usando il Service Worker? Beh, data la natura di un periodico, la probabilità di riutilizzare un singolo pezzo di contenuto è piuttosto bassa. Se mettete in cache tutto quello che l’utente vede, specialmente se il vostro contenuto ha un sacco di immagini ad alta risoluzione, riempireste la loro cache con robe che potrebbero non visualizzare mai più. Per essere bravi cittadini del web, dovreste o ripulire regolarmente tenendo traccia dell’ultima volta a cui si è acceduto a una risorsa (il che, francamente, mi sembra un po’ troppo lavoro) oppure potreste mettere in cache giusto le risorse necessarie a vita lunga come i file CSS e JavaScript. Poi potreste dare il controllo ai vostri utenti dandogli un pulsante che gli permetta di salvare una entry per dopo.

Proseguendo il nostro viaggio nella terra di Service Worker, potremmo cominciare ad esplorare Background Sync per richiamare nuove risorse periodicamente. Se siete un quotidiano, forse volete preparare le cache dei vostri utenti ogni mattina con la prima pagina e le storie principali. Se siete un podcast, forse vorreste caricare l’episodio più nuovo a cadenza regolare. Di nuovo, per giocare come dei bravi bambini al parco giochi, probabilmente dovreste buttare gli articoli, episodi e simili più vecchi, e questo potrebbe essere un modo grandioso di dare un’esperienze incredibilmente veloce ai vostri utenti. Ma pensateci! Lanciano il vostro sito e il browser ha già tutto ciò di cui ha bisogno per rendere l’uscita di oggi. Magia!

Infine, i periodici sono uno di quegli archetipi per cui comincia ad avere senso l’opzione di installare il sito. Ad alcune persone piace poter toccare un’icona sul loro home screen o nello Start Menu per accedere al giornale locale. Non è per tutti e potrebbe non andare bene per tutti i periodici, ma è un’opzione. E offrire agli utenti la possibilità di installare la PWA è gratis, quindi potreste adottare questa opzione ed assicurarvi che il vostro Web App Manifest sia stato creato con attenzione per dare una buona user experience quando la vostra PWA è installata.

Transazionale#section6

Ogni sito che facilita lo scambio di informazioni dovrebbe essere considerato transazionale. Gli esempi più comuni includono i negozi online, banche e strumenti per trading, sistemi di prenotazione di viaggi e portali di pagamento. Le PWA hanno, in gran parte, già provato il loro valore in quest’area. Una rapida occhiata su PWA Stats ha rivelato le seguenti “vittorie“:

• The Raphael Hotels ha aumentato le website conversion del 20%, le pageview del 66%, le sessioni del 59% e ha ridotto il bounce rate al 51%.
• MakeMyTrip ha visto un aumento di tre volte nelle conversion e una crescita del 160% nelle shopper session ed è tre volte più probabile che gli shopper che visitano per la prima volta convertano sulla PWA rispetto alla app nativa.
• Lancôme ha visto una crescita del 17% nelle conversion, un aumento del 51% nelle sessioni mobile in generale e un aumento del 53% solo su iOS.

Il colpo di scena dell’ultimo? iOS non supporta nemmeno Service Workers!

È noto che migliorare la performance sulle pagine faccia aumentare le conversion, quindi i miglioramenti di velocità garantiti da un caching smart e da una strategia offline con Service Workers sono incredibilmente importanti qui. Ma ci sono anche numerosi altri modi in cui le PWA possono portare benefici ai siti transazionali.

Dal momento che ho menzionato l’offline, aggiungerò che la vostra strategia per l’offline non dovrebbe ridursi a Service Workers. Per un certo tempo ormai, abbiamo usato i cookie per tracciare i dati transazionali del contenuto del carrello, ma i cookie sono sempre stati severamente limitati in termini di quantità di dati che possono memorizzare perché vengono inviati con ogni network request. Con IndexedDB, localStorage e sessionStorage, abbiamo la capacità di memorizzare più dati (e più ricchi) sulla transazione in corso lato client. Memorizzare questa informazione sul client rende più semplice recuperare da problemi quali la perdita di rete. Se una transazione fallisce, avrete ancora accesso ai dati (che in caso contrario potrebbero essere andati persi in un POST fallito) e potete anche provare di nuovo la transazione periodicamente o aspettare finché vedete che la rete è tornata prima di inviarla. In ogni caso, aggiungere dei messaggi in real time su cosa sta succedendo e in che modo state lavorando per risolverlo sarà di grande aiuto per rassicurare i vostri utenti che i loro dati non sono andati persi.

Se il vostro progetto è altamente transazionale, dovete sicuramente prendere in considerazione Background Sync come mezzo per tenere i dati locali dei vostri utenti sincronizzati con i dati sul server. Per esempio, se state creando un sistema di banking, sarà incredibilmente utile per i vostri clienti sincronizzare le informazioni come le transazioni recenti e il saldo corrente. Lo stesso vale per i prezzi attuali dello stock market e il saldo se state lavorando ad una piattaforma di trading.

Nella maggior parte degli scenari transactional, le notifiche possono essere piuttosto utili. Prendendo in prestito dallo scenario che ho citato prima, le notifiche possono essere usate per far sapere a qualcuno quando la loro transazione è stata completata (dopo tutto, in una PWA potreste completare la transazione durante un Background Sync quando il vostro sito non gira). Le notifiche sono di due tipi: le Web Notifications vengono fatte partire con JavaScript in una pagina attiva, le Push Notifications vengono inviate dal server e possono essere inviate anche quando il sito non è aperto. A seconda dello scenario, è probabile che avrà più senso un tipo piuttosto che l’altro. Prestate solo attenzione al fatto che le Push Notifications non sono così ben supportate quanto le Web Notifications… Per il momento.

Per i siti transazionali a cui si accede frequentemente (e mi rendo conto che “frequentemente“ è un termine molto relativo) l’installabilità di una PWA è un’enorme vittoria. Isolare il vostro sito all’interno del suo app container permette agli utenti di concentrarsi sul task che hanno sotto mano, senza la distrazione di altri tab. Isola anche i processi che fanno girare il vostro codice dai processi che fanno girare tutti i siti che hanno aperti nel browser. Inoltre, ha meno overhead dal momento che non c’è una chrome del browser che gira contemporaneamente. Tutti questi benefit contribuiscono alla creazione di un’esperienza semplificata, senza attriti, per gli utenti.

Una volta installata, molti sistemi operativi garantiranno al vostro progetto l’accesso alle API interne. Magari volete permettere che scelgano dai loro contatti un indirizzo a cui spedire un regalo. O magari vorreste dar loro la possibilità di aggiungere i voli che hanno appena prenotato direttamente al loro calendario. O magari volete integrare il loro assistente virtuale così che l’app abbia delle capacità vocali. Tutti questi scenari diventano possibili nel contesto di una PWA, che è una manna per i siti web transazionali.

Social#section7

I siti web social — pensate a Twitter, Facebook, etc. — sono dei candidati eccellenti per la PWA-ficazione. In effetti, Twitter ha già intrapreso questa strada. I siti social combinano aspetti dei siti periodici e transazionali, quindi ereditano naturalmente molti dei benefit di quegli archetipi. In particolare, le Push Notifications, sono incredibilmente importanti per siti come questo, dal momento che il re-engagement è cruciale per il successo a lungo termine della vostra piattaforma. Sotto questo aspetto è importante anche l’installabilità.

La performance, specialmente la velocità di inizializzazione, sarà un importante benchmark per i progetti social, dal momento che gli utenti non staranno ad aspettare che tutti gli item del loro feed (con le relative immagini, video, etc.) si carichino. Mettere in cache gli asset del vostro sito aiuterà un po’, ma, a seconda degli obiettivi del vostro progetto e della vostra situazione, potreste prendere in considerazione l’utilizzo di Background Sync per aggiornare i news feed dei vostri utenti così che siano pronti a partire (o quasi) la volta successiva che lo riaprono.

In qualità di progetti transazionali, i siti web social trarranno beneficio anche dall’accesso a device e API di sistema una volta installati. La maggior parte dei social network, per esempio, richiede il permesso di accedere ai vostri Contatti per cercare amici e colleghi che stanno già usando il servizio. Se scegliete questa strada è imperativo che non abusiate del privilegio cercando di ingannare i vostri utenti spammando i loro amici con informazioni sul vostro servizio. Se non rispettiamo i nostri utenti e le loro informazioni private, corriamo il rischio di perdervi accesso completamente (e di perdere anche gli utenti).

Software#section8

Quando parliamo di “web app“, spesso quello che viene in mente naturalmente è il software online. Alcuni esempi includono i client di email, gli strumenti di contabilità, le suite di project management, i sistemi di version control e gli editor di foto. In molti modi, questi sono software nel senso tradizionale, solo che esistono sul web invece che essere installati localmente… Finora.

Attraverso la magia delle PWA, questi progetti “software as a service” possono diventare applicazioni desktop (e mobile) a pieno titolo. Questo permette ai team che si sono dedicati completamente alle tecnologie web di continuare (o addirittura aumentare il loro investimento in quell’area senza sacrificare la comodità dell’installabilità sulle piattaforme native. Ovviamente, ci sono assolutamente alcune valide ragioni perché potreste voler personalizzare un’esperienza nativa per il vostro software, ma per la stragrande maggioranza dei casi il web offre tutto il necessario per far girare la vostra applicazione… Questa è la primissima ragione per cui si trova sul web.

La memorizzazione dei dati offline, la sincronizzazione in background e l’accesso al file system aiuta a elevare l’esperienza per i vostri utenti, rendendo questo archetipo il beneficiario più ovvio dalle Progressive Web App.

Istituzionale#section9

Alcuni progetti sono, francamente, troppo estesi per ricadere perfettamente in un archetipo o in un altro. Sto pensando a scuole, grandi aziende, istituzioni finanziarie mastodontiche. Questi progetti sono spesso un’amalgama di molti o di tutti gli archetipi che ho coperto qui. Come tali, hanno tutti i benefici discussi da quegli archetipi, nel loro contesto ovviamente.

Quando osserviamo i grandi progetti istituzionali, può essere difficile capire come assemblare una strategia complessiva per farli diventare PWA. La buona notizia è che non dovete necessariamente farlo. Potete ritagliare il vostro progetto in molte PWA individuali che possono esistere indipendentemente.

Prendete, per esempio, un sistema di apprendimento online. Potreste creare una PWA per il learning system stesso, ma potreste anche ritagliare ogni singolo corso nella sua PWA installabile, con la sua cache, le sue notifiche, etc. Ha senso farlo perché Service Workers e i Web App Manifest possono avere un loro scope. Potete tenerli raggruppati sotto uno specifico hostname oppure potreste anche assegnare loro un percorso specifico all’interno della vostra struttura URL. Anche se ovviamente è più complesso, diventa più semplice da comprendere se pensate a ognuno di quei corsi come ad un template e pensate al Web App Manifest e Service Worker come facenti parte di quel template.

Tocca a voi#section10

Le Progressive Web App potrebbero sembrare eccessivamente tecniche o al di fuori dei bisogni del vostro progetto ma in realtà non lo sono. Sono solo una scorciatoia per esperienze web di qualità, esperienze che possono assolutamente fare una differenza nella vita dei nostri utenti. Se non avete ancora preso in considerazione di realizzare una PWA, spero che questo articolo vi abbia fatto cambiare idea. E se siete già immersi fino al collo in Service Workers, magari vi ha fatto venire delle idee per nuovi modi di affrontare i progetti a cui state lavorando.