Deciziile dezvoltatorului pentru construirea de componente flexibile

În lumea reală, conținutul diferă adesea foarte mult de conținutul îngrijit, perfect potrivit, prezentat în design. În plus, pe web-ul modern, utilizatorii au o gamă din ce în ce mai mare de opțiuni pentru modul în care accesează site-urile pe care le construim.

În acest articol, vom parcurge procesul de luare a unui design aparent simplu pentru o componentă de text și media și de a decide cum să o traducem cel mai bine în cod, ținând cont atât de nevoile utilizatorilor, cât și ale autorilor de conținut. Nu vom analiza modul în care îl codificăm, ci mai degrabă factorii care vor determina deciziile noastre de dezvoltare. Vom lua în considerare întrebările pe care trebuie să le punem (atât pe noi, cât și pe celelalte părți interesate) la fiecare pas.

Schimbarea mentalității noastre de dezvoltare

Pur și simplu nu mai putem proiecta și dezvolta doar pentru conținut „optime” sau condiții de navigare. În schimb, trebuie să îmbrățișăm flexibilitatea și imprevizibilitatea inerente ale web-ului și să construim componente rezistente. Modelele statice nu pot satisface fiecare scenariu, așa că multe decizii de proiectare revin dezvoltatorilor în timpul construirii. Vă place sau nu, dacă sunteți un dezvoltator de UI, sunteți un designer - chiar dacă nu vă considerați unul!

În jobul meu la agenția web specializată în WordPress Atomic Smash , construim site-uri web pentru clienții care au nevoie de flexibilitate maximă din partea componentelor pe care le oferim, asigurându-ne totodată că site-ul arată în continuare grozav, indiferent de conținutul pe care îl aruncă. Uneori interpretarea unui design înseamnă a cere designerului să-și elaboreze în continuare ideile (sau chiar să le reevalueze). Alteori, înseamnă să luăm decizii de proiectare din mers sau să facem recomandări pe baza cunoștințelor și experienței noastre. Vom analiza câteva dintre momentele în care aceste abordări ar putea fi adecvate în acest studiu de caz.

Design-ul

Începem cu un design simplu pentru o componentă text și media - ceva destul de des întâlnit pe paginile de destinație ale produselor. Este alcătuit dintr-o imagine sau un videoclip în stânga și o coloană în dreapta care conține un titlu, un paragraf de text și un link pentru îndemn. Acest design este pentru un startup (fictiv) care îi ajută pe cei care doresc să învețe o nouă abilitate să găsească un tutore.

Notă: Dacă doriți să săriți direct la cod și să vedeți toate soluțiile posibile la care am apelat pentru această componentă, îl puteți găsi în acest demo Codepen.

Aspect și ordine

Designerul a stipulat că toate celelalte componente ar trebui să aibă aspectul inversat, astfel încât imaginea să fie în dreapta și coloana de text în stânga.

În aspectul mobil, însă, imaginea este stivuită deasupra conținutului textului în toate cazurile. Presupunând că construim acest aspect folosind fie Grid, fie flexbox, am putea folosi flex-direction sau proprietatea order pentru a reordona aspectul pentru fiecare a doua componentă:

 .text-and-media:nth-child(even) { flex-direction: row-reverse; }

Merită să rețineți că, deși acestea vor reordona conținutul vizual, nu schimbă ordinea DOM. Aceasta înseamnă că pentru o persoană cu vedere parțială care navighează pe site folosind un cititor de ecran, ordinea conținutului poate să nu pară logică, sărind de la stânga la dreapta la dreapta la stânga.

Personal vorbind, în cazul în care singurul conținut dintr-una dintre coloane este o imagine, consider că folosirea proprietății order este mai mult sau mai puțin ok. Dar dacă am avea două coloane de text, de exemplu, reordonarea cu CSS ar putea crea o experiență confuză. În aceste cazuri, avem și alte opțiuni disponibile. Am putea:

1. Expuneți preocupările noastre privind accesibilitatea și recomandăm ca, pentru aspectele mobile, ordinea vizuală să fie schimbată pentru a se potrivi cu ordinea desktopului.
2. Utilizați Javascript pentru a reordona elementele din DOM.

De asemenea, trebuie să luăm în considerare dacă să aplicăm ordinul prin selectorul :nth-child sau să permitem clientului să controleze comanda (prin adăugarea unei clase la componentă, de exemplu). Adecvarea fiecărei opțiuni va depinde probabil de proiect.

Faceți față cu diferite lungimi de conținut

În design, proporția conținutului textului în comparație cu imaginea este destul de plăcută. Permite imaginii să mențină un raport de aspect ideal. Dar ce ar trebui să se întâmple dacă textul este mai lung sau mai scurt decât ceea ce este prezentat? Să ne ocupăm mai întâi de primul.

Conținut mai lung

Putem seta o limită de caractere pe câmpul de text din CMS-ul ales (dacă suntem atât de înclinați), dar ar trebui să permitem cel puțin o anumită variație în componenta noastră. Dacă adăugăm un paragraf mai lung, coloana media opusă se poate comporta într-unul din mai multe moduri:

1. Imaginea sau videoclipul rămâne în partea de sus, în timp ce spațiul este adăugat mai jos (fig. 1).
2. Imaginea sau videoclipul este centrat, adăugând spațiu în partea de sus sau de jos (fig. 2).
3. Proporțiile imaginii sau ale videoclipului sunt scalate pentru a se potrivi cu înălțimea, utilizând object-fit: cover pentru a preveni distorsiunile și pentru a se asigura că imaginea umple spațiul disponibil. Aceasta ar însemna că unele părți ale imaginii pot fi tăiate (fig. 3).

Am decis că opțiunea 3 a fost cea mai plăcută din punct de vedere vizual și că, în cea mai mare parte, autorii de conținut ar putea să obțină imagini adecvate în care o cantitate mică de tăiere ar fi acceptabilă. Dar a reprezentat mai mult o provocare pentru conținutul video, unde există mai mult riscul ca părțile importante să fie tăiate. Am apelat la o altă opțiune, care a fost să creăm o variantă diferită a designului, în care videoclipul să-și mențină raportul de aspect original și să fie conținut într-o lățime maximă în loc să se alinieze la marginea paginii.

Autorii de conținut puteau alege această opțiune atunci când se potrivea mai bine nevoilor lor.

În plus, am ales să extindem această opțiune la cazurile în care a fost folosită o imagine în loc de un videoclip. Oferă clientului o varietate mai mare de opțiuni de aspect, fără a afecta negativ designul. Văzut în contextul mai larg al paginii, ar putea fi considerat chiar o îmbunătățire, permițând pagini mai interesante atunci când mai multe dintre aceste blocuri sunt folosite pe o pagină.

Conținut mai scurt

Tratarea cu mai puțin conținut este puțin mai simplă, dar totuși ne prezintă unele probleme. Cum ar trebui să se comporte imaginea când conținutul textului este mai scurt? Ar trebui să devină mai puțin adânc, astfel încât înălțimea totală a componentei să fie determinată de conținutul textului (fig. 4)? Sau ar trebui să setăm un raport de aspect minim, astfel încât imaginea să nu devină cutie scrisă sau să permitem imaginii să-și preia înălțimea naturală, intrinsecă? În acest caz, avem de asemenea în considerare dacă să aliniem textul central sau în partea de sus (fig. 5 și 5a).

Lungimea titlului

Să nu uităm că va trebui să testăm și titluri de lungimi diferite. În design, titlurile sunt scurte și rapide, rareori înfășurate pe o a doua linie. Dar ce se întâmplă dacă un titlu are mai multe rânduri sau conținutul folosește o mulțime de cuvinte lungi, ceea ce duce la o împachetare diferită a textului? Aceasta ar putea fi o problemă în special în limbi precum germana, unde cuvintele tind să fie mult mai lungi decât engleza, de exemplu. Dimensiunea fontului de titlu din design permite o lungime adecvată a liniei atunci când este utilizat în acest aspect? Cuvintele lungi ar trebui să fie întrerupte cu cratimă atunci când se împachetează? Acest articol al lui Ahmad Shadeed abordează problema lungimii conținutului și a inclus câteva sfaturi utile pentru modalități de a rezolva problema în CSS.

Au autorii de conținut permis să omite cu totul un titlu acolo unde le convine? Asta ne duce la următoarea considerație.

Omiterea Conținutului

Construirea acestei componente într-un mod cât mai flexibil posibil înseamnă să vă asigurați că autorii de conținut pot omite anumite câmpuri și au în continuare aspectul și funcționarea corectă a designului. Pare rezonabil ca clientul să dorească să omite textul corpului, linkul sau chiar titlul atunci când folosește această componentă în sălbăticie. Trebuie să avem grijă să testăm cu fiecare combinație imaginabilă de conținut, astfel încât să putem fi siguri că componenta noastră nu se va rupe sub stres. Este o practică bună să ne asigurăm că nu redăm etichete HTML goale atunci când conținutul câmpului nu este prezent. Acest lucru ne va ajuta să evităm erorile neprevăzute de aspect.

Putem restricționa autorii de conținut cu câmpuri „obligatorii” în CMS, dar poate că am dori, de asemenea, să luăm în considerare scenarii în care un client ar putea alege să omite imaginea sau, dimpotrivă, fără conținutul textului? Ar putea fi util să le oferiți aceste opțiuni. Iată un exemplu despre cum am putea alege să redăm componenta în acele cazuri:

Prin indentarea puțin mai mult a textului și creșterea lățimii corpului textului, îl putem menține echilibrat, chiar și atunci când nu există nicio imagine.

Link-uri multiple

Omiterea conținutului este un scenariu. Dar la Atomic Smash, am descoperit că, mai des, clienții doreau opțiunea de a adăuga mai mult de un link la componentă. Asta ne prezintă o altă alegere: cum să dispunem mai multe link-uri? Le așezăm unul lângă altul (fig. 8) sau le stivuim vertical (fig. 8a)?

Cum ne descurcăm cu titlurile de linkuri de lungimi extrem de diferite? Un truc frumos este să setați lățimile ambelor legături la lățimea maximă a celei mai lungi (fig. 9). (Acest articol acoperă tocmai asta.) Acest lucru funcționează bine pentru butoanele stivuite vertical, în timp ce așezarea lor orizontală ne oferă și mai multe opțiuni (fig. 9a).

Avem nevoie de un stil de link secundar, pentru a le diferenția? Toate acestea sunt întrebări de luat în considerare.

De asemenea, ar putea fi nevoie să luăm în considerare (în cazul unui singur link) dacă, de fapt, zona pe care se poate face clic a linkului ar trebui să cuprindă întreaga componentă - astfel încât utilizatorii să poată face clic oriunde pe ea pentru a activa linkul. Această alegere ar putea depinde de contextul mai larg. Este cu siguranță obișnuit în interfețele de utilizator bazate pe carduri.

Video

Când componenta este folosită pentru video, mai degrabă decât pentru o imagine statică, am putea observa că designul omite unele informații cheie. Cum este controlată redarea video? La hover? Se redă automat pe scroll? Ar trebui să existe controale vizibile pentru utilizator?

Dacă videoclipul este redat cu mouse-ul, trebuie să luăm în considerare modul în care utilizatorul unui dispozitiv fără capacități de hover accesează conținutul video. În mod alternativ, dacă videoclipul se redă automat, ar trebui să luăm în considerare prevenirea acestui lucru pentru utilizatorii cu preferință pentru mișcare redusă, care pot suferi de tulburări vestibulare (sau ar putea dori pur și simplu să evite animațiile șocante). De asemenea, ar trebui să oferim o modalitate pentru toți utilizatorii de a opri videoclipul atunci când doresc.

Punându-l în context

O problemă legată de concentrarea atât de atent pe componente atunci când vine vorba de design web, este că uneori uităm să luăm în considerare modul în care componentele pe care le construim vor apărea în contextul întregii pagini web. Va trebui să luăm în considerare distanța, atât între componentele de același tip, cât și într-un aspect de pagină în care sunt intercalate alte componente.

Aceste componente text și media sunt concepute pentru a fi utilizate cu moderație, creând o pată de culoare atrăgătoare și o întrerupere față de un aspect altfel liniar. Dar folosind WordPress, un autor de conținut ar putea decide cu ușurință să construiască o pagină întreagă formată din nimic altceva decât aceste componente. Acest lucru ar putea ajunge să arate destul de plictisitor și deloc efectul pe care îl speram!

În timpul procesului de construire, am decis să adăugăm o opțiune pentru a omite culoarea de fundal. Acest lucru ne permite să despărțim pagina și să o facem mai interesantă:

Am putea fie să impunem un model folosind :nth-child fie să adăugăm un câmp în CMS pentru a oferi clientului mai mult control creativ.

Deși acest lucru nu făcea parte din designul original, arată că o linie deschisă de comunicare între designer și dezvoltator poate ajuta la crearea unor rezultate mai bune în ceea ce privește modelele mai flexibile și mai robuste.

Stiluri de text WYSIWYG

Când luăm în considerare conținutul, trebuie să luăm în considerare nu doar lungimea textului, ci și elementele HTML reale care ar putea fi permise în câmpul textului. Autorii de conținut ar putea dori să adauge mai multe paragrafe, link-uri de ancorare, liste și multe altele la copierea corpului. La Atomic Smash ne place să oferim un câmp WYSIWYG (What You See Is What You Get) sau un câmp de text îmbogățit pentru aceste zone, care poate permite multe elemente diferite. Este important să testați cu diferite tipuri de conținut și să stilați corespunzător, inclusiv testarea pentru un contrast suficient de culoare pe toate culorile de fundal utilizate.

Încheierea

Am atins multe decizii diferite implicate în construirea acestei componente aparent simple. S-ar putea chiar să vă gândiți la câteva altele pe care nu le-am acoperit aici! Luând în considerare fiecare aspect al designului și modul în care ar putea fi folosit în context, am ajuns să obținem ceva mult mai versatil, care sperăm că ar trebui să aibă ca rezultat clienți mai fericiți!

Uneori, cu cât este omis mai mult dintr-un design, cu atât mai mult timp și atenție vor fi necesare de la un dezvoltator. Am alcătuit mai jos o listă de verificare cu lucruri de testat și pus la îndoială atunci când construiești o componentă, pe care s-ar putea să-l consideri utile. Poate fi adaptat și pentru diferite componente.

Capacitatea de a privi dincolo de simplitatea aparentă, de a împărți o componentă în părțile sale constitutive, de a pune întrebări cheie (chiar înainte de a avea loc orice dezvoltare) și chiar de a lua în considerare utilizările viitoare, sunt toate abilitățile care vor fi de folos oricărui dezvoltator atunci când construiește site-uri web - și vă va ajuta să furnizați estimări mult mai precise atunci când este necesar. O bună comunicare în echipă și un proces puternic de colaborare sunt de neprețuit pentru construirea de site-uri rezistente, dar rezultatul final face ca merită să investim în dezvoltarea acestei culturi. Să integrăm flexibilitatea în procesele noastre de proiectare și construcție.

Lista de verificare

Lucruri de testat:

1. Accesibilitatea aspectului (mobil și desktop).
2. Imaginile cu diferite raporturi de aspect intrinseci - sunt decupate corespunzător?
3. Corpul textului mai lung și mai scurt (inclusiv mai multe paragrafe).
4. Titlu mai lung și mai scurt (inclusiv diferite lungimi de cuvinte).
5. Omițând (divers) titlul, corpul textului, linkurile și imaginea.
6. Link-uri multiple (inclusiv lungimi diferite ale textului linkului).
7. Accesibilitatea conținutului video.
8. Conținut text WYSIWYG (include link-uri, liste etc. în corpul textului).
9. Testați în context - includeți mai multe componente (cu opțiuni de conținut diferite), precum și alte componente amestecate în aspectul paginii.