tollwerk® GmbH | Responsive Webdesign · TYPO3 · Accessibility & Performance | Werbeagentur · Nürnberg

Fischer Automobile — Barrierefreies TYPO3 mit Living Styleguide

Geschrieben von Joschi am 25.09.2017 - 6 Kommentare

Als die Marketingabteilung der Fischer Automobile GmbH im August 2016 auf uns zukam und den Relaunch ihrer Unternehmenswebsite anfragte, war zunächst nicht klar, dass sich damit eines der umfangreichsten und vielseitigsten Projekte unserer Geschichte anbahnen würde. Klar war dagegen, dass die Projektanforderungen ganz wunderbar zu einigen unserer Schwerpunkte passten:

  • Responsives / adaptives Design, optimiert für alle Plattformen und Geräteklassen
  • TYPO3 als Content Management System
  • Erstmalige, plakative Darstellung des umfangreichen Neu- und Gebrauchtwagenbestands auf der eigenen Website (und damit Ablösung eines externen Services)
  • Anbindung an verschiedene Schnittstellen und Drittsysteme, u.a. täglicher Fahrzeugdatenimport und das Einlesen von Stellenangeboten aus einer externen HR-Software
  • Leistungsstarke Suche über alle Inhalte und Fahrzeuge
  • Integration einer E-Commerce-Lösung und weiterer Marketing-Instrumente in einer späteren Projektphase

Fischer zählt zu den Großen der Branche: Mit 4 Standorten, rund 500 Mitarbeitern und einem ständigen Pool von 1.500 Neu- und Gebrauchtfahrzeugen kann das Unternehmen auf 35 erfolgreiche Geschäftsjahre zurückblicken. In einem ersten Sondierungsgespräch wurde schnell deutlich, dass wir trotz straffen Zeitplans und eines fixierten Budgets große Lust auf die Herausforderung hatten. Nicht minder groß war dann auch unsere Freude, als wir im Oktober 2016 den Zuschlag für das Projekt erhielten.

Türschild der Marketing-Abteilung bei Fischer Automobile, überschrieben mit "Marketing — Zentrale des Wahnsinns"

Vorüberlegungen

Wir wären nicht wir, hätten wir uns neben den kundenseitigen Anforderungen nicht intern noch ein paar Zusatzkriterien zurechtgelegt, die wir ergänzend erfüllen wollten:

  • Da das Projekt umfangreich werden und ein Großteil unseres Teams über längere Zeit gemeinsam daran arbeiten würde, schien der Einsatz einer Komponentenbibliothek angebracht. Allerdings hatten wir bis dahin — von einfachen Ansätzen im kleineren Maßstab abgesehen — noch kein Projekt wirklich umfassend und dauerhaft durch einen "Living Styleguide" flankiert.
  • Auch wenn die primäre Zielgruppe der Website dies nich unbedingt fordern mag, sollte unser Ergebnis trotzdem besonderen Fokus auf Barrierefreiheit legen und selbstredend dem Prinzip des Progressive Enhancement folgen, also beispielsweise auch mit einfachen Endgeräten oder ohne JavaScript nutzbar sein.
  • Den tagesaktuellen Fahrzeugbestand vollumfänglich auf die eigene Website zu bringen mag vielen Autohändlern als überflüssiger Aufwand erscheinen, leisten dies doch auch die bekannten Automobilbörsen wie mobile.de oder AutoScout24. Um konkurrenzfähig zu sein, musste unsere Website also wenigstens ein vergleichbares, wenn nicht besseres Benutzererlebnis bieten.

Konzept- & Designphase

Den Auftakt markierte ein halbtägiger, intensiver Kick-Off-Workshop mit den Projektverantwortlichen auf Kundenseite. Ziel war es, Grundlagen und Ziele zu erfassen, Erwartungen an die neue Website einzusammeln und den Grundstein für eine gemeinsame Domänensprache zu legen. Der Kunde war gut vorbereitet: Er hatte sowohl funktionale, als auch designmäßige Wunschvorstellungen zusammengetragen, Mitbewerber studiert und selbst Skizzen gefertigt. Unser Hauptansprechpartner, Online Marketing Manager und nebenberuflicher Webentwickler, erklärte sich mit unserem komponentenbezogenen Entwurfs- und Entwicklungsansatz einverstanden — eine ungeheuer wichtige Voraussetzung für den weiteren Prozess.

Umfassendes Brainstorming im Form eines Kick-Off-Workshops
Foto-Collage mit Skizzen und verschiedenfarbigen Post-It-Zetteln an der Wand, Ergebnisse des initialen Kick-Off-Workshops

Unterstützt von Markus Schuster entwickelten wir bis zum Jahresende in mehreren Iterationen ein umfassendes Designkonzept, Komponente für Komponente, beginnend mit einfachsten typografischen Vorgaben über komplexere Bausteine bis hin zum überspannenden Präsentations-Layout. Die Reihenfolge spielt bei diesem Vorgang eine besondere Rolle: Anders als nach wie vor von vielen Auftraggebern erwartet, steht hier nicht das Gesamtlayout der Präsentation am Anfang, das im Folgenden weiter verfeinert wird. Vielmehr verläuft der Prozess "Bottom-Up", ausgehend von den kleinsten Bausteinen wie Links und Buttons, die dann legoartig zu immer komplexeren Komponenten kombiniert werden. Das hohe Maß an Vorstellungskraft, das der Prozess verlangt, wird zum Ende hin durch ein in sich stimmiges, sehr robustes und leicht zu bedienendes Designsystem belohnt. Im Fischer-Projekt wurden die Entwürfe mithilfe der Layout-Software Sketch erstellt.

Umfassendes, komponentengetriebenes Screen-Design für alle Geräteplattformen
Miniaturausdrucke des vollständigen Screen-Designs, aufgehängt an einer weißen Wand

Komponentenbibliothek

Zum Umsetzungsstart im Januar 2017 war es notwendig, die entworfenen Komponenten ans Entwicklerteam zu kommunizieren und eine Plattform einzurichten, mit deren Hilfe es den schon im Design durchlaufenen Prozess auch in der Umsetzung nachvollziehen konnte. Grundlage hierfür kann eine Komponentenbibliothek sein, die es erlaubt, einzelne Bausteine isoliert und jenseits der eigentlichen Website umzusetzen, zu optimieren und ausgiebig zu testen. Unsere Entscheidung für die Open-Source-Software Fractal als Tool zum Aufbau einer Komponentenbibliothek erforderte zunächst einige Vorarbeit.

Das Schicksal vieler Komponentenbibliotheken — manchmal auch als "Design Systeme" oder "Living Styleguides" bezeichnet — wird oft durch (ungewollte) Nachlässigkeit besiegelt: Zu Beginn eines Projekts werden die erarbeiteten Entwürfe mit großer Motivation in eine anschauliche Struktur gebracht, die als Vorlage für die Umsetzung dient. Während der Implementierung werden häufig Anpassungen oder Ergänzungen notwendig, die in den Styleguide rückübertragen werden müssen, soll dieser aktuell bleiben. Nicht selten fehlt hierfür jedoch die Priorität, Zeit oder Motivation, so dass Styleguide und Produkt nicht selten auseinanderlaufen. Die Komponentenbibliothek verwildert und wird irgendwann nicht länger genutzt — schließlich zählt ja vor allem das reale Produkt. Abhilfe könnte schaffen, wenn Komponentenbibliothek und Produkt nicht zwei parallele Systeme wären, sondern sich aus ein und denselben Quellen speisen würden — so könnten beide Plattformen dauerhaft synchron bleiben.

Unser Anspruch war es also, TYPO3 als technische Basis der neuen Website und Fractal als Komponentenbibliothek so miteinander zu koppeln, dass die Synchronizität jederzeit gewährleistet bleibt. Uns war kein bestehendes Beispiel für diese Hochzeit bekannt, also mussten wir selbst Hand anlegen: Dank der offenen Architektur beider Systeme war es möglich, eine Brücke zwischen ihnen herzustellen. Unsere Ergebnisse — ein Zusatzmodul für Fractal und ein dazu passendes Gegenstück in Form einer TYPO3-Extension — tuen gute Dienste und stehen zwischenzeitlich als Open Source Module zum Download bereit. Die TYPO3-Fractal-Bridge leistet im Wesentlichen zwei Dinge:

  • Durch die geeignete Organisation von Programmcode auf TYPO3-Seite lassen sich funktionale und Design-Komponenten definieren, deren Merkmale von extern ausgelesen werden können. Unsere Fractal-Erweiterung nutzt diese Schnittstelle ins TYPO3, um per Knopfdruck einen aktuellen Komponentensatz zu beziehen und die entsprechenden, Fractal-internen Strukturen aufzubauen.
  • TYPO3 nutzt mehrere Techniken, um HTML-Quellcode zu generieren, darunter die Templating-Engine Fluid sowie die TYPO3-Konfigurationssprache TypoScript. Vielschichtige Abhängigkeiten machen eine "Simulation" der Funktionsweise von TYPO3 bei der HTML-Ausgabe unmöglich. Mit unserer Fractal-Erweiterung gehen wir daher den entgegengesetzten Weg und ermöglichen die Nutzung von TYPO3 als Rendering-Engine für Fractal. Mit einfachen Worten: Zur Darstellung einer Komponente im Fractal wird im Hintergrund TYPO3 zur Ausgabe bemüht.

Die Live-Integration der beiden Systeme hilft also bei der Vermeidung doppelter Strukturen (und damit überflüssiger Arbeit) und sorgt gleichzeitig für unbedingte Synchronizität zwischen Dokumentation und realer Website. Mit einer unabhängigen, aber zu 100% repräsentativen Komponentenbibliothek haben alle Projektbeteiligten — Designer, Entwickler und Entscheider — jederzeit ein mächtiges Werkzeug zur gegenseitigen Kontrolle und Kommunikation an der Hand.

Darstellung einer Tablist-Komponente im Living Styleguide (Fractal-Komponentenbibliothek)
Screenshot einer Komponentendarstellung in der Fractal-Komponentenbibliothek

Damit wir jedoch die Stärken des Zusammenschlusses voll ausschöpfen konnten, war zusätzlich eine Anpassung unserer bisherigen Arbeitsweise notwendig. Um eine isolierte Betrachtung aller Komponenten zu ermöglichen, bedarf es einer sehr sorgsamen — eben strikt komponentenorientierten — Organisation der beteiligten Technologien:

  • Konfigurationen, Templates und alle Programmteile (CSS, JavaScript, etc.) müssen modular strukturiert und umgesetzt werden.
  • Je mehr Komponenten am fertigen Produkt beteiligt sind, umso größer ist die Bedeutung, die einer durchdachten, gut bedienbaren Struktur zukommt. Vor diesem Hintergrund bietet es sich an, wirklich sämtliche projektspezifische Bausteine in einer zentralen TYPO3-Extension zu organisieren, anstatt sie auf mehrere Extensions oder gar unabhängige Verzeichnisse zu verteilen.
  • Für den Nutzer einer Website ist ihr komponentenbasierter Hintergrund letztlich irrelevant. Ganz im Gegenteil: Er profitiert am meisten, wenn nur möglichst wenige, kompakte Fragmente übertragen werden. Dies steht in gewisser Weise im Widerspruch zur Granularität, die für den Betrieb einer Komponentenbibliothek notwendig ist. Eine durchdachte Toolchain mit hohem Automatisierungsgrad kann dafür sorgen, dass beide Ansprüche ohne eine Explosion des Aufwands bedient werden können: Modulare Zwischenresultate für die Komponentenbibliothek und kombinierte, hochoptimierte Endergebnisse für die eigentliche Website.
  • Für zukünftige Projekte stellen wir uns vor, die modularen Komponenten für automatisiertes, visuelles Regression Testing nutzen zu können — doch auch hier hinein wird noch einiges an Vorbereitung gehen müssen.

TYPO3, Gulp & Co.

Die neue Fischer-Website sollte in einer modernen Betriebsumgebung platziert werden:

  • Aktuelle TYPO3 Long Term Support (LTS) Version (8.7)
  • PHP 7.0 oder 7.1
  • MySQL 5.6

Unsere Toolchain — also die Zusammenstellung und das Zusammenspiel der Programme, die uns bei der Umsetzung im Hintergrund unterstützen — hat bereits eine gewisse Tradition. In der Regel übernimmt die Grundeinrichtung unser speziell dafür entwickelter Yeoman Generator. Im Fall der Fischer-Website zählen zur Arbeitsumgebung:

  • Ein Node.js-Server mit Gulp als Workflow-Toolkit
  • Individuelle Gulp-Tasks zur Automatisierung von Hintergrundvorgängen, darunter
    • CSS-Verarbeitung (PostCSS) und -Optimierung
    • JavaScript-Verarbeitung und -Optimierung
    • Dynamische Erzeugung von SVG-Sprites mit iconizr (hauseigen)
    • "Critical Path"-Optimierung der CSS- und JavaScript-Ladereihenfolge mit shortbread (hauseigen)
    • HTML-Validitätsprüfung
  • Periodische Programmaufrufe (Cronjobs), etwa zur Optimierung und Größenreduktion von Bildern

Barrierefreiheit & strukturierte Daten

Auch ohne ausdrücklichen Kundenwunsch hatten wir uns vorgenommen, die Website so zugänglich wie möglich umzusetzen und besonderes Augenmerk auf Barrierefreiheit zu legen, ohne dabei Abstriche beim Design zu machen. Im Ergebnis bedeutet dies:

  • Zugängliches Design durch angemessene Proportionen, Farben und Kontraste
  • Semantisches, in allen relevanten Bereichen valides HTML5-Markup
  • Korrekte Überschriftenhierarchien
  • Nutzung von WAI ARIA (ARIA-Attribute und Landmark Roles) zur Unterstützung assistiver Technologien
  • Vollständige Tastatursteuerbarkeit

Zur kontinuierlichen Prüfung der Barrierefreiheit kam unter anderem der Online-Service Tenon zum Einsatz, mit dem sich sowohl komplette Websites, als auch einzelne Komponenten auf typische Fehler untersuchen lassen.

Barrierefreiheitsprüfung einzelner Komponenten mit Tenon aus Fractal
Screencast eines Tests auf Barrierefreiheit mit dem Online-Dienst Tenon, durchgeführt aus der Fractal-Komponentenbibliothek heraus

Um problematische Stellen frühzeitig erkennen zu können, entwickelten wir ein weiteres Fractal-Zusatzmodul, mit dem sich einzelne Komponenten direkt aus der Komponentenbibliothek heraus per Knopfdruck mit Tenon testen lassen.

Doch nicht nur für menschliche Nutzer kann die Zugänglichkeit einer Website optimiert werden. Durch strukturierte Daten wie Microformats, HTML Microdata oder RDFa Lite lassen sich zusätzliche Bedeutungsebenen in die vorhandenen Website-Daten legen, die dann von spezialisierten Programmen — allen voran Suchmaschinen — gezielt ausgelesen werden können. Für viele auf der Fischer-Website enthaltenen Informationen existieren spezialisierte Vokabulare zur Auszeichnung, etwa für Fahrzeuge, Ansprechpartner, News-Artikel und Stellenanzeigen. Durch explizites Anreichern mit passenden Mikroformaten haben wir die Website bestens auf potenzielle, nicht-menschliche Besucher wie die Indizierungsroboter von Fahrzeug- oder Stellenportalen vorbereitet. Beim Testen kam uns neben unserer Erfahrung unser hauseigenes micrometa-Tool zugute.

Strukturierte Daten in der Google Search Console
Screenshot der Google Search Console mit einer Übersicht über die vielfältigen, in die Website integrierten Strukturierten Daten

Leistungsfähige Suche

Herzstück der neuen Website ist zweifelsohne die hochperformante Suche, die über Fahrzeuge, News, Ansprechpartner, Standorte und sonstige redaktionelle Inhalte hinweg Ergebnisse liefert. Die technische Basis ist ein Apache Solr Suchindex, der direkt durch eine individualentwickelte JavaScript-Bibliothek vom Browser aus angesprochen wird.

Für redaktionelle Inhalte, News-Artikel, Ansprechpartner und Standorte werden jeweils individuelle Merkmale in den Suchvorgang einbezogen. Dieser unterstützt unter anderem unscharfe Ergebnisse (mit leichten Abweichungen in der Schreibweise) und Stemming, also die Reduktion der gesuchten Begriffe auf ihren Wortstamm.

Universalsuche auf Basis von Apache Solr und einer individualentwickelten JavaScript-Bibliothek
Screencast eines Suchvorgangs über die Universalsuche, bei dem verschiedene Suchbegriffe eingegeben und Filter gesetzt werden

Speziell bei Fahrzeugen greifen weitere Funktionaltitäten. So können etwa Fahrzeugmarken, -modelle und Standorte als Filter für verfeinerte Suchvorgänge genutzt werden. Bei der Eingabe von Ziffern wird eine intelligente Interpretation als Maximalpreis oder Erstzulassungsjahr versucht. Die Fahrzeug-Detailsuche stützt sich auf die hochperformante Facettierung, die der Solr-Server bietet — die dargestellten Stückzahlen werden dynamisch an die jeweilige Filterauswahl angepasst.

Tatsächlich ist die Suchlogik mehrfach redundant implementiert. Beim Aufruf der Fahrzeug-Detailsuche mit vorausgewählten Filterkriterien, etwa aus der Universalsuche im Kopfbereich heraus, findet bereits serverseitig eine erste Anfrage an den Solr-Index statt, so dass ein vollständiges Suchergebnis an den Browser ausgeliefert wird. Alle folgenden Verfeinerungen der Suche spielen sich unmittelbar zwischen Browser und Solr-Server ab. Sollte der Solr-Server aufgrund von z.B. Netzwerk- oder sonstigen Problemen einmal nicht zur Verfügung stehen, fallen sowohl server- als auch clientseitige Suchvorgänge auf die Datenbank zurück. Unscharfe Suchen, Stemming oder Facettierung stehen dann nicht zur Verfügung — dennoch bleibt die Suche grundsätzlich weiterhin nutzbar.

Facettierte Fahrzeug-Detailsuche über einen umfassenden Apache Solr Index
Screencast eines Suchvorgangs über die Fahrzeug-Detailsuche, bei dem verschiedene Filter und wieder aufgehoben werden

An dieser Stelle sei erwähnt, dass die eingesetzte Solr-Instanz von OpenSolr, einem in Rumänien ansässigen, dedizierten Hosting-Anbieter, betrieben wird. Als tatsächlicher Server-Standort wurde aus einer großen Auswahl ein Rechenzentrum in Nürnberg gewählt. Nicht zum ersten Mal konnten wir mit OpenSolr hervorragende Erfahrung machen — gerade auch in der direkten Kundenbetreuung. Eine Anekdote für technisch Interessierte: Manche Anfragen der Fahrzeug-Detailsuche nutzen derart viele Parameter, dass die erlaubte Maximallänge für GET-URLs überschritten wird (4 kB). Die Empfehlung lautete zunächst, wir mögen doch auf POST-Requests ausweichen. Bis dato unterstützt OpenSolr jedoch keine CORS-Header, weshalb als Anfragemethode vom Browser aus nur JSONP, also GET-Requests in Frage kamen — ein Henne-Ei-Problem also. Nach Darlegung der Problemsituation und ein wenig Recherche hat OpenSolr speziell in unsere Instanz dann doch CORS-Header integriert und erwägt, dies als Standardfeature auszurollen. So geht Service!

Agiler Projektverlauf

Für die Umsetzung unserer Projekte nutzen wir das Scrum-Vorgehensmodell, bei dem Teilaufgaben in kurzen Zyklen, den sogenannten "Sprints" organisiert, umgesetzt und freigegeben werden — eine agile Arbeitsweise, die sich auch auf einen Designprozess anwenden lässt. Zur teaminternen Organisation wie auch zur Abstimmung mit Kunden setzen wir auf die webbasierte Kanban-Implementierung Trello — eine effektive Möglichkeit, um den Fortschritt eines Projekts anschaulich zu visualisieren und gezielt zu einzelnen Aufgaben zu kommunizieren.

Sprints dauerten im Fischer-Projekt jeweils eine Woche lang. Zu Spitzenzeiten arbeiteten auf unserer Seite 6 Personen parallel am Projekt. Die Bearbeitungsdauer lag insgesamt bei rund 9 Monaten, Urlaubsphasen nicht eingerechnet.

Launch & Betrieb

Anfang September 2017 ging die neue Fischer-Website schließlich online — und das Ergebnis kann sich durchaus sehen lassen, wie wir finden:

  • Begleitet durch entsprechende Ankündigungsmaßnahmen auf internen und externen Kanälen schnellte die Sitzungszahl mit dem Launch von vormals 10-20 auf rund 1.000 eindeutige Besucher pro Tag, um sich dann auf durchschnittlich ca. 600 Besucher einzupendeln. Dies entspricht einem Besucherzuwachs von nahezu 6.000%. Die durchschnittliche Aufenthaltsdauer liegt derzeit zwischen 4 und 5 Minuten.
Sprunghafter Anstieg und Einpendeln der Besucherzahlen bei ca. 6.000%
Screenshot der Traffic-Entwicklung in Google Analytics mit einem Anstieg von durchschnittlich 10 auf ca. 600 Sitzungen pro Tag
  • Mit einem Google PageSpeed Index zwischen 95 und 98 schneidet die Website äußerst performant ab.
Überzeugender Google PageSpeed Index (95/98 von 100) und keinerlei Tenon-Issues auf der Startseite
Montage dreier Screenshots, die den Google PageSpeed Index für mobile und Desktop-Geräte zeigen, sowie die Tenon-Ergebnisdarstellung mit null Fehlern
  • Mit ~1.1 MB Datenvolumen und knapp 80 Requests liegt die Startseite deutlich unter dem derzeitigen Durchschnitt (3.3 MB, Stand September 2017) und macht so nicht nur mobile Nutzer glücklich, sondern bietet auf allen Plattformen eine überzeugende User Experience.

Die angenehme, sehr konstruktive Zusammenarbeit mit unseren Ansprechpartnern bei Fischer hat uns großen Spaß gemacht und uns immer wieder motiviert, noch eine Schippe obendrauf zu legen. Wir freuen uns schon sehr auf die nächsten Projektphasen — irgendwann soll es schließlich auch einen Online-Shop geben — und werden sicher die gewonnene Erfahrung auch in anderen Projekte nutzen können.

Geschrieben in: TYPO3 Projekte Design Mobile / RWD Accessibility / Barrierefreiheit PHP

Kommentare

  1. Markus Gattenlöhner schrieb am 09.10.2017 13:27

    Vorbildliche Umsetzung!
    6000% Besucherzuwachs und 4 Minuten Verweildauer
    machen jeden Web-Controller glücklich.

    Alles richtig gemacht. :)

  2. ‹ß› Zimmermann schrieb am 09.10.2017 20:43

    Tolle Sache, sauber umgesetzt, mein Respekt. PageSpeed bei 95, das stachelt meinen Ehrgeiz ordentlich an… geht also doch … nicht zu sprechen von all den Accessibility-Features … die Latte habt ihr ohne Zweifel hoch gelegt.
    Weiter so & schöne Grüße aus Stuttgart!

  3. Onur schrieb am 17.10.2017 10:18

    Ausführlicher Artikel, jedoch ist mir nicht ganz klar, wie der Kunde jetzt am Ende Inhalte pflegt. Könntet Ihr das auch ggfs. mit einem kleinen Gif/Video mal zeigen?

  4. Joschi Kuphal schrieb am 17.10.2017 22:09

    @Onur Hinter der Website steht ja — wie oben dokumentiert — TYPO3 als Content Management System. Die Pflege der meisten Inhalte geschieht über das reguläre TYPO3-Backend mit den dafür vorgesehenen Standard-Redaktionswerkzeugen. Fahrzeugdaten und Stellenanzeigen werden ohne manuelles Zutun über Hintergrunddienste täglich aus externen Quellen importiert (CSV-Daten, XML-Feed). Da sich diese Dokumentation den Besonderheiten des Projekts widmen soll, halte ich Videos vom Standard-TYPO3-Backend für eher nicht relevant an dieser Stelle. Wenn du dich allgemein zu den Möglichkeiten von TYPO3 als CMS informieren möchtest, lade ich dich ein, dich telefonisch bei uns zu melden und ich will versuchen, dir z.B. per Screensharing eine kurze Tour durch ein blankes TYPO3 zu geben. Viele Grüße, Joschi

  5. Onur schrieb am 17.10.2017 22:19

    @Joschi

    Danke für die Antwort. Es ging mir nur darum, wie Ihr Komponenten dann am Ende mit dem Backend verknüpft habt. Ich vermute, aus deiner Antwort ableitend, dass der Kunde im Backend die Komponenten nicht zur Pflege verwenden kann, sondern sich nur mit den "Standard" Elementen austoben darf?
    Die Komponenten aus dem Fractal kommen dann hauptsächlich in den Extension gestützten Bereichen zum Einsatz? Darauf zielte meine Frage eher ab.

  6. Joschi Kuphal schrieb am 17.10.2017 22:46

    @Onur Ah, jetzt komme ich mit, danke! :) Da gibt es einige unterschiedliche Fälle:

    1. Manche Komponenten entstehen mehr oder weniger ohne direktes Zutun und ohne Einfluss der Redakteure, bspw. die Primärnavigation oder die Filter in der Fahrzeugdetailsuche (natürlich reagiert das Menü trotzdem auf neue Seiten, die vom Redakteur angelegt werden).

    2. Andere Komponenten werden von individuellen, abstrakten Datensätzen gespeist, die von Extension-Plugins zur Anzeige gebracht werden, z.B. die Ansprechpartner. Die Redakteure pflegen die Ansprechpartner zentral in einem Ordner im TYPO3, und an vielen Stellen sind Ansprechpartner-Plugins platziert (entweder manuell im Backend oder implizit in andere Templates eingebunden, z.B. bei Fahrzeugen), die sich dann ganz gezielt Ansprechpartner herauspicken (nach unterschiedlichen Kriterien) und diese anzeigen.

    3. Manche Komponenten sind aber auch ganz gezielt als Flexible Content Elements im Backend exponiert, z.B. die Tabliste (Registerkarten) oder die kollabierbaren Bereiche / Akkordeons. Diese kann der Redakteur ganz gezielt einsetzen und mit beliebigen anderen Content-Elementen füllen. Oder beispielsweise kann der Redakteur den Page-Hero über ein Häckchen in den Seiteneigenschaften aktivieren und dort auch das Bild oder die Bilder dazu pflegen.

    4. Schließlich gibt es auch noch ganz subtile Varianten: Beispielsweise haben wir in den Rich-Text-Editor im Backend individuelle Textstile integriert, die einen Link zu einem Button bzw. zur Button-Komponente machen, sobald sie verwendet werden. Indirekt setzt der Redakteur also solche Komponenten auch gezielt ein, wenn er möchte.

    Ich hoffe, das klärt deine Frage etwas besser?

Kommentar schreiben

MathGuard Sicherheitsabfrage. Bitte lösen Sie folgende Rechnung:
3LN          E       
B 8    D    TG    4LJ
J M   2XB    J       
E D    C     J    TNB
TEP         P51