6 cose che abbiamo fatto nel redesign di Today.it
Qualche giorno fa è andato online il nuovo Today.it. È un progetto a cui ho lavorato molto negli ultimi mesi e tra le (tante) cose fatte ce ne sono alcune che, secondo me, hanno fatto la differenza.
1. Creare delle guidelines per il design e il front-end
Prima che ogni componente del team iniziasse a scrivere ogni singola riga di codice venisse scritta o qualunque wireframe/mockup venisse prodotto, ci siamo presi il tempo di definire le regole del gioco.
A cosa servono le design guidelines
Le guidelines di design mirano a definire come svolgere una serie di attività ordinarie in un tool di design. Nel nostro caso abbiamo ragionato su come:
- utilizzare i design tokens, dalla struttura del naming all’organizzazione di layer e text styles;
- dare un nome ai livelli, per evitare di trovarci difronte al classico Rectangle_01_copy-2, Rectangle_01_copy-3, etc.
- dare un nome ai files di design, anche in questo caso per evitare final, final_final, LAST_FINAL, etc.
- versioning design files, utilizzando Plant per la collaborazione in real-time e un repository GitHub per ospitare la public release
- organizzare la library, creando un Design Kit comprensivo di tutti i foundations, components e layouts;
A cosa servono le front-end guidelines
Le guidelines per il front-end sono importanti perché aiutano il team a scrivere insieme un codice solido e coerente. È un compito per nulla banale, perché in ognuno di noi sono radicate della abitudini che difficilmente mettiamo in discussione.
Pertanto ci siamo serviti di un documento condiviso su GitHub così che potesse essere consultato, modificato o integrato da tutti.
Abbiamo dedicato molto tempo alla sintassi CSS e Sass definendo nel dettaglio il maggior numero di casistiche.
2. Progettare una solida architettura front-end
L’architettura front-end è stata progettata seguendo 3 principi molto conosciuti nello sviluppo software:
1. Single responsibility principle
2. Separation of concerns
3. DRY — don’t repeat yourself.
Come li abbiamo messi in pratica?
1. Applicando la piramide invertita della metodologia ITCSS nell’organizzazione dei files CSS siamo riusciti ad avere una basso livello di specificità e a non duplicare codice inutilmente;
2. Creando una vasta libreria di utility classes per risolvere le esigenze di layout più comuni; ad ogni classe corrisponde una sola CSS declaration
3. Utilizzando BEM per il naming delle classi, a vantaggio di un codice forse verboso ma sicuramente comprensibile;
4. Utilizzando le CSS custom properties per definire le proprietà di ciascun componente e tutte le sue varianti (dark mode, themes, etc)
4. Condurre un interface inventory
Non ci si rende conto del casino in cui ci si trova fintanto che non lo si affronta. Un’interface inventory serve proprio a mettere sul tavolo i problemi, le incongruenze e le infinite varianti che nel tempo si accumulano.
È un’attività piuttosto semplice in quanto si tratta di fare tanti e tanti screenshots. Più è ricca l’interfaccia, più elementi si andrà a raccogliere.
La parte più significativa di un interface inventory viene alla fine: una volta raggruppati tutti gli screen in categorie specifiche (es. Buttons, Images, Forms, etc) si decide sul destino di ciascun elemento scegliendo se mantenerlo nel nuovo design, cambiarlo o eliminarlo definitivamente.
5. Progettare un Design Kit (e mantenerlo aggiornato)
Per il nuovo design del sito abbiamo costruito un Design Kit sfruttando al massimo le potenzialità delle Sketch library.
Nella libreria abbiamo inserito solo gli elementi essenziali:
- design tokens (typography, spacing, sizes, colors)
- icons
- components
- grid layouts
Dovendo servire il duplice contesto Web e App, avevamo la necessità di creare un posto dove reperire a prescindere gli elementi della UI. I mockup completi delle pagine web o gli screen per le app iOS/Android sfruttano la library, ma sono creati in files separati.
6. Creare una pattern library con fractal
Abbiamo usato Fractal per creare la nostra pattern library e styleguide perché è uno strumento che si integra facilmente in qualsiasi processo di sviluppo front-end.
Per noi la differenza l’hanno fatta:
- l’integrazione con nunjucks, template language che usiamo su altri progetti
- personalizzazione dei componenti tramite le varianti e i context data;
- possibilità di documentare ogni singolo componente
Un impatto reale sulle performance
Abbiamo avuto sempre come obiettivo quello di migliorare le performance (e l’esperienza utente) sui dispositivi mobile, che rappresentano il 70% del traffico.
Google Pagespeed
Su Google PageSpeed Insights abbiamo raggiunto il punteggio di 99 e 100 rispettivamente per mobile e desktop, ottimizzando al massimo tutti gli aspetti correlati ai cosidetti web vitals.
PS: partivamo da un punteggio di 25 (mobile) e 70 (desktop)
CSS Stats
L’analisi relativi al peso dei CSS è stata affidata al tool CSS Stats che ha segnato un +50% (e oltre) di risparmio sul peso totale delle risorse.
Se ti interessa approfondire qualche aspetto trattato in questo articolo, avere supporto per un redesign in corso o semplicemente chiarirti qualche dubbio, puoi scrivermi a francesco[at]designabile.com
