Tra le altre cose questo blog è nato perché era da un po’ che volevo provare il full site editing di WordPress. Qui raccolgo un po’ di opinioni non richieste sull’esperienza che ho avuto. Una sorta di recensione, diciamo.
Contesto, questo blog e me
Ho usato WordPress più o meno da quando mi sono affacciato sull’internet. Mi è sempre sembrata la soluzione più veloce, economica e in generale comoda – o almeno, la meno scomoda – per tirare su un blog in cui scrivere qualche cavolata.
Mi sono sempre approcciato alla piattaforma – e questa recensione non fa eccezione – prima di tutto come utente, interessato il giusto al lato di sviluppo software e alla direzione del progetto open-source (non parlerò qui delle recenti controversie intorno a WordPress, Automattic e il suo CEO, né di eventuali alternative migliori o peggiori e citerò il “classic” editor solo quando necessario come confronto con il nuovo). In questo articolo mi occuperò di WordPress e del Full Site Editing su quello che è l’aspetto con cui è maggiormente pubblicizzato, ovvero la facilità di utilizzo.
Per contesto: questo blog utilizza l’ultima versione di WordPress ad oggi (6.8.2) e il tema di default twenty-twentyfive (1.3) modificato esclusivamente tramite gli strumenti forniti dal site editor. L’idea dell’esperimento è proprio quella di usare la versione di WordPress più “pulita” e fedele alle intenzioni del team possibile.
Non coprirò definizioni e concetti che sono in WordPress da sempre, ma solo come questi cambiano con il site editor. (Anche perché l’articolo sta già venendo lunghissimo così…)
Tenere insieme vecchio e nuovo
Se dovessi fare un TL;DR sarebbe tutto qui: le nuove versioni di WordPress cadono nel difficile compito di tenere insieme il vecchio e nuovo, spesso ottenendo il risultato di confondere sia gli utenti storici che i nuovi.
In questo mi ricorda un po’ Windows, che in in alcune parti del sistema operativo mantiene residuati degli anni 90, in altre invece sperimenta funzioni nuovissime ed evidentemente poco testate, il tutto condito con una buona dose di opzioni che vengono spostate qua e là o addirittura duplicate e seconda di come gira.
In WordPress c’è questo stacco grandissimo tra l’editor a blocchi nuovissimo e patinato (il famigerato Gutenberg, ci arriviamo) e tutto il resto che è rimasto uguale da anni. Nella versione “classica” di WordPress c’è un’interfaccia che già solo dai nomi e dalla struttura dei menù tendeva a separare molto i contenuti dal tema grafico. Struttura che viene mantenuta ma in cui sembra sia stato inserito un editor visuale a forza. Per cui che tu vada in “Aspetto” o in “Articoli”, ti ritrovi nello stesso editor. Questo genera confusione, soprattutto quando ti trovi a modificare template e pattern e non è chiaro se li stai modificando per la singola pagina o articolo o su tutto il sito. [spoiler alert: a quanto ho capito i pattern sono sempre modificati su tutto il sito a prescindere da dove li modifichi, i blocchi dipende]
Full site editing, site editor, block editor, Gutenberg?
Il mio primo problema, da utente con poca familiarità con il nuovo editor a blocchi, è una questione terminologica. A fondo articolo ci sono link ad alcune risorse che ho trovato utili per navigare nella confusione; ma per capirci da qui in avanti, ecco alcune definizioni (perdonate il misto inglese-italiano, ma penso sia l’unico modo per essere chiari):
- Full site editing: è il nome che raccoglie tutte le funzionalità del nuovo modo di creare temi per WordPress. In pratica un termine cappello che comprende tutto quanto segue.
- Block (blocco): tutte le componenti che si possono usare per comporre articoli o pagine sul sito sono adesso chiamati blocchi. Quindi un blocco è sia quello che si poteva già inserire nel “classic editor” come paragrafi, titoli, immagini, pulsanti, ecc, ma anche quelli che erano i widget (shortcode, rss, archivi, termini, calendario, ecc.) oltre che nuovi blocchi inclusi con WordPress o da plugin terzi.
- Site editor (in italiano: semplicemente “editor”): è l’area della dashboard che si raggiunge dal menù aspetto>editor e in cui è possibile modificare:
- Navigazione: permette di spostare le voci dei menù o rimuoverle. Per creare nuovi menù o nuove voci occorre entrare nell’editor a blocchi.
- Stili: qui si modificano aspetti relativi all’intero tema come tipografia, colori, sfondo, ombre, layout, oltre che l’aspetto dei blocchi (modifiche fatte ai blocchi in questa sezione impatteranno i blocchi presenti nell’intero sito).
- Pagine: di fatto una copia della sezione “pagine” nella dashboard.
- Template: qui si possono creare e modificare tramite l’editor a blocchi i template per pagine, articoli, archivi, pagina 404, risultati di ricerca.
- Pattern: sono un’insieme di blocchi che possono essere riutilizzati all’interno dei template, delle pagine o degli articoli. I più ovvi sono header e footer, ma si può creare più o meno tutto, sidebar, card, call to action, ecc.
- Block editor (editor a blocchi): è l’editor che ci consente di creare, spostare, modificare i blocchi all’interno delle pagina
- Gutenberg: è il nome in codice (code name) dell’editor a blocchi. Ormai non più utilizzato nella documentazione ufficiale, ma ci sono ancora parecchie risorse/guide/tutorial di terze parti che usano questo nome.
Vantaggi del Full Site Editing
Partiamo positivi con i vantaggi che secondo me esistono nel passaggio al Full Site Editing.
Editor a blocchi visuale
Noterete che l’editor visuale è sia nei pro che nei contro di questo articolo.
Questo perché da un lato, non dover gestire file php per modificare i template è un notevole vantaggio e l’editor visuale consente di avere un’anteprima in tempo reale di quello che si sta modificando, consentendo praticamente a chiunque di creare il proprio tema custom a blocchi con una barriera d’ingresso minore rispetto ai temi classici.
Dall’altro un editor di questo tipo tende ad essere inutilmente complesso e ingombrante quando si tratta di scrivere semplici articoli di un blog. Inoltre, ma approfondisco in seguito, ci sono dei problemi di UI e UX nell’utilizzo dell’editor.
Insomma l’editor a blocchi è ottimo quando si tratta di creare il tema del sito da zero senza particolari competenze di sviluppo e per me, se questo contribuisce a spingere più persone a creare il loro blog online, è un netto positivo.
Template e pattern
Come già detto il fatto di poter creare (o anche solo vedere e gestire) i template del tema senza dover uscire dalla dashboard di WordPress per me è un vantaggio notevole. A questo si aggiunge la possibilità di creare pattern da riutilizzare in giro per il sito senza doverli rifare ogni volta.
I blocchi dinamici
L’editor a blocchi contiene una serie di blocchi (raggruppati alla voce “tema”) che consentono di inserire contenuti dinamici come menù, autori, tassonomie, immagini in evidenza e altro, senza dover inserire short code o codice.
Il blocco query loop
Tra questi in particolare il blocco query loop, consente di mostrare contenuti (articoli o pagine, al momento in cui scrivo) in base all’archivio in cui ci trova o in base a query personalizzate. Al momento, c’è da dire, le query sono molto basiche, ma secondo me è uno strumento molto potente e che merita di essere portato avanti e migliorato.
Svantaggi del Full Site Editing – UI e UX
Come si sarà capito sono tra quelli (una minoranza, credo, visto l’accoglienza che ha avuto Gutenberg al rilascio e il Full Site Editing quando è diventato default su WordPress) a cui il concetto del Full Site Editing piace. I principali aspetti che sono ancora da limare sono nell’interfaccia e nell’esperienza utente.
Editor visuale ok, ma quanto è intuitivo?
L’editor a blocchi fa di tutto per essere minimimalista e il più simile possibile alla pagina finita. Il problema è che così finisce per rendere poco intuitiva la modifica dei blocchi da parte degli utenti. Secondo me dovrebbero esserci due distinte viste, una visuale di modifica (con i blocchi e le loro possibili modifiche ben evidenziati) e una visuale di anteprima (simile alla resa finale della pagina), con la possibilità di passare da una all’altra a seconda delle necessità.
Al momento l’editor si trova in una via di mezzo per cui quando vuoi avere una vista d’insieme della pagina, hai comunque pannelli e menu dell’editor in mezzo (al punto che una vista di anteprima pura esiste, ma la devi aprire in un’altra pagina del browser). Mentre non esiste proprio una vista di modifica pura in cui puoi vedere la struttura dei blocchi, righe e colonne quando ci sono delle grigle, oppure margini e padding, ecc.
Alcuni esempi da questo sito:
Personalmente faccio molta fatica ad individuare al volo la struttura dei blocchi senza usare l’apposito pannello (vedi sezione che segue) e questo mi crea qualche contrattempo quando devo inserire nuovi blocchi o spostare quelli esistenti. Penso che anche solo un leggero contorno sui blocchi potrebbe aiutare, mentre la “modalità in risalto” che attenua tutti i blocchi tranne quello selezionato, la trovo personalmente ancora più confusionaria. Per questo ho creato qualche linea di codice CSS che si può vedere in questo articolo.
Un’altra cosa che non mi spiego è perché non si possano inserire i blocchi nella vista elenco. Il pannello di inserimento e il pannello vista elenco – entrambi chiusi di default – non possono essere aperti in contemporanea, o tieni aperto uno o l’altro. Ne consegue che non puoi inserire un blocco usando la struttura della pagina come riferimento. Ma devi scorrere nel punto in cui vuoi inserire il blocco e posizionarlo esattamente lì.
Per spiegarmi meglio, metto qui un esempio da InDesign che avrà pure tanti problemi, ma di sicuro non quello di concederti di vedere chiaramente struttura, gerarchia e posizionamento dei contenuti.
InDesign fornisce viste chiaramente distinte che si possono cambiare a seconda di quello che si vuole vedere e modificare nella pagina. Secondo me questo genere di programmi può fornire spunti interessanti per la UI di un editor visivo, chiaramente con i distinguo dovuti alla differenza tra una pagina stampata e una web.
Ve li buco sti menù a scomparsa
La cosa che mi fa impazzire e forse la singola che più mi tiene lontano dall’editor a blocchi è la presenza eccessiva di menù a scomparsa di ogni tipo e forma: tabs, accordion, “hamburger” menù, menù a tendina e chi più ne ha più ne metta. Tutto ciò crea confusione soprattutto per chi si approccia per la prima volta all’editor.
Ad esempio, mi sarei immaginato che il pannello “blocco” (sulla destra nell’immagine che segue) contenesse tutte le impostazioni del blocco, mentre il pop-up contenesse le impostazioni più utilizzate.
In realtà no, le funzioni sono separate: alcune sono solo nel pop-up (addirittura nascoste da un ulteriore menù a scomparsa), alcune solo nel pannello “blocco”, altre sono sempre nel pannello “blocco”, ma bisogna attivarle di volta in volta con il pulsante “+” o sono nascoste dentro sottomenù a scomparsa.
Sì
A questo si aggiunge il fatto che alcuni pannelli sono nascosti di default (o almeno non ho trovato un’opzione per mantenerli sempre attivi senza doverli riaprire ogni volta che scrivo un nuovo articolo o senza intervenire sul file theme.json), o che in alcuni blocchi più complessi se ne aprano mille diversi.
Da migliorare
Chiuso l’aspetto su UI e UX, ci sono invece alcune cose che mi sembrano in linea con le premesse e gli obiettivi del Full Site Editing e che mi piacerebbe vedere integrate o migliorate. Le metto in una categoria a parte perché non sono di loro dei difetti della piattaforma, quanto delle cose che personalmente mi piacerebbe vedere integrate o spiegate meglio.
A questo punto perché non integrare CPT e custom fields?
Abbiamo blocchi con contenuti dinamici e il blocco query loop, a questo punto perché non includere la possibilità di creare Custom Post Types o custom fields direttamente in WordPress senza l’uso di svariati plugin aggiuntivi? So che può essere un lavoro difficile, ma mi sembra il passo successivo quasi obbligato per WordPress come piattaforma.
CSS o Json?
Sì avevo promesso di non parlare di codice, ma questo aspetto mi sembra rilevante perché crea confusione su aspetti che riguardano la costruzione di un sito in WordPress in generale. Di base tutte le componenti visive (comprese quelle tradizionalmente definite tramite fogli di stile) sono settate nel file theme.json del tema. E ok (cioè circa perché comunque a me non mi torna tanto come best practice, ma vabbè tare mie), ma questo crea una serie di dubbi, tra cui:
- Quindi servono ancora i child themes? Questa domanda chiederebbe un altro articolone a parte, ma qui una risposta che mi sembra puntuale.
- Forse non avrò trovato la soluzione corretta io (mi sembra troppo strano onestamente), ma se devo usare il file theme.json e il site editor perché poi alcune proprietà non sono gestibili (su tutto, gli “hover” tra le cose base base che non puoi fare) e online si consiglia di aggiungere CSS custom?
Conclusione
La conclusione di questa specie di recensione? Come dicevo in apertura, non sono un detrattore del progetto Gutenberg (e neanche dell’altro, di progetto Gutenberg). Alla fine mi sento ancora di consigliare WordPress come piattaforma per blog. E, se non si è particolarmente legati al vecchio modo di costruire i temi e al “classic” editor, mi sento anche di consigliare di usare l’editor a blocchi e i block themes.
Ci sono tutte le basi di una piattaforma sia user-friendly, ma anche potente abbastanza da permettere ad utenti avanzati o dev di modificarla secondo necessità. Con qualche attenzione in più ai dettagli in più nella UI e uno studio un po’ più attento della UX penso si possa fare ancora meglio.
Risorse
Funzione per evidenziare i blocchi nell’editor
Ho scritto del codice CSS che consente di evidenziare i blocchi (solo all’interno dell’editor) tramite un bordo esterno per chiarirne meglio la struttura.
Un sito per approfondire il Full Site Editing
Ho trovato questo sito (in inglese) che mi ha fornito una guida introduttiva molto migliore di quella data dalla documentazione ufficiale. Lo lascio qui perché davvero mi ha risolto un sacco di dubbi e aiutato ad avere una visione di insieme più chiara.
