One Size Fits Some: A Guide to Responsive Web Design Image Solutions

Pe măsură ce dispozitivele mobile și tabletele se apropie de dominația finală a lumii, designul web și tehnologia se află într-o cursă pentru a se adapta la numărul tot mai mare de dimensiuni de ecran. Cu toate acestea, elaborarea de instrumente pentru a face față provocărilor acestui fenomen aduce un set cu totul nou de probleme, unul dintre cele mai recente cuvinte la modă care a apărut fiind „web responsive”. Aceasta este provocarea de a face web-ul să funcționeze pe majoritatea, dacă nu pe toate, dispozitivele fără a degrada experiența utilizatorului. În loc să proiecteze conținut pentru a se potrivi desktop-urilor sau laptopurilor, informațiile trebuie să fie disponibile pentru telefoane mobile, tablete sau orice suprafață conectată la web. Cu toate acestea, această evoluție a designului web receptiv s-a dovedit a fi una dificilă și uneori dureroasă.

Deși poate fi aproape banal să găzduiești informații textuale, partea dificilă vine atunci când luăm în considerare conținut cum ar fi imagini receptive, infografice, videoclipuri și așa mai departe, care au fost odată concepute doar pentru desktop-uri. Acest lucru nu aduce doar problema afișării corecte a conținutului, ci și a modului în care conținutul în sine este consumat folosind diferite dispozitive. Utilizatorii de pe telefoane inteligente sunt diferiți de utilizatorii de pe desktop. Lucruri precum planurile de date și viteza de procesare trebuie luate în considerare, de asemenea. Google a început să evidențieze site-uri adaptate pentru dispozitive mobile în rezultatele căutării sale, unii speculând că va duce la o creștere substanțială a pagerank-urilor pentru astfel de site-uri. Soluțiile anterioare au abordat acest lucru prin implementarea de subdomenii (și redirecționări) numai pentru dispozitive mobile, dar acest lucru a crescut complexitatea și s-a demodat rapid. (Nu orice site are capacitatea de a-și permite această rută.)

În căutarea imaginilor web receptive

În acest moment, dezvoltatorii și designerii trebuie să se asigure că încărcarea site-ului lor este optimizată pentru a satisface utilizatorii care se află pe site-uri mobile. Peste 20% din traficul web este acum utilizatori de telefonie mobilă, iar numărul este în continuare în creștere. Având în vedere că imaginile ocupă cele mai mari cote de date din conținutul paginii, devine o prioritate reducerea acestei încărcări. Au fost făcute mai multe încercări de simplificare a redimensionării imaginii de design receptiv, inclusiv soluții atât pe partea de server, cât și pe cele front-end. Pentru a discuta aceste soluții de imagine receptivă, trebuie să înțelegem mai întâi deficiențele actuale ale legăturii imaginilor.

Eticheta <img> are doar atributul sursă care se leagă direct la imaginea în sine. Nu are nicio modalitate de a determina tipul corect de imagine necesar fără suplimente.

Nu putem să includem toate dimensiunile imaginii în HTML și să folosim regulile CSS pentru a display:none pentru toate, cu excepția imaginii corecte? Aceasta este soluția cea mai logică într-o lume logică perfectă. Astfel browserul poate ignora toate imaginile neafisate si, teoretic, sa nu le descarce. Cu toate acestea, browserele sunt optimizate dincolo de logica comună. Pentru ca pagina să fie redată suficient de rapid, browser-ul preia conținutul legat înainte chiar de a fi încărcate complet foile de stil și fișierele JavaScript necesare. În loc să ignorăm imaginile mari destinate desktop-urilor, ajungem să fi descărcat toate imaginile și să rezulte o încărcare și mai mare a paginii. Tehnica numai CSS funcționează numai pentru imaginile destinate ca imagini de fundal, deoarece acestea pot fi setate în foaia de stil (folosind interogări media).

Deci, ce are de făcut un site web?

Soluții de scalare a imaginilor responsive back-end

Cu excepția site-urilor/subdomeniilor numai pentru dispozitive mobile, ne rămâne cu sniffing user-agent (UA) și să-l folosim pentru a servi imaginile cu dimensiunea corectă înapoi utilizatorului. Cu toate acestea, orice dezvoltator poate atesta cât de nesigură poate fi această soluție. Noile șiruri UA continuă să apară tot timpul, ceea ce face dificilă menținerea și actualizarea unei liste cuprinzătoare. Și, desigur, acest lucru nici măcar nu ține cont de nefiabilitatea șirurilor UA ușor de falsificat în primul rând.

Imagini adaptive

Cu toate acestea, unele soluții pe partea de server merită luate în considerare. Imaginile adaptive este o soluție excelentă pentru cei care preferă o remediere a imaginii receptive la back-end. Nu necesită nici un marcaj special, ci folosește în schimb un fișier JavaScript mic și face cea mai mare parte a muncii grele în fișierul său back-end. Utilizează un server configurat PHP și nginx. De asemenea, nu se bazează pe nici un UA sniffing, ci verifică în schimb lățimea ecranului. Imaginile adaptive funcționează excelent pentru reducerea la scară a imaginilor, dar este și la îndemână atunci când imaginile mari au nevoie de direcție artistică, adică reducerea imaginii prin tehnici precum decuparea și rotația - nu doar scalare.

Sencha Touch

Sencha Touch este o altă soluție de imagine de design responsive back-end, deși este mai bine să ne referim la aceasta ca o soluție terță parte. Sencha Touch va redimensiona imaginea în consecință prin mirosirea UA. Mai jos este un exemplu de bază despre cum funcționează serviciul:

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

Există și o opțiune pentru a specifica dimensiunile imaginii, în cazul în care nu dorim ca Sencha să redimensioneze imaginea automat.

La sfârșitul zilei, soluțiile de pe partea de server (și de la terți) necesită resurse pentru a procesa cererea înainte de a trimite înapoi imaginea corectă. Acest lucru necesită timp prețios și, la rândul său, încetinește călătoria cerere-răspuns. O soluție mai bună ar putea fi dacă dispozitivul însuși ar determina ce resurse să solicite direct, iar serverul să răspundă în consecință.

Soluții front-end

În ultima vreme, au existat îmbunătățiri mari în partea browserului pentru a aborda imaginile receptive.

Elementul <picture> a fost introdus și aprobat în specificația HTML5 de către W3C. În prezent, nu este disponibil pe scară largă pe toate browserele, dar nu va trece mult până când va fi disponibil nativ. Până atunci, ne bazăm pe polyfills JavaScript pentru element. Polyfills sunt, de asemenea, o soluție excelentă pentru browserele vechi, care nu au elementul.

Există și cazul atributului srcset care este disponibil pentru mai multe browsere bazate pe webKit pentru elementul <img> . Acesta poate fi folosit fără JavaScript și este o soluție excelentă dacă browserele non-webKit trebuie ignorate. Este o soluție utilă pentru situațiile ciudate în care alte soluții nu sunt insuficiente, dar nu ar trebui să fie considerate o soluție cuprinzătoare.

Picturefill

Picturefill este o bibliotecă polyfill pentru elementul <picture> . Este una dintre cele mai populare biblioteci dintre soluțiile front-end la problemele de dimensionare și scalare a imaginilor receptive. Există două versiuni; Picturefill v1 imită elementul <picture> folosind span , în timp ce Picturefill v2 utilizează elementul <picture> printre browserele care îl oferă deja și oferă o completare polivalentă pentru cele vechi (de exemplu, pentru IE >= IE9). Are unele limitări și soluții, în special pentru Android 2.3 - care, de altfel, este un exemplu de unde atributul img srcset vine în ajutor. Mai jos este un exemplu de marcare pentru utilizarea Picturefill v2:

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

Pentru a îmbunătăți performanța utilizatorilor cu planuri limitate de date, Picturefill poate fi combinat cu încărcare leneră. Cu toate acestea, biblioteca ar putea oferi un suport mai larg pentru browser și ar putea aborda cazurile ciudate, mai degrabă decât să se bazeze pe corecții.

Imager.js

Imager.js este o bibliotecă creată de echipa BBC News pentru a realiza imagini receptive cu o abordare diferită de cea folosită de Picturefill. În timp ce Picturefill încearcă să aducă elementul <picture> în browsere neacceptate, Imager.js se concentrează pe descărcarea doar a imaginilor adecvate, ținând, de asemenea, cu ochiul la vitezele rețelei. De asemenea, încorporează încărcare leneșă fără a se baza pe biblioteci terțe. Funcționează prin utilizarea elementelor substituent și înlocuirea lor cu elemente <img> . Exemplul de cod de mai jos prezintă acest comportament:

 <div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

HTML-ul redat va arăta astfel:

 <div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

Suportul pentru browser este mult mai bun decât cel al Picturefill, în detrimentul că este o soluție mai pragmatică decât una cu gândire avansată.

Amestecarea sursei

Source Shuffling abordează problema imaginii receptive dintr-un unghi ușor diferit față de restul bibliotecilor front-end. Seamănă cu ceva din școala de gândire „în primul rând mobil”, prin care servește implicit cea mai mică rezoluție posibilă. După ce detectează că un dispozitiv are un ecran mai mare, schimbă sursa imaginii cu o imagine mai mare. Se simte mai mult ca un hack și mai puțin ca o bibliotecă cu drepturi depline. Aceasta este o soluție excelentă pentru site-urile în principal mobile, dar înseamnă că descărcarea de resurse duble pentru computere desktop și/sau tablete este inevitabilă.

Alte biblioteci JavaScript notabile sunt:

• HiSRC - Un plugin jQuery pentru imagini receptive. Dependența de jQuery ar putea fi o problemă.
• Mobify.js - O bibliotecă mai generală pentru conținut receptiv, inclusiv imagini, foi de stil și chiar JavaScript. Acesta „capturează” DOM-ul înainte de încărcarea resurselor. Mobify este o bibliotecă cuprinzătoare puternică, dar poate fi exagerată dacă scopul este doar imagini receptive.

rezumat

La sfârșitul zilei, este la latitudinea dezvoltatorului să decidă care abordare a imaginii de design web receptiv se potrivește bazei de utilizatori. Aceasta înseamnă că colectarea și testarea datelor vor oferi o idee mai bună asupra abordării care trebuie luate.

Pentru a încheia, lista de întrebări de mai jos poate fi utilă de luat în considerare înainte de a decide soluția adecvată de imagine receptivă.

• Sunt browserele vechi o problemă? Dacă nu, luați în considerare utilizarea unei abordări mai moderne (de exemplu: Picturefill, atributul srcset )
• Timpul de răspuns este critic? Dacă nu, alegeți o soluție terță parte sau back-end.
• Soluțiile ar trebui să fie interne? Soluțiile de la terți vor fi evident excluse.
• Există deja multe imagini pe un site care încearcă să treacă la imagini receptive? Există îngrijorări cu privire la validare sau etichetele semantice (sau mai degrabă etichetele non-semantice)? Acest lucru va necesita o soluție back-end pentru a direcționa solicitările de imagine către ceva de genul Adaptive Images.
• Este direcția artistică o problemă (în special pentru imaginile mari cu multe informații)? O bibliotecă precum Picturefill va fi o soluție mai bună pentru un astfel de scenariu. De asemenea, oricare dintre soluțiile back-end va funcționa, de asemenea.
• Există o îngrijorare cu privire la lipsa JavaScript? Oricare dintre soluțiile front-end va fi exclusă, ceea ce lasă opțiunile back-end sau terțe care se bazează pe UA sniffing.
• Există o prioritate pentru timpii de răspuns pe dispozitive mobile față de timpii de răspuns pe desktop? O bibliotecă precum Source Shuffling poate fi mai potrivită.
• Este nevoie de a oferi un comportament receptiv pentru fiecare aspect al site-ului, nu doar imagini? Mobify.js ar putea funcționa mai bine.
• S-a atins lumea perfectă? Utilizați abordarea display:none numai pentru CSS!