Temi del futuro: una struttura di design e un tema principale

Il tema WordPress ha una ricca storia. Nel corso degli anni, gli autori di temi hanno portato una pletora di funzionalità sulla piattaforma. In parte, è perché hanno spesso dovuto risolvere problemi fondamentali con WordPress per creare le funzionalità desiderate dagli utenti finali.

Le lezioni di post e corpo che tutti gli autori di temi usano oggi? Quelli erano originariamente in un tema chiamato Sandbox.

Immagini in evidenza? Quelli sono stati resi popolari dai temi delle riviste un decennio fa.

Pensi che i formati dei post siano originati da Tumblr? Matt Mullenweg, co-creatore di WordPress, ci ha insegnato come creare post a parte nei nostri temi nel 2004, ma esistevano prima.

Le funzionalità di WordPress spesso iniziano nel mondo dei temi. A volte diamo per scontati gli anni di sperimentazione e iterazione sulle idee in cui gli autori del tema stanno mettendo nel lavoro. Anche l'editor di blocchi gestisce elementi che sono stati tradizionalmente nel regno della progettazione dei temi. Il blocco di copertura è un buon esempio. Per anni, gli autori di temi hanno creato opzioni tematiche per un'immagine di base dell'eroe con testo e pulsanti sovrapposti. Il risultato era spesso goffo e non ideale per gli utenti. Portando questa funzionalità al centro, ha fornito agli utenti la possibilità di inserire questo blocco di copertura in qualsiasi area di blocco consentita.

Il motivo per cui molte funzionalità del tema lo rendono fondamentale è che funzionano semplicemente meglio quando sono standardizzate. Gli utenti sanno cosa aspettarsi e gli autori dei temi possono concentrarsi sull'aspetto del design piuttosto che sulla risoluzione del problema dell'esperienza utente.

Parte del problema del passato è che ogni nuova funzionalità adottata nel core non seguiva alcun modello di progettazione o schema di denominazione standard. Un'enorme abilità nella progettazione di temi WordPress sta impegnando nella memoria il miscuglio di centinaia di classi.

L'editor di blocchi è in una posizione unica per cambiarlo creando un framework di progettazione universale.

WordPress ha bisogno di un framework di progettazione front-end?

Con i modelli di blocchi in arrivo in futuro e la personalizzazione completa del sito ad un certo punto, gli autori del tema si chiedono esattamente dove sta navigando questa nave. È eccitante perché le possibilità sono illimitate per gli utenti finali. È spaventoso per gli autori di temi che hanno costruito i loro imperi su un modo di fare le cose, ma lo sviluppo riguarda più l'adattamento che altro.

Armati della consapevolezza che il paesaggio sta cambiando, questo è il momento in cui gli autori del tema hanno bisogno di unirsi per plasmare il loro futuro in un mondo basato sui blocchi.

C'è una piccola battuta in uno dei gruppi di sviluppatori in cui sono coinvolto sul fatto che gli sviluppatori principali non sono autori di temi. Dal punto di vista dell'autore del tema, a volte può sembrare che le idee siano messe insieme a casaccio senza pensare ai sistemi di progettazione CSS.

Oh, vedo un po' di BEM. Perché questo sottoelemento non segue lo stesso schema di denominazione? Attesa. È una classe di utilità di 38 caratteri?

Ciò che a WordPress è sempre mancato è un sistema di progettazione front-end universale. A volte, è stata una buona cosa. Ha consentito agli autori dei temi di utilizzare il loro framework preferito. Qualsiasi autore di temi che è stato nel gioco abbastanza a lungo ti dirà che quel tipo di flessibilità è eccezionale... finché non lo è . Hai mai provato ad aggiungere classi contestuali ai widget? Che ne dici di aggiungere una classe di utilità al wrapper del modulo di commento? Avrai bisogno di un'aspirina. O due.

Con WordPress, alcune cose sono scolpite nella pietra e altre sono collegabili. Alcune funzionalità seguono uno schema di denominazione delle classi standard e altre non hanno senso. Il risultato per i temi è spesso un CSS gonfio nel tentativo di litigare tra i vari componenti.

È quasi impossibile utilizzare completamente un framework di classe di utilità come Tailwind CSS in un tema senza ricreare le funzionalità principali.

Gran parte di ciò deriva da anni di accumulo di codice legacy e dall'impegno di WordPress per la compatibilità con le versioni precedenti. Ma il futuro non deve assomigliare al passato. Siamo alle soglie di una nuova era e ora è il momento per i designer front-end di entrare nella conversazione.

WordPress ha bisogno di un solido framework di progettazione front-end.

Questa è una dichiarazione caricata. Se metti 20 designer in una stanza e chiedi loro di discutere le strutture di progettazione, potrebbe essere una ricetta per scazzottate. Tendo ad essere un ottimista e spero che il dibattito abbia fornito risultati.

Gutenberg ci ha spinto in parte in questa direzione, ma non è abbastanza. Con la modifica dell'intero sito in futuro, è necessario un approccio più olistico nell'affrontare questo problema.

Più di ogni altra cosa, abbiamo bisogno di più designer front-end nella conversazione. Non c'è modo .has-subtle-pale-green-background-color debba esistere come classe di utilità su qualcosa come .bg-pale-green , .bg-green-100 , o anche .background-pale-green , se tu voglio essere più prolisso. Non c'era alcun concetto di ottimizzazione che è andato in quella decisione. In un momento in cui gli sviluppatori utilizzano connessioni Internet gigabit, è facile dimenticare che gran parte del mondo sta seguendo un ritmo più lento.

Uno schema di denominazione basato sui componenti con una buona dose di classi di utilità è un'opzione che potrebbe colpire diversi punti deboli. Questo non è un argomento per un framework CSS rispetto a un altro. Ci sono molte buone opzioni esistenti. WordPress dovrebbe affrontare questo problema prendendo in prestito dalle basi stabilite da altri progetti e creando qualcosa di unico WordPress. Dovrebbe essere un leader nel settore.

I framework di progettazione riguardano anche i plugin. C'è qualche incrocio nel regno dei temi in cui i due hanno intrapreso una guerra in corso sin dagli albori del sistema tematico. Il campo di battaglia tra temi e plugin è disseminato della morte delle buone idee. Troppi non hanno mai raccolto il supporto di cui avevano bisogno per atterrare nel nucleo. Una sorta di standard di progettazione universale potrebbe arginare la marea di problemi e richiedere un cessate il fuoco.

Un plug-in che genera un componente front-end personalizzato non ha modo di sapere come il tema corrente gestisce il ritmo verticale, ad esempio. Utilizza il margine superiore o inferiore? Qual è il valore e l'unità utilizzata? Questa è roba fondamentale, ed è quasi sempre interrotta quando il plugin tenta di aggiungere CSS personalizzato per gestirlo.

WordPress ha bisogno di un framework di progettazione, o linguaggio, che consenta a tutte le sue parti mobili di unirsi in armonia sul front-end. Sono sicuro che a un certo punto ci arriveremo. Spero che sia più coeso dei componenti casuali e degli schemi di denominazione del passato. Dovremmo anche avere una tabella di marcia chiara che riempia alcuni dettagli tecnici in modo che sviluppatori e designer possano essere preparati.

È possibile un futuro a tema unico?

Rich Tabor sostiene che il core WordPress potrebbe fornire un unico tema genitore nel suo articolo A Look at WordPress Themes of the Future. L'idea è che gli autori di temi sarebbero relegati a creare un tema figlio per questo tema "master".

La reazione istintiva per molti sarebbe che non funzionerebbe, i temi perderebbero la loro personalità e vivremmo in un mondo di disegni di stampini.

La realtà è che ci stiamo dirigendo verso un futuro in cui l'idea di un genitore single o un tema principale è una seria considerazione.

La maggior parte dei temi sono raggruppamenti personalizzati di elementi standard che esistono in quasi tutti i temi. Ci sono alcune decisioni, a parte le preoccupazioni stilistiche, che rendono i temi diversi l'uno dall'altro, come il layout dell'intestazione. Un tema potrebbe avere un titolo del sito e un menu di navigazione in un blocco. Un altro potrebbe avere un menu di navigazione, un titolo e un secondo menu di navigazione di seguito. Tuttavia, un altro tema potrebbe mostrare una casella di ricerca. In un mondo in cui la personalizzazione dell'intero sito appartiene all'utente, tali decisioni diventano parte dell'esperienza dell'utente piuttosto che dell'esperienza dello sviluppatore.

I temi dovranno distinguersi con tavolozze di colori, tipografia e il loro marchio di stranezza: un ritorno dei giorni di CSS Zen Garden ma su scala molto più ampia.

Non sarò triste per questo. Sarebbe interessante vedere la concorrenza tra i migliori designer del settore. Potrebbe anche riportare i temi di WordPress in un'era in cui chiunque potrebbe farlo con un po' di conoscenza e determinazione CSS.

Anche se non siamo ancora pronti per un futuro in cui un tema governa tutti i temi, è un punto di partenza per la conversazione. Se progettassimo WordPress per questo potenziale futuro, anche se non implementassimo mai un tema principale, come sarebbe la tabella di marcia? Quali ostacoli si frappongono? È fattibile?