Themen der Zukunft: Ein Design-Framework und ein Master-Thema

WordPress-Themes haben eine lange Geschichte. Im Laufe der Jahre haben Themenautoren eine Fülle von Funktionen auf die Plattform gebracht. Zum Teil liegt es daran, dass sie oft grundlegende Probleme mit WordPress lösen mussten, um die Funktionen zu erstellen, die Endbenutzer wünschen.

Die Post- und Body-Klassen, die alle Themenautoren heute verwenden? Diese befanden sich ursprünglich in einem Thema namens Sandbox.

Ausgewählte Bilder? Diese wurden vor einem Jahrzehnt durch Zeitschriftenthemen populär gemacht.

Du denkst, dass Postformate ihren Ursprung bei Tumblr haben? Matt Mullenweg, Mitschöpfer von WordPress, hat uns 2004 beigebracht, wie man Nebenbeiträge in unseren Themen erstellt, aber sie existierten schon vorher.

WordPress-Funktionen beginnen oft in der Themenwelt. Wir nehmen manchmal die Jahre des Experimentierens und Iterierens von Ideen als selbstverständlich hin, in die Themenautoren die Arbeit stecken. Sogar der Blockeditor verarbeitet Elemente, die traditionell im Bereich des Themendesigns liegen. Der Abdeckblock ist ein gutes Beispiel. Jahrelang haben Themenautoren Themenoptionen für ein grundlegendes Heldenbild mit Text und überlagerten Schaltflächen erstellt. Das Ergebnis war oft klobig und für Benutzer nicht ideal. Durch das Einbringen dieser Funktion in den Kern wurde den Benutzern die Möglichkeit gegeben, diesen Abdeckblock in jedem zulässigen Blockbereich zu platzieren.

Der Grund, warum viele Themenfunktionen es zum Kern schaffen, ist, dass sie einfach besser funktionieren, wenn sie standardisiert sind. Benutzer wissen, was sie erwartet, und Themenautoren können sich auf den Designaspekt konzentrieren, anstatt das Problem der Benutzererfahrung zu lösen.

Ein Teil des Problems der Vergangenheit bestand darin, dass jede neue Funktion, die in den Kern übernommen wurde, keinem standardmäßigen Entwurfsmuster oder Benennungsschema folgte. Eine große Fähigkeit beim Entwerfen von WordPress-Themes besteht darin, den Mischmasch aus Hunderten von Klassen in Erinnerung zu behalten.

Der Blockeditor ist in der einzigartigen Position, dies zu ändern, indem er ein universelles Design-Framework erstellt.

Braucht WordPress ein Front-End-Design-Framework?

Mit Blockmustern in der Zukunft und einer vollständigen Anpassung der Website irgendwann danach fragen sich Themenautoren genau, wohin dieses Schiff segelt. Es ist spannend, weil die Möglichkeiten für Endbenutzer grenzenlos sind. Es ist beängstigend für Themenautoren, die ihre Imperien auf eine Art und Weise aufgebaut haben, Dinge zu tun, aber bei der Entwicklung geht es mehr um Anpassung als um alles andere.

Bewaffnet mit dem Vorwissen, dass sich die Landschaft verändert, ist dies der Moment, in dem Themenautoren sich zusammenschließen müssen, um ihre Zukunft in einer blockbasierten Welt zu gestalten.

Es gibt einen kleinen Witz in einer der Entwicklergruppen, an denen ich beteiligt bin, dass Kernentwickler keine Themenautoren sind. Aus der Perspektive des Themenautors kann es manchmal so aussehen, als würden Ideen willkürlich zusammengeworfen, ohne an CSS-Designsysteme zu denken.

Oh, ich sehe einige BEM. Warum folgt dieses Unterelement nicht demselben Namensschema? Warten. Ist das eine Dienstprogrammklasse mit 38 Zeichen?

Was WordPress immer gefehlt hat, ist ein universelles Frontend-Designsystem. Manchmal war das eine gute Sache. Es hat Themenautoren ermöglicht, ihr bevorzugtes Framework zu verwenden. Jeder Themenautor, der lange genug im Spiel ist, wird Ihnen sagen, dass diese Art von Flexibilität großartig ist … bis sie es nicht mehr ist . Haben Sie jemals versucht, Widgets Kontextklassen hinzuzufügen? Was ist mit dem Hinzufügen einer Utility-Klasse zum Kommentarformular-Wrapper? Sie benötigen ein Aspirin. Oder zwei.

Bei WordPress sind einige Dinge in Stein gemeißelt und andere sind austauschbar. Einige Funktionen folgen einem standardmäßigen Klassenbenennungsschema, andere ergeben keinen Sinn. Das Ergebnis für Themen ist oft aufgeblähtes CSS, bei dem versucht wird, die verschiedenen Komponenten zu verwirren.

Es ist nahezu unmöglich, ein Framework der Utility-Klasse wie Tailwind CSS vollständig in einem Design zu verwenden, ohne Kernfunktionen neu zu erstellen.

Vieles davon stammt aus jahrelanger Anhäufung von Legacy-Code und dem Engagement von WordPress für Abwärtskompatibilität. Aber die Zukunft muss nicht der Vergangenheit gleichen. Wir stehen an der Schwelle zu einer neuen Ära, und jetzt ist es an der Zeit, dass Frontend-Designer ins Gespräch kommen.

WordPress benötigt ein solides Front-End-Design-Framework.

Das ist eine geladene Aussage. Wenn Sie 20 Designer in einen Raum stellen und sie bitten, Design-Frameworks zu diskutieren, könnte dies ein Rezept für Handgreiflichkeiten sein. Ich bin eher Optimist und hoffe, dass die Debatte zu Ergebnissen geführt hat.

Gutenberg hat uns teilweise in diese Richtung gedrängt, aber es geht nicht ganz weit genug. Mit der zukünftigen vollständigen Website-Bearbeitung ist ein ganzheitlicherer Ansatz zur Bewältigung dieses Problems erforderlich.

Wir brauchen vor allem mehr Frontend-Designer im Gespräch. Es gibt keine Möglichkeit, .has-subtle-pale-green-background-color als Utility-Klasse über etwas wie .bg-pale-green , .bg-green-100 oder sogar .background-pale-green existieren sollte, wenn Sie möchte ausführlicher sein. Es gab kein Optimierungskonzept, das in diese Entscheidung eingeflossen ist. In einer Zeit, in der Entwickler mit Gigabit-Internetverbindungen arbeiten, vergisst man leicht, dass ein Großteil der Welt langsamer folgt.

Ein komponentenbasiertes Benennungsschema mit einer gesunden Dosis von Utility-Klassen ist eine Option, die mehrere Sweetspots treffen könnte. Dies ist kein Argument dafür, ein CSS-Framework einem anderen vorzuziehen. Es gibt viele gute, bestehende Optionen. WordPress sollte dies direkt angehen, indem es sich von den Grundlagen anderer Projekte borgt und etwas einzigartiges WordPress schafft. Es sollte führend auf dem Gebiet sein.

Bei Design-Frameworks geht es auch um Plugins. Es gibt einen Übergang in den Themenbereich, in dem die beiden seit Beginn des Themensystems einen andauernden Krieg führen. Das Schlachtfeld zwischen Themes und Plugins ist übersät mit dem Tod guter Ideen. Viel zu viele haben nie die Unterstützung erhalten, die sie brauchten, um im Kern zu landen. Eine Art universeller Designstandard könnte die Flut von Problemen eindämmen und einen Waffenstillstand fordern.

Ein Plug-in, das eine benutzerdefinierte Frontend-Komponente ausgibt, hat beispielsweise keine Möglichkeit zu wissen, wie das aktuelle Thema mit vertikalem Rhythmus umgeht. Wird der obere oder untere Rand verwendet? Welcher Wert und welche Einheit werden verwendet? Dies sind grundlegende Dinge, die fast immer kaputt gehen, wenn das Plugin versucht, benutzerdefiniertes CSS hinzuzufügen, um damit umzugehen.

WordPress benötigt ein Design-Framework oder eine Sprache, die es ermöglicht, dass alle beweglichen Teile im Frontend harmonisch zusammenkommen. Ich bin mir sicher, dass wir irgendwann ankommen werden. Ich hoffe, dass es zusammenhängender ist als die zufälligen Komponenten und Benennungsschemata der Vergangenheit. Wir sollten auch eine klare Roadmap haben, die einige der technischen Details enthält, damit Entwickler und Designer vorbereitet sind.

Ist eine One-Theme-Zukunft möglich?

Rich Tabor argumentiert in seinem Artikel A Look at WordPress Themes of the Future, dass Kern-WordPress ein einzelnes übergeordnetes Thema bereitstellen könnte. Die Idee ist, dass Theme-Autoren dazu gezwungen werden, ein Child-Theme für dieses „Master“-Theme zu erstellen.

Die Bauchreaktion für viele wäre, dass es nicht funktionieren würde, Themen ihre Persönlichkeit verlieren würden und wir in einer Welt von Cookie-Cutter-Designs leben würden.

Die Realität ist, dass wir auf eine Zukunft zusteuern, in der die Idee eines alleinerziehenden Elternteils oder eines Hauptthemas eine ernsthafte Überlegung ist.

Die meisten Themen sind benutzerdefinierte Gruppierungen von Standardelementen, die in fast allen Themen vorhanden sind. Abgesehen von stilistischen Bedenken gibt es einige Entscheidungen, die Themen voneinander unterscheiden, wie z. B. das Layout der Kopfzeile. Ein Thema kann einen Seitentitel und ein Navigationsmenü in einem Block haben. Ein anderes könnte ein Navigationsmenü, einen Titel und ein zweites Navigationsmenü darunter haben. Ein anderes Thema zeigt jedoch möglicherweise ein Suchfeld an. In einer Welt, in der die vollständige Website-Anpassung dem Benutzer gehört, werden diese Entscheidungen eher Teil der Benutzererfahrung als der Entwicklererfahrung.

Themes müssen sich durch Farbpaletten, Typografie und ihre eigene Art von Skurrilität abheben – eine Rückkehr zu den Tagen von CSS Zen Garden, aber in einem viel größeren Maßstab.

Ich werde darüber nicht traurig sein. Es wäre interessant, den Wettbewerb zwischen den Top-Designern auf diesem Gebiet zu sehen. Es kann auch WordPress-Themen in eine Zeit zurückversetzen, in der es jeder mit ein wenig CSS-Kenntnissen und Entschlossenheit tun konnte.

Wir sind zwar noch nicht ganz bereit für eine Zukunft, in der ein Thema alle Themen beherrscht, aber es ist ein Ort, um das Gespräch zu beginnen. Wenn wir WordPress für diese potenzielle Zukunft entwerfen würden, wie würde die Roadmap aussehen, auch wenn wir nie ein Master-Theme implementieren? Welche Hindernisse stehen im Weg? Ist es machbar?