Mobiilina ja tabletti laitteet tulevat lähemmäksi maailman lopullista ylivaltaa, verkkosivujen suunnittelu ja tekniikka kilpailevat jatkuvasti kasvavan näytön koon mukauttamiseksi. Työkalujen suunnitteleminen tämän ilmiön haasteisiin vastaamiseksi tuo kuitenkin aivan uudenlaisen ongelmakokonaisuuden, ja yksi viimeisimmistä muotisanoista on 'Reagoiva verkko' . Tämä on haaste saada verkko toimimaan useimmilla, ellei kaikilla laitteilla, heikentämättä käyttäjän kokemuksia. Sen sijaan, että suunnitellaan sisältöä sopivaksi pöytätietokoneille tai kannettaville tietokoneille, tietojen on oltava saatavilla matkapuhelimille, tableteille tai mille tahansa verkkoon liitetylle pinnalle. Kuitenkin tämä reagoiva web-suunnittelu evoluutio on osoittautunut vaikeaksi ja joskus tuskalliseksi.

Vaikka tekstitietojen sijoittaminen voi olla melkein triviaalia, hankala osa tulee, kun otamme huomioon sisällön, kuten reagoivat kuvat, infografiikat, videot jne., Jotka on aikoinaan suunniteltu vain työpöytiä ajatellen. Tämä tuo esiin paitsi sisällön oikean esittämisen kysymyksen myös sen, miten sisältöä itse kulutetaan eri laitteilla. Älypuhelinten käyttäjät eroavat työasemien käyttäjistä. Tietosuunnitelmien ja käsittelynopeuden kaltaisia ​​asioita on myös otettava huomioon. Google on alkanut korostaa mobiililaitteille sopivia sivustoja hakutuloksissaan, joidenkin spekuloimalla että se johtaa huomattavaan pagerank-vauhtiin tällaisille sivustoille. Aikaisemmissa ratkaisuissa puututtiin tähän ottamalla käyttöön vain mobiililaitteille tarkoitettuja aliverkkotunnuksia (ja uudelleenohjauksia), mutta tämä lisäsi monimutkaisuutta ja putosi muodista nopeasti. (Kaikilla sivustoilla ei ole varaa tällä reitillä.)

Reagoivien verkkokuvien etsinnästä

Tässä vaiheessa kehittäjien ja suunnittelijoiden on varmistettava, että heidän verkkosivustonsa kuormitus on optimoitu vastaamaan mobiilisivustoissa olevia käyttäjiä. Yli 20% verkkoliikenteestä on nyt mobiilikäyttäjiä, ja määrä kasvaa edelleen. Kun kuvat ottavat suurimman osan sivun sisältötiedoista, on ensisijaista vähentää tätä kuormitusta. Reagoivan suunnittelukuvan koon muuttamista on yritetty yksinkertaistaa useita, mukaan lukien sekä palvelin- että käyttöliittymäratkaisut. Keskustellaksemme näistä reagoivista kuvaratkaisuista meidän on ensin ymmärrettävä nykyiset kuvan linkittävät puutteet.

-tunnisteessa vain lähde-attribuutti linkittää suoraan kuvaan. Sillä ei ole mitään keinoa määrittää oikean tyyppistä kuvaa ilman lisäosia.

Emmekö voi vain sisällyttää HTML-koodiin kaikkia kuvakokoja ja käyttää display:none CSS-sääntöjen avulla kaikille paitsi oikea kuva? Se on loogisin ratkaisu täydellisessä loogisessa maailmassa. Tällä tavalla selain voi jättää huomiotta kaikki kuvat, joita ei näytetä, eikä teoriassa ladata niitä. Selaimet on kuitenkin optimoitu yleisen logiikan ulkopuolelle. Sivun hahmontamiseksi riittävän nopeasti selain hakee linkitetyn sisällön valmiiksi, ennen kuin edes tarvittavat tyylitaulukot ja JavaScript-tiedostot ladataan. Sen sijaan, että sivuuttaisimme työasemille tarkoitetut suuret kuvat, lopulta lataamme kaikki kuvat ja tuloksena on vielä suurempi sivulataus. Vain CSS-tekniikka toimii vain taustakuviksi tarkoitetuille kuville, koska ne voidaan asettaa tyylitaulukossa (käyttämällä mediakyselyjä).

Joten mitä verkkosivusto on tehtävä?

Reagoivat kuvien skaalausratkaisut

Estämällä vain mobiililaitteille tarkoitetut sivustot / aliverkkotunnukset jää jäljelle käyttäjäagentin haistaminen ja sen käyttäminen oikeankokoisten kuvien näyttämiseen käyttäjälle. Jokainen kehittäjä voi kuitenkin todistaa, kuinka epäluotettava ratkaisu voi olla. Uudet UA-kielet tulevat jatkuvasti esiin, mikä tekee kattavan luettelon ylläpitämisestä ja päivittämisestä raskasta. Ja tietysti tässä ei edes oteta huomioon helposti väärennettävien UA-kielien epäluotettavuutta.

Mukautuvat kuvat

Jotkin palvelinpuolen ratkaisut ovat kuitenkin harkinnan arvoisia. Mukautuvat kuvat on loistava ratkaisu niille, jotka haluavat taustan reagoivan kuvakorjauksen. Se ei vaadi mitään erityisiä merkintöjä, vaan käyttää sen sijaan pientä JavaScript-tiedostoa ja tekee suurimman osan raskaasta työstä sen taustatiedostossa. Se käyttää PHP- ja nginx-palvelimia. Se ei myöskään luota mihinkään UA-haistamiseen, vaan tarkistaa näytön leveyden. Adaptive Images toimii erinomaisesti kuvien pienentämisessä, mutta se on kätevä myös silloin, kun suuria kuvia tarvitaan taideohjaus eli kuvan pienentäminen tekniikoilla, kuten rajaus ja kiertäminen - ei vain skaalaus.

Sencha Touch

Sencha Touch on toinen taustalla oleva reagoiva suunnittelukuvaratkaisu, vaikka onkin parempi kutsua sitä kolmannen osapuolen ratkaisuksi. Sencha Touch muuttaa kuvan kokoa vastaavasti haistamalla UA: ta. Alla on perusesimerkki palvelun toiminnasta:

On myös mahdollisuus määrittää kuvakoot, jos emme halua Senchan muuttavan kuvan kokoa automaattisesti.

Päivän lopussa palvelinpuolen (ja kolmannen osapuolen) ratkaisut vaativat resursseja pyynnön käsittelemiseksi ennen oikean kuvan lähettämistä takaisin. Tämä vie arvokasta aikaa ja puolestaan ​​hidastaa pyyntö-vastausmatkaa. Parempi ratkaisu voi olla, jos laite itse päättää, mitkä resurssit pyytää suoraan, ja palvelin reagoi vastaavasti.

Etupään ratkaisut

Viime aikoina selainpuolella on tapahtunut suuria parannuksia reagoivien kuvien osoittamiseksi.

Elementti W3C on ottanut käyttöön ja hyväksynyt HTML5-eritelmän. Sitä ei tällä hetkellä ole laajalti saatavana kaikissa selaimissa, mutta ei kauan ennen kuin se on luonnollisesti saatavana. Siihen asti luotamme elementin JavaScript-täytteisiin. Polyfillit ovat myös loistava ratkaisu vanhoille selaimille, joilta puuttuu elementti.

On myös tapaus srcset määritteen joka on saatavana useille webKit-pohjaisille selaimille elementti. Tätä voidaan käyttää ilman JavaScriptiä ja se on loistava ratkaisu, jos ei-webKit-selaimet jätetään huomiotta. Se on hyödyllinen pysähdyspaikka parittomassa tapauksessa, jossa muut ratkaisut puuttuvat, mutta sitä ei pidä pitää kattavana ratkaisuna.

Kuvan täyttö

Kuvan täyttö on polyfill-kirjasto elementille. Se on yksi suosituimmista kirjastoista reagoivien kuvien mitoitus- ja skaalausongelmien etupään ratkaisujen joukossa. On olemassa kaksi versiota; Picturefill v1 jäljittelee elementtiä span kun taas Picturefill v2 käyttää elementtiä jo tarjolla olevissa selaimissa ja tarjoaa polyfill-version vanhoille selaimille (esimerkiksi IE> = IE9). Siinä on joitain rajoitukset ja kiertotavat , erityisesti Android 2.3: lle - joka on muuten esimerkki siitä, missä img srcset attribuutti tulee apuun. Alla on esimerkkikuvaus Picturefill v2: n käytöstä:

Parantaakseen suorituskykyä käyttäjillä, joilla on rajoitettu tietosuunnitelma, Picturefill voi olla yhdistettynä laiskaan kuormitukseen . Kirjasto voisi kuitenkin tarjota laajempaa selaintukea ja käsitellä parittomia tapauksia sen sijaan, että luotettaisiin laastareihin.

Imager.js

Imager.js on kirjasto, jonka on luonut BBC uutiset joukkue suorittamaan reagoivia kuvia erilaisella lähestymistavalla kuin Picturefill. Vaikka Picturefill yrittää tuoda elementin tukemattomiin selaimiin, Imager.js keskittyy lataamaan vain sopivat kuvat samalla kun pidät silmällä verkon nopeutta. Se sisältää myös laiskan lataamisen turvautumatta kolmansien osapuolten kirjastoihin. Se toimii käyttämällä paikkamerkkielementtejä ja korvaamalla ne : lla elementtejä. Alla oleva esimerkkikoodi osoittaa tämän käyttäytymisen:

new Imager({ availableWidths: [480, 768, 1200] });

Renderoitu HTML näyttää tältä:

new Imager({ availableWidths: [480, 768, 1200] });

Selaimen tuki on paljon parempi kuin Picturefill, sillä se on käytännöllisempi ratkaisu kuin eteenpäin ajatteleva ratkaisu.

Lähteen sekoitus

Lähteen sekoitus lähestyy reagoivaa kuvaongelmaa hieman eri näkökulmasta kuin muut käyttöliittymäkirjastot. Se muistuttaa jotain 'mobiili ensin' -ajattelukoulusta, jolloin se palvelee oletusarvoisesti pienintä mahdollista resoluutiota. Havaittuaan, että laitteella on suurempi näyttö, se vaihtaa kuvalähteen suurempaan kuvaan. Tuntuu enemmän hakkeroinnilta ja vähemmän täysimittaiselta kirjastolta. Tämä on loistava ratkaisu pääasiassa mobiilisivustoille, mutta tarkoittaa, että työasemien ja / tai tablettien kaksoisresurssien lataaminen on väistämätöntä.

Joitakin muita merkittäviä JavaScript-kirjastoja ovat:

• HiSRC - JQuery-laajennus reagoiville kuville. Riippuvuus jQuerystä voi olla ongelma.
• Mobify.js - Yleisempi kirjasto reagoivaa sisältöä varten, mukaan lukien kuvat, tyylitaulukot ja jopa JavaScript. Se 'sieppaa' DOM: n ennen resurssien lataamista. Mobify on tehokas kattava kirjasto, mutta se voi olla ylivoimainen, jos tavoitteena on vain reagoivia kuvia.

Yhteenveto

Päivän lopussa kehittäjän on päätettävä kumpi reagoiva web-suunnittelu imago-lähestymistapa sopii käyttäjäkuntaan. Tämä tarkoittaa, että tiedonkeruu ja testaus antavat paremman kuvan lähestymistavasta.

Lopuksi alla olevasta kysymysluettelosta voi olla hyötyä harkita ennen sopivan reagoivan kuvaratkaisun valitsemista.

• Ovatko vanhat selaimet ongelma? Jos ei, harkitse nykyaikaisemman lähestymistavan käyttöä (esim. Picturefill, srcset attribuutti)
• Onko vasteaika kriittinen? Jos ei, valitse kolmannen osapuolen tai taustajärjestelmä.
• Ovatko ratkaisujen oltava sisäisiä? Kolmansien osapuolten ratkaisut on tietysti suljettu pois.
• Onko sivustolla jo paljon kuvia, jotka yrittävät siirtyä reagoiviin kuviin? Onko huolta validoinnista tai semanttisista tunnisteista (vai pikemminkin ei-semanttisista tunnisteista)? Tämä edellyttää taustaratkaisua kuvapyyntöjen reitittämiseksi esimerkiksi Adaptive Images -sovellukseen.
• Onko taiteen suunta ongelma (erityisesti suurille kuville, joissa on paljon tietoa)? Kirjasto, kuten Picturefill, on parempi ratkaisu tällaiseen skenaarioon. Myös kaikki taustaratkaisut toimivat hyvin.
• Onko JavaScriptien puutteesta huolestuttavaa? Mikä tahansa käyttöliittymäratkaisuista ei tule kysymykseen, mikä jättää UA-haistamiseen tukeutuvat tausta- tai kolmannen osapuolen vaihtoehdot.
• Onko mobiililaitteiden vasteajoilla etusija työpöydän vasteajoilla? Source Shufflingin kaltainen kirjasto voi olla sopivampi.
• Onko tarpeen antaa reagoiva käyttäytyminen sivuston kaikille osa-alueille, ei vain kuville? Mobify.js saattaa toimia paremmin.
• Onko täydellinen maailma saavutettu? Käytä vain CSS: ää display:none lähestyä!