Webutvikling Konsepter Alle webdesignere bør forstå

Det er mye å si om skillelinjen funnet mellom designere og utviklere. Gitt det er mange designer / developer hybrider som kan forstå begge sider av mynten, men de er få og langt mellom.

Kreative prosjekter trives riktig kommunikasjon. Dette kan imidlertid være vanskelig når designere og utviklere ikke er sikre på hvordan snakk med hverandre. Jeg tror ikke designere trenger å vite hvordan man skriver riktig JavaScript, og heller ikke utviklerens master typografivalg. Men det er noen grunnleggende emner som jeg tror går begge veier.

Følgende emner er min egen personlige påføring viktige webutvikling ideer som alle designere bør forstå. Som designer / utvikler selv, vet jeg hvor forvirrende det kan være å studere begge deler. Men det er alltid verdt innsatsen for å lære fordi en klar forståelse forbedrer kommunikasjonen og gjør en designer mye mer verdifull for et kreativt team.

Frontend Code Behavior

Webdesignere er ofte tenkt å ha frontend ferdigheter sammen med sine design talenter. Dette er et diskutert tema, for det meste fordi det er ingen korrekt svar.

Designere bør gjøre det de gjør er komfortabel med. Hvis det bare betyr å gjøre visuelt designarbeid, så vær så snill. Men en kort forståelse av frontend-teknologier kan skape den samme designeren mer intuitivt når du oppretter eiendeler for utviklere.

Jeg tror at alle designere skal minst forstå tre grunnleggende språk for frontendutvikling (HTML, CSS og JS) sammen med hvordan de brukes. For eksempel er de fleste rullegardinmenyer avhengig av JavaScript, men det finnes også CSS-bare alternativer.

Når en designer lager en rullegardinmeny, kan de tenke på kompleksiteten av å implementere den via kode. En designer som forstår hvilke elementer som krever JavaScript, kan være bedre forberedt på å forstå hva de ber utviklere å bygge.

Dette er mulig uten å lære å skrive en enkelt linje med kode.

CSS er laget til stil nettsiden. Det er for det meste statisk bortsett fra CSS animasjon, og CSS skaper de fleste visualer på en side. Mest dynamiske funksjoner er laget med JavaScript.

Hvis du kan forstå denne splittelsen, vil det puste en bevisst innsats inn i designarbeidet. Det vil også tvinge UX-bevegelsesdesignere til å vurdere hvor mye arbeid som går inn i å animere et grensesnitt.

Responsive Techniques

Hver webdesigner bør i det minste kjenne termen responsiv utforming. Dette tillater nettsteder å tilpasse seg forskjellige skjermstørrelser, til hver av dem tilhører en annen layout. Enhetsdimensjoner når en ny layout blir brukt er definert av breakpoints, lagt til i (en av) CSS-filene.

Breakpoints er spesifisert av a viss pikselbredde (og / eller noen ganger høyde), enten minimum eller maksimum, der oppsettet tilpasser seg den aktuelle skjermstørrelsen. Så et responsivt layout vil se annerledes ut på en 1080px skjerm enn på en 320px smarttelefon.

For å se hvordan breakpoints jobber på ekte nettsteder, sjekk ut Media Queries nettsted.

Din jobb som designer er å vurdere hvordan hvert bruddpunkt kan påvirke mockup. Du kan være oppgave med å designe flere comps, hver passer inn i forskjellige skjermdimensjoner.

Når du har forstått at et CSS-brytepunkt definerer forholdene når layoutet endres, vil du ha en mye enklere tid å levere disse eiendelene til dev-teamet.

Tenk modulær med design

Utviklere vil alltid gjenbrukskode så mye som mulig, ettersom denne tilnærmingen gir utvikling mindre verbose og kutter ned filstørrelser - faktisk er det en viktig kodeoptimaliseringsteknikk.

Modulær design beskriver en metode for å lage nettsteder ut av “moduler” det kan være gjenbrukes over tid. Tenk knapper, form innspill, overskrift stiler, eller blokkeringer med fancy stylings.

Hvis du designelementer modulært, det blir enklere for utviklere å kode oppsettet med gjenbrukbare CSS klasser. Det er alltid en god ide å tenke på hvor du kan rimelig gjenbruk De samme farger, teksturer og sideelementer, men du må være smart om det Ikke å skade total estetikk.

Det er enda bedre hvis du kommentere hvilke elementer du har kopiert på tvers av forskjellige mockups, slik at utviklere kan merk opp disse delene av nettstedet med gjenta kode - gjør utviklingen raskere og enklere.

Modular design relaterer seg til atomdesign, begge tilnærmingene er rettet mot utviklere. derimot visualisering kan hjelpe deg å forstå hvordan koden fungerer, så hvis du sliter med visualisere modulær design sjekk ut dette innlegget for å se noen eksempler.

Forstå Retina Images & SVG

Vanligvis er det designers jobb å forberede bilder, fange opp nødvendige bilder og design ikoner fra bunnen av. Dette betyr at designere er eneansvarlig for levere de visuelle eiendelene at utviklere til slutt kodes inn i oppsettet. Derfor er det viktig å forstå retina størrelser og til passere retina-støttede eiendeler til utviklerne sammen med siste mockup (s).

Jeg vil sterkt anbefale denne Smashing Magazine innlegget hvis du vil lære mer om retina design arbeidsflyter. Retinize Det er en gratis samling av Photoshop-handlinger som kan opprett automatisk retina-versjoner av dine eiendeler.

De fleste designere vet allerede å støtte @ 2x bilder, men nyere iPhone 6 + enheter har @ 3x resolusjoner. Men noen prosjekter bryter ikke med @ 3x bildestørrelser, så snakk med prosjektlederen før du fullfører eventuelle eiendeler.

En siste ting å vurdere er fremgang av SVG på internett. Alle moderne nettlesere støtter SVG som er en vektorbasert bildeformat. Dette betyr at SVG ikoner vil automatisk skalering uten tap av kvalitet, slik at du ikke trenger retina-midler for SVG-grafikk.

Ikke alle kreative lag er villige til å gå med SVGs for webdesign skjønt. De støttes av nettlesere sikkert, men i noen tilfeller kan de også være vanskelig å implementere. Derfor er kommunikasjon viktig for et vellykket designer / utviklerforhold.

Diskuter fordelene og ulemperne ved å bruke vektorgrafik og bestem hva som passer best for hvert prosjekt. Ved å bare ha en forståelse av disse funksjonene, vil du kunne kommunisere med utviklere tydelig, og til og med hjelpe dem med å kode oppsettet for netthinnen.

Forstå tilgjengelighet

Progressiv forbedring og grasiøs nedbrytning er to forskjellige måter å håndtere det samme problemet på: tilgjengelighet. Ikke alle brukere vil være på enheter eller kjøre nettlesere som støtter 100% av nettstedets dynamiske funksjoner.

Disse brukerne bør fortsatt få en erfaring som virker, og dette må håndteres med riktig koding. Noen skjermlesere kan ignorere all JavaScript og CSS-koden, men nettstedet trenger fortsatt å fungere.

Jeg har nylig gjort et innlegg progressiv forbedring i detalj, som det er min foretrukne utviklingsmetode. Progressiv forbedring starter med svært grunnleggende funksjoner, så jobber opp til flere “avansert” egenskaper.

Grasiøs nedbrytning er den motsatt tilnærming hvor alle hovedtrekkene er designet først, da bestemmer utvikleren hvordan han skal håndtere disse funksjonene hvis brukeren ikke støtter JavaScript eller CSS.

Det er usannsynlig at en designer vil bli bedt om å gjøre mockups for noen av disse situasjonene. Men det er viktig at designere forstår disse vilkårene og hva de mener, fordi de påvirke utviklingsprosessen. Dette gjelder spesielt for prosjekter der tilgjengelighet er en stor bekymring.

I Avslutning

Det er noen emner jeg hoppet over, fordi jeg anser dem valgfritt. Versjonskontroll, feilsøking og JavaScript-animasjoner er noen flere komplekse emner som designere kan ønske å dykke inn i.

Men rettferdig vil poengene i dette innlegget mer enn hjelpe designere å forstå kravene til et utviklingslag. Ved å bare skumme overflaten av webutvikling, vil du Oppnå innsikt som vil hjelpe deg med å formidle ideer og sympatisere med problemer som oppstår under produksjonen.

Hvis du leter etter mer relatert innhold, ta en titt på disse innleggene:

• Slik kommuniserer du effektivt med utviklere (Smashingmagazine.com)
• Hjelp designere og utviklere Lær å forstå hverandre (Uie.com)
• Lære å kode gir deg fordeler som en UX-designer (Jessicaivins.net)