Buletin informativ Smashing

În fiecare săptămână, trimitem tehnici utile front-end și UX. Abonați-vă și obțineți Liste de verificare pentru designul interfeței inteligente PDF livrat în căsuța de e-mail.

diet

Nota editorului: Acesta este un articol introductiv despre un idee de carte care urmează să fie publicat de Smashing Magazine împreună cu Chris Heilmann. Verificați ce propunem ca idee - explicând o modalitate de a reconsidera modul în care creăm site-uri web pentru a ne asigura că acestea sunt mai slabe și mai rezistente la viitor. La sfârșitul articolului, vă vom cere să completați un sondaj rapid pentru a vă arăta interesul.

Web-ul, deoarece suferă acum de o problemă de obezitate. Dacă navigați pe web pe o conexiune mobilă fulgurantă sau pe o rețea fără fir de hotel, vă veți găsi de multe ori cu ochii pe o pagină sau o aplicație care nu face nimic și nu vă spune nici ce se întâmplă. Rotitorul din filă sau bara URL pare să fie cel mai mare kilometraj în browsere. Navigarea cu o filă netă deschisă în instrumentele de dezvoltator vă arată o cantitate incredibilă de date trimise pentru produse finale aparent foarte simple.

De ce este asta? Nu ar fi trebuit ca anii de dezvoltare web și de susținere a performanțelor de către Yahoo și Google și mulți alții să dea roade și să ne conștientizeze cât costă fiecare cerere HTTP? Dacă te uiți la produsele finale, nu pare așa.

Motive pentru o rețea obeză

Există câteva motive pentru care Web-ul nostru este pe partea dolofană, iar majoritatea dintre ele sunt de fapt posibile pentru noi ca dezvoltatori să le schimbăm.

Nu ne dezvoltăm în medii realiste

Probabil că principalul motiv este că, în calitate de dezvoltatori, lucrăm pe computere rapide și mari conectate la o linie grasă și prima dată când cineva testează produsele noastre pe conexiuni lente este în timpul asigurării calității (QA). Și întrucât QA este primul lucru care trebuie abandonat atunci când termenele limită nu sunt respectate, uneori acest lucru nu se întâmplă deloc.

Agățându-ne de trecut

Un alt motiv pentru mâncarea dragostei de pe produsele noastre web este un fals sentiment de loialitate față de tehnologia învechită și veche, și anume browserele din anii '90 care refuză să dispară. Există multe încercări de soluții la problema mediilor vechi, fiecare dintre ele având propriile sale probleme. Faptul este că există o mulțime de utilizatori finali pe computere teribil de învechite, cu - în viziunea noastră - browsere proaste și, probabil, conexiuni limitate. Acești utilizatori nu ar trebui să fie blocați, dar nu ar trebui să dicteze ceea ce construim.

Diferențe de browser

Un alt motiv important este supărarea diferențelor de browser. Nu există multe tehnologii web și API-uri în care toate browserele sunt de acord atunci când vine vorba de sprijinirea acestora și de multe ori trebuie să repetăm ​​codul și furculița și să testăm pentru a le oferi tuturor aceleași funcționalități.

Îmbrățișând haosul și sărbătorind diferențele

Ultimul punct este principala greșeală pe care o facem: în loc să îmbrățișăm haosul care este webul și mediile și abilitățile utilizatorilor noștri finali, nu pare să putem renunța la visul de a avea un produs care să funcționeze și să arate exact la fel peste tot.

Browserul meu nu este lumea?

În cel mai rău caz, încercăm să realizăm acest lucru blocând toate browserele care nu ne plac și proclamând cu mândrie că „toată lumea folosește browserul X și oricine nu este un dușman al web-ului modern”. Bineînțeles, acest lucru ne minte pe noi înșine și se bazează pe conceptul trecător al unei „rețele moderne”. Multe dintre cele mai groaznice produse web bazate pe web au fost construite cu ani în urmă pentru a funcționa numai în Internet Explorer (IE) 6, care era genunchiul albinei în acel moment. Nu contează ce hardware interesant are un browser cablat, care este foarte activ acum - facem din nou aceeași greșeală dacă construim doar un browser și blocăm altele.

Blocarea oricărui browser înseamnă de fapt scrierea mai multor coduri pentru testarea browserelor și este aproape imposibil să detectăm în mod fiabil ce browser este utilizat. Dacă doriți dovezi, aruncați o privire rapidă asupra șirului de agent utilizator al browserului Yandex, care conține numele a aproape fiecare motor de browser de acolo:

_Mozilla/5.0 (Macintosh; Intel Mac OS X 10_82) AppleWebKit/536.5 (KHTML, cum ar fi Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5402 Safari/536.5

Sper că putem fi de acord că construirea unui singur browser (sau motor) funcționează numai pentru dvs. dacă vizați o anumită piață și un anumit grup și chiar și atunci nu sunteți în siguranță să nu le pierdeți în viitorul apropiat.

Bibliotecile sunt viitorul

O altă încercare de a realiza visul uniformității cross-browser-ului este o strategie de abstractizare, utilizând biblioteci, polifenituri și cadre pentru a ne permite să scriem într-o singură limbă și să avem toată magia diferenței de browser sub capotă. Pentru utilizare în producție, aceasta este o idee foarte bună. Pe termen lung, bibliotecile ar trebui să ne ducă unde vrem să fim - aproape fiecare mediu software, mai devreme sau mai târziu, rulează utilizând biblioteci care unifică accesul la hardware sau API-uri de date. Pentru dezvoltarea aplicațiilor, trebuie să definim și să cultivăm aceste biblioteci și să le folosim în avantajul nostru.

Redundanță încorporată

Problema pe care o avem acum este însă că bibliotecile și cadrele de abstractizare devin punctul de plecare și, în cazul site-urilor web simple, cu un pic de fler, nu sunt necesare. Tocmai am început să le folosim fără să ne gândim la impactul lor sau chiar am uitat cum să facem lucrurile fără ele. Și, în multe cazuri, multe dintre lucrurile pe care le facem cu ele sunt deja disponibile în browser pentru noi, trebuie doar să folosim ceea ce există în loc să simulăm. Bibliotecile încep să sufere de obezitate și, în multe cazuri, grăsimea suplimentară este funcționalitatea de a face browserele vechi să facă lucruri pe care nu au fost niciodată menite să le facă, dar browserele bazate pe specificațiile HTML5 au deja încorporat.

Death By A Thousand Plugins

Utilizarea greșită a abstractizării codului este în curs de desfășurare în zilele noastre. Folosim biblioteci și convertoare care ne permit să scriem cea mai mică cantitate posibilă de cod pentru a realiza multe. Aceasta vine cu un preț. Cele trei rânduri pe care le scriem într-un limbaj abstract pot duce la zeci după convertire în cod care poate fi înțeles de browser. Este foarte tentant să folosim 20 de scripturi mici pe paginile noastre atunci când toate sunt doar câteva rânduri, dar acest lucru înseamnă o masă de solicitări HTTP și cod generat care înăbușă browserul. Deoarece nu vedem niciodată acest cod, nu pare a fi greșeala noastră - am scris doar cea mai mică cantitate posibilă de cod. Sigur că adăugarea unui alt script cu doar cinci linii de cod nu poate face diferența?

Deci, aici ar trebui să începem să ne gândim mai greu la ceea ce facem chiar acum. Am devenit dependenți de abstracții pentru cele mai simple lucruri și urmăm un cult de a adăuga o mulțime de instrumente de ajutor, deoarece acestea fac lucrurile mult mai simple și sunt necesare pentru ca un produs să poată fi întreținut și să crească. Multe dintre cele mai bune practici în dezvoltarea web au fost găsite și definite de companiile mari care au trebuit să construiască produse care sunt întreținute în diferite țări și echipe și care trebuie să facă față solicitărilor a milioane de utilizatori. Ceea ce este cea mai bună practică pentru pagina de pornire Yahoo sau Gmail nu trebuie neapărat să fie ceea ce face ca produsul dvs. mai mic să fie cel mai eficient.

Jonathan Snook are un exemplu excelent în acest sens atunci când vorbește despre abordarea sa SMACCS pentru a scrie CSS. El subliniază că aproape fiecare produs începe cu un fișier reset.css, dar odată terminat, eliminarea fișierului nu arată deloc nicio diferență, deoarece pentru elementele pe care le folosim definim marja, umplerea și dimensionarea.

O dietă cu vanilie pentru web

Deci, iată ce vă propun: trebuie să punem Web-ul pe o dietă, folosind tehnologia web vanilată care vine cu browserele. Așa cum a spus Alex Russell în discursul său de la Fronteers anul acesta, dacă vrem să schimbăm internetul, depinde de noi să mergem mai departe, iar utilizarea polifilențelor și a bibliotecilor este o taxă viitoare pe care o plătim în prezent.

Fiecare dietă de succes este legată de o schimbare a stilului de viață. Pentru dieta Vanilla Web, iată ce vă propunem să putem face pentru a reduce produsele pe care le construim. Acest lucru nu se va aplica tuturor, desigur, și există un loc pentru a începe cu o bibliotecă și un strat de abstractizare. După cum am spus mai devreme sau mai târziu, vom avea un mediu în care bibliotecile ne permit să construim aplicații și produse excelente. Dar pentru un site web simplu, cu câteva îmbunătățiri, este timpul să nu mai punem lucrurile la întâmplare, deoarece acestea arată strălucitoare sau par foarte mici.

Principiile unei diete web cu vanilie:

Un exemplu rapid: Adăugarea unui videoclip la un site web

Să luăm un exemplu simplu: adăugarea unui videoclip la o pagină. Condiționat și împovărat cu ani de dezvoltare web, gândirea noastră ar putea fi:

  • Videoclipul HTML5 este frumos, deoarece este nativ pentru browser, comenzile sunt ușor accesibile și aș putea să-mi construiesc propriile controale folosind API-ul JavaScript care vine cu acesta.
  • Cu toate acestea, versiunile mai vechi ale IE nu redă niciun videoclip HTML5, așa că trebuie să adaug o rezervă Flash.
  • Mai mult, nu toate browserele acceptă MP4, așa că trebuie să am video în două formate, MP4 și WebM, precum și OGV, dacă vreau să accept și Firefox și Opera mai vechi.

Ținând cont de acestea, probabil vom primi un player video de la GitHub și îl vom folosi. Playerul video ar fi suficient de inteligent pentru a recunoaște ce suportă browserul curent și pentru a scrie un videoclip Flash sau un videoclip nativ. Nu va ajuta la problema codecului și a suportului pentru browser, cu excepția cazului în care folosim și un player care detectează acest lucru și trimite formatul corect, cum ar fi Vid.ly.

Asta îi face pe toți fericiți și se asigură că toată lumea poate vedea videoclipul, nu? Este adevărat, dar adaugă, de asemenea, o mulțime de cheltuieli generale care nu sunt într-adevăr necesare. Să ne gândim la cazurile de utilizare aici:

  • Dacă mă aflu într-un browser vechi, vreau să încărc o bibliotecă JavaScript, să se facă detecții și să primesc un player Flash? Ce se întâmplă dacă nu am Flash? Am încărcat o bibliotecă degeaba și încă nu pot ajunge deloc la videoclip.
  • Dacă sunt într-un browser modern, am încărcat o bibliotecă și, dacă am Flash activat, atunci voi primi un player Flash cu toate consumurile de memorie și cheltuielile de inițializare (acordat, nu este mult, dar pe MacBook Air pentru de exemplu, ventilatorul pornește mai ales din cauza Flash).

O abordare dietetică cu vanilie în acest sens ar fi următoarea:

Browserele compatibile video HTML5 vor afișa videoclipul, iar altele vor primi o previzualizare a imaginii legată de videoclip. În acest fel, utilizatorii de pe calculatoare vechi și conexiuni sau browsere defecte, fără capacitate video HTML5, vor obține o imagine și pot viziona filmul în aplicația video a sistemului lor de operare. Pot chiar să facă altceva în timp ce videoclipul se descarcă, în loc să se uite la un mesaj „tampon”.

Este prea mult de lucru să ai videoclipul în două formate? Bine, folosește una și mută linkul din eticheta video - astfel vei oferi opțiunea de a descărca videoclipul către toată lumea cu conexiuni fulgurante:

Nu doriți ca videoclipul dvs. să poată fi descărcat? Folosiți Flash sau Silverlight. Acest lucru nu va opri pe nimeni suficient de dedicat pentru ao descărca, dar vă asigură că ați făcut partea dvs. în securizarea conținutului. Blochează însă destul de mulți clienți potențiali și cititori.

Un alt exemplu: Știri extensibile

De multe ori folosim o bibliotecă JavaScript pentru a avea niște titluri care, atunci când se face clic sau se răstoarnă, arată câteva paragrafe sub ele. show-ul jQuery () și hide () sunt destinate acestui lucru și există o multitudine de plugin-uri care să ne ofere această funcționalitate.

Dacă doriți să faceți acest lucru într-o dietă web vanilată, nu este nevoie de JavaScript. Să începem cu HTML. Există multe modalități corecte și greșite de a face acest lucru - liste, liste de definiții, titluri și divizări și așa mai departe. Multe ore au fost irosite pe forumuri, discutând care este mărirea perfectă pentru asta. Luând o frunză din cartea lui Nicole Sullivan, să aplicăm câteva OOCSS și să fim independenți de numele elementelor adăugând clase:

Acum, pentru a face ca acestea să se prăbușească și să se extindă într-un mod lin, tot ce trebuie să facem este să aplicăm câteva CSS:

Aici puteți vedea câteva dintre principiile în acțiune. Versiunile mai vechi ale IE nu înțeleg înălțimea maximă sau opacitatea, deci nu vor aplica niciodată stilurile care ascund conținutul. Înălțimea maximă mult mai mare a stărilor de deplasare și focalizare se asigură că browserul extinde conținutul până la capăt (va merge întotdeauna la înălțimea reală, singura problemă pe care o veți avea este când conținutul este mai mare de 200 de pixeli, deci acest lucru este ceva de subliniat oricui menține codul). Tranziția de o secundă asigură că browserul face acest lucru fără probleme, în loc să afișeze doar conținutul. Browserele care nu acceptă tranzițiile încă afișează și ascund conținutul. Puteți adăuga și tranziții prefixate de browser. Firefox și IE10 au renunțat deja la prefixul pentru tranziții și alții vor urma.

Acum, dacă doriți să adăugați funcționalitate onclick la antet, avem nevoie de ceva JavaScript. În primul rând, însă, ne schimbăm CSS pentru a căuta o clasă pe elementul pliabil în loc să ne bazăm pe hover. De asemenea, ascunderea depinde de o clasă JavaScript, deoarece nu dorim să ascundem conținutul în browsere care nu îndeplinesc toate cerințele scriptului nostru.

Când utilizatorul dă clic pe antet, dorim să adăugăm clasa de spectacol la elementul pliabil și apoi să o eliminăm data viitoare când acesta face clic. Pentru aceasta, nu avem nevoie decât de un singur gestionar de evenimente pe document. Pentru a elimina și a adăuga clasa, am putea modifica proprietatea className, dar browserele mai noi au implementarea classList mult mai flexibilă. Testăm lucrurile pe care le folosim într-o instrucțiune if și ajungem să nu avem deloc cod:

Versiunile mai vechi ale IE nu înțeleg addEventListener (), deci acest lucru nu va fi executat pe măsură ce testăm existența acestuia. Dacă ClassList este acceptat, aplicăm un document de gestionare a clicurilor. Apoi testăm și comutăm clasa show pentru a declanșa schimbarea CSS folosind classList ori de câte ori se face clic pe elementul cu declanșatorul clasei.

Iată acum ideea: intenționez să scriu o carte despre aceasta, publicată cu și de Smashing Magazine. Cred cu adevărat că sunt multe de spus despre lucrurile în HTML5 pe care ni le oferă acum browserele și care ne permit să scriem cod simplu și eficient pentru a lansa produse pragmatice în loc să adăugăm o mulțime de cod, doar că nu avem nevoie pentru ce vrem să realizăm.

Dacă sunteți interesat, completați rapid sondajul de mai jos sau trimiteți-ne un comentariu și vom continua.