A look behind the scenes - ISB Sprint I

In the first sprint, we set the foundations for a successful project at different levels. In this article, we will focus on three central aspects:

• Concept
• Design
• Technical setup

Conception

Conceptual design is divided into two areas that are closely intertwined: The development of the information architecture on the one hand and the data model on the other.

Information Ar­chi­tec­ture

By "information architecture" we mean the structure of the website and its content according to hierarchies, semantics and taxonomies - especially from the point of view of the target group. We have clarified which content should be accessible, clusterable and searchable, and how. Here, there are many points of contact with the user experience (UX) in the sense of good user guidance (e.g. through a clean navigation concept), which is also always considered.

We had already clarified our ideas with a wireframe when we took part in the tender; we fleshed this out and expanded it in the first sprint. In the process, we incorporated a lot of interesting information that we gained from our research into the use and handling of the ISB editors with the old system (which was not converted to TYPO3). In the old system, there are a number of different document types (downloads, contact persons, materials) as well as different modules. This bears the risk of a certain "proliferation" – especially when a system offers too much freedom, editors change frequently and the dedicated purpose of certain modules is not apparent to the editorial team.
Here, there is a clear desire for the new system to become more stringent and consistent in order to make content easily accessible and structured for the frontend user. The solution here, as so often, is: less is more. We have defined a simple basic set of content elements with clearly defined purposes and only the essential options. We deliberately refrain from using grid systems (e.g. "containers" or "grid elements") for layout purposes.

Data Model

While we focus on the needs of the frontend user in the information architecture, we look at the data model to see how the requirements can be realized "under the hood" in TYPO3. In doing so, we consider three major questions:

• How do we meet the specific requirements of the information architecture?
• Which aspects should be considered with regard to the expandability of the system in the context of later expansion stages and functions?

And last but really not least:

• How do we ensure a good user experience in the backend for the editorial team and map data structures in a comprehensible way?

This last point in particular is crucial for us. Because while we only develop the system for a few weeks, the editorial team should be able to work efficiently and happily with the system for many years.

Technically, all document types are content on the website; therefore, we decided to implement them as pages as well. This makes it easier for editors to cross-link different data in different places in the system (as teasers, related content, etc.).

Many of the contents have dedicated contact persons, which are also output in the frontend of the website. We have also created a concept and data model for this that maps the various requirements well. We will go into more detail about the concept in a later post when we get to the technical implementation of the same.

Design

An important component in the first sprint is the development of a guideline for the graphical implementation. This does not have to be finalized in all details (at the current time, for example, it is not yet clear which content elements there will be). In order to be able to easily derive new elements in the course of further work, we have decided to proceed according to "atomic design". In concrete terms, this means that we defined essential design building blocks in the first sprint and agreed them with our customer. Small building blocks, so-called "atoms" are e.g.

• Colors and their purpose
• Iconsets
• Typography incl. font sizes and font styles as well as inline elements
• Headline styles
• Button and form styles

Much more advanced elements that are built from these atoms, so-called "organisms", are e.g. the header and footer, but also teaser elements, which we have also already defined. We wrote down a general brief overview of Atomic Design in this blog post.

Technical Setup

Of course, we need a TYPO3 instance that we can continuously expand in the further sprints. We have a "skeleton" available at F7 that facilitates this recurring work and defines our internal standards. As part of the technical setup, we have also set up our build chain and prepared our review server, on which we can also perform our internal QA and acceptance with the customer for this project.

So even though the frontend looks very sober at the moment, we have a fully installed TYPO3 system, including automatic build chain, code quality assurance, automatic deployment to our review server and a test suite including visual regression tests.

Technical Research

In addition to the actual implementation, we have also started research and testing on larger issues. For example, Solr is to be used as an onsite search. In addition, newsletters are to be sent and archived via the system. We will certainly go into more detail on these topics later.