Blick hinter die Kulissen – ISB Sprint I

Im ersten Sprint legen wir die Grundsteine für einen erfolgreichen Projektverlauf auf unterschiedlichen Ebenen. Wir wollen in diesem Beitrag auf drei zentrale Aspekte eingehen:

• Konzeption
• Design
• Technisches Setup

Konzeption

Die Konzeption teilt sich in zwei Bereiche, die eng miteinander verwoben sind: Die Entwicklung der Informationsarchitektur auf der einen Seite und das Datenmodell auf der anderen Seite.

In­for­ma­ti­ons­ar­chi­tek­tur

Unter „Informationsarchitektur“ verstehen wir die Struktur der Website und ihrer Inhalte nach Hierarchien, Semantik und Taxonomien – insbesondere aus Sicht der Zielgruppe. Wir haben geklärt, welche Inhalte wie erreichbar, clusterbar und durchsuchbar sein sollen. Hier gibt es viele Berührungspunkte mit der User Experience (UX) im Sinne einer guten Nutzerführung (z.B. durch ein sauberes Navigationskonzept), die auch immer mitgedacht wird.

Bereits zur Teilnahme an der Ausschreibung hatten wir unsere Ideen anhand eines Wireframes verdeutlicht; dieses haben wir im ersten Sprint konkretisiert und erweitert. Dabei sind viele interessante Informationen eingeflossen, die wir aus unserer Recherche zum Einsatz und Umgang der ISB-Redakteure mit dem Altsystem (das nicht auf TYPO3 umgesetzt wurde) gewonnen haben. Im alten System gibt es eine Reihe unterschiedlicher Dokumententypen (Downloads, Ansprechpartner*innen, Materialien) sowie unterschiedlicher Module. Dies birgt die Gefahr eines gewissen „Wildwuches“ – gerade dann, wenn ein System zu viele Freiheiten bietet, Redakteur*innen oft wechseln und im System der dedizierte Einsatzzweck bestimmter Module nicht für die Redaktion ersichtlich ist.
Hier besteht an das neue System der klare Wunsch, stringenter und konsistenter zu werden um für den Nutzer im Frontend Inhalte gut erreichbar und strukturiert zur Verfügung zu stellen. Die Lösung ist hier wie so oft: Weniger ist mehr. Wir haben dazu ein einfaches Basis-Set von Content-Elementen mit klar definierten Einsatzzwecken und nur den wesentlichen Optionen definiert. Auf den Einsatz von Grid-Systemen (z.B. „Container“ oder „Grid Elements“) zu Layoutzwecken verzichten wir ganz bewusst.

Datenmodell

Während wir bei der Informationsarchitektur die Bedürfnisse des*der Frontend-User*innen im Fokus haben, haben wir beim Datenmodell im Blick, wie sich die Anforderungen „unter der Haube“ in TYPO3 realisieren lassen. Dabei berücksichtigen wir drei große Fragestellungen:

• Wie erfüllen wie die konkreten Anforderungen aus der Informationsarchitektur?
• Welche Aspekte sollten in Hinblick auf die Ausbaufähigkeit des Systems im Rahmen späterer Ausbaustufen und Funktionen berücksichtigt werden?

And last but really not least:

• Wie sichern wir eine gute User*in Experience im Backend für die Redaktion und bilden Datenstrukturen nachvollziehbar ab?

Gerade dieser letzte Punkt ist für uns entscheidend. Denn während wir nur einige Wochen das System entwickeln, soll die Redaktion über viele Jahre effizient und glücklich mit dem System arbeiten.

Technisch gesehen sind alle Dokumententypen Inhalte auf der Website; daher haben wir uns entschieden, diese auch als Seiten (Pages) zu realisieren. Dies macht es für die Redakteur*innen nachvollziehbar und einfacher, unterschiedliche Daten an verschiedenen Stellen im System querzuverlinken (als Teaser, Related Content usw.).

Viele der Inhalte haben dedizierte Ansprechpartner, die auch im Frontend der Website ausgeben werden. Hierfür haben wir ebenfalls ein Konzept und Datenmodell erstellt, das die verschiedenen Anforderungen gut abbildet. Auf das Konzept werden wir in einem späteren Beitrag genauer eingehen, wenn wir an die technische Umsetzung desselben gehen werden.

Design

Eine wichtige Komponente im ersten Sprint ist die Ausarbeitung einer Guideline für die grafische Umsetzung. Diese muss nicht in allen Details final ausdefiniert sein (zum aktuellen Zeitpunkt steht z.B. noch nicht fest, welche Inhaltselemente es alle geben wird). Damit wir im Rahmen der weiteren Arbeiten hier unproblematisch neue Elemente einfach ableiten können, haben wir uns für ein Vorgehen nach „Atomic Design“ entschieden. Konkret heißt das, dass wir wesentlichen Design-Bausteine im ersten Sprint definiert und mit unserem Kunden abgestimmt haben. Kleine Bausteine, sog. „Atome“ sind dabei z.B.

• Farben und deren Einsatzzweck
• Iconsets
• Typografie inkl. Schriftgrößen und Schriftschnitte sowie Inline-Elemente
• Headline-Styles
• Button- und Formular-Styles

Wesentlich höher entwickelte Elemente, die aus diesen Atomen aufgebaut werden, sog. „Organismen“, sind z.B. der Header und Footer, aber auch Teaser-Elemente, die wir ebenfalls bereits definiert haben. Einen allgemeinen Kurzüberblick zum Thema Atomic Design haben wir in diesem Blogbeitrag aufgeschrieben.

Technisches Setup

Natürlich benötigen wir eine TYPO3-Instanz, die wir in den weiteren Sprints kontinuierlich ausbauen können. Wir haben bei F7 ein „Skeleton“ zur Verfügung, das uns diese wiederkehrende Arbeit erleichtert und unsere internen Standards definiert. Im Rahmen des technischen Setups haben wir ebenfalls unsere Build-Chain aufgebaut und unseren Review-Server vorbereitet, auf dem wir auch für dieses Projekt unsere interne QA und die Abnahme mit dem Kunden durchführen können.

Auch wenn das Frontend momentan noch sehr nüchtern aussieht, haben wir also ein fertig installiertes TYPO3-System, inkl. automatischer Build-Chain, Sicherstellung der Code-Qualität, automatisches Deployment auf unseren Review-Server und eine Test-Suite inkl. Visual Regression Tests.

Technische Recherche

Neben der konkreten Umsetzung haben wir außerdem Recherche und Testings zu größeren Themen begonnen. So soll als Onsite-Search Solr zum Einsatz kommen. Außerdem sollen über das System Newsletter versendet und archiviert werden. Auf diese Themen werden wir später sicher umfangreicher eingehen.