Alla fine di Novembre si è tenuta a San Francisco la Clarity Conference, una conferenza che ogni anno cerca di fare il punto sui temi di design del momento. Premesso che i contenuti erano tantissimi ed impossibili da raccontare tutti in un blog post, mi piacerebbe invece condividere qualche spunto interessante.

Consistenza o inconsistenza? 🤔

Chi di voi non ha mai sentito parlare di "interfacce intuitive"? Gli addetti ai lavori ne avranno le tasche piene, tutti ad affermare che le interfacce debbano essere il più intuitive possibile, il più naturali possibile e così via. In realtà un elemento che trovo molto interessante è quanto afferma Abi Jones (Designer e Sprint Master a Google) la quale sostiene che più che intuitive, le UI dovrebbero essere predicibili, sfruttando la memoria procedurale dell'utente.

La memoria procedurale è quella parte di memoria implicita e memoria a lungo termine che determina le performance di alcuni particolari task senza la coscienza di avere delle esperienze pregresse al riguardo. Essa guida i processi che eseguiamo e quasi sempre risiede al di sotto del livello di consapevolezza cosciente. Quando necessario, le memorie procedurali vengono automaticamente utilizzate per l'esecuzione delle procedure coinvolte nelle attività cognitive e motorie, dal legare le scarpe a leggere un libro. Le memorie procedurali sono accessibili e utilizzate senza necessità di controllo o attenzione cosciente e vengono create attraverso l'apprendimento procedurale (learning by experience, imparando dall'esperienza) ripetendo un'attività complessa più e più volte fino a quando tutti i sistemi neurali pertinenti lavorano insieme per produrre automaticamente tale attività.

Secondo questa teoria, per sfruttare la memoria procedurale sviluppata da ognuno di noi, si dovrebbero creare interfacce con comportamenti tipici dei servizi informatici più diffusi. Il loro ampio utilizzo ha fatto si che si sviluppasse in ognuno di noi una memoria procedurale nell'usare tali strumenti, dunque perchè non sfruttarla?

Tipi di consistenza

Sempre secondo Abi Jones, abbiamo principalmente 3 tipi di consistenza:

1. Interna
2. Esterna
3. Del mondo reale

1. Consistenza interna

Consiste nel colore, nella tipografia, nel linguaggio, negli elementi da visualizzare, nel layout e nel posizionamento dei vari elementi che compongono un'interfaccia. L'utente utilizza un'interfaccia con tali caratteristiche per eseguire un determinato compito. Ciò che lo spinge a portare a termine tale compito è il controllo cognitivo: consente alla mente di ignorare gli impulsi e aiuta a prendere decisioni in base agli obiettivi, piuttosto che alle abitudini o alle reazioni. Il controllo cognitivo è la capacità della tua mente di creare attivamente un'immagine informativa che guidi il tuo comportamento. È ciò che ti permette di selezionare un determinato comportamento che hai accettato come appropriato e di rifiutare un comportamento che hai deciso essere inappropriato. Chiarifica anche i tuoi obiettivi e scopi a lungo termine, aiutandoti a cambiare quello che stai facendo per raggiungere questi obiettivi. Il controllo cognitivo è al centro della tua auto-consapevolezza, del tuo più alto livello di coscienza e della tua forza di volontà e dato che è una risorsa esauribile, utilizzare un'interfaccia incoerente è mentalmente oneroso ed avere coerenza interna può ridurre il carico cognitivo degli utenti.

2. Consistenza esterna

Le emoji hanno molte rappresentazioni diverse tra le piattaforme. L'emoji che ride di Apple aveva una connotazione negativa mentre nelle altre piattaforme è considerata (molto) più positiva ed infatti la stessa Apple ha deciso di correre ai ripari passando da iOS 9 ad iOS 10.

Persino una stessa frase, senza cambiare nemmeno una virgola, potrebbe avere significati diversi se detta in contesti diversi. Jones ci ricorda che

la consistenza esterna può essere ben osservata nelle somiglianze che il team di Google Docs ha voluto dare al loro prodotto, utilizzando pressochè lo stesso design della UI di Microsoft Word. Elementi del menu, lingua, elementi visivi, layout, posizione e persino le interazioni sono le stesse.

Passare da Photoshop a Sketch in passato era difficile perchè la lettera R aveva un significato completamente diverso, ma se si crea un prodotto molto simile ad un altro, con la stessa base di utenza, bisogna assicurarsi di comprendere a fondo il modello mentale degli utilizzatori e capirne le aspettative.

3. Consistenza del mondo reale

Sono le abitudini apprese dal mondo reale. Un esempio può essere la realtà virtuale: chi di voi avrà provato almeno una volta i visori VR avrà notato che nonostanze si tratti di simulazione, le reazioni del nostro corpo quando il nostro cervello viene stimolato sono quasi le stesse di quelle che avremmo nella realtà. Siete caduti dalla sedia mentre giocavate alle montagne russe sui VR? 😂 Sarò ripetitivo ma: si può sfruttare nelle interfacce ciò che è stato appreso dal mondo reale.

Ragioni per essere inconsistenti

Perché alcune volte vogliamo essere inconsistenti?

Possiamo esserlo quando abbiamo una migliore metafora: se stiamo sviluppando un gioco in VR e dobbiamo simulare uno sforzo lavorativo, nonostante l'utente sappia dal mondo reale come compiere tale lavoro, i creatori del gioco saranno inconsistenti con la realtà del mondo reale in quanto non vorranno che il giocatore abbandoni il loro videogame perchè troppo stancante ed utilizzeranno una migliore metafora per renderne l'idea.

Un'altra buona ragione per essere inconsistenti è il divertimento. Avete presente le pagine 404 dei servizi più famosi? Sotto vi propongo quella di GitHub, in genere tali pagine sono inconsistenti con il resto del sito/portale ma aggiungono quel tocco di ilarità che fà l'utente felice (e lo sviluppatore ancor di più).

Anche essere inconsistenti per distinguersi è concesso, l'esempio che Jones fa sono le tazze di caffè Starbucks che non sono le usuali small, medium & large.

Infine, essere incoerenti utilizzando i vantaggi della tecnologia. Riproponiamo la realtà virtuale per capire meglio il concetto: se essa fosse coerente con la realtà, non avrebbe senso di esistere. Invece ti permette di estrapolare alcune idee per ora solo fantascientifiche e di metterle in atto, mi viene da pensare al teletrasporto, al volo, il ridimensionare degli oggetti, ecc...

Disegnare sistemi per Data Product ✍️

Un'altra parte interessante della conferenza è stata quella tenuta da Linh Yao Pham (Product Designer presso Trifacta) che ha provato a rispondere alla domanda

come possiamo creare o estendere sistemi in grado di supportare meglio quei servizi che fanno dei dati il loro prodotto?

Per Data Product si intendono infatti tutti quei servizi che facilitano il raggiungimento di un goal tramite l'uso di dati. Che aspetto ha un sistema di progettazione per UX di dati? La progettazione dei dati è difficile, e la maggior parte dei progettisti non ha una formazione statistica dunque ci si scontra spesso con sistemi inappropriati. I valori chiave per tali servizi sono:

Linh Yao Pham ci fornisce un modo in cui possiamo estendere il sistema di progettazione per supportare meglio l'UX dei dati attraverso 5 principi da seguire:

1. Identificare preferenze cognitive/oggettive degli utenti

Il cervello può essere diviso in due parti principali: emisfero di sinistra e di destra, ognuna delle quali ha compiti molto diversi, una più creativa e l'altra più analitica, ma la maggior parte delle persone ricade ampiamente nello spettro. A seconda di chi abbiamo di fronte, il modo di ricreare all'interno della mente la realtà che ci circonda varia, dunque uno stesso tipo di visualizzazione non può essere adatta per tutti. L'immagine sottostante mostra come sia diversa l'astrazione della realtà a seconda che si tratti di figure con un certo tipo di forma mentis piuttosto che un altro. Gli scienziati e gli ingegneri preferiscono le visualizzazioni con più astrazione, densità di informazioni, novità. Artisti e giornalisti preferiscono ridondanza, leggerezza, figurazione, oserei dire chiarezza.

Progettare interfacce significa anche prestare attenzione alla creazione del pensiero umano. Il pensiero molto spesso può sorgere in due modi diversi o come risultato di due processi diversi, il più delle volte i due processi consistono in un processo implicito, automatico, inconscio ed un processo cosciente, controllato, esplicito.

L'argomento sarebbe molto ampio e meriterebbe un articolo a se con infinite cose da dire, per abbreviare li chiameremo pensiero implicito e pensiero esplicito ed elenchiamo le loro caratteristiche:

Come utilizziamo questi due tipi di pensieri nel progettare interfacce?

Diverse teorie al riguardo, tra le quali quella di attirare l'attenzione dell'utente, mostrando che si è in grado di risolvere i suoi problemi (pensiero implicito) e poi approfondire i dettagli, i dati e le informazioni di cui ha bisogno per prendere una decisione informata (pensiero esplicito). Una cosa è sicura: progettare sistemi senza tener conto di questi due concetti è come sparare alla cieca e cercare di colpire un bersaglio, poiché molti esperimenti dimostrano che sottoposti a delle sollecitazioni, persone con uno stato mentale prevalentemente implicito rispondono in modo opposto alle persone con stato mentale prevalentemente esplicito. Non bisogna nemmeno esagerare col fornire informazioni che sollecitano il pensiero esplicito, si finirebbe per forzare tali persone a "pensare troppo" il che come abbiamo visto può essere stancante e stressante.

Facciamo ora alcuni esempi pratici di come si possano avere effetti positivi o negativi al riguardo. Prenderemo alcuni siti web di rivenditori di antifurti per effettuare un paragone (non me ne vogliano le aziende che purtroppo non hanno seguito le linee guida di questo articolo).

La pagina di casasicura.it è orientata alla promozione dei loro prodotti dato che ne hanno molti, a cosa dice di loro mamma Rai e alle loro offerte. È più adatta ad un tipo di pensiero esplicito e potrebbe andar bene per una persona molto analitica, in grado di ponderare per bene le informazioni che ha davanti.

D'altro canto, niceforyou.com sceglie una comunicazione diversa, quasi non mostra il loro prodotto per la casa preferendo mostrare un'immagine di serenità, divulgando sicurezza, proprio quello che dovrebbe fare un allarme di casa...d'altronde: di cosa stiamo parlando? Questa è una comunicazione per un tipo di pensiero implicito, fornendo però sufficienti informazioni al pensiero esplicito posizionando in primo piano solamente il link per trovare l'installatore più vicino alla nostra posizione.

Partendo dal presupposto che si potrebbe fare di meglio in entrambi i casi, non vi è un modo migliore rispetto ad un altro, come non è detto che far prevalere sempre il pensiero implicito rispetto a quello esplcitio sia la scelta vincente. Tutto dipende dal contesto. Molti siti web risolvono il problema del pensiero implicito vs pensiero esplicito nascondendo la maggior parte delle informazioni su fatti/caratteristiche all'interno di una scheda separata o utilizzando un link "ulteriori informazioni" per accedervi. In questo modo le persone che vogliono davvero più dettagli possono ottenerli, ma le altre non sono soggette ad un sovraccarico di informazioni.

2. Ottimizzare l'efficienza della percezione visiva

Proprietà quali posizione, dimensione, colore, forma, orientamento, contrasto, allineamento, prossimità, gerarchia, raggruppamento, sequenza... Circa il 10% delle persone soffre di una forma di daltonismo che rende alcune visualizzazioni dei dati molto meno utilizzabili.

3. Creare contenuti in base alle esigienze delle linee guida dettate dal machine learning

Il 75% di ciò che guardi su Netflix è guidato da algoritmi machine learning (ML da ora in poi). Trifacta utilizza algoritmi di ML in combinazione con l'interazione predittiva ovvero ciò che gli utenti probabilmente faranno di li a poco.

4. Progettare e implementare in modo estendibile, configurabile e componibile in varie visualizzazioni

Se si hanno delle componenti di base per visualizzare alcuni tipi di dati, esse possono essere messe assieme per formare altre visualizzazioni efficaci per altri tipi di dati. Va da se che per poter fare questo, si deve tenere a mente tale concetto sin dalla progettazione dei componenti base, altrimenti ciò non è possibile.

5. Affrontare le eccezioni

Bisogna accettare che alcuni dati debbano essere trattati in modo diverso da tutti gli altri, facendo delle eccezioni o scendendo a compromessi.

Per fare un esempio concreto, mappe di Apple è un Data Product, venne lanciato con dati piuttosto scadenti, ed ora è davvero difficile riportare indietro gli utenti quando perdi la loro fiducia all'inizio.

Una teoria dei componenti funzionante 💪

Quello che ha presentato Elyse Holladay (Designer System Engineer presso Indeed) è una teoria sui componenti. Abbiamo parlato in precedenza di componenti e di come si possano combinare assieme per ottenere diverse visualizzazioni grafiche, dunque cerchiamo di capire quali principi dovremmo seguire secondo Elyse, per avere un framework di componenti funzionante. Gli strumenti che abbiamo oggi non esistevano 10 anni fa, li abbiamo creati per consentire una progettazione più flessibile e modulare nelle pratiche di sviluppo. I nostri bisogni sono cambiati e i nostri strumenti sono migliorati. I vari tool cambiano a seconda di come concepiamo il nostro lavoro e di sicuro accadrà anche in futuro. Non esiste una soluzione definitiva ma, come accade nelle varie teorie scientifiche, vi è un'iterazione dopo l'altra per poter affinare lo strumento in modo che si adatti sempre meglio a ciò di cui l'utilizzatore ha bisogno.

Secondo Elyse, un componente per essere efficace ed utile deve rispettare tre principi:

1. Coerenza
2. Riusabilità
3. Manutenibilità

Con le corrette astrazioni, un componente deve essere semplice a livello concettuale, nel senso che se pensaste ad esso, non dovreste porvi troppe domande ma dovreste essere in grado di capire, in linea teorica, cosa esso debba fare, ma non come lo debba fare. Se questo non avviene, probabilmente il componente va spezzato in sotto-componenti diversi ognuno dei quali esegue delle operazioni più semplici, la somma di tali operazioni porterà al risultato finale desiderato.

Oltre questo, il componente ideale dovrebbe essere agnostico, non dipendente dal contesto. Qualora venga posizionato in un punto qualsiasi, dovrebbe comportarsi sempre nella stessa manierea senza che l'ambiente circostante possa influenzarlo, non dovrebbe mai avere interazioni o funzionalità specifiche in quel contesto. Questo aumenterebbe enormemente il carico cognitivo e ridurrebbe l'intuitività e l'usabilità di un'interfaccia. All'atto pratico di scrittura del codice, esso non dovrebbe nemmeno ereditare stili dai componenti padre. Oltre a renderlo completamente riutilizzabile, gioverebbe anche al testing. Per essere indipendente dal contesto, un componente non dovrebbe avere layout, dovrebbe essere supportato da browser e dispositivi diversi ed essere accessibile a persone diversamente abili. Un componente indipendente e isolato dovrebbe influire solo su se stesso, definire se stesso e i suoi stili in un solo posto e dovrebbe essere in grado di funzionare nella stessa maniera sia che esso venga utilizzato solo, sia quando viene utilizzato da un altro componente o da un'altra applicazione.

È concesso ad un componente essere complesso ma semplice. Troppe opzioni possono renderlo complicato a livello concettuale, mentre troppo poche possono portarlo ad essere vago e non intuitivo. Si faccia attenzione ai prototipi che utilizzano un componente che ha bisogno di essere ritoccato ogni qualvolta lo si usa e all'atto di implementazione (quando si scrive codice) si faccia attenzione a quelli che hanno troppe proprietà o stati, solitamente è un segno che qualcosa non sta andando per il verso giusto.

Essere semplice a livello concettuale non ha nulla a che vedere con la leggibilità o la pulizia del codice, riguarda piuttosto la facilità d'uso con la quale i progettisti e gli sviluppatori riescono a maneggiarlo in maniera appropriata e potente. Tutti i componenti semplici a livello concettuale che si rispettino, devono essere documentati, avere unit e visual test, un appropriato stato di default e comprendere stati di errore.

Il progetto LIGO mirava a rilevare le onde gravitazionali; costò milioni di dollari ed impiegò oltre 50 anni prima di avere successo, era pura ricerca scientifica. Quasi 100 anni dopo le previsioni di Einstein, LIGO le rilevò.

In tutti i campi, la ricerca di nuove soluzioni dovrebbe perseguire la sperimentazione e dovremmo continuare a pensare oltre la nostra attuale comprensione del mondo per permetterci di creare un domani migliore.

Interazione di sistemi di colore 🌈

Diana Mounter (Design Systems Lead presso Github) ha parlato invece di... 🏳️‍🌈 colori! La prima cosa che tiene a specificare è che lei lavora da casa solitamente in pigiama circondata dai suoi gatti 😀 fortunatamente anche nel nostro paese qualcosa si muove e chi vi scrive ha la stessa fortuna.

Una sfida nel lavorare con i colori e sistemi cromatici è che il colore è soggettivo e le persone hanno interpretazioni diverse di esso in base a vari fattori, come l'età e le forme di cecità verso di essi. Purtroppo per ora l'intera storia della teoria dei colori è trascurata negli strumenti di progettazione moderna, dovrebbe invece essere tenuta in forte considerazione in quanto alcune tonalità hanno più gamma di luminosità e oscurità. Un'altra sfida nell'imparare questa teoria è che nonostante possa apparire semplice, in realtà è molto complicata, con un sacco di cose da imparare: additivo vs sottrattivo, HSB, RGB, HSBA, HSL (che non è HSB), HSV (che è fondamentalmente HSB).

Nel creare un sistema di colori, la prima domanda che Diana si pose fu:

perché lo stiamo facendo?

Uno dei problemi di Github da risolvere in passato era il numero spropositato di colori senza significato. Vi erano 2.449 valori esadecimali nella codebase, i nomi non avevano un significato umanamente comprensibile dunque sfavorivano il loro riutilizzo. Le combinazioni di colore che venivano utilizzate, non soddisfacevano i requisiti di contrasto e accessibilità. L'occasione di ridisegnare il sistema dei colori a Github fu colta da Diana quando il reparto marketing dovette lavorare su di un aggiornamento e voleva un sistema riutilizzabile e strutturato.

È raro avere una buona opportunità per un lavoro così importante, quindi quando capita, coglietela!

Diana diede priorità ai componenti utilizzati più frequentemente: parti importanti dell'interfaccia utente, pagine più visitate, pulsanti, messaggi flash e l'iconica griglia verde / calendario dell'attività dei commit. Un errore che fecero fu quello di rendere blu le icone dei file negli elenchi, questo portò lamentele per il "troppo blu". Tutto ciò insegna che è importante non solo il singolo colore, ma osservare come i colori all'interno di una tavolozza interagiscono tra loro. Esempio rapido di differenza cromatica: arancione e rosso. I due possono sembrare troppo simili, specialmente, ma non solo, sottoposti a soggetti con varie forme di daltonismo. Essere sicuri di renderli abbastanza diversi da poter essere riconosciuti da tutti. Un altro principio importante: non affidarsi mai solo al colore per comunicare differenze e significato!

Dare un nome alle cose è difficile, quindi si dovrebbe cercare di capire cosa è importante per te e il tuo team. Un loro bisogno fu quello di conoscere il colore leggendo solamente il nome. Convenzione di nomi intuitivi e autoesplicativi per i colori aiutano a interiorizzare rapidamente i colori con cui lavori, contrariamente ad altri sistemi di progettazione che a volte utilizzano nomi di colori non ovvi o umanamente comprensibili, questo porta quasi sempre a confondere o a far perdere tempo ai progettisti e agli sviluppatori nel trovare il colore giusto. Diventa fondamentale un vocabolario di colori condiviso all'interno di uno o più team, in modo tale che quando ci si riferisce ad un nome di un colore, tutti abbiano chiaro in mente di cosa si tratta.

PALX è un generatore automatico di palette di colori per interfacce, può essere utile per generare rapidamente sfumature di colori. Si può usare come punto di partenza e poi regolarlo in base alle esigenze. Nel completare il sistema di cui stiamo parlando, "solo" il 23% della codebase di GitHub è stato aggiornato, ma la percezione degli utenti potrebbe essere molto maggiore. Nonostante i progressi fatti Diana ci informa che il lavoro è ancora lungo e al momento hanno ancora oltre 1200 valori esadecimali.

È possibile controllare la tavolozza e la composizione dei colori ma non il contesto o l'osservatore (il tipo di schermo che l'utente sta utilizzando, le sue forme di daltonismo).

Design delle prestazioni 📈

Concludiamo questo post con l'ultimo (ma non meno importante) argomento: le performance. Ne ha parlato Henri Helvetica (Web Performance Analyst) il quale come prima cosa ci tiene a puntualizzare che Helvetica non è il suo vero cognome, sarebbe stato troppo per un designer...😂

Fatto shockante: a partire dal Novembre 2016, si accede alle pagine web più dagli smartphone che dai desktop. Perchè shockante?

1. è un processo irreversibile, non si tornerà più indietro
2. il dispositivo più diffuso negli Stati Uniti è di fascia medio-bassa: Android indietro di due aggiornamenti, non l'ultimo iPhone
3. in media si perde il 50% degli utenti dopo 3 secondi di caricamento e spesso non si ha il controllo di questo se dovuto a congestionamento di rete

Il tempo medio di caricamento su mobile dei siti più recenti è di 19 secondi, troppo. Servono delle metriche per misurare le performance dovute al design. Ve ne sono 4 molto importanti con diversi significati:

1. FP - first paint: momento del primo pixel disegnato sullo schermo
2. FCP - first contentful paint: prima sezione caricata completamente
3. FMP - first meaningful paint: tutti i testi e tutti i contenuti caricati
4. TTI - time to interactive: bottoni clickabili, stati attivi e raggiungimento dell'interattività

Lavorare sul Critical Rendering Path o Percorso di Rendering Critico

Di cosa si tratta? Premetto che farò un post a parte su questo argomento per spiegare i passi di cui necessita un browser per visualizzare una pagina web, sostengo sia molto interessante. Per ora, in modo sintetico, il Critical Rendering Path è la serie di eventi che devono aver luogo per renderizzare (inglesismo derivato da rendering, visualizzare) la vista iniziale di una pagina web.

Esempio molto superficiale:

1. ottieni il codice html
2. ottieni le risorse (immagini, font, ecc...)
3. traduci il codice
4. visualizza pagina web

Per agevolare il Percorso di Rendering Critico è consigliabile caricare solo il CSS e l'HTML che consentono di eseguire il rendering della pagina, il fine è quello di raggiungere l'interattività il prima possibile. Il principio fondamentale da seguire è Keep it Simple (mantieni le cose facili): quanto meno CSS e codice JavaScript possibile per esigenze di rendering iniziali perchè entrambi bloccano le risorse. Si dice scherzosamente che

La richiesta più rapida è quella mai realizzata.

Oltre a quanto detto, il caricamento ma soprattutto l'elaborazione di CSS e JavaScript impattano sulla batteria dei dispositivi mobili.

Capitolo a parte: i caratteri web. Sono fantastici da vedere, vi sono dei font bellissmi, ci danno la possibilità di leggere il testo attraverso gli occhi dei type designer ma il loro uso da dei problemi! Facendone largo utilizzo, potremmo incappare nel FOUT: Flash of Unstyled Text e nel FOIT: Flash of Invisible Text.

FOUT - Flash of Unstyled Text

Quando si utilizza un carattere personalizzato tramite l'istruzione @font-face, i browser utilizzano un font di fallback nello stack dei font, sino a quando il font specificato nell'istruzione non è stato caricato. Questo meccanismo può essere sconvolgente e causare spostamenti di layout. Vi sono delle tecniche per combatterlo, ad esempio, rendendo il testo invisibile fino a quando il carattere non è pronto.

FOIT - Flash of Invisible Text

Per ovviare al problema precedente, un certo numero di anni fa i browser iniziarono a cambiare la gestione di questo processo cominciando a rilevare se il testo personalizzato, indicato nell'istruzione @font-face, fosse ancora da caricare e, in tal caso, rendendolo invisibile sino alla sua disponibilità (o al passare di X secondi). Se il caricamento di un asset di font fallisce o richiede molto tempo, questi X secondi possono diventare eterni e, nel peggiore dei casi, questo comportamento può portare a contenuti permanentemente invisibili.

In ogni caso, sia di FOUT che di FOIT, l'utente si ritroverebbe a vivere un'esperienza davvero pessima.

Le immagini sono un altro argomento portante del design delle prestazioni, esse rappresentano alcuni dei carichi di dati più pesanti da gestire perchè creano sempre più colli di bottiglia su vari livelli. Si deve approfondire per scoprire e conoscere i vari formati per poterli utilizzare nel modo ottimale.

Il chroma subsampling (sottocampionamento della crominanza) è una pratica di codifica delle immagini implementando una minor risoluzione per le informazioni sulla crominanza e più informazioni sulla luminanza, sfruttando l'acutezza del sistema visivo umano per le differenze di colore rispetto alla luminanza. Come impattano sulle prestazioni? Mentre il sottocampionamento può facilmente ridurre le dimensioni di un'immagine non compressa del 50% con una perdita minima di qualità, l'effetto finale sulla dimensione di un'immagine compressa è notevolmente inferiore.

Un'altra sfida (come se fino ad ora non fossero abbastanza) è la nuova vasta gamma di colori disponibili. Alcuni dei formati di immagine e schermi che utilizziamo oggi possono coprire una gamma di colori molto più ampia rispetto agli anni precedenti, questo è un problema da non sottovalutare: un certo colore di un determinato marchio può apparire significativamente diverso in schermi diversi e in formati di immagine diversi, grazie appunto all'ampia gamma di colori.

Non possiamo parlare di prestazioni senza mensionare almeno di sfuggita la memoria. Maggiore è il numero delle immagini presenti, maggiore sarà l'utilizzo della memoria del browser e peggiore sarà la prestazione complessiva della pagina.

L'abbondanza di immagini influisce anch'essa, come per CSS e JavaScript, sull'utilizzo della batteria. La quantità di energia utilizzata per il rendering delle immagini è proporzionale alla dimensione e al numero di immagini su di una pagina.

In conclusione, non si riuscirà a raggiungere le prestazioni web desiderate al primo tentativo. Si deve giocare, spostare le cose, prendersi il proprio tempo per sperimentare, documentarsi, misurare e costruire una maggiore comprensione di ciò che accade nella propria pagina apportando modifiche incrementali.

Concetti takeaway 📦

Per concludere questo breve post 😂 ecco i concetti principali riassunti in punti:

1. I componenti dovrebbero essere semplici a livello concettuale, senza dipendere dal contesto ed agendo in modo indipendente e isolato.

2. Va bene essere non consistenti ma fornire un ragionamento che rispecchi i principi del design scelto

3. Mantenere le cose il più semplici possibile: concetti, nomi, formati, tutto!

4. Integrità in tutte le parti del processo.

Auguri di buon natale! 🎅🏻 🎄 ❄️ ☃️