Editarea completă a site-ului va ajunge în WordPress 5.8? Urmează o decizie

Ieri, Josepha Haden Chomphosy a anunțat foaia de parcurs pentru a decide dacă Full Site Editing (FSE) va ajunge în WordPress 5.8. După lansarea lui Gutenberg 10.4 pe 14 aprilie, un grup mic de clienți potențiali de bază vor participa la o demonstrație go/no-go.

Următoarele persoane vor fi la apel:

• Matias Ventura – Director de proiect Gutenberg care va găzdui demonstrația.
• Matt Mullenweg – Conducător de proiect WordPress.
• Helen Hou-Sandi – Dezvoltator principal.
• Josepha Haden Chomphosy – Director executiv.

Ordinea de zi a ședinței este simplă. Ventura va găzdui demonstrația, iar grupul va discuta și va aborda întrebările de implementare.

Dacă nu există blocanți, aceștia vor împărtăși un plan pentru fuzionarea FSE în WordPress. Rezultatul cel mai probabil este că vor găsi cel puțin câteva elemente care trebuie abordate. În acest caz, ei le vor împărtăși în mod public cu un plan pentru a le aborda înainte de a doua dată de acces/nevoiat, 27 aprilie.

Prima lansare beta a WordPress 5.8 este stabilită pentru 8 iunie, cu o lansare publică generală pentru 20 iulie. Echipa trebuie să decidă cu privire la includerea la începutul ciclului de lansare pentru a oferi dezvoltatorilor de teme și pluginuri timp să se pregătească.

În timp ce mulți sunt pe picioarele lor așteaptă o decizie finală, toată lumea trebuie să aibă puțină răbdare în acest moment. Totul trebuie cântărit cu atenție de către liderii de proiect. Există șanse mari să nu știm rezultatul până la acel al doilea termen limită, 27 aprilie.

Cea mai mare parte a tranziției FSE ar fi o rulare beta pentru un subset de utilizatori. Includerea acestor funcții în nucleu nu înseamnă că WordPress comută imediat comutatorul și activează totul pentru 40% din web. Pentru experiența generală FSE, utilizatorii trebuie să facă o alegere explicită de a instala și activa o temă bazată pe blocuri.

Având în vedere acest lucru, experiența de integrare ar trebui să fie una primitoare, care să invite utilizatorii la editarea site-ului, anunțându-le în același timp potențialele probleme. Dacă este o versiune beta încorporată, ei chiar trebuie să înțeleagă că urmează îmbunătățiri.

O rulare beta in-core ca aceasta este de asemenea binevenită, având în vedere lansarea de către proiect a editorului de blocuri în urmă cu câțiva ani. Indiferent dacă oamenii au iubit sau au urât editorul de blocuri, lansarea nu a fost lină pentru toată lumea. WordPress a introdus utilizatorii finali într-un sistem revizuit, ceea ce a fost o schimbare șocantă pentru mulți. Proiectul are șansa de a face mai bine de data aceasta, introducând treptat funcții utilizatorilor și permițând altora să se cufunde în noua experiență la alegerea lor.

„Cel mai important context de împărtășit este că nu se livrează ca experiență completă, implicită pentru utilizatori ”, a scris Chomphosy în postare, menționând că echipa crește dincolo de greșelile trecute. „Una dintre cele mai clare elemente de feedback din procesul de îmbinare Faza 1 a fost că nu a existat suficient timp pentru ca extensiatorii noștri (agenții, autori de teme, dezvoltatori de pluginuri, constructori de site-uri etc.) să se pregătească pentru schimbările viitoare.”

Factorii de decizie pot decide, de asemenea, să expedieze unele piese, dar nu altele. FSE este un proiect format din mai multe componente.

„Întregul proiect de editare a site-ului este un fel de termen umbrelă pentru o colecție de instrumente și proiecte, așa că ar fi posibil ca unele piese să fie livrate, în timp ce altele nu”, a spus Haden Chomphosy. „Probabil că există câteva excepții de la asta, așa cum ați menționat, dar multe dintre acestea se pot expedia pe măsură ce sunt gata.”

Excepțiile la care se referea sunt componente care au mai mult sens împreună. De exemplu, temele bazate pe blocuri printr-un fișier de configurare theme.json și majoritatea blocurilor de editare a site-ului nu sunt la fel de utile atunci când sunt separate.

Desigur, există cazuri în care ceva de genul blocului Query ar putea fi folosit în afara editorului site-ului. Utilizatorii pot crea interogări personalizate într-o pagină fără beneficiul editorului de site, de exemplu.

Preocuparea mea principală nu este cu funcțiile legate de editorul site-ului, ci cu widget-urile bazate pe blocuri. Este un instrument de tranziție pentru utilizatorii pe teme tradiționale. Împreună cu noul ecran de meniuri de navigare, acesta nu face parte din experiența temelor bazate pe blocuri. Scopul este de a permite utilizatorilor să înceapă să folosească blocuri în mai multe locuri. Cu toate acestea, acest lucru va duce la o UX defectă în multe cazuri.

Experiența cu widget-uri este încă parțial întreruptă, tratând fiecare bloc ca pe un widget separat. Utilizatorii trebuie să învețe să pună un titlu (titlul widgetului) și un alt bloc (conținutul widgetului) într-un Grup (învelișul widgetului) pentru clasele corecte legate de widget-ul de pe partea frontală a site-ului. Pentru unele teme, dacă utilizatorii fac acest lucru nu va fi o problemă. Pentru alții, va arăta urât în ​​cel mai bun caz și va rupe aspectul în cel mai rău caz. Punerea acestei responsabilități pe umerii utilizatorilor finali a fost considerată o soluție acceptabilă.

Am vrut să mă concentrez pe această problemă, deoarece este unul dintre acele lucruri care pot fi pur și simplu răsturnate pentru toți utilizatorii. Încă mă tem că trecerea de la un sistem funcțional la unul potențial defect va face o călătorie accidentată.

Echipa de lansare WordPress 5.6 a decis să nu livreze widget-uri bazate pe blocuri. Hou-Sandi, în calitate de lider tehnologic de bază pentru 5.6, a oferit o prezentare istorică a deciziei și de ce nu era pregătită pentru includere:

Întrebarea mea pentru funcțiile care afectează front-end-ul este „pot să încerc acest lucru nou fără penalizarea de a-mi da peste cap site-ul?” — adică încrederea utilizatorilor. În acest moment, având în vedere că zonele widget nu sunt afișate nimic asemănător cu ceea ce vedeți pe site-ul dvs. fără ca temele să depună cu adevărat efort și că trebuie să salvați modificările live fără revizuiri pentru a obține o vizualizare contextuală reală, blocurile zonei widget nu vă permit să încercați această nouă funcție fără a vă penaliza pentru experimentare.

În timp ce widget-urile s-au îmbunătățit, în continuare văd răspunsul ca fiind același ca în octombrie anul trecut. Nu am văzut suficientă acceptare din partea comunității de dezvoltare a temelor pentru a sprijini editorul de blocuri în sine, cu atât mai puțin noi funcții legate de blocuri. Cu toate acestea, la un moment dat, proiectul trebuie pur și simplu să avanseze. Tematicii vor trebui doar să țină pasul.