Designing i nettleseren pleide å skremme meg. Ikke fordi det virket vanskelig, men fordi jeg trodde jeg ville ende med et design bestående av mange små bokser, noe som var så generisk og tørt, ville jeg ende opp med å gjøre om det i Photoshop.
Den frykten viste seg å være helt uberettiget. Ikke bare ble designene mine mer fokuserte, jeg fullførte dem også raskere og fikk klienter involvert tidligere i prosessen gjennom samhandling og diskusjon.
Design er design. Det spiller ingen rolle om det gjøres i et program eller skrives i kode. Designing i nettleseren er ikke noe vanskeligere enn å designe i Photoshop. Som et hvilket som helst verktøy må du bruke den til å lære det og til slutt mestre det.
Design er en iterativ prosess, en som blir vanskeligere ved å jobbe for kunder. Det er vanskelig noen ganger for kundene å presisere nøyaktig hva du beskriver; utforming i nettleseren kan få dem involvert gjennom hele prosessen i stedet for bare designfasen.
I hovedsak er design- og utviklingsfasene sammenslåing, og hvis du er naturlig god til design og front-end-utvikling, vil du ta for å designe i nettleseren som en ande tar til vann.
En stor fordel ved å designe i nettleseren er at vi kan designe basert på realistiske forventninger. Noen ganger kan utforming i programvare skape uforutsette problemer for front-end-utvikling. UI-elementene kan utformes wonky eller kanskje de bare ikke gir mening, det er vanskelig å forklare for en klient hvorfor du forandret noe, ikke fordi de ikke forstår, men fordi du allerede har lagt den i design og hadde det godkjent. Utforming i nettleseren gir seg ideen om enkelhet.
Før jeg tenker på design, må jeg ha en plan. Bare fordi jeg bruker et annet verktøy, betyr ikke min prosessendring. Jeg liker å ha en ganske solid plan før jeg begynner å designe, og jeg trenger å vite hva jeg designer, hvorfor jeg designer, hvem jeg designer for, klientbakgrunn og hvilken som helst tjeneste eller produktinformasjon jeg må fokusere på på.
Etter at jeg har bestemt disse tingene, vil jeg få en bedre ide om hva produktet er, eller hva klienten gjør, hvor lenge har de gjort det, hva skiller dem fra konkurrentene deres, hvem brukeren er og hva primær og sekundær målene på nettstedet skal være.
Jeg personlig har dokumentasjon av alt. Vanligvis har jeg dokumentasjon for nettstedskart, innhold, oppfordringer til handling og nettstedarkitektur. Da jeg begynner å designe, burde jeg ha en klar strategi for designen og alt innholdet skulle ha blitt samlet.
Skisse er nøkkelen hvis jeg skal designe noe i nettleseren. Jeg kan grove ut innholdsområder med blyant og papir, få tilbakemelding og raskt gjenta i grunnlaget for designet mitt.
Jeg skisserer basert på planen jeg beskrev ovenfor, og jeg sørger for at jeg har alle innholdsområder og oppfordringer til å legge til rette for det. Skisse bør være rask, ikke tilbringe mye tid på å perfeksjonere noe. Det skal være solid nok til å vise til en klient, men slurvet nok til at du kan få dem ferdig på mindre enn en time.
Neste liker jeg å prototype nettstedet fra skissene mine i HTML og CSS. Prototypen er mange grå bokser med tekst og bilder for plassholdere. De grå boksene fungerer som containere for innhold når jeg faktisk begynner å designe. Den største fordelen ved prototyping med kode er at klienten kan samhandle med prototypen og se hvordan nettstedarkitekturen fungerer, på den måten hvis noe er av eller trenger raffinert, kan vi håndtere det nå, heller enn på lanseringsdagen.
Før vi kan begynne å designe, trenger vi en slags stil for å basere vårt design ut av. Vi må bestemme hvilke farger og skrifttyper vi skal bruke med potensielle teksturer og mønstre. Dette er hvor stilfliser kommer inn i spill.
Stil fliser ble skapt av Samantha Warren, og jeg har brukt dem en stund nå. De hjelper kundene å se en tidlig og veldig enkel stilguide som vi kan bruke til å begynne å designe med. Jeg liker å lage flere av disse for å se hvilken klient som foretrekker den måten jeg kan begrense den til en. Jeg finner at disse også er svært viktige i godkjenningsprosessen, og bidrar til å forhindre direkte avvisning.
Nå er vi klare til å begynne å designe. Hvis du er vant til å designe i et program som Photoshop eller Sketch, er dette ikke så mye annerledes. Ved hjelp av vår prototypefil begynner vi å legge til mock innhold i vårt oppslag. På dette punktet vet vi nøyaktig hva som går inn i hvert innholdsseksjon i markeringen, og rutenettet er allerede definert, så det bør ikke ta så lang tid.
Nå skal jeg begynne layering-stiler på innholdet mitt. Jeg skal legge til basestiler for farge, typografi og layout. Når basestilene er ferdige, vil jeg gå bort og se på den. Jeg liker å skjerme bestemte deler av designet for senere referanse.
Når jeg er fornøyd med grunnlaget, liker jeg å ta notater om hva du skal finjustere. Basert på disse notatene vil jeg mest sannsynlig bruke Photoshop eller Skisse å legge til tekstur eller noe med en konkret følelse. Photoshop og Sketch er gode verktøy for å finjustere komplekse brukergrensesnittelementer raskt, så jeg lagrer alt som kan være vondt for å kodes ut mer enn en gang
Grunnen til at jeg gjør dette er fordi jeg vil at min kodebase skal være magert og rent og jo mer du kodes, kommenterer og sletter, jo mer slurvete og oppblåste kodebase blir.
Hvis du måtte designe i nettleseren fra starten hver gang, kan det virke som om de tar for alltid, men hvis du starter fra en egendefinert base, et rammeverk, kan du eliminere eventuelle repeterende trinn. Til å begynne med har jeg en egendefinert versjon av Initializr som jeg bruker med et tilpasset responsivt grid bygget i Sass (http://sass-lang.com/). Ved å bruke et tilpasset rammeverk får jeg en start for prototyping og design.
Å ha et bibliotek med vanlige brukergrensesnitt er også en fin måte å bygge en rask prototype på, og det gjør utformingen i nettleseren mer effektiv. jeg bruker Sublim tekst å kode og en ting jeg har lært å dra nytte av, er de egendefinerte utklippene du kan lage. Jeg har lagt til flere variasjoner av navigasjon, lister, sidebjelker og andre vanlige elementer i min liste over utklipp, slik at jeg raskt kan plassere dem i oppslaget mitt med en enkel handling. Jeg bruker også kontoer på Codepen og JSFiddle for å lagre mønstre. Dan Cederholm skapte et flott WordPress-tema for lagring av vanlige mønstre som heter pærer . Det bruker innlegg for å lagre kode som du kan redigere live i frontend for å teste og forhåndsvise endringer.
Øvelse og praktisk bruk vil gjøre deg bedre til å designe i nettleseren. Sjansene er at hvis du gjør noen form for utvikling foran deg, har du allerede et grunnlag for å starte fra, og du har allerede noen vanlige mønstre å bruke.
Nå er alt du trenger å gjøre, begynne å designe i nettleseren og til slutt kommer du opp med en arbeidsflyt som er effektiv og fungerer i prosessen. Med praksis får du bare raskere.