Renașterea fără cod pentru web designeri

Publicat: 2022-03-10
Rezumat rapid ↬ La fel ca în perioada Renașterii, trăim vremuri de inovații culturale și artistice incredibile. Pe măsură ce Internetul evoluează, browserele se aliniază, capacitățile sunt adăugate și accesibilitatea tehnologiei devine mai ușoară, designerii se confruntă cu noi oportunități de a crea, gândi și schimba statutul cu instrumente fără cod.

Cuvântul Renaștere – care înseamnă „renaștere” în franceză – a fost dat unei perioade extraordinare de realizări filozofice și artistice care a început în secolul al XIV-lea.

În acest timp, au existat o gamă largă de evoluții, printre care:

  • Utilizarea vopselelor în ulei, mai degrabă decât tempera, ceea ce a făcut procesul de vopsire mai ușor.
  • Utilizarea țesăturii, mai degrabă decât a plăcilor de lemn, ceea ce a redus cheltuielile de pictură.
  • Traducerea textelor clasice în arhitectură, anatomie, filozofie și multe altele, făcând cunoștințele mai accesibile publicului larg.

Aceste evoluții și multe altele au făcut din Renaștere una dintre cele mai productive ere artistice din istorie, reducând dramatic bariera creativă și atrăgând un public numeros, mai degrabă decât doar un grup mic de elite.

Bloc de piatră
„Fiecare bloc de piatră are o statuie înăuntru și este sarcina sculptorului să o descopere”. — Michelangelo. Unii oameni văd un bloc de piatră, în timp ce alții văd o sursă de creație. Instrumentele disponibile în orice moment ne pot scoate în evidență potențialul maxim. (Previzualizare mare)

La fel ca în epoca Renașterii, domeniul web design-ului de astăzi își explorează potențialul prin intermediul platformelor de dezvoltare fără cod (NCDP). Aceste instrumente permit non-programatorilor să creeze aplicații software prin interfețe grafice de utilizator și configurare, în loc de programarea tradițională a computerului.

Modelul mental de proiectant/dezvoltator

Un colaj realist cu o sculptură 3D care ține un fulger în mâna stângă și becuri în mâna dreaptă
Preluat din „The Singularity Is Here: Human 2.0” de Amit Maman. Parte a proiectului său final de la Colegiul de Inginerie și Design Shenkar, Maman a creat acest triptic pentru a-și arăta viziunea asupra singularității și a punctului de cotitură din istoria umanității pe care îl reprezintă. Opera sa este inspirată de principii din epoca Renașterii. (Previzualizare mare)

În 2000, expertul în uzabilitate Jakob Nielsen a introdus „Legea lui Jakob”, ideea că utilizatorii dezvoltă modele mentale ale produselor cu care interacționează pe baza experienței lor anterioare. Cu cât utilizatorii se pot concentra mai mult asupra obiectivului lor fără a contesta acest model mental, cu atât le este mai ușor să atingă acel obiectiv.

„CSS este mai aproape de pictură decât Python.”
— Chris Coyier, co-fondator la CodePen

Abilitățile de proiectare și dezvoltare sunt înrădăcinate în diferite tipuri de gândire și necesită diferite tipuri de instrumente. În timp ce designerii folosesc editori WYSIWYG precum Figma, Sketch și Photoshop pentru a plasa elemente pe pânză, dezvoltatorii lucrează cu IDE-uri precum VSCode, Webstorm și Brackets. Pentru a rămâne productivi, designerii și dezvoltatorii trebuie să poată face modificări și să primească feedback instantaneu, conform modelului lor mental.

Așadar, folosirea generatorilor de tragere și plasare poate interfera de fapt cu dezvoltatorii care doresc să depaneze rapid, dar lucrul numai cu un editor de text poate fi inadecvat pentru designerii care doresc să testeze compoziția.

Mai multe după săritură! Continuați să citiți mai jos ↓

Designeri și cod

Mulți designeri înțeleg diferențele funcționale dintre o machetă și un produs funcțional. Pentru a înțelege posibilitățile mediului, unde să tragă limitele și cum să facă față constrângerilor, mulți designeri sunt dispuși să „murdărească mâinile” atunci când vine vorba de învățarea codului - dar au dificultăți.

Unul dintre principalele motive pentru care designerii nu sunt programatori este că există un decalaj mare între modelul mental al designerului și modelul conceptual al multor editori de cod. Proiectarea și dezvoltarea necesită două moduri de gândire foarte diferite. Această nepotrivire duce la o curbă de învățare dificilă și frustrantă pentru designeri, pe care s-ar putea să nu o depășească.

Abstracția codului

Un colaj realist cu o sculptură 3D care zdrobește apa
(Previzualizare mare)

Abstracția este un concept de bază al informaticii. Limbajele, cadrele și bibliotecile sunt construite pe diferite straturi de abstractizare de complexitate pentru a facilita, optimiza și garanta productivitatea.

„Uneltele de programare vizuală abstrac codul de la creator, făcându-le semnificativ mai accesibile. Cu toate acestea, adevărata magie a acestor instrumente este modul în care integrează toate straturile de software subiacente în produsele finale, oferind funcționalități utile prin componente modulare care pot fi valorificate prin interfețe vizuale intuitive.”
— Jeremy Q. Ho, Niciun cod nu este o programare nouă

Când lucrați cu straturi de abstractizare, există instrumente precum Editor X și Studio pentru site-uri web/aplicații web, Draftbit și Kodika pentru aplicații mobile și Modulz pentru sisteme de proiectare, care permit o reprezentare vizuală a codului, pe lângă capabilitățile de cod.

Prin adoptarea unui mediu vizual familiar, curba de învățare devine mai ușoară pentru designeri.

Dacă Chris Wanstrath, co-fondatorul și fostul CEO al GitHub, a spus: „Viitorul codării nu este deloc codificare”, atunci cu siguranță fără cod este o modalitate legitimă de dezvoltare - în ciuda percepției că aceste instrumente nu oferă flexibilitatea. pentru a scrie propriul cod, rând cu linie.

Într-adevăr, vedem că interesul pentru termenul „nocode” este în creștere:

O captură de ecran a Google Trends
Căutați termenul „nocode” în ultimii 5 ani pe Google Trends. (Previzualizare mare)

Diferența dintre programarea imperativă și declarativă

Pentru a înțelege dezvoltarea instrumentelor fără cod pentru designeri, trebuie să cunoașteți distincția dintre două tipuri de programare:

  1. Programare imperativă
    Deconstruiți rezultatul într-o secvență de imperative, adică fluxul de control explicit. De exemplu: JavaScript, Python, C++.
  2. Programare declarativă
    Declarați rezultatul, adică fluxul de control implicit. De exemplu: SQL, HTML, CSS.

Limbile declarative sunt adesea limbi specifice domeniului, sau DSL, ceea ce înseamnă că sunt folosite într-un anumit scop, într-un anumit domeniu.

De exemplu, SQL este DSL pentru lucrul cu baze de date, HTML este DSL pentru adăugarea de structură semantică și semnificație la conținutul unei pagini web, iar CSS este DSL pentru adăugarea de stil.

„Sunt prea multe variabile de luat în considerare. Scopul CSS este să-l faci astfel încât să nu fii nevoit să-ți faci griji pentru toate. Definiți unele constrângeri. Lasă limbajul să rezolve detaliile.”
— Keith J. Grant, Resilient, Declarative, Contextual

Programarea imperativă setează browserului instrucțiuni specifice, pas cu pas, pentru a obține rezultatul dorit, în timp ce programarea declarativă afirmă rezultatul dorit, iar browserul își face treaba singur.

Evul Mediu

Efortul de a crea un instrument de interfață vizuală pentru dezvoltarea designului web a început în anii 1990 prin încercări inovatoare precum InContext Spider, Netscape Navigator Gold, Microsoft FrontPage și, desigur, Dreamweaver.

O captură de ecran cu Dreamweaver MX
Dreamweaver MX, Fundația Dreamweaver MX. (Previzualizare mare)

În această perioadă, terminologia comună includea: instrumentul de creație HTML vizual, compozitorul de pagini web WYSIWYG sau pur și simplu editor HTML . Termenul „fără cod” a fost popular în anii 1990 – dar dintr-un motiv diferit. În 1996, trupa rock americană Pearl Jam a lansat al patrulea album de studio, No Code .

Aceste instrumente fără cod au redus dramatic bariera creativă și au atras un public larg, Internetul nu era pregătit pentru aceste tipuri de instrumente la momentul respectiv.

Acest efort a fost limitat din următoarele motive:

1. Aspect

Când inventatorul World Wide Web Tim Berners-Lee și-a lansat creația în 1989, el nu a oferit o modalitate de a proiecta un site web.

Acest lucru a apărut în octombrie 1994, după o serie de sugestii despre cum să proiectați internetul de către diferiți oameni - inclusiv unul de la Hakon Wium Lie - care au propus o idee care a atras atenția tuturor. Lie credea într-un stil declarativ care ar permite browserelor să se ocupe de procesare - se numea Cascading Style Sheets sau pur și simplu CSS.

„CSS s-a remarcat pentru că era simplu, mai ales în comparație cu unii dintre primii concurenți ai săi.”
— Jason Hoffman, O privire înapoi la istoria CSS

Multă vreme după aceea, CSS a oferit soluții de proiectare pentru un singur obiect, dar nu a dat un răspuns adecvat relației dintre obiecte.

Metodele de a rezolva acest lucru au fost efectiv hack-uri și nu au fost capabili să facă față unei mari complexități. Pe măsură ce site-urile au evoluat de la documente simple la aplicații complexe, machetele web au devenit dificil de asamblat. În loc să folosească un stil într-un mod declarativ așa cum l-a conceput Lie, dezvoltatorii web au fost forțați să folosească programarea imperativă.

Un sistem de grile bazat pe regulile designerului elvețian Josef Muller-Brockmann, care era obișnuit în tipărire din anii 1940, pare un vis îndepărtat când luăm în considerare orice este legat de Web.

Trei postere de Josef Muller-Brockmann
Afișe de Josef Muller-Brockmann. (Previzualizare mare)

Din cauza acestor limitări de aspect, platformele fără cod au fost forțate să adauge un strat abstract pentru a efectua calcule în culise. Acest strat cauzează o serie de probleme, inclusiv pierderea valorii semantice a obiectelor, probleme de performanță, cod voluminos, o curbă complexă de învățare, nescalabilitate și probleme de accesibilitate.

2. Alinierea browserului

În primele zile, producătorii de browsere au fost cei care au decis cum să construiască internetul. Acest lucru a făcut ca Web-ul să devină o marfă manipulativă. Concurența dintre browsere a dus la „funcții de design” unice. Acest lucru a forțat nevoia de a reconstrui același site de mai multe ori, astfel încât să poată fi accesat din mai multe browsere.

„Dezvoltatorii din anii 90 ar trebui adesea să creeze trei sau patru versiuni ale fiecărui site web pe care l-au construit, astfel încât să fie compatibil cu fiecare dintre browserele disponibile la momentul respectiv”.
— Amy Dickens, Standardele Web: Ce, De ce și Cum

Pentru a compensa nevoia de a construi site-uri web care să se potrivească cu anumite browsere, comunitatea World Wide Web Consortium (WC3) a fost înființată la MIT în 1994. WC3 este o comunitate internațională care lucrează pentru a dezvolta standarde web funcționale, accesibile și intercompatibile.

Când au fost introduse standardele, producătorii de browsere au fost încurajați să respecte un singur mod de a face lucrurile - împiedicând astfel construirea mai multor versiuni ale aceluiași site. În ciuda recomandărilor WC3, a durat mult timp pentru ca browserele să îndeplinească aceleași standarde.

Din cauza lipsei de aliniere între browsere (Internet Explorer, mă uit la tine), CSS pentru un timp a fost blocat și nu au fost adăugate capacități noi. Odată ce un limbaj declarativ nu acceptă ceva, este nevoie să vă bazați pe tot felul de hack-uri imperative pentru a atinge acest obiectiv.

3. Legarea datelor

În primii ani ai Web-ului, site-urile au fost dezvoltate ca o colecție de pagini statice fără sens semantic. Când a sosit Web-ul 2.0, a primit descrierea „web-ul ca platformă”, ceea ce a dus la o schimbare semnificativă – paginile aveau conținut dinamic, care a afectat conexiunea la date și, desigur, sensul semantic.

„Site-urile din anii 1990 erau, de obicei, fie broșuri (pagini HTML statice cu conținut insipid), fie erau interactive într-un fel sclipitor, animat, JavaScript.”
— Joshua Porter, Web 2.0 pentru designeri

Într-adevăr, conectarea la date folosind o abordare fără cod a existat de mult timp - dar experiența utilizatorului a fost dificilă. În plus, trecerea la marcarea semantică, astfel încât conținutul să poată fi detectat în instrumentele fără cod, a fost dificilă din cauza amestecului dintre programarea declarativă și imperativă.

Instrumentele fără cod nu se potriveau cu acele sarcini de bază.

Un colaj realist cu un televizor vechi 3D cu ecran cu probleme
(Previzualizare mare)

Proto-Renaștere

Pe 29 iunie 2007, natura Internetului a fost schimbată dramatic. Aceasta a fost ziua în care Steve Jobs a introdus iPhone - o combinație de telefon mobil și player media care se conectează la Internet și permite navigarea multi-touch.

Când iPhone-ul a fost introdus în 2007, a fost un punct de cotitură pentru web design. Dintr-o dată, designerii web au pierdut controlul asupra pânzei pe care am proiectat site-urile web. Anterior, site-urile web trebuiau să funcționeze doar pe ecrane de monitor, care variau ca dimensiune, dar nu atât de mult. Cum ar fi trebuit să facem site-urile noastre să funcționeze pe aceste mici ecrane?
— Clarissa Peterson, Learning Responsive Web Design

Acest lucru a creat noi provocări pentru dezvoltarea designului web. În principal, cum să construiți un site care poate fi utilizat pe mai multe tipuri de dispozitive. Multe abordări „hack” ale designului de layout pur și simplu s-au destramat – au cauzat mai multe probleme decât au rezolvat.

Totul trebuia reevaluat.

Renașterea fără cod

O pereche de statui plutind în aer în timp ce se îmbrățișează
(Previzualizare mare)

Browserele care acceptă standardele WC3 (Chrome și Firefox) au astăzi o cotă de piață uriașă, ceea ce a determinat mai multe browsere să accepte standardele. Faptul că toate browserele acceptă același standard, permit alinierea în construirea site-urilor și asigură că aceste capabilități vor continua să funcționeze pe măsură ce standardele și browserele evoluează.

Metode precum interogare media, flexbox și grid - care sunt disponibile nativ în browsere pentru designul aspectului - au deschis calea pentru machete flexibile, chiar și atunci când dimensiunile elementelor sunt dinamice.

„Când CSS Grid a fost expediat în martie 2017, cutia noastră de instrumente a atins un punct critic. În cele din urmă, avem o tehnologie suficient de puternică pentru a ne permite să fim cu adevărat creativi cu aspectul. Putem folosi puterea designului grafic pentru a transmite sens prin utilizarea aspectului – creând machete unice pentru fiecare proiect, fiecare secțiune, fiecare tip de conținut, fiecare pagină.”
— Rachel Andrew, Noul aspect CSS

În acest fel, HTML a devenit mai curat și și-a putut atinge scopul inițial: o descriere semantică a conținutului.

În cele din urmă, datorită alinierii dintre browsere și noilor capabilități, instrumentele fără cod sunt susținute de o tehnologie puternică și uniformă. Aceste modificări au creat o distincție mai clară între declarativ și imperativ. Au fost create noi posibilități pentru a rezolva probleme vechi.

„Simplitatea este sofisticarea supremă.”
— Leonardo da Vinci

Efectul fără cod asupra designerilor

O captură de ecran a Editor X în modul de editare
Editor X | Fotografia lui David de Igor Ferreira pe Unsplash. (Previzualizare mare)

Evoluțiile internetului de-a lungul anilor au condus la o situație în care abstracția dintre design și cod se îmbunătățește constant. Acest lucru are implicații asupra modului în care designerii web își planifică și implementează design-urile.

1. Planificarea proiectării

În timp ce instrumentele de design populare utilizează conținut static pentru design web dinamic, instrumentele fără cod le permit designerilor să lucreze cu propriile materiale web.

„Photoshop este cel mai eficient mod de a le arăta clienților tăi cum nu va arăta niciodată site-ul lor.”
— Stephen Hay, autorul cărții Responsive Design Workflow

Dacă avem un design complex cu diferite stări, micro-interacțiuni, animații și puncte de întrerupere receptive — folosind instrumente fără cod, putem lucra într-un mod mai tangibil.

În plus, dezvoltarea web-ului permite instrumentelor fără cod să separe în mod clar conținutul de design (ceea ce permite designerilor să gestioneze vizual conținutul real). Reflectarea conținutului dinamic în design (de exemplu, text, imagini, videoclipuri și audio), oferă designerilor o înțelegere mai clară a modului în care va apărea.

Avantajul lucrului în spațiul de lucru fără cod este că interacțiunile apar imediat. Acest lucru le permite designerilor să-și testeze rapid alegerile de design și să vadă dacă funcționează.

2. Implementarea Proiectului

După ce au investit în perfecțiunea designului, designerii ar trebui să explice dezvoltatorilor deciziile vizuale și conceptuale prin intermediul prototipurilor. Prototipurile nu necesită doar timp în ceea ce privește pregătirea, dar și designul lor este adesea implementat incorect din cauza interpretărilor greșite.

Cu instrumente fără cod, designerii pot plasa obiecte pe afișajul lor și pot gestiona vizibilitatea și comportamentul acestora cu ușurință și rapiditate. Cu alte cuvinte, pot proiecta rezultatul final fără a depinde de nimeni altcineva.

Ca să mă folosesc ca exemplu, când a lovit pandemia de Coronavirus, am lucrat cu o echipă mică la un proiect pentru a ajuta la conectarea tinerilor voluntari cu seniori izolați. În doar trei zile, eu și un alt designer am creat site-ul web și am conectat datele de înregistrare a utilizatorilor la o bază de date, în timp ce dezvoltatorul echipei a lucrat pentru a integra datele de pe site într-o aplicație mobilă separată.

Efectul fără cod asupra dezvoltatorilor

Instrumentele fără cod vor înlocui complet dezvoltatorii? Răspunsul scurt: Nu. Schimbarea semnificativă este în modul în care designerii și dezvoltatorii pot lucra împreună pentru a crea site-uri web.

Pe lângă dezvoltarea CSS, Javascript a evoluat și în paralel și poate chiar mai mult. Ideea că dezvoltatorii frontend trebuie să controleze toate abilitățile nu are sens. Și totuși, dezvoltarea fără cod de-a lungul anilor a permis designerilor să-și construiască propriile design-uri.

Este o situație câștigătoare, în care dezvoltatorii se pot concentra pe dezvoltarea logicii, iar designerii au mai mult control asupra experienței utilizatorului și stilului.

Efortul nu este încă finalizat

Nu vreau să vă las cu impresia că designerii au libertate deplină de a proiecta cu instrumente fără cod. Încă lipsesc unele capabilități de stil pe care CSS nu le-a rezolvat încă și acestea necesită încă o dezvoltare imperativă.

Spre deosebire de Evul Mediu, unde arta era considerată artizanat fără o bază teoretică, evoluțiile renascentiste au schimbat statutul artistului - care a fost brusc considerat un polimat.

Instrumentele fără cod elimină blocajele, ceea ce le permite designerilor să câștige mai multă proprietate, influență și control asupra experiențelor pe care le proiectează.

Am parcurs un drum lung de la vremurile în care designerii nu puteau să-și dea viață design-urilor. Pe măsură ce Internetul evoluează, browserele se aliniază, capacitățile sunt adăugate și accesibilitatea tehnologiei devine mai ușoară – designerii se confruntă cu noi oportunități de a crea, gândi și schimba statutul cu instrumente fără cod.

Mișcarea fără cod nu afectează doar modul în care se fac lucrurile, ci și cine.

Credite : Yoav Avrahami și Jeremy Hoover au contribuit la acest articol.

Citiți suplimentare despre SmashingMag:

  • Ce ne poate învăța Vitruvius despre Web Design
  • Personalitatea divizată a dezvoltării web brutaliste
  • Ce ne pot învăța ziarele despre web design
  • Ce înseamnă de fapt un Web pliabil?