Luonnos selaimessa

Kysy jokaiselta suunnittelujärjestelmää käyttävältä tiimiltä. Löydät edut selkeästi - suunnittelijat ja kehittäjät ovat tuottavampia, tuotteet ovat johdonmukaisempia, tieteiden välinen viestintä on selkeämpää.

Useimmissa suunnittelujärjestelmissä on kuitenkin edelleen olennainen virhe. Suunnittelijat ja kehittäjät toimivat edelleen täysin erilaisilla välineillä. Seurauksena on, että ilman jatkuvaa, manuaalista pyrkimystä pitää ne synkronoituna, koodi- ja suunnitteluomaisuutemme ajautuvat jatkuvasti yhä pidemmälle toisistaan.

Suunnittelujärjestelmien parissa työskenteleville yrityksille näyttää siltä, ​​että alamme on juuttunut suunnittelutyökaluihin, jotka on rakennettu pääasiassa väärälle välineelle - täysin kykenemätöntä syöttämään kehitystyötämme takaisin seuraavaan suunnittelukierrokseen.

Onneksi tämä on kaikki muuttumassa.

SEEK Style Guide -sivu

Suunnittelujärjestelmän matkamme

Olemme SEEKissä työskennellyt elämäntyyli-oppaamme jo yli vuoden ajan jatkuvasti kasvavan React-komponenttien kanssa. Kuten saatat odottaa, tämä on ottanut käyttöön radikaalin muutoksen ajattelussa visuaalisesta suunnittelusta.

Yhtäkkiä meillä oli yksi totuuden lähde, koodilla, helposti asennettavissa, mikä määritteli kuinka brändimme näkyy kymmenissä erilaisissa projekteissa.

Luonnollisesti suunnittelujärjestelmätyömme ei alkanut selaimesta. Vietimme jo paljon aikaa yrittäessämme muotoilla suunnittelussäännöt staattisemmassa muodossa - kauan ennen kuin elävän tyylin oppaamme koskaan olemassa.

Se, joka alkoi staattisena PDF-tiedostona, antoi lopulta tien Sketch-aloituspakettiin. Vakioidut symbolit, värit ja tekstityylit voitaisiin helposti hyödyntää uuden suunnittelutyön lähtökohtana.

Alkuperäinen Sketch-aloitussarja

Jonkin ajan kuluttua kokeilimme Craftia, InVisionin Sketch-laajennusten sarjaa, joista merkittävin on heidän Library-laajennus.

Tämän ansiosta voimme jakaa Sketch-symbolit sekä dokumenttien että ryhmien rajojen yli, rakentaen jaetun symbolikirjaston koko organisaatiolle.

Craft's Library -laajennus

Heti ilmeni, että kirjaston pitämiseksi ajan tasalla tarvitaan paljon työtä, etenkin kun uusia ja olemassa olevia malleja kehittyy jatkuvasti tuotteidemme välillä.

Kehittäjät, jotka pariksi muodostuvat usein suunnittelijoiden kanssa, tekisivät muutoksia koodiin, jolla voi olla dramaattinen vaikutus visuaaliseen suunnitteluun, mutta staattinen suunnittelukirjastomme pysyisi täysin koskemattomana - ellei tietysti joku muistaisi pitää sitä manuaalisesti ajan tasalla, mikä yleensä ei tapahtunut.

Samaan aikaan meillä oli tarkalleen samat johdonmukaisuusongelmat aidan toisella puolella, kehittäjiltä puuttui selkeä totuuden lähde suunnittelusta koodissaan.

Reaktista reagoimaan-luonnoskuva

Se oli noin tällä kertaa, kun aloitimme ensimmäisen React-projektimme - palvelimen tarjoaman, verkkopakkauksesta saatavan ja CSS-moduulien (joita autimme yhdessä luomaan matkan varrella) - johtamisen, joka johti tasapuolisesti elämäntyyliin liittyvän oppaan luomiseen.

Reaktin yksittäinen keskittyminen komponentteihin teki tämän siirtymisen lähes väistämättömäksi. Ei ole yllättävää, että julkaisun jälkeen olemme nähneet samanlaisia ​​tarinoita lukemattomissa muissa yrityksissä ympäri maailmaa.

Kun olimme rakentaneet mittavan komponentekokoelman, muut uusien projektien parissa työskentelevät ryhmät käyttivät nopeasti hyötyä työstämme - mutta koska tyyliopas koostui React-komponenteista ja vähemmän tyyleistä, siitä ei ollut hyötyä suunnittelijoillemme. Tämä ei kuitenkaan eronnut meille välittömänä asiana. Suunnittelijoiden ja kehittäjien välinen tekninen katkaiseminen on vanha ongelma - ongelma, joka on ollut teollisuudessamme niin kauan, että olemme suurelta osin koulutettuja sivuuttamaan sen.

Se oli tietysti siihen asti, kunnes näimme reagoi-luonnoksen.

Reagoivat-sketchapp
”Luonnoksessa käytämme symboleja ja ohituksia, Reaktissa komponentteja ja ominaisuuksia. Käsitteet ovat niin samanlaisia, että tuntui typerältä olla yhdistämättä niitä. ”
Jon Gold, Airbnb

Emme voineet uskoa silmäämme. Täällä meillä oli todellinen React-koodi, joka muuttui suoraan Sketchiksi. Näytti siltä, ​​että sekä kehittäjät että suunnittelijat kykenevät vihdoin hyödyntämään suunnittelujärjestelmän ainoata totuuden lähdettä.

Suunnittelusääntöjemme kanssa, jotka on määritelty keskitetysti koodissa, emme pysty vain tuottamaan tuotantosovelluksiamme, vaan voimme myös palauttaa työmme takaisin työkaluihin, joita suunnittelijamme olivat jo käyttäneet. Suunnittelusääntöjemme kehitystyön myötä pystyimme automaattisesti pitämään suunnittelijamme ajan tasalla ilman mitään manuaalista käännöstä takaisin Sketchiin.

Tietenkin, kun kaivoimme vähän kauempana, huomasimme, että react-sketchapp -sovelluksessa oli muutamia vaatimuksia.

  1. Komponentit oli rakennettava Reaktin kanssa (ilmeisesti). Onneksi olimme jo käyttäneet Reaktia, joten tämä ei ollut ongelma.
  2. Tyylit on määritettävä JavaScriptillä. Koska suunnittelujärjestelmämme on rakennettu CSS-moduuleilla, olimme tapauksessamme jo joutuneet hiukan esteeseen. Olemme CSS-in-JS: n suuria faneja, mutta emme olleet aikeissa uudistaa tyyliämme koko ekosysteemissä - ainakaan kiireesti.
  3. Komponentit, joita tarvitaan yleisten primitiivien (View, Text, StyleSheet) käyttämiseen selaimen primitiivien sijasta käyttämällä jotain react-primitives. Pohjimmiltaan react-sketchapp oli lähempänä React Native kuin vanilla React. Tämä on jälleen asia, johon voimme helposti siirtää, mutta se vaatisi paljon työtä - ja mahdollisesti muutamaa vaihtoa matkan varrella.

Joten vaikka react-sketchapp on hämmästyttävä projekti, jota suosittelemme koko sydämestämme, sen tekniset vaatimukset tarkoittivat valitettavasti sitä, ettemme voisi käyttää sitä lyhyellä tai keskipitkällä aikavälillä.

Vaikka päätimme siirtää komponenttikirjastomme, tarvitsimme sillä välin toisen vastauksen.

Suunnittelun tuominen versionhallintaan

Kuten ehkä jo tiedät, nyt on saatavana työkaluja, joiden avulla voit käyttää versionhallintaa suunnittelutyökalujen sisällä - mutta tämä on täysin taaksepäin.

Meidän on saatettava suunnittelutyökalumme versionhallintaan, ei päinvastoin. Tarvitsemme suunnittelumahdollisuuksia istuaksemme vierekkäin minkä tahansa muun omaisuuslajin kanssa - jota ei ole varastoitu suunnittelukeskeiseen siiloon, jota isännöidään omalla muurilla varustetussa puutarhassa.

Joten yritimme jotain erilaista.

Käyttämällä Kactusta ja joitain mukautettuja Node-skriptejä, kokeilimme Sketch-tiedostojen tekemistä tyyliopasvarastoon.

Kactus, osoittaen git diff Sketch-tiedostolle

Vaikka pystyimme saavuttamaan tämän teknisesti, olimme pettyneitä huomatessamme, että työnkulku ei koskaan toiminut toivotulla tavalla - ainakin käyttötapauksemme kannalta. Kahden radikaalisti erilaisen muodon pitäminen synkronoinnissa oli erittäin työlästä, virhealtista ja vaikea tarkistaa.

Koodi- ja luonnetiedostojen pitäminen samassa paikassa on saattanut auttaa selventämään ongelmaa, mutta se ei auttanut paljon ongelman ratkaisemisessa. Asioiden vaikeuttamiseksi se toi mukanaan paljon ylimääräistä kitkaa tyylioppaiden avustajille näennäisesti pienen voiton saamiseksi. Sketch-tiedostot jätettiin nopeasti huomiotta. Meille se oli epäonnistunut kokeilu.

Mutta sitten - heti kun tunsimme kadonneen toivomme saattaa suunnittelijat ja kehittäjät yhteen samassa projektissa - html-sketchapp tuli mukana ja muutti kaiken.

Html-sketchappin syntyminen

Kävi ilmi, että meillä ei ollut ainoita, joilla oli vaikeuksia integroida react-sketchapp nykyiseen tekniikkapinoon.

"Emme pystyneet kiertämään näitä rajoituksia nopeasti, joten loimme html-sketchapp".
Konrad Dzwinel, Brainly

Html-sketchapp -sovelluksella he käyttivät radikaalisti erilaista lähestymistapaa.

Kuten nimestä voi päätellä, html-sketchapp antaa sinun luoda Sketch-tiedostoja tavallisesta HTML-sisällöstä - mutta toisin kuin react-sketchapp, sovelluksessasi ei ole rajoituksia tekniikan valinnalle.

Voit rakentaa sovelluksesi Preactilla, Vuellä, Kulmaisella, Selkärangalla tai jQueryllä - tai jopa Rubyllä tai PHP: llä.

Voisit silti käyttää Reaktia, tietenkin, mutta nyt voit muotoilla sen haluamallasi tavalla käyttämällä kaikkia projektisi kannalta järkeviä alkukankaita.

Sopimus oli uskomattoman suoraviivainen - niin kauan kuin olet luonut HTML-koodin, voit tuoda sen Sketchiin.

Luomalla Sketch-tiedostoja

Ensi silmäyksellä tämä näytti taikuulta, mutta kun katselimme konepellin alla, huomasimme nopeasti, että se ei oikeastaan ​​ole niin monimutkainen.

Ymmärtääksesi, kuinka html-sketchapp toimii, sinun on ensin ymmärrettävä Sketchin tiedostomuoto. Yllättäen luonnokset ovat todella vain ZIP-tiedostoja.

Kun luettelotiedostot on upotettu, ne tehdään pääosin JSON-tiedostoista, jotka voidaan tietysti avata missä tahansa tavallisessa tekstieditorissa.

Jos tarkastelet näiden tiedostojen sisältöä, huomaat, että se on suhteellisen yksinkertainen muoto, joka on pääosin tehty pienestä kourallisesta sisäkkäisestä luokasta.

Alimmalla tasolla html-sketchapp antaa sinun tuottaa ohjelmallisesti näiden luokkien esiintymät ja muuntaa ne JSON: ksi - mutta se menee paljon pidemmälle.

Html-sketchappin tehokkain toiminto on 'nodeToSketchLayers', joka antaa sinulle mahdollisuuden muuntaa yhden selainelementin luonnoksiksi Sketch-tasoja. Tässä tapahtuu suurin osa taikuudesta, koska se sisältää kaiken logiikan selaintityylien purkamiseksi ja muuntamiseksi niiden Sketch-vastaavuuksiksi.

Tämän kaiken todella yhdistää 'SymbolMaster' -luokka, jonka avulla voit luoda dynaamisesti Sketch-symboleja. Koska symbolit ovat minkä tahansa Sketch-kirjaston perusta, sen avulla voimme valikoivasti paljastaa komponenttijoukon suunnittelijoillemme suoraan perustuen alla olevaan koodiin.

Valitettavasti nykyisessä Sketch-muodossa on joitakin rajoituksia tekstityylien koodaamiseen, luodut asiakirjat eivät ole aivan kelvollisia Sketch-tiedostoja - html-sketchapp viittaa niihin nimellä ”Melkein Sketch” tai ”asketch”. Seurauksena on, että ne on tuotava manuaalisesti html-sketchapp Sketch -laajennuksen kautta. Onneksi tämä prosessi ei ole liian vaikea.

Kaikkien näiden vaiheiden kytkeminen kokonaan kuulosti aluksi pelottavalta, mutta osoittautui, että GitHubissa oli jo esimerkkihanke, joka osoitti, kuinka muuntaa olemassa oleva tyyliopas Sketch-asiakirjaksi.

Heti kun huomasimme tämän, ei kulunut kauan kokeilun aloittamiseen, ja kesti yllättävän vähän aikaa, ennen kuin aloimme nähdä todella hätkähdyttäviä tuloksia.

Kokeilu html-sketchappilla

Ensinnäkin saadaksemme käsityksen siitä, mikä oli mahdollista, osoitimme sen tyylioppaan verkkosivustomme kotisivulle.

Seuraavaksi aloimme tuottaa ensimmäisiä symboleja Button-komponentistamme, tuottaa muutamia erilaisia ​​variantteja.

Tämän saavuttamiseksi keksimme tavan lisätä erityinen JavaScript-tiedosto jokaiseen komponenttikansioon (esim. Button.sketch.js) määrittelemällä symbolit, jotka halusimme viedä.

Jokainen tiedosto viemään objektin, joka määrittelee symbolien nimet ja niitä vastaavat React-elementit.

tuo reagoida 'reagoida';
Tuo painike './painikkeesta';
vie const-symbolit = {
  'Button / Pink': ,
  'Button / Blue': ,
  'Painike / läpinäkyvä': ,
};

Sitten loimme erityisen piilotetun reitin tyyliopasivustoomme, joka toi kaikki tiedostot, jotka päättyvät '.sketch.js', ja toimitti toimitetut React-elementit näytölle. Tätä lähestymistapaa noudattaen pystyimme yksinkertaistamaan huomattavasti muuntamisprosessia paljastamalla kaikki Sketch-sisällöt yhdellä sivulla.

Jokainen symboliesimerkki oli kääritty div-elementtiin nimellä, joka määritettiin dataominaisuudessa, minkä avulla voimme helposti valita ja nimetä kaikki sivun symbolit.

  ...

Tämä kuvio osoittautui erittäin tehokkaaksi, ja laajensimme sitä pian sisällyttämään siihen tekstityylit ja asiakirjan värit.

Koska tyyliopasmme on reagoiva, automatisoimme sitten selainikkunan koon muuttamisen ja symbolikuvien ottamisen erikokoisilla näytöillä.

Voimme nyt lisätä, poistaa ja nimetä näkymäkokoja yhdessä paikassa, ja jokainen symboli luodaan uudelleen näiden uusien arvojen heijastamiseksi. Yhdessä huippua näytti siltä, ​​että olemme ratkaisseet yhden tylsimmistä ongelmista ylläpitämällä reagoivaa Sketch-kirjastoa.

Vaikka kaikki meni yllättävän sujuvasti, meidän piti lisätä muutama kiertotapa erityisesti Sketchin tukemiseksi - samalla tavalla kuin saatat tukea vikailmoitettujen selainten toteutuksia -, mutta onnistuimme lokalisoimaan ne yhteen tiedostoon.

Kokeesta tuotantoon

Se, mikä alkoi pienimuotoisena kokeiluna, oli nopeasti muuttunut jotain minikehyksestä. Tässä vaiheessa meidän ei tarvinnut tehdä paljon työtä saadaksemme sen asianmukaisesti osaksi tyyliopasamme, joka toimii osana normaalia rakennusprosessiamme.

Jos tarkastelet vetopyyntöä, huomaat kuitenkin, että se vaatii meitä sisällyttämään paljon ylimääräisiä johdotuskoodeja ja riippuvuuksia, vaikkakin - korkealla tasolla - yritimme saavuttaa yhden, käsitteellisesti yksinkertaisen tehtävän.

Luomalla Sketch-kirjasto meidän piti suorittaa seuraavat vaiheet:

  • Käännä selainohjelma webpackilla, joka sisältää html-sketchapp ja siihen liittyvän logiikan elementtien valitsemiseksi ja muuntamiseksi.
  • Käynnistä staattinen web-palvelin kaikista käytettävissä olevista porteista.
  • Avaa Puppeteer (päättömät Chromium-versiot).
  • Siirry oikeaan URL-osoitteeseen.
  • Pistä koottu komentosarja käynnissä olevaan Puppeteer-ilmentymään.
  • Muuta selainikkunan kokoa useita kertoja ottamalla valokuvia jokaiselle määritettyyn näytön kokoon kutsumalla koottuun skriptiin määritellyt toiminnot.
  • Kirjoita tuloksena olevat JSON-tiedostot levylle.
  • Sammuta staattinen web-palvelin.
  • Sammuta päättömät selaimet.

Meille näytti itsestään selvältä, että tätä voidaan helposti virtaviivaistaa yhdellä komennolla - sellaisella, jonka avulla voimme yksinkertaisesti osoittaa URL-osoitteen ja alkaa ottaa kuvia.

Joten mitä me teimme.

Html-sketchapp-cli paljastaminen

Alle kuukauden kuluttua siitä, kun olemme integroineet html-sketchapp -sovelluksen ensin tyylioppaaseemme, avaamme lähteen html-sketchapp-cli, pieni komentoriviohjelma, joka ottaa kaiken tämän putkityökoodin käsistäsi.

Nyt voisimme saavuttaa saman asian yhdellä riippuvuudella ja yksinkertaisella, deklaratiivisella konfigurointitiedostolla.

module.exports = {
  tarjoa: 'docs / dist',
  URL: '/ luonnosvienti',
  outDir: 'dist / asketch',
  näyttöportit: {
    'Työpöytä': '1024x768',
    'Mobile Plus': '414x736',
    'Mobiili': '320x568'
  }
};

Ei ole yllättävää, että kun käytimme html-sketchapp-cli -tyyliopasamme, pystyimme poistamaan paljon koodia.

Jatkuva suunnittelu putkisto

Kaikki tämä työkalu on nyt osa tavanomaista jatkuvatoimitusprojektiamme, joka antaa meille mahdollisuuden laajentaa koodimme ulottuvuutta - siirtyä kehittäjäyhteisön ulkopuolelle ja tukea suunnittelijamme heidän päivittäisessä työssään.

Jokaisessa onnistuneessa tyylioppaan rakennuksessa - emme vain siirrä sivustoamme automaattisesti GitHub-sivuille (käyttämällä gh-sivuja) ja julkaisemme komponenttikirjasto npm: iin (käyttämällä semanttista julkaisua) - luomme nyt automaattisesti 'melkein Sketch'-tiedostot, valmis tuotavaksi ja muunnettavissa viralliseksi Sketch-kirjastoomme.

Tämä luonnoksikirjasto jaetaan sitten suunnittelutiimimme yhteisen aseman kautta, mikä tarkoittaa, että suunnittelijoillamme on aina ajantasainen kopio kirjastosta, joka synkronoituu reaaliajassa, jopa luonnoksen ollessa avoinna.

Sketchin uuden sisäänrakennetun kirjastotuen ansiosta suunnittelijat voivat heti avata ”SEEK Style Guide Library” -valikon ja aloittaa komponenttien valinnan tietäen, että nimeämiskäytännöt ja visuaalinen muotoilu vastaavat kehittäjien heidän tiiminsä odotuksia.

Siitä lähtien, kun tämä otettiin käyttöön, olemme nähneet muutoksia koodiin jatkuvasti Sketchissä - toisinaan silloin, kun muutoksia tekeneillä ei ole edes Sketchiä asennettuna koneisiinsa. Koska tyyliopas on liitetty tuotantosovelluksiin, sitä kehitetään jatkuvasti ihmisiltä kaikkialla organisaatiossa, ja voimme nyt varmistaa, että kaikki nämä parannukset pitävät Sketch-kirjastomme tuoreena ja ajan tasalla.

Vaikka he teknisesti edelleen työskentelevät erilaisilla välineillä, työskentelemme ahkerasti luodakseen yhtenäisen kielen illuusion.

Joten, mistä täältä?

Niin suuri kuin tämä kehitys on ollut meille, näemme sitä edelleen vain väliaikaisena ratkaisuna. Verkkosisällön tekeminen Sketchiksi on uskomattoman tehokasta ja välttämätöntä askelta eteenpäin matkallamme, mutta teollisuutemme on viedä tätä vielä pidemmälle.

Raja väliaineidemme välillä saattaa olla epäselvä, mutta tulevaisuuden suunnittelutyökalujen on poistettava tämä viiva kokonaan. Jotta voimme todella hyödyntää tätä potentiaalia, tarvitsemme suunnittelutyökaluja, jotka eivät vain jäljittele kohdeväliainetta - tarvitsemme niiden tosiasiallisen rakentamisen siihen.

Onneksi ihmisistä, jotka työskentelevät tämän ongelman parissa, ei ole pulaa tällä hetkellä. Työkalut, kuten Compositor, Interplay, Alva, Haiku, Webflow ja UXPin, pyrkivät hajottamaan tekniset seinät suunnittelutyökalujen ja niiden alla olevan koodin välillä, ja matkalla on enemmän tällaisia ​​työkaluja.

Kuka tietää - saatamme jopa alkaa nähdä perinteisempiä suunnittelutyökaluja käyttävän tätä lähestymistapaa pysyäkseen ajan tasalla, etenkin kun suunnittelujärjestelmistä tulee edelleen vakio-osa nykyaikaista suunnittelutyökalupakkia.

Sillä välin kun odotamme uusia suunnittelutyökaluja, jotka todella omaksuvat suunnittelujärjestelmän aikakauden periaatteet, react-sketchapp ja html-sketchapp, kuten projektit, tekevät hämmästyttävää työtä saadakseen meidät valmiiksi uudelle ajattelutavalle tänään.

Suoraan sanottuna, koskaan ei ole ollut parempaa aikaa aloittaa.