Designul responsiv nu este suficient, avem nevoie de performanță responsive

Recent, am întâlnit o mulțime de site-uri web receptive cu multe probleme de performanță. La majoritatea dintre ele, problemele sunt atât de evidente încât sunt aproape inutile pe orice, în afară de ultima generație de smartphone-uri. Având în vedere faptul că receptivitatea ca concept are scopul de a ajunge la un public mai larg, acest lucru pare mai degrabă contraproductiv.

Cel mai mare contributor la această problemă este paradigma de proiectare a desktop-ului, încă răspândită. Gândirea din perspectiva mobile-first pare să abordeze problema, dar numai asta nu garantează o performanță satisfăcătoare. Se pare că toți ne bazăm mult prea mult pe o degradare mai mult sau mai puțin grațioasă. Ne bazăm pe lamele și umplerile polivalente pentru a permite funcționalitatea lipsă. Ne bazăm pe biblioteci pentru a permite dezvoltarea rapidă și pentru a ne sprijini atunci când compatibilitatea browser-ului este o problemă.

"De ce sa te ingrijorezi?" ai putea întreba. „Majoritatea vizitatorilor noștri au smartphone-uri performante care rulează cele mai recente versiuni ale sistemului de operare. Ei se pot ocupa de site-urile noastre. Analizele ne spun așa.”

Îmi pare rău pentru argumentul omului de paie, dar cred că merită afirmat cu voce tare că oamenii care pot folosi site-ul tău vor fi majoritatea utilizatorilor tăi. Dacă nu vedeți Android 2.3 în analizele dvs., înseamnă că nu există utilizatori cu acele dispozitive? Sau înseamnă că site-ul tău nu are nimic de oferit acelor utilizatori? Luați în considerare că o mulțime de dispozitive din acea generație sunt încă pe rafturi, fiind cumpărate noi și astăzi. Nu ar trebui să-l respingi ca fiind o tehnologie de altădată.

Prin urmare, aș dori să vorbesc despre cazurile ideale și obiectivele reale ale dezvoltării web. Și despre practici și paradigme care ne apropie de acele obiective.

Brick-First Design Paradigm

O parte semnificativă din vânzările anuale de telefoane sunt încă preluate de telefoanele cu caracteristici. O parte și mai mare a populației nu cumpără telefoane în fiecare an, dar totuși are în posesia un dispozitiv capabil de web. Adăugați la aceste numere smartphone-uri de ultima generație încă în uz, adăugați kindle și alte dispozitive web semi-capabile (dispozitive WAP, televizoare, prăjitoare de pâine, tricouri și cărămizi). Adună-le pe toate și s-ar putea să ajungi la o sumă uluitoare.

Luați în considerare cazurile de utilizare pentru acest public. Nu vor citi articole lungi, nu vor căuta și nu vor cerceta pe dispozitivele lor. Dar ar putea trece prin ororile de a încerca să introducă o adresă URL pe tastatura numerică și de a naviga prin pagină folosind tastele direcționale pentru a ajunge la un număr de telefon sau de a verifica o adresă din plin.

Cât de greu este atunci pentru noi să implementăm un aspect sub-mobile-first care va oferi doar acele informații dispozitivelor sub un anumit prag de capabilități și performanță?

Îmbunătățire grațioasă

Având degradarea grațioasă ca cea mai bună practică minimă, am creat un principiu general care (într-o oarecare măsură) împiedică gândirea dincolo de el. Odată ce degradarea grațioasă este în vigoare, putem spune cu siguranță că treaba noastră este făcută și bine făcută. Din ce în ce mai des nici nu trebuie să ne gândim la asta, deoarece este deja acoperit de diferitele cadre și biblioteci utilizate. Și, în cele din urmă, poliumpluturile și lamelele elimină complet nevoia de degradare a funcționalității în unele cazuri.

Pe măsură ce această funcționalitate devine din ce în ce mai ușor disponibilă, nevoia de a ne gândi la ea (dară să mai vorbim dincolo de ea) devine din ce în ce mai îndepărtată.

Din punctul de vedere al acestui articol, ar putea fi defalcat astfel:

Degradare incorect: dacă o caracteristică nu este disponibilă cu ușurință, implementarea eșuează în așa fel încât devine inutilizabilă sau utilizabilă într-un mod prohibitiv de impracticabil.

Degradare grațioasă: dacă o caracteristică nu este ușor disponibilă, eșuează într-un mod care permite totuși o utilizare acceptabilă.

Îmbunătățire neplăcută: dacă funcția nu este disponibilă cu ușurință, aceasta este emulată printr-o umplere polivalentă sau o suprafață.

Acolo, problema rezolvată.

Ei bine, dacă nu luați în considerare performanța acelorași dispozitive low-end.

Neavând puterea de procesare și capabilitățile de date ale fraților lor mai mici, li se cere să suporte o sarcină mult mai mare. Luarea polyfills ca soluție creează iluzia că toate funcționalitățile moderne sunt acum disponibile pe toate dispozitivele și pot fi utilizate fără griji.

Și astfel implementați modernizr și polyfill totul pentru orice eventualitate. Dispozitivul cel mai puțin competent ajunge să încarce cea mai mare cantitate de date și să efectueze cea mai mare cantitate de procesare. Asigurând astfel cea mai „cea mai bună” experiență pentru utilizatorul final.

Ideea unei îmbunătățiri grațioase ar inversa conceptul, pornind de la cele mai scăzute cerințe de caracteristică și încărcând upgrade-uri până când echilibrul performanță-utilizabilitate este optim pe baza capacităților dispozitivului. Astfel, cerințele privind traficul și procesarea datelor ar fi mutate către dispozitivele cele mai potrivite pentru a le gestiona.

Sigur, în acest moment conceptul este prohibitiv de complex: nu este susținut de majoritatea cadrelor și bibliotecilor, este în mare parte nediscutat, iar referințele la astfel de practici sunt puține, îndepărtate și localizate în micro-funcționalități. Dar la un moment dat a fost așa cu toate conceptele și funcționalitățile.

Se poate, dar trebuie?

O altă practică bună cu dezvoltarea web este verificarea dacă o caracteristică este disponibilă pe un dispozitiv înainte de a o activa.

Cu toate acestea, țineți cont de faptul că puteți instala cea mai recentă versiune de Google Chrome pe telefonul dvs. Android vechi de ani și acesta va pretinde că poate rula animații CSS, WebGL, efecte de paralaxă de fundal și multe alte funcționalități. Dar chiar, într-adevăr , nu se poate. Atât de mult încât browserul se va prăbuși, iar întregul dispozitiv nu va mai răspunde până la un punct în care va trebui să fie repornit pentru a recăpăta controlul.

Această problemă a început în ultima vreme să afecteze aplicațiile Android într-un mod semnificativ (din punctul de vedere al utilizatorului). Una dintre cele mai vizibile degradări în acest sens a afectat upgrade-ul aplicației Google Talk/Hangouts, care a transformat serviciul lor de la cea mai ușoară aplicație de chat disponibilă la o aplicație aproape inutilizabilă din cauza problemelor de performanță pe dispozitivele mai vechi. (Doar pentru a sublinia încă o dată acest punct: „mai vechi” aici înseamnă că îl puteți cumpăra în continuare de la raft, nou-nouț în aproape orice magazin). Aceeași problemă a afectat aplicația YouTube și aplicația Twitter (din experiența mea) și se pare că multe altele.

Așadar, luați un moment la un moment dat în timpul fazei de planificare pentru a evalua valoarea unei caracteristici de bază de înaltă performanță față de machiajul de ultimă generație. Sau cel puțin lăsați ultima generație a aplicației/serviciului/conținutului dvs. disponibilă într-o anumită formă pentru utilizatorii moșteniți. Apropo de care…

Permiteți utilizatorilor să renunțe la Bleeding Edge

V-ați trezit vreodată că încercați să utilizați Gmail de pe un dispozitiv vechi sau printr-o conexiune slabă? Acest link de „încărcare HTML de bază” este cu siguranță util.

De ce vitrina dvs. online de ultimă oră, receptivă, animată și orientată către atingere nu are această funcționalitate?

Gândiți-vă: ați cerut să fie receptiv, astfel încât să puteți ajunge la mai mulți clienți potențiali. Ai făcut-o de vârf pentru a lăsa cea mai bună impresie. Și, ca rezultat, mai puțini clienți potențiali pot ajunge chiar și la informațiile de bază despre tine și serviciile tale. Dacă îmbunătățirea grațioasă este un concept prea costisitor pentru dvs., de ce nu le oferiți măcar vizitatorilor opțiunea de a accesa o versiune numai text a conținutului dvs. dacă versiunea „WOW” este prea mult pentru dispozitivele lor.

Chiar aveți nevoie de întreaga bibliotecă?

În cele din urmă, ultima bună practică pe care aș dori să o văd împins puțin peste standard este „folosește-l sau pierde-l”. Urmărirea bibliotecilor și modulelor care sunt de fapt utilizate și includerea numai a acestora este uneori plictisitoare, dar păstrarea întregului set de instrumente pe fiecare pagină este pur și simplu neglijentă.

Recent, am început să urmăresc cât de multă funcționalitate folosesc de fapt odată ce includ o bibliotecă. Și instrumentul pe care îl folosesc cel mai des este jQuery. Adesea constat că am folosit doar una sau două funcționalități (cum ar fi $.extend sau $.ready), sau chiar mai rău, că le-am folosit doar pentru a obține elemente după clasă sau ID. Uneori o las așa, alteori revin prin cod pentru a elimina sau decupla dependența.

Nu ar fi bine dacă ați putea analiza automat ce și cât de mult dintr-o bibliotecă a ajuns să fie folosită și să slăbească pe baza rezultatelor?

O mulțime de biblioteci și aplicații oferă opțiunea de a personaliza încărcarea înainte de a începe să o utilizați. Dar continui să am sentimentul că nu ar trebui să fie prea departe de îndemâna noastră standardizarea unei arhitecturi de construcție automate „folosește-o sau pierde-l” în bibliotecile noastre.

Am o alergie la abordarea „include totul”. Dar utilizarea acestuia împreună cu o astfel de funcționalitate ar putea transforma abordarea către ceva similar cu o placă de prototipare: un instrument de dezvoltare excesiv de flexibil care este redus nu numai în sintaxă, ci și în funcționalitatea reală în sine.

Ceea ce ar fi necesar este o versiune numai de dezvoltare a bibliotecii care, printr-un test unitar al funcționalității dependente, ar permite urmărirea caracteristicilor utilizate și emiterea dependenței minime sau cel puțin a unei scale de utilizare (cum ar fi întrebarea dacă am inclus jQuery pentru 8% din funcționalitatea acestuia sau 80%). Ieșirea dependenței ar putea fi apoi utilizată pentru a alege, agrega și minimiza producția pentru producție.

Dar ce pot face în privința asta?

În primul rând, implicați problema . Gândește-te la asta, discută cu colegii tăi și încearcă să identifici problema în scenarii din lumea reală.

Încearcă. Scoateți telefonul de ultimă generație pe care l-ați ascuns într-un sertar undeva. Încercați să-l utilizați pe propriile site-uri web și verificați dacă conținutul este utilizabil chiar de la distanță. Mergeți să vizitați niște rude din urmă din țară și încercați să fiți un evanghelist în tehnologie pentru ei. Vedeți dacă decalajul lor în adoptarea tehnologiei este de fapt facilitat de problemele de accesibilitate.

Dacă sunteți un cumpărător care pune în funcțiune un site web, asigurați-vă că solicitați (cel puțin) un suport de nivel scăzut în această problemă. Amintiți-vă: scopul nu este de a crea un port complet al tuturor funcțiilor dvs. pe dispozitive de nivel scăzut. Tot ceea ce li se cere este ca acei utilizatori să primească informațiile tale de contact în loc să se blocheze dispozitivul.

Lăsați deoparte resursele reale pentru aceasta: cea mai simplă soluție pentru problemă nu ar trebui să dureze mai mult de o zi sau două și puțină gândire înainte. Ține cont de cele mai de bază motive pentru a crea site-ul web în primul rând (darămite să faci un site responsive).

Dacă sunteți un dezvoltator de pachete care lucrează la o bibliotecă, un cadru, un pachet sau orice alt software încorporabil: sunteți cel care poate face cea mai mare diferență aici. Dacă puteți facilita sau încorpora aceste concepte în platforma dvs., veți afecta întregul peisaj al dezvoltării web. Dacă îl încorporezi în designul pachetului tău, anunță-mă și voi evangheliza pentru tine.

Și, în sfârșit, **dacă ești dezvoltator sau designer**, nu te opri doar la cele mai bune practici. Încercați întotdeauna să priviți puțin peste acel orizont. Munca grea este pe tine pentru a promova aceste concepte pe care nimeni nu le-a cerut încă, care sunt nesuportate și nedocumentate în beneficiul clienților și utilizatorilor tăi.

În cele din urmă, dacă doriți să auziți pe cineva care vorbește despre asta ore întregi și să vă aflați în apropiere de Zagreb, anunțați-mă. Am putea merge să luăm o ceașcă de cafea.