Design Guideline für CoreMedia CMS Projekte

Das Design und die Frontend Entwicklung für eine Webseite wo nicht technische Nutzer den Inhalt editieren birgt einige Fallstricke. Es ist ein Unterschied, ob man die volle Kontrolle über den Output Markup hat oder nicht. Leider kommt bei CoreMedia Projekten häufig vor, dass Designer die nicht in den Tiefen eines Enterprise Content Managements stecken Dateien abliefern, die in Photoshop gut aussehen, aber nach der Überführung in CMS Templates und Befüllung mit echtem Content grausig aussehen. Ebenfalls ist es ein sehr großer Unterschied, ob Webdesigner oder Printdesigner ans Werk gehen. Es sind nun mal unterschiedliche Welten. Das Zauberwort heißt: Dynamik.
Nachfolgend wollen wir die Problematik beleuchten und einige Hinweise geben.

Heutzutage wollen Kunden natürlich ihren Content selbst bearbeiten können, d.h. die Designs (meist Photoshop oder Sketch Dateien) werden in Templates überführt. Die Besonderheiten eines CMS Systems schon während der Designphase in die Überlegungen einfliessen zu lassen hilft später böse Überraschungen und Zeitverlust zu vermeiden.

Kenne Deinen Feind (unstrukturiertes HTML)
Können Redakteure HTML Tags in den Content einfügen, z.B. durch Richtext Editoren oder direkt als eigenen Dokumententyp (CMHtml)? Je mehr Freiheiten der Redakteur geniesst, um so mehr muss das Design defensiv damit umgehen können. Der bessere Weg ist es hier vorgefertigte Strukturen vorzugeben, die der Redakteur befüllen kann. Wir haben so oft erlebt, dass große, unstrukturierte HTML Blöcke das gesamte Layout zerschiessen und schlimmer die Seite zum erliegen bringen können. Einige nutzen diese HMTL Dokumenttypen so extensiv, dass man sich fragt, ob statische HTMLs nicht besser geeignet wären als ein Enterprise CMS. Diese HTML Blöcke existieren nicht im leeren Raum, sondern sind immer im Context eines CMS zu betrachten. Man hat keine Kontrolle darüber, was in diesen HTMLs eingefügt wird. Teilweise sind as auch externe Agenturen , die ein CMS System nicht kennen und nur nach Design Überlegungen gehen.

Bleib Konsistent
Wie flexibel das CMS auch sein mag, es ist wichtig in Templates konsistent zu bleiben. Das Training von Redakteuren wird erheblich einfacher, wenn Dokumenttypen und Ansichtssettings mit denen sie arbeiten müssen über alle Seiten hinweg konsistent sind.

Wenn man mit strukturiertem Content arbeitet (z.B. Artikel Übersichtsseite, welches alle Titel mit einem Teasertext und Bild anzeigt) ist es hilfreich jeden Artikelblock als sich wiederholenden Block zu betrachten. Mit CSS3 Selektoren ist es dann einfach unterschiedliche Zeilen unterschiedlich zu behandeln (z.B. alternierende Farben für die Zeilen). Es dürfen weiterhin keine verschachtelnden DIVs vorhanden sein, jedes Listing sollte ein in sich selbständiger Block sein ohne Abhängigkeit zu einem parent div.

Wenn der User große Mengen an freiem HTML einfügen kann dann darf man nicht davon ausgehen, dass dieser auch daran denkt die entsprechenden CSS Klassen im Richtext hinzuzufügen. Das Design / CSS muss das berücksichtigen.

Content Höhe oder Blockhöhe sind nicht fix
Im Web ist es nie eine gute Idee davon auszugehen, dass irgend ein Element eine bestimmt Höhe haben wird. Auch wenn man Kontrolle über den Content hat, ein Font Resizing kann schon dafür sorgen, dass das Design zerfällt und z.B. ungewollte Overflows oder Umbrüche passieren.
Ausserdem muss man berücksichtigen, dass Redakteure mal weniger mal mehr Text einpflegen. Beim initialen Design in Photoshop muss man sich schon vorstellen wie Boxen aussehen werden mit weniger Text (Weißräume vermeiden) oder mehr Text (machen wir die Box größer oder fügen wir ein „Mehr“ ein).

Grid basierte Layouts haben hier besonders ein Problem. Wenn z.B. mehrere Boxen nebeneinander in Spalten angeordnet sind dann sieht das mit dem einzeiligen Lorem Ipsum noch gut aus. Aber Wass wenn die Headlines mal 1-zeilig mal 2-zeilig sind? Das lässt das Design sehr unruhig wirken. Eventuell hätte man hier ein anderes Layout gewählt, wenn die Probleme bekannt gewesen wären. Wenn der Designer die Dateien an den Frontend Entwickler weitergibt und diese Szenarios schon durchdacht hat, dann behält er die Kontrolle und vermeidet unnötige Fragen, wenn schon teure Implementierung stattgefunden hat. Als Designer muss man entscheiden wie mit Textgrößen Änderung, Mehr und weniger Content umgegangen werden soll. Dies ist nicht Aufgabe des Entwicklers, der meist kein Auge für das Design hat.

Navigation beim Design berücksichtigen
Auch bei der Navigation ist Vorsicht geboten. Wird die Navigation z.B. in Form von Tabs dargestellt dann kann man nicht einfach beliebig viele Navigationspunkte zulassen. Aber auch bei vertikalen Navigationen muss mit damit gerechnet werden, dass nicht zu viele Weißräume entstehen, bzw. große Unterschiede in der Spaltenhöhe.
Fragen, die man sich stellen sollte:

Wieviele Ebenen sollen dargestellt werden und sind diese editierbar/erweiterbar im CMS.
Können Redakteure Die Top-Level Navigation beeinflussen?
Kommt eine Breadcrumb Navi zum Einsatz?

Performance Entscheidungen spielen auch eine Rolle. In CoreMedia gibt es verschiedene Caching Layer. Bei der Navigation kommen hauptsächlich die DataViews zum Einsatz, um die „teuere“ Navigationsstruktur zu berechnen und zu cachen. Verändert sich irgend etwas and der Struktur oder selbst im Namen Navigations items oder wird etwas hinzugefügt, dann werden die kompletten Dataviews für die Navigation invalidiert was zur Neuberechnung führt. Das kann unter Umständen die Seite unbenutzbar machen. Auch kann einen Invalidierung sich massiv auf die Reindizierung in der Suchmaschine führen.

Erstelle CSS Regeln für alle möglichen HTML Elemente
Im Design mag man vielleicht nur zwei Level von Headings berücksichtigt haben aber eine „Liste“ oder „Blockquote“ nicht. Das Problem ist, dass wenn man einen Richtext Editor nutzt und die Funktion nicht abschaltet, dann werden diese Elemente auch irgendwann vom Redakteur benutzt werden. Besser man denkt vorher dran.

Gehe davon aus, dass HTML Elemente gestapelt werden
Wird das Design noch standhalten, wenn z.B. Heading Elemente gestapelt werden? Oder einzelne Paragraphen? Stimmen noch die Abstände?
Was wenn Bilder in Listen eingefügt werden?
Was wenn im Richtext ein Bild eingefügt und ausgerichtet wird? Wie wird der Text fliessen?
Ein CMS ist wie ein Lego System. Man entwirft und implementiert einzelne Content Elemente und der Redakteur setzt sie zusammen. Jede beliebige Zusammenstellung der Content Elemente muss aus Designsicht funktionieren.

CSS nutzen um Styleguide und Semantik zu erzwingen
Wir beobachten folgendes Phänomen häufiger nachdem die Redakteure sich an das CMS gewöhnt haben. Sie erkennen z.B., dass H1 einen fett und groß dargestellten Text erzeugt. Das Resultat ist, dass H1 an allen mögliche Stellen plötzlich verwendet wird, um die Wichtigkeit eines Satzes hervorzuheben.
Um dem vorzubeugen sollte man einen Styleguide erstellen und den Nutzern die korrekte Nutzung von Markup erklären. Das Styleguide dient auch als Dokumentation um auch später Nutzern, die vielleicht nicht an einem Training teilgenommen haben, die Semantik zu erklären.
Im Falles des Beispiels mit dem H1 kann man z.B. einen CSS Selektor nutzen, um nur das erste H1 zu stylen, sodass keiner auf die Idee kommt H1 rein als Styling Element zu nutzen. Das sind alles keine Haarspaltereien, aus SEO Gründen ist es ganz wichtig nur ein H1 zu haben.

Testen mit echtem Content
Der Workflow beim CMS Design sieht folgendermaßen aus:
Design (Photoshop) -> CSS/HTML -> CMS Template
Im zweiten Schritt kann man bereits das Design testen mit echtem Content. D.h. die Boxen mal kleiner mal größer machen. Mal 1- zeilige Headlines mal 2-zeilige Nutzen usw. Auf diese Weise kann man schon vor der Implementierung viele Fehler und Nachfragen ausmerzen. Idealerweise kommen Nachfragen von den Entwicklern. Im schlimmsten Fall setzen sie es einfach um und die Überraschung kommt dann beim Livegang. Das macht eben einen guten CMS Designer aus.

Funktionalität aus dem Richtext Editor entfernen
Man sollte so viele Funktionen aus dem Richtext Editor wie möglich entfernen. Je weniger Funktionalitäten zu Verfügung stehen desto sicherer kann man sein was das Design angeht. Das schränkt natürlich die Flexibilität ein. Die Frage ist wieviel Flexibilität notwendig ist. Der Richtext Editor lässt sich auf viele verschiedene Arten nutzen. Habe viele Kunststücke erlebt was in dem XML des Editors implementiert wird. In einem Projekt hatte ich selbst mal eine Expression Language implementiert wo man mit einer Dot Notation auf verschiedene Properties zugreifen konnte wie: this.image.caption oder this.article[0].image.caption.

CSS zum Richtext Editor hinzufügen
Es gibt eine CSS Datei die vom Editor eingelesen wird. Diese kann um eigene CSS Klassen erweitert werden, und der Redakteur kann im Richtext diese verwenden. Ein anderer Vorteil ist, dass in der Preview sofort die Änderungen sichtbar sind.

Teilen:

Relevante Artikel

Advanced AI applications for the insurance domain

Advanced AI applications for the insurance domain

Has an automobile accident ever happened to you? You are probably aware of the difficulties associated with filing an auto insurance claim if you have

Framework für die Einführung von Generative AI

Framework für die Einführung von Generative AI

Der Leitfaden zur Einführung von Generative AI in Ihrem Unternehmen: Ein systematisches Framework In der Ära der digitalen Transformation ist Generative AI nicht mehr nur

Wie können Large Language Modelle wie GPT-4 Geschäftsprozesse optimieren?

Wie können Large Language Modelle wie GPT-4 Geschäftsprozesse optimieren?

Wussten Sie, dass KI-Modelle wie GPT-4, Gemini, LLama2, Mistral & Co. dabei helfen können, die Leistungsfähigkeit Ihres Unternehmens zu steigern? Diese großen Sprachmodelle sind revolutionäre