Cum interesul pentru domeniul mobilitatii este in crestere, designul responsive a devenit un subiect fierbinte. Insa acesta nu se limiteaza doar la layouturi adaptabile, ne explica Stephen Hay.
Textul
Stephen Hay este unul dintre sefii companiei Zero Interface si se ocupa de consultant pentru clienti in domeniul designului si strategiilor multi –platforma.
Stephen a scris pentru A List Apart si organizeaza conferintele Mobilism impreuna cu PPK si Krijn Hoetmer. Pe langa activitatea cu clientii, el conferentiaza si scrie despre subiecte legate de layouturi CSS3, web design si accesibilitate.
Ilustratia
Rob Bowen este director creativ la Tracknine, o agentie de grafica si web design care la momentul actual se ocupa de tot felul de proiecte.
Multi designeri si dezvoltatori Web sunt , cu siguranta, familiari cu novatorul articol al lui Ethan Marcotte de pe A List Apart. In scurtul material, a prezentat o abordare a designului web pentru diferite dimensiuni ale ecranului, care implica folosirea unei combinatii de interogari despre media din CSS3 cu layouturi fluide si imagini. Aceasta metoda le permite dezvoltatorilor sa implementeze solutii de design care se adapteaza la marimile ecranului aparatului pe care sunt vizualizate. Este o descoperire importanta; consecinta este ca solutiile separate de design sau chiar site-urile separate destinate diferitelor dispozitive ar putea deveni, in mare masura, de domeniul trecutului.
Este putin probabil sa vreti sa mancati cu un ciocan sau sa folositi furculita pentru a bate un cui in perete. Pastrand analogia, interogarile despre mediu nu vor ajuta continutul sa se potriveasca cu o audienta mobila la fel cum o strategie legata de continut nu va determina o interfat sa arate fantastic si sa functioneze bine pe un dispozitiv de 240×320 de pixeli. Simplificand, exista unealta potrivita la scopul potrivit. Sau mai degraba, pentru noi, cei din dezvoltarea web, adesea exista zeci sau sute de instrumente pentru fiecare scop. Articolul lui Marcotte a descries una dintre muncile pe care ni le asumam atunci cand cream site-uri pentru domeniul mobil. Pare logic ca aceasta sa fie combinata cu alte activitati si respectivele lor seturi de instrumente.
Desktop sau dispozitiv mobil?
Tendinta noastra sau, cel putin, a clientilor nostri este sa gandim totul pornind de la un site pentru desktop care trebuie convertit catre domeniul mobil. Aceasta poate insemna folosirea abordarii prezentate in articolul lui Marcotte. In acelasi timp, poate insemna detectia hardware-ului care apeleaza o pagina web, iar apoi servirea unei pagini adecvate dispozitivului respectiv. Oricum am privi lucrurile, designul si dezvoltatrea pentru domeniul mobil introduce o seama de noi chestiuni de luat in considerare (si reintroduce cateva existente):
- Dimensiunea ecranului : cea mai mare parte a discutiei se invarte in jurul acestui subiect. Din cauza numarului de dispozitive diferite existente in exploatare, este un factor important.
- Rezolutia : 600 de pixeli pe un telefon nu vor arata la fel ca 600 de pixeli pe un computer desktop. Un pixel de aici nu este la fel cu un pixel de acolo.
- Densitatea pixelilor: inrudita cu rezolutia, dar nu acelasi lucru, densitatea pixelilor ne indica numarul de pixeli per inch pe un anume dispozitiv.
- Suportul pentru interogarile despre mediu : interogarile despre mediu sunt un instrument minunat pentru modificarea layoutului pe baza diferitelor caracteristici ale mediului (din care una este latimea ecranului), insa ele nu sunt suportate peste tot.
- Performanta : pentru ca nu toata lumea care foloseste un dispozitiv mobil are o conexiune inceata si nici toti utilizatorii de desktop una rapida, performanta conteaza in intreg spectrul.
- Orientarea : anumite lucruri trebuie sa se schimbe semnificativ din punct de vedere vizual pe baza faptului ca un site sau o aplicatie este vizualizata fie orizontal, fie vertical.
Continutul
Desi chestiunile anterioare sunt importante, exista un lucru pe care suntem tentati sa-l trecem cu vedrea: continutul. Si aici este locul unde sta miezul intregii discutii. Ar trebui sa ajustam continutul la fiecare dispozitiv? Ar trebui sa consideram dispozitivele ca fiind secundare si sa modelam continutul pentru contextul in care este utilizat? Pana la urma, ce inseamna context si cum stim cu oricata certitudine ca respectivul continut va fi utilizat inauntrul unui context dat? De cele mai multe ori, nu vom sti. Si peisajul de scenariu de utilizare se extinde atat de rapid incat nu prea putem pune prea mare baza pe supozitii.
As sugera folosirea unei abordari asupra continutului independent de platforma si a unei abordari in relatie cu platforma asupra experientei de utilizare. Aceasta nu inseamna schimbarea continutului de baza al unui site din cauza faptului ca cineva il viziteaza intr-un telefon, ci, mai degraba, ajustarea si imbunatatirea experientei de utilizare a acelui continut intr-o modalitate care se potriveste cu posibilitatile aparatului, marimea ecranului si/sau cu browserul. Va suna familiar? Ii spunem imbunatatire progresiva de ani de zile si dileme si discutii din anii trecuti apar din nou, imbracand haina mobilitatii. Continutul ar trebui sa fie portabil si independent de platforma/interfata.
Fiecare site sau aplicatie web include continut care este esential scopului sau. Putem sa denumim “scenariu cheie” aceste cazuri fundamentale de utilizare. In cele mai multe cazuri, continutul de baza oferit utilizatorilor ar trebui sa fie identic oriunde poate fi consumat, cu exceptia cazurilor in care “scenariul cheie” este atat de diferit incat acelasi continut nu va mai avea sens.
Consider ca urmatoarele sunt ingrediente cheie in experienta de utilizare pe Web:
- Continutul structurat : acesta este lucrul cel mai important. “Structurat” este aici cuvantul cheie; nu ne intereseaza inca aspectul continutului, pentru ca el poate diferi pe fiecare aparat, ecran, sistem de operare sau browser. Ne intereseaza ce este continutul si ce sens are fiecare bucata de continut in intreg.
- Prezentarea : de aici putem incepe sa ne gandim despre layout la diferite dimensiuni de ecran, la inteligibilitate si la modalitatea de prezentare a informatiilor tabelare.
- Comportamentul : cum se va comporta site-ul in diferite situatii? Ce se va intampla cand Flash nu este disponibil? Fara JavaScript? Fara suport de interogari despre mediu?
- Scopul : motivele pentru care in primul rand cineva utilizeaza site-ul sau aplicatia sunt critice in construirea experientei de utilizare. Desi dispozitivele primesc o atentie deosebita, trebuie sa ne amintim ca nu aparatele sunt central. Fundamental este ceea ce utilizatorii trebuie sa faca pentru a duce la bun sfarsit ceea ce isi propun. Este de asteptat din partea noastra sa facilitam acest lucru.
- Interactiunea : cum trebuie sa interactioneze cineva cu site-ul pentru a-si atinge scopul.
- Circumstantele : multi considera acestea ca fiind contextuale: – care sunt situatii normale cand cineva utilizeaza site-ul? Fiti precauti aici. Aici apar supozitiile despre “oameni in miscare” cand , de fapt, majoritatea oamenilor isi folosesc dispozitivele “mobile” acasa si/sau sezand.
Este interesant ca deseori facem teste cu utilizatorii pe site-uri “desktop”, insa subestimam lucruri precum circumstantele/contextul din domeniul mobilitatii. Testarea ar trebui sa fie aplicabila si spatiul mobil pentru ca ipoteze de genul “ utilizatorii nostri sunt in plina activitate cand ne viziteaza site-ul” ne pot deturna in directia gresita. Daca, la descrierea contextului mobil, tu sau altcineva din echipa foloseste cuvinte precum “probabil” sau “cred” luati o pauza si in considerare testarea cu utilizatorii.
Primul, continutul structurat
Continutul structurat functioneaza peste tot. Practic, daca adaugam prea multe la el, influentam accesibilitatea si usurinta utilizarii lui. Prea multe dependente, prea multe tehnologii, prea multe resurse , prea multa mizerie.
Designul responsiv ar trebui sa inceapa prin continut structurat si cateva stiluri de baza. Bryan Rieger, unul dintre primii care au descris ceea ce este designul responsiv cu mult inainte sa primeasca acest nume, sugereaza ca prima interogare despre mediu este nici o interogare despre mediu.
Ma indoiesc de faptul ca Tim Berners-Lee a stiut ca iPad-ul (sau oricare alta tableta) va fi inventat si folosit pentru a vizualiza primul site Web din lume. Nu este aspectuos, insa, cum nu este altceva decat continu structurat, primul site din lume se poate inca vedea foarte bine practic pe orice dispozitiv care poate incarca pagina. Singura imbunatatire care ii poate fi adaugata este codul HTML, care poate fi actualizat la specificatia curenta. Insa, exista mii de feluri prin care am putea face complet inaccesibil acest continut in numele experientei de utilizare. Luke Wroblewski sustine designul si dezvoltarea in prima instanta pentru domeniul mobil, lucru care are mult sens: pornind activitatea de la cel mai mic numitor comun, incurajeaza imbunatatirile progresive. In toate situatiile avem acelasi continut si experienta oferita, modul cum il consumi sau cum interactionezi cu acel continut se pot schimba in functie de situatia particulara in care te afli. Insa acea situatie nu ar trebui niciodata sa se interpuna intre tine si continut sau serviciu.
In primul rand, continutul structurat inseamna, domeniul mobil. Daca primul site web din lume functioneaza pe dispozitive vechi si noi, e ceva de invatat din acest lucru. Destul de frecvent, problemele din designul mobil sunt legate de lipsa imbunatatirilor progresive si a unei prea mici discriminari intre continut, prezentare si comportament. In mijlocul tuturor acestor idei, exista oportunitatea sa privim experienta de utilizare ca un intreg, indiferent de platforma. Poate fi de ajutor schimbarea opticii asupra unora dintre ele in sensul unei intrebari de genul “ ce nu as schimba pentru domeniul mobil si ce as schimba pentru desktop?”, mai ales atunci cand simplificam experienta de utilizare, “site-urile desktop” suporta multe imbunatatiri. Cum diferentele dintre posibilitatile aparatelor se diminueaza si numarul de aparate diferite creste, argumentele in favoarea “unui singur web” devine tot mai convingatoare.
Mai mult decat design adaptabil
Daca examinam aspectele de mai sus, putem concluziona ca un design cu adevarat responsiv implica mai mult decat folosirea interogarilor despre mediu si grile flexibile. In lumea reala a dezvoltarii Web, cei care vorbesc despre tehnici responsive se refera de obicei la layout adaptabil : caile prin care se poate permite caracteristicilor vizuale ale unui site sau aplicatii sa se modifice in functie de dimensiunea ecranului utilizatorului. Designerul Paul Rand a spus odata: “Designul este arta de a combina forma si continutul”. Aceasta inseamna ca, in sine, un layout nu este design. Layoutul este forma si nu vom ajunge la un design cu adevarat responsiv fara a trata la randul sau si continutul. Articolul lui Marcotte ne arata ca layout-urile adaptabile sunt fructul cel mai accesibil al designului responsiv, insa, in nici un moment nu a intentionat ca noi sa ne oprim acolo. Totusi , pentru un moment, fiecare mica deplasare in directia buna este pozitiva. Asadar, sa aruncam o privire asupra layout-urilor adaptabile – si asupra unor tehnici pe care le putem folosi acum si a unora care s-ar putea sa devina disponibile in viitor.
[showmodule id=”3800″]
Layout-uri flexibile
O grila flexibila conteaza mult la crearea unui layout adaptabil. Prin folosirea procentelor si a em-urilor in locul pixelilor, mai ales pentru latime de coloana, margini si alte asemenea, putem crea layout-uri care se intind si se contracta destul de mult pana incep sa esueze la ambele capete ale sprectrului. Locurile in care un layout da gres sau este nereusit reprezinta punctele de rupere. In aceste puncte de rupere ne pot ajuta interogarile despre mediu, ca sa ne permita sa modificam in acele puncte specte ale layoutului prin aplicarea unor reguli CSS diferite.
Interogari despre mediu
Interogarile despre mediu ne permit sa folosim CSS sau JavaScript pentru a detecta anumite caracteristici ale mediului de afisare. Cele care sunt cele mai utile in acest moment sunt latimea, inaltimea, orientarea si raportul de aspect. Latimea si inaltimea sunt cele mai suportate.
Exista inca noua alte caracteristici, inclusiv promitatoarele resolution, device-width si device-height, insa acestea nu sunt de asa mare ajutor in acest moment, iar device-width si device-height nici macar nu sunt prea precise. Pentru a compensa, interogarile despre mediu pot fi combinate cu meta viewport.
Meta viewport
Caracteristicile device-width si device-height nu prea ne sunt de ajutor acum. Principalul motiv pentru aceasta situatie este ca device-width nu este neaparat egala cu latimea layoutului. De exemplu, un aparat are o latime de 480 de pixeli, iar layoutul prezentat in viewport are aproape 1000 de pixeli, pagina fiind apoi micsorata pentru a o afisa in intregime. Aceasta situatie a fost intentionat lasata asa pentru a permite si layouturilor neadaptabile sa incapa in browserul mobil. Ne intereseaza mai mult latimea viewportului pentru ca trebuie sa gasim o modalitate de a stabili latimea layoutului la aceasta atunci cand testam conditiile de afisare prin intermediul interogarilor despre mediu. Pentru a face acest lucru putem folosi un element META in codul HTML:
meta name=”viewport” content=”width=device-width initial-scale=1”
Secventa spune aparatului “fa latimea viewportului egala cu latimea aparatului”. Putem trece la folosirea interogarilor despre mediul de prezentare
@media screen and (max-width:320px){
div{
width: 80%
}
}
Parametrul “initial-scale” stabileste in acest caz nivelul de zoom la 1(100%), lasand in acelasi timp posibilitati de marire a paginii atunci cand este necesar. Putem fi aproape siguri ca acest stil va fi aplicat browserelor in care viewportul layoutului (ceea ce ne intereseaza) nu este mai mare de 320 de pixeli.
Imagini si solutii pe server
Determinarea imaginilor sa se adapteze o data cu layoutul este o provocare. Dezvoltatorii talentati s-au gandit mult la aceasta problema (de remarcat Scott JEhl de la filament Group). O metoda este atasarea mai multor dimensiuni ale aceleiasi imagini:
img src=”small.jpg?full=large.jpg”
Un script si un fisier .htaccess pe server sunt indeajuns pentru a transmite imaginea adecvata marimii respective de ecran.
Uneori este necesara detectia dispozitivului si nu poate fi facut totul folosind tehnologia de pe partea de client. Multi dezvoltatori se bazeaza pe colectiile de profiluri de dispozitive precum DeviceAtlas si WURFL.
Optiuni pe viitor
Exista cateva instrumente interesante pe care nu le putem folosi peste tot, insa este placut sa te joci cu ele, si cel mai probabil, vor deveni mai utilizabile in viitor. Cele mai interesante sunt SVG (Scalable Vector Graphics) si modelele de layout CSS3 independente de ordinea in codul sursa.
Scalable Vector Graphics ofera o modalitate de a include in solutiile de design imagini independente de rezolutie. Acestea sunt imagini vectoriale, nu de tip bitmap, astfel incat cele mai probabile scenarii de utilizare sunt logourile, fundalurile, butoanele, graficele, diagramele si ilustratiile vectoriale. Fisierele SVG pot fi atasate in acelasi fel ca alte formate de imagini, insa ele pot fi plasate in HTML si folosite impreuna cu JavaScript. Imaginile SVG se vor redimensiona automat si arata la fel de bine la orice dimensiune.
Modulul CSS3 Flexible Box functioneaza in browserele Webkit (cum sunt safari si Chrome) si in Firefox. Le permite dezvoltatorilor sa creeze usor layouturi flexibile, folosind casete incapsulate care se maresc si se micsoreaza in concordanta cu schimbarile de latime si inaltime. Insa fiti precauti : W3C schimba drastic specificatia si, in consecinta, v-as sfatui sa nu folositi Flexbox – cum i se spune de multe ori – in site-uri functionale decat daca nu va deranjeaza sa faceti modificari mai tarziu. Flexbox se bazeaza pe o parte din XUL, limbajul folosit pentru crearea interfetei Firefox. Cand redimensionati fereastra Firefox si toate componentele interftei reactioneaza corespunzator, practic vedeti Flexbox in actiune.
Celelalte doua module pe care sa le aveti in vedere sunt Template Layout si Grid Layout, cel din urma implementat in IE10 developer preview. Ambele pot crea layouturi independente de ordinea in codul sursa; ambele permit crearea unei grile de layout prin intermediul CSS, in care elementele sunt pozitionate explicit sau implicit. Atunci cand sunt combinate cu interogari despre mediul de prezentare, vom dispune de un instrument foarte puternic pentru manipularea layouturilor complexe la diferite dimensiuni de ecran.
Concluzie
Exista indeajuns de multe tehnici care pot fi combinate pentru a inlesni crearea unui design responsiv pentru a discuta doar despre unul. Insa designul resposiv merge mai departe de vizual. In acest moment, este mai mult o tinta, un ideal, ceva pentru care ne-ar placea sa ne luptam astfel incat sa cream cea mai buna experienta de utilizare pentru intreaga audienta indiferent de dispozitiv, platforma sau browser. Layouturile adaptabile sunt o fateta importanta si exista destule unelte si resurse pentru a le implementa astazi. Provocarea va fi examinarea circumstantelor de utilizare si a scenariilor cheie, colectarea datelor si dezvoltarea strategiilor de continut care pot fi combinate cu layouturile adaptabile pentru a crea o solutie de design cu adevarat responsiva.
Sintaxa interogarilor despre mediul de prezentare
O interogare despre mediu acopera un anumit mediu de prezentare pe care multi il recunoastem atunci cand folosim type=”screen” sau type=”print” pentru a atasa fisierele de stiluri. Interogarea despre mediu adauga caracteristici logice acestor tipuri de medii de prezentare si in efect ne permite sa cream declaratii conditionale-precum cele relative la dimensiunea ecranului unui dispozitiv pe care este afisata pagina. Atunci cand aceste declaratii sunt adevarate, sunt aplicate regulile de stil continute in interogare. Interogarile despre mediu au urmatoarea sintaxa:
@media[notIonly] type [and] (expression) { Rules; }
Sa examinam declaratia in detaliu: cuvantul cheie not (optional) neaga interogarea, practic spunand “daca ceea ce urmeaza nu este adevarat, aplica aceste stiluri”. Cuvantul not neaga intreaga interogare asadar
@media not screen and (min-width:600 px)
este evaluata la
@media(not(screen and (min-width:600px))
si nu la
@media(not screen) and (min-width:600px)
Cuvantul cheie only forteaza doar acele browsere care suporta interogarile despre mediu din CSS3 sa evalueze expresia. In esenta, ascunde codul CSS de browserele mai vechi
@media only all and (device-aspect-ratio:16/9)
Type se refera la tipul de mediu, cum ar fi tiparitura, dispozitiv mobil, ecran sau, in acest caz toate.
Cuvantul cheie and ne permite crearea unor interogari complexe
@media screen and (min-width:600px) and (max-width:1200px)
Declaratia va aplica secventa CSS inglobata la viewporturile de tip ecran, unde latimea este cel putin de 600 de pixeli, dar nu mai mare de 1200 de pixeli.
And-ul logic este folosit pentru a adauga limitari unei interogari; poate fi folosit de cate ori doriti. Si in sfarsit, expression este caracteristica mediului pe care vrem sa o testam. Din nou, de cele mai multe ori, veti folosi doar cateva dintre ele. De fapt, respond.js al lui Scott Jehl activeaza doar min-width si max-width in browserele care nu le suporta. Este un script foarte util, deoarece multe layouturi adaptabile testeaza doar latimea viewportului.
Un fapt mai putin cunoscut este ca interogarile despre mediu din CSS permit si un SAU logic. In acest scop poate fi utilizata virgule:
@ media screen and(min-resolution:300dpi), Screen and (-webkit-min-device-pixel-ratio:2)
Declaratia zice “aplica secventa CSS pe ecrane daca densitatea pixelilor este cel putin 300dpi sau daca exista 2 pixeli ai aparatului pentru fiecare pixel CSS”. Ca sa spunem adevarul, inca nu este un exemplu din realitate; aceste caracteristici nu sunt prea bine suportate.
Interogarile media pot fi folosite in cadrul fisierelor CSS:
@media screen and(min-width:600px){ /*reguli*/ }
Insa pot fi aplicate si folosind atributul media al elementului link:
link rel=”stylesheet” href=”styles.css” media=”only screen and (min-width:600px)”
Si in final, ele pot fi importate folosind @ import:
@import url(“import.css”) only all;