Il design reattivo non è sufficiente, abbiamo bisogno di prestazioni reattive

Di recente mi sono imbattuto in molti siti Web reattivi con molti problemi di prestazioni. Sulla maggior parte di essi, i problemi sono così evidenti che sono quasi inutili su qualsiasi cosa oltre all'ultima generazione di smartphone. Considerando il fatto che la reattività come concetto è destinata a raggiungere un pubblico più ampio, ciò sembra piuttosto controproducente.

Il maggior contributo a questo problema è il paradigma di progettazione desktop-first ancora prevalente. Pensare dal punto di vista del mobile-first sembra risolvere il problema, ma questo da solo non garantisce prestazioni soddisfacenti. Sembra che tutti noi facciamo troppo affidamento su una degradazione più o meno aggraziata. Facciamo affidamento su spessori e polyfill per abilitare la funzionalità mancante. Facciamo affidamento sulle librerie per consentire uno sviluppo rapido e per avere le spalle quando la compatibilità del browser è un problema.

"Perché preoccuparsi?" potresti chiedere. “La maggior parte dei nostri visitatori ha smartphone ad alte prestazioni con le ultime versioni del sistema operativo. Possono gestire i nostri siti. Ce lo dicono gli analytics".

Mi dispiace per l'argomento dell'uomo di paglia, ma penso che meriti di affermare ad alta voce che le persone che possono utilizzare il tuo sito saranno la maggior parte dei tuoi utenti. Se non vedi Android 2.3 nelle tue analisi, significa che non ci sono utenti con quei dispositivi? O significa che il tuo sito non ha nulla da offrire a quegli utenti? Considera che molti dispositivi di quella generazione sono ancora sugli scaffali, acquistati nuovi di zecca anche oggi. Non dovresti liquidarla come una tecnologia del passato.

Pertanto, vorrei parlare dei casi ideali e degli obiettivi reali dello sviluppo web. E su pratiche e paradigmi che ci avvicinano a quegli obiettivi.

Il paradigma del design Brick-First

Una parte significativa delle vendite annuali di telefoni è ancora occupata dai feature phone. Una porzione ancora più ampia della popolazione non acquista telefoni ogni anno, ma possiede comunque qualche dispositivo compatibile con il web. A questi numeri si aggiungono gli smartphone di ultima generazione ancora in uso, si aggiungono i kindle e altri dispositivi web semi-abilitati (dispositivi WAP, TV, tostapane, t-shirt e brick). Sommali tutti e potresti raggiungere una somma sbalorditiva.

Considera i casi d'uso per questo pubblico. Non leggeranno lunghi articoli, navigheranno e ricercheranno sui loro dispositivi. Ma potrebbero passare attraverso l'orrore di provare a digitare un URL sulla tastiera numerica e navigare nella pagina utilizzando i tasti direzionali per raggiungere un numero di telefono o ricontrollare un indirizzo al volo.

Quanto è difficile quindi per noi implementare un layout sub-mobile first che fornisca solo quelle informazioni ai dispositivi al di sotto di una certa soglia di capacità e prestazioni?

Miglioramento grazioso

Con il degrado grazioso come best practice minima, abbiamo creato un principio onnicomprensivo che (in una certa misura) ostacola il pensiero al di là di esso. Una volta che il grazioso degrado è a posto, possiamo sicuramente dire che il nostro lavoro è fatto e ben fatto. Sempre più spesso non dobbiamo nemmeno pensarci in quanto è già coperto dai vari framework e librerie in uso. Infine, i polyfill e gli spessori eliminano completamente la necessità di un degrado della funzionalità in alcuni casi.

Man mano che questa funzionalità diventa sempre più prontamente disponibile, la necessità di pensarci (per non parlare di oltre) diventa sempre più remota.

Dal punto di vista di questo articolo potrebbe essere suddiviso in questo modo:

Degrado sgraziato: se una funzionalità non è prontamente disponibile, l'implementazione non riesce in modo tale da diventare inutilizzabile o utilizzabile in modo proibitivo.

Grazioso degrado: se una funzionalità non è prontamente disponibile, fallisce in un modo che consente comunque un'usabilità accettabile.

Miglioramento sgraziato: se la funzione non è prontamente disponibile, viene emulata da un polyfill o da uno spessore.

Ecco, problema risolto.

Bene, a meno che non si considerino le prestazioni di quegli stessi dispositivi di fascia bassa.

Non avendo la potenza di elaborazione e le capacità di dati dei loro fratelli più piccoli, viene loro chiesto di portare un carico molto maggiore. Prendere i polyfill come soluzione crea l'illusione che tutte le funzionalità moderne siano ora disponibili su tutti i dispositivi e possano essere utilizzate senza preoccupazioni.

E quindi implementi modernzr e polyfill tutto per ogni evenienza. Il dispositivo meno competente finisce per caricare la maggior quantità di dati ed eseguire la maggior quantità di elaborazione. Assicurando così la "migliore" esperienza per l'utente finale.

L'idea di un miglioramento graduale invertirebbe il concetto iniziando con i requisiti di funzionalità più bassi e caricando gli aggiornamenti fino a quando il rapporto prestazioni-usabilità non sarà ottimale in base alle capacità del dispositivo. In questo modo il traffico dati e le esigenze di elaborazione verrebbero spostati sui dispositivi più adatti a gestirli.

Certo, al momento il concetto è proibitivamente complesso: non è supportato dalla maggior parte dei framework e delle biblioteche, è per lo più indiscusso e i riferimenti a tali pratiche sono pochi, distanti e localizzati a micro-funzionalità. Ma ad un certo punto è stato così con tutti i concetti e le funzionalità.

Può, ma deve?

Un'altra best practice per lo sviluppo Web è verificare se una funzionalità è disponibile su un dispositivo prima di attivarla.

Tuttavia, tieni presente che puoi installare l'ultima versione di Google Chrome sul tuo telefono Android vecchio di anni e affermerà che può eseguire animazioni CSS, WebGL, effetti di parallasse in background e molte altre funzionalità. Ma davvero, davvero , non può. Tanto che il browser andrà in crash e l'intero dispositivo non risponderà al punto che dovrà essere riavviato per riprendere il controllo.

Questo problema ha recentemente iniziato a interessare le applicazioni Android in grande stile (dal punto di vista dell'utente). Uno dei degradi più evidenti in questo senso ha interessato l'aggiornamento dell'app Google Talk/Hangouts che ha trasformato il loro servizio dall'applicazione di chat più leggera disponibile a un'applicazione quasi inutilizzabile a causa di problemi di prestazioni sui dispositivi meno recenti. (Solo per sottolineare ancora una volta questo punto: "più vecchio" qui significa che puoi ancora acquistarlo pronto, nuovo di zecca in quasi tutti i negozi). Lo stesso problema riguardava l'app YouTube e l'app Twitter (secondo la mia esperienza) e apparentemente molti altri.

Quindi, prenditi un momento durante la tua fase di pianificazione per valutare il valore di una caratteristica principale ad alte prestazioni rispetto a un trucco all'avanguardia. O almeno lascia l'ultima generazione della tua app/servizio/contenuto disponibile in qualche forma per gli utenti legacy. A proposito…

Consenti agli utenti di rinunciare al Bleeding Edge

Ti sei mai trovato a provare a utilizzare Gmail da un vecchio dispositivo o con una connessione scadente? Quel link "carica HTML di base" è sicuramente utile.

Perché la tua vetrina online all'avanguardia, reattiva, animata e orientata al tocco non ha questa funzionalità?

Pensaci: hai richiesto che fosse responsive in modo da poter raggiungere più potenziali clienti. L'hai fatto all'avanguardia per lasciare la migliore prima impressione. E di conseguenza, meno potenziali clienti possono raggiungere anche le informazioni di base su di te e sui tuoi servizi. Se il miglioramento grazioso è un concetto troppo costoso per te, perché non offri almeno ai tuoi visitatori la possibilità di accedere a una versione di solo testo dei tuoi contenuti se la versione "WOW" è troppo per i loro dispositivi.

Hai davvero bisogno dell'intera libreria?

Infine, l'ultima best practice che mi piacerebbe vedere spinta un po' oltre lo standard è "usarla o perderla". Tenere traccia di quali librerie e moduli sono effettivamente in uso e includerli solo a volte è noioso, ma mantenere l'intero set di strumenti su ogni pagina è semplicemente sciatto.

Di recente, ho iniziato a tenere traccia di quante funzionalità utilizzo effettivamente una volta inclusa una libreria. E lo strumento che uso più spesso è jQuery. Spesso mi accorgo di aver usato solo una o due funzionalità (come $.extend o $.ready), o peggio ancora, che l'ho usato solo per ottenere elementi per classe o ID. A volte lo lascio così, altre volte torno indietro nel codice per rimuovere o disaccoppiare la dipendenza.

Non sarebbe bello se potessi analizzare automaticamente cosa e quanto di una libreria è stata utilizzata e perdere peso in base ai risultati?

Molte librerie e applicazioni offrono la possibilità di personalizzare il caricamento prima di iniziare a usarlo. Ma continuo ad avere la sensazione che non dovrebbe essere troppo fuori dalla nostra portata standardizzare un'architettura di build automatizzata "usalo o perdilo" nelle nostre librerie.

Ho un'allergia per l'approccio "includi tutto". Ma usarlo insieme a una tale funzionalità potrebbe trasformare l'approccio in qualcosa di simile a una scheda di prototipazione: uno strumento di sviluppo eccessivamente flessibile che viene minimizzato non solo nella sintassi, ma nella funzionalità stessa.

Ciò che sarebbe richiesto è una versione della libreria di solo sviluppo che, attraverso un test unitario della funzionalità dipendente, consenta il tracciamento delle funzionalità utilizzate e l'output della dipendenza minima o almeno della scala di utilizzo (come chiedere se ho incluso jQuery per l'8% della sua funzionalità o l'80%). L'output delle dipendenze può quindi essere utilizzato per selezionare, aggregare e ridurre al minimo l'output per la produzione.

Ma cosa posso fare al riguardo?

Prima di tutto, affronta il problema . Pensaci, discuti con i tuoi colleghi e cerca di individuare il problema in scenari del mondo reale.

Provalo. Tira fuori quel telefono di ultima generazione che hai nascosto in un cassetto da qualche parte. Prova a usarlo sui tuoi siti Web e controlla se il contenuto è utilizzabile anche da remoto. Vai a trovare alcuni parenti indietro nel tempo nel paese e prova a essere un evangelista tecnologico per loro. Verifica se il loro ritardo nell'adozione della tecnologia è effettivamente facilitato da problemi di accessibilità.

Se sei un acquirente che commissiona un sito web, assicurati di chiedere (almeno) un supporto di basso livello su questo problema. Ricorda: l'obiettivo non è creare un port completo di tutte le tue funzionalità su dispositivi di basso livello. Tutto ciò che viene chiesto è che quegli utenti ottengano le tue informazioni di contatto invece che il loro dispositivo si arresti in modo anomalo.

Metti da parte risorse reali per questo: la soluzione più semplice per il problema non dovrebbe richiedere più di un giorno o due e un po' di lungimiranza. Tieni a mente i motivi più basilari per creare il sito Web in primo luogo (per non parlare di creare un sito reattivo).

Se sei uno sviluppatore di pacchetti che lavora su una libreria, un framework, un bundle o qualsiasi altro software incorporabile: qui puoi fare la differenza. Se riesci a facilitare o incorporare questi concetti nella tua piattaforma, influenzerai l'intero panorama dello sviluppo web. Se lo incorpori nel design del tuo pacchetto, fammelo sapere e evangelizzerò per te.

E infine, **se sei uno sviluppatore o un designer**, non limitarti alle migliori pratiche. Cerca sempre di guardare solo un po' oltre quell'orizzonte. Il duro lavoro spetta a te per spingere questi concetti che nessuno ha ancora chiesto, che non sono supportati e non documentati a beneficio dei tuoi clienti e utenti.

In definitiva, se vuoi sentire qualcuno parlare di questo per ore e trovarti vicino a Zagabria, fammi sapere. Potremmo andare a prendere una tazza di caffè.