Dalle pagine ai pattern: un esercizio per tutti

Il linguaggio definisce la vita dei componenti. Un “pulsante blu” funzionerà finché il pulsante non sarà più blu e quindi il nome non avrà più senso. Il pattern non avrà ragione di esistere se non si usano più i pulsanti blu. Un componente con il nome “pulsante”, tuttavia, vivrà una vita più lunga e proficua, anche se le sue proprietà cambieranno. Perché? Per il suo nome descrive la sua funzione, non il suo aspetto.

Come molti di noi sanno fin troppo bene, assegnare nomi è difficile, ma è la chiave per creare un sistema robusto e implica il lasciarsi indietro alcuni modi di pensare molto radicati.

Pensare in pagine (ancora)#section1

Anche quando il deliverable finale è una pattern library, i clienti si aspettano ancora di dare il consenso su design di pagina. Al loro passaggio tra i vari team e manager per l’approvazione, le pagine vengono ovviamente discusse: prima che ve ne rendiate conto, diventano Home page, Listing page, Product page e così via. Tutti pensano in termini di pagine, quindi può sembrare naturale che il design dei componenti e il design della pagina viaggino in tandem, ma, creare componenti dai design della pagina è come partire dall’esterno e lavorare verso l’interno – può diventare complicato.

In Clearleft, la sfida di sviluppare simultaneamente pagine e componenti è diventata particolarmente evidente in alcuni nostri progetti recenti, dove, invece di fornire ai nostri clienti delle pattern library complete, ci è stato chiesto di collaborare con un team di designer e developer in-house per aiutarli a crearne e mantenerne una loro. In un’occasione, come esercizio, abbiamo passato alcune settimane a concentrarci sulla UX e UI con un team prima di chiedere loro di assegnare un nome e di programmare i componenti a partire dai design. Stavamo lavorando con il design di una pagina prodotto con del contenuto relativo al prodotto in ogni componente. Il primo componente che abbiamo costruito aveva l’aspetto di una card, quindi tutti l’abbiamo chiamato “product card”. Abbiamo continuato l’esercizio per diversi componenti con risultati simili.

Ora, è fantastico che le persone se ne escano con suggerimenti unanimi, ma riuscite a vedere il problema di questa struttura di naming? Cosa succede se il componente viene spostato in un’altra pagina o viene popolato con del contenuto diverso? Potreste anche pensare alla product card come a una “profile card” o a una “location card”. Potrebbe essere riutilizzata per una varietà di scopi diversi. Il nome “card” potrebbe essere più semplice e molto più versatile.

Dalle pagine ai pattern#section2

Per aiutare gli altri ad adottare il pattern thinking, abbiamo creato un esercizio per chiunque sia coinvolto nella pattern library. Non è solo per i developer e i designer: dovrebbe parteciparvi chiunque debba prendere una decisione nella creazione della pattern library. Lo scopo è di far sì che tutti pensino ai pattern a livello granulare, rimuovendo qualunque contesto attorno a ciascun componente. Inoltre, incoraggia ad avere un vocabolario condiviso.

Tutto quello che vi serve sono dei visual design di pagine e componenti (possono essere una qualunque cosa dalla prima bozza fino ai design finali) e i seguenti oggetti:

• una stampante
• carta
• forbici
• post-it

Ecco come si fa.

Parte 1: carta e forbici#section3

• Stampate i design di pagina e condivideteli con il team, in modo che ognuno abbia i componenti da ritagliare.
• In gruppo o da soli, ritagliate ogni pagina nei suoi elementi più piccoli e mischiateli, così da non sapere da che pagina provengono.
• Raggruppate elementi simili come pulsanti, icone, campi di una form, etc., e rimuovete i duplicati.

I duplicati sono istanze multiple dello stesso identico elemento con lo stesso identico design. Potete tranquillamente rimuoverli: vi serve solo che annotiate un’istanza di ciascun elemento. Tuttavia, se vi ritrovate con molte istanze che hanno leggere variazioni tra loro, potreste voler rivedere i vostri design e ottimizzarli per assicurarvi di creare un’esperienza consistente e unita.

Brad Frost usa una tecnica chiamata interface inventory per analizzare i componenti dell’interfaccia di un sito web. Invece di ritagliare dalla carta, usa gli screenshot e li raggruppa in uno spreadsheet. Quando ha fatto l’inventario del sito web della sua banca, ha scoperto che i design dei pulsanti erano piuttosto inconsistenti. Usare la sua tecnica ha contribuito a sollevare il bisogno di una design review.

La mia versione dell’esercizio dalle pagine ai pattern. Ho raggruppato i campi delle form, le tabelle, i pulsanti, le icone, le famiglie di font, le dimensioni di font e addirittura i colori del sito web.

Parte 2: assegnare nomi ai componenti#section4

Generare idee per i nomi dei componenti come team è un modo fantastico per cominciare a sviluppare un vocabolario condiviso.

• Scegliete un componente.
• Ognuno prende un post-it e ci scrive sopra il nome per quel componente.
• Tenete segreti i nomi finché tutti hanno finito. Pensate alla funzione che avrà il componente ed evitate tutti i riferimenti al suo aspetto. Chiedere perché un designer ha scelto quell’aspetto può aiutare ad identificare la sua funzione o il suo scopo. Il nome ha ancora senso se il componente viene spostato in un posto completamente diverso da dove ve lo state immaginando?
• Una volta che tutti hanno pensato a un nome, scoprite ogni Post-it. Confrontateli e discutetene. I nomi che appaiono più volte sono buoni candidati perché indicano la formazione di un vocabolario condiviso.
• Ripetete questo procedimento con ogni componente.

Per quella che è la mia esperienza, questa parte dell’esercizio ha dato il via ad alcune discussioni produttive sul naming, facendo emergere alcuni nomi di classi che hanno importanza per l’azienda per le metodologie di naming in CSS. Assegnare nomi alle cose non dovrebbe essere semplicemente lasciato agli sviluppatori. Coinvolgere tutti rende un po’ più semplici i difficili task di assegnazione dei nomi alle cose ed incoraggia il team a continuare ad usare la stessa terminologia dopo il termine dell’esercizio.

Se il progetto è nelle sue fasi iniziali ed è probabile che il design cambi in maniera significativa, potrebbe non essere necessario fare questa parte dell’esercizio. D’altro canto, c’è molto valore nell’abituarsi al dare un nome ai componenti e nel cominciare a formare da subito un vocabolario condiviso, anche se tale vocabolario si evolverà durante il progetto.

Alcuni suggerimenti per dare nomi ai componenti.

Parte 3: codice#section5

Per quelli che si sentono a proprio agio a scrivere codice, c’è un ultimo step in questo esercizio. Se avete cominciato a discutere le metodologie CSS, adesso è il momento adatto per testarle. A questo punto, potete giocare con quante variazioni volete: se decidete che una particolare metodologia o un dato termine non funzionano per voi, potete lasciarlo cadere senza creare del codice nell’effettiva pattern library.

• Ciascuno prende un componente.
• Codificatelo in HTML e CSS. Mettete un tempo limite e resistete alla tentazione di rendere le cose perfette. Va bene buttare via il codice se cambia il design.
• Confrontate il vostro codice e discutetene.
• Ripetete.

Ripetere, ripetere, ripetere#section6

Tutto questo esercizio può essere ripetuto più volte per identificare i componenti più grandi. Alcuni di questi conterranno elementi identificati durante il primo round dell’esercizio. Potete controllare che abbiano senso e che stiano in piedi da soli all’interno del loro nuovo contesto.

La prima parte dell’esercizio pages-to-patterns ripetuta con i componenti più grandi.

Uno degli aspetti migliori di questo esercizio è che può essere prezioso durante fasi diverse di un progetto. Magari gruppi con skill set diversi, incluse le persone che non sono né sviluppatori né designer, vogliono cominciare a pensare in pattern. Se questo è il caso, usate semplicemente le bozze iniziali o la versione in cui vi trovate in quel momento. Non importa se cambieranno i design, perché il focus è su un nuovo modo di pensare, non sul modo in cui appare il pattern. In questa fase, i nomi scelti nella seconda parte dell’esercizio sono appropriati per essere temporanei, ma dal momento che assegnare nomi è comunque invariabilmente una sfida perché non usare questa mutabilità come un’opportunità per cominciare a costruire le fondamenta del vostro vocabolario condiviso cercando vari nomi nel contesto del progetto?

O magari siete più avanti nel progetto e il design è piuttosto consolidato, quindi vorrete cominciare a raggruppare e assegnare nomi ai pattern. Di nuovo, usate i design più recenti per l’esercizio. La bellezza dei prototipi su carta è il loro basso costo di cambiamento: potete buttarli via e ripetere quante volte volete. Natalie Downe era solita effettuare un esercizio simile quando lavorava in Clearleft. Usava carta e penna per fari i prototipi dei componenti, dimostrando la loro funzionalità e dimensione. Questo le permetteva di vedere in che modo avrebbero funzionato e come sarebbero stati insieme prima di investire del tempo nel codice.

Poi cosa succede?#section7

Dipende da voi. Dipende da cosa sperate di ottenere dall’esercizio. Personalmente, trovo utile mettere i componenti e i loro nomi su un grande foglio di carta per poi appenderlo al muro, così che tutti possano vederlo. Man mano che cambiano i design, i componenti possono essere ristampati, discussi e sostituiti. Tenere le cose visibili funge da reminder dei componenti e provocherà discussioni man mano che il progetto continua. Oppure, se il team non può lavorare nello stesso edificio, potete tenerne traccia online. Dan Mall ha parlato dell’utilizzo di un Google Sheet come repository centrale dei componenti così che tutti nel team possano accedere e discuterne in maniera asincrona.

Lo scopo dell’esercizio che vi ho descritto qui è di coinvolgere tutti nel team di creazione della pattern library. Alla Kholmatova si spinge ancora più in là e coinvolge gli utenti del sito web. Testa i componenti cartacei con loro per avere un feedback quanto prima possibile durante il processo.

Qui, i partecipanti possono prendere, spostare, discutere e scarabocchiare sulle card, diventando attivamente parte del processo di design. Questo ci dà una chance per testare le nostre scelte di linguaggio e per essere sicuri che le funzioni che abbiamo definito abbiano senso per i nostri utenti.

—Alla Kholmatova

In maniera simile, Heydon Pickering usa carta, penne, adesivi come Blu-Tack, forbici e nastro adesivo per fare prototipi di interfacce con cui gli utenti possano giocare in Neontribe. In questo modo, può rapidamente validare idee con gli utenti senza dedicare tempo alla fedeltà dei prototipi. A volte, fa a pezzi i prototipi e lascia poco più di quello con cui ha cominciato, ma almeno può rapidamente dedicarsi a nuove idee.

Sviluppare i componenti#section8

L’esempio della card illustra un componente comune e sottolinea il bisogno di uno schema di naming. In questo caso, la class .card funge da blueprint di stili per ciascun componente card, su cui si possono creare delle variazioni. Questo è il modo in cui il markup di un intero componente card potrebbe apparire usando la sintassi BEM:

<div class="card">
    <a class="card__link" href="">
        <h3 class="card__title">Hello</h3>
        <img class="card__hero" src="images/image.png" alt="Card image">
        <p class="card__description">Some text content</p>
    </a>
</div>

Una variazione, diciamo un prodotto, può essere creata modificando così il componente card:

<div class="card card--product">
    <a class="card__link" href="">
        <h3 class="card__title">Hello</h3>
        <img class="card__hero" src="images/image.png" alt="Card image">
        <p class="card__description">Some text content</p>
    </a>
</div>

Negli ultimi anni ci sono stati alcuni cambiamenti significativi nello sviluppo web, in modo particolare, gli approcci modulari al CSS e le convenzioni di naming. Le convenzioni di naming giocano un ruolo importante perché forniscono metodologie come SMACSS, BEM e OOCSS. Tutti questi aiutano a gestire lo stesso problema: dare nomi alle cose in maniera chiara e consistente.

Resistete alla tentazione di buttarvi direttamente nel codice. C’è molto da guadagnare allontanandosi dai nostri monitor per concentrarci prima sul pensiero, sul linguaggio e sull’approccio. Potrebbe sembrare che prenda troppo tempo e che costituisca un problema, ma può ridurre le possibilità di scoprire che occorre fare delle correzioni in corso d’opera più tardi.

I benefici principali di questo esercizio sono che crea lo stesso punto di inizio per tutti ed incoraggia un linguaggio condiviso e il pattern thinking in tutto il team, il che contribuisce a realizzare le fondamenta per un’efficace pattern library. Ho cominciato ad usare questo esercizio per fare il kick off di ogni progetto di pattern library su cui lavoro: avrei solo voluto scoprirlo prima. Dopo tutto, a chi non piace giocare con forbici e carta?

Illustrazioni: {carlok}