Schimbare vizuală în sistemele de proiectare

Respectăm API-urile de cod. Dar ce zici de culoare, tip și spațiu?

Nr. 4 din 6 din seria lansatoare de sisteme de proiectare:
Produse | Cadență | Versiuni | Ruperea | Dependențe | Proces

Sistemele de proiectare stabilesc un stil vizual de bază care este o dependență esențială. Aceste opțiuni - culoare, tipografie, spațiu și multe altele - sunt specificate în mod robust și se așteaptă să modifice în mod stabil, previzibil, modificarea lansării. Când un adoptator face upgrade, un sistem de proiectare nu ar trebui să-și rupă lucrurile pe neașteptate.

Deci, întreabă-te ...

Adopții pot face upgrade la o versiune minoră sigură că interfața de utilizator nu se va sparge din cauza modificărilor vizuale ale unui sistem?

Versiunea semantică (SemVer) oferă criterii clare pentru a comunica schimbările între versiuni, folosind desemnări majore, minore și patch. Fiecare sistem de proiectare pe care îl întâlnesc folosește SemVer și monitorizarea schimbărilor în interfața de programare a aplicației sau API-ul pachetului lor. Acesta este un teritoriu familiar pentru dezvoltatorii care codifică accesorii JavaScript și marcare HTML. Rupeți API-ul dvs., iar următoarea versiune trebuie să crească versiunea la o versiune următoare următoare, cum ar fi de la 1.4.0 la 2.0.0.

Specificarea unei interfețe pentru stilul vizual compozițional ne evită. Este atât de dificil să definești reguli clare și simple pentru a monitoriza schimbările de stil. Producătorii de sistem se luptă să articuleze ce sau de ce „Schimbarea acestui stil sparge interfața utilizatorului”, față de „Modificarea acelui stil nu”. Puține echipe de sistem documentează astfel de criterii. Întreb „Ce tipuri specifice de modificări vizuale declanșează o versiune majoră pentru dvs.?” Răspunsul lor: ¯ \ _ (ツ) _ / ¯.

În acest articol, propun ca cel puțin criteriile de culoare, tipografie și garanție spațială care să constituie o schimbare de rupere. Există și alte proprietăți care trebuie luate în considerare. Un sistem de proiectare poate defini, documenta și comunica aceste criterii, astfel încât adoptatorii să poată actualiza lansarea prin eliberare cu încredere.

Ruperea culorii

Majoritatea echipelor de sistem se simt în siguranță atunci când ajustează culoarea de fundal a unui buton principal. Poate motivația lor este să îmbunătățească contrastul cu o etichetă de text alb, de obicei. „Să întunecăm un pic mâncarea”, spun ei. „Vom îmbunătăți contrastul de culoare accesibil al butonului, de la un rating AA la un AAA.”

Reglarea culorii de fundal a unui buton primar

Cu siguranță, adoptarea echipelor nu ar trebui să înlocuiască setul de culori al unui buton principal standard. Suprasolicitarea unei alegeri de sistem interzice conexiunea cu un sistem. În acel moment, un adoptator este pe cont propriu. Prin urmare, ajustarea nuanței culorii de fundal a butonului primar este sigură și nu este o schimbare completă.

Cu toate acestea, schimbarea culorilor în altă parte poate pune în pericol adopții. Luați în considerare următoarele scenarii.

Exemplu: Text de sistem pe fundaluri personalizate

Imaginează-ți o echipă de sistem care ajustează bine albastrul interactiv pentru a îmbunătăți contrastul culorilor. Albastru interactiv din v1.4.0 a fost accesibil pe un fundal alb, dar nu a reușit pe fundalul cărbunelui.

Verificarea contrastului culorilor prin contrast-grid.eightshapes.com

Deci, pentru v1.5.0, echipa a adaptat albastru interactiv la un ton mai ușor, mai saturat, care a funcționat atât pe alb cât și pe cărbune.

Reglarea culorii textului unei etichete de buton fantomă pe fundaluri imprevizibile

Cu toate acestea, un adoptator folosise butonul Ghost dependent de acea culoare pe un fundal gri deschis. După schimbarea sistemului, contrastul de culoare al textului etichetei este inaccesibil. Sistemul dvs. a rupt produsul lor.

Exemplu: Fundaluri de sistem cu text suprapus personalizat

În mod similar, imaginați-vă că un sistem întunecă culoarea fundalului componentei cardului. Zona de conținut a cardului include o zonă de container-conținut „sigură” în care utilizatorii introduc orice conținut și marcaj doresc.

Reglarea culorii de fundal a unui card care permite conținutul personalizat conținut

În acea zonă, probabil, sigură, un adoptator a adăugat un text secundar care, deși un gri subtil moderat, a trecut un test de contrast de culoare. După schimbarea sistemului, contrastul de culoare nu mai este accesibil. Sistemul dvs. a rupt produsul lor.

Imaginează-ți că versiunea minoră a sistemului tău a inclus aceste ajustări. Compatibil înapoi, ai spus? Nu aveți niciun risc în actualizare, au avut încredere? Nope! Sistemul dvs. a rupt produsul lor!

Prin urmare, evaluați proprietățile de culori schimbate pentru a determina dacă un sistem a fost schimbat, cum ar fi:

  • Culoarea textului care ar putea apărea deasupra culorii de fundal, a imaginii sau a altei texturi a adoptatorului.
  • culoare de fundal pe care este suprapusă culoarea textului unui adoptant.
  • culoare de fundal, culoare de bordură, culoare text, cutie-umbră sau alte proprietăți compuse lângă, deasupra sau sub marginea sau conținutul altei componente, pentru a diminua contrastul dintre elemente.

Accesibilitatea a determinat aceste exemple. Există, de asemenea, un risc estetic, prin faptul că schimbările bine intenționate ale sistemului ar putea perturba armonia colorată realizată de un designer de produse. Interacțiunile de culori abundă în toată interfața de utilizare în care un proiectant de sistem nu controlează sau nu are vizibilitate.

Take away: Începeți să schimbați conversația cu schimbarea criteriilor de culoare. Este mai ușor să transmită riscuri, se poate măsura în mod obiectiv și este accesibil la accesibilitatea care stârnește pasiunile. Înarmat cu câteva criterii, puteți trece la alte probleme.

Tipografie de rupere (prin înfășurare)

Tipografia este o fațetă de bază a oricărui stil vizual. Echipele vor să o înțeleagă. Și există atât de multe formate pentru a tonifica: font-family, font-weight, font-size, text-transformation, line-înălțime, distanțare de litere și multe altele.

Nu toate experiențele riscă să se rupă dacă un sistem ajustează tipografia. Pentru experiențe cu conținut puternic, conținutul fiecărui element poate fi imprevizibil, cu o lungime variabilă și conceput pentru a înfășura și a răspunde modificărilor în lățimea viewport-ului.

Pentru interfețe mai dense, tipografia trebuie să fie precisă. Designerii măcinează ore în șir tipografia de reglare fină, aranjând etichete pentru a se potrivi în zone compacte. Dacă ajustați tipografia sistemului, elementele lor se pot înfășura sau decupa în mod neașteptat.

Exemplu: filele de înfășurare sunt grozave

Imaginați-vă că sistemul ajustează fila labelfont-greutate de la normal la bold.

După o actualizare a versiunii minore, filele care nu răspund sunt înfășurate. Nu e bine.

Un adoptator face upgrade. Fișele lor care nu răspund deja depășesc spațiul alocat, astfel încât acestea se înfășoară. Ghastly! Sistemul dvs. a rupt produsul lor.

Exemplu: Mayhem Spațiu de litere

Liniile directoare ale brandului evoluează, oferind o nouă ierarhie și stil de rubrică. Astfel, sistemul dvs. se adaptează sporind spațiul de litere al fiecărui titlu.

Un adoptator își îmbunătățește aplicația de radiologie densă, cu o singură pagină, care este tradusă în 14 limbi, compusă din panouri de control numeroase, fiecare chock plin de elemente de formă și titluri. Aceștia fac upgrade, iar interfața de utilizator este neplăcută, cu titluri neprevăzute decupate. Ei numesc o întâlnire de criză. Ei invită ingineri de date din urmă, pentru sume de bunătate! Sistemul dvs. a rupt produsul lor!

Reglarea tipografiei sistemului poate fi periculoasă. Pentru dvs., este o evoluție tipografică revigorantă desfășurată fără efort într-o bibliotecă. Pentru ei, textul începe să se comporte greșit. Te învinovățesc. Poate vă flamăază în canalul # Slack-design de sistem. Nimeni nu are nevoie de asta.

Take away: înainte de 1.0.0, lucrați cu sârguință pentru a experimenta, perfecționa și finaliza stiluri de tip potrivite pentru varietatea clientului. Odată ce trece 1.0.0, susțineți o bază stabilă și luați în considerare schimbarea cu prudență. Luați în considerare rezervarea unor schimburi periculoase pentru următoarea versiune majoră. Până atunci, adăugați în mod incremental caracteristici conținute, cum ar fi o componentă Text Formă lungă pentru a crea doar o copie a articolului.

Spargerea spațiului și dimensiunea

Măcar puteți vedea culoarea și tipografia. Spațiu și dimensiune? Acestea sunt mai greu de definit ca fiind refolosibile în mod concret, cu atât mai puțin să monitorizăm schimbările de rupere.

În HTML, atunci când schimbați proprietățile modelului de casetă a unei componente - căptușire, marjă, lățime, înălțime, afișare, dimensionare cutie, poziție, stânga, dreapta, sus, jos - riscați să influențați compoziția machetei care aranjează acea componentă cu alte elemente de pagină.

Exemplul 1: Îndepărtarea spațiului vertical

Echipa dumneavoastră de sistem decide să elimine controalele de formular aplicate cu spațiu vertical sub formă de margine de jos. Acest lucru afectează ,