Update to this blog series
In the first part, we announced that we would continuously report on the progress of the project. "Continuity" is a peculiar thing - as we all know, wish and reality are two different things. So it took some time until we could report back here. ¯\_(ツ)_/¯.
Since we have advanced the project in the meantime, there is the possibility of a reorientation from a chronological logbook to a topic-centered logbook.
Today on the program: content elements.
Content elements - Reduce them to the max
The heart of a content management system are the available content elements. Two questions play the decisive role for every project:
- Which content elements are really needed to represent the planned content of the website in a structured way?
- How can these elements be implemented in the backend in such a way that they can be used by the system's editorial staff easily and (only) in the intended sense?
In answering these questions, our credo is: "Less is more". As a counter- and negative example, website construction kits such as Jimdo or Wix, as well as "all-round" themes for WordPress, for example, can be mentioned here. These systems come with a colorful bouquet of countless content elements with, again, countless configurable options. At first glance, this sounds promising, but in practice, this places unsolvable demands on the editorial team and thus brings enormous problems with it - especially if a system has a long lifespan.
If the option exists to "design" every single page, every news article and every news item completely differently, then sooner or later this option will be used. This may correspond to the individual design sensibilities of an editor, but it rarely serves the requirement for the target group to offer information in a clear and structured manner.
This is also of little use when it comes to complying with CI design specifications. Such a "layout" can quickly blow up in your face - at the latest when displayed on a smartphone.
Furthermore, the editorial maintenance is complicated by the overload of options and thus becomes a real time eater and thus a cost factor.
Another aspect is that one quickly blocks the options for the future development of the project; e.g. with regard to playing out the content via other channels (API connections, RSS) as well as in the more distant future with regard to a system change with content migration.
Particularly in the case of an extensive and content-driven project such as the ISB website, we therefore see it as one of our central tasks to ensure that the content can be easily and conveniently maintained by the editorial team and that it is presented in a comprehensible, easily understandable and structured manner for the website user. And above all, that this quality of content presentation is permanently supported and secured by the system we are building.
Editorial content elements
To achieve these goals, we approached our partners at the ISB with a minimum proposal of content elements in the second sprint and continuously updated the requirements for the content elements in the subsequent sprints. In the meantime, this has resulted in a grown but compact set of just under ten content elements for the content structure of individual pages:
- Text with image
- Image / Image carousel
- Video and Audio
- Download (in two layout-Options)
Some of these content elements have no defined purpose and can be used freely (e.g. text or image element). Other elements, on the other hand, are designed for a clearly defined purpose and can only be used for this purpose. For example, the "Section Header" element is, superficially viewed, used to generate a headline. In detail, however, it also has a function: The respective page is divided into several sections with independent content using this element. For the regular website user, we achieve this through the dedicated, visual design of the headline. For search engines and in terms of accessibility, this is additionally achieved through clean semantic markup of the source code. We ensure the correct use of the element - and thus the quality assurance of the content structure - through clearly defined rules that we have anchored in the CMS. In this case, the system is configured so that the section header can only be used in appropriate positions. This means that this headline type cannot be used within body text or even within other content elements.
This example shows how crucial it is to plan well in advance and then use content elements correctly, and how significant an impact this has on the long-term success of a project.
Column set – Nope!
Basically, the above-mentioned elements can be combined or stacked as desired when building the pages. I.e. the elements can be placed above and below each other - but not next to each other in columns. After close coordination with the ISB, we deliberately refrain from using such column elements (e.g. extensions like "container" or "grid elements"). The reason is simple: The introduction of freely assignable columns would create new degrees of freedom and additional complexity. From an editorial point of view, this is difficult to control, and for the end user it results in no added value whatsoever. The editorial team can create virtuoso layouts, but at the price of poor semantics, unclear references in different responsive viewports, and additional editorial effort.
It's valuable to keep reminding ourselves that we're talking about CMS: Content management systems. Not Indesign, Quarkxpress or even Photoshop. In short: A CMS is not a layout system! The fact that this hasn't made its way into every nook and cranny after well over 10 years of responsive websites never ceases to amaze.
Instead of editorial (!) column systems, we rely on a stringent concept for dividing the content of the page into a content area and a sidebar area. The latter is reserved for certain functions and cannot be arbitrarily occupied with content modules. This ensures that the user finds the expected content types at the same positions.
Next to this, we have a single element that is designed in two columns in the tablet and desktop state: "Text with image". This element displays an image (on the left or at the top in the mobile viewport) with an optional copyright and caption as well as an associated, possibly longer body text (on the right or at the bottom). It is used in particular for the display of publications and portrait-format images with content-related reference. The fixed structure of the element guarantees that the relationship between image and text is given on all devices and that images are not merely inserted as decorative ornaments.
Functional content elements
In addition to the above-mentioned editorial content elements for page construction, we have implemented modules that fulfill certain functions and, depending on the editorial configuration, automatically generate the content for lists or teasers, for example. These elements are particularly interesting for the construction of index- and overview pages; with them, editorial intervention for these page types will be reduced to a minimum in the future, as editorial activities are automated. This is where the too often unused potential of structured data and the strength of a well-designed CMS unfolds. We will go into the concepts and our solutions for this in later blog posts.
As already mentioned in the project introduction: in this project we expect a fluctuation of editors over time and would like to make the backend as self-explanatory as possible. In addition to the quality assurance principles already listed, which are an immanent part of the overall concept as well as the detailed concept of individual content elements, we pay special attention to backend optimization. For us, this is actually self-evident, but not infrequently we have seen it differently. In concrete terms, this means that we do not provide sprawling degrees of freedom in the individual content elements, but only provide the options that should be used sensibly by editors and that actually have an impact. In addition, we supplement fields in the backend with explanatory short descriptions, which are a great help for new editors in particular. All in all, this saves editors a lot of time in the end and guarantees a smooth workflow in productive use.
Style-Guide and documentation – Do’s and Dont‘s
Unfortunately, the truth is that not every possible misuse can be avoided. To help, we've built a style guide directly in the system that explains what which content element should (and shouldn't) be used for and shows the different manifestations of the element.
As a pleasant side effect, we thus get pages that are rendered by the TYPO3 system and that we can use as a basis for our visual regression tests. Since these pages also remain in the system later for the editors' orientation, we can do without our own test database.
- Reduce the number of content elements
- Definition of specific purposes for content elements
- Avoidance of column sets and thus effective reduction of complexity as well as ensuring content references and semantics
- Optimize backend options for the editors
- Documentation for editors in the system
Or: Make things as simple as possible; but not simpler.