Post 1. Sep. 2011 Redaktion and TYPO3

CMS benutzerfreundlich entwickeln

t3n Magazin Nr. 25, 09/2011 - 11/2011

Content Management Systeme (CMS) wie TYPO3 sollen in erster Linie die redaktionelle Arbeit unterstützen. Es erklärt sich eigentlich von selbst, dass sich das CMS an den Bedürfnissen der Redakteure orientieren sollte. Häufig entspricht dieser Anspruch jedoch nicht der Realität. Dabei bedarf es nicht viel Entwicklungsaufwand, um Redakteuren die Arbeit zu erleichtern.

Artikel auf t3n: CMS benutzerfreundlich entwickeln

Das Internet ist ein Kommunikationsmedium. Eine Website dient zur Publizierung von Inhalten. Im Mittelpunkt stehen somit die Erstellung, Aufbereitung und Bereitstellung der Inhalte. Die Redakteure leisten hier die wesentliche Arbeit, doch häufig werden Anforderungen aus technischer Perspektive umgesetzt und die Nutzbarkeit für die Redakteure vernachlässigt. Das Redaktionssystem wird folglich als unverständlich und umständlich empfunden - und nicht selten zu Recht.

Die redaktionelle Arbeit ist die eigentliche Arbeit, welche durch ein Content Management System (CMS) unterstützt werden soll. Es erklärt sich eigentlich von selbst, dass sich das CMS an den Bedürfnissen der Redakteure orientieren sollte. Häufig wird diese Sichtweise aus den Augen verloren. Als Folge wird dadurch mitunter der Projekterfolg gefährdet. Zur Veranschaulichung ein klassisches Szenario:

Es werden komplexe Anforderungen mit komplizierten technischen Lösungen erfüllt. Das TYPO3-System läuft, nur der Inhalt muss noch eingepflegt werden. Trotz Schulung verstehen die Redakteure nicht, wie die Eingaben zu erfolgen haben. Es werden im Nachgang Handbücher und Screencasts erstellt - aber das System wird dadurch nicht einfacher. Die Inhaltpflege geht nicht voran und der geplante Live-Termin naht. Das Resultat: Die Stimmung kippt und der pünktliche Onlinegang wird gefährdet. Dadurch leidet die Kundenzufriedenheit, manchmal bis zur Eskalation. Und das bei einem technisch voll funktionsfähigem TYPO3-System.

Leider sind solche Projektverläufe nicht fiktiv sondern Realität. Dabei bietet TYPO3 als leistungsfähiges Framework genügend Möglichkeiten, Funktionen so zu realisieren, dass sie auch durch Redakteure einfach verwendbar sind.

Die Ursachen, warum die Möglichkeiten nicht genutzt werden, sind vielfältig. In der Entwicklung wird die Pflege der Inhalte häufig nicht berücksichtigt – oder hinter die technische Lösung gestellt. Entwickler haben eine andere Perspektive und gewöhnlich wenig praktische Erfahrung in der redaktionellen Arbeit. Später im Test werden Funktionen und Features betrachtet und evtl. noch die Usabilty im Frontend - die Bedienbarkeit des Backends wird jedoch selten bewertet, solange alle Daten per Admin-Account eingepflegt werden können. Die Probleme bei der Pflege treten somit erst bei der redaktionellen Arbeit auf, welche häufig vom Kunden selbst übernommen wird. Und das ist häufig zu spät.

Dabei lassen sich viele Eingaben für den Redakteur vereinfachen ohne langsamer oder komplizierter zu entwickeln, wenn man es nur mitdenkt.

Im Folgenden werden einige Regeln und Lösungen vorgestellt, welche aus den Problemen zahlreicher Projekte zusammengetragen wurden und wesentlich zur besseren Nutzung eines TYPO3-Systems durch die Anwender führen.

###1: Anwendungsfälle des Kunden mitdenken Viele Konfigurationen und Erweiterungen eines TYPO3-Systems werden aufgrund spezieller Projektanforderungen realisiert. Wichtig ist, was der Kunde damit bezweckt und wie die Pflege aus Sicht der Redaktion erfolgen soll. Häufig wird dies durch die Betrachtung von Datenmodellen und Features überlagert.

Sollen z.B. zu Veranstaltungen Ansprechpartner zugeordnet werden, möchte man an der Veranstaltung die Zuordnung zu der Person pflegen und nicht anders herum. Wenn bspw. Mitarbeiterdaten verwaltet werden, ist die Zuordnung zu einer Abteilung ggf. in der Pflegemaske der Person sinnvoller platziert. Besondere Meldungen eines Unternehmens sollen ggf. manuell auf der Starseite platziert werden – dann kann man sie auch dort einpflegen. Ebenfalls werden hier vielleicht die neusten drei Pressemeldungen angezeigt – hier können die Pressemeldungen im Pressebereich erstellt werden und die Anzeige auf der Startseite kann automatisiert erfolgen.

Die Möglichkeiten sind so vielfältig und individuell wie die Anforderungen. Hier sollte bei der Definition der technischen Lösung im Sinne des Anwenders gedacht werden. Erkennt der Redakteur im TYPO3-System seinen Anwendungsfall wieder, dann versteht er auch, wie die Pflege funktioniert – findet er sich nicht wieder, dann entsteht Verwirrung.

###2: Richtige und verständliche Sprache Vielleicht die banalste Regel, aber leider besteht genau hier am häufigsten ein Problem: die Sprache. Grundsätzlich sollte die Sprache der Redakteure verwendet werden, zum Beispiel Deutsch anstatt Englisch. Und dies sollte auch konsequent erfolgen, sodass kein Sprachwirrwar im Backend entsteht. Wenn man aus technischen Gesichtspunkten englische Texte bereitstellen möchte, dann ist zwingend die deutsche Übersetzung mit anzugeben.

Ebenso sollte eine klare und verständliche Sprache verwendet werden. Viele Begriffe der Webentwicklung sind Fachbegriffe, welche den Kunden und Redakteuren nicht immer geläufig sind. Hier können außer der Verwendung von einfacheren Begriffen, zusätzliche verständliche Erläuterungen Wunder wirken. Wichtig ist dabei, dass der Redakteur die Bedeutung eines Feldes oder einer Funktion für seine Zwecke versteht. Ein Klassiker sind die vier Spalten im Backend. Neben der Ausblendung nicht verwendeter Spalten können die sichtbaren auch inhaltlich zur Website passend benannt werden.

ext_tables.php

$TCA["tt_content"]["columns"]["colPos"]["config"]["items"] = array (  
	"0" => array ("Inhalt||Inhalt||||||||","0"),  
	"1" => array ("Bühne||Bühne||||||||","1"),  
	"2" => array ("Weiterführende Links||Weiterführende Links||||||||","2") 
);

In den neueren TYPO3-Versionen sind z.B. die Felder „keywords“ und „description“ in den Seiteneigenschaften sinnvoll beschrieben: „Beschreibung (SEO): Geben Sie eine kurze Beschreibung der Seite ein. Sie wird in den Suchergebnissen von Suchmaschinen angezeigt.“ So weiß der Anwender genau was er tun muss und auch wozu die Eingabe verwendet wird.

###3: TYPO3-Hilfefunktionen nutzen Ein Softwaresystem sollte möglichst selbsterklärend sein. Handbücher und Screencasts sind immer ein Umweg. TYPO3 bietet die Möglichkeit Erläuterungen direkt in die Redaktionsoberfläche zu integrieren. Für Standardfelder sind hier auch Texte hinterlegt, wie oben am Beispiel der Meta-Description gezeigt. Bei projektspezifischen Umsetzungen werden diese leider fast immer ignoriert - und das wo hier für den Redakteur besonderer Bedarf besteht, da es kein Standard ist. Werden auch bei individuellen Erweiterungen sinnvolle Hinweise angeboten, sind die CMS-eigenen Hilfefunktionen eine echte Hilfe. In Schulungen kann man sich dann auf den Gesamtüberblick konzentrieren und bei Details auf die integrierte Hilfe verweisen. Die Einbindung ist übrigens sehr einfach und unter dem Stichwort „Context Sensitive Help (CSH)“ in der „Core Documentation“ gut erläutert.

Sind bei komplexeren Systemen dennoch ein Handbuch oder Screencasts nötig, können diese über ein einfachen Backend-Modul in das TYPO3-System integriert werden. So hat der Redakteur immer alle Informationen zur Hand.

###4: Redaktionsaccounts einsetzen Das die Einrichtung von Redaktionsaccounts sinnvoll ist, steht außer Frage. Diese sollten zu Beginn eingerichtet und bereits während der Entwicklung – z.B. zur Einpflege von Testinhalten - verwendet werden. So werden Probleme frühzeitig sichtbar und es können entsprechend Lösungen gefunden werden, bevor die Entwicklung abgeschlossen ist.

Bei der Konfiguration der Redaktionsaccounts und -gruppen sollte immer eine starke Reduktion der Eingabeoptionen angestrebt werden. Umso weniger Module, Seiten und Felder vorhanden sind, umso einfacher fällt die Orientierung im Backend bei den Standardanwendungen. Bei großen Inhaltmengen ist es häufig sinnvoll den Zugriff für Redakteure zu differenzieren. In größeren Organisationen gibt es i.d.R. Redakteure für einzelne Teilbereiche wie Pressemeldungen (PR-Abteilung) oder Job-Angebote (Personalabteilung). Hier kann neben den Funktionen auch der Seitenbaum eingeschränkt werden. Ebenso können Attribute in den Seiteneigenschaften, bei Inhaltelementen und anderen Datenstrukturen ausgeblendet werden. Gibt es bspw. einen SEO-Redakteur, können die entsprechenden Felder für diesen ein- und für andere Redakteure ausgeblendet werden.

Wie die Konzeption und Einrichtung von Benutzergruppen und -berechtigungen konkret erfolgen, wurde bereits im Artikel „Benutzerrechte und Rechte im Seitenbaum: Rechtevergabe im TYPO3-Backend“ in der t3n Nr. 16 ausführlich erläutert.

###5: Vorlagen für komplexe Seiten Manche Seiten haben einen komplexen Aufbau, welcher auch durch Optimierungen im Backend nicht vollständig vereinfacht werden kann. Zum Beispiel eine Seite für eine Case Study, welche in einer Vollausprägung Fotos, Zitate, ein Video, Textinhalte und Downloads enthalten kann, in einer kleineren Ausprägung aber auch nur Text- und Bildinhalte umfassen kann. Zur flexiblen Bestückung einer umfangreichen Seite werden immer mehrere Eingabeschritte erforderlich sein.

Ein einfaches aber sehr wirkungsvolles Hilfsmittel sind vorbefüllte Seiten, welche als Vorlage dienen. In der Vorlage wird bspw. die Maximalausprägung der Seite eingepflegt. Als Texte werden Platzhalter-Texte oder besser Erläuterungen zur Verwendung eingesetzt. Die Seite wird anschließend auf „nicht sichtbar“ gestellt und den Redakteuren die Bearbeitung und Löschung der Seite verboten. Redakteure können nun anstatt eine neue Seite anzulegen, einfach diese Seite per Drag’n’Drop kopieren. So müssen Sie nicht alle Elemente neu zusammenstellen, sondern können durch Ändern und Löschen einzelner Elemente schneller zum Ziel gelangen.

###6: Seiteneigenschaften aufräumen Die Seiteneigenschaften in TYPO3 sind sehr umfangreich und sorgen am Anfang fast immer für Verwirrung. Arbeitet man zusätzlich mit verschiedenen Seitentypen und Attributen, verschärft sich das Problem. Spätestens dann ist es sinnvoll, zum einen die Anzahl der Felder stark zu reduzieren und zum anderen die Gruppierungen der Seiteneigenschaften zu hinterfragen und ggf. logisch neu zu gruppieren. Für die Organisation der Eingabefelder gibt es in TYPO3 mehrere Konzepte: die Tabs, die Paletten und die zweite Optionspalette. Tabs wie „Ressourcen“ oder „Erweitert“ sind wenig aussagekräftig. Dagegen kann ein Tab „Seitenvorschau“ mit Feldern für Teaserbild und Teasertext (abstract) sinnvoll sein. Sinnvoll ist auch ein Tab „SEO“, welcher Felder für Fenstertitel, Keywords, Description, OpenGraph-Angaben, Alt-Texte von Seitenelementen und das Pfadsegment umfassen könnte.

In Paletten kann man dabei alle enger zusammengehörigen Felder gruppieren, so kann der Fenstertitel bspw. in die Palette „Meta-Tags“ des Tabs „Metadaten“ integriert werden. Die zweite Optionspalette ist sinnvoll für Angaben, welche nicht unbedingt nötig sind oder seltener verwendet werden. Bsp. kann ein Seitentyp für eine Veranstaltung das Datum und den Ort in einer üblichen Palette enthalten und ein optionales Enddatum sowie Angabe zu Uhrzeit, Raum und Referent in der zweiten Optionspalette. So erhält ein Redakteur die Chance die Paletten und Felder zu überblicken, ohne auf die zusätzlichen Eingabemöglichkeiten verzichten zu müssen.

Die Konfiguration neuer Felder in den Seiteneigenschaften mit Angabe der Position funktioniert so:

ext_tables.php

t3lib_extMgm::addToAllTCAtypes('pages', 'columnname','','before:hidden');

Neue Tabs können ebenso einfach eingefügt werden. Im dritten Parameter der Funktion können zudem die IDs von Seitentypen angegeben werden, falls die neuen Felder nicht global gültig sind.

ext_tables.php

t3lib_extMgm::addToAllTCAtypes('pages', '--div--;Tab-Name,columnname','55,56,57','after:description');

Felder in bestehende Paletten einfügen kann man über die Funktion addFieldsToPalette. Mit der Funktion removeDuplicatesForInsertion kann man sicherstellen, dass die Felder nicht doppelt auftauchen. Grundsätzlich ist alles, was für die Seiteneigenschaften gilt, auch für die Felder bei Inhaltelementen aus tt_content relevant. Hier werden erfahrungsgemäß die Felder aber besser verstanden und der Bedarf ist nicht so groß, hier mehr Ordnung rein zu bringen.

###7: RTE konfigurieren Der Rich-Text-Editor ist eine zentrale Eingabemöglichkeit. Zum Teil werden hier gesamte Artikel mit Zwischenüberschriften, Formatierungen und Bildern eingegeben. Der Editor bietet dabei i.d.R. mehr Funktionen als nötig an. Über eine TSconfig-Konfiguration kann der Umfang der Funktionen auf die Bedürfnisse zugeschnitten werden. Insbesondere die Optionen showButtons und hideButtons sind hier von Bedeutung.

TSconfig

RTE.default {
	hidePStyleItems = h1, h2, h5, h6, pre, address, div, blockquote
	showButtons (...)
	hideButtons (...)
}

Darüber hinaus ist die Anpassung des CSS für den Editor sehr wichtig. Erfolgt im RTE bereits ein Styling der Inhalte, welches der Frontendausgabe gleicht, bleibt den Redakteuren ein allzu häufiges Hin- und Herschalten zwischen Eingabe und Vorschau erspart. Das CSS wird ebenfalls per TSconfig angegeben:

TSconfig

RTE.default {
	contentCSS = EXT:extname/static/templatename/css/rtehtmlarea.css
}

###8: Passenden Entwicklungsansatz für Frontend-Plugins wählen Frontend-Plugins sollen auf der Website bestimmte Funktionen oder spezielle Ansichten bereitstellen. Häufig können hier Inhalte und Konfigurationen durch Redakteure eingepflegt werden – bspw. ein Teaser zu einem Ansprechpartner oder ein spezielles Inhaltelement mit zwei Rich-Text-Feldern.

Für die technische Umsetzung gibt es verschiedene Varianten – sie kann als klassisches Inhaltelement (über tt_content) oder als Plugin mit einem Flexform umgesetzt werden. Der Nachteil von Flexforms ist, dass in den Eingabemasken geschachtelte Tab-Ebenen entstehen. Ein Redakteur wählt das Element aus dem Wizard aus, wechselt in den zweiten Tab „Plugin“ und findet dort die Eingabeoptionen. Bei vielen Eingabeoptionen mit zusätzlichen Tabs innerhalb des Flexforms oder bei gleichzeitiger Nutzung von Standardfeldern aus tt_content wird dies schnell kunfus.

Bei der Umsetzung als individuelle tt_content-Elemente können die dem Redakteur bereits geläufigen Elemente wiederverwendet werden. Sind viele Eingaben möglich, können Tabs auf der ersten Ebene (wie bei den Seiteneigenschaften) hinzugefügt werden. Zudem können diese Felder für den Zugriff einzelner Redaktionsgruppen konfiguriert werden, was mit Flexforms nicht möglich ist. Neben den Vorteilen für die Redaktion entspricht dieser Ansatz auch eher dem Content Model von TYPO3. Und: der Zugriff auf alle Daten ist per SQL (Stichworte Suche und Datenmigration) und TypoScript möglich, die Übersetzungsmechanismen lassen sich besser nutzen und die Inhalte bleiben auch beim Wechsel des Typs erhalten, soweit für Standard-Attribute die vorhandenen Felder genutzt werden.

Die Erstellung von tt_content-Elementen ist entgegen der gängigen Meinung sehr einfach. Der Code ist fast identisch zu Plugins mit Flexforms:

ext_tables.php

t3lib_extMgm::addTCAcolumns('tt_content', $CUSTOM_TCA, 1);
$TCA['tt_content']['types'][$_EXTKEY . '_piname']['showitem'] = '--palette--... [tx_extname_columnname] ...';
if (TYPO3_MODE=='BE') $TBE_MODULES_EXT['xMOD_db_new_content_el']['addElClasses']	['tx_extname_wizicon'] = t3lib_extMgm::extPath($_EXTKEY).'piname/class.tx_extname_piname_wizicon.php';
t3lib_extMgm::addPlugin(array(
	'LLL:EXT:extname/locallang_db.xml:tt_content.CType_pi1',
	$_EXTKEY . '_piname',
	t3lib_extMgm::extRelPath($_EXTKEY) . 'ext_icon.gif'
),'Ctype');


ext_localconf.php

t3lib_extMgm::addPItoST43($_EXTKEY, 'pi1/class.tx_extname_piname.php', '_pi1', 'list_type', 1);

Daten holen im PI

$this->columnname = $this->cObj->data['tx_extname_columnname'];

###9: Passende Datenstruktur für strukturierte Daten Es gibt mehrere Varianten, Inhalte und Daten in TYPO3 zu verwalten. Die gängigsten sind die Verwendung von Seitentypen über die Tabelle pages, der Einsatz erweiterter Inhaltelemente über die Tabelle tt_content oder die Erstellung eigener Tabellen. Es sollte jeweils die Datenstruktur gewählt werden, die den Anwendungsfall für den Redakteur am einfachsten machen.

Mache Entitäten können gut als Seitentyp abgebildet werden. Sinnvoll ist dies immer, wenn es eine Detailansicht gibt und in dieser flexibel Inhalte platziert werden sollen, wie z.B. bei der o.g. Case Study, einer Veranstaltungsseite oder einer Pressemeldung. Die wesentlichen Vorteile ergeben sich aus der konsistenten Pflege für den Redakteur, denn Seiten anlegen kann jeder. Hinzu kommen zahlreiche technische Vorteile wie bei den Themen Übersetzung, Publizierung, Caching, Suchindizierung und URL-Handling sowie anderer Erweiterungen. Alle Funktionen sind beim Einsatz von Seitentypen sofort auch für eigene Entitäten verfügbar.

Für andere Entitäten sind Seitentypen eher ungeeignet. Dies trifft z.B. zu, wenn keine Detailansicht existiert oder kein freier Inhalt möglich sein darf. Beispiele hierfür sind strukturierte Daten wie FAQ, Produktdaten oder Adressdatensätze. Hier bieten sich individuelle Tabellen an.

Handelt es sich weniger um Entitäten als um Elemente, die eine Darstellungsart repräsentieren, dann können sinnvoll tt_content-Elemente eingesetzt werden. Klassiker hierfür sind spezielle Störer oder Testimonials sowie kombinierte Inhaltelemente z.B. aus Tabelle und Text.

###10: Sinnvolle Abbildung von Relationen Relationen zwischen Entitäten müssen genau durchdacht werden - und zwar aus semantischer, aus technischer und redaktioneller Sicht. Bei der Betrachtung des Datenmodells ist dabei insbesondere die Navigierbarkeit zu berücksichtigen bzw. die Definition wo und wie die Relationen tatsächlich gepflegt werden. Bei normalen 1:n und m:n Relationen ist zu entscheiden, von welcher Seite die Relation gepflegt wird, ob sie auf der anderen Seite sichtbar sein soll oder ob sie bidirektional verändert werden soll. TYPO3 bietet für Relationen verschiedene Konzepte von Einfach-Selectboxen über Mehrfachauswahlen bis hin zu Auswahlfeldern mit Suchfeld, Seitenauswahl-Wizard und Inline-TCA (IRRE). Alle Varianten haben ihre Vor- und Nachteile, welche bei der Definition der technischen Lösung abgewogen werden sollten. Durch die passende Wahl können die Verständlichkeit des Backends und die Anzahl der Klicks bei der Bearbeitung deutlich verbessert werden.

###Fazit Wenn man die Perspektive der Redakteure im gesamten Prozess im Hinterkopf behält, kann ein TYPO3-System mit einfachen Mitteln sehr viel komfortabler gestaltet werden. Fast alle genannten Maßnahmen erfordern keinen oder nur geringen zusätzlichen Aufwand, sondern vielmehr ein Mitdenken bei der Definition der technischen Lösung und der Umsetzung. Die Redakteure und Ihre Kunden werden es Ihnen danken.