Responsive Design stellt nicht nur unsere Tools und Ansätze für Webdesign und -entwicklung in Frage, sondern zwingt uns auch dazu, unsere Möglichkeiten zur Planung und Verwaltung von Inhalten zu überprüfen. Neue Arbeitsabläufe erfordern die richtigen Werkzeuge. Auf den ersten Blick eröffnet dies die Möglichkeit für völlig neue Content-Management-Systeme (CMS) und Publishing-Plattformen (und wir werden wahrscheinlich in naher Zukunft viele davon sehen). Aber jeder, der jemals von einem CMS zum anderen gewandert ist, weiß sehr gut, dass der Prozess nicht schmerzfrei ist. Können wir also ein bekanntes und beliebtes CMS wie WordPress anpassen, um uns bei der Erstellung und Verwaltung von adaptiven Inhalten zu unterstützen?

Zuerst müssen wir die Dinge klären. Was bedeutet adaptiver Inhalt und warum brauchen wir ihn im Zeitalter des responsiven Designs? Wir werden auch über die Funktionen und Tools von WordPress diskutieren, die uns helfen können, eine zukunftsfähige Veröffentlichungsplattform zu erstellen. Wir streben ein hohes Ziel an: Inhalte, die einmal erstellt wurden, können flexibel auf verschiedenen Geräten und unter verschiedenen Betrachtungsbedingungen präsentiert werden. Mal sehen, wie nah wir dran sind.

Adaptive Inhalte und warum wir sie brauchen

In ihrem letzten Buch Content-Strategie für Mobilgeräte , UX und Content-Strategie-Spezialist Karen MacGrane gibt eine detaillierte und gut begründete Erklärung, warum wir einen neuen Ansatz für das Content-Management brauchen. Wir gehen weiter als reaktionsschnelle Websites zu erstellen - wir erstellen Inhalte, die auf verschiedenen Plattformen veröffentlicht und auf verschiedenen Geräten abgerufen werden können. Was wäre, wenn morgen ein Kühlschrank zum primären Werkzeug für den Informationskonsum wird? Ist Ihre Website für einen solchen Anwendungsfall bereit?

Responsive Design hat sich hauptsächlich aus der Notwendigkeit ergeben, mobilen Benutzern eine angemessene Erfahrung zu bieten. Ehrlich gesagt ist "mobil" nur ein Teil des Bildes. Wenn wir an die Zukunft denken, können wir leicht andere neue Plattformen und Geräte erwarten, auf denen unsere Inhalte erscheinen werden: Uhren, Kühlschränke, Brillen, sprechende Roboter - alles, was man sich vorstellen kann. Bedeutet das, dass wir eine "sprechende Roboter" Version unserer Website erstellen müssen? Das wäre Wahnsinn. Also, was ist die Lösung? Die Lösung ist adaptive Inhalte - Inhalte, die nach ihrer Erstellung in verschiedenen Situationen und Szenarien wiederverwendet werden können. Klingt gut, oder? Wie erreichen wir es?

1. Strukturierter Inhalt

Unser Inhalt besteht nicht mehr aus "Seiten". Er besteht aus Objekten, von denen jedes als ein Paket von vordefinierten Elementen betrachtet werden sollte. Für jede strukturelle Komponente - ein Stück - würde das Entwurfssystem berücksichtigen, wie es in allen Szenarien angezeigt werden sollte. Chunks können in alternativen Medien oder Formaten für verschiedene Anwendungsfälle präsentiert werden. Wenn wir beispielsweise ein Video in unserem Inhaltsobjekt haben, könnten wir einen beschreibenden Text oder ein Transkript für Szenarien haben, in denen das Video nicht angezeigt werden kann. Oder die Anmerkungen zu einem Objekt können je nach Szenario variieren, z. B. wenn sie in sozialen Medien geteilt, in Suchergebnissen enthalten oder auf einer Website eingeführt werden.

2. Präsentationsunabhängiger Inhalt

Wir müssen den nächsten Schritt zur Trennung von Inhalt und Präsentation machen. Eigentlich ist dies ein wichtiger Grundsatz des Redesigns und ein Eckpfeiler von Webstandards. Aber wir müssen weiter gehen und uns von der WYSIWYG-Mentalität befreien. "Was Sie sehen" ist nicht mehr das, was Ihre Nutzer sehen. Das ist eine gefährliche Illusion. Wir sollten unseren Text nicht kursiv markieren oder Bilder als HTML in das Feld "Inhalt" einer "Seite" einfügen. Wir sollten einfach einen Verweis auf ein Inhaltsobjekt einfügen und unser Designsystem entscheiden lassen, wie das Objekt präsentiert wird.

3. Metadaten

Je mehr Arbeit wir an Programm-Tools abladen (schließlich möchten wir, dass unsere Inhalte automatisch auf verschiedenen Plattformen basierend auf vordefinierten Szenarien präsentiert werden, oder?), Desto mehr Informationen sollten wir diesen Systemen über den Inhalt zur Verfügung stellen. Zum Beispiel konnten wir in der Vergangenheit in einfachem Englisch schreiben, dass der Autor eines Textes John Doe war und seinen Namen fett markieren - jetzt können wir nicht. Wir benötigen ein separates Feld in unserem CMS, um den Namen und eine Reihe von Regeln für die Darstellung in verschiedenen Szenarien einzugeben.

4. Wiederverwendbarer Inhalt

Wir benötigen eine einzige Inhaltsquelle und ein Szenario-basiertes Publishing-System, das entscheiden kann, wie der angeforderte Inhalt einem Benutzer entsprechend seiner Umgebung (Gerät, Bildschirmauflösung, Verbindungsgeschwindigkeit usw.) präsentiert wird.

Können all diese Aspekte mit WordPress erreicht werden? MacGrane beschuldigt WordPress und andere Blogging-Software, Publisher nicht als Werkzeug für adaptive Inhalte zu unterstützen. Insbesondere haben wir immer noch einen WYSIWYG-Editor in WordPress, mit einem einzigen Textbereich, um in unseren "Post" zu gelangen. Leider ist dies die Situation, der sich ein Designer mit der einfachen Standardversion von WordPress gegenübersieht. Glücklicherweise ist WordPress ein bisschen mehr als nur "Blogging-Software". Es hat sich zu einer Entwicklungsplattform entwickelt, mit der ein Entwickler seinen Kunden eine wirklich moderne und zukunftssichere Erfahrung bieten kann.

Verwandeln Sie WordPress in eine adaptive Publishing-Plattform

Lassen Sie uns sehen, welche Tools wir als Entwickler haben und wie wir sie implementieren können, um WordPress in eine adaptive Publishing-Plattform für unsere Kunden zu verwandeln.

WordPress begann seine Entwicklung zu einem vollwertigen CMS mit der Einführung von benutzerdefinierten Post-Typen und benutzerdefinierten Taxonomien. Eine weitere leistungsstarke Funktion, die in Kombination mit diesen Funktionen verwendet wird, sind die sogenannten benutzerdefinierten Felder. Dieser einfache Name bezieht sich auf die GUI; Tatsächlich stellen diese benutzerdefinierten Felder die Menge der Metadaten dar, die jedem Objekt in WordPress zugeordnet werden können. WordPress gibt uns die Möglichkeit, eine hochgradig anpassbare Benutzeroberfläche für Metadaten und eine flexible API zum Speichern und Zugriff darauf zu erstellen.

Warum ist das hilfreich? Mit benutzerdefinierten Post-Typen sind wir nicht mehr in das "Seiten" -Konzept eingeschlossen. Wir können einen Post-Typ für jedes Objekt erstellen, das wir brauchen (wie Nachrichten, Ereignisse, Partner - was immer wir wollen), und wir können die Struktur des Objekts durch diesen Satz von Metadaten definieren. Wir können auch eine separate Benutzeroberfläche zur Verwaltung der Metadaten erstellen. All dies gibt unserem Inhalt mehr Struktur. Sobald WordPress uns erlaubte, Metadaten eines beliebigen Typs zu erstellen, konnten wir damit Alternativen für integrierte Inhaltsblöcke wie Titel und Beschreibungen speichern. (Zum Beispiel könnten wir SEO-Plugins sehen, die einen eindeutigen SEO-spezifischen Titel und eine Beschreibung für jedes Inhaltsobjekt ermöglichen.)

Was sind seine Grenzen? WordPress wird oft dafür kritisiert, dass es nicht konsequent eine API zum Speichern von Metadaten zur Verfügung stellt. Insbesondere können wir Metadaten für Posts (und benutzerdefinierte Post-Typen) und Benutzer, aber nicht für Taxonomien (a Plugin wird benötigt dafür). Das Erstellen einer benutzerdefinierten Benutzeroberfläche im Bearbeitungsbildschirm für einen Post ist nicht so einfach wie es sein könnte. Vordefinierte Funktionen und Standards fehlen (weshalb verschiedene Plugins das anders machen und uns damit eher ein Chaos als ein System hinterlassen). Aber die jüngsten Änderungen, die helfen, das WordPress-Dashboard zu vereinheitlichen und zu optimieren, geben uns Hoffnung.

Ein weiteres großartiges Feature von WordPress ist, dass es mehrere Instanzen des Rich-Text-Editors auf einer Seite erlaubt. Dies kann mit dem implementiert werden wp_editor Funktion, die nicht nur das entsprechende Textarea-Markup erstellt, sondern auch diesem und den Medienauswahlschaltflächen Rich-Editing-Funktionalität zuweist.

Warum ist das hilfreich? Mit dieser Funktion können wir ein einzelnes Inhaltsfeld gemäß der Struktur eines Objekts in mehrere Teile aufteilen. Dabei fügen wir unseren Objekten eine strukturelle Komponente hinzu. Jeder bearbeitbare Bereich verfügt über eine einheitliche und vertraute Benutzeroberfläche, die es Editoren erleichtert, die erforderlichen Markups in die entsprechenden Felder, einschließlich Kurzwahlnummern, einzufügen.

Was sind seine Grenzen? Wir sollten Daten, die in solchen Rich-Editing-Bereichen eingegeben werden, als Metadaten speichern, und das bedeutet mehr Datenbankaufrufe usw. Daher erfordert dieser Ansatz weitere Aufmerksamkeit auf die Optimierung der Site, wie etwa Caching. Es gibt keine integrierte Funktion, um diese Daten in Templates darzustellen. Daher müssen wir sie erstellen.

Mit diesem Ansatz würde der gewohnte Post-Editing-Bildschirm vollständig transformiert:

Mit den oben besprochenen WordPress-Tools können wir unsere Inhalte strukturierter gestalten, indem wir Objekte definieren und einen einzelnen Inhaltsblob durch einen Satz von Feldern ersetzen, die die verschiedenen Teile und Metadaten des Inhalts speichern.

Jetzt wollen wir sehen, welche Werkzeuge wir brauchen, um Bedeutung und Präsentation zu trennen. Eigentlich gibt es nur zwei Grundregeln:

  1. Beseitigen Sie den visuellen Editor.
  2. Vermeiden Sie die Verwendung von einfachem HTML in Inhaltsfeldern so weit wie möglich.

Die erste Regel ist einfach zu folgen. Mit einem einfachen Filter können wir den visuellen Editor für alle Benutzer entfernen.

add_filter('user_can_richedit', '__return_false');

Die zweite Regel ist viel schwieriger zu folgen. Sicher werden wir nicht nach jedem HTML-Tag in unserem Text suchen - diejenigen, die wirklich semantische Elemente darstellen, sind absolut in Ordnung. Aber wenn wir anfangen einzufügen

In ein Inhaltsobjekt geraten wir in Schwierigkeiten. Wie wir wissen, könnte eine Spalte in einem Szenario in einem anderen Szenario etwas völlig anderes sein.

Ein weiteres großes Problem ergibt sich daraus, wie WordPress Rich Media - insbesondere Bilder - in Inhaltsfelder einfügt. Zurzeit wird nur HTML-Code gedruckt, der den Link zum Bild, seine Größe und das Wrapping-Markup fest codiert. Es ist das denkbar schlechteste Szenario für einen adaptiven Ansatz. Was wäre, wenn wir für einen bestimmten Anwendungsfall eine andere Variante eines Bildes benötigten? Was ist, wenn wir unsere Medienbibliothek in eine andere Domain verschoben haben? Was, wenn wir das Design eines Objekts geändert haben und das Bild in einer anderen Größe benötigen? Was ist, wenn wir eine reaktionsfähige Technik implementieren, bei der wir mehrere Quellen für ein Bild angeben müssen? All diese Anwendungsfälle sind absolut unmöglich, wenn wir das Standardverhalten von WordPress nicht ändern.

Und doch hat WordPress fast alles, um einen Wechsel zu einem adaptiven Ansatz zu ermöglichen:

  • Jedes Medienelement in der Medienbibliothek hat einen eigenen Eintrag in der Datenbank, in dem alle relevanten Informationen einschließlich der Daten zur Quelldatei gespeichert sind. WordPress speichert jedoch keine absolute Verknüpfung zu einer Datei. Stattdessen speichert es den Namen der Datei und den Pfad zum uploads Ordner separat, so dass der vollständige Pfad dynamisch erstellt werden kann.
  • WordPress verfügt über eine Shortcode-Funktionalität, mit der Sie jedes Markup in Inhaltsfeldern referenzieren und das tatsächliche Markup dynamisch erstellen können, wenn der Inhalt im Frontend gedruckt wird.

Zusammenfassend können wir das Markup für Medien mit einem Shortcode darstellen, der die ID des Artikels in der Medienbibliothek enthält. Ein sehr einfaches Beispiel würde so aussehen:

add_shortcode('frl_image', 'frl_image_screen');function frl_image_screen($atts, $content = ''){extract(shortcode_atts(array('id' => 0, 'link' => 'file', 'size' => 'medium'), $atts ));$out = '';$id = intval($id);if($id == 0)return ''; // no attachment$out = "