Hyvä reagoiva web-suunnittelu luonteeltaan jää huomaamatta niille, jotka kuluttavat sisältöä verkossa. Joten kun joku pyytää uutta verkkosivustoa, he eivät useinkaan tiedä konseptia, vaikka he kokivat sen päivittäin. Ja silti, reagoiva verkkosivuston suunnittelu tunnustetaan nyt vakiintuneeksi käytännöksi koko toimialalla.
Reagoivien verkkosivustojen rakentaminen on muuttanut prosessejamme, luomasta täydellisiä sivuja, luomaan uudelleenkäytettävien komponenttien ja layoutien kirjastot.
ulkoasu on sisällöllistä ja tyylit ovat brändi-pohjaisia
Äskettäin meitä lähestyttiin olemassa olevan asiakkaan kanssa, jotta he voisivat reagoida verkkosivustosi uudelleen. Olimme aikaisemmin työskennelleet heidän kanssaan jäykällä vesiputousprosessilla. Siirryttäessä ketterään työnkulkuun pystyimme omaksumaan muutoksen projektin missä tahansa vaiheessa.
Koko prosessissa noudatimme filosofiaa, että ulkoasu on sisällöllistä ja tyylit ovat brändipohjaisia.
Tekniset asiakirjat toimivat erinomaisesti, kun luetellaan kaikki toiminnot, joita sivustolla vaaditaan. Mutta onko se todella mitä asiakkaan tarvitsee? Näitä ominaisuuksia on vaikea kuvitella paikallaan. Siten tuloksena on, että spesifikaatiot dokumentit muuttuvat usein paisutetuiksi toivomuslistoiksi. Tämä ei auta asiakkaalle, suunnittelijoille tai lopulliselle verkkosivustolle.
Sen sijaan, että määriteltiin asiakirjoja, päätimme käyttää lanka-kehyksiä. Projektin ensimmäisessä vaiheessa luotiin lanka-kehyksiä jokaiselle sivulle. Tämä voi kuulua ylikuormitukselta, mutta lanka-kehykset johtivat varhaiseen keskusteluun kunkin sivun sisällöstä ja ominaisuuksista. Löysimme, että ominaisuuksia, joita emme koskaan pitäneet aiemmin, lisättiin, kun taas monet poistettiin.
Wire-kehykset antoivat meille selkeän visuaalisen esityksen siitä, miten sisällön ja toiminnallisuuden tulisi olla etusijalla jokaisella sivulla. Nämä lanka-kehykset muuttuivat sitten vertailupisteeksi, korvaamalla spesifikaatiotiedoston.
Keskeinen takeaway: tuottaa lanka-kehyksiä sijaan eritelmä asiakirjat keskittyy kaikki keskeiset ominaisuudet ja sisällön tärkeys.
Lanka-kehysten tarkastus antaa meille mahdollisuuden laatia luettelo kaikista yleisistä osista. Yhdellä sivustolla on kymmeniä pieniä osioita jokaiselle sivulle, jotka ovat hyvin samankaltaisia. Nämä osat voidaan koota kattavaan luetteloon, jota käytetään myöhemmin.
Tässä vaiheessa on kolme etua:
Keskeinen takeaway: Suunnittelu, miten lähestyä projektin etupään kehittämistä on tärkeä luoda ylläpitävä, laiha koodipohja.
Mallikirjastot ovat kokoelma yhteisiä elementtejä, joita käytetään verkkosivuilla. Keskittymällä etupään kehittämiseen sellaisiin rakennusosioihin, jotka eivät ole riippuvaisia sivuista, voimme vähentää koodin yläpuolella ja parantaa johdonmukaisuutta.
Käyttämällä komponenttien luetteloa, jonka olemme koonnut tarkastusvaiheen aikana, voimme rakentaa Sassin hallitsevaan tiedostojen kokoon.
Olemme käyttäneet mallikirjastoja muutamissa projekteissa, mutta olemme aina kamppaillut nimeämiskäytäntöjen, erityisesti kansion rakenteen kanssa: missä laitat tyylisi tähän musiikkisoittimeen, komponentteihin tai osittaisiin?
Aikaisemmin olimme käyttäneet terminologiaa, kuten osia ja komponentteja Sass-tiedostojen järjestämiseksi. Vaikka nämä näyttävät aivan laillisilta nimeämiskäytännöiltä, ne ovat avoimia tulkinnalle. Kun projektissa on useita kehittäjiä, jättäen koodiperustan organisoinnin avoimeksi tulkinta johtaa järjestäytymättömään CSS: hen.
BEM (Block, Element, Modifier) tarjoaa meille yhteistä yleissopimusta, joka seuraa ja luo ymmärtämyksen etupään kehittäjien välillä. Vanha tapa jätettiin yksittäisille kehittäjille keksimään luokkien nimet, jotka olivat kaikki liian korkeatasoisia, jotta ne voisivat kerätä kaiken merkityksen. Onneksi meillä oli onnea nähdä Brad Frost puhua hänen kuvakirjastostaan Upfront-konferenssi Manchesterissa. Pattern Lab myöntää kemian käsitteistöä kuvaamaan kirjaston muodostavia osia. Atomin, molekyylien ja organismien käyttäminen kuvaamaan sivujen komponenttien välisiä eroja auttaa selittämään konseptin hankkeen uusiin kehittäjiin.
Atomic design on tarkoitettu käyttöliittymille: http://t.co/eEZSYeK5VF Voit käyttää atomisuunnittelua mihin tahansa käyttöliittymään, kuten Instagram pic.twitter.com/BrztgtRoGU
- Brad Frost (@brad_frost) 10. heinäkuuta 2015
Luonnossa atomit ovat pienin nimellisarvo (ellei kaivata kvarkeja ja elektroneja). Verkkokehityksessä atomit ovat HTML: n peruselementtejä. Kaikille tahoille ja tarkoituksille ne eivät tee paljon itsestään. Näihin kuuluvat otsikot, kappaleet, panokset, painikkeet, listat ... Sinulla on idea.
Nämä ovat seuraavaa kerrosta. Kemiassa molekyylit koostuvat atomeista, ja sama koskee CSS: n rakennetta. Molekyylit ovat osia verkkosivuilla, jotka käyttävät atomeja muodostaen ne.
Hyvä esimerkki molekyylistä on hakukenttä. Tämä sisältää 3 atomia: tarra, syöttö ja painike. Molekyylikerros alkaa muodostaa joitain elementtejä, joita voimme käyttää verkkosivuilla. On tärkeää, että kaikki nämä molekyylit skaalautuvat. Ne olisi suunniteltava ajatuksella, että niitä voitaisiin käyttää missä tahansa sivustossa. Tavoitteenamme on tehdä CSS joustavaksi ja uudelleenkäytettäväksi.
Kuten nimestä käy ilmi, organismit ovat molekyylien ryhmittymiä. Esimerkkejä näistä ovat otsikko, alatunniste tai tuotteiden luettelo.
Jos otat esimerkin otsakkeesta, siihen kuuluu logo, haku ja navigointi. Ne kaikki luotiin molekyyleiksi ja yhdistettiin muodostamaan otsakkeen organismi.
Tässä biokemian analogia päättyy. Kuten Brad sanoo, "päästä kielelle, joka tekee asiakkaiden mielekästä ja lopputulosta" . Mallit ovat verkkosivuston liima. Nämä yhdistävät kaikki luomamme organismin osaksi ulkoasua, jota voitaisiin soveltaa verkkosivuston sivulle.
Esimerkki voisi olla blogikirjoitus. Tämä malli sisältää otsikon, alatunnisteen, blogikirjoitusten luettelon ja sivupalkin. Mallit ovat yleensä rakenteellisia ja sisältävät vain ulkoasun.
Viimeinen osa on sivuja. Tässä voit testata mallipohjia reaaliajassa. Sivut ovat mallin erityisiä esimerkkejä. Tämä osa on tärkeä, koska se antaa meille mahdollisuuden nähdä, kuinka hyvin atomit, molekyylit, organismit ja mallit ovat onnistuneet.
On väistämätöntä, että kun rakennetaan verkkosivustoa, tiettyjä skenaarioita menetetään. Klassinen esimerkki on pitkä nimi tai ruokailu eri valuutoista ja kielistä.
Tärkein takeaway: Nimeämiskäytännöt ovat tärkeitä. Layering CSS luo puhtaan koodibudion, joka toimii mahdollisimman pienenä.
Suunnittelu on vaikeaa. Et voi suunnitella erillistä mallia, kuten uutislehteä, ja odottaa sen olevan sopiva muuhun sivun kanssa. Tapa, jolla rakennamme verkkosivustoja ja miten ne suunnitellaan, eroavat toisistaan.
Mallit muuttuvat todennäköisesti riippumatta siitä, saavuudumme pois ... Kirjautumisesta tuli merkityksetön vaihe prosessissa, joka vain painoi molempia osapuolia
Käytimme Photoshopia luodaksemme lanka-kehyksiä, joissa nämä tyylitellyt komponentit ovat paikallaan. Kun olimme tyytyväisiä mallien ulkoasuun, muutimme kunkin komponentin eristämiseen. Tämä antoi meille mahdollisuuden varmistaa, että jokainen osa on riittävän joustava työskentelemään missä tahansa verkkosivustolla.
Olimme hyvin tietoisia siitä, että emme pääse allekirjoittamaan mitään suunnittelutyötä. Suunnittelukirja luo esteen, jossa suunnittelija tuntee olevansa painostettu luomaan jotain, joka asetetaan kiveen. Mallit muuttuvat todennäköisesti riippumatta siitä, saavutammeko ne pois vai ei. Yleensä olemme mielellämme mahdollisia muutoksia milloin tahansa projektin aikajanalla. Kirjautumisesta tuli merkityksellinen askel prosessissa, joka vain painoi molempia osapuolia suhteen vahingoksi.
Tietäen, milloin siirtyä Photoshopista koodiksi on tärkeää. Tämä vaihe on paljon aikaisempi kuin olimme tottuneet kahdesta syystä:
Sen sijaan, että voisimme käyttää lisäaikaa Photoshopissa, päätimme sijoittaa aikaa koodiin. Jos meidän pitäisi täydentää kaikkea, sen pitäisi olla koodi, jota kaikki sivuston käyttäjät käyttävät ja näkevät. Meille Photoshop oli työkalu sellaisen tyylin luomiseen, jota voisimme käyttää verkkosivuilla.
Suunnittelu on paljon enemmän tiimin yhteistyötä. Mockupit olivat edelleen erittäin tärkeä osa prosessia, mikä auttoi asiakkaan näkemään, miten sivusto näyttäisi. Jos olisimme kaikki tyytyväisiä suunnittelun yleiseen suuntaan, siirrisimme sen koodiksi. Harvoin käytimme aikaa taaksepäin ja eteenpäin tekemällä muutoksia Photoshop-dokumentteihin.
Key takeaway: Photoshop on loistava työkalu suunnittelukonseptien luomiseen. Siirtyminen koodiin mahdollisimman pian on tärkeää. Täydellinen koodi, ei Photoshop.
Tämän työnkulun kauneus on niin monta paikkaa verkkosivuston tarkistamiseen ja parantamiseen.
On tärkeää huomata, että nämä ovat löyhästi vaiheita projektiprosessissamme. Jos tarvitsemme jotain uutta hankkeen aikana, käsittelemme sitä yleensä itsenäisenä, modulaarisena komponenttina, joka voidaan pudottaa verkkosivustoon ja hyväksyä sivuston suunnitteluteema.
Jokainen näistä vaiheista tarjoaa pisteitä, joilla voimme tarkastella tähänastista työtä. Se mahdollistaa myös tuoreen silmän katsomisen eri näkökulmista.
Jokin näistä vaiheista voimme havaita, että jotkut osat eivät toimi niin kuin on odotettavissa. Tämä on kunnossa. Itse asiassa se on hyvä. Hyvän käytettävyyden saaminen varhaisessa vaiheessa on avain onnistuneelle verkkosivustolle. Paluu ja wire-framing nämä sivuston osat tekevät projektista paremman, kun se menee elää.
Keskeinen takeaway: Älä pelkää palata alkuun, jos jotain on parannettava. Näiden varhaisten hankkiminen tekee projektista paremman, kun se kulkee.
Vietimme päiviä yhdessä varmistaaksemme, että sivuston kaikki osat valmistuivat korkealle tasolle. Testasimme mahdollisimman monta skenaariota varmistaen, että selailukokemus oli johdonmukainen.
Kun tiedot ovat verkkosivustolla, voimme testata sivuston kokonaan. On usein liian helppoa asettaa projekti elää ilman täysin testausta. Voimme tarkistaa nopeuden, helppokulkuisen navigoinnin ja ennen kaikkea ostovirran.
Kaikki mainitsevat Applen olevan perfektionistit, mutta olen varma, että heidän ensimmäiset yritykset eivät olleet täydellisiä. Se vie aikaa ja omistautumista tekemään nämä lopulliset parannukset antamaan meille tuotteita, joita me rakastamme tänään. Laitelaboratoriamme avulla, joka sisältää suurimman osan suosituista laitteista ja käyttöympäristöistä, pystyimme varmistamaan, että kokemus on optimoitu mahdollisimman monella uusimmalla alustalla ja näytön koolla.
Oppiminen kustakin hankkeesta on tärkeää, jotta voimme jatkuvasti parantaa prosesseja, jotka johtavat parempaan verkkosivustoon.
Projektissa syntyi oma kotimainen kuvakirjasto, joka kannustaa projektien välistä johdonmukaisuutta. Kun työskentelet virastossa, meillä voi olla kymmeniä samanaikaisesti kehitteillä olevia projekteja. Kyky kenelle tahansa työskentelemään missä tahansa hankkeessa on tärkeää.
Perusta, jolla voimme kaikki työskennellä, myötävaikuttaa tähän tavoitteeseen.
Verkkosivujen suorituskykyä tarkasteltiin vain projektin loppupuolella. Menestyksekkään reagoivan verkkosivuston on oltava vähäistä ja nopeaa. Valtava valikoima laitteita ja niiden ominaisuuksia vaihtelee suuresti uusista Mac-tietokoneista vanhoihin älypuhelimiin. Kun luot mediasisällön verkkosivustoa, sitä voi olla hyvin vaikea hallita suorituskykyä, varsinkin kun se yrittää parantaa sitä jälkikäteen.
Manchesterissa pidetyssä Upfront-konferenssissa näimme Yesenia Perez Cruz puhuu suorituskyvyn arvioinnista projektin jokaisessa vaiheessa, mukaan lukien suunnittelu. Tämän jälkeen meidän olisi pitänyt toteuttaa tämä. Useiden suunnittelijoiden, kehittäjien ja front-end-kehittäjien tiiminä, joka hallitsee kokonaiskokoa ja suorituskykyä (erityisesti havaitun suorituskyvyn), olisi pitänyt olla suurempi painopiste.
Kaikki sivuilla on suorituskyvyn kustannukset. Tärkeä priorisointi varmistaa, että verkkosivusto ei ole vain nopea, vaan myös useampien laitteiden käytettävissä. Joillakin vanhemmilla laitteilla havaitsimme, että verkkosivusto ei törmäsi pelkästään selaimeen vaan koko laitteeseen. Yritimme nopeuttaa verkkosivustoa taannehtivasti, joten emme voineet tehdä verkkosivustoa niin nopeasti kuin se olisi voinut olla.
Seuraavalla kerralla voimme varmistaa, että suorituskyky on tarttunut prosessin jokaiseen vaiheeseen, joten se ei ole jälkikäteen.