God responsiv webdesign, av sin natur, går ubemerket til de som bruker innhold på nettet. Så når noen spør om et nytt nettsted, er de ofte helt uvitende om konseptet, til tross for å oppleve det på daglig basis. Og likevel er responsiv nettside design nå anerkjent som standard praksis i hele bransjen.
Å bygge responsive nettsteder har endret våre prosesser, fra å lage mockups av komplette sider, til byggebiblioteker av gjenbrukbare komponenter og layouter.
Oppsettet er innholdsdrevet og stilene er merkedrevet
Nylig ble vi nærmet av en eksisterende klient til å reprodusere nettsiden deres på en forsvarlig måte. Vi hadde tidligere jobbet med dem ved hjelp av en stiv vannfallsprosess. Vi var i stand til å omfavne endringer når som helst i prosjektet.
Gjennom hele prosessen fulgte vi filosofien om at layout er innholdsdrevet og stiler er merkedrevne.
Spesifikasjonsdokumenter fungerer bra for å vise ut alle funksjonalitetene et nettsted er pålagt å ha. Men er det virkelig hva kunden trenger? Det er svært vanskelig å visualisere disse funksjonene på plass. Dermed er resultatet at spesifikasjonsdokumenter ofte blir til oppblåste ønskeliste. Dette hjelper ikke kunden, designerne eller den endelige nettsiden.
I stedet for spesifikasjonsdokumenter valgte vi å bruke ledningsrammer. Det første trinnet i prosjektet var å skape trådrammer for hver side. Dette kan høres ut som overkill, men ledningene førte til tidlig diskusjon av innhold og funksjoner for hver side. Vi fant at funksjoner som vi aldri har vurdert før, ble lagt til, mens mange ble fjernet.
Wire-rammer ga oss en klar, visuell fremstilling av hvordan innhold og funksjonalitet bør prioriteres på hver side. Disse trådrammene ble deretter et referansepunkt som erstatter et spesifikasjonsdokument.
Nøkkelopptak: Produksjon av trådrammer i stedet for spesifikasjonsdokumenter fokuserer alle på kjernevennene og viktigheten av innhold.
Ved å revidere ledningsrammer kan vi lage en liste over alle de vanlige komponentene. Over et enkelt sted vil det være dusinvis av små seksjoner på hver side som er svært like. Disse komponentene kan samles inn i en uttømmende liste som vil bli brukt senere.
Dette stadiet har tre hovedfordeler:
Nøkkeltaking: Å planlegge hvordan man skal nærme seg fremdriftsprosjektets utvikling er viktig for å skape en vedlikeholdbar, magert kodebase.
Mønsterbiblioteker er en samling av vanlige elementer som brukes på et nettsted. Ved å fokusere frontend-utviklingen på byggekomponenter som ikke er avhengige av sider, kan vi redusere koden overhead og forbedre konsistensen.
Ved å bruke listen over komponenter vi samler i revisjonsstadiet, kan vi strukturere vår Sass i en håndterlig samling av filer.
Vi har brukt mønsterbiblioteker på noen få prosjekter, men har alltid slitt med navnekonvensjoner, spesielt mappestrukturen: hvor setter du stilene dine for denne musikkspilleren, i komponenter eller delvise?
Tidligere hadde vi brukt terminologi som partials og komponenter for å organisere våre Sass-filer. Mens disse virker som helt legitime navngivningskonvensjoner, er de åpne for tolkning. Når det er flere utviklere som jobber med et prosjekt, vil organisasjon av kodebase åpne for tolkning føre til uorganisert CSS.
BEM (Block, Element, Modifier), gir oss en felles konvensjon å følge, og skaper en forståelse mellom front-end-utviklere. Den gamle måten ble overlatt til de enkelte utviklere for å komme opp med klassenavn som var altfor høye for å skaffe noen mening fra. Heldigvis var vi heldige å se Brad Frost snakk om hans mønsterbibliotek på Upfront konferanse i Manchester. Pattern Lab gir terminologi fra kjemi for å beskrive komponentene som utgjør biblioteket. Ved å bruke atomer, molekyler og organismer for å beskrive forskjellene mellom komponentene på en side, er det viktig å forklare konseptet til utviklere som er nye for prosjektet.
Atomisk design er for brukergrensesnitt: http://t.co/eEZSYeK5VF Du kan bruke atomdesign til alle brukergrensesnitt, som Instagram pic.twitter.com/BrztgtRoGU
- Brad Frost (@brad_frost) 10. juli 2015
I naturen er atomer den minste denominasjonen (med mindre vi dykker inn i kvarker og elektroner). I webutvikling er atomer de mest grunnleggende elementene i HTML. Til alle formål og formål gjør de ikke mye alene. Disse inkluderer overskrifter, avsnitt, innganger, knapper, lister ... Du får ideen.
Dette er neste lag opp. I kjemi består molekyler av atomer, og det samme gjelder strukturen til CSS. Molekyler er komponenter på nettstedet som bruker atomer til å danne dem.
Et godt eksempel på et molekyl er en søkeboks. Dette inneholder 3 atomer: en etikett, input og knapp. Molekylaget begynner å danne noen av elementene vi kan bruke på nettsiden. Det er viktig å gjøre alle disse molekylene skalerbare. De bør utformes med ideen om at de kan brukes hvor som helst på nettstedet. Vårt ultimate mål å gjøre CSS så fleksibelt og gjenbrukbart som mulig.
Som navnet antyder, er organismer grupperinger av molekyler. Noen eksempler på disse inkluderer en header, bunntekst eller produktliste.
Hvis vi tar eksemplet på en topptekst, vil dette inkludere en logo, søk og navigasjon. Disse ble alle opprettet som molekyler og er kombinert for å danne en header organisme.
Det er her biokjemi analogien ender. Som Brad sier, "gå inn på språk som gir mer mening til klienter og endelig produksjon" . Maler er limet på et nettsted. Disse kombinerer alle organismene vi har opprettet i et layout som kan brukes på en side på nettstedet.
Et eksempel kan være en bloggoppføring. Denne malen vil inkludere et overskrift, bunntekst, en liste over bloggelementer og et sidebjelke. Maler er generelt strukturelle, som bare inneholder oppsettet.
Den siste delen er sider. Her kan du teste malene med ekte data. Sider er bestemte forekomster av en mal. Denne delen er viktig fordi den lar oss se hvor vellykket atomer, molekyler, organismer og maler har vært.
Det er uunngåelig at visse scenarier blir savnet når du bygger nettstedet. Det klassiske eksempelet er lange titler, eller catering til forskjellige valutaer og språk.
Viktig takeaway: Naming conventions matter. Layering CSS skaper en ren kodebase for å arbeide fra det som er så lite som mulig.
Design mønstre er vanskelig. Du kan ikke designe et isolert mønster som et nyhetsart, og forvent at det passer med resten av siden. Måten vi bygger nettsteder på og hvordan vi designer dem, er forskjellige.
Designene vil sannsynligvis endres uansett om vi får sign-off ... Sign-off ble et irrelevant trinn i prosessen som bare satte press på begge sider
Vi brukte Photoshop til å lage mockups av trådrammer med disse stilte komponentene på plass. Når vi var fornøyd med utseendet på designene flyttet vi for å isolere hver komponent. Dette tillot oss å sikre at hver komponent var fleksibel nok til å fungere hvor som helst på nettstedet.
Vi var veldig bevisste på at vi ikke fikk sign-off på noen designarbeid. Design sign-off skaper en barriere der designeren føler seg presset til å lage noe som vil bli satt i stein. Designene vil sannsynligvis endres, uansett om vi får sign-off eller ikke. Generelt er vi glade for å imøtekomme eventuelle endringer når som helst i prosjektets tidslinje. Sign-off ble et irrelevant skritt i prosessen som bare satte press på begge sider til skade for forholdet.
Å vite når du skal flytte fra Photoshop til kode er viktig. Dette trinnet er mye tidligere enn vi var vant til av to grunner:
I stedet for å bruke ekstra tid i Photoshop valgte vi å investere tiden i kode. Hvis vi skulle perfeksjonere noe, bør det være koden, biten som faktisk blir brukt og sett av alle nettstedbrukerne. For oss var Photoshop et verktøy for å lage en designstil som kunne brukes på hele nettstedet.
Design handler mye om samarbeid mellom alle i teamet. Mockups var fortsatt en svært viktig del av prosessen, og hjelper kunden å visualisere hvordan nettstedet skulle se ut. Hvis vi var alle fornøyd med den generelle retningen til designen, ville vi flytte den til kode. Vi brukte sjelden tid på å gå bakover og fremover, og forandret seg til Photoshop-dokumenter.
Key takeaway: Photoshop er et flott verktøy for å skape designkonsepter. Det er viktig å flytte til kode så snart som mulig. Perfekt det i kode, ikke Photoshop.
Skjønnheten i denne arbeidsflyten er at det er så mange steder å vurdere og forbedre nettstedet.
Det er viktig å merke seg at dette er løse skritt i prosjektprosessen. Hvis vi trenger noe nytt under prosjektet, vil vi generelt behandle det som en frittstående, modulær komponent som kan bli droppet inn på nettsiden og vedta designtemaet til nettstedet.
Hver av disse trinnene gir et punkt der vi kan se gjennom arbeidet vårt så langt. Det gir også et friskt sett øyne for å se ting fra et annet perspektiv.
Under noen av disse stadiene kan vi oppdage at enkelte deler ikke virker så godt som forventet. Dette er bra. Faktisk er det bra. Fangst dårlig brukbarhet tidlig er nøkkelen til et vellykket nettsted. Å gå tilbake og sette inn disse delene av nettsiden vil gjøre prosjektet bedre når det går live.
Viktig takeaway: Ikke vær redd for å gå tilbake til begynnelsen hvis noe må forbedres. Fange disse tidlige vil gjøre prosjektet bedre når det går live.
Vi brukte dager på å jobbe sammen for å sikre at alle deler av nettstedet var ferdig til en høy standard. Vi testet så mange scenarier som mulig, slik at surfingopplevelsen var konsistent.
Når dataene er på nettstedet, kan vi fullt ut teste nettstedet. Det er ofte for enkelt å sette et prosjekt live uten full test. Vi kan sjekke hastigheten, brukervennligheten og viktigst av innkjøpsflyten.
Alle nevner Apple for å være perfeksjonister, men jeg er sikker på at deres første forsøk var langt fra perfekte. Det tar tid og dedikasjon å gjøre de endelige forbedringene for å gi oss produktene vi elsker i dag. Ved hjelp av enhetslaben vår, som inkluderer de fleste av de populære enhetene og plattformene, var vi i stand til å sikre at opplevelsen var optimalisert på så mange av de nyeste plattformene og skjermstørrelsene som mulig.
Læring fra hvert prosjekt er viktig, slik at vi kontinuerlig kan forbedre prosesser som fører til bedre nettsteder.
Dette prosjektet ble født av vårt eget mønsterbibliotek som fremmer konsistens mellom prosjekter. Når vi jobber i et byrå, kan vi ha dusinvis av prosjekter som er i utvikling samtidig. Evnen til noen å jobbe på et prosjekt er viktig.
Å skape en base som vi alle kan jobbe med, vil bidra til å bidra til dette målet.
Utførelsen av nettstedet ble bare vurdert mot slutten av prosjektet. En vellykket responsiv nettside må være slank og rask. Det enorme spekteret av enheter og deres evner varierer sterkt fra splitter nye Mac-maskiner til gamle smarttelefoner. Når du bygger et medierikt nettsted, kan det være svært vanskelig å administrere ytelsen, spesielt når du forsøker å forbedre det med tilbakeblikk.
På Upfront Conference i Manchester så vi Yesenia Perez Cruz snakk om å vurdere ytelse på alle stadier av et prosjekt, inkludert design. Etterpå, dette er noe vi burde ha implementert. Som et team av flere designere, utviklere og front-end-utviklere, som skal ha den største størrelsen og ytelsen (spesielt den oppfattede ytelsen), burde det vært en større prioritet.
Alt på en side har en kostnad for ytelse. Prioritering av det som er viktig sikrer at nettstedet ikke bare er rask, men tilgjengelig for flere enheter. På noen eldre enheter fant vi ut at webområdet krasjet ikke bare nettleseren, men hele enheten. Forsøk på å øke hastigheten på nettsiden med tilbakemelding betydde at vi ikke kunne gjøre nettsiden så rask som den kunne ha vært.
Neste gang vil vi sørge for at ytelsen inngår i alle stadier av prosessen, så det er ikke en ettertanke.