Responsive Web Design

Informatica

Responsive Web Design

Byadmin ianuarie 1, 2024

Responsive Web Design

Declarație pe proprie răspundere privind

autenticitatea lucrării de licență/diplomă/disertație

Subsemnatul _________________________________________________________________________ ,

legitimat cu ________________seria ________nr. ___________________________,

CNP ___________________________________________________autorul lucrării

_____________________________________________________________________

_____________________________________________________ elaborată în

vederea susținerii examenului de finalizare a studiilor de ______________

la Facultatea__________________________________, Specializarea ____________________________

din cadrul Universității Tehnice din Cluj-Napoca, sesiunea ____________________ a anului universitar __________________, declar pe proprie răspundere, că această lucrare este rezultatul propriei activități intelectuale, pe baza cercetărilor mele și pe baza informațiilor obținute din surse care au fost citate, în textul lucrării, și în bibliografie.

Declar că această lucrare nu conține porțiuni plagiate, iar sursele bibliografice au fost folosite cu respectarea legislației române și a convențiilor internaționale privind drepturile de autor.

Declar, de asemenea, că aceasta lucrare nu a mai fost prezentată în fața unei alte comisii de examen de licență/diplomă/disertație.

În cazul constatării ulterioare a unor declarații false, voi suporta sancțiunile administrative, respectiv, anularea examenului de licență/diplomă/disertație.

Nume si prenume

_______________________________

Data

_____________________

Semnătura

Absolvent : Ing. Bobăilă Radu-Christian

Conducător: Prof.dr.ing. Mircea VAIDA

SINTEZA LUCRĂRII DE DISERTAȚIE

Enunțul temei: Responsive web design (Design web receptiv)

Responsive web designul reprezintă una dintre ultimele tehnologii aplicate în domeniul dezvoltării aplicațiilor web. În ultimii ani de zile piața terminalelor mobile și a tabletelor a revoluționat practic webul, iar din cauza faptului că au apărut o mulțime de echipamente noi, fiecare cu moduri diferite de afișare a conținutului, a fost nevoie de introducerea unor noi metode de ajustare a paginilor web pentru o bună interpretare a informațiilor pe acestea. Pentru a implementa cu succes o aplicație web responsive este nevoie de o echipă de dezvoltatori care, pentru a atinge cele mai bune rezultate vor colabora cu restul echipelor care au participat la dezvoltarea produsului respectiv. Pentru o bună integrare a acestei funcționalități, pentru managementul proiectului, se va implementa metodologia SCRUM, deoarece aceasta va avea cele mai bune rezultate în cazul de față.

ABSTRACT

Enuntul temei: Responsive web design

Responsive web design is one of the latest technologies that have been applied in web development. Of late years, the mobile device and tablet market revolutionized the web, and because of the fact that many new devices appeared, each one with his own display mode, it took the introduction of some new methods for adjusting web pages to reach good rendering results on each one of these devices. In order to develop with success a responsive web design project, it is needed a team of developers, which will work closely with the other teams that have participated to the development process of that product. To successfully integrate this functionality, for the management of the project, it is being used the SCRUM methodology, because this will reach the best results in this case.

Cuprins

1. Planificarea activității

2. Stadiul actual

3. Fundamentare teoretică

3.1 Elementele Responsive Web Design

3.2 Mobile web

3.3 Paradigmele mobile web design

3.3.1 Codarea în mod regresiv și codarea în mod progresiv

3.3.2 Conținutul în prim plan

3.4 Fluxul de lucru al unui website receptiv

3.5. Renunțarea la metodologia „Waterfall”

3.6 Cercetarea în domeniu

3.7 Metodologia SCRUM

3.7.1 Roluri

3.7.2 Product Owner

3.7.3 Echipa de dezvoltare

3.7.4 Scrum master

3.7.5 Evenimentele SCRUM

3.7.5.1 Sprintul

3.7.5.2 Metodologia SCRUM

3.7.5.3 Întâlnirile

3.7.5.3.1 Întâlnirea de planificare a sprintului

3.7.5.3.2 Întâlnirea zilnică de Scrum

3.7.5.3.3 Întâlnirea retrospectivă

3.7.5.4 Extensii

3.7.5.4.1 Îmbunătățirea backlogului

3.7.5.4.2 Scrum de scrumuri

4. Implementarea soluției adoptate

5. Rezultate experimentale

5.1 Varianta de tip articol

5.2 Varianta de tip metro

6. Concluzii

7. Referințe bibliografice

8. Anexe

Abrevieri:

AJAX: Asynchronous JavaScript and XML

CDN: Content Delivery Network

CSS: Cascading Style Sheets

HTML: Hyper Text Markup Language

HTTP: Hypertext Transfer Protocol

JPEG: Joint Photographic Experts Group

PNG: Portable Network Graphics

RWD: Responsive Web Design

SVG: Scalable Vector Graphics

W3C: World Wide Web Consortium

Figuri:

Figura 1: Design website de tip grid [21]

Figura 2: Tipurile de dispozitive pentru care se realizează web designul responsive [22]

Figura 3: Evoluția diferitelor tipuri de dispozitive pe care este posibilă afișarea unui website [23]

Figura 4: Evoluția comparativă a numărului de utilizatori ai internetului folosind calculatoarele desktop și a numărului de utilizatori ai internetului folosind terminale mobile [24]

Figura 5: Pașii de dezvoltare a unei aplicații web pornind de la terminalele mobile [25]

Figura 6: Reprezentarea grafică a unui request(cerere) HTTP [26]

Figura 7: Schema unei rețele de servere care implementează un CDN [27]

Figura 8: Exemplu de fișier CSS minificat [28]

Figura 9: Codarea progresivă. Codarea regresivă. [29]

Figura 10: Straturile componente ale unei aplicații web [30]

Figura 11: Metodologia waterfall [31]

Tabele:

Tabel 1: Lista celor mai comune dispozitive PC, tablete și telefoane mobile

1. Planificarea activității

2. Stadiul actual

Principiul de bază al web designului, cât și al limbajelor de programare îl reprezintă universalitatea. World Wide Web-ul reprezintă o sursă accesibilă tuturor, și de aceea totalitatea website-urilor existente trebuie să fie universal accesibile, și anume să dețină posibilitatea de a fi accesate și de a fi interpretate corect de către orice dispozitiv hardware care are posibilitatea de a se conecta la Internet.

Primele pagini web au fost realizate folosind limbaj HTML simplu, rezultând pagini web care aveau proprietatea de adaptabilitate automată la orice lățime a browserului web, fiind afișate într-un mod corect pe toate dispozitivele existente la acel moment, fapt care dovedește că una dintre primele proprietăți ale webului a fost universalitatea, mai precis site-urile web au fost gândite în așa fel incât să fie receptive. Odată cu trecerea timpului, din dorința de realizare a unor pagini web mai spectaculoase din punct de vedere estetic, au fost introduse diferite elemente care practic nu au mai putut fi scalate cu atâta ușurință, fiind nevoie de definirea unor containere cu lățime fixă. Prima pagină web realizată oferea o corectă interpretare a ei pe telefoane mobile, tablete și pe orice alte tipuri de dispozitive, având în componența sa numai elemente de tip text si hyperlinkuri. Această pagină a fost relansată în anul 2003 odată cu aniversarea a 20 de ani de World Wide Web.

Cele mai comune designuri utilizate pentru realizarea website-urilor sunt bazate pe gridurile folosite și în tipografie, designuri care au devenit populare la mijlocul anilor 1900. Un grid tipografic reprezintă un sistem ordonat de rânduri și coloane care creează anumite module în care va fi plasat conținutul ulterior. Deși inițial acest model de design(proiectare) a fost conceput pentru realizarea revistelor, ziarelor, majoritatea designurilor web existente în momentul de față utilizează acest concept.

Figura 1) Design website de tip grid [21]

Flexibilitatea webului și inflexibilitatea gridurilor tipografice care au în componență elemente cu lățimi fixe au condus la apariția unor probleme în cazul dispozitivelor care posedă afișaje mici, respectiv rezoluții scăzute, fapt din cauza căruia conținutul nu a mai putut fi afișat corect pe ecran. Soluția la această problemă îl reprezintă web designul receptiv, care transformă un grid inflexibil într-unul flexibil.

Este necesară înțelegerea conceptului de web design receptiv cât și motivul pentru care importanța lui a crescut odată cu trecerea anilor. Această lucrare prezintă importanța utilizării web designului receptiv cât și modalitățile prin care o aplicație web poate fi realizată în scopul îndeplinirii acestui criteriu, fie de a fi modificată în același scop.

Web designul receptiv reprezintă un model sau un tipar de web design prin care sunt folosite standardele web pentru realizarea designurilor flexibile pentru o bună afișare a acestora pe diferitele dispozitive existente.

Figura 2) Tipurile de dispozitive pentru care se realizează web designul responsive [22]

Interfețele cu utilizatorul utilizează multe analogii cu lumea reală, astfel încât atât în lumea reală cât și în cea virtuală, spre exemplu, sunt folosite albume pentru stocarea fotografiilor și coșul de gunoi pentru obiecte nefolositoare etc. World wide webul utilizează deasemenea analogia cu designurile implementate de către tipografii. Astfel, world wide web se definește ca fiind o rețea compusă din mai multe websiteuri. Fiecare website este compus din mai multe pagini, iar fiecare pagină poate fi comparată cu o pagină a unui ziar. Din acest motiv, se poate găsi o legătură strânsă între aceste doua entități diferite, deoarece atât pagina unui ziar cât și o interfață web sunt realizate folosind anumite standarde deja existente și de cele mai multe ori acestea sunt realizate într-un șablon care folosește o lățime fixă.

O mare diferență între aceste două modele existente este aceea că, paginile web, spre deosebire de paginile unui ziar, pot fi accesate utilizând mai multe tipuri de dispozitive. Utilizarea unui număr mare de dispozitive implică folosirea mai multor tehnologii de afișare, din cauza diferitelor browsere de pe care acestea sunt accesate, cât și o multitudine de rezoluții care fac ca o singură pagină să fie interpretată diferit de la un dispozitiv la celălalt. Această variație a interpretării se datorează multiplelor modele de PC-uri existente, laptopuri, tablete, smartphone-uri, etc. Din cauza existenței acestor tehnologii, dezvoltarea unui website compatibil pentru toate aceste tipuri de dispozitive este foarte dificilă. Dezvoltarea mai multor variante pentru grupuri de dispozitive este practic imposibilă din cauza faptului că numărul acestora este foarte mare, cât și din pricina faptului că, odată cu trecerea timpului, sunt dezvoltate din ce în ce mai multe noi tehnologii, numărul acestora crescând exponențial. Web designul receptiv face posibilă modelarea website-urilor pentru multiple medii, folosind un singur conținut pentru interpretarea corectă a conținutului de către toate dispozitivele existente.

Figura 3) Evoluția diferitelor tipuri de dispozitive pe care este posibilă afișarea unui website [23]

Metoda tradițională de dezvoltare a site-urilor web constă în determinarea rezoluției minime pentru care un website poate fi afișat corect pe majoritatea dispozitivelor, iar apoi se realizează o interfeță web cu o rezoluție fixă. Această metodă prin care o singură rezoluție se potrivește pentru toate dispozitivele oferă un mare dezavantaj atât pentru utilizatorii care folosesc ecrane cu rezoluții mari, cât și pe cei care folosesc dispozitive cu rezoluții mici. La momentul apariției unor dispozitive noi pe piață, este necesară realizarea unor noi designuri pentru ca acestea să poată fi adaptate pentru noi rezoluții. Un alt mare dezavantaj al metodei tradiționale de dezvoltare a website-urilor este acela că optimizarea lor a fost realizată numai pentru cele mai utilizate browsere de pe piață, ca și exemple putând fi date Internet Explorer, Mozilla Firefox, Google Chrome. Un prim pas în soluționarea acestei probleme a fost rdiferitelor tipuri de dispozitive pe care este posibilă afișarea unui website [23]

Metoda tradițională de dezvoltare a site-urilor web constă în determinarea rezoluției minime pentru care un website poate fi afișat corect pe majoritatea dispozitivelor, iar apoi se realizează o interfeță web cu o rezoluție fixă. Această metodă prin care o singură rezoluție se potrivește pentru toate dispozitivele oferă un mare dezavantaj atât pentru utilizatorii care folosesc ecrane cu rezoluții mari, cât și pe cei care folosesc dispozitive cu rezoluții mici. La momentul apariției unor dispozitive noi pe piață, este necesară realizarea unor noi designuri pentru ca acestea să poată fi adaptate pentru noi rezoluții. Un alt mare dezavantaj al metodei tradiționale de dezvoltare a website-urilor este acela că optimizarea lor a fost realizată numai pentru cele mai utilizate browsere de pe piață, ca și exemple putând fi date Internet Explorer, Mozilla Firefox, Google Chrome. Un prim pas în soluționarea acestei probleme a fost realizarea unui website pentru toate dispozitivele fixe, cum ar fi PC-urile, iar pentru dispozitivele mobile a fost propusă realizarea unei aplicații native. Aceasta a fost o soluție foarte utilizată până la apariția tabletelor, fapt care a dat din nou peste cap modul de abordare al problemei.

Statisticile arată faptul că numărul utilizatorilor care navighează pe internet, folosind dispozitivele mobile și tablete, urmează să depașească numărul utilizatorilor care folosesc PC-urile sau laptopurile pentru navigare, la începutul secolului XXI, iar, de aceea, dezvoltarea rapidă a unei soluții optime este o necesitate. Web designul receptiv nu mai pune accent pe realizarea unei aplicații web pentru un anumit dispozitiv, ci are ca și scop principal dezvoltarea aplicației în jurul conținutului. În concluzie, un website receptiv trebuie să fie realizat astfel încât el să fie adaptabil pentru orice tip de dispozitiv și la orice rezoluție.

3. Fundamentare teoretică

3.1 Elementele Responsive Web Design

Există trei elemente care definesc conceptul de Responsive Web Design (RWD). Cele trei elemente sunt:

– Layout fluid

– Medii flexibile

– Media Queries

Primul element, layoutul fluid, se deosebeste de layout-urile fixe care specifică dimensiunile elementelor container în pixeli, puncte, inch. Un layout fluid specifică dimensiunile în unități relative, cum ar fi reprezentarea procentuală, reprezentarea in „em”, „rem”. Lățimea unui layout fluid este specificată ca fiind relativă la dimensiunea ferestrei browserului în care este afișată pagina, iar lățimile containerelor copii urmând la rândul lor să fie calculate relativ la dimensiunile containerului părinte.

Elementele multimedia flexibile, cel de-al doilea element din care se compune RWD, și anume imaginile, video-urile pot avea dimensiunile calculate și ele în funcție de elementul părinte.

Media queries reprezintă cel de-al treilea element care definește RWD și reprezintă practic modalitatea prin care un fișier sau anumite proprietăți Cascading Style Sheets (CSS) sunt utilizate pentru afișarea conținutului în funcție de contextul în care se realizează afișarea paginii [3].

Un layout fluid, deasemenea cunoscut ca fiind un layout lichid, reprezintă opusul unui layout fix. Layoutul fix are un element container cu o lățime fixă, iar restul elementelor din interiorul acestuia vor păstra practic aceeași dimensiune indiferent de echipamentul de pe care websiteul este accesat. Un layout fluid are un container care se mulează pe dimensiunea ferestrei, având lățimea definită procentual față de dimensiunea ferestrei în care este afișat [11]. Spre exemplu, un design cu o lățime de 90% se va adapta perfect pe oricare dintre dispozitivele existente, iar restul containerelor copii se vor adapta și ele conform regulilor definite de către programator.

Majoritatea website-urilor au conținutul centrat pe pagină pe plan orizontal. O tehnică foarte utilizată în cadrul RWD îl reprezintă definirea unei lățimi de 90% pe elementul părinte, containerul conținutului, cât și definirea marginilor pentru centrarea conținutului prin utilizarea urmatoarelor proprietăți CSS:

margin-left: auto;

margin-right: auto;

Aceste două instrucțiuni CSS nu realizează altceva decât să lase în sarcina browserului web calculul marginilor, în așa fel încât elementul să fie centrat în elementul container.

Deasemenea, o altă tehnică utilizată în realizarea RWD, este reprezentată de specificarea unei dimensiuni minime pentru containerul părinte, pentru a nu avea un conținut nelizibil din cauza împărțirii lui într-un mod neorganizat. De aceea, s-a luat în calcul dimensiunea minimă a unui dispozitiv mobil, de pe care este accesat un website, și anume cea de 320 pixeli, după care se specifică pentru acest element container o dimensiune minimă, folosind următoarea linie de cod CSS:

min-width: 320px;

Utilizarea elementelor multimedia în cadrul paginilor web duce la apariția unor probleme, în cazul în care se dorește o adaptare perfectă a acestora pentru diferitele dispozitive. Marea problemă o reprezintă faptul că, în vederea utilizării în cadrul unui design receptiv, le este specificată o lățime de 100% din elementul părinte. După cum se stie, în cadrul aplicațiilor web, pentru a crește eficiența aplicațiilor și a reduce timpul de încărcare a paginilor, se folosesc elemente multimedia optimizate, și anume elemente care au calitatea scăzută destul de mult pentru a nu ocupa un spațiu mare de stocare, fapt care implică automat o durată scăzută petrecută pentru descărcarea respectivului element. Elementele care suferă de aceste probleme sunt imaginile și videoclipurile. O soluție pentru rezolvarea acestei probleme îl reprezintă limitarea lățimii elementelor multimedia la un prag superior, prag care reprezintă lățimea propiu-zisă a imaginii sau pe cea a videoclipului. Spre exemplu, dacă am avea o imagine JPEG cu lățimea de 340 pixeli, pentru a realiza o adaptare a ei la multiple rezoluții, dar și pentru a păstra o afișare corectă a acesteia, se vor specifica următoarele linii de cod CSS:

max-width: 340px;

width: 100%;

Deasemenea, în momentul în care se utilizează un design receptiv pentru o anumită pagină, elementele multimedia își pot pierde practic forma, printr-o utilizare incorectă a proprietăților acestora de lățime și înălțime. De aceea, cea mai uzuală practică prin care o imagine își păstrează corect raportul dimensiunilor este aceea de a ii specifica o lățime de 100% și o înălțime care este lăsată să fie calculată automat de către browserul web. Acest lucru se realizează folosind:

height: auto;

width: 100%;

Media queries au fost introduse ca și parte componentă a standardului CSS3 propus de World Wide Web Consortium (W3C), care reprezintă organizația care realizează reglementările referitoare la World Wide Web. Media queries sunt instrucțiunile CSS care sunt încărcate numai în momentul în care condiția impusă este corectă. Spre exemplu, dacă avem un media query care specifică o anumită lățime minimă a browserului, în momentul în care lățimea ferestrei are o valoare mai mică decât acel prag se aplică stilurile specificate în acel fișier sau portiune a fișierului CSS. Condițiile utilizate in Media queries sunt denumite și break-points și în mod normal acestea sunt exprimate in pixeli.

Deși standardele referitoare la realizarea website-urilor responsive specifică faptul că lățimea containerului părinte trebuie să fie 100% din lățimea ferestrei, uneori designurile responsive folosesc o lățime fixă până când lățimea ferestrei ajunge la acea valoare, iar apoi aceasta se va adapta folosind regulile generale și anume cele de a folosi o lățime fie de 100%, fie putin mai mică. În general, website-urile care folosesc această tehnică au o dimensiune fixă de 980px, iar la momentul în care lățimea ferestrei ajunge sub acest prag, se vor aplica noile stiluri folosind media queries. Acest lucru poate fi realizat prin utilizarea următoarei secvențe CSS:

@media screen and (max-width: 980px) {

/*Regulile CSS pentru lățimi

mai mici de 980px*/

}

Web designul receptiv este adaptiv prin definiție, dar din punct de vedere tehnic acesta se adaptează numai la praguri de rezoluții ale afișajului. În afară de adaptarea din punctul de vedere al rezoluției dispozitivului de pe care aplicația web este accesată, este necesară o adaptare și la alte condiții cum ar fi viteza de descărcare a rețelei, dispozitivele cu ecran tactil, browser și sistem de operare.

Un mod de abordare mai avansat din punctul de vedere al eficienței, pentru crearea elementelor multimedia, este acela de a lua în considerare și dimensiunile elementelor de acest tip pentru a realiza o ajustare din punctul de vedere al timpului de descărcare. În momentul în care avem o imagine sau un videoclip care trebuie afișat în cadrul unei interfețe web, deși conținutul acesteia va fi la un moment dat afișat la dimensiuni mai mici, acest efect este doar unul vizual, dimensiunea respectivului element multimedia rămânând aceeași pe tot parcursul vizualizării, și anume va păstra dimensiunea inițială, chiar dacă aceasta este una semnificativă. Acest fapt trebuie luat în considerare deoarece performanțele aplicației care va utiliza asemenea elemente vor fi foarte scăzute. Soluția pentru rezolvarea acestei probleme, a elementelor multimedia, este aceea de a încărca din fișiere diferite imaginile, videoclipurile, pentru a avea o optimizare corectă a aplicației. În acest moment nu există o anumită tehnică standardizată pentru a realiza acest lucru, dar o metodă propusă este aceea de a folosi tagul introdus în standardul HTML5 <picture>. Alte tehnici propuse pentru rezolvarea acestui tip de problemă îl reprezintă utilizarea SVG (Scalable Vector Graphics), servere proxy sau soluții bazate pe partea de server [6].

Designul adaptiv reprezintă un domeniu destul de vast și poate să includă nu numai adaptarea afișării elementelor multimedia, ci și adaptarea conținutului pentru o mai bună întrebuințare a acestuia de către utilizator, cum ar fi:

Adaptarea paletei de culori și setărilor de contrast

Adaptarea dimensiunilor fonturilor

Adaptarea zoomului

Adaptarea acestor parametrii poate fi realizată de către programator folosind un set de stiluri definite în limbajul CSS. Designul adaptiv nu reprezintă numai adaptarea conținutului la diferite rezoluții si browsere web, ci și formatarea conținutului pentru a oferi o formă corectă de interpretare a acestuia pe diferite platforme. Nu există numai diferite browsere pentru stațiile PC desktop sau dispozitive mobile, ci există și browsere embedded în cadrul aplicațiilor. Câteva exemple de astfel de browsere de tip embedded sunt cele folosite de Facebook si Twitter, în cadrul aplicațiilor native dezvoltate de aceste două rețele de socializare, care permit accesarea hyperlinkurilor în cadrul view-urilor create în interiorul aplicațiilor.

3.2 Mobile web

Termenul „mobile web” poate fi definit ca fiind o ramură a webului, fiind constituită din website-uri destinate exclusiv pentru terminalele mobile, sau, în acest caz, reprezintă accesarea unui website direct de pe un terminal mobil. În timp ce există website-uri și servicii care sunt proiectate în mod special pentru acest tip de terminale, tehnologia a evoluat în așa fel încât orice aplicație web poate fi accesată pe orice tip de dispozitiv care folosește un browser web.

Tabel 1) Lista celor mai comune dispozitive PC, tablete și telefoane mobile

O versiune diferită a aplicației, pentru telefonul mobil, oferă o serie de dezavantaje din punctul de vedere al funcționalităților oferite, având practic funcționalități mult mai puține față de aplicațiile desktop. Costul necesar dezvoltării unei aplicații mobile a devenit unul destul de ridicat la momentul în care o serie de alte funcționalități în afara celor de bază au început să fie implementate. Mai multe soluții referitoare la această problemă au fost descoperite, cea mai uzuală tehnică folosită fiind cea de a avea o aplicație dezvoltată pe un server proxy, care are ca și principală funcționalitate transformarea aplicațiilor web desktop în aplicații optimizate pentru dispozitive mobile [12]. Ca și exemple de astfel de aplicații pot fi date următoarele: Highlight, Digestor, M-Links.

În luna iunie a anului 2007, compania Apple a lansat iPhone, telefonul care practic a contribuit la revoluționarea webului. Premergător acelui moment, navigarea pe dispozitive mobile era foarte lentă și deasemenea neoptimizată din pricina faptului că respectivele terminale erau realizate folosind displayuri foarte mici, tastaturi compuse din 12 butoane și joystickuri. Introducerea textului era foarte dificilă, iar selectarea linkurilor folosind joystickul reprezenta o metodă mult prea dificilă și nu tocmai optimă pentru navigarea pe internet. Majoritatea website-urilor aveau dezvoltată numai o interfață, și anume una optimizată pentru dispozitivele desktop, fapt care făcea foarte dificilă și neplăcută experiența pentru utilizatorii de terminale mobile, pentru că, pentru vizualizarea conținutului, era nevoie ca utilizatorul să scrolleze atât pe verticală cât și pe orizontală [2]. Noul telefon propus de Apple, iPhone, folosea un sistem de operare care permitea utilizarea browserului Safari, care reprezenta o bună soluție pentru vizualizarea website-urilor desktop pe un ecran tactil cu o rezoluție de 320x480px. Ecranul tactil facilita modul în care utilizatorul putea utiliza acea interfață web, deoarece scrollarea se putea realiza într-un mod foarte usor, iar mărirea respectiv micșorarea conținutului era foarte facilă. Din momentul lansării pe piață a acestui nou dispozitiv, traficul web în cadrul rețelelor de telefonie mobilă a crescut până la 5000% [13].

Figura 4) Evoluția comparativă a numărului de utilizatori ai internetului folosind calculatoarele desktop și a numărului de utilizatori ai internetului folosind terminale mobile [24]

Începând cu anul 2014, numărul utilizatorilor de terminale mobile a depășit numărul utilizatorilor de calculatoare, în special din nevoia continuă pentru mobilitate și transportul datelor. Statisticile arată faptul că 74% din tinerii cu vârstele cuprinse între 12 și 17 ani accesează internetul folosind terminale mobile, tablete sau telefoane, iar 26% dintre aceștia folosesc numai smartphone-uri [10].

Odată înmulțirea spectaculoasă a numărului utilizatorilor de terminale mobile, proprietarii website-urilor au fost nevoiți să acorde o mai mare atenție acestei categorii de vizitatori și au fost nevoiți deasemenea să îmbunătățească interfețele paginilor pentru a fi compatibile într-o mare măsură cu afișarea pe acest tip de dispozitive. O soluție comună pentru soluționarea acestei probleme a fost, și încă mai e folosită uneori, aceea de a oferi o versiune separată a website-ului pentru utilizatorii terminalelor mobile. De obicei, această versiune oferită utilizatorilor are o funcționalitate redusă, conținut diferit, dar totuși păstrează într-o oarecare măsură același layout. Această soluție are un mare dezavantaj, și anume faptul că trebuie întreținute două versiuni diferite ale website-ului, în loc de întreținerea doar uneia singure. Detecția terminalelor mobile folosind „user agent-ul” sau posibilitatea de ecran tactil oferită de anumite terminale poate da o anumită probabilitate de eroare în realizarea acestei detecții. Eroarea poate apărea din cauza faptului că, utilizând un terminal mobil cu un afișaj la o rezoluție foarte mare, s-ar putea ca acesta să ofere o bună reprezentare a conținutului afișat și pe calculator, dar din cauza faptului că acesta a fost detectat ca și terminal mobil, el va afișa o versiune simplificată în locul versiunii originale a website-ului. În această categorie sunt incluse noile smartphone-uri și tablete care au început să devină din ce în ce mai performante și reușesc să înlocuiască din ce în ce mai mult calculatoarele desktop și laptopurile.

Creșterea numărului terminalelor mobile pe piață nu a însemnat adăugarea suportului numai pentru dispozitivele cu afișaj la rezoluție mică, ci a revoluționat practic modul în care internetul este folosit. Navigarea pe internet nu se mai realizează numai de pe telefoanele mobile, tablete sau calculatoare, ci navigarea poate avea loc simultan de pe toate aceste tipuri de dispozitive. Ca și exemplu poate fi dată situația în care un utilizator dorește să navigheze pe un website, începe navigarea după care el este nevoit să părăsească încăperea, dar continuă să navigheze pe același website folosind un terminal mobil. Fenomenul descris înainte poartă numele de „multi-screening”, iar acesta poate fi împărțit în două categorii: „screening” secvențial, care înseamnă practic folosirea simultană a unui singur dispozitiv pentru navigare și „screening” simultan, caz în care navigarea se realizează pe mai multe dispozitive în același timp [14].

Contextul joacă un rol foarte important în cazul multi-screeningului. Un dispozitiv mobil poate asigura navigarea în orice locație în care este disponibilă o conexiune către internet. Spre exemplu, telefonul mobil poate fi folosit pentru navigare atât acasă cât și în mijloacele de transport, sau pe stradă unde există acoperire fie din partea unei rețele wireless, fie unde operatorul de telefonie mobilă oferă suport pentru internet. Uneori, este nevoie de utilizarea unui anumit serviciu pentru respectiva aplicație în funcție de contextul de pe care se realizează navigarea, fapt care nu necesită numai o interfață web receptivă, dar deasemenea are nevoie de actualizarea continuă a informațiilor pentru a avea întotdeauna versiunea curentă a ceea ce se urmărește.

Odată cu această evoluție, trebuie analizate foarte bine cerințele pentru aplicații, cât și piața pentru care aceasta a fost dezvoltată. Pentru a determina cu precizie tipurile de dispozitive de pe care este accesată aplicația, cât și categoriile de persoane care o accesează, trebuie folosit serviciul de web analytics. Dacă în urma acestei analize rezultă faptul că aplicația este accesată de un număr mare de utilizatori de terminale mobile, atunci recomandarea este aceea de optimizare a respectivului website folosind un design receptiv [15].

3.3 Paradigmele mobile web design

În cazul dezvoltării unei aplicații cu o interfață optimizată pentru telefonul mobil, pasul cel mai important este reprezentat de realizarea designului pentru acest tip de dispozitive. Această metodă presupune deasemenea pregătirea conținutul website-ului pentru aplicațiile mobile, fapt care implică automat o clasificare a conținutului în funcție de relevanță, astfel conținutul cu cea mai mare importanță se va regăsi pe acest tip de dispozitiv, iar in jurul acestui conținut va fi dezvoltată și restul aplicației. Această paradigmă subliniază faptul că, este mult mai ușor ca, odată cu creșterea rezoluției, și implicit a suprafeței vizibile, să se adauge conținut cu relevanță mai mică decât metoda prin care odată cu scăderea rezoluției să fie înlăturate elementele mai puțin relevante. De obicei, în momentul în care pe o pagină web rămâne spațiu disponibil, pentru o maximizare a profitului se vor plasa în respectivele zone lăsate libere reclame, promoții cât și alte tipuri de conținut neesențial. Afișajul unui telefon mobil are o rezoluție și o dimensiune a afișajului prea mică pentru a face posibilă afișarea unui asemenea tip de conținut. De aceea, în momentul în care se face designul unei aplicații, designerul trebuie să cunoască foarte bine elementele cele mai importante pentru acea aplicație, cât și modul în care utilizatorii o vor folosi, pentru a putea realiza cea mai bună optimizare pentru diferitele tipuri de dispozitive cât și de a optimiza modul în care aplicația este percepută de către utilizator pentru a îi capta atenția într-o măsură cât mai mare [13].

Figura 5) Pașii de dezvoltare a unei aplicații web pornind de la terminalele mobile [25]

Odată cu diminuarea conținutului vizibil, scade și cantitatea de conținut care va fi încărcată în aplicație. Rețelele de telefonie mobilă nu oferă o viteză foarte bună pentru navigare ca și furnizorii de internet prin fibră optică sau cablu tv, de aceea, acesta trebuie sa fie unul dintre cele mai importante criterii de care trebuie ținut cont în momentul în care se face dezvoltarea unei aplicații. Diminuarea conținutului optimizează atât timpul de încărcare al paginilor cât și costul necesar accesării aplicației. Deasemenea, odată cu realizarea acestui pas, vor crește performanțele și pentru interfețele disponibile pentru tablete si calculatoare desktop, fapt care avantajează foarte mult utilizatorii, din prisma faptului că, și în cazul în care aplicația este accesată de pe un calculator desktop, banda de viteză disponibilă nu este obligatoriu să fie foarte mare. Studiile arată faptul că, în cazul în care o aplicație are nevoie de mai mult de 5 secunde pentru a încărca conținutul, 74% dintre persoanele care ar fi dorit să viziteze acel website vor închide browserul și nu vor mai încărca pagina respectivă [8].

Pentru atingerea unor performanțe cât mai bune din punctul de vedere al încărcării website-urilor, există câțiva pași care trebuie urmați: minimizarea numărului de requesturi HTTP, minimizarea datelor care vor fi încărcate în vederea vizualizării și optimizării vitezei de interpretare a conținutului de către browser.

Figura 6) Reprezentarea grafică a unui request(cerere) HTTP [26]

Un request HTTP este reprezentat de un request realizat de către client, reprezentat de către browser, către serverul web, pe care rulează aplicația. Clientul cere serverului o informație, după care serverul trimite un răspuns. Fiecare request necesită o conexiune HTTP inițializată și tratată de către server. Mai multe asemenea requesturi presupun un timp mai mare de așteptare, timp în care conexiunea între client și server este deschisă, respectiv procesarea fiecărui request în parte și trimiterea unui răspuns clientului. Conexiunile lente vor crește semnificativ timpul de încărcare al paginilor, și, cu cât vom avea mai multe requesturi de făcut către server, cu atât mai scăzute vor fi performanțele aplicației respective. De aceea, este recomandat, pentru a optimiza cu succes un website, să avem un număr de requesturi HTTP cât mai mic, acest fapt realizându-se prin gruparea imaginilor, codului CSS și a codului Javascript în pachete individuale. Spre exemplu, imaginile pot fi grupate în așa numitele sprite-uri, care reprezintă o imagine de dimensiuni mai mari în care vor fi plasate mai multe imagini de dimensiuni relativ mai mici pentru o optimizare a timpului de încărcare al paginii. De exemplu, în sprite-urile respective pot fi grupate toate butoanele, iconițele, cât și alte imagini necesare pentru afișarea pe o pagină web. Codurile CSS și Javascript pot fi concatenate la rândul lor într-un singur fișier CSS, incluzând în el anumite librării și alte porțiuni de cod necesare pentru o bună reprezentare și interacțiune a website-ului cu utilizatorii. Un alt factor care poate fi optimizat este acela de a lucra cu modul de caching activat, pentru a preveni eventuale requesturi inutile în cazul website-urilor care sunt accesate de mai multe ori de pe un singur dispozitiv. Cachingul poate avea loc atât la nivel de server cât și la nivel de client. Există anumite servere specializate, care sunt furnizate ca și servicii pentru utilizatori, care la momentul în care se va face un request, acesta va avea păstrat în cache-ul său intern o versiune a conținutului și îl va livra cu rapiditate utilizatorului. Deasemenea, acest tip de server poate avea și opțiunea de a precompila anumite părți a codului pentru a minimiza timpul necesar pentru livrarea conținutului către utilizator. În mod curent, pentru o optimizare și mai bună a livrării conținutului către utilizatori, în cazul în care un website este accesat de utilizatori din întreaga lume, se folosește așa numitul CDN (Content Delivery Network). Un CDN este reprezentat de o rețea de servere, plasate în diferite locații în lume, pe fiecare server în parte regăsindu-se aceeași variantă a website-ului, atât partea de imagini, cod CSS și Javascript, cât și partea de cod care trebuie să fie procesată de către server, iar în funcție de coordonatele de pe care este accesată aplicația, se va căuta serverul cel mai apropiat de acel utilizator, iar respectivul server va furniza răspunsul pentru acesta.

Figura 7) Schema unei rețele de servere care implementează un CDN [27]

Gruparea codului CSS și Javascript, cât și compresia și optimizarea imaginilor pot fi folosite pentru minimizarea dimensiunii datelor necesare pentru afișarea paginilor web. Un fisier care conține cod CSS, cât și un fișier care conține cod Javascript, pentru a respecta condiția de minimizare a dimensiunii, trebuie supus procesului de concatenare, cât și procesului de minificare. Minificarea fișierelor are ca și rezultat fișiere de dimensiuni foarte mici, acest lucru realizându-se prin eliminarea tuturor spațiilor care nu sunt necesare, proces care poate fi realizat folosind aplicații specializate pentru proces, cât și rescrierea funcțiilor pentru a realiza optimizarea codurilor Javascript. Imaginile la rândul lor trebuie să fie comprimate cu anumite setări optime pentru a rezulta imagini la o calitate cât mai bună, dar și o dimensiune a fișierului cât mai mică. Imaginile de tip PNG nu suportă compresia, dar se poate înlătura surplusul de informații care scad practic performanțele. O metodă des întâlnită în optimizarea website-urilor este aceea de a încărca în mod implicit imaginile la dimensiunile lor cele mai mici, după care, în cazul în care este nevoie, să fie preluate de pe server imaginile la dimensiuni mai mari. Această metodă are ca și mare dezavantaj creșterea numărului de requesturi către server. Pe lângă aceste metode de optimizare a performanțelor, serverele au posibilitatea de a comprima datele trimise către utilizator, aceasta în cazul în care se cunoaște posibilitatea navigatorului web de a decomprima aceste date.

O altă metodă de a optimiza conținutul paginilor este aceea de a reprezenta fundalurile, care în mod normal încărcau o imagine, sub forma codului CSS3, recent introdus ca și standard, și care deasemenea este într-o continuă dezvoltare. Spre exemplu, se pot crea degradeuri utilizând CSS3, umbre pentru diferite elemente, umbre pentru texte, etc. toate acestea contribuind atât la îmbunătățirea vitezei de încărcare a paginilor cât și la reducerea dimensiunii datelor.

Figura 8) Exemplu de fișier CSS minificat [28]

Un criteriu foarte important este acela de a nu folosi pe paginile create cod CSS sau Javascript neutilizate, cum ar fi anumite librării de Javascript UI, griduri CSS, decât în cazul în care acestea sunt absolut necesare.

Viteza de încărcare este deasemenea importantă pentru calculatoarele desktop și, orice tip de întârzieri, fie ele cât de mici, pot afecta în mod negativ performanțele acestuia și, odată cu acestea, poate scădea și profitul afacerii respective [13].

Paradigma „mobile first” aduce odată cu utilizarea ei un suport lărgit pentru accesibilitate. Accesibilitatea este proprietatea unui website de a putea fi încărcat de pe orice browser și de a putea fi utilizat de către orice tip de utilizator, indiferent că acesta ar avea anumite dizabilități sau nu. Deasemenea, un website trebuie să poată afișa într-un mod corect informațiile pe orice tip de browser, fie că acesta este un browser care rulează pe o tabletă, calculator, telefon ori pe un televizor modern. De aceea, un alt criteriu care practic ar trebui pus la același nivel de importanță ca și cel de „mobile first” trebuie să fie criteriul de „accesibility first”. Un criteriu important din punctul de vedere al accesibilității este acela de citire. Modul și ușurința cu care un website poate fi citit și utilizat de către un utilizator reprezintă unul dintre cele mai importante criterii de care trebuie să se țină cont la momentul designului și implementării unei pagini web. Acest criteriu asigură odată cu respectarea lui și o mai bună indexare a website-ului în cadrul motoarelor de căutare, deoarece criteriul principal al acestora este acela de semantică din punctul de vedere pur, cât și semantica din punctul de vedere al codului scris [16].

3.3.1 Codarea în mod regresiv și codarea în mod progresiv

Aceste două metode de codare sunt strâns legate una de cealaltă. Codarea în mod regresiv are ca și principală țintă atingerea celor mai bune performanțe în browserele moderne, după care sunt înlăturate elementele care nu sunt suportate de către browserele învechite. Spre deosebire de codarea în mod regresiv, codarea în mod progresiv are ca și punct de pornire designul pentru browserele cu o funcționalitate și anumite proprietăți limitate, după care se realizează o îmbunătățire constantă a codului scris pentru a adăuga elemente mai sofisticate pentru browserele care suportă aceste noi caracteristici. Codarea în mod progresiv, în mod teoretic, are ca și rezultat o aplicație care este suportată de către orice tip de browser, indiferent de dispozitivul sau sistemul de operare pe care acesta operează.

Figura 9) Codarea progresivă. Codarea regresivă. [29]

Codarea regresivă are ca și principal scop dezvoltarea aplicației pentru browserele moderne, după care se realizează o diminuare treptată a funcționalităților la fiecare pas în care apare o eroare de reprezentare a unei proprietăți, sau la momentul apariției unei erori de funcționalitate.

Codarea regresivă aduce odată cu ea anumite avantaje din punctul de vedere al programatorului, și anume simplificarea codului necesar pentru realizarea unui anumit layout. Spre exemplu, dacă s-a optat pentru un design care necesită colțuri rotunjite, umbre, atunci din punctul de vedere al implementării se renunță la codarea folosind proprietățile introduse odată cu standardul CSS3, și se trece la o codare mult mai rudimentară, și anume de reprezentare a tuturor acestor elemente cu ajutorul imaginilor.

Codarea progresivă are ca și principiu de bază o împărțire a componentelor care alcătuiesc websiteul în 3 mari categorii, și anume stratul de conținut, stratul de prezentare și stratul care reprezintă funcționalitatea. Pentru dezvoltarea unei aplicații utilizând metoda aceasta, primul pas ar fi reprezentat de realizarea stratului de conținut, după care urmează realizarea stratului de prezentare, iar ca și ultim pas îl reprezintă realizarea stratului de funcționalitate [17].

Figura 10) Straturile componente ale unei aplicații web [30]

Primul pas, și anume cel reprezentat de conținut, reprezintă practic scheletul paginii [9]. Scheletul paginii este practic reprezentat de structura HTML, modul în care a fost scris codul, care poate fi asemantic, realizat folosind standardul HTML4 sau semantic, cod care poate fi realizat utilizând noile elemente prezente în standard HTML5. După realizarea stratului de conținut, urmează realizarea stratului de prezentare, și anume scrierea codului CSS care practic realizează partea vizuală a respectivei aplicații, utilizând atât cod CSS cât și imaginile dorite. Ultimul pas este reprezentat de către realizarea stratului de funcționalitate. Stratul de funcționalitate este reprezentat de codul Javascript scris, care va realiza partea de interacțiune cu utilizatorul, cât și partea de interacțiune cu serverul. Fiecare browser în parte are un mecanism prin care el ignoră fiecare tag HTML care nu este suportat, fiecare proprietate CSS care nu este suportată, fie returnează o eroare prin care anunță browserul că respectiva funcție de cod Javascript nu este suportată, deci nu poate fi interpretată.

3.3.2 Conținutul în prim plan

Conținutul reprezintă practic o problemă de design, cu toate că acest pas se desfășoară cronologic înaintea etapei de design. Realizarea designului fără a se ține cont de conținut reprezintă doar un simplu desen [17].

Se cunoaște faptul că utilizatorii vizitează un anumit website pentru conținutul acestuia. Conținutul poate fi reprezenat prin text, galerii de imagini, rețele de socializare, componente multimedia cum ar fi sunetele sau secvențele video, jocuri sau alte aplicații, etc. Deși nu există o delimitare bine definită între un website și o aplicație web, în fiecare dintre cele două cazuri utilizatorului îi sunt afișate informațiile de conținut. Utilizatorii vizitează un website, sau o aplicație web pentru a ii explora conținutul, de aceea principala țintă a designerului este aceea de a servi într-un mod cât mai eficient clientul, și anume vizitatorul. Tehnologia de design receptiv reprezintă și ea o formă de design, pentru o categorie diferită de dispozitive, și anume dispozitivele mobile cu afișaje mai mici decât cele existente disponibile pentru calculatoarele desktop, fapt care presupune ideea că cel mai important lucru care stă la baza unui website este conținutul. Conținutul potrivit trebuie afișat utilizatorului care vizitează websiteul pentru a îi menține atenția concentrată asupra a ceea ce respectiva aplicație are de oferit [17].

Realizarea designurilor pentru fiecare rezoluție în parte este extrem de dificilă, deoarece nu mai există o rezoluție pentru care ar trebui sa se realizeze designul și implementarea unei pagini web, de aceea este necesar ca la momentul realizării designului unui website, acesta să fie gândit ca o suma de componente, fapt care subliniază proprietatea de modularitate de care trebuie să se țină cont la realizarea unui website [7].

3.4 Fluxul de lucru al unui website receptiv

Designul clasic, cât și designul receptiv, reprezintă o problemă care necesită rezolvarea unui set de constrângeri, iar în cazul în care există anumite constrângeri care sunt încă necunoscute, designerul aplicației este cel care trebuie să rezolve aceste neajunsuri. În cazul designului receptiv, constrângerea principală nu mai este reprezentată de un singur browser, ci constrângerea este reprezentată de conținutul în sine [8].

Multe website-uri sunt realizate pornind de la o interfață cu utilizatorul în locul dezvoltării acestuia în funcție de conținutul de care acesta trebuie să fie reprezentat. Designul receptiv are structura bazată pe conținut, fapt care conferă aplicației care îl afișează posibilitatea unei bune interpretări. Pe scurt, atunci când cerința este reprezentată de realizarea unei interfețe web receptive, pașii sunt reprezentați de realizarea conținutului urmată de schițarea designului, realizarea unui prototip, realizarea unui design vizual, iar abia după realizarea tuturor acestor pași se poate trece practic la implementarea designului receptiv [16].

3.5. Renunțarea la metodologia „Waterfall”

În cadrul proiectelor web clasice se folosea cu preponderență metodologia waterfall, deși alte metodologii „Agile” ar fi putut fi folosite pentru dezvoltarea unor asemenea tipuri de aplicații. Dezvoltarea unei aplicații urmărind un set de pași, cum ar fi schițarea, vizualizarea, revizuirea, reproiectarea, ar fi fost de preferat să folosească o metodologie „Agile” în locul uneia de tip „Waterfall”. Majoritatea proiectelor de design a unei aplicații web au ca și punct de pornire etapa de planificare, care are ca și rezultat producerea unui concept, după care se trece la realizarea unor „wireframe-uri” iar în cele din urmă realizarea unei reprezentări vizuale a interfețelor [19]. Faza de dezvoltare a aplicației nu poate începe până la momentul în care designul grafic nu este finalizat și acceptat de către client. În momentul în care s-a obținut aprobarea clientului referitoare la partea de design, dezvoltatorii pot să înceapă implementarea cerințelor clientului respectiv.

Figura 11) Metodologia waterfall [31]

Implementarea metodologiei „Waterfall” constă în trei pași principali:

1) Planificarea, designul artefactelor, incluzând hărțile site-urilor, „wireframes”, user flowuri, scenarii, toate acestea fiind aprobate de către client;

2) Realizarea designului website-ului folosind Adobe Photoshop sau orice alt program specializat pentru realizarea designurilor web, urmat de aprobarea clientului;

3) Implementarea layoutului realizat folosind cod HTML și CSS, după care se vor realiza implementările de funcționalitate suplimentare, urmate de aprobarea finală a clientului;

Metodologia waterfall nu este optimă pentru realizarea proiectelor de aplicații web, și în special a celor de responsive web design din cauza nivelurilor de dificultate ale acestora. Fiecare pas în parte a acestui proces poate fi executat de către echipe de dezvoltatori și designeri diferite, incluzând posibilitatea dezvoltării acestora de către companii diferite. Fără a înțelege cu exactitate cerințele, cât și a modului în care aplicația web trebuie să reacționeze în interacțiunea sa cu clienții, respectivul proiect poate ajunge într-o fază în care o mare parte din efortul irosit până la acel moment să fie inutil, și se poate ajunge practic la realizarea doar a unei părți a respectivului proiect și anume a interfeței desktop, care la momentul actual este insuficientă pentru o aplicație web accesată la scară globală. La momentul în care clientul aprobă partea de design, în vederea începerii implementării ei, există în continuare posibilitatea modificării anumitor cerințe care au ca și scop realizarea unei interfețe web receptive mai performante. Există posibilitatea ca mai multe companii să realizeze un proiect cerut de un anumit client, dar varianta optimă pentru realizarea acestui lucru este aceea de a avea o companie cu mai multe echipe specializate care să realizeze respectivul proiect în toate fazele lui, deoarece este necesară o foarte bună organizare a pașilor care trebuie urmați pentru atingerea rezultatului dorit.

Realizarea unei aplicații web receptive presupune implicarea uneia sau a mai multor echipe, fiecare având atribuite numai cerințele specifice ei, după care munca fiecărei echipe în parte urmând să fie pusă cap la cap cu munca celorlalte echipe pentru a ajunge la produsul final.

3.6 Cercetarea în domeniu

Primul pas în dezvoltarea unui proiect de web design receptiv este acela de a realiza o cercetare asupra website-urilor existente deja în acest domeniu. Cel de-al doilea pas constă în analizarea publicului țintă, după care urmează cel de-al treilea pas care constă în stabilirea unor obiective care trebuie să fie atinse pentru ca afacerea să aibă parte de succes. Cea mai mare parte de informații legate de utilizatori se vor extrage folosind instrumente de analytics și date statistice. Web analytics este un instrument important care ajută la descoperirea comportamentului unui utilizator pe durata navigării pe website, iar din acestea se pot trage concluzii asupra cărei secțiuni din website nu aduce cele mai bune rezultate. Deasemenea, instrumentele analytics oferă celui care realizează statisticile informații referitoare la browserul folosit pentru navigare, rezoluțiile cele mai folosite de către utilizatorii website-ului, tipul de dispozitiv de pe care acesta este accesat, inclusiv denumirea completă a dispozitivului mobil dacă este cazul, zonei geografice din care s-a accesat aplicația respectivă, cât și multe alte statistici importante în cadrul procesului de dezvoltare și îmbunătățire a unui website. În urma analizării acestor statistici se pot trage concluzii foarte folositoare în vederea dezvoltării ulterioare a website-ului, și anume dacă în continuare trebuie asigurat suport pentru versiuni mai vechi ale browserelor, apariția necesității realizării unei traduceri în vederea asigurării suportului aplicației pentru diferite zone georgrafice și multe altele [15].

Uneori, înainte de a dezvolta o anumită aplicație, există posibilitatea de a nu avea acces la acest tip de statistici, fapt care este un mare dezavantaj deoarece dezvoltarea trebuie realizată intuitiv. Aceasta se poate datora faptului că proprietarul website-ului nu a instalat pentru monitorizare niciun instrument de analytics. În acest tip de cazuri, analiza trebuie realizată direct cu proprietarul website-ului, realizând un set de întrebări necesare pentru a dezvolta cu succes o aplicație web pe același domeniu, și totodată pentru mulțumirea clientului.

Fără realizarea acestei etape de cercetare în domeniu, și fără a avea cunoștințele necesare legate de piața pentru care se desfășoară respectiva afacere, este imposibilă înțelegerea nișei respective, cât și a cerințelor proprietarului. Această etapă este una foarte dificilă deoarece necesită colectarea unui set mare de date pentru a putea obține cele mai bune rezultate.

3.7 Metodologia SCRUM

SCRUM reprezintă o metodă iterativă și incrementală din cadrul metodologiei Agile folosită pentru managementul și dezvoltarea unui produs. Prin intermediul termenului SCRUM se poate defini o strategie de dezvoltare flexibilă a unui produs, unde scopul principal este reprezentat de livrarea unei variante finale a tuturor funcționalităților cerute. În cadrul acestei metodologii nucleul este reprezentat de către o echipă care are ca și scop principal realizarea tuturor cerințelor, ne fiind atât de importante realizările personale cât cele ale întregului grup. Echipele care implementează metodologia SCRUM sunt echipe în cadrul cărora caracteristicile dominante o reprezintă colaborarea, auto-organizarea cât și realizarea zilnică a întâlnirilor cu scop de raportare a stării actuale, impedimentelor și a sarcinilor care urmează să fie realizate în ziua respectivă.

Un principiu important al SCRUM este acela că pe parcursul unui proiect cerințele clienților se pot modifica. Aceste modificări ale cerințelor nu sunt previzibile, deoarece pe durata proiectului clientul poate observa necesitatea unor noi funcționalități, fără de care aplicația respectivă nu poate exista. Din această cauză, o caracteristică importantă a procesului SCRUM este aceea că echipa care participă la realizarea proiectului trebuie să se adapteze și să reacționeze ferm la aceste schimbări pentru a obține cele mai bune rezultate. [20]

3.7.1 Roluri

Există mai multe roluri într-o echipă SCRUM, dintre care doar 3 dintre ele sunt roluri de bază. Rolurile principale mai sunt denumite și „porci” iar rolurile secundare mai sunt denumite și „pui”.

Rolurile principale sunt cele care contribuie la realizarea în sine a produsului finit. Persoanele care realizează rolurile principale reprezintă practic echipa SCRUM. [20]

3.7.2 Product Owner

Product ownerul reprezintă beneficiarul proiectului, și anume este un reprezentant al clientului. Acesta are ca și scop asigurarea faptului că echipa care va realiza proiectul va duce la final cu succes cerințele clientului. Acesta va prelua de la client cerințele proiectului și le transformă într-o serie de features, denumite și „user-story”, după care le prioritizează și le adaugă într-un „backlog” care reprezintă cerințele care trebuie să fie implementate de către echipa de dezvoltatori. Deasemenea, el reprezintă o interfață între stiva de sarcini existente în backlog și dezvoltatori și trebuie să realizeze și următoarele lucruri:

– demonstrează soluția obținută celor care nu au luat parte la o iterație demonstrativă

– anunță lansările

– comunică statusul echipei

– organizează revizuiri la momente prestabilite

– realizează o dezvoltare a părților interesate din cadrul proiectului

– negociază prioritățile și programul adoptat în cadrul dezvoltării produsului

Modul de relaționare a product ownerului cu persoanele implicate în proiect este o caracteristică foarte importantă a acestuia. Motivul pentru care acest lucru este vital este acela că persoana care ocupă această poziție trebuie să comunice cu diverse persoane cu niveluri si domenii de pregatire diferite, el trebuind să aibă capacitatea să vadă problemele din diferite puncte de vedere. Deasemenea, un product owner trebuie să știe nivelul de detalii cu care trebuie să prezinte anumite probleme în funcție de persoanele vizate. Spre exemplu, o echipă de dezvoltatori are nevoie de specificații cât mai precise pentru a dezvolta într-un mod cât mai corect produsul respectiv în timp ce persoana care reprezintă clientul are nevoie doar de rezumate a celor realizate până la acel moment. Dezvăluirea unor informații irelevante pentru persoana în cauză poate duce la irosirea timpului. Comunicarea cu diversele persoane cu diferite nivele de cunoștințe duce practic la necesitatea realizării unor diferite prezentări, și anume în timp ce pentru persoanele din echipa de dezvoltatori este suficientă o prezentare schematică, pentru client mult mai relevantă este prezentarea unei documentații. [20]

Capacitatea unui product owner de a comunica cu persoanele implicate în respectivul proiect este întărită de capacitățile sale de negociere cu privire la prioritățile în cadrul proiectelor și colaborarea acestuia cu echipa de dezvoltatori pentru implementarea cu succes a tuturor cerințelor.

3.7.3 Echipa de dezvoltare

Echipa de dezvoltare este partea responsabilă pentru livrarea funcționalităților produsului la sfârșitul fiecărui sprint. O echipă de dezvoltare este compusă din 3-10 persoane cu cunoștințe multiple, și anume cunoștințe legate de partea de analiză, design, dezvoltare, testare, comunicare tehnică, documentație etc. Echipa de dezvoltare SCRUM este o grupare care se auto-organizează singură sau cu ajutorul unei echipe de manageri de proiect.

3.7.4 Scrum master

Procesul de dezvoltare SCRUM este facilitat de un Scrum Master, al cărui scop principal este acela de a înlătura obstacolele care vor împiedica echipa să atingă cele mai bune performanțe în vederea livrării produsului în cea mai bună formă a acestuia. Scrum masterul nu este un „team leader” sau un manager de proiect, ci el se comportă pracic ca și un amortizor între echipa care lucrează la dezvoltarea produsului și evenimentele care îi pot distrage acesteia atenția. Un alt rol al acestuia este acela de a se asigura de faptul că procesul Scrum se desfășoară în parametri optimi prin impunerea regulilor care trebuie urmate cât și organizarea întâlnirilor în momentele cheie.

În cadrul procesului SCRUM nu este indicată prezența unui manager de proiect deoarece toate atribuțiile acestuia sunt împărțite în cadrul celor 3 roluri SCRUM (Product Owner, Echipa de dezvoltare și Scrum Master), în principal primelor două. Practic, dacă în cadrul unui proces SCRUM ar exista un manager de proiect, atunci ar apărea o confuzie asupra persoanei care conduce proiectul respectiv, cât și rezultate mult mai slabe în realizarea funcționalităților și a timpului de livrare a acestora.

3.7.5 Evenimentele SCRUM

3.7.5.1 Sprintul

Sprintul sau o iterație este unitatea de bază a dezvoltării în SCRUM. Sprintul este o iterație care se desfășoară într-o perioadă de timp determinată în avans pentru fiecare unitate în parte și poate avea o durată între 2 săptămâni și o lună.

Fiecare sprint începe cu o întâlnire de planificare, unde sarcinile sunt identificate și li se realizează o estimare ca durată de timp, și se încheie cu o întâlnire retrospectivă unde progresul este revizuit astfel încât la următorul sprint să nu se repete greșelile făcute în iterația curentă.

3.7.5.2 Metodologia SCRUM

În cadrul SCRUM, sfârșitul unui sprint semnifică un produs finit. În cadrul dezvoltării aplicațiilor software, sfârșitul unui sprint semnifică faptul că funcționalitățile respective sunt integrate, testate, documentate și pregătite pentru livrare.

3.7.5.3 Întâlnirile

3.7.5.3.1 Întâlnirea de planificare a sprintului

Are loc la începutul unui sprint (între 7-30 zile) și constă în următoarele:

– Selectarea sarcinilor care trebuie realizate

– Pregătirea backlogului în care se va detalia timpul necesar pentru realizarea sarcinilor respective, împreună cu echipa

– Identificarea și comunicarea volumului de muncă realizabil până la sfârșitul sprintului

– Limita acestei întâlniri este de 8 ore

– primele 4 ore (cu întreaga echipă) – Prioritizarea backlogului

– ultimele 4 ore (echipa de dezvoltare) – Schițarea planului pentru sprintul curent, rezultând backlogul sprintului

3.7.5.3.2 Întâlnirea zilnică de Scrum

În fiecare zi a sprintului are loc o întâlnire a membrilor echipei. Fiecare întâlnire zilnică trebuie să urmeze anumiți pași:

– Toți membrii echipei de dezvoltare vin pregătiți cu noutățile care vor trebui prezentate

– Întâlnirea începe la o oră prestabilită înainte chiar dacă se observă absența unora dintre membrii echipei

– Întâlnirea trebuie să aibă loc la aceeași oră și în aceeași locație în fiecare zi

– Durata unei asemenea întâlniri trebuie să aibă o durată aproximativă de 15 minute

– Toți membrii echipei trebuie să ia parte la această întâlnire, dar numai anumite persoane delegate vor trebui să prezinte statusul

În timpul unei asemenea întâlniri fiecare membru al echipei trebuie să răspundă la următoarele 3 întrebări:

– Ce ai dezvoltat în cursul zilei de ieri?

– Ce plănuiești să dezvolți astăzi?

– Există anumite blocaje care te impiedică să avansezi?

Răspunsul la ultima întrebare trebuie să fie observat cu atenție de către Scrum Master, iar în cazul în care există anumite lucruri care trebuie îmbunătățite acesta trebuie să le rezolve într-un interval de timp cât mai scurt pentru a facilita o bună funcționare a procesului SCRUM. [20]

3.7.5.3.3 Întâlnirea retrospectivă

La finalul fiecărui sprint se țin două întâlniri: întâlnirea de revizuire a sprintului și retrospectiva sprintului,

La întâlnirea de revizuire a sprintului vor avea loc următoarele:

– Revizuirea sarcinilor care au fost duse la final cu succes și a sarcinilor plănuite dar care nu au fost realizate

– Presentarea rezultatului final părților implicate prin realizarea unui demonstrativă

– Sarcinile care nu au fost duse la final nu vor fi prezentate

– Limita de timp pentru această întâlnire este de 4 ore

La întâlnirea de retrospectivă a sprintului vor avea loc următoarele:

– Toți membrii echipei se vor gândi la cele petrecute în cadrul sprintului curent

– Membrii echipei vor îmbunătăți procesul dacă este cazul

– Membrii echipei trebuie să răspundă la două întrebări: Ce anume a decurs bine în cadrul sprintului? Ce anume poate fi îmbunătățiti în vederea sprinturilor care vor urma?

– Limita de timp pentru această întâlnire este de 3 ore

– Întâlnirea este supravegheată de către Scrum Master

3.7.5.4 Extensii

3.7.5.4.1 Îmbunătățirea backlogului

Îmbunătățirea backlogului este procesul prin care se realizează o revizuire constantă a backlogului și verificarea itemurilor prezente în acesta pentru asigurarea faptului că ordinea corectă a priorităților a fost stabilită. Un alt scop pentru care se realizează acest proces este acela că se vor realiza anumite verificări ale sarcinilor care urmează a fi executate în vederea împărțiri lor, dacă este posibil, în sarcini mai specifice, și totodată, în cazul în care anumite sarcini nu sunt clare, se vor cere explicații suplimentare pentru o mai bună înțelegere a acestora. Acest proces nu este unul de bază în cadrul procesului SCRUM, dar a fost adoptat pentru asigurarea calității sarcinilor prezente ăn backlogul sprinturilor viitoare. [20]

3.7.5.4.2 Scrum de scrumuri

Întâlnirea scrum a scrumurilor este o tehnică de scalare a SCRUM-ului pentru echipe mari de dezvoltare care fac posibilă comunicarea între grupuri mai mari de dezvoltatori pentru a-și discuta progresul și a facilita integrarea funcționalităților. Fiecare întâlnire SCRUM zilnică se încheie cu delegarea unui membru „ambasador” care va trebui să ia parte la o întâlnire cu „ambasadorii” fiecărei echipe în parte. În funcție de contextul întâlnirii, „ambasadorii” pot fi persoane tehnice sau scrum masterul fiecărei echipe.

Întrebările la care trebuie să se răspundă în cadrul unei întâlniri scrum de scrumuri sunt următoarele:

– Ce a realizat echipa ta de la ultima întâlnire?

– La ce va lucra echipa ta până la următoarea întâlnire?

– Există ceva ce încetinește viteza de dezvoltare a sarcinilor în cadrul echipei tale?

Scopul aceste întâlniri este acela ca fiecare echipă să ia la cunoștință progresul celorlalte echipe, cât și realizarea unui transfer de cunoștințe sau a unui transfer de sarcini, iar toate aceste informații vor fi adăugate într-un backlog separat care va avea ca principal scop îmbunătățirea procesului de comunicare și cooperare între echipe. [20]

4. Implementarea soluției adoptate

Pentru implementarea soluției de realizare a unor interfețe web responsive s-au folosit urmatoarele limbaje: pentru stratul de conținut s-a utilizat limbajul HTML, pentru stratul de prezentare s-a utilizat limbajul CSS iar pentru stratul de funcționalitate s-a utilizat limbajul Javascript și libraria acestuia numită jQuery. Limbajul HTML a fost folosit pentru realizarea întregii părți de conținut al aplicației, prin intermediul căruia au fost introduse în pagină elementele de tip text, cele de tip imagine etc. Limbajul CSS a fost folosit pentru realizarea interfeței grafice a aplicației, și anume descrierea modului de afișare al containerelor, textelor și a celorlalte elemente din pagină. Cu ajutorul limbajului CSS au fost setate culorile de fundal, culorile textelor, umbrele existente, elementele transparente, aranjarea acestor elemente în pagină, cât și multe alte caracteristici ale elementelor vizibile în această aplicație. Limbajul Javascript și librăria acestuia jQuery au fost folosite pentru a realiza partea de interacțiune cu clientul aplicației, și anume ce acțiuni trebuie să se realizeze în cazul apăsării unui element, în cazul în care utilizatorul scrollează pagina etc.

Pagina de start

Pagina de start conține următoarele elemente: headerul, care va fi persistent pe tot parcursul aplicației, footerul, care își va păstra deasemenea locul inițial și conținutul care va fi înlocuit în funcție de versiunea aleasă. Navigarea între versiunile diferite de mostre responsive va fi realizată utilizând apelurile AJAX, fapt care ajută considerabil la cresterea performanțelor aplicației, deoarece anumite elemente comune nu necesită o reîncărcare la fiecare schimbare de conținut. Aceste elemente sunt headerul și footerul, care conțin un logo, linkurile către pagini și copyrightul. La apăsarea unui link din header sau footer se va realiza un apel AJAX către un alt fișier HTML, iar din acela se vor insera în pagină conținutul necesar afișării și adresele fișierelor externe incluse în ele cum ar fi fișierele CSS și cele Javascript. În timpul încărcării datelor, a fost setat artificial un timp de 3 secunde pentru a simula încărcarea informațiilor de pe un server web (încarcarea urmatoarei pagini nu va fi realizată instantaneu), iar în decursul a celor 3 secunde va apărea o imagine care să sugereze faptul că în momentul acela se încarcă datele solicitate.

Codul HTML care va realiza stratul de conținut este următorul:

<!DOCTYPE html>

<html>

<head>

<title>Bobaila Radu-Christian – Responsive web design</title>

</head>

<span class="pageTitle">Responsive<br/> Web Design</span>

<ul>

Home

</li>

Article Style

</li>

Metro Style

</li>

</ul>

</nav>

</header>

</main>

Home

</li>

Article Style

</li>

Metro Style

</li>

</ul>

</footer>

<p class="loadingElement">Please wait while <span id="loadingSection"></span> is loading…</p>

</article>

</div>

</body>

</html>

Se poate observa faptul că, în partea de sus a paginii avem antetul paginii, unde avem inclusă o imagine, un text, și meniul principal. În containerul aflat sub antentul paginii se va încărca conținutul pentru cele 2 exemple prezentate în această lucrare. Se poate observa faptul că în această pagină au fost folosite taguri html incluse în standardul HTML5. Un alt lucru important care se poate observa în stratul de conținut este acela că pentru elementele de meniu, au fost definite atributele navPage și desc. Aceste 2 noi atribute sunt folosite mai departe pentru navigarea între pagini, care vor fi descrise la stratul de funcționalitate.

Codul jQuery care realizează stratul de funcționalitate este următorul:

var serverTime = 3;

var fadeTime = 500;

$(document).ready(function() {

$.ajax({

type: "GET",

url:'home/index.html',

dataType: "html",

success: function(response){

$('.responsiveContent').html(response);

$('html').scrollTop();

},

error: function(xhr) {

console.log(xhr);

}

});

$('.mainNavigation li').click(function() {

if ($(this).attr('navPage') !== undefined) {

$('#loadingSection').html($(this).attr('desc'));

$('.loader').fadeIn(fadeTime);

var getContent = $(this).attr('navPage');

setTimeout(function() {

$.ajax({

type: "GET",

url: getContent + '/index.html',

dataType: "html",

success: function(response){

$('.responsiveContent').html(response);

$('body').scrollTop();

$('.loader').fadeOut(fadeTime);

},

error: function(xhr) {

console.log(xhr);

}

});

}, serverTime * 1000);

}

});

La începutul fișierului se poate observa că avem definite 2 variabile, și anume timpul de așteptare pentru încărcarea datelor, care este setat artificial pentru a simula cu succes o încărcare a datelor direct de pe un server. După definirea acestei variabile a fost setată variabila fadeTime care definește timpul de apariție și dispariție a containerului care se suprapune peste restul paginii pentru a anunța utilizatorul că în acel moment se vor încărca datele. În interiorul funcției document.ready() se poate observa faptul că se realizează un apel AJAX, care are ca și țintă fișierul index.html din folderul home. La executarea cu succes a apelului AJAX se observă că în containerul destinație se va introduce conținutul returnat de către fișierul apelat, după care se realizează o scrollare până în partea de sus a paginii. Mai departe, la detectarea evenimentului de click pe unul dintre elementele meniului, se poate observa faptul că, dacă există atributul navPage definit, se va trece la executarea unei bucăți de cod, care, întâi personalizează containerul care notifică utilizatorul în legătură cu pagina care urmează a fi încărcată, alipind conținutul găsit în atributul desc. După aceea, se va executa bucata de cod care va realiza apariția respectivului container, după care, variabila getContent va prelua valoarea atributului navPage, pentru a ști din care fișier să fie adus conținutul către utilizator. După aceea, se va apela din nou o funcție AJAX dinamică, care va aduce în containerul destinat conținutul pentru fiecare pagină în parte.

Codul care realizează stratul de prezentare a acestei pagini este următorul:

html {

min-width: 320px;

}

.clear {

clear: both;

content: "";

}

body.firstPage {

margin: 0;

width: 100% !important;

}

.firstPage .mainHeader {

background-color: #FFF;

border-bottom: 1px solid #CCC;

height: 130px;

margin: 0 auto;

padding-bottom: 20px;

width: 470px;

}

.firstPage .logo {

float: left;

transition: 0.2s ease-in-out all;

}

.firstPage .pageTitle {

font-size: 48px;

font-weight: bold;

position: relative;

top: 35px;

}

.firstPage .pageTitle {

font-size: 36px;

font-weight: bold;

left: 5px;

position: relative;

top: 20px;

}

.firstPage .mainNavigation ul li {

background-color: #555;

color: #fff;

cursor: pointer;

display: inline-block;

font-size: 15px;

font-weight: bzold;

margin-left: 5px;

margin-right: 5px;

margin-top: 10px;

padding: 5px 15px;

transition: all 0.2s ease-in-out 0s;

}

.firstPage .mainNavigation ul li:hover {

background-color: #226699;

padding-left: 35px;

}

.firstPage .mainNavigation ul {

left: 0px;

position: relative;

}

.firstPage .mainFooter {

background-color: #FFF;

border-top: 1px solid #CCC;

height: 45px;

margin: 0 auto;

position: relative;

width: 470px;

}

.firstPage .mainFooter ul {

display: block;

margin: 0 auto;

padding-left: 0;

width: 215px;

}

.firstPage .mainFooter ul li {

color: #555;

cursor: pointer;

display: inline-block;

font-size: 12px;

margin-left: 0;

margin-right: 5px;

margin-top: 10px;

padding: 5px;

transition: all 0.2s ease-in-out 0s;

}

.firstPage .mainFooter ul li:hover {

color: #226699;

}

.firstPage .responsiveContent {

padding: 20px 0 20px;

}

.firstPage .userInfo {

margin: 0 auto 50px;

width: 460px;

}

.firstPage .userPic {

float: left;

margin-right: 15px;

}

.firstPage .userInfo p {

color: #373737;

font-size: 22px;

}

.loader {

background: none repeat scroll 0 0 rgba(255, 255, 255, 0.95);

display: none;

height: 100%;

left: 0;

position: fixed;

top: 0;

width: 100%;

}

.loader article {

height: 200px;

left: 50%;

margin-left: -100px;

margin-top: -100px;

position: absolute;

text-align: center;

top: 50%;

width: 200px;

}

@media screen and (max-width: 480px) {

.firstPage .pageTitle {

font-size: 30px;

top: 15px;

}

.mainNavigation {

clear: both;

}

.firstPage .mainNavigation ul li {

font-size: 13px;

margin-top: 0;

padding: 5px 10px;

}

.firstPage .mainNavigation ul {

margin: 0;

padding-left: 10px;

}

.firstPage .userPic {

float: none;

margin-bottom: 15px;

}

.firstPage .userInfo p {

font-size: 18px;

}

.firstPage .userInfo {

text-align: center;

}

.firstPage .mainHeader {

height: auto;

}

.firstPage .mainHeader, .firstPage .mainFooter {

width: 320px;

}

.firstPage .userInfo {

margin-bottom: 0;

width: 100%;

}

.firstPage .logo {

float: left;

height: 100px;

width: auto;

}

Se poate observa faptul că, în codul CSS realizat au fost utilizate proprietăți CSS3, modul de realizare a unor anumite proprietăți utilizând shorthandul acestora (definirea printr-o metodă mai scurtă și eficientă a proprietăților), și nu în ultimul rând media queries care ajută la adaptarea conținutului pentru toate tipurile de dispozitive. În cazul de față, un singur breakpoint media query a fost folosit, și anume la rezoluția de 480px pentru a realiza adaptarea conținutului.

Pagina web responsive de tip articol

Această pagină are ca și scop reprezentarea unei pagini web de tip articol din ziar. Layoutul după care a fost realizată această pagină este una de grid clasic, având un header, 3 coloane de conținut și un footer. La trecerea la o rezoluție mai mică a aplicației, de fiecare dată, în momentul în care conținutul nu s-ar încadra perfect în ecran, ultima coloană va trece sub precedentele coloane, realizând astfel o adaptare a acestuia pentru o bună vizualizare pe diferitele tipuri de dispozitive. Totodată, la trecerea la aceste reprezentări se realizează și o ajustare din punctul de vedere al dimensiunii fonturilor pentru a menține la eficiență maximă proprietatea de uzabilitate.

Pagina web responsive de tip „metro-style”

Această pagină are ca și scop reprezentarea unei pagini web de tip „metro style”, care de fapt reprezintă interfața metro aparținând sistemului de operare Microsoft Windows 8. Această pagină are o reprezentare mai simplă, și anume este formată dintr-o multitudine de pătrate și dreptunghiuri, fiecare dintre ele reprezentând o zonă de interes, care poate să conțină fie informații referitoare la o anumită temă, fie o legătură către o pagină care va conține informații. Aceste secțiuni sunt și ele așezate în pagină sub forma unor rânduri și coloane, iar la micșorarea rezoluției la care va fi vizualizată pagina, aceste secțiuni vor trece secvențial sub restul secțiunilor existente în pagină.

5. Rezultate experimentale

5.1 Varianta de tip articol

Rezoluție > 960px

Această captură prezintă varianta de tip articol, la o rezoluție cu lățimea mai mare de 960px, fapt prin care se poate analiza această interfață la dimensiunea sa originală. Se pot observa antetul paginii, prezentarea conținutului pe 3 coloane, dintre care primele 2 coloane au un conținut mai restrâns, iar cea de-a treia are conținutul prezentat mai pe larg.

Rezoluție > 768px și < 960px

Această captură reprezintă varianta de tip articol, prezentată la o rezoluție mai mare de 768px. În aceasta, din cauza faptului că în mod normal conținutul ar fi avut o lățime mai mare, și anume de 960px, conținutul nu ar fi putut fi reprezentat corect pe suprafața ecranului și de aceea a fost nevoie de introducerea primului media query pentru a reface structura paginii. Se poate observa că la această rezoluție cea de-a treia coloană va ocupa mai mult spațiu și va fi reprezentată vizual sub primele 2 coloane. În acest moment, reprezentarea paginii este una corectă, ne fiind nevoie de scrollare pe orizontală, fapt care introduce un anumit discomfort în experiența utilizatorului.

Rezoluție > 640px și < 768px

În cazul reprezentării conținutului paginii la o rezoluție mai mare decât 640px și mai mică decât 768 px se poate observa faptul că reprezentarea paginii se va realiza într-un container cu o dimensiune mai mică, fapt care va face conținutul din nou să fie potrivit pentru acest interval de rezoluții, dar va crește dimensiunea paginii pe verticală.

Rezoluție < 480px

În cazul reprezentării paginii la o rezoluție mai mică decât 480 px se poate observa faptul că pagina va folosi o lățime a containerului de conținut de 100%, aceasta fiind în acest moment o interfață web de tip adaptive care va ocupa o suprafață procentuală din lățimea ferestrei, adaptându-și conținutul într-un mod în care experiența utilizatorului în cadrul navigării pe pagină să fie una optimă. Se poate observa faptul că, odată cu trecerea la cel mai mic prag de rezoluție, pagina va fi reprezentată sub forma unei singure coloane, fapt care îi conferă proprietatea de adaptabilitate automată în funcție de fereastra mamă.

5.2 Varianta de tip metro

Rezoluție > 960px

Această captură prezintă varianta de tip metro, la o rezoluție cu lățimea mai mare de 960px, fapt prin care se poate analiza această interfață la dimensiunea sa originală. Se pot observa elementele de conținut, și anume titlul paginii în partea din stânga sus, iar în partea din dreapta sus se poate observa o iconiță cu numele userului care vizitează pagina, aceasta putând ulterior să capete o funcționalitate. Sub partea de antet a paginii, se pot observa o serie de elemente care pot avea funcționalități și roluri diferite, unele putând avea casete de conținut, altele numai să realizeze legaturile cu alte pagini.

Rezoluție > 768px și < 960px

Această captură reprezintă varianta de tip metro, prezentată la o rezoluție mai mare de 768px. În aceasta, din cauza faptului că în mod normal conținutul ar fi avut o lățime mai mare, și anume de 960px, conținutul nu ar fi putut fi reprezentat corect pe suprafața ecranului și de aceea a fost nevoie de introducerea primului media query pentru a reface structura paginii. Se poate observa că la această rezoluție elementele din dreapta paginii, pentru o bună reprezentare au trecut sub restul elementelor, acum vizual apărând o reprezentare sub forma a două coloane.

Rezoluție > 640px și < 768px

În cazul reprezentării conținutului paginii la o rezoluție mai mare decât 640px și mai mică decât 768 px se poate observa faptul că reprezentarea paginii se va realiza într-un container cu o dimensiune mai mică, fapt care va face conținutul din nou să fie potrivit pentru acest interval de rezoluții, dar va crește dimensiunea paginii pe verticală. Un alt fapt care se poate observa este acela că, la această rezoluție conținutul paginii este mai compact și vom avea cel mult 2 elemente într-o coloană.

Rezoluție < 480px

În cazul reprezentării paginii la o rezoluție mai mică decât 480 px se poate observa faptul că pagina va folosi o lățime a containerului de conținut de mult mai mică, elementele fiind afișate unul sub celălalt, pagina având acum o reprezentare a tuturor acestor elemente pe verticală. Din acest moment va exista o singură coloană cu o lățime fixată din care se va putea alege elementul dorit fie pentru navigare mai departe, fie pentru extragerea unor informații dorite.

6. Concluzii

Aplicațiile desktop există deja de o lungă perioadă de timp, realizând funcționalități foarte complexe și rezolvând în același timp toate problemele prezentate de diverși clienți. Un mare dezavantaj al aplicațiilor desktop în reprezintă mobilitatea, ceea ce odată cu trecerea timpului a devenit o problemă majoră.

În rezolvarea acestei probleme s-au realizat primele aplicații web, care doreau să realizeze practic aceleași funcții ca și aplicațiile desktop. Această nouă soluție acoperă o mare parte din problemele descoperite la aplicațiile desktop, dar încă au mai fost aduse îmbunătățiri la această metodă deoarece doar mobilitatea nu a reprezentat o soluție de termen lung.

Pe lângă faptul că cerințele au devenit din ce în ce mai exigente, și problema mobilității a fost rezolvată, s-a dorit nu în ultimul rând realizarea unor aplicații estetice din punctul de vedere al utilizării lor pe diverse tipuri de dispozitive, cum ar fi noile smartphone-uri, tabletelor, sau a oricărui dispozitiv care dispune de un browser instalat.

Metoda prin care o aplicație web are proprietatea de a se adapta pe orice dispozitiv se numește responsive web design. Există două metode prin care acest lucru poate fi dus la bun sfârșit, și anume realizarea lui prin intermediul CSS3, metoda care nu este suportată de browserele de internet mai vechi, dar practic realizează toate funcțiile necesare pentru noile dispozitive pentru care a fost adus în discuție acest termen. Cea de-a doua metodă, care însă este compatibilă cu orice tip de browser web, o reprezintă implementarea prin intermediul Javascript, dar care însă nu este atât de elegantă și utilizată ca și cea care utilizează CSS3.

Având la dispoziție toate aceste tehnologii noi dezvoltate, se pot realiza aplicații care pot să rezolve orice problemă cerută de către un client, și în același timp pot să fie utilizate pe toată gama de dispozitive existente în momentul de față.

7. Referințe bibliografice

[1] Bos, B., Çelik, T., Hickson, I., & Wium Lie, H. (2011). Cascading Style Sheets Level

2 Revision 1 (CSS 2.1) Specification (No. 20110607). W3C. http://www.w3.org/TR/2011/REC-CSS2-20110607/

[2] Chen, Y., Ma, W.-Y., & Zhang, H.-J. (2003). Detecting web page structure for

adaptive viewing on small form factor devices. Presented at the WWW '03: Proceedings of the 12th international conference on World Wide Web, New York, New York, USA: ACM.

[3] Gardner, B. S. (2011). Responsive Web Design: Enriching the User Experience.

Connectivity and the User Experience, 13.

[4] Nichols, J., & Lau, T. (2008). Mobilization by demonstration: using traces to reauthor

existing web sites. Presented at the IUI '08: Proceedings of the 13th international conference on Intelligent user interfaces, New York, New York, USA: ACM Request Permissions

[5] Ahrens, T. (2012, April 24). A Closer Look At Font Rendering. Smashing Magazine.

http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-fontrendering/

[6] Alexander, S. (2013, July 8). Choosing a responsive image solution. Smashing

Magazine. http://mobile.smashingmagazine.com/2013/07/08/choosing-aresponsive-image-solution/

[7] Boulton, M. (2011, March 24). A Richer Canvas. The Personal Disquiet of Mark

Bolton. Retrieved December 8, 2013, http://www.markboulton.co.uk/journal/a-richer-canvas

[8] Brown, M. (2013, June 7). Reasons Why to Invest in Responsive Web Design.

http://www.zaginteractive.com/about/blog/blog-post/the-zdrive/2013/06/07/8-reasons-why-to-invest-in-responsive-web-design

[9] Gustafson, A. (2008). Understanding Progressive Enhancement. A List Apart,

(269). http://alistapart.com/article/understandingprogressiveenhancement

[10] Joly, K. (2013). To Go or Not to Go Responsive. University Business, (May

2013). http://www.universitybusiness.com/internettech

[11] Knight, K. (2014, August 29). Fixed vs. Fluid vs. Elastic Layout. Smashing Magazine

http://www.smashingmagazine.com/2009/06/02/fixed-vs-fluid-vs-elastic-layout-whats-the-right-one-for-you/

[12] Schilit, B. N., Trevor, J., Hilbert, D. M., & Koh, T. K. (2001). mlinks: An infrastructure for very small internet devices

[13] Wroblewski, L. (2011). Mobile first, (2014, August 29), http://static.lukew.com/MobileFirst_LukeW.pdf

[14] The New Multiscreen World. (2012), (2014, August 29), http://www.ipsos.fr/sites/default/files/attachments/multiscreenworld_final2.pdf

[15] Leibtag, A. (2014, August 29). Is a Mobile First Mentality Right for Your Organization EContent. http://www.econtentmag.com/Articles/Column/Content-Ahas!/Is-a-Mobile-First-Mentality-Right-for-Your-Organization-85363.htm

[16] Hay, S. (2013). Responsive Design Workflow, (2014, August 29), http://ptgmedia.pearsoncmg.com/images/9780321887863/samplepages/0321887867.pdf

[17] Zeldman, J. (2014, August 29) .Content First by Jeffrey Zeldman http://vimeo.com/70977623

[18] Monteiro, M. (2012). Design is a Job, (2014, August 29), http://denisbettiographics.files.wordpress.com/2013/04/design-is-a-job.pdf

[19] Salminen, V. (2014, August 29). Responsive Workflow. http://viljamis.com/blog/2012/responsive-workflow/

[20] (2014, August 29) http://www.pentalog.com/approach/agile-scrum-methodology.htm

[21] (2014, August 29) http://eyelearn.org/ma-stu-gallery/gridEssay-2013/chivonne/pictures/webGridSystem.png

[22] (2014, August 29) http://johnpolacek.github.io/scrolldeck.js/decks/responsive/img/responsive_web_design.png

[23] (2014, August 29) http://www.e-blueprint.co.uk/wp-content/uploads/WebDevices.png

[24] (2014, August 29) http://www.kauferdmc.com/wp-content/uploads/2013/10/Mobile-Web-Usage-Growth.png

[25] (2014, August 29) http://dragojevich.com/wp-content/uploads/2013/06/mobile-first.png

[26] (2014, August 29) http://students.mimuw.edu.pl/SR/prace-mgr/jawaharlal/Thesis_files/image010.gif

[27] (2014, August 29) http://cdn.paessler.com/media/scales/lightbox/common/files/blog/cdn3.png

[28] (2014, August 29) http://media02.hongkiat.com/css3-code-slim/minify-css.jpg

[29] (2014, August 29) http://www.webperformancetoday.com/wp-content/uploads/2010/07/mobile-web-market-share-vs-usage.jpg

[30] (2014, August 29) http://99points.info/wp-content/uploads/2010/03/css_html_javascript.jpg

[31] (2014, August 29) http://www.livingprinciples.org/wp-content/plugins/uploads/OriginalWaterfallDiagram.jpg

8. Anexe

Varianta responsive pentru tipul articol

Codul HTML

<!DOCTYPE html>

<html>

<head>

<title>Article Style</title>

</head>

<body>

<ul>

<li>

</li>

<li>

</li>

<li>

</li>

<li>

</li>

<li>

</li>

<li>

</li>

</ul>

</div>

</nav>

<h1>

<span class="t1">Article</span>

<span class="t2">Style</span>

</a>

</h1>

<h2>Lorem Ipsum is simply dummy text…</h2>

</div>

</header>

<h3>Lorem ipsum is</h3>

<span class="smallCaps">Lorem ipsum dolor.</span>

<ul>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

</ul>

</article>

<h3>Lorem ipsum is</h3>

<span class="smallCaps">Lorem ipsum dolor.</span>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

</article>

<h3>Lorem ipsum is</h3>

<span class="smallCaps">Lorem ipsum dolor.</span>

<ul>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

<li>

<a href="javascript:;">Lorem ipsum dolor sit amet metus. </a>

</li>

</ul>

</article>

<h3>Lorem ipsum is</h3>

<span class="smallCaps">Lorem ipsum dolor.</span>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

</article>

</aside>

<h3>Lorem ipsum is</h3>

<span class="smallCaps">Lorem ipsum dolor.</span>

<ul>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

<li>

<a href="javascript:;">Lorem ipsum.</a>

</li>

</ul>

</article>

<h3>Lorem ipsum is</h3>

<span class="smallCaps">Lorem ipsum dolor.</span>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

</article>

<h3>Lorem ipsum is</h3>

<span class="smallCaps">Lorem ipsum dolor.</span>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

</article>

<h3>Lorem ipsum is</h3>

<span class="smallCaps">Lorem ipsum dolor.</span>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

</article>

<h3>Lorem ipsum is</h3>

<span class="smallCaps">Lorem ipsum dolor.</span>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

</article>

</aside>

<article class="content"> <h1>Lorem ipsum dolor</h1>

<h2>sit amet, consectetur posuere. </h2>

<span class="number">.01 |</span> <a href="javascript:;" class="headlineUrl">Lorem ipsum dolor sit amet</a>

<span class="smallCaps">Lorem ipsum dolor sit amet</span>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet doloremagna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</p>

<q>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod</q>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

<div class="commentBox"><a href="javascript:;">Comments (9)</a></div>

</article>

<article class="content"> <h1>Lorem ipsum dolor</h1>

<h2>sit amet, consectetur posuere. </h2>

<span class="number">.02 |</span> <a href="javascript:;" class="headlineUrl">Lorem ipsum dolor sit amet</a>

<span class="smallCaps">Lorem ipsum dolor sit amet</span>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet doloremagna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</p>

<q>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod</q>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi egestas eros ut magna interdum consequat. Pellentesque ut nisi sit amet eros condimentum sagittis sit amet eget lacus. Nulla varius massa quis scelerisque imperdiet. Sed et lorem nulla. Integer blandit amet. </p>

<div class="commentBox"><a href="javascript:;">Comments (7)</a></div>

</article>

</content>

<p>

<a href="javascript:;">link 1</a> |

<a href="javascript:;">link 2</a> |

<a href="javascript:;">link 3</a> |

<a href="javascript:;">link 4</a> |

<a href="javascript:;">link 5</a> |

<a href="javascript:;">link 6</a> |

<a href="javascript:;">link 7</a> |

<a href="javascript:;">link 8</a> |

</p>

</footer>

</main>

</body>

</html>

Codul CSS

/*Start main styles*/

* {

margin:0; padding:0;

}

body {

background: url(../images/crossword.png) repeat;

color:#555;

font:0.69em Arial,Verdana, sans-serif;

line-height:1.64em;

margin:0;

padding:0;

}

a {

background:inherit;

color: #222;

text-decoration:none;

}

a:hover {

background:none;

border-bottom:1px dashed;

color:#e74c3c;

text-decoration:none;

}

.clearfix:after, .clearfix:before {

clear: both;

content: ".";

display: block;

height: 0;

line-height: 0;

visibility: hidden;

}

.clearfix {

display: inline-block;

}

p {

padding:5px 0 5px 0;

}

ul {

list-style:none;

margin:0;

padding:0;

}

img {

border:0;

}

.clear{

clear:both;

margin-top:1px;

}

main {

background:#e2e2e2;

box-sizing: border-box;

display: block;

margin:0px auto;

padding:0 20px 0 20px;

width:960px;

}

/*End main styles*/

/*Top*/

.topnav {

background:#333;

height:42px;

width:100%;

}

.menu {

float:right;

height:23px;

margin:8px 8px 0 0;

}

.menu a {

background:inherit;

color:#999;

display:block;

font-weight:bold;

line-height:23px;

margin-right:4px;

text-decoration:none;

}

.menu a:hover {

background:inherit;

color:#e74c3c;

}

.menu ul {

list-style:none;

margin:0;

padding:0;

}

.menu li {

float:left;

margin: 0 0 0 5px;

}

/*Start header*/

header {

background: url(../images/header.jpg) no-repeat;

background-size: 100%;

clear:both;

height:180px;

padding:0;

margin:0 0 10px 0;

}

.title {

float:left;

margin:0 0 0 180px;

padding:50px 0 10px 0;

width:340px;

}

.header h1 {

font-size:3.9em;

margin:0 0 4px 20px;

}

.header h2 {

color:#868686;

font:0.9em Arial, Sans-Serif;

letter-spacing:0;

margin:15px 0 0 20px;

padding:0;

}

.t1 {

color:#e74c3c;

font-family:'Impact';

}

.t2 {

color:#333;

font-family:'Impact';

}

/*End header*/

/*Start left col*/

.left {

background:inherit;

float:left;

margin-right:20px;

padding:0 5px 5px 5px;

width:195px;

}

.left ul {

padding:3px 0 12px 5px;

}

.left li {

background:inherit;

color:#e74c3c;

line-height:18px;

list-style:disc;

margin-left:16px;

}

.left li a {

background:inherit;

text-decoration:none;

}

.left li a:hover {

text-decoration:none;

}

/*End left col*/

/*Start aside links – left*/

.linkbar {

background:inherit;

float:left;

margin-right:20px;

padding:0 5px 5px 5px;

width:195px;

}

.linkbar ul {

padding:3px 0 12px 5px;

}

.linkbar li {

background:inherit;

color:#e74c3c;

line-height:18px;

list-style:disc;

margin-left:8px;

}

.linkbar a {

background:inherit;

text-decoration:none;

}

.linkbar a:hover {

text-decoration:none;

}

/*End aside links – left*/

/*Start aside links – right*/

.right {

background:inherit;

float:right;

padding:0;

margin-bottom:10px;

width:465px;

}

.content {

padding: 10px 0 0 0;

}

.right img {

float:left;

padding:0 10px 5px 0;

}

.commentBox {

background: none repeat scroll 0 0 #333333;

clear: both;

height: 23px;

margin: 10px 0;

padding: 7px 12px 0 0;

text-align: right;

}

.commentBox a {

background:transparent;

color:#e74c3c;

font:bold 1.2em Arial, Sans-Serif;

}

/*End aside links – right*/

/*Start article – headline*/

h1 {

font-size:3.50em;

line-height:.8em;

color:#333;

font-family:'Impact';

}

h2 {

border-bottom:4px solid #e74c3c;

color:#333;

display: inline-block;

font-family:'Impact';

font-size:3.50em;

line-height:1.1em;

}

h3 {

border-bottom:#e74c3c 2px solid;

color:#333;

display: inline-block;

font-size:1.3em;

font-weight:bold;

text-transform:uppercase;

}

.number {

color:#e74c3c;

float:left;

font-family:'Impact';

font-size:4.0em;

line-height:1em;

margin-right:8px;

}

.headlineUrl {

color:#999;

font-size:1.48em;

font-weight:bold;

line-height:1.5em;

padding-bottom:3px;

text-decoration:none;

text-transform:uppercase;

}

.smallCaps {

color:#333;

display: block;

font-size:.7em;

letter-spacing:6px;

padding-top:1px;

text-transform:uppercase;

}

/*End article – headline*/

/*Start bloquote*/

q {

background:none;

border:1px double #CCC;

border-width:2px 0;

color:#333;

display:block;

float:left;

font:italic 1.6em/1.7em Georgia;

margin:0.75em 0.75em 0 0;

padding:0.3em;

text-align:left;

width:14em;

}

/*End bloquote*/

/*Start footer*/

.footer {

background:inherit;

border-top:1px solid #333;

clear:both;

margin:0;

padding:10px 0 5px 0;

width:900px;

}

/*End footer*/

/*Start responsive*/

@media screen and (max-width: 960px) {

main {

width: 740px;

}

.linkbar, .left {

margin-bottom: 15px;

width: 315px;

}

h3 {

display: block;

}

.right {

border-top: 2px solid #e74c3c;

clear: both;

display: block;

float: none;

padding: 10px 0 0;

width: 100%;

}

.commentBox {

background-position: left top;

padding: 7px 0 0 35px;

text-align: left;

}

.footer {

box-sizing: border-box;

width: 720px;

}

.title {

margin-left: 145px;

padding-top: 20px;

}

@media screen and (max-width: 768px) {

main {

width: 620px;

}

.footer {

width: 600px;

}

.title {

margin: 0 0 0 120px;

padding: 15px 0 10px;

width: 340px;

}

.header h2 {

margin-top: 5px;

}

.linkbar, .left {

width: 255px;

}

@media screen and (max-width: 640px) {

main {

width: 460px;

}

.footer {

width: 440px;

}

.linkbar, .left {

margin-right: 0;

width: 100%;

}

header {

height: 90px;

}

.linkbar li, .left li {

display: inline-block;

margin-left: 0;

width: 195px;

}

.linkbar article, .left article {

margin-bottom: 20px;

}

.title {

margin-left: 80px;

padding-top: 10px;

width: 300px;

}

h2 {

font-size: 1.5em;

font-weight: 300;

}

@media screen and (max-width: 480px) {

main {

min-width: 320px;

width: 100%;

}

header {

background: none;

height: 75px;

}

.footer {

text-align: center;

width: 100%;

}

.title {

margin: 0;

width: 100%;

}

.header h1, .header h2 {

margin-left: 0;

}

.menu a {

font-size: 10px;

}

.commentBox {

padding-left: 0;

text-align: center;

}

/*End responsive*/

Varianta responsive pentru tipul metro

Codul HTML

<!DOCTYPE html>

<html>

<head>

<title>Metro Style</title>

</head>

<body>

<h1>Metro Style</h1>

Hello Christian,

</span>

</header>

<h3>Welcome</h3>

<p>Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic…</p>

</article>

</figure>

<h2>About</h2>

</figure>

<h2>Contact</h2>

</figure>

</content>

<h3>Article 1</h3>

<p>Lorem Ipsum is simply dummy text of the printing and typesetting industry…</p>

</article>

<h2>Article 1</h2>

</figure>

<h3>Article 2</h3>

<p>Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard…</p>

</article>

<h2>Article 2</h2>

</figure>

<h3>Article 3</h3>

<p>Lorem Ipsum is simply dummy…</p>

</article>

<h2>Article 3</h2>

</figure>

<h3>Article 4</h3>

<p>Lorem Ipsum is simply dummy…</p>

</article>

<h2>Article 4</h2>

</figure>

<h2>Weather</h2>

</figure>

<h2>Currency</h2>

</figure>

</content>

<h2>Facebook</h2>

</figure>

<h2>Twitter</h2>

</figure>

<h3>Article 5</h3>

<p>Lorem Ipsum is simply dummy…</p>

</article>

<h2>Article 5</h2>

</figure>

<h3>Article 6</h3>

<p>Lorem Ipsum is simply dummy…</p>

</article>

<h2>Article 6</h2>

</figure>

<h3>Article 7</h3>

<p>Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard…</p>

</article>

<h2>Article 7</h2>

</figure>

<h3>Article 8</h3>

<p>Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard…</p>

</article>

<h2>Article 8</h2>

</figure>

</content>

</main>

</body>

</html>

Codul CSS

/*General styles*/

body {

background: url('../images/rsz_bg.jpg') center center scroll no-repeat;

background-size: cover;

height: 100%;

margin: 0 auto;

width: 1060px;

}

main {

text-align: center;

}

.clearfix:after {

content: ".";

display: block;

clear: both;

visibility: hidden;

line-height: 0;

height: 0;

}

.clearfix {

display: inline-block;

}

.col {

display: inline-block;

margin: 20px;

vertical-align: top;

width: 310px;

}

header {

position: relative;

}

header .user {

background-color: rgba(255, 255, 255, 0.8);

border-radius: 20px;

box-shadow: 1px 2px 1px rgba(0, 0, 0, 0.5);

box-sizing: border-box;

cursor: pointer;

display: inline-block;

font-weight: 700;

height: 50px;

padding: 10px;

position: absolute;

right: 20px;

text-align: center;

top: 0;

width: 190px;

}

header .user:hover {

box-shadow: 1px 1px 1px rgba(0, 0, 0, 0.5);

top: 1px;

}

header .user img {

margin-left: 5px;

position: relative;

top: 5px;

}

header h1 {

color: rgba(255, 255, 255, 0.95);

margin: 60px 0 30px;

padding-left: 25px;

text-shadow: 1px 1px 0 rgba(0, 0, 0, 0.6), 1px 1px 0 rgba(255, 0, 0, 0.8);

}

figure {

background-attachment: scroll;

background-position: center;

background-size: auto;

border: 1px solid rgba(255,255,255,0.3);

box-shadow: 1px 1px 2px rgba(0,0,0,0.4);

box-sizing: border-box;

cursor: pointer;

float: left;

margin: 5px auto 5px 5px;

padding: 5px 5px 30px;

position: relative;

transition: all 0.2s ease-in-out 0s;

}

figure i {

color: rgba(255, 255, 255, 0.8);

padding-top: 50%;

text-shadow: 1px 1px 5px rgba(0, 0, 0, 0.5);

transition: 0.2s ease-in-out all;

}

figure:hover i {

padding-top: 55%;

}

figure article {

box-sizing: border-box;

overflow: hidden;

padding: 10px;

text-align: justify;

}

figure article p {

color: #FFF;

margin-top: 10px;

text-shadow: 1px 1px 0 rgba(0,0,0,0.5);

transition: 0.2s ease-in-out all;

}

figure:hover article{

background: none repeat scroll 0 0 rgba(0, 0, 0, 0.1);

}

figure article h3 {

background: none repeat scroll 0 0 rgba(255, 255, 255, 0.1);

box-shadow: 1px 1px 1px 0 rgba(0, 0, 0, 0.3), 1px 1px 0 rgba(255, 255, 255, 0.4) inset;

color: #fff;

margin: 0;

padding: 10px;

text-shadow: 1px 1px 0 rgba(0, 0, 0, 0.35);

}

figure h2 {

background: none repeat scroll 0 0 rgba(0, 0, 0, 0.15);

bottom: 0;

box-sizing: border-box;

color: rgba(255, 255, 255, 0.9);

font-size: 16px;

height: 30px;

left: 0;

line-height: 1.3em;

margin: 0;

padding: 5px 0 0 20px;

position: absolute;

text-align: left;

text-shadow: 1px 1px 0 rgba(0, 0, 0, 0.4);

transition: all 0.2s ease-in-out 0s;

width: 100%;

}

figure:hover h2 {

background: none repeat scroll 0 0 rgba(255, 255, 255, 0.5);

color: rgba(0,0,0,1);

padding-left: 30px;

text-shadow: 1px 1px 0 rgba(255, 255, 255, 0.7);

}

/*Background colors*/

.blueBg {

background-color: rgba(52,152,219,0.8);

}

.blueBg:hover {

background-color: rgba(52,152,219,1);

}

.greenBg {

background-color: rgba(46,204,113,0.8);

}

.greenBg:hover {

background-color: rgba(46,204,113,1);

}

.greyBg {

background-color: rgba(149,165,166,0.8);

}

.greyBg:hover {

background-color: rgba(149,165,166,1);

}

.orangeBg {

background-color: rgba(230,126,34,0.8);

}

.orangeBg:hover {

background-color: rgba(230,126,34,1);

}

.redBg {

background-color: rgba(231,76,60,0.8);

}

.redBg:hover {

background-color: rgba(231,76,60,1);

}

.silverBg {

background-color: rgba(189,195,199,0.8);

}

.silverBg:hover {

background-color: rgba(189,195,199,1);

}

.turquoiseBg {

background-color: rgba(26,188,156,0.8);

}

.turquoiseBg:hover {

background-color: rgba(26,188,156,1);

}

.violetBg {

background-color: rgba(155,89,182,0.8);

}

.violetBg:hover {

background-color: rgba(155,89,182,1);

}

.yellowBg {

background-color: rgba(241,196,15,0.8);

}

.yellowBg:hover {

background-color: rgba(241,196,15,1);

}

/*Box layout*/

.sqBig {

height: 300px;

width: 305px;

}

.rctVertBig {

height: 300px;

width: 150px;

}

.sqMed {

height: 145px;

width: 150px;

}

.rctHorBig {

height: 150px;

width: 305px;

}

.rctHorSmall {

height: 75px;

width: 300px;

}

.sqSmall {

height: 75px;

width: 75px;

}

.rctVertSmall {

height: 150px;

width: 75px;

}

/*Article content*/

figure.sqBig article {

height: 257px;

}

figure.rctHorBig article {

height: 107px;

}

figure.rctVertBig article {

height: 257px;

}

figure.sqMed article {

height: 103px;

}

/*Icons*/

.rctVertBig i {

font-size: 100px;

}

.sqMed i {

font-size: 80px;

padding-top: 7%;

}

figure.sqMed:hover i {

padding-top: 10%;

}

@media screen and (max-width: 1060px) {

body {

width: 710px;

}

.col:last-of-type {

margin-top: -20px;

width: 670px;

}

.col:last-of-type figure:nth-of-type(2) {

margin: 5px 48px 5px 5px;

}

@media screen and (max-width: 710px) {

body {

width: 480px;

}

.col,.col:last-of-type {

width: auto;

}

.sqBig {

height: 255px;

width: 430px;

}

figure.sqBig article {

height: 212px;

}

.rctVertBig {

height: 190px;

width: 212px;

}

figure i {

padding-top: 10%;

}

figure:hover i {

padding-top: 15%;

}

.col:nth-of-type(2) {

margin-top: -20px;

}

.rctHorBig {

width: 430px;

}

.sqMed {

width: 213px;

}

.col:nth-of-type(2) .rctVertBig {

height: 300px;

}

figure.rctVertBig article {

height: 145px;

}

.col:last-of-type figure:nth-of-type(2) {

margin-right: 0;

}

@media screen and (max-width: 480px) {

body {

width: 310px;

}

html {

min-width: 320px;

}

.col,.col:last-of-type {

width: auto;

}

header {

text-align: center;

}

header h1 {

padding-left: 0;

}

header .user {

position: static;

}

.sqBig, .rctVertBig, .rctHorBig,.sqMed {

width: 260px;

}

.col:nth-of-type(2) .rctVertBig {

height: 190px;

}

figure.rctHorBig article {

height: 105px;

}

figure.sqBig article {

height: 205px;

}

header h1 {

margin: 20px 0 10px;

}

Referințe bibliografice