PowerSet 2 – Leitfaden zur Erstellung von Vorlagen – Evalanche Helpcenter

Gestaltungskonzepte

Restriktive vs. flexible Konfiguration

Bei der Template-Entwicklung kann man entscheiden, wie viel gestalterische Freiheit die Redaktion im Alltag hat.

Restriktive PowerSet-Vorlagen legen möglichst viele Designaspekte fest: Farben, Schriftarten, Abstände und Modul-Varianten sind streng gemäß Corporate Design eingestellt und Redakteure können diese kaum ändern. Das garantiert maximale Konsistenz – jeder Newsletter sieht markenkonform aus. Z.B. könnten Hintergrundfarben für Inhaltsblöcke fest auf Weiß oder Hellgrau eingestellt sein, ohne Auswahlmenü für andere Farben.

Flexible Konfigurationen hingegen geben den Anwendern mehr Optionen. So könnte man im Inhalts-Modul die Wahl zwischen mehreren Hintergrundfarben zulassen oder alternative Modul-Layouts freischalten.

Ein Mittelweg ist üblich: Kritische Gestaltungselemente (Logo, Font, primäre Farben) sind fix, während bei weniger kritischen Aspekten (z.B. optionaler farbiger Highlight-Block) Auswahl möglich ist. Template-Entwickler steuern dies über die Konfiguration der Module und Widgets (siehe Abschnitt: Entwicklung von Vorlagen). Jedes Eingabefeld im Editor (jedes “Widget”) kann ein- oder ausgeblendet werden. Beispielsweise kann man die Option “Hintergrundfarbe” im Inhaltsmodul deaktivieren, um nur eine Standardfarbe zu erlauben – oder aktivieren, um dem Creator die Möglichkeit zu geben, Segmente hervorzuheben. Ähnlich kann man das Feld “Bildposition” sperren, wenn z.B. immer Bild links festgelegt sein soll. Durch diese gezielte Einschränkung oder Freigabe entsteht ein Designsystem, das entweder sehr uniform ist oder bewusst variabel für kreative Spielräume der Redakteure.

Empfehlenswert ist, die wichtigsten CI-Vorgaben restriktiv durchzusetzen (Logo-Position, Hauptfarben, Font), aber dort Flexibilität zu bieten, wo inhaltlich notwendig (abwechselnde Hintergrundfarben für bessere Lesbarkeit, Wahl zwischen 1- oder 2-Spalter, etc.).

Mehrspaltigkeit

Ein- und mehrspaltige Layouts: PowerSet-Templates unterstützen sowohl einfache einspaltige Layouts als auch mehrspaltige Designs. Welche man verwendet, hängt vom Inhalt und Design ab. Einspalter sind sehr lesefreundlich und für mobile Darstellung optimal – alle Elemente untereinander, kein Spaltenumbruch nötig. Viele klassische Newsletter und Standalones setzen auf ein einspaltiges Hauptlayout. Mehrspalter ermöglichen komplexere Inhaltsanordnungen, z.B. zwei Produkte nebeneinander. Im Evalanche Designer werden Mehrspalten-Layouts durch die Layout-Module (2-Spalter, 3-Spalter) realisiert. Innerhalb eines 2-Spalters kann man z.B. zwei Inhalt-Komponenten nebeneinander platzieren – ideal um Text-Bild-Kombinationen side-by-side zu zeigen.

Wichtig: In Evalanche werden Inhalte in Mehrspalter-Modulen bei geringem Platz automatisch untereinander gestapelt (insbesondere auf Smartphones). Dadurch bleibt die Lesbarkeit gewahrt.

Als Designer: Plane, welche Abschnitte ggf. zweispaltig sein sollen (z.B. zwei News-Artikel nebeneinander am Desktop) und welche besser einspaltig (z.B. breite Überschriften-Banner). Der Mix aus ein- und mehrspaltigen Bereichen kann dem Newsletter visuelle Abwechslung geben. Beachte auch, dass sehr breite Texte in mehrspaltigen Layouts auf Desktop evtl. in zwei schmalen Spalten stehen – stelle sicher, dass das noch gut aussieht. Du kannst auch bewusst optionale mehrspaltige Sektionen anbieten, die Redakteure nutzen können, aber nicht müssen (siehe Sonderfälle für 1-/2-/3-Spalter-Kombinationen).

Content Management

Artikel vs. Modul-Content: Evalanche bietet zwei Ansatzpunkte, um Inhalte ins Mailing zu bringen: Artikel-Objekte oder individuelle Modulinhalte:

Bei der Artikel-Variante erstellt man im System separate Artikel (mit Titel, Text, Bild etc.), die dann via "Artikel (CMS)"-Modul oder "Artikel (Liste)"-Modul ins Mailing eingebunden werden . Das hat den Vorteil, dass ein Artikel mehrfach (in verschiedenen Mailings) verwendet werden kann und zentral gepflegt ist. Zudem haben Artikel eine eigene Statistik. Änderungen am Artikel (z.B. Korrektur im Text) aktualisieren automatisch alle Mailings, die ihn referenzieren. Zudem können Artikellisten dynamisch erstellt werden (z.B. fünf neueste Blogposts).
Die alternative Methode ist, Inhalte direkt im Mailing über "Inhalt"-Module manuell einzupflegen (Text/Bild direkt eingeben). Dieser Modul-Content ist individuell pro Mailing und bietet oft mehr Layoutflexibilität (z.B. gemischte Reihenfolge, individuelle Darstellungen). Template-Entwickler müssen entscheiden, ob sie ihren Nutzern empfehlen, mit Artikeln zu arbeiten oder frei im Mailing zu schreiben. Oft wird beides kombiniert: Ein Newsletter kann z.B. einen Artikel-Teaserbereich haben, wo via Artikel-Module automatisch Beiträge eingefügt werden, und darunter frei gestaltete Promotions mit dem Inhalts-Modul.

Für den Template-Aufbau bedeutet das: Du solltest Artikel-Module mit einplanen, wenn Kunden ein zentrales Content-Repository nutzen. Diese Module bieten in der Sidebar dann z.B. ein Dropdown zur Auswahl eines Artikels aus dem CMS. Beachte auch, dass Artikel-Module im Design weniger flexibel sein können, da der Inhalt bereits vordefiniert aus dem Artikel stammt und die Layout-Optionen möglicherweise festgelegt sind. Im Gegensatz dazu erlauben Inhalts-Module vollen kreativen Spielraum innerhalb eines Mailings. Als Designer kannst du bestimmte Styles nur bei manuell gepflegten Inhalten zulassen und nicht bei Artikeln, um Konsistenz zu wahren. Wichtig ist auch die Pflegeprozesse zu bedenken: Ein Marketer ohne HTML-Kenntnisse wird Artikel-Module schätzen, während ein geübter Editor vielleicht lieber direkt modulare Inhalte baut.

Vorteile von Artikeln:

Eigene wiederverwendbare Objekte
Separate statistische Auswertung beim Versand
Dynamisch generierbare Detailseiten
Automatische Sortierung nach Relevanz

Nachteile von Artikeln:

Eigene Artikel-Vorlagen notwendig
Content-Struktur durch Artikel-Typ(en) vorgegeben
Artikel müssen im Vorfeld angelegt werden

Crossmedialität

Moderne Mailings sollten crossmedial nutzbar sein, das heißt auf verschiedenen Ausgabewegen funktionieren . Evalanche PowerSets tragen dem Rechnung, indem sie die E-Mail-Inhalte auch als PDF/Print-Version, Vorlese- und reine Textversion bereitstellen können. Für Template-Entwickler bedeutet dies, dass man das Mailing so gestaltet, dass es in all diesen Formaten sinnvoll dargestellt werden kann.

Die reine Textversion eines Mailings (Plaintext) wird typischerweise automatisch aus dem Inhalt generiert. Beispielsweise werden Links in der Textversion als vollständige URLs erscheinen. Im „Universalmodul“ (siehe Sonderfälle) ist ein eigenes Textfeld für die Textvariante vorgesehen werden, da der HTML-Inhalt sehr komplex sein kann.
Die Vorleseversion bezieht sich auf die Nutzung durch Screenreader oder evtl. ein generiertes Audio. Alt-Texte bei Bildern sollten gepflegt sein, damit das Vorlese-Systeme Bildinhalte beschreiben kann. Evalanche PowerSet-Templates sind BITV/WCAG-konform aufgebaut, was bedeutet, dass sie die Standards für Barrierefreiheit erfüllen.
Für die PDF/Print-Version gilt es, das Layout drucktauglich zu machen. Evalanche bietet eine PDF-Generierung an, die das Mailing/LeadPage automatisch in ein PDF überführt. Oft werden im PDF alle Inhalte in einer linearen Abfolge ausgegeben. Teste, wie z.B. zweispaltige Abschnitte im PDF aussehen.

Crossmedialität bedeutet auch, dass man inhaltlich konsistente Botschaften über alle Kanäle hat. Eine gute Praxis ist, im Mailing z.B. einen Hinweis auf die Webversion zu haben (“Wenn diese Nachricht nicht richtig angezeigt wird, klicken Sie hier.”) – dieser Link zur Online-Variante wird automatisch im Header/Preheader Modul eingefügt. Ebenso kann man den Newsletter als PDF anbieten, falls Nutzer ihn herunterladen oder drucken wollen.

Durch die PowerSets und den neuen Designer wird diese crossmediale Bereitstellung weitgehend automatisch unterstützt.

Wichtig: Einstellungen zu Social Sharing werden im verknüpften Sprach-Container vorgenommen.

Barrierefreiheit

Der neue E-Mail-Designer erfüllt Barrierefreiheit nach geltenden Standards BITV 2.0 und WCAG 2.0. Für Template-Entwickler heißt das zweierlei: technische Umsetzung und inhaltliche Leitplanken.

Technische Optimierung: Der HTML-Code des Templates wird automatisch von dem PowerSet barrierefrei erzeugt. Achte jedoch auf Kontraste: Definiere die Farben so, dass Text vor Hintergrund ausreichend Kontrast hat. Wenn z.B. eine dunkle Hintergrundfarbe genutzt wird und du dort hellen Text draufsetzt, prüfe, dass dies den WCAG-Kontrastvorgaben entspricht. Buttons sollten ebenfalls einen kontrastierenden Text haben. Falls das Corporate Design sehr helle Farben verlangt, ggf. im StyleSet eine alternative dunklere Schriftfarbe für diese Fälle definieren.

Inhaltsrichtlinien: Weise die Content-Verantwortlichen darauf hin (z.B. in Dokumentation oder Schulung), dass sie barrierefreie Inhalte erstellen. Die PowerSet-Templates unterstützen das mit Funktionen wie Felder für Alt-Text bei Bildern. Die Redakteure sollten verständliche Linktexte schreiben (nicht “hier klicken”, sondern z.B. “Produktdetails lesen”), Überschriften sinnvoll strukturieren (nicht zu viele Hauptüberschriften verwenden), und ggf. die Sprache des Inhalts korrekt markieren, wenn Fremdsprachen vorkommen. Evalanche bietet sogar Möglichkeiten “Barrierefreien Sprache” per AI zu optimieren, dies hilft, Texte in einfache, zugängliche Formulierungen umzuschreiben . Dies ist Teil der AI Generatoren (siehe Abschnitt: AI Content Framework).

Letztlich ist das Ziel, dass der fertige Newsletter sowohl für Sehende optisch ansprechend als auch für Screenreader-Nutzer oder Menschen mit kognitiven Einschränkungen verständlich ist. Ein Barrierefreiheits-Check ist sinnvoll: Prüfe mit einem Screenreader oder entsprechenden Prüftools die Ausgabe. Evalanche stellt auch einen Leitfaden Barrierefreiheit bereit mit einer Checkliste für barrierefreie E-Mails – darauf kannst du in deinem Team verweisen.

Leitfaden Barrierefreiheit (mit Checkliste)

Entwicklung von Vorlagen

Um ein individuelles PowerSet-Template für eMailings oder LeadPages zu erstellen, empfiehlt sich ein strukturiertes Vorgehen. In der Praxis haben sich fünf Schritte bewährt:

(1) der Vorlagenentwurf,

(2) Festlegen erlaubter Einstellungen (für Entwurf),

(3) Festlegen erlaubter Module & Widgets,

(4) Design & StyleSet Umsetzung sowie

(5) Aktualisierungs- und Synchronisationslogik

optional ergänzt um AI-Integration für automatisierte Erstellung oder Optimierung von Inhalten.

Nachfolgend wird dieses Vorgehen für Template-Entwickler erläutert.

Vorlagenentwurf

Am Anfang steht der konzeptionelle Entwurf der Vorlage. Hier solltest du ein Musterlayout mit Dummy-Inhalten erstellen, das alle vorgesehenen Module und Designs im groben zeigt. Ziel ist ein Referenz-Mailing oder LeadPage mit Beispieltexten und Platzhalterbildern, der alle denkbaren Inhaltstypen abbildet: z.B. Header mit Logo, eine Begrüßung, mehrere Artikelteaser, Call-to-Action-Buttons, ggf. ein Zwei-Spalten-Bereich mit Produkten, ein Trenner, Footer etc. Dieses Dummy-Mailing dient später als Vorlage in Evalanche.

Im neuen E-Mail-/LeadPage Designer von Evalanche kann man die Vorlage direkt im sogenannten Templater-Modus (eMailing oder LeadPage Vorlage) umsetzen. Dieser Modus ist in der Regel Partnern/Administratoren vorbehalten, während normale Anwender im Creator-Modus (eMailing oder LeadPage Objekt) arbeiten. Du startest also in der leeren PowerSet eMailing oder LeadPage Vorlage ein neues Template.

Ziehe nacheinander die Module in den Canvas, entsprechend dem Musterentwurf: z.B. ein "Header"-Komponentenmodul, dann ein "Layout"-Modul für den Hauptinhalt etc. Befülle die Module exemplarisch mit Dummy-Texten und -Bildern, so dass das Template nach Fertigstellung wie der abgestimmte Entwurf aussieht. Diese Dummy-Inhalte werden später den Redakteuren als Beispiel angezeigt, wenn sie ein neues Mailing auf Basis der Vorlage erzeugen. Sie wissen dann, wie der Newsletter ungefähr aussehen soll. (Wichtig: Evalanche übernimmt beim Anlegen eines eMailings die Inhalte der Vorlage – i.d.R. müssen die Dummy-Texte manuell überschrieben oder gelöscht werden. Markiere Dummytexte daher eindeutig, etwa als Lorem Ipsum, damit klar ist, dass hier eigene Inhalte hingehören.)

Während du die Module platzierst, überlege auch direkt die Konfiguration der verwendeten Module: Welche Einstellungen (Widgets) jedes Modul haben soll, wer sie ändern darf (Redakteur oder nur Templater) und ob alle benötigten Felder vorhanden sind. Im Templater-Modus kannst du bei jedem Modul definieren, welche Eingabefelder es hat und diese ggf. deaktivieren. Auch Berechtigungen spielen hier eine Rolle: Evalanche erlaubt es, Module so zu konfigurieren, dass gewisse Felder nur im Template bearbeitet werden können (gesperrt für Creator).

Zusammengefasst: In Schritt 1 entsteht ein vollständiges Template-Layout mit allen vorgesehenen Modulen, Stilrichtungen und Beispieldaten. Dieses Gerüst ist die Basis, die in den folgenden Schritten verfeinert wird.

Erlaubte Module und Widgets

Nun geht es ins Detail der Modulkonfiguration. Nachdem der grobe Aufbau steht, lege fest, welche Module in der fertigen Vorlage verfügbar sein sollen und wie weit diese vom Endanwender (Content Creator) konfiguriert werden können. Im PowerSet-Framework stehen standardmäßig alle oben beschriebenen Module (Layouts, Komponenten, Elemente) zur Verfügung. Als Template-Entwickler solltest du jedoch die Auswahl einschränken, um den Editor für die Nutzer übersichtlich zu halten und das Design konsistent zu halten.

Im Templater-Modus kannst du Module deaktivieren, die in deinem Template nicht benutzt oder erlaubt werden sollen. Zum Beispiel, wenn dein Newsletter-Design keinen Event-Bereich vorsieht, könntest du das Modul “Event” für den Creator ausblenden – so taucht es in der Sidebar nicht auf und kann nicht versehentlich genutzt werden. Ähnlich könntest du, je nach Use-Case, entscheiden, nur eine der Artikel-Varianten freizugeben (CMS oder Liste). Die verbleibenden erlaubten Module bilden den Baukasten, aus dem Redakteure später schöpfen können, um neue Inhalte hinzuzufügen. In unserem Beispielnewsletter wären vermutlich "Editorial", "Inhalt", "Artikel (CMS/Liste)", "Bild", "Überschrift", "Text", "Button", "Trenner" relevant – andere Komponenten wie “Kategorie” oder “Bildergalerie” nur, wenn benötigt. Weniger ist oft mehr: Entferne Module, die das Template unnötig verkomplizieren.

Als nächstes definiere die erlaubten Widgets (Eingabefelder) innerhalb der Module. Jedes Modul bringt eine Reihe von Eingabemöglichkeiten mit – siehe z.B. das "Inhalt"-Modul mit Feldern für Bild, Alt-Text, Überschrift, Unterüberschrift, Text, Button-Beschriftung, Link, Hintergrundfarbe, Bildposition, Textausrichtung, Teilungsverhältnis. Frage dich für jedes Feld: Soll der Creator (also der Endnutzer im Editor) dieses Feld sehen und ändern dürfen, oder soll es fixiert werden? In Evalanches neuem Template-Ansatz entspricht dies dem Festlegen von Standardwerten vs. Konfigurationsoptionen.

Beispiel: In vielen Fällen wird der Style eines Moduls (Farben, Schriften, etc.) durch das generelle StyleSet geregelt, sodass man dem Redakteur keine Farbauswahl geben muss – dann kann das Widget “Hintergrundfarbe” im Modul auf einen Default gestellt und verborgen werden. Oder du möchtest, dass Redakteure keine eigenen Schriftgrößen einstellen können (um die Typografie einheitlich zu halten) – entsprechend gibt es im Text-Widget gar keine Option für Schriftgröße, sondern nur den Inhalt. Umgekehrt könntest du Optionen aktivieren, wenn Flexibilität gewünscht ist: z.B. ein Text-Element hat standardmäßig evtl. keine Farbeinstellung, aber du könntest ein Widget “Textfarbe” hinzufügen, wenn du dem Benutzer erlauben willst, einen Textblock andersfarbig zu gestalten (sofern CD-konform).

Technisch wird das in Evalanche meist so gelöst, dass man in der Template-Definition diese Widgets konfiguriert. Nicht erlaubte Einstellungen blendet man aus. Dadurch hat der Editor im Creator-Modus nur die wirklich notwendigen Eingabefelder vor sich. Das reduziert Fehlerquellen und Schulungsaufwand. Diese Phase erfordert etwas Weitsicht: Überlege, welche Felder ein Redakteur wirklich variabel braucht. Alles andere kannst du fest im Template setzen.

Beispiel: Im "Editorial"-Modul könnte der Anrede-Teil fix “Sehr geehrter Herr/Frau [Personalisierung]” sein, ohne dass der Redakteur daran etwas ändern darf – dann würde man das Anrede-Checkbox-Widget gar nicht anzeigen. Im "Button"-Element wiederum gibt es wenig zu beschränken – hier sind Beschriftung und Link natürlich variabel, aber den Stil willst du vorgeben. Also belässt du nur diese zwei Felder.

Design & StyleSet

In diesem Schritt geht es darum, das definierte Gestaltungskonzept technisch umzusetzen: alle globalen Styles festzulegen und das StyleSet mit Leben zu füllen, sowie Standardwerte für Module zu setzen nach folgenden Schritten:

Globales StyleSet definieren
Konfiguration globaler Styles einschränken
Abweichende Module-Style definieren, sofern nötig

Zunächst stelle in den Template-Einstellungen (bzw. im globalen Konfigurationsmodul) die allgemeinen globalen Einstellungen ein. Das umfasst primär:

Farben: Lege die Farbpalette fest. In Evalanche PowerSet 2 Templates gibt es typischerweise Variablen für Standard-Hintergrund, Standard-Text, Linkfarbe und Standardfarben. Trage hier die HEX-Werte des Corporate Designs ein. Alternativ kannst du auch mit der Pipette die gewünschten Farben auswählen. Diese Werte werden dann von den Modulen verwendet.
Typografie: Eine konsistente Typografie wird ebenfalls im StyleSet bzw. Template-Code festgelegt. Template-Entwickler definieren in der Regel die Schriftfamilie und -größe sowie den Zeilenabstand (line-height) für verschiedene Texttypen: Headlines (Überschriften), Subheadlines (Unterüberschriften), Fließtext und Links. Beispielsweise kann festgelegt werden, dass die Überschriften eine bestimmte Web-sichere Schrift (z.B. Arial oder Verdana) in einer größeren Schriftgröße und farblich abgehoben verwenden, während der Fließtext in einer gut lesbaren Standardgröße gehalten ist. Es werden derzeit nur websichere Schriften angeboten, die in E-Mail-Clients zuverlässig dargestellt werden (z.B. Arial, Helvetica, Verdana, Times New Roman). Zudem sollte das Verhältnis zwischen Überschrift und Normaltext stimmig sein (Überschriften deutlich größer als Text, aber nicht übertrieben). Zeilenhöhen werden so gewählt, dass Texte leicht lesbar sind – weder zu dicht (sonst “kleben” die Zeilen), noch zu weit auseinander . All diese typografischen Vorgaben hinterlegt der Entwickler zentral. So werden Überschriften-, Fließtext- und Link-Stile automatisch einheitlich angewendet. Links können z.B. eine definierte Standardfarbe (etwa Corporate Color), damit sie im Text erkennbar sind.
Button-Stile: In den PowerSet-Templates sind üblicherweise drei Button-Stile vorgesehen, um verschiedene Arten von Call-to-Action zu ermöglichen: Umrandet, Gefüllt und TextOnly. Diese Styles unterscheiden sich in der Darstellung:
- Gefüllter Button (Primary Button) hat einen vollflächig farbigen Hintergrund (typischerweise die Hauptaktionsfarbe) mit kontrastierender Schriftfarbe (z.B. weiß auf blauer Fläche). Er wird für die wichtigste Aktion verwendet.
- Umrandeter Button (Secondary Button) ist transparent mit farbigem Rand und Text (oft in der Primärfarbe gehalten). Dieser Stil eignet sich für sekundäre Handlungsaufforderungen, um weniger Gewicht als der primäre CTA zu haben, aber dennoch sichtbar zu sein.
- Text-Only Button (Link-Stil) erscheint lediglich als hypertext (farbiger, evtl. unterstrichener Link) ohne spezielle Button-Grafik. Dies kann für unaufdringliche Links oder im Fließtext eingesetzt werden.

Nachdem das StyleSet sitzt, schaue dir jedes Modul in der Vorlage nochmals an und prüfe die Standardeinstellungen:

Sind alle Module so vorbelegt, wie es der Regelfall sein soll? Beispiel: Das "Footer"-Modul könnte eine Option “Hintergrundfarbe” haben (keine/hervorgehoben). Wenn du erwartest, dass meist kein farbiger Footer genutzt wird, setze den Default auf “Keine” und ggf. sperre die Option, falls unerwünscht.

Oder im "Inhalt"-Modul: Standard-Bildposition vielleicht “Links” und Teilungsverhältnis “50:50” – außer dein Design sieht standardmäßig z.B. ein großes Bild oben vor, dann wäre “Oben” der Default. Diese Defaults sind im Dummy-Content schon umgesetzt, aber prüfe in den Modul-Einstellungen, dass die Default-Werte korrekt hinterlegt sind, falls ein Redakteur ein neues Modul dieses Typs hinzufügt. (Ein neu hinzugefügtes Modul startet meist mit Standardwerten.)

Deaktiviere testweise/gedanklich bestimmte Elemente: Was passiert, wenn ein Redakteur z.B. keinen Untertitel im Inhaltsmodul eingibt? Ist das Feld optional?

Kurz gesagt, in diesem Schritt wird das Template design-technisch finalisiert: Alles, was mit Aussehen und Style zusammenhängt, wird festgelegt oder als Wahlmöglichkeit implementiert. Danach sollte das Newsletter-Template dem gewünschten Design entsprechen und alle Schalter und Optionen nur das ermöglichen, was erlaubt ist.

Aktualisierungslogik und Synchronisation (Noch nicht verfügbar)

Ein großer Vorteil der PowerSet-Architektur ist die Möglichkeit, Vorlagen-Updates zentral vorzunehmen und auf bestehende Mailings anwenden zu können. Als Template-Entwickler musst du daher eine Aktualisierungslogik einplanen: Wie sollen sich Änderungen an der Vorlage auf bereits erstellte oder abgeleitete eMailings auswirken? Und wie geht das System damit um?

Sync-Einstellungen für platzierte Module/Widgets: Wenn ein Redakteur ein neues eMailing auf Basis deiner Vorlage erstellt (via Creator), werden alle in der Vorlage vorhandenen Module als Instanzen in dieses Mailing kopiert. Ab dann können sie im Mailing individuell geändert werden, ohne die eigentliche Vorlage zu beeinflussen. Wenn du später die Vorlage änderst (z.B. das Inhalts-Modul erhält ein neues Feld oder du passt das Layout an), stellt sich die Frage: Sollen bestehende Mailings diese Änderung erhalten? In Evalanches neuem System gibt es eine Synchronisations-Funktion für Vorlagen und Mailings/LeadPages. Du kannst als Entwickler pro Modul definieren, ob es deren Inhalte synchronisieren soll. Eine Synchronisierung erfolgt immer manuell innerhalb der Vorlage.

Daher überlege für jedes Template-Modul: Statisch oder dynamisch? Bereiche wie der Header ändern sich selten; wenn doch (neues Logo, geänderte Webversion-Formulierung), möchte man es überall einheitlich haben. Hier macht Synchronisation Sinn – der Header kann in den Mailings gesperrt oder zumindest mit Vorlage verknüpft sein (im Beispiel ist der Header nur in der Vorlage bearbeitbar). Inhaltsblöcke hingegen sind meist individuell pro Mailing, da sie ja die unterschiedlichen Newsletter-Inhalte repräsentieren – hier würde ein Sync keinen Sinn ergeben. Also bleibt z.B. das Inhalts-Modul unsynchronisiert (losgelöst) in jedem Mailing-Klon.

Sync für optionale Module/Widgets: Eine besondere Herausforderung sind optionale Module, also solche, die nicht in jeder Instanz vorhanden sind. Angenommen, du hast das Template minimal gehalten (nur Kernmodule) und der Redakteur kann zusätzliche Module hinzufügen. Was, wenn du später das Template erweiterst – z.B. fügst du ein neues Modul hinzu? Bereits bestehende Mailings haben davon nichts mitbekommen. Hier gibt es zwei Ansätze: Entweder man belässt es und kommuniziert, dass das neue Modul nur in neu erstellten Mailings zur Verfügung steht. Oder man versucht, bestehende Mailings beim nächsten Bearbeiten zu aktualisieren – etwa indem das System erkennt, dass ein neues Template-Modul existiert und es als neue Option in die Sidebar ergänzt.

Insgesamt solltest du klare Update-Prozesse definieren: Wenn z.B. rechtliche Änderungen im Footer notwendig sind, wird das Template angepasst und dann alle aktiven Templates synchronisiert. Dokumentiere, welche Teile des Templates vom Marketing selbst gepflegt werden können und welche nur durch einen Template-Update geändert werden können.

Ein weiteres Element der Aktualisierungslogik ist die Versionierung. Es kann sinnvoll sein, großen Änderungen nicht am bestehenden Template durchzuführen, sondern eine neue Template-Version anzulegen (z.B. „Newsletter PowerSet v2“) und neue Mailings daraus zu erzeugen, während alte Mailings mit der alten Version fortgeführt werden. Evalanche bietet daher die Möglichkeit, Templates zu duplizieren.

Zusammengefasst: In diesem Schritt planst und konfigurierst du, was passiert, wenn das Template geändert wird, um eine konsistente Nutzung sicherzustellen. Synchronisation kann ein mächtiges Feature sein, muss aber gezielt eingesetzt werden, damit die Creator-Nutzer nicht von überraschenden Änderungen betroffen sind oder umgekehrt wichtige Updates verpassen.

Sonderfälle und Tipps

Nicht alle Anforderungen lassen sich mit den Standardmodulen sofort abbilden. Hier einige Sonderfälle, die Template-Entwickler beachten bzw. nutzen können:

Freies Text-Element für individuelle Gestaltung: Das Text-Element (bzw. “Text” im neuen Designer) ist ein flexibel einsetzbarer Baustein, da es im Prinzip reinen HTML-Text aufnimmt. Redakteure können darin Absätze schreiben, Listen erstellen, Links setzen etc. und über den Inline-Editor formatieren (fett, kursiv, ggf. Farben) - z.B. ein großes Prozentzeichen als grafisches Element für einen Rabatt.
Wenn etwas sehr Individuelles benötigt wird – etwa ein spezielles formatiertes Zitat, eine Tabelle oder eingebetteter externer Code – kann man manchmal das Text-Element dafür verwenden. Zum Beispiel könnte man im HTML-Modus des Textfelds speziellen Code einfügen. Allerdings ist Vorsicht geboten: Viele E-Mail-Clients filtern bestimmte HTML-Tags, und man sollte die Konsistenz des Designs nicht gefährden.
Universalmodul mit eigener Textversion (HTML-Modul): Es kann vorkommen, dass der Kunde einen Inhalt wünscht, der durch kein vorhandenes Modul gut abgebildet wird – z.B. einen komplex formatierten Banner mit personalisierten Platzhaltern innerhalb des Textes, oder ein interaktives Element. Hier kann ein Template-Entwickler ein Universal- bzw. Custom-Modul programmieren. Dieses Modul hätte dann ein Widget vom Typ “HTML-Code” oder ähnliches, wo der Redakteur den gewünschten Code reinkopieren kann, der 1:1 im Mailing erscheint. Ein solcher Ansatz ist vergleichbar mit einem “Raw HTML”-Block. Wenn du so etwas vorsiehst, denke an die Textversion! Standardmäßig würde ein blockierter HTML-Inhalt eventuell als Leertext in der Plaintext-Version enden. Du solltest daher im Modul ein zusätzliches Textfeld einbauen für den Textversion-Inhalt. Beispielsweise: Ein Modul “HTML-Block” mit zwei Eingabefeldern – HTML (für die HTML-Version) und “Textalternative” (für die Textversion).
Für Barrierefreiheit und Crossmedia ist es also notwendig, bei allen modulspezifischen Inhalten einen Blick auf die Nicht-HTML-Ausgabe zu haben. Falls dein Template eigene Quellcode-Module beinhaltet, dokumentiere klar, wie die Textversion gehandhabt wird.
1-, 2-, 3-Spalter-Kombinationen: Die vordefinierten Layout-Module (ein-, zwei-, dreispaltig) können auch kombiniert eingesetzt werden, um komplexere Strukturen zu schaffen. Ein Beispielszenario: Du möchtest einen Bereich mit 3 Spalten in einer Zeile direkt unterhalb eines einspaltigen Intros. Dafür ziehst du zunächst ein "Layout: (3-Spalter)"-Modul in den Canvas; in jede der drei Spalten kommt dann z.B. ein "Bild"-Element oder eine kleine "Inhalt"-Komponente (z.B. drei Produkte nebeneinander). Unterhalb davon möchtest du aber wieder zwei Spalten haben? Dann fügst du unter dem 3-Spalter-Modul ein "Layout: (2-Spalter)"-Modul ein. So entstehen getrennte Abschnitte mit unterschiedlicher Spaltenanzahl. Diese Schachtelung in der Vertikalen ist problemlos möglich. Was nicht geht, ist verschachtelte Spalten (also z.B. ein 2-Spalter innerhalb eines 3-Spalters) – das lässt der Editor nicht zu, und es wäre auch fürs responsive Verhalten problematisch. Daher arbeitet man modular Abschnitt für Abschnitt.

Zusammengefasst: PowerSets decken die meisten Standardszenarien ab, doch es gibt auch immer wieder Spezialfälle. Dank der Modularität kann man meist auch ungewöhnliche Anforderungen abbilden, indem man Module kombiniert oder eigene kleine Erweiterungen schafft. Wichtig ist, trotz Sonderfällen die Wartbarkeit des Templates im Blick zu behalten – jeder zusätzliche Freiraum für Individual-HTML birgt Risiken für die Einheitlichkeit.

PowerSet 2 (Beta)