The design and front-end development for a website where non-technical users edit the content has a few pitfalls. There is a difference between having full control over the output markup and not. Unfortunately, it often happens with CoreMedia projects that designers who are not familiar with the depths of enterprise content management deliver files that look good in Photoshop, but look terrible after being transferred to CMS templates and filled with real content. There is also a very big difference between web designers and print designers. They are two different worlds. The magic word is: dynamics .
Below we want to shed light on the problem and give some tips.
Nowadays, customers naturally want to be able to edit their content themselves, which means that the designs (usually Photoshop or Sketch files) are converted into templates. Taking the special features of a CMS system into account during the design phase helps to avoid unpleasant surprises and wasted time later on.
Know your enemy (unstructured HTML)
Can editors insert HTML tags into the content, e.g. using rich text editors or directly as a separate document type (CMHtml)? The more freedom the editor has, the more defensively the design must be able to deal with them. The better way here is to provide pre-fabricated structures that the editor can fill. We have seen so often that large, unstructured HTML blocks can destroy the entire layout and, worse, bring the site to a standstill. Some people use these HTML document types so extensively that you wonder whether static HTMLs would not be more suitable than an enterprise CMS. These HTML blocks do not exist in empty space, but must always be viewed in the context of a CMS. You have no control over what is inserted into these HTMLs. Sometimes these are external agencies who are not familiar with a CMS system and are only going by design considerations.
Stay consistent
No matter how flexible the CMS is, it is important to stay consistent in templates. Training editors becomes much easier when the document types and view settings they have to work with are consistent across all sites.
When working with structured content (e.g. article overview page, which displays all titles with a teaser text and image) it is helpful to consider each article block as a repeating block. With CSS3 selectors it is then easy to treat different rows differently (e.g. alternating colors for the rows). There should also be no nested DIVs, each listing should be an independent block without dependency on a parent div.
If the user can insert large amounts of free HTML, you cannot assume that they will remember to add the corresponding CSS classes in the rich text. The design / CSS must take this into account.
Content height or block height are not fixed
On the web, it is never a good idea to assume that any element will have a certain height. Even if you have control over the content, font resizing can cause the design to fall apart and, for example, unwanted overflows or breaks to occur.
You also have to take into account that editors sometimes add less text and sometimes more. When initially designing in Photoshop, you have to imagine how boxes will look with less text (avoid white space) or more text (make the box bigger or add „more“).
Grid-based layouts have a particular problem here. If, for example, several boxes are arranged next to each other in columns, then this looks good with the single-line Lorem Ipsum. But what if the headlines are sometimes 1 line and sometimes 2 lines? This makes the design look very busy. A different layout might have been chosen here if the problems had been known. If the designer passes the files on to the front-end developer and has already thought through these scenarios, then he retains control and avoids unnecessary questions if expensive implementation has already taken place. As a designer, you have to decide how to deal with changes in text size and more or less content. This is not the developer’s job, who usually has no eye for design.
Consider navigation in the design You
also need to be careful with navigation. If the navigation is presented in the form of tabs, for example, you cannot simply allow as many navigation points as you want. But even with vertical navigation you have to make sure that there is not too much white space or large differences in the column height.
Questions you should ask:
How many levels should be displayed and are they editable/expandable in the CMS?
Can editors influence the top-level navigation?
Is a breadcrumb navigation used?
Performance decisions also play a role. There are various caching layers in CoreMedia. DataViews are mainly used for navigation to calculate and cache the „expensive“ navigation structure. If anything changes in the structure or even in the name of navigation items or if something is added, then the entire dataviews for navigation are invalidated, which leads to a recalculation. This can make the page unusable under certain circumstances. An invalidation can also have a massive impact on reindexing in the search engine.
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.
Remove functionality from the Richtext Editor
You should remove as many functions from the Richtext Editor as possible. The fewer functions available, the more secure you can be in terms of design. This of course limits flexibility. The question is how much flexibility is necessary. The Richtext Editor can be used in many different ways. I have seen many tricks implemented in the editor’s XML. In a project I once implemented an expression language where you could access various properties using a dot notation such as: this.image.caption or this.article[0].image.caption.
Add CSS to the Richtext Editor
There is a CSS file that is read by the editor. This can be extended with your own CSS classes, and the editor can use these in the richtext. Another advantage is that the changes are immediately visible in the preview.
