Cele nouă principii ale implementării proiectării

La început, am fost confuz. Tocmai am petrecut ore întregi spunându-le tot ce au nevoie pentru a „face-o corect”. Dar după ce m-am gândit la asta, mi-am dat seama că întrebarea are rădăcinile într-o nevoie mai profundă de a ghida și evalua ceea ce este adesea un set de alegeri subiective - alegeri care sunt uneori făcute de o mulțime de oameni diferiți în momente diferite. Lucruri precum convențiile de denumire consecvente și ghidurile de stil live sunt rezultatul final, dar aceste „cele mai bune practici” sunt înrădăcinate într-un set mai profund de valori care nu sunt întotdeauna explicite. De exemplu, sfaturi specifice precum „Reduceți la minimum numărul de clase cu care colaborează o altă clasă” nu sunt la fel de util fără o apreciere mai largă pentru modularitate.

Mi-am dat seama că pentru a ști cu adevărat dacă munca noastră este bună, avem nevoie de un nivel mai înalt de principii care să poată fi folosite ca un instrument de măsurare pentru implementarea designului. Avem nevoie de ceva care să fie eliminat dintr-un anumit limbaj, cum ar fi CSS, sau un mod obișnuit de a-l scrie. La fel ca principiile universale ale designului sau euristica de utilizare a Nielsen, avem nevoie de ceva care să ghideze modul în care implementăm designul fără a ne spune exact cum să o facem. Pentru a reduce acest decalaj, am compilat nouă principii de implementare a designului.

Aceasta nu este o listă de verificare. În schimb, este un set de linii directoare ample menite să păstreze o valoare subiacentă. Poate fi folosit ca ghid pentru cineva care lucrează la implementare sau ca instrument de evaluare a unui proiect existent. Deci, indiferent dacă revizuiți codul, auditați CSS sau intervievați candidații pentru un rol în echipa dvs., aceste principii ar trebui să ofere o structură care să transcende tehnicile specifice și să rezulte într-o abordare comună a implementării designului.

1. Structurat Documentul este scris semantic și logic, cu sau fără stiluri.
2. Eficient Cea mai mică cantitate de markup și active sunt utilizate pentru realizarea designului.
3. Regulile standardizate pentru valorile comune sunt stocate și utilizate liberal.
4. Elementele de bază abstracte sunt separate dintr-un context specific și formează un cadru de bază.
5. Elementele comune modulare sunt împărțite în mod logic în părți reutilizabile.
6. Personalizările configurabile ale elementelor de bază sunt disponibile prin parametri opționali.
7. Scalabil Codul este ușor de extins și anticipează îmbunătățiri în viitor.
8. Documentat Toate elementele sunt descrise pentru ca alții să le folosească și să le extindă.
9. Acurate Rezultatul final este o reprezentare adecvată a designului dorit.
   

Pentru a fi mai ușor de urmărit și de a vedea cum se aplică fiecare principiu unui proiect, vom folosi o machetă de design dintr-unul dintre proiectele mele ca bază pentru acest articol. Este o pagină de destinație specială care promovează oferte zilnice pe un site de comerț electronic existent. Deși unele dintre stiluri vor fi moștenite de pe site-ul web existent, este important să rețineți că majoritatea acestor elemente sunt noi. Scopul nostru este să luăm această imagine statică și să o transformăm în HTML și CSS folosind aceste principii.

1. Structurat

Documentul este scris semantic și logic, cu sau fără stiluri.

Principiul aici este că conținutul documentului nostru (HTML) are sens chiar și fără stiluri de prezentare (CSS). Desigur, asta înseamnă că folosim niveluri de titluri ordonate corect și liste neordonate, dar și containere semnificative, cum ar fi <header> și <article> . Nu ar trebui să omitem folosirea unor lucruri precum etichetele ARIA, atributele alt și orice alte lucruri de care am putea avea nevoie pentru accesibilitate.

S-ar putea să nu pară mare lucru, dar contează dacă utilizați o etichetă de ancorare sau un buton - chiar dacă sunt identice din punct de vedere vizual - deoarece comunică semnificații diferite și oferă interacțiuni diferite. Marcajul semantic comunică acest sens motoarelor de căutare și tehnologiilor de asistență și chiar facilitează reutilizarea muncii noastre pe alte dispozitive. Ne face proiectele mai sigure pentru viitor.

Crearea unui document bine structurat înseamnă să înveți să scrii HTML semantic, să te familiarizezi cu standardele W3C și chiar cu unele bune practici de la alți experți și să-ți iei timp pentru a-ți face codul accesibil. Cel mai simplu test este să vă uitați la HTML într-un browser fără stiluri:

• Este utilizabil fără CSS?
• Mai are o ierarhie vizibilă?
• HTML-ul brut transmite în sine sens?

Unul dintre cele mai bune lucruri pe care le puteți face pentru a vă asigura că un document structurat este să începeți cu HTML. Înainte de a vă gândi la stilurile vizuale, scrieți HTML simplu pentru modul în care ar trebui să fie structurat documentul și ce înseamnă fiecare parte. Evitați div -urile și gândiți-vă care ar fi o etichetă de ambalare adecvată. Doar acest pas de bază vă va ajuta în mare măsură să creați o structură adecvată.

 <section> <header> <h2>Daily Deals</h2> <strong>Sort</strong> <span class="caret"></span> <ul> <li><a href="#">by ending time</a></li> <li><a href="#">by price</a></li> <li><a href="#">by popularity</a></li> </ul> <hr /> </header> <ul> <li aria-labelledby="prod7364536"> <a href="#"> <img src="prod7364536.jpg" alt="12 Night Therapy Euro Box Top Spring" /> <small>Ends in 9:42:57</small> <h3 id="prod7364536">12" Night Therapy Euro Box Top Spring</h3> <strong>$199.99</strong> <small>List $299</small> <span class="callout">10 Left</span> </a> </li> </ul> </section>

Începând doar cu HTML și gândirea la semnificația fiecărui element are ca rezultat un document mai structurat. Mai sus, puteți vedea că am creat întregul marcaj fără a utiliza un singur div .

2. Eficient

Cea mai mică cantitate de markup și active sunt utilizate pentru realizarea designului.

Trebuie să ne gândim la codul nostru pentru a ne asigura că este concis și nu conține markupuri sau stiluri inutile. Este obișnuit pentru mine să revizuiesc codul care are div -uri în div -uri în div -uri folosind nume de clasă specifice cadrului doar pentru a obține un element la nivel de bloc care este aliniat la dreapta. Adesea, o utilizare excesivă a HTML este rezultatul neînțelegerii CSS sau cadrul de bază.

Pe lângă marcaj și CSS, este posibil să avem nevoie de alte active externe, cum ar fi pictograme, fonturi web și imagini. Există o mulțime de metode și opinii grozave despre cele mai bune modalități de implementare a acestor active, de la fonturi de pictograme personalizate la încorporare base64 până la SVG-uri externe. Fiecare proiect este diferit, dar dacă aveți un PNG de 500 de pixeli pentru o singură pictogramă pe un buton, sunt șanse să nu fiți intenționat în ceea ce privește eficiența.

Atunci când evaluați un proiect pentru eficiență, există două întrebări importante de adresat:

• Aș putea realiza același lucru cu mai puțin cod?
• Care este cea mai bună modalitate de a optimiza activele pentru a obține cele mai mici cheltuieli generale?

Eficiența implementării se suprapune, de asemenea, cu următoarele principii privind standardizarea și modularitatea, deoarece o modalitate de a fi eficient este implementarea proiectelor folosind standarde stabilite și a le face reutilizabile. Crearea unui mixin pentru o umbră de casetă comună este eficientă, creând în același timp un standard care este modular.

3. Standardizat

Regulile pentru valorile comune sunt stocate și utilizate liberal.

Crearea de standarde pentru un site web sau o aplicație înseamnă, de obicei, stabilirea regulilor care guvernează lucruri precum dimensiunea fiecărui nivel de antet, o lățime comună a jgheabului și stilul pentru fiecare tip de buton. În CSS simplu, ar trebui să păstrați aceste reguli într-un ghid de stil extern și să vă amintiți să le aplicați corect, dar cel mai bine este să folosiți un preprocesor precum LESS sau Sass, astfel încât să le puteți stoca în variabile și mixuri. Principala concluzie aici este să prețuiești standardele în defavoarea designurilor perfecte cu pixeli .

Deci, când primesc o machetă de design cu o lățime a jgheabului de 22 de pixeli, în loc de cei 15 pixeli pe care îi folosim în altă parte, voi presupune că o astfel de precizie nu merită și în schimb voi folosi jgheabul standard de 15 pixeli. . Făcând un pas mai departe, toată distanța dintre elemente va folosi acest standard în multipli. Un spațiu extra larg va fi $gutter-width * 2 (echivalent cu 30 de pixeli), mai degrabă decât o valoare codificată. În acest fel, întreaga aplicație are o senzație consistentă și aliniată.

 .product-cards { li { display: inline-block; padding: @gutter-width/4; color: @text-color; text-decoration: none; background-color: @color-white; .border; margin-bottom: @gutter-width/2; margin-right: @gutter-width/2; } } .product-status { font-size: @font-size-small; color: @grey-darker; font-weight: @font-weight-bold; margin-bottom: @gutter-width/4; }

Deoarece folosim valori standardizate derivate din variabile LESS sau mixuri, CSS-ul nostru nu are valori numerice proprii. Totul este moștenit dintr-o valoare centralizată.

Pentru a verifica standardizarea, examinați CSS-ul și căutați orice unitate codificată: pixeli, culori HEX, ems sau aproape orice valoare numerică.

• Aceste unități ar trebui să utilizeze o valoare standard sau o variabilă existentă?
• Unitatea este reutilizată astfel încât să beneficieze de o nouă variabilă? Poate v-ați dat seama că este a doua oară când aplicați un fundal parțial opac și că aceeași opacitate este necesară de ambele ori.
• Ar putea unitatea să fie derivată din calculul unei variabile existente? Acest lucru este util pentru variațiile de culoare - de exemplu, folosirea unei culori standard și efectuarea unui calcul pe aceasta pentru a obține ceva cu 10% mai întunecat, mai degrabă decât codificarea valorii HEX rezultată.

Pe cât posibil, folosesc valori standard și creez altele noi doar ca excepție. Dacă ajustezi un element cu 5 pixeli aici și 1 pixel acolo, sunt șanse ca standardele tale să fie compromise.

Din experiența mea, majoritatea CSS-urilor preprocesate ar trebui să utilizeze variabile și mixuri centralizate și nu ar trebui să vedeți aproape nicio valoare numerică, pixelă sau HEX în componentele individuale. Ocazional, adăugarea de câțiva pixeli pentru a ajusta poziția unei componente individuale ar putea fi adecvată - dar chiar și acele cazuri ar trebui să fie rare și să vă determine să vă verificați din nou standardele.

4. Rezumat

Elementele de bază sunt separate dintr-un context specific și formează un cadru de bază.

Inițial am numit acest principiu „încadrat”, deoarece, pe lângă crearea unui proiect specific la care lucrați acum, ar trebui să lucrați și la un sistem de proiectare care să poată fi utilizat dincolo de contextul original. Acest principiu se referă la identificarea elementelor comune mai mari care trebuie utilizate pe parcursul întregului proiect sau în proiecte viitoare. Aceasta începe la fel de larg ca tipografie și intrări în câmpuri de formular și până la diferite modele de navigare. Gândiți-vă la asta astfel: dacă CSS-ul dvs. ar fi open source ca cadru, cum ar fi Bootstrap sau Foundation, cum ați separa elementele de design? Cum le-ai stila diferit? Chiar dacă utilizați deja Bootstrap, sunt șanse ca proiectul dvs. să aibă elemente de bază pe care Bootstrap nu le furnizează și acestea trebuie, de asemenea, să fie disponibile în sistemul de proiectare al proiectului.

Cheia aici este să vă gândiți la fiecare element în termeni mai generici, mai degrabă decât în ​​contextul specific al proiectului dumneavoastră. Când vă uitați la un anumit element, împărțiți-l în părți și oferiți fiecărei părți stiluri generale pe care acel element le-ar avea, indiferent de implementarea specifică cu care lucrați acum. Cele mai comune elemente sunt tipografia (stilurile de titlu, înălțimea liniilor, dimensiunile și fonturile), elementele de formular și butoanele. Dar și alte elemente ar trebui să fie „încadrate”, cum ar fi eticheta cu înștiințări sau orice formatare specială a prețului care ar fi putut fi concepută pentru Ofertele noastre zilnice, dar care ar fi, de asemenea, utilă în altă parte.

Când verificați proiectul pentru abstracție, întrebați:

• Cum aș construi acest element dacă aș ști că va fi reutilizat într-un alt context cu nevoi diferite?
• Cum îl pot împărți în părți care ar fi valoroase pe parcursul întregii aplicații?

Gândirea la o implementare mai generală a fiecărui element este cheia. Aceste piese ar trebui să fie stocate ca clase complet separate și independente sau, mai bine, ca fișiere LESS sau Sass separate care pot fi compilate cu CSS-ul final.

Acest principiu este mai ușor într-o arhitectură de aplicație de componentă web sau modul, deoarece widget-urile sunt probabil deja separate în acest fel. Dar are la fel de multe implicații pentru gândirea noastră ca orice altceva. Ar trebui să ne abstragem întotdeauna munca din contextul din care a fost derivată pentru a fi siguri că creăm ceva flexibil.

5. Modular

Elementele comune sunt împărțite în mod logic în părți reutilizabile.

Suprapunerea cu principiul „Abstract”, modularizarea proiectelor noastre este o parte importantă a stabilirii unui sistem de proiectare concret cu care este ușor de lucrat și de întreținut. Există o linie fină între cele două, dar diferența este importantă în principiu. Nuanța este că, în timp ce elementele de bază globale trebuie să fie abstrase din contextul lor, articolele individuale din context trebuie, de asemenea, să fie reutilizabile și să mențină stiluri independente. Modulele pot fi unice pentru aplicația noastră și nu este ceva de care avem nevoie disponibil în întregul cadru - dar ele trebuie totuși să fie reutilizabile, astfel încât să nu duplicam codul de fiecare dată când folosim acel modul.

De exemplu, dacă implementați lista de carduri de produse din exemplul anterior pentru o pagină de destinație Daily Deals, în loc să faceți HTML și CSS specific pentru Daily Deals, cu nume de clasă precum daily-deal-product , creați în schimb o pagină mai generală. clasă product-cards care include toate clasele rezumate, dar poate fi reutilizată și în afara paginii Oferte zilnice. Acest lucru ar duce probabil la trei locuri separate în care componenta dvs. își primește stilurile:

• CSS de bază . Acesta este cadrul de bază, inclusiv valorile implicite pentru tipografie, jgheaburi, culori și multe altele.
• Componente CSS . Acestea sunt părțile abstracte ale designului care formează blocurile de construcție ale designului general, dar pot fi utilizate în orice context.
• componentele părinte . Acestea sunt componenta daily-deal (și orice copii) care conține stiluri sau personalizări specifice ofertelor zilnice. Pentru mulți, aceasta va fi o componentă web JavaScript reală, dar ar putea fi doar un șablon părinte care include HTML-ul necesar pentru a reda întregul design.

Desigur, puteți duce acest lucru prea departe, așa că va trebui să vă exercitați judecata. Dar, în cea mai mare parte, tot ceea ce creați ar trebui să fie cât mai reutilizabil posibil, fără a complica prea mult întreținerea pe termen lung.

6. Configurabil

Personalizările elementelor de bază sunt disponibile prin parametri opționali.

O parte a construirii unui sistem de proiectare constă în a gândi opțiunile de care proiectul ar putea avea nevoie acum sau în viitor. Nu este suficient să implementați designul doar așa cum este prescris. De asemenea, trebuie să luăm în considerare ce părți ar putea fi opționale, pornite sau oprite printr-o configurație diferită.

De exemplu, steagurile cu înștiințări din designul nostru arată doar trei variante de culoare, toate îndreptate spre stânga. În loc să creăm trei clase separate, vom crea o clasă implicită și vom adăuga nume de clasă suplimentare ca parametri opționali. Dincolo de asta, cred că cineva ar putea veni și ar dori să îndrepte steagul corect pentru un context diferit. De fapt, folosirea culorilor noastre implicite ale mărcii pentru aceste înștiințări este de asemenea utilă, chiar dacă designul nu o solicită în mod special. Am scrie CSS-ul special pentru a ține cont de acest lucru, incluzând atât stânga, cât și dreapta ca opțiuni.

În timp ce vă gândiți la un anumit element de design, gândiți-vă la opțiunile care ar putea fi valoroase. O parte importantă a înțelegerii acestui lucru este gândirea critică la alte contexte în care acest element ar putea fi reutilizat.

• Ce părți ar putea fi configurate, opționale sau activate printr-o variabilă externă?
• Ar fi valoros ca culoarea sau poziția elementului să se poată schimba?
• Ar fi util să oferiți dimensiuni mici, medii și mari?

Utilizarea unei metodologii precum BEM, OOCSS sau SMACSS pentru a vă organiza CSS și a stabili convenții de denumire vă poate ajuta să luați aceste decizii. Lucrarea prin aceste cazuri de utilizare este o parte importantă a construirii unui sistem de proiectare configurabil.

7. Scalabil

Codul este ușor de extins și anticipează îmbunătățiri în viitor.

În același spirit ca principiul „Configurabil”, implementarea noastră trebuie, de asemenea, să se aștepte la schimbări în viitor. Deși construirea parametrilor opționali este utilă, nu putem anticipa tot ce va avea nevoie proiectul nostru. Prin urmare, este important să luăm în considerare și modul în care codul pe care îl scriem va afecta modificările viitoare și să-l organizăm în mod intenționat, astfel încât să fie ușor de îmbunătățit.

Construirea de CSS scalabil îmi cere de obicei să folosesc funcții mai avansate ale LESS și Sass pentru a scrie mixuri și funcții. Deoarece toate steagurile noastre de apelare sunt aceleași, cu excepția culorilor, putem crea un singur mixin LESS care va genera CSS pentru fiecare apel fără a fi nevoie să duplicam codul pentru fiecare variație. Codul este proiectat pentru scalare și este ușor de actualizat într-un singur loc.

 @angle: 170; .callout { &.qty-left { .callout-generator(@color-deals, @color-white, @angle); } &.qty-sold { .callout-generator(@color-white, @color-deals, @angle, 2px solid @color-deals); } &.qty-out { .callout-generator(@color-grey, darken(@color-grey, 10%), @angle); } }

Pentru a face înștiințările scalabile, vom crea un mixin LESS numit .callout-generator care acceptă valori pentru lucruri precum culoarea de fundal, culoarea textului, unghiul punctului și chenarul.

 .review-flag { .callout-generator(@color-brand, @color-white, 75); }

În viitor, când o nouă cerință necesită un model de design similar, generarea unui nou stil va fi ușor.

Pentru a crea un sistem de proiectare scalabil, învățați să anticipați schimbările care sunt comune în proiecte și să aplicați această înțelegere pentru a vă asigura că codul pe care îl scrieți este pregătit pentru acele modificări. Soluțiile obișnuite includ utilizarea variabilelor și mixurilor, precum și stocarea valorilor în matrice și trecerea în buclă prin ele. Intreaba-te pe tine insuti:

• Ce părți ale acestor elemente sunt susceptibile de a se schimba?
• Cum poți scrie codul astfel încât să fie ușor să faci acele modificări în viitor?

8. Documentat

Toate elementele sunt descrise pentru ca alții să le folosească și să le extindă.

Documentarea designului este subevaluată și este adesea primul colț care trebuie tăiat într-un proiect. Dar crearea unei evidențe a muncii tale înseamnă mai mult decât să ajuți următoarea persoană să-și dea seama ce ai intenționat – este de fapt o modalitate excelentă de a-ți aduce toți părțile interesate la bord cu întregul sistem de design, astfel încât să nu reinventezi roata de fiecare dată. . Documentația dvs. ar trebui să fie o referință pentru toată lumea din echipă, de la dezvoltatori la directori.

Cel mai bun mod de a vă documenta munca este să creați un ghid de stil live, unul care este generat direct din comentariile din codul dvs. Folosim o abordare numită dezvoltare bazată pe ghiduri de stil, împreună cu DocumentCSS, care se plătește singur în dividende. Dar chiar dacă proiectul tău nu poate avea un ghid de stil live, crearea manuală a unuia în HTML sau chiar a unui PDF formatat pentru imprimare este bine. Principiul de reținut este că tot ceea ce facem trebuie să fie documentat .

Pentru a vă documenta sistemul de proiectare, scrieți instrucțiuni pentru a ajuta pe altcineva să înțeleagă cum a fost implementat designul și ce trebuie să facă pentru a-l recrea ei înșiși. Aceste informații pot include gândirea de design specifică din spatele unui element, mostre de cod sau o demonstrație a elementului în acțiune.

• Cum aș spune altcuiva cum să-mi folosească codul?
• Dacă aș include un nou membru al echipei, ce aș explica pentru a mă asigura că știu cum să-l folosească?
• Ce variații ale fiecărui widget pot arăta pentru a demonstra toate modurile în care poate fi utilizat?

9. Acurate

Rezultatul final este o reprezentare adecvată a designului dorit.

În cele din urmă, nu putem uita că ceea ce creăm trebuie să arate la fel de grozav ca și conceptul original de design pe care intenționează să îl reflecte. Nimeni nu va aprecia un sistem de design dacă nu le satisface așteptările în ceea ce privește atractivitatea vizuală. Este important de subliniat faptul că rezultatul poate fi doar o reprezentare adecvată a designului și nu va fi perfect în pixeli. Nu-mi place expresia „pixel-perfect”, deoarece a sugera că o implementare trebuie să fie exact ca macheta, pixel pentru pixel, înseamnă a uita orice constrângere și a devaloriza standardizarea (nu contează că fiecare browser redă CSS puțin). diferit). Acuratețea care complică este faptul că design-urile statice pentru aplicații receptive rareori iau în considerare fiecare dimensiune posibilă a dispozitivului. Ideea este că este necesar un anumit grad de flexibilitate.

Va trebui să decideți cât de mult este nevoie de o reprezentare adecvată pentru proiectul dvs., dar asigurați-vă că aceasta corespunde așteptărilor oamenilor cu care lucrați. În proiectele noastre, voi analiza abaterile majore de la perfecțiunea pixelilor cu clientul, doar pentru a fi sigur că suntem pe aceeași pagină. „Desenele arată un stil implicit de buton albastru cu chenar, dar culoarea standard a butonului este ușor diferită și nu are chenar, așa că am optat pentru asta.” Stabilirea așteptărilor este cel mai important pas aici.

Un sistem de gândire

Scopul acestor nouă principii este de a oferi un ghid pentru implementarea designului în HTML și CSS. Nu este un set de reguli sau sfaturi prescriptive la fel de mult, ci este un mod de a vă gândi munca, astfel încât să puteți optimiza pentru cel mai bun echilibru între design excelent și cod excelent. Este important să vă oferiți o anumită flexibilitate în aplicarea acestor principii. Nu vei putea atinge perfecțiunea cu fiecare de fiecare dată. Sunt idealuri. Există întotdeauna alte distrageri, principii și priorități care ne împiedică să facem cel mai bun lucru. Totuși, principiile ar trebui să fie ceva pentru care să te străduiești mereu, să te verifici în mod constant și să le urmărești în mod agresiv în timp ce îți duci designul de la planșa de desen la mediul final în care va fi experimentat. Sper că vă vor ajuta să creați produse mai bune și să construiți sisteme de proiectare care să dureze mulți ani.

Mi-ar plăcea să aud de la tine despre experiența ta în implementarea designului. Postați un comentariu și împărtășiți orice sfat sau alte principii pe care le utilizați în propria muncă.