Schizzi nel browser

Chiedi a qualsiasi team che lavora con un sistema di progettazione e scoprirai che i vantaggi sono chiari: i progettisti e gli sviluppatori sono più produttivi, i prodotti sono più coerenti, la comunicazione tra le discipline è più chiara.

Tuttavia, la maggior parte dei sistemi di progettazione presenta ancora un difetto fondamentale. Designer e sviluppatori continuano a lavorare su mezzi completamente diversi. Di conseguenza, senza un costante sforzo manuale per mantenerli sincronizzati, il nostro codice e le risorse di progettazione vanno costantemente allontanandosi sempre di più.

Per le aziende che lavorano con i sistemi di progettazione, sembra che il nostro settore sia bloccato con strumenti di progettazione che sono essenzialmente costruiti per il mezzo sbagliato, completamente incapaci di reinserire il nostro lavoro di sviluppo nel prossimo ciclo di progettazione.

Fortunatamente, questo sta per cambiare.

Home page della Guida allo stile SEEK

Il nostro viaggio nel sistema di progettazione

Alla SEEK, lavoriamo alla nostra guida sullo stile di vita da oltre un anno, con una suite in continua crescita di componenti React. Come ci si potrebbe aspettare, questo ha introdotto un cambiamento radicale nel modo in cui pensiamo al design visivo.

All'improvviso, abbiamo avuto un'unica fonte di verità, nel codice, facilmente installabile, che definiva il modo in cui il nostro marchio appare attraverso dozzine di progetti diversi.

Naturalmente, il nostro sistema di progettazione non è iniziato nel browser. Avevamo già trascorso molto tempo a cercare di formalizzare le nostre regole di progettazione in una forma più statica, molto prima che la nostra guida sullo stile di vita esistesse.

Quello che è iniziato come un PDF statico alla fine ha lasciato il posto a un kit di avvio di Sketch. Simboli, colori e stili di testo standardizzati potrebbero essere facilmente sfruttati come punto di partenza per qualsiasi nuovo lavoro di progettazione.

Il nostro kit iniziale di Sketch

Qualche tempo dopo, abbiamo sperimentato Craft, una suite di plugin Sketch di InVision, il più noto dei quali era il loro plugin Library.

Questo ci ha permesso di condividere i simboli di Sketch oltre i confini del documento e del team, creando una libreria di simboli condivisa per l'intera organizzazione.

Plugin della libreria di Craft

Ciò che è diventato immediatamente evidente è stata la mole di lavoro richiesto per mantenere aggiornata questa libreria, in particolare quando modelli nuovi ed esistenti sono in costante evoluzione attraverso i nostri prodotti.

Gli sviluppatori, spesso in associazione con i progettisti, apporterebbero modifiche al codice che potrebbero avere un impatto drammatico sulla progettazione visiva, ma la nostra libreria di progettazione statica rimarrebbe completamente intatta, a meno che, ovviamente, qualcuno abbia ricordato di tenerlo manualmente aggiornato, che di solito non è successo.

Nel frattempo, stavamo riscontrando esattamente gli stessi problemi di coerenza dall'altro lato della recinzione, con gli sviluppatori privi di una chiara fonte di verità per la progettazione nel loro codice.

Da React a reazioni-sketchapp

È stato in questo periodo che abbiamo iniziato a lavorare al nostro primo progetto React - reso da server, alimentato da webpack e moduli CSS (che abbiamo contribuito a co-creare lungo la strada) - portando alla realizzazione della nostra guida sullo stile di vita.

L'attenzione singolare di React sui componenti ha reso questa transizione quasi inevitabile. Non sorprende che, dalla sua uscita, abbiamo visto storie simili recitare in innumerevoli altre società in tutto il mondo.

Dopo aver creato una considerevole collezione di componenti, altri team che lavoravano a nuovi progetti hanno rapidamente sfruttato il nostro lavoro, ma poiché la nostra guida di stile era composta da componenti React e meno stili, è stato di scarsa utilità per i nostri progettisti. Tuttavia, questo non si è rivelato un problema immediato per noi. La disconnessione tecnica tra designer e sviluppatori è un problema secolare, che è stato per così tanto tempo con il nostro settore che siamo in gran parte addestrati per ignorarlo.

Questo è stato, ovviamente, fino a quando abbiamo visto reazioni-sketchapp.

React-sketchapp
“In Sketch, utilizziamo simboli e sostituzioni, in React utilizziamo componenti e proprietà. I concetti sono così simili che sembrava sciocco non unificarli. "
Jon Gold, Airbnb

Non potevamo credere ai nostri occhi. Qui abbiamo avuto il vero codice React, renderizzato direttamente in Sketch. Sembrava che sia gli sviluppatori che i designer sarebbero stati finalmente in grado di sfruttare l'unica fonte di verità di un sistema di progettazione.

Con le nostre regole di progettazione definite centralmente nel codice, non saremmo solo in grado di alimentare le nostre applicazioni di produzione, ma saremmo anche in grado di reinserire il nostro lavoro negli strumenti che i nostri progettisti stavano già utilizzando. Man mano che le nostre regole di progettazione continuavano a evolversi, saremmo automaticamente in grado di mantenere aggiornati i nostri progettisti, senza alcuna traduzione manuale in Sketch.

Naturalmente, una volta scavato un po 'più in là, abbiamo scoperto che la reattività-sketchapp è arrivata con alcuni requisiti.

  1. I componenti dovevano essere costruiti con React (ovviamente). Fortunatamente, stavamo già usando React, quindi questo non era un problema.
  2. Gli stili dovevano essere definiti in JavaScript. Nel nostro caso, dal momento che il nostro sistema di progettazione è stato creato con i moduli CSS, ci siamo già imbattuti in un ostacolo. Siamo grandi fan di CSS-in-JS, ma non avremmo rivisto il nostro stile su tutto l'ecosistema, almeno non di fretta.
  3. I componenti dovevano usare primitive generiche (Visualizza, Testo, Foglio di stile) anziché primitive del browser, usando qualcosa come reagenti primitivi. In sostanza, la reazione-sketchapp era più vicina a React Native che a Vanilla React. Ancora una volta, questo è qualcosa su cui potremmo migrare in modo fattibile, ma richiederebbe molto lavoro, e forse alcuni compromessi lungo la strada.

Quindi, sebbene il reattivo-sketchapp sia un progetto straordinario che consigliamo vivamente di cuore, i suoi requisiti tecnici purtroppo hanno significato che non saremmo stati in grado di utilizzarlo nel breve-medio termine.

Anche se abbiamo deciso di migrare la nostra libreria di componenti, nel frattempo avevamo bisogno di un'altra risposta.

Porta il design al controllo della versione

Come forse già saprai, ora sono disponibili strumenti che ti consentono di utilizzare il controllo versione all'interno dei tuoi strumenti di progettazione, ma questo è completamente indietro.

Dobbiamo portare i nostri strumenti di progettazione al controllo della versione, non viceversa. Abbiamo bisogno di risorse di progettazione per stare fianco a fianco con qualsiasi altro tipo di risorsa, non archiviate in un silo incentrato sul design, ospitato in un giardino recintato di proprietà.

Quindi abbiamo provato qualcosa di diverso.

Usando Kactus e alcuni script Node personalizzati, abbiamo sperimentato il commit di file Sketch nel nostro repository della guida di stile.

Kactus, mostrando un git diff per un file Sketch

Sebbene siamo stati in grado di raggiungere questo risultato tecnicamente, siamo rimasti delusi dal constatare che il flusso di lavoro non ha mai funzionato come speravamo, almeno per il nostro caso d'uso. Mantenere sincronizzati due formati radicalmente diversi era estremamente noioso, soggetto a errori e difficile da rivedere.

Il mantenimento di file di codice e di schizzo nella stessa posizione potrebbe aver contribuito a chiarire il problema, ma non ha aiutato molto a risolverlo effettivamente. A peggiorare le cose, ha introdotto un sacco di attrito extra per i collaboratori della guida di stile per un guadagno apparentemente piccolo. I file di Sketch sono stati rapidamente trascurati. Per noi è stato un esperimento fallito.

Ma poi - proprio quando sentivamo di aver perso la speranza di riunire designer e sviluppatori nello stesso progetto - html-sketchapp è arrivato e ha cambiato tutto.

L'emergere di html-sketchapp

Si è scoperto che non eravamo i soli ad avere problemi a integrare reagire-sketchapp nel loro stack tecnologico esistente.

"Non siamo stati in grado di aggirare rapidamente queste limitazioni, quindi abbiamo creato html-sketchapp."
Konrad Dzwinel, Brainly

Con html-sketchapp, hanno adottato un approccio radicalmente diverso.

Come suggerirebbe il nome, html-sketchapp ti consente di generare file di Sketch da normali contenuti HTML, ma a differenza di reazione-sketchapp, non ci sono restrizioni sulle scelte tecnologiche nella tua applicazione.

Puoi creare la tua app con Preact, o Vue, o Angular, o Backbone o jQuery, o persino Ruby o PHP.

Potresti comunque usare React, ovviamente, ma ora puoi modellarlo come preferisci, usando qualunque primitivo avesse senso per il tuo progetto.

Il contratto è stato incredibilmente semplice: finché hai generato HTML, puoi importarlo in Sketch.

Generazione di file di schizzo

A prima vista, questa sembrava magia, ma quando abbiamo dato un'occhiata sotto il cofano, abbiamo rapidamente scoperto che in realtà non è poi così complicato.

Per capire come funziona html-sketchapp, devi prima capire il formato del file di Sketch. Abbastanza sorprendentemente, i file di Sketch sono in realtà solo file Zip.

Una volta aggiornati, i file di Sketch sono principalmente costituiti da file JSON che, ovviamente, possono essere aperti in qualsiasi normale editor di testo.

Se dai un'occhiata al contenuto di questi file, vedrai che si tratta di un formato relativamente semplice, costituito essenzialmente da una manciata di classi nidificate.

Al suo livello più basso, html-sketchapp ti consente di generare in modo programmatico istanze di queste classi e convertirle in JSON, ma va molto oltre.

La funzione più potente in html-sketchapp è "nodeToSketchLayers", che ti dà la possibilità di convertire un singolo elemento del browser in una matrice di livelli di Sketch. È qui che accade la maggior parte della magia, poiché contiene tutta la logica per estrarre gli stili del browser e convertirli nei loro equivalenti di Sketch.

Ciò che unisce davvero tutto questo è la classe "SymbolMaster", che ti consente di generare dinamicamente simboli Sketch. Poiché i simboli costituiscono la base di qualsiasi libreria Sketch, questo ci ha permesso di esporre selettivamente un set di componenti ai nostri progettisti, basato direttamente sul codice sottostante.

Sfortunatamente, a causa di alcune limitazioni nell'attuale formato di Sketch con il modo in cui gli stili di testo sono codificati, i documenti generati non sono file di Sketch abbastanza validi: html-sketchapp si riferisce a loro come file "Quasi Sketch", o "asketch" in breve. Di conseguenza, devono essere importati manualmente tramite il plug-in Sketch di html-sketchapp. Per fortuna, questo processo non è troppo difficile.

Il cablaggio di tutti questi passaggi insieme sembrava inizialmente un po 'scoraggiante, ma si è scoperto che su GitHub esisteva già un progetto di esempio che mostrava come convertire una guida di stile esistente in un documento di Sketch.

Non appena l'abbiamo visto, non ci è voluto molto tempo per iniziare a sperimentare e ci è voluto un tempo sorprendentemente piccolo prima di iniziare a vedere risultati davvero sorprendenti.

Sperimentando con html-sketchapp

In primo luogo, per avere un'idea di ciò che era possibile, lo abbiamo indicato nella home page del sito Web della nostra guida di stile.

Successivamente, abbiamo iniziato a generare i nostri primi simboli dal nostro componente "Pulsante", presentando alcune varianti diverse.

Per raggiungere questo obiettivo, abbiamo trovato una convenzione per l'aggiunta di un file JavaScript speciale all'interno di ogni cartella dei componenti (ad esempio Button.sketch.js), definendo i simboli che volevamo esportare.

Ogni file esporrebbe un oggetto definendo i nomi dei simboli e i loro corrispondenti elementi React.

import React da 'reagire';
pulsante import da './Button';
export const simboli = {
  "Button / Pink": ,
  "Button / Blue": ,
  'Button / Transparent': ,
};

Abbiamo quindi creato uno speciale percorso nascosto sul nostro sito della guida di stile che ha importato qualsiasi file che termina in ".sketch.js" e ha reso gli elementi React forniti sullo schermo. Con questo approccio, siamo stati in grado di semplificare notevolmente il processo di conversione esponendo tutti i contenuti di Sketch su una singola pagina.

Ogni istanza di simbolo è stata racchiusa in un elemento div con il suo nome definito in un attributo di dati, che ci ha permesso di selezionare e nominare facilmente ogni simbolo sulla pagina.

  ...

Questo modello si è rivelato molto efficace e lo abbiamo presto ampliato per includere stili di testo e colori dei documenti.

Poiché la nostra guida di stile è reattiva, abbiamo quindi automatizzato il processo di ridimensionamento della finestra del browser e la creazione di istantanee di simboli con dimensioni dello schermo diverse.

Ora potremmo aggiungere, rimuovere e rinominare le dimensioni della finestra in un'unica posizione e ogni singolo simbolo verrebbe rigenerato per riflettere questi nuovi valori. In un sol colpo, sembrava che avessimo risolto uno dei problemi più noiosi con il mantenimento di una libreria di Sketch reattiva.

Mentre tutto è andato sorprendentemente senza intoppi, abbiamo dovuto aggiungere alcune soluzioni alternative per supportare Sketch, nello stesso modo in cui potresti supportare le implementazioni del browser con errori, ma siamo riusciti a localizzarli in un singolo file.

Dall'esperimento alla produzione

Quello che era iniziato come un esperimento su piccola scala si era rapidamente trasformato in una sorta di mini-framework. A questo punto, non ci è voluto molto lavoro per integrarlo correttamente nella nostra guida di stile, in esecuzione come parte del nostro processo di costruzione standard.

Se osservi la richiesta pull, tuttavia, vedrai che ci ha richiesto di includere un sacco di codice di cablaggio aggiuntivo e dipendenze, anche se, ad un livello elevato, stavamo cercando di realizzare un singolo compito concettualmente semplice.

Per generare la nostra libreria Sketch, abbiamo dovuto eseguire i seguenti passaggi:

  • Compilare uno script del browser con webpack, contenente html-sketchapp e la logica di accompagnamento per la selezione e la conversione di elementi.
  • Avviare un server Web statico su qualsiasi porta disponibile.
  • Open Puppeteer (una versione senza testa di Chromium).
  • Passa all'URL corretto.
  • Iniettare lo script compilato nell'istanza Puppeteer in esecuzione.
  • Ridimensiona la finestra del browser più volte, scattando istantanee per ogni dimensione dello schermo configurata chiamando le funzioni definite nel nostro script compilato.
  • Scrivi i file JSON risultanti sul disco.
  • Chiudere il server Web statico.
  • Chiudi il browser senza testa.

Ci è sembrato ovvio che questo potrebbe essere facilmente semplificato in un singolo comando, uno che ci consentirebbe semplicemente di puntare a un URL e iniziare a scattare istantanee.

Questo è quello che abbiamo fatto.

Presentazione di html-sketchapp-cli

Meno di un mese dopo la prima integrazione di html-sketchapp nella nostra guida di stile, apriamo html-sketchapp-cli di provenienza, una piccola utility da riga di comando per toglierti tutto questo codice idraulico.

Ora, potremmo ottenere la stessa cosa con una singola dipendenza e un semplice file di configurazione dichiarativo.

module.exports = {
  servire: "docs / dist",
  url: "/ sketch-exports",
  outDir: 'dist / asketch',
  finestre: {
    "Desktop": "1024x768",
    "Mobile Plus": "414x736",
    "Cellulare": "320x568"
  }
};

Non sorprende che, quando abbiamo usato html-sketchapp-cli nella nostra guida di stile, siamo riusciti a eliminare molto codice.

Pipeline di progettazione continua

Tutti questi strumenti fanno ora parte della nostra pipeline di consegna continua standard, che ci consente di espandere la portata del nostro codice, spostandoci oltre la comunità degli sviluppatori e supportando i nostri progettisti nel loro lavoro quotidiano.

Su ogni build di successo della guida di stile — non solo distribuiamo automaticamente il nostro sito sulle pagine GitHub (usando gh-pages) e pubblichiamo la libreria dei componenti su npm (usando la versione semantica) — ora generiamo automaticamente file 'Quasi schizzo', pronto per essere importato e convertito nella nostra libreria ufficiale di Sketch.

Questa libreria Sketch viene quindi distribuita tramite l'unità condivisa del nostro team di progettazione, il che significa che i nostri designer hanno sempre una copia aggiornata della libreria, sincronizzandosi in tempo reale, anche quando Sketch è aperto.

Grazie al nuovo supporto della libreria integrata di Sketch, i progettisti sono immediatamente in grado di aprire il menu "SEEK Style Guide Library" e iniziare a selezionare i componenti, sapendo che le convenzioni di denominazione e lo stile visivo corrispondono alle aspettative degli sviluppatori nei loro team.

Da quando è stato introdotto, abbiamo visto le modifiche al nostro codice che fluiscono continuamente in Sketch, a volte quando chi apporta le modifiche non ha nemmeno Sketch installato sui propri computer. Poiché la guida di stile è collegata alle nostre applicazioni di produzione, viene costantemente migliorata da persone di tutta l'organizzazione e ora possiamo garantire che tutti questi miglioramenti continuino a mantenere la nostra libreria Sketch fresca e aggiornata.

Anche se tecnicamente stanno ancora lavorando su mezzi diversi, stiamo lavorando duramente per creare l'illusione di una singola lingua unificata.

Quindi, dove da qui?

Per quanto questo sviluppo sia stato per noi, stiamo ancora vedendo questo come una soluzione temporanea. Il rendering di contenuti Web in Sketch è incredibilmente potente e rappresenta un passo avanti necessario nel nostro viaggio, ma il nostro settore deve spingersi oltre.

La linea tra i nostri mezzi potrebbe diventare sfocata, ma gli strumenti di progettazione del futuro devono rimuovere del tutto questa linea. Per poter veramente sfruttare questo potenziale, abbiamo bisogno di strumenti di progettazione che non imitino semplicemente il mezzo di destinazione, ma abbiamo bisogno che siano effettivamente basati su di esso.

Fortunatamente, non c'è carenza di persone che lavorano su questo problema in questo momento. Strumenti come Compositor, Interplay, Alva, Haiku, Webflow e UXPin stanno cercando di abbattere i muri tecnici tra gli strumenti di progettazione e il codice sottostante, e ci sono altri strumenti come questo in arrivo.

Chissà, potremmo persino iniziare a vedere strumenti di progettazione più tradizionali adottare questo approccio per rimanere pertinenti, in particolare poiché i sistemi di progettazione continuano a diventare una parte standard del moderno toolkit di progettazione.

Nel frattempo, mentre aspettiamo nuovi strumenti di progettazione che abbracciano veramente i principi che guidano l'era dei sistemi di progettazione, progetti come reazioni-sketchapp e html-sketchapp stanno facendo un lavoro stupefacente nel prepararci a questo nuovo modo di pensare oggi.

Francamente, non c'è mai stato un momento migliore per iniziare.