Share
I løpet av denne artikkelen vil vi ta et stort skritt i frontend-utviklingen og se hvordan det passer inn i vårt bredere bilde. Her er hva vi skal dekke:
Gjenopprette nettsteder kan være ganske en oppgave. Med en rekke enheter, nettlesere, tilgangspunkter, båndbredder, programmeringsspråk og miljøer kan det være vanskelig å bygge konsekvente webopplevelser. Takket være nettleserne og en standardiseringsdel (W3C) har vi noen pilarer på plass for å gi kontroll hvor det er mulig; disse pilarene er HTML, CSS og JavaScript.
Kombinert refererer vi til disse stolpene som front-end stack. Hvert språk har sin egen hensikt, og utviklere bruker mye tid på å sørge for at de ikke slør ut linjene til hver enkelt, da de kan bløde inn i hverandre. Så, la oss få grunnleggende her. Moderne nettlesere, som er kommersielt tilgjengelige: Likesom Safari, Edge, Chrome og Firefox kan bare forstå HTML, CSS og JavaScript. Det er det, tre språk. Med unntak av Javascript er HTML og CSS deklarative statisk språk. Ved dette mener jeg at du ikke nødvendigvis "program" i noen av dem, da det ikke er noen reell logikk å skrive (med noen små unntak). JavaScript, som har eksplodert til noen gang i internett på de siste årene, er imidlertid et programmeringsspråk.
Når jeg har forsøkt å forklare Front-End Stack til studenter tidligere, har jeg alltid funnet det nyttig å referere til menneskekroppen. Med tanke på at vi snakker i sammenheng med Atomic Design, bærer dette tilfeldigvis min metafor over!
En kropp, i gårHTML er skjelettet ditt. Det bestemmer strukturen og stillingen din. Et visst nivå av mening kan utledes av en slik struktur. Hodet ditt kommer alltid først, nakke, ribbe-bur, hofter, ben, føtter, helt ned til falangene dine.
HTML, ewOrdren til elementer Jeg har nettopp beskrevet er ditt typiske menneske. Det kan være forskjellig for en hval eller en tiger. Derfor kan HTML være forskjellig for blogger, handelsbutikker eller plattformer. HTML handler om mening, og beskriver til en nettleser på en meningsfull måte hva en side handler om. Det er blitt ganske en vitenskap for sent da Googles algoritme leser i hovedsak denne strukturen og kommer fra det som siden handler om.
Takeaway: Husk at HTML gir en struktur for din webopplevelse.
CSS er hvordan du ser ut. Hårfarge, øyenfarge, hudfarge, hårete, lange armer, muskuløs, tå neglelengde etc. Det er selv måten du stiler håret ditt eller sminke du legger på for å få deg til å ligne deg.
Den eneste hensikten er å style hva ellers ville være veldig vanlig og kjedelig HTML. Hvis vi alle gikk rundt i bare våre skjeletter, ville attraksjon være et problem. Det samme gjelder for webopplevelser.
JavaScript er din mannerisms og interaksjoner. Alt fra å klikke på dine knokler, å blinke, smilende, hoste, måten du går på, hvis du bestemmer deg for å hoppe over eller ikke, handler det om interaktivitet. Det viktige å huske om JavaScript er at når du lukker nettleseren din, er det alt glemt (generelt sett), slik at vi kan tenke på JavaScript som interaktiviteten i et nettsted som skjer mens du er i en "økt" eller aktivt samhandler med nettsiden. Tenk på å klikke på popup-vinduer eller navigasjonsmenyer.
Dette er noen som gårNoen av dere på dette punktet kan spørre hvor hjernen eller "logikken" kommer inn, men vi kommer dit. Det viktigste å ta ut av denne delen er at HTML, CSS og JavaScript lever i nettleseren, de jobber sammen for å skape en "statisk" nettopplevelse som vi deretter kan ta tilbake til Atomic Design for å finjustere.
DOM står for Dokumentobjektmodell. DOM er det levende, puste resultatet av HTML, CSS og JavaScript som eksisterer i en økt aktivert av brukeren.
Fordi DOM er en levende, pustende representasjon av kildekoden, er det viktig å forstå at det har begrensninger. Koden du skriver i HTML, CSS og JavaScript-filer på datamaskinen din kalles kildekoden. Denne kilden etterligner nøyaktig hva du ser i DOM, men det er ikke det samme. DOM er etterproduktet av manipulering og sortering av disse filene, fylt med kildekoden. Når disse filene blir forespurt fra en nettleser, blir språkene "tolket" og et nettsted eller en nettside er født. Hvis du endrer kildekoden, må representasjonen av disse kildefilene oppdateres for å vise den oppdaterte versjonen i nettleseren din.
Hvert språk har sine egne begrensninger. CSS har for eksempel ikke en spesielt sterk layoutmotor. Dette betyr at det kan være ganske prosess å generere komplekse oppsett i nettleseren. HTML har ingen oppsettegenskaper og er kun i stand til å gi en struktur og hierarki for at nettstedet skal forstås. JavaScript, som er et programmeringsspråk, har evnen til å manipulere HTML og CSS. På grunn av det faktum at vi bruker en tre-lags stabel for å skape fronten på et gitt nettsted, trenger de alle å leke pent med hverandre, så vel som i samsvar med noen ekstra parametere. I vårt tilfelle refererer disse parametrene til forskjellige nettlesere, enheter, operativsystemer, versjoner av nettlesere og mer. DOM er mer eller mindre det samme på alle nettlesertyper og -distributører, men på grunn av dette er det mange regler å følge med for å skape en konsekvent opplevelse.
CSS benytter et konsept kalt Box Model. Boxmodellen består av følgende egenskaper:
Her er et diagram som forklarer det litt bedre.
Lite bokser, på en åssideVed utforming av en form som en firkant, omfatter eiendommen det tar opp de ovennevnte elementene.
“Oddsen er aldri til din fordel"
Ja, fem kolonne grids ikke bode godt for utviklere. Det er generelt lettere å jobbe med evens enn odds. Utviklere pleier å bruke front-end rammer som Bootstrap eller UIKIT som følger med forhåndsberegnede rister som inneholder ti kolonner, tolv kolonner, eller kanskje mer. Det er en veldig god idé å spørre en utvikler hvilken ramme de planlegger å bruke, hvis noen, for å justere designet ditt mer hensiktsmessig med HTML og CSS
Borte er de gamle dagene av web. På grunn av at flertallet av nettstedet beveger seg mot respons, har behovet for væskeoppsett blitt svært tydelig. Grids er nå utarbeidet med prosenter (10%, 30%, 50%) av containere, som deretter kollapser ved bestemte bruddpunkter som en utvikler kan spesifisere.
Fonter på nettsteder fungerer veldig annerledes enn å skrive ut. Mens du bygger et nettsted på din egen datamaskin, kan du bruke hvilken som helst skrift du har installert på systemet ditt. Dette er bra for deg, men så snart disse filene flytter til en annen datamaskin, kan kildekoden ikke referere til skrifttypen du har installert på din egen datamaskin, siden det ikke er noen forbindelse til det.
Det er mange måter å omgå dette dilemmaet, men du vil ofte høre en utvikler be designere å bruke Google Fonts. Google Fonts er et sett med skrifter som er vert på et CDN (Content Delivery Network) som kan nås av hvilken som helst datamaskin som har en aktiv forbindelse til Internett, noe som betyr at selv om jeg ikke har den spesifikke skrifttypen installert på min egen datamaskin, kan fortsatt gjengi på nettstedet mitt. Vær oppmerksom på dette. Noen skrifttyper er heller ikke laget for gjengivelse på webmotorer. De kan se drastisk forskjellig når de ses i, sier Photoshop, sammenlignet med en nettleser. Hvert program gir skrifter med forskjellige gjengivelsesmotorer.
Nå som vi har dekket noen grunnleggende, la oss ta en titt på noen problemer som designere pleier å ikke vurdere i deres design, men er veldig viktige for brukeropplevelsen.
Hendelser er handlinger som en bruker tar mens de samhandler med nettstedet ditt. JavaScript har ganske mange å ta hensyn til, men enkle eksempler inkluderer "klikk", "rulle", "mouseon" eller "mouseout" og "keydown" eller "keyup". Hvis du vil lese litt mer om JavaScript-hendelser, kan du besøke Mozilla. Noen av hendelsene du ser her, trengs ikke nødvendigvis av brukerinteraksjon.
Fra designers perspektiv er det viktig å forstå hva som skjer med enkelte elementer eller deler på nettstedet ditt når en bruker har handlet på dem. Hva skjer når en knapp klikkes, for eksempel? Eller er det en animasjon som brukes til et modalt vindu når det lukkes på klikk? Dette er spørsmål du må gi svar på, spesielt hvis prosjektet ditt har et forhåndsdefinert omfang. Avhengig av budsjett og tidslinjer kan "Interaksjonsdesign", som det er kalt i websamfunnene, ta dyrebar tid ut av et prosjekt.
Etter at en hendelse har skjedd, blir elementer igjen i "stater". Et vanlig eksempel er koblinger. Lenker har en rekke stater: aktiv, fokus, sveve. Hva ser koblingene ut når de er klikket på? Mens du presser ned? Når musen svinger over dem? Eller når de blir rørt på mobilen?
Atomisk design kan virkelig komme til nytte her, ettersom stilstøttene dine lett kan ta hensyn til disse tilstandene mens du bygger opp et atom som en knapp. Stat kan ha en dramatisk innvirkning på brukeropplevelsen din, så ta hensyn til det når du arbeider med mer komplekse nettsteder.
"Response" buzz ordet har vært summende for en stund nå. Som utviklere må vi sørge for at våre webopplevelser er konsistente på alle enheter. Hvis du er freelancer, vil nesten alle klienter be om at deres nettsted skal være lydhør. Det er blitt "brød og smør" på nettet. CSS gir utviklere en nyttig teknologi som Media Queries som tillater utviklere å tilpasse oppsett på bestemte "breakpoints".
Front-end rammer som Bootstrap og Foundation er rettet mot å gjøre responsiviteten enklere å implementere ved å utvikle responsive, prosentbaserte grid for utviklere å jobbe med. Det største uttaket her er ikke hvor lydhør designrammer fungerer, men mer hva de er konstruert for å gjøre.
Det er det for denne gangen! I neste artikkel vil vi se på backend og hvordan vi kan bruke en Atomic Design-tankegang for å forbedre forståelsen av logikk og programmeringsferdigheter.
Accentsconagua