Ist TYPO3 kompliziert?

Die Antwort auf die Frage ist also: Wenn man sich als Agentur keine Mühe gibt, dann ist es kompliziert. 

Anders formuliert: Wenn man als Agentur den Redakteur nicht als wichtige Zielgruppe sieht und das Backend nicht auf den Redakteur maßschneidert, dann hat man etwas falsch gemacht, dann ist es unnötig kompliziert.

TYPO3 ist ein mächtiges und höchst anpassbares CMS. Komplexität und Flexibilität erfordern einiges an Wissen und Know-how.

Die Frage ist vielmehr, für wen es kompliziert ist und für wen die Lernkurve hoch ist. Dies trifft zu für Entwickler. Unsere Entwickler können das. Unsere Kunden müssen sich um komplizierte Dinge nicht kümmern, dafür bieten wir einfache Lösungen.

Klassiker, die wir immer wieder sehen sind:

• jeder Redakteur hat einen Admin-Zugang
• der Redakteur sieht im Backend keine Inhalte, nur kryptische Bezeichnungen
• Felder sind nicht sinnvoll benannt
• Felder und Funktionen aus dem Core werden zweckentfremdet
• Plugins werden zweckentfremdet
• Elemente werden für zu viele verschiedene Zwecke verwendet
• Automatismen die vorhanden wären, werden durch händische Arbeiten ersetzt
   

Klar, es scheint toll ein Admin zu sein. Man interpretiert dort rein, dass man alles darf und kann. Aus Entwicklersicht kann man sich dann den Aufwand sparen, Redakteursgruppen zu definieren. Man müsste explizit einstellen, was ein Benutzer darf und was nicht. Das ist Aufwand. Ein Admin sieht einfach alles. Das geht schnell. Da ist für Entwickler nichts zu tun.
Jetzt ist es kompliziert, denn das Ergebnis ist leider: Der Benutzer sieht alles. 

Niemand braucht in einem Projekt 100% der Felder die ein TYPO3 mitbringt. Niemand! Das ist ein Garant für Frustration beim Benutzer des Backends. Die Wahrscheinlichkeit, dass er die Felder findet, die er wirklich braucht und die im Frontend auch etwas bewirken ist gering. Es wird zahlreiche Schalter und Hebel im System geben, die keinerlei Auswirkungen haben, weil sie im Frontend einfach gar nicht benötigt werden in diesem Projekt. 

Ich habe also 1000 Knöpfe und muss die 5 finden, die etwas bewirken. Natürlich ist das frustrierend und kompliziert.

Viel sinnvoller wäre es, wenn der Redakteur nur die Felder sieht, die auch etwas bewirken und die zur Erfüllung der Aufgaben auf der Webseite benötigt werden. Das Backend ist dann sehr übersichtlich und jede Stelle, die benötigt wird, ist einfach zugänglich. Man weiß, wo man hinfassen muss, ohne Schnickschnack, auch nach ein paar Wochen noch, wenn man nicht täglich Content editiert.

Die fehlende Vorschau der Elemente im Backend ist ein Produktivitätskiller. Noch schlimmer wird es, wenn mit mehrfach verschachtelten Grid-Elementen ohne backend-preview gearbeitet wird, dann findet der Redakteur nichts und die Sache ist in der Tat kompliziert.

Auf großen Content-Seiten reihen sich zahlreiche Elemente untereinander ein, die keinerlei Vorschau im Backend bieten. Sind die Elemente dann nicht explizit für das Backend benannt, findet man als Redakteur nichts. Der User muss im Backend sofort sehen, welches Element er sucht, nicht nur textuell, sondern auch visuell. Die Möglichkeiten, es für den Redakteur visuell einfach zu machen sind da, müssen aber auch umgesetzt sein damit er davon profitiert.

Wie wir Backend verstehen kann hier nachgelesen werden: TYPO3 - So muss Backend!

Eine sinnvolle Benamung von Dingen ist alternativlos und gilt grundsätzlich. Das gilt für Redakteure als auch für Entwickler, auch außerhalb eines CMS, immer! Benenne etwas so, dass es jeder versteht und jeder weiß, was erwartet wird und wofür etwas ist.

Das ist deswegen völlig unerklärlich, weil der Aufwand so gering, der Nutzen aber so groß ist. Man schreibt hin was das Feld macht und was es an Eingaben erwartet. So einfach!

Natürlich hat so ein mächtiges Content Management System eine Vielzahl an Funktionen und Felder. Oft gesehen und nie für gut befunden ist die Praxis, dass man bestehende Felder die etwas ganz anderes tun sollen, zweckentfremdet. Das geht schnell, aber es rächt sich. Das sind technische Schulden, die einem irgendwann auf die Füße fallen.

Wir haben schon so einige Systeme übernommen, wo selbst 20 Jahre Erfahrung nicht helfen und man erstmal herausfinden muss, woher eine Funktionalität oder ein Verhalten kommt und was sich der Entwickler dabei gedacht hat. Man ist immer wieder überrascht, auf welche Ideen man kommen kann. Für den Redakteur ist so etwas noch viel weniger nachvollziehbar, wenn man das Feld im Backend noch nicht mal richtig benennt. Selbst für erfahrene Entwickler nicht nachvollziehbar und schlecht wartbar, zu kompliziert, das geht besser!

Häufig sieht man auch, dass eine Funktionalität mit einem Plugin umgesetzt wird, dass für einen völlig anderen Zweck entwickelt wurde. Der Klassiker ist hier das Plugin "news". Es hat eine Listen- und Detailansicht und generiert aus Datensätzen sowohl die Detailansicht als auch Übersichtsseiten. Es kann natürlich deutlich mehr, ist im Grunde aber für die Anzeige von News konzipiert und entwickelt. Dies verleitet offenbar dazu, dieses Plugin inflationär für alles einzusetzen, was eine Liste mit einem Pager benötigt. Oftmals kommt es dann an den Punkt, dass Felder zweckentfremdet werden und schlimmstenfalls in den Code der Extension eingegriffen wird.

Kommen dann noch weitere Anforderungen dazu, die im Kern der News-Extension nicht sinnvoll sind, dann holt der vermeintlich gesparte Aufwand einen mit voller Wucht ein. Es ist unbedienbar, es ist nicht mehr updatebar. Wir haben zahlreiche Beispiele gesehen, die mit einem normalen Content-Element und entsprechender Entwicklermagie auch ohne Plugin wunderbar funktioniert hätte. Einfach pflegbar, updatefähig, mit weniger Aufwand umgesetzt.

Der Kern eines CMS sind die Content Elemente. Damit strukturiert der Benutzer seine Inhalte und kann diese flexibel kombinieren. Er zerlegt den Inhalt der transportiert werden soll in kleine Häppchen, Content Bühnen trifft es ganz gut. In nahezu jedem Projekt gibt es Text-, Bild- und Videoelemente. Gute Praxis ist, dass es dafür jeweils eigene Elemente gibt. Damit ist klar was der Redakteur an Inhalten einpflegt und was rauskommt. Die Menge an Feldern ist für den Anwendungsfall auf ein Minimum reduziert und schafft Klarheit.

Gibt es etwa einen Teaser für mehrere Zwecke, empfiehlt es sich dafür explizit eigene Element zur Verfügung zu stellen. Es spart keinen Aufwand, ein Element mit vielen Schaltern zum Chamäleon zu machen, im Gegenteil. Soll jeder Schalter im Frontend signifikante Auwirkungen haben ist es meist komplizierter, diese "Wenn-Dann" Fälle umzusetzen. Auch hier gilt: Keep it simple. Für Entwicklung und Redakteure. Bessere Wartbarkeit und klare Bedienung haben vorang vor einem allumfassenden Element das vermeintlich alles kann und nicht bedienbar ist.

Ein CMS ist ein hochspezialisiertes Konstrukt mit dem Ziel, Dinge die häufig gebraucht werden bereits an Bord zu haben. Oftmals ist es aber so, dass diese Automatismen oder Funktionalitäten nicht richtig konfiguriert oder eingesetzt werden, um dem Redakteur das Leben leichter zu machen. Oftmals wird an der falschen Stelle gespart und der Redakteur muss hundertfach dasselbe tun um etwas zu bewirken, was eigentlich automatisch ginge. Da fragt der Redakteur dann zurecht: "Warum ist das so kompliziert?". Wäre es eigentlich gar nicht.