La modifica completa del sito atterrerà in WordPress 5.8? Una decisione è imminente

Ieri, Josepha Haden Chomphosy ha annunciato la tabella di marcia per decidere se Full Site Editing (FSE) arriverà su WordPress 5.8. Dopo il lancio di Gutenberg 10.4 il 14 aprile, un piccolo gruppo di lead principali parteciperà a una demo go/no-go.

Parteciperanno alla chiamata le seguenti persone:

• Matias Ventura – Gutenberg Project Lead che ospiterà la demo.
• Matt Mullenweg – Responsabile del progetto WordPress.
• Helen Hou-Sandi – Sviluppatore capo.
• Josepha Haden Chomphosy – Direttore Esecutivo.

L'agenda dell'incontro è semplice. Ventura ospiterà la demo e il gruppo discuterà e tratterà le questioni di implementazione.

Se non ci sono blocchi, condivideranno un piano per unire FSE in WordPress. Il risultato più probabile è che troveranno almeno alcuni elementi che devono essere affrontati. In tal caso, li condivideranno pubblicamente con un piano per affrontarli prima di una seconda data di accesso/non utilizzo del 27 aprile.

La prima versione beta di WordPress 5.8 è fissata per l'8 giugno, con una versione pubblica per il 20 luglio. Il team deve decidere se includerlo all'inizio del ciclo di rilascio per dare agli sviluppatori di temi e plugin il tempo di prepararsi.

Mentre molti sono in punta di piedi in attesa di una decisione finale, tutti hanno bisogno di avere un po' di pazienza in questo momento. Tutto deve essere attentamente soppesato dai capi progetto. Ci sono buone probabilità che non conosceremo l'esito fino a quella seconda scadenza del 27 aprile.

La maggior parte della transizione FSE sarebbe una versione beta per gli utenti di un sottoinsieme. Includere queste funzionalità nel core non significa che WordPress capovolga immediatamente l'interruttore e abiliti tutto per il 40% del web. Per l'esperienza complessiva di FSE, gli utenti devono scegliere esplicitamente di installare e attivare un tema basato su blocchi.

Con questo in mente, l'esperienza di onboarding dovrebbe essere un'esperienza accogliente che invita gli utenti a modificare il sito mentre fa loro conoscere i potenziali problemi. Se si tratta di una versione beta integrata, devono davvero capire che i miglioramenti sono imminenti.

Anche una versione beta in-core come questa è benvenuta, dato il lancio del progetto dell'editor di blocchi un paio di anni fa. Indipendentemente dal fatto che le persone amassero o odiassero l'editor di blocchi, il lancio non è stato facile per tutti. WordPress ha portato gli utenti finali in un sistema revisionato, il che è stato un cambiamento scioccante per molti. Il progetto ha la possibilità di fare meglio questa volta introducendo in modo incrementale funzionalità agli utenti e consentendo ad altri di immergersi nella nuova esperienza di loro scelta.

"Il contesto più importante da condividere è che non viene distribuito come l'esperienza predefinita completa per gli utenti ", ha scritto Chomphosy nel post, osservando che il team sta crescendo oltre gli errori del passato. "Uno dei feedback più chiari dal processo di unione di Phase One è stato che non c'era abbastanza tempo per i nostri extender (agenzie, autori di temi, sviluppatori di plug-in, costruttori di siti, ecc.) Per prepararsi alle modifiche imminenti".

I decisori possono anche decidere di spedire alcuni pezzi ma non altri. FSE è un progetto composto da più componenti.

"L'intero progetto di editing del sito è una sorta di termine generico per una raccolta di strumenti e progetti, quindi sarebbe possibile che alcuni pezzi vengano spediti mentre altri no", ha affermato Haden Chomphosy. "Probabilmente ci sono alcune eccezioni, come hai detto, ma molti di questi possono essere spediti quando sono pronti."

Le eccezioni a cui si riferiva sono componenti che insieme hanno più senso. Ad esempio, i temi basati su blocchi tramite un file di configurazione theme.json e la maggior parte dei blocchi di modifica del sito non sono così utili se separati.

Naturalmente, ci sono casi in cui qualcosa come il blocco Query potrebbe essere utilizzato al di fuori dell'editor del sito. Gli utenti potrebbero creare query personalizzate all'interno di una pagina senza il vantaggio dell'editor del sito, ad esempio.

La mia preoccupazione principale non riguarda le funzionalità relative all'editor del sito, ma i widget basati su blocchi. È uno strumento di transizione per gli utenti su temi tradizionali. Insieme alla nuova schermata dei menu di navigazione, non fa parte dell'esperienza dei temi basati su blocchi. L'obiettivo è consentire agli utenti di iniziare a utilizzare i blocchi in più punti. Tuttavia, ciò si tradurrà in un'esperienza utente interrotta in molti casi.

L'esperienza dei widget è ancora parzialmente interrotta, trattando ogni blocco come un widget separato. Gli utenti devono imparare a inserire un'intestazione (titolo del widget) e un altro blocco (contenuto del widget) in un gruppo (wrapper del widget) per le classi corrette relative ai widget sul front-end del sito. Per alcuni temi, se gli utenti lo fanno non sarà un problema. Per altri, nel migliore dei casi sembrerà brutto e nel peggiore dei casi interromperà il layout. Mettere questa responsabilità sulle spalle degli utenti finali è stata considerata una soluzione accettabile.

Volevo concentrarmi su questo problema perché è una di quelle cose che possono essere semplicemente capovolte per tutti gli utenti. Ho ancora paura che il passaggio da un sistema funzionante a uno potenzialmente rotto possa rendere la corsa accidentata.

Il team di rilascio di WordPress 5.6 ha deciso di non spedire widget basati su blocchi. Hou-Sandi, in qualità di core tech lead per 5.6, ha fornito un resoconto storico della decisione e del motivo per cui non era pronta per l'inclusione:

La mia domanda per le funzionalità che influiscono sul front-end è "posso provare questa nuova cosa senza la penalità di rovinare il mio sito?" — ovvero la fiducia degli utenti. In questo momento, dato che le aree dei widget non vengono visualizzate per niente come quelle che vedi sul tuo sito senza che i temi ci mettano davvero impegno e che devi salvare le modifiche in tempo reale senza revisioni per ottenere una visualizzazione contestuale effettiva, i blocchi delle aree dei widget non lo fanno permetterti di provare questa nuova funzionalità senza penalizzarti per la sperimentazione.

Sebbene i widget siano probabilmente migliorati, vedo ancora la risposta come la stessa dello scorso ottobre. Non ho visto abbastanza buy-in dalla comunità di sviluppo dei temi per supportare l'editor di blocchi stesso, tanto meno nuove funzionalità relative ai blocchi. Tuttavia, a un certo punto, il progetto deve semplicemente andare avanti. I soggetti dovranno solo tenere il passo.