Cum tratati problema, ce alegeti?
Eu unul, am mici temeri fata de ideea de mobile responsive. Mi se pare ca ai multe constrangeri in proiectarea paginilor, atunci cand te gandesti ca trebuie sa arate OK si pentru mobil.
1 Like
Eu până acum cred că am avut ghinion la clienții ce mi-au cerut site-uri responsive:
- mulți nu-mi dau un layout (sau măcar un mockup, orice!) pentru varianta mobilă;
- și mai mulți înțeleg prin responsive, de fapt, iphone 5;
- toți designerii cu care am lucrat și mi-au dat totuși un layout responsive, mi l-au dat pentu rezoluția 640x960 (când, de fapt, rezoluția reală este 320x480); nu pare o problemă prea mare decât atunci când clientul vrea să apară X elemente într-o pagină dar de fapt nu încap (da, știu că pot forța viewport la 2x, dar pierdem din vedere sensul responsive)
- am avut clienți care prin responsive înțelegeau conținut diferit pentru mobil vs desktop. În aceeași pagină;
- am avut parte de designeri ce au considerat că e ok să pună elemente poziționate fix pe mobil. Ceea ce nu-i o problemă prea mare dacă acele elemente nu acopereau un sfert din viewport.
Responsive este o chestie ce se aplică cu succes site-urilor de conținut (blog-uri, știri) și mai puțin site-urilor de prezentare sau aplicațiilor web. Chiar și în cazul site-urilor de conținut designul trebuie gândit în așa fel încât să suporte rearanjare.
De cele mai multe ori recomand clienților să facă un site mobil separat.
De cele mai multe ori sunt ignorat, că deh, ăsta e trendul. Și cu siguranță EL, clientul, știe mai bine decât mine 
Ca multe alte tehnologii și practici noi, responsive este un termen reinventat. Prin '99, când am început eu sa învăț HTML se preciza în fiecare articol sau carte citită că site-urile trebuiesc testate pe cât mai multe rezoluții și browsere și că trebuie să arate bine la fiecare din ele.
Eu sunt 100% pentru responsive (vorbim de site-uri, nu de web apps).
Dacă faci html/css bine gândit (nu făcut doar să mergă) nu văd de ce ai avea probleme cu responsive.
Eu de obicei primesc doar versiunea desktop, cum se comportă la rezolutii mici în 90% din cazuri e common sense (depinde și de client, ce și cât vrea să înțeleagă)
ăla nu mai e responsive… e altceva
Și de ce nu la site-uri de prezentare? Părerea mea e că ăla e cazul ideal. La alea de continut cred că e mai greu, că trebuie să înțeleagă și cei care produc conținutul care e treaba cu responsive.
Responsive design unde design este chiar luat in serios (PSD-ul in sine contine variantele pt. major breakpoints)
1 Like
@dan este common sense, dar din punctul tău de vedere. Clientul are alte așteptări aproape de fiecare dată 
De ce nu la site-uri de prezentare? Trendul actual este să se folosească parallax. Cât mai mult parallax. Cât mai mult JS. Cât mai multe imagini. I-am zis unui client că poate totuși nu e o idee bună ca un site de mobil să cântărească 2Mb (iar desktop 7mb+) mi-a zis foarte serios că imaginile vor fi servite de pe CDN.
Pentru că știm cu toții, CDN-ul e o chestie magică ce face transferul de fișiere instantaneu
Oh, dar erau optimizate imaginile!
Varianta de optimizare ce mi s-a sugerat includea imagini la fel de mari ca cele de pe desktop! 
Pentru că da, este o idee foarte bună să pui imagini de 1200x800 pe mobil
Sa inteleg ca nu apar constrangeri de proiectere a UX-ului? Gandeste-te la un site ca http://edition.cnn.com/ . Daca ai primi o astfel de macheta, pur si simplu te-ai apuca sa il faci si pe 320px?
Zi mersi ca nu ti l-au dat in pt sau cm, 300dpi, si apoi ti-ai zis sa maresti butonul cu un centrimetru!
Mi-ai adus aminte de un client ce îmi trimitea layout-urile în format freehand care, după ce am terminat un proiect, îmi zice: „știi, site-ul parcă este prea mare”; după o zi: „a greșit designerul și l-a salvat greșit!”. Atunci eram la început, nu știam eu de SASS & co; a trebuit să reiau și să măsor o grămadă de chestii… Eheeee…
Ok, am exagerat cu 100%
în exemplul dat de tine clar e nevoie de variantă specială de mobile, pentru că e cantitate și densitate prea mare de informație pentru in ecran de 4"-5", plus că informația afișată nu e aceeași și nu e la fel organizată.
Deși sunt și exemple de site-uri știri/media (e drept mai mici) full responsive, de exemplu Japan Times, deci se poate.
1 Like
Sunt total contra la o aplicatie complexa.
La fel ca @iamntz, la mine intotdeauna a fost: responsive = haos.
De ce? Clientii doreau foarte multe animatii, progress bar-ul sa se invarta asa, loading-ul ala sa se incarce asa, pozele alea sa se salveze in sesiune asa iar la finalul zilei aveai foate mult Javascript si css, plin de animatii.
Nu ar fi rau daca responsive nu ar insemna si un smartphone chinezesc cu browser varianta 1998 pe care acel javascript si css nu functionau la fel ca pe PC, sau chiar incetineau prea mult functionarea.
Daca te si folosesti de un framework front-end care e gandit mobile-first ( foundation ) se simplifica un pic abordarea responsive.
Dupa destul de multe experiente negative cu implementarea de responsive design, dintre care pot sa enumar diferiti clienti care doreau responsive design fara sa ofere un layout, clienti care voiau ca toate elementele din versiunea desktop sa apara in 320-480px, doar ca mai mici putin si pana la propriile piedici de care m-am lovit atunci cand am inceput sa ma joc cu media-queries, imagini responsive, rem vs em vs px, pot spune ca am ajuns sa consider grid-ul de la bootstrap salvator.
In concluzie, indiferent de proiect (WordPress, HTML, etc.) integrez grid-ul de la bootstrap, pentru mult mai putine probleme cu rezolutiile device-urilor mobile.
Pentru cei curiosi, lectura suplimentara: The Subtle Magic Behind Why the Bootstrap 3 Grid Works
1 Like
La taskul “sa se vada frumos pe mobil” I mostly hide stuff. Bootstrap is a gem cand vine vorba de chestia asta.
@Catalin_Banu Foundation e foarte flexibil. Mie personal imi place foarte mult sa lucrez full-width, pentru care Foundation e top class, in comparatie cu Bootstrap. Singurul dezavantaj la Foundation, din experienta mea cu, e performanta in anumite situatii.
Cat despre responsive vs. mobile, din punctul meu de vedere totul se rezuma la continut si la loading times. Pentru site-uri foarte content-heavy unde pe langa tonele de continut, mai trebuie sa incarci 12 scripturi, n media-queries sau 6-7 fisiere css (da, unii chiar practica asta pentru responsive), clar mobile e de preferat.
Marile dezavantaje a unei variante mobile, sunt marketing, SEO si social media. 
Evident, e de preferat sa ai toate link-urile intr-un loc si impartite intre domain si sub-domain.
@Razvan: multumesc de interventie, nu am experienta cu Foundation sau Bootstrap.
In legatura cu mobile si desktop version, am vazut cateva variante in care site-ul mobile este servit la acelasi url ca si varianta desktop.
Daca am cuvant de spus in aceasta privinta, aleg intotdeauna responsive. Nu vad probleme care sa nu poata fi rezolvate.
E mult mai rapid, iar mentenanta mult mai usoara.
Pentru ca am vazut ca s-a discutat despre utilitatea framework-urilor frontend in crearea unei versiuni responsive: nu le folosesc niciodata. Grid-urile, stilurile implicite si breakpoint-urile sunt de cele mai multe ori unice pentru fiecare proiect (cu exceptia poate a breakpoint-urilor pentru grid). Da, exista componente reutilizabile, dar si ele au un stil care difera de cele mai multe ori de la un proiect la altul. In afara de asta, lipsa semanticii din anumite componente, mi se pare cea mai mare problema a acestor framework-uri (ex: liste impartite in coloane egale, facute din div-uri doar pentru a se adapta la css).
1 Like
Ce breakpointuri folosesti?
Nu am breakpoint-uri predefinite. In functie de design si continut, verific care sunt rezolutiile la care este necesara o modificare de layout pentru o accesibilitate/vizibilitate cat mai buna a continutului. Pentru fiecare element pot fi diferite (ex: header-ul are nevoie de o prima modificare de la 1000px in jos, insa footer-ul poate necesita o modificare de la 800px in jos). Nu aleg breakpoint-urile in functie de dispozitive, ci in functie de continut si design.
2 Likes