No. 94

Titolo originale: Building Twitter Bootstrap

Pubblicato in: CSS, HTML, Javascript, Workflow & Tools

Scritto da Mark Otto

Un anno e mezzo fa, un piccolo gruppo di impiegati di Twitter decise di migliorare i tool amministrativi e analitici in uso nel nostro team interno. Dopo le prime riunioni attorno a questo argomento, avevamo un'ambizione più grande: creare un toolkit per chiunque lo voglia usare internamente a Twitter e oltre. Così, ci siamo messi a realizzare un sistema che potrebbe costituire una base per le persone come noi che vogliono creare nuovi progetti. Così concepimmo Bootstrap.

Realizzato da me e da Jacob Thornton, Bootstrap è un toolkit front-end open-source per aiutare i designer e gli sviluppatori a creare rapidamente ed in maniera efficace online. Il nostro obiettivo è di fornire una libreria raffinata, ben documentata ed estesa di componenti di design flessibili, realizzati in HTML, CSS e JavaScript, così che altri possano usarli come base ed innovare. Ad oggi è cresciuto fino ad includere dozzine di componenti ed è diventato il progetto più popolare su GitHub, con più di 13000 watchers e 2000 forks.

Sveleremo ora come e perché abbiamo creato Bootstrap, i processi che abbiamo utilizzato durante la sua realizzazione ed in che modo è diventato un design system.

Riconoscere un'opportunità

Ad alcuni dei primi tool che utilizzavamo internamente a Twitter mancava un design raffinato e accessibile e ci risultava difficile sviluppare o iterare rapidamente. Alcune persone di diversi team ammisero il problema e videro un'incredibile opportunità per questo e per i progetti futuri. Riconoscendo ciò, abbiamo cominciato a formare un processo grossolano collaborando fin da subito con Design ed Engineering.

Ad alto livello, il nostro processo cominciava ad assomigliare a questo:

  1. Alcuni tool developer interni hanno lavorato con i product manager e con i potenziali utenti di ciascun tool per identificare le funzionalità e le caratteristiche principali
  2. Io ho lavorato con gli sviluppatori per identificare le nostre necessità per poi progettarle nel browser, al fine di creare un linguaggio visuale consistente ed esplorare le interazioni. Dopo la prima implementazione, discutevamo di ciascun componente e soppesavamo attentamente ciascuna opzione ed implementazione prima di proseguire.
  3. Dopodiché, abbiamo progettato e programmato i componenti isolati per il progetto dei nuovi tool interni che avremmo dovuto creare originariamente. Durante questo periodo, abbiamo implementato rapidamente, testato ed iterato ciascuna nuova feature.
  4. Infine, come follow-up, ho preso quegli stessi componenti dal progetto dei tool interni e li ho aggiunti ad una codebase condivisa (Bootstrap) per astrarli e documentarli per altri progetti.

Fondamentalmente, tutto ciò si riduce ad un concetto principale: far lavorare i designer con gli sviluppatori. L'interazione costante con gli sviluppatori è quello che ha fatto brillare Bootstrap e che continua a guidare il suo sviluppo ad oltre un anno dalla sua nascita. Dalle idee abbozzate su una lavagna bianca alla programmazione di prototipi grossolani, la collaborazione tra le diverse discipline è quello che ha fatto avere successo a Bootstrap per l'uso interno a Twitter. Questo processo ha permeato lo sviluppo praticamente per tutte le feature di Bootstrap e ha funzionato incredibilmente bene nel tempo.

Realizzare Bootstrap in questo modo vuol dire che la comunicazione ha avuto un ruolo cruciale e la maggior parte del lavoro di design è avvenuta nel codice. Dal momento che il deliverable finale di Bootstrap è sempre codice, aveva molto più senso lavorarci quanto più possibile per comunicare nel nostre idee. Questo ci ha messo nelle condizioni di ragionare come farebbe un buon sviluppatore, incoraggiando componenti succinti, ma con la pulizia nei componenti visuali e con l'accuratezza che uno si aspetterebbe da un bravo designer.

Un esempio

Fig. 1

Fig. 1: I menu dropdown nella prima release di Bootstrap venivano attivati all'hover.

Diamo uno sguardo ad una feature di Bootstrap: i dropdown menu. Per aiutare ad ospitare le informazioni riguardanti la sessione corrente e far risaltare altre aree del tool, avevamo bisogno dei dropdown. Tutti hanno i menu dropdown nelle proprie applicazioni, ciascuno con un'implementazione, delle interazioni e un visual design differente, quindi, come possiamo farli? Seguendo lo schema di cui sopra, ecco come è stata realizzata questa feature in Bootstrap:

  1. Ci siamo accorti di avere troppi link di navigazione e troppe azioni nella topbar fissa che stavamo usando. I menu dropdown estesi e multi-livello ci sono sembrati la soluzione giusta.
  2. Abbiamo lavorato insieme per identificare i motivi per cui così tanti link e tante azioni avessero bisogno di apparire come primo elemento e perché avremmo bisogno di un supporto multi-livello.
  3. Dopo un po' di dibattito, abbiamo deciso di riarrangiare la topbar rimuovendo alcuni link ed implementando i dropdown, ma senza il supporto multi-livello. In quel momento, avrebbe comportato la scrittura di codice extra che avrebbe complicato la nostra implementazione e abbiamo preferito evitare questa cosa.
  4. Poi abbiamo scritto l'HTML ed il CSS di base per i dropdown a fronte di un :hover. Abbiamo sistemato i dettagli visivi all'interno della codebase del tool e quindi li abbiamo astratti e documentati per Bootstrap.
  5. Come ultimo step durante l'astrazione per Bootstrap, abbiamo scelto l'opzione di attivare il comportamento con un click piuttosto che al passaggio sopra di esso. Ritenevamo che questo avrebbe risparmiato agli utenti un po' di confusione e dei click accidentali, garantendo così un'esperienza migliore.

La maggior parte dei componenti e molti dei dettagli più sottili che gli ruotano attorno sono stati progettati e realizzati mettendo insieme designer e sviluppatori. Insieme, il nostro processo per tutte le nuove feature o per i singoli componenti di design è maturato fino alla ideazione, dibattito e revisione delle feature, implementazione ed infine astrazione e documentazione. Ha fatto andare via liscio lo sviluppo dei nostri tool interni, ci ha permesso di evitare la crescita fuori controllo delle feature e l'aumento sproporzionato del codice. Inoltre, ci ha aiutato a documentare non solo come usare un componente, ma perché si dovrebbe usare quel particolare componente in Bootstrap.

Questo si estende naturalmente oltre le nuove feature ed in quelle esistenti. Se una feature che abbiamo già ha bisogno di essere modificata o rimossa, seguiamo gli stessi step: ideazione, revisione, implementazione e documentazione. Per portare avanti l'esempio, abbiamo ricevuto moltissimo feedback sui dropdown e potremmo rivedere il supporto multi-livello. Dal momento che le applicazioni web si comportano sempre più come le proprie controparti desktop, che usano i dropdown multi-livello, ha senso che noi si consideri di supportarle. Ovviamente, potremmo semplicemente tirarci indietro dalle nostre decisioni iniziali, ma questo processo ci rende onesti, importanti e responsabili verso i nostri utenti ed i loro bisogni.

Sviluppo parallelo

Il nostro processo ci ha aiutato a superare quasi tutto il nostro sviluppo delle feature e ha messo in luce un importante aspetto della nostra decisione dell'andare oltre il semplice sviluppo di un tool. Lo sviluppo parallello ha significato che abbiamo comunicato in maniera efficace a chi non rea toccato dai processi o dalle informazioni interne il nostro lavoro.

Mentre eravamo impegnati a lavorare alla creazione di una roadmap per il prodotto e a determinare gli obiettivi di un singolo progetto, abbiamo considerato attivamente come gli altri avrebbero usato gli stessi componenti. Astrarre e documentare i componenti è diventato parte del nostro processo per creare questo tool e Bootstrap in tandem. Ma soprattutto, abbiamo risparmiato tempo e sforzo, abbiamo discusso più chiaramente sul valore di aggiungere (o a volte rimuovere) una o più caratteristiche e siamo adesso pronti ad affrontare futuri progetti più grandi.

Dopo le prime settimane di sviluppo, abbiamo cominciato a chiamare questo documento vivente come “toolkit in forma di guida di stile”. Questo ci ha fatto raggiungere l'obiettivo di comunicare il nostro lavoro attraverso Bootstrap, che a sua volta a permesso a Bootstrap di crescere rapidamente e di diventare utilizzabile da chiunque.

Bootstrap come guida di stile

La decisione di creare Bootstrap come una guida di stile è scaturita naturalmente da uno dei nostri processi di design e sviluppo. Bootstrap ci aiuta a documentare i componenti con degli esempi “live” man mano che li creiamo, mentre hanno la funzione di un documento vivo che si alimenta da solo, con i componenti ed i template che prescrive. Ci ha dato un singolo punto di riferimento per condividere i consigli da parte dei designer e ha creato della documentazione per ciascun componente attivo.

Creare Bootstrap come una guida di stile ha influenzato il suo sviluppo fin dall'inizio. Ci ha permesso di rimanere fedeli alle feature che volevamo implementare aiutandoci a guardare più in là che al singolo progetto. Non volevamo limitarci a realizzare un singolo progetto: avevamo ambizioni più grandi e non volevamo privarne noi stessi o coloro i quali avrebbe tratto dei benefici da un simile tool. Il nostro approccio ha reso possibile la realizzazione di tool non solo per Twitter, ma per tutti i designer e gli sviluppatori.

Soddisfare tutti i livelli di capacità

L'approccio da "documento vivente" ci ha dato la possibilità non solo di condividere l'intero toolkit, ma anche di fornire documentazione scritta ed interattiva per chiunque volesse usare Bootstrap. Questo approccio ha soddisfatto tutti indipendentemente dal livello di competenza, permettendo a chiunque di clonare o scaricare un repo per il codice sorgente o di usare Inspector o "visualizza sorgente" nel browser.

Con l'avanzare dello sviluppo, questo è diventato uno dei principi guida del nostro lavoro, inserito nel nostro credo: “Aiutare persone fantastiche a creare cose fantastiche”. Questo si è incastrato a coda di rondine con il nostro obiettivo di articolare chiaramente le decisioni di design e di sviluppo per coloro i quali non avevano le informazioni interne al processo o al prodotto originali. Non importa il livello di capacità o il workflow, avevamo bisogno che le persone fossero in grado di aprire questo documento vivente e di utilizzare Bootstrap per creare in maniera rapida e semplice qualcosa che amassero.

Evolversi attraverso la collaborazione

All'inizio, Bootstrap includeva solo la tipografia, le tabelle, le form, una guida al colore ed alcuni asset grafici. Era una guida alla best practice della presentazione, a come usare alcune regole di design usate in tutta l'azienda. A quell'epoca, avevamo solo bisogno di un reset CSS più personalizzato e delle risorse aziendali per aggiungere un minimo di eleganza allo sviluppo.

Fig. 2

Fig 2: Una delle primissime feature di uno dei nostri toolkit è stata una guida al colore.

Con il coinvolgimento di sempre più persone e sempre più applicazioni possibili, aumentava la richiesta di feature. Alla fine, abbiamo creato molte più componenti, inclusa una topbar fissa, la navigazione a tab, i dropdown menu, le form estese e altro ancora. Per tutto il processo, la collaborazione tra designer e sviluppatori è stata evidente in ogni nuovo componente che abbiamo aggiunto. La collaborazione ha reso possibili molte conversazioni gratificanti ed esaltanti e molte feature.

Fig. 3

Fig 3: La nostra release iniziale si concentrava sul supporto dei browser più recenti ed includeva meno componenti.

Al momento, Bootstrap include dozzine di componenti e molti altri sono già stati pianificati, che vengono però realizzati solo se i loro requisiti e la loro funzionalità sono già stati chiaramente individuati usando il processo che abbiamo stabilito in precedenza. Jacob ed io iteriamo sul toolkit gestendo le richieste di feature e tenendo traccia dei problemi e dei vari bug. Lavoriamo insieme alla valutazione di ciascun nuovo item per capirne l'utilità nella community. Implementiamo una nuova feature solo se non confonde gli utenti o se non gonfia il framework inutilmente. Aver impostato un processo che permette alle persone di valutare imparzialmente le nuove feature è incredibilmente potente e assolutamente necessario ai fini del progetto. La nostra collaborazione si è estesa ben oltre la portata di un singolo progetto e continua in tutti a partire da quel momento, specialmente in Bootstrap.

Riflessioni finali

Bootstrap è stato usato in test pratici per la prima volta nel mondo reale durante la prima Hackweek di Twitter. Durante quella settimana, ho aiutato alcune persone ad usare Bootstrap nei loro progetti per velocizzare lo sviluppo, ma non avevo idea di quanto efficace o diffuso sarebbe diventato il toolkit. Quando tutti i team si sono presentati davanti all'azienda per illustrare le loro idee, dozzine di loro stavano usando Bootstrap. Avevano usato Bootstrap per creare dei progetti che sembravano tutti come una famiglia di idee, con un design e un'implementazione consistenti. Un toolkit semplice, ben progettato e documentato ha fatto risparmiare moltissime ore con pochissimo o addirittura nessun aiuto da un designer scrupoloso.

In altre parole, ha funzionato!

Con il progetto ora disponibile a tutti e open source su GitHub, il nostro successo continua ed aiutiamo i nerd di tutto il mondo ad accelerare il loro sviluppo web. Il nostro processo di sviluppo per Bootstrap rimane identico, ma si è evoluto per sfruttare il ciclo costante di feedback GitHub attraverso il tracciamento di problemi e il wiki feature, per comunicare meglio con quelli che usano il toolkit. Perciò, abbiamo pubblicato un certo numero di release e ne abbiamo pianificate altre. La nostra prossima grande release sarà la v2, uno sforzo maggiore, che include un responsive grid system, estende i plugin JavaScript, risolve un'infinità di bug e migliora la documentazione.

Senza lo sviluppo parallelo e la collaborazione tra i vari team, Bootstrap non esisterebbe e avremmo creato un altro esemplare unico di tool. Internamente, i progetti come Bootstrap hanno cominciato a cambiare il modo in cui cooperiamo. Le domande tra i team hanno cominciato a cambiare da “fallo apparire più bello” o “programma questo” in “come posso risolvere questo problema?” e Bootstrap si nutre di questo. Il processo collaborativo ci ha aiutato a lavorare più efficientemente e a creare molta fiducia gli uni negli altri.

Grazie alla visione e alla concentrazione di un piccolo gruppo di designer e sviluppatori, siamo stati in grado di far evolvere il nostro processo di sviluppo, creare un esteso toolkit per il front-end ed aiutare migliaia di altre persone ha fare bootstrap sui progetti che hanno a cuore.

Illustrazioni: Carlo Brigatti

Share/Save/Bookmark
 

Discutiamone

Ti sembra interessante? Scrivi tu il primo commento


Cenni sull'autore

Mark Otto

Mark OttoMark Otto lavora in Twitter a San Francisco come designer di Twitter.com. Ha progettato e mantiene Bootstrap nel tempo libero, per aiutare persone stupende a creare cose stupende. Seguitelo su Twitter o visitate il suo blog.