PEIQ Knowledge Base
Hilfestellung zum objektübergreifenden Vorlagenbau
- Marlis Heidinger
- Manh Long Nguyen
In der Best Practice Lösung in der Cloud sehen wir in NGen keine harte Mandantentrennung mehr vor. Das bedeutet: jeder User sieht die Produktionsdaten aller Objekte. Auch der Agentureingang ist zentral, man sieht jedem Element an, wo es bereits verwendet wird - objektübergreifend.
Funktionalitäten Hilfestellung beim objektübergreifenden Vorlagenbau
Gleichzeitiges Arbeiten für mehrere Objekte
Weiches Mandantenkonzept
Benutzerstruktur beim objektübergreifenden Arbeiten
Objektübergreifendes Arbeiten
Vorlagen für den Austausch zwischen mehreren Objekte
Grundsätzliche Empfehlungen an das Layout der einzelnen Objekte
Zentrales “Tiefen-Customizing”
Inhaltsverzeichnis
1. Gleichzeitiges Arbeiten für mehrere Objekte
1.1 Weiches Mandantenkonzept
In der Best Practice Lösung in der Cloud sehen wir in NGen keine harte Mandantentrennung mehr vor. Das bedeutet: jeder User sieht die Produktionsdaten aller Objekte. Auch der Agentureingang ist zentral, man sieht jedem Element an, wo es bereits verwendet wird - objektübergreifend.
Jeder redaktionelle User ist seinem “Heim-Objekt” zugeordnet, so dass er objektspezifische Voreinstellungen wie Default-Objekt, Default-Ausgabe, Default-Ressort und in seinem Heim-Objekt verwendete Seiten-/Artikelvorlagen etc. benutzt.
Er kann aber auch nach den Produktionsdaten anderer Objekte suchen, um zum Beispiel Inhalte auszutauschen. Ein Benutzer-Wechsel ist dazu nicht nötig.
In den Suchen- und Anlegen-Masken entscheidet das Objekt darüber, welche Ausgaben dem Anwender zur Verfügung stehen.
Je nach gewähltem oder gemäß Benutzerkontext vor eingestellten Objekt werden unterschiedliche Ausgaben angeboten.
1.2 Benutzerstruktur beim objektübergreifenden Arbeiten
Die Benutzerstruktur ist so angelegt, dass es mehrere Objekte innerhalb eines Verlages gibt, und unter jedem Objekt-Knoten sind die in diesem Objekt vorhandenen Benutzergruppen angesiedelt.
Pro Objekt gibt es die Gruppe
<objektkürzel>_lay_red: Hier werden die redaktionellen Benutzer hinterlegt, die alle Rechte zum Schreiben und Layouten erhalten. Optional gibt es darunter noch die Gruppe <objektkürzel>_red, für schreibende Redakteure ohne Berechtigung für das Layouten
<objektkürzel>_workflow (nur relevant für PEIQ) Dies ist ein “unbenannter” User, der im Hintergrund für die PDF-Ausgabe des jeweiligen Objekts zuständig ist
Einmalig im kompletten Verlagsobjekt gibt es die Gruppen
<verlag>_anzeigen ist unterteilt in die Benutzergruppen
<verlag>_auftragsbearbeitung und
<verlag>_buchhaltung. Beide sind für die Nutzung des Anzeigensystems, jedoch haben Buchhaltungsnutzer erweiterte Rechte wie z.b. das ausführen der Faktura.
<verlag>_api Die Benutzergruppe API wird für die Generierung der Token zur Authentifizierung mit der “Bearer Token”-Methode beim Aufrufen der PEIQ APIs (AdAPI, CreateAPI, DAM API, PrintAPI) benötigt. An den Usern ist hinterlegt, für welche API(s) Berechtigungen mit dem über den User generierten Token vorliegen. (nur relevant für PEIQ)
(optional) <verlag>_assist
<verlag>_blattplanung
<verlag>_lay_red mit der Untergruppe <verlag>_vorlagenbau
<verlag>_nwas (nur relevant für PEIQ)
<verlag>_sys mit der Untergruppe <verlag>_sys_mc (nur relevant für PEIQ)
<verlag>_workflows (nur relevant für PEIQ)
Hinweis: Sie können diejenigen Benutzergruppen, die wir objektübergreifend einmal pro Verlag definiert haben, alternativ natürlich auch in die Objektgruppen packen, falls die Benutzer nicht verlagsübergreifend arbeiten, sondern ganz gezielt für ein einzelnes Objekt.
1.3 Objektübergreifendes Arbeiten
1.3.1 Objektübergreifendes Arbeiten in der Redaktion
Wie oben beschrieben, sieht der Benutzerbaum neben den objektspezifischen Usern auch übergeordnete User vor, wie Anzeigensystem, Blattplanung, Vorlagenbau.
Diese User haben keine objektbezogenen Default-Werte für Ausgabe, Ressort etc.
Benutzer in der Redaktion, die für mehrere Objekte arbeiten und auch mit den Vorlagen des jeweiligen Objektes layouten sollen, benötigen
entweder
A) Zugriff auf die zu verwendenden Vorlagen-Bibliotheken aller Objekte (wie auch der Vorlagenbauer oder der Planer)
oder
B) die Möglichkeit eines Benutzerwechsels in ihr “Pendant” im anderen Objekt
Beide Varianten haben ihre Vorteile.
Variante A kommt ohne den Benutzerwechsel aus
Variante B kann dem User ganz gezielt ausschließlich die Vorlagen und Default-Werte zur Verfügung stellen, die im jeweiligen Objekt benötigt werden.
 | Wenn Sie sich für Variante B entscheiden, müssen Sie bei den entsprechenden Benutzer(gruppe)n angeben, in welche anderen Benutzer sie wechseln dürfen. |
| Diese User stehen nun beim Klick auf den Button ”Benutzer” in der Default-Werkzeugleiste zur Verfügung … |
 | … und können aus einem Dialog ausgewählt werden. |
1.3.2 Objektübergreifendes Arbeiten beim Vorlagenbauer
Wie auch die Anzeigensystem-User und der Planer ist der Vorlagenbauer objektübergreifend tätig. Achten Sie also darauf, dass er im Benutzerkontext Zugriff auf alles bekommt, was er für den Vorlagenbau und für das Testen von Vorlagen braucht.
Insbesondere geht es um folgende vier Einstellungen (Eigenschaftsgruppen “Bibliotheken” und “Bibliotheken gedockt/erstellen”).
Farben (Füllungsdialog)
Layouts-Gedockt
Artikel-Erstellen
Layouts-Erstellen
2. Vorlagen für den Austausch zwischen mehreren Objekten
2.1 Grundsätzliche Empfehlungen an das Layout der einzelnen Objekte
Die im folgenden aufgelisteten Empfehlungen haben das Ziel, mit möglichst geringer manueller Nacharbeit Inhalte zwischen verschiedenen Objekten zu tauschen. Natürlich lassen sich, je nach Corporate Design, nicht alle der Punkte ad hoc realisieren, aber eine entsprechende Anpassung Ihres Layouts sollte auf jeden Fall in Betracht gezogen werden, um den Austausch so effizient und einfach wie möglich gestalten zu können.
gleiche Spaltenbreiten und Spalten-Zwischenschläge
gleiche Spaltenanzahl
gleiche Zeilenhöhen
ähnlich laufende Grundschrift, um möglichst wenig Über-/Untersatz ausgleichen zu müssen
2.2 Was tun bei unterschiedlichen Spaltenrastern?
2.2.1 Wie baut man Vorlagen für ein Objekt, das verschiedene Spaltenbreiten und Zwischenschläge nutzt? Wie viele Vorlagen benötigt man?
Es ist grundsätzlich nicht nötig, für ein Objekt gleiche Artikelvorlagen mehrfach zu bauen, um sämtliche möglichen Spaltenbreiten abzudecken.
Es ist ausreichend, eine Variante für eine (idealerweise die gängigste) der verwendeten Spaltenbreiten und Zwischenschläge zu bauen.
Hinweis:
Zu beachten ist jedoch, dass man eine gewissen manuellen Mehraufwand hat, um diesen Artikel nach dem Platzieren auf einem abweichenden Spaltenraster in Form zu bringen:
Wenn die Zeilenhöhe identisch ist, reicht es, den Artikel nach dem Platzieren (dabei sollte er auf der linken Kante einer Spalte einspringen) einmal an der rechten Kante breiter oder schmäler zu “zupfen”, damit er in das neue Raster einspringt. Dabei passt sich bei einem Mehrspalter auch die Breite des Zwischenschlages an. Ist die Zeilenhöhe auch unterschiedlich, muss man auch an der Unterkante des Artikelcontainers zupfen.
Ausnahme bilden natürlich diejenigen Artikelvorlagen, die bewusst ein eigenes Spaltenraster erhalten haben, klassischerweise einspaltige Infoboxen oder Kommentarspalten, die i. d. R. nach innen eingerückt sind und häufig mit einer umrahmenden Linie versehen sind. Diese werden grundsätzlich - egal wie schmal oder breit sie auf der Seite gezogen werden - ihr eigenes Raster behalten - im Extremfall läuft dann ein Einspaltig über sieben Spalten Breite auf der Seite (außer er ist in der Breite fixiert und daher eh nicht flexibel veränderbar)
Möglich wäre auch, abhängig von der Breite eines Artikelcontainers dem Artikel selbst ein unterschiedliches Spaltenraster (via Layoutabbildung, aus einer Vorlagenbibliothek) zuzuweisen.
Hinweis:
Möchten Sie sich den Mehraufwand des “Zurechtzupfens” ersparen, können Sie alternativ für alle möglichen Spaltenbreiten und Zwischenschläge eigene Vorlagen bauen. Das erhöht natürlich die Anzahl der Vorlagen enorm, und die Auswahl einer geeigneten Vorlage wird für den Anwender dadurch unübersichtlich und in Folge dessen fehleranfälliger, weil man sich schnell mal vertut.
2.2.2 Wie kann man ein abweichendes Spaltenraster für einzelne Bereiche einer Seite vergeben?
Wir empfehlen hier die Arbeit mit eigenen Teilseiten, die ein von der Seite abweichendes Raster haben. Teilseiten haben auch den Vorteil, dass theoretisch jede Teilseite auf einer Ganzseite gleichzeitig von einem Layouter bearbeitet werden kann, ohne dass man sich gegenseitig den Zugriff auf die Ganzseite sperrt.
Alternativ möglich ist auch, für die Ganzseite ein sogenanntes inhomogenes oder auch komplexes Spaltenraster zu vergeben. So kann die Ganzseite unterschiedliche Spaltenbreiten und Spalten-Zwischenschläge haben. Auf so einem komplexen Raster platzierte Artikel sind sogar in der Lage, sich an dieses Raster anzupassen, wenn man sie über mehrere inhomogene Spalten hinweg breiter oder schmäler zieht, sie haben also wie die Seite selbst unterschiedlich breite Spalten und Zwischenschläge.
2.2.3 Austausch zwischen Objekten mit unterschiedlichem Raster
Hinweis:
Wenn Sie Inhalte zwischen Zeitungstiteln austauschen, die mit unterschiedlichem Spaltenraster arbeiten, müssen Sie ebenfalls, wie oben angesprochen, die Artikel im Anschluss in das neue Raster “zupfen”.
2.2.4 Generelle Empfehlung
Unsere Empfehlung ist natürlich, insbesondere in Anbetracht des Austauschens von Inhalten zwischen Objekten, mit einheitlichen Spaltenbreiten, Zeilenhöhen und Zwischenschlägen zu arbeiten, um den oben angesprochenen händischen Mehraufwand nach dem Platzieren (Stichwort “Zupfen”) zu vermeiden.
2.3 Basisformate: Das A und O beim Austausch!
Basisformate sind das A und O für einen effizienten Austausch von Artikeln zwischen verschiedenen Zeitungstiteln.
2.3.1 Kurze Erklärung Basisformatbibliothek/Basisformat-Element
Über die Abbildung “BasisformatBibliothek”, auf die Sie am Seitencluster bei der Eigenschaft “BasisformatBibliothek” verweisen…
… steuern Sie in Abhängigkeit von Seiteneigenschaften - insbesondere dem Objekt - welche BasisformatBibliothek greift.
An den einzelnen Bereichen auf der Seiten- oder Artikelvorlage werden die Basisformate vergeben
2.3.2 Neutrale Benennung der Basisformate
Achten Sie darauf, die Basisformate für Elemente, die es in verschiedenen Größen geben kann, neutral zu benennen.
Also nicht “Titel_30pt”, sondern neutral, wie z. B.
“Titel_S”, “Titel_M”, “Titel_L”, “Titel_XL” etc.
Die neutrale Benennung ist sinnvoll, wenn mehrere Objekte miteinander Inhalte austauschen. Das Basisformat “Titel_XL” bedeutet dann in Objekt A z.b. 48pt, im Objekt B 54pt Schriftgröße.
2.3.3 Gleiche Namen für Basisformate über alle Objekte hinweg!
Wenn Sie möchten, dass beim Austausch zwischen den Objekten Ihre Basisformate auch wirken, müssen Sie in den Basisformat-Bibliotheken der einzelnen Objekte auch mit dem gleichen Namen angelegt sein.
Das Basisformat “Titel_S” in der Basisformat-Bbliothek von Objekt A muss auch in der Bibliothek von Objekt B mit gleichem Namen vorhanden sein. Andernfalls kann es nicht interpretiert werden.
Beachten Sie zur Benennung der Basisformate bitte unbedingt den folgenden Abschnitt.
2.3.4 Muss es jedes Basisformat in jedem Objekt geben?
Hinweis: Neue Information
Insbesondere beim Austausch zwischen einem Boulevard-Objekt, das beispielsweise zahlreiche verschiedene Titelvarianten in Basisformaten abgebildet hat, und einem Tageszeitungs-Objekt, das nur die vier Varianten S, M, L und XL für die Titelbereiche verwendet, stellt sich die Frage: Muss man im einfacheren Objekt wirklich sämtliche Basisformate des komplexeren Objektes abbilden?
Die Antwort lautet: nein, wenn man bei der Benennung der Basisformate gewisse Grundregeln beachtet.
Beispiel:
Objekt1 benötigt jeden Titelbereich in der Variante schwarz, weiß und rot. Zudem gibt es die Größen von S bis XXL.
Objekt B nutzt lediglich die Titelgrößen S bis L, und grundsätzlich sind alle Titelbereiche mit schwarzer Schrift definiert.
Korrekte Benennung:
Objekt A | Objekt B |
|
|---|---|---|
Titel#S#rot | Titel#S | Da in Objekt B die Variante “Titel#S#rot”, “Titel#S#weiß” und “Titel#S#schwarz” nicht existieren, sucht NGen als nächstes nach einem Basisformat mit dem Namen “Titel#S” |
Titel#S#weiß |
| |
Titel#S#schwarz |
| |
Titel#XXL#rot | Titel | Wenn das System weder die Variante “Titel#XXL#rot” noch “Titel#XXL” findet, verkürzt es zu “Titel” |
2.3.5 Möglichst wenig setzen, möglichst viel erben
Um die Basisformat-Logik beim Austausch optimal auszuschöpfen, gilt die Regel: möglichst viel in den Basisformaten setzen und möglichst wenig direkt in den Vorlagen. So dass Sie idealerweise alles aus den Basisformaten erben können und nicht beim Austausch über gesetzte Werte stolpern, die im Objekt A zwar wunderbar passen, im Objekt B aber stören.
Im schlimmsten Fall hat Objekt A an der Artikelvorlage fest die Grundschrift am Textbereich gesetzt, Objekt B nimmt aber natürlich eine ganz andere Schrift.
2.4 Makros gleich benennen!
Wenn Objekte miteinander Inhalte austauschen, müssen natürlich auch die Textformatierungen (“Makros”) in den Makrobibliotheken der Objekte gleich heißen.
(Eine Benennung mit # wie bei den Basisformaten ist hier nicht möglich, da ein Tagname mit # im XML nicht erlaubt ist!)
Existiert in Objekt B ein Makro nicht, das in einem Artikel aufgerufen wurde, der von Objekt A übernommen wurde, ist die Darstellung des Makros in Objekt B einfach unformatiert.
2.5 Bereichsnamen gleich benennen/Gleiche Bereiche in allen Objekten?
Bereichsnamen werden ausschließlich von PEIQ vergeben, so dass hier nicht die Gefahr von “Bereichsnamen-Wildwuchs” besteht.
Wichtig ist aber dennoch die Überlegung: gibt es über alle Objekte hinweg die gleichen Bereiche?
Wenn Objekt A mit Dachzeilen arbeitet, Objekt B aber mit Unterzeilen - wird das Basisformat “Dachzeile” dann in Objekt B einfach wie eine Unterzeile interpretiert?
Farbwechsel beim Austausch zwischen Objekten
| Wenn die Farbnamen verlagsweit eindeutig sind und sich der Wert einer Farbe nicht beim Austausch mit einem anderen Objekt verändern soll, reicht es, die Farben innerhalb der Objekt-Farbbibliothek (im Beispiel links “LZ_Farben”) zu erstellen, die unterhalb der Verlags-Farben-Bibliothek (im Beispiel links unten “PM_Alle_Farben”) eingehängt ist. |
| Wenn das Objekt mit anderen Objekten Austausch betreiben soll und sich dadurch automatisch die Farben verändern sollen, müssen in der Verlags-Füllungsbibliothek und der Bibliothek für das erste Objekt die Farben wie links aufgezeigt erstellt werden. Die Farben sollten neutral benannt sein, also nicht “blau” oder “grün” sondern “A, B, C” oder “01, 02, 03” etc. Die Farbwerte sind jeweils identisch, also “01” in LZ-Farben und “01#lz” in PM_Alle_Farben haben die gleichen Farbwerte |
2.6 Automakros, Autotexte gleich benennen!
Auch Automakros und Autotexte müssen über die Objekte hinweg gleich benannt sein!
3. Zentrales “Tiefen-Customizing”
Neben dem Customizing für den Vorlagenbau wie Layout-Bibliotheken, Makros etc. gibt es auch einige Elemente im sogenannten “Tiefencustomizing”, die anzupassen sind. Sie finden diese Elemente (Abbildungen und Wertelisten) in der Mappe “CustomizingAusnahmenKunde”, die Ihnen als Vorlagenbauer in der Systembetreuer-Werkzeugleiste zur Verfügung steht.
Diese Elemente befinden sich nicht in Objektspezifischen Abbildungs- und Wertelisten-Bibliotheken, sondern in den Verlags-Bibliotheken. Es gibt also keine objektspezifischen Abbildungs/Wertelisten-Bibliotheken.
Wenn man für mehrere Objekte arbeitet, muss man also darauf achten, dass man in den Abbildungen/Wertelisten, wo dies nötig ist, alle Objekte abbildet.
Zum Beispiel in der Werteliste “BasisformatBibliothek”
der Layoutabbildung “LA_Kopfposition”
der SeitenKöpfe-Abbildung
etc.
Welche Unterschiede zwischen den Vorlagen der einzelnen Objekte können abgebildet werden?
Was ist das erlaubte Delta zwischen den Objekten (z.B. Linien in einem Objekt, andere Form der Infoboxen in einem Objekt etc)?
Wo liegen die Grenzen des möglichen Deltas zwischen den Objekten?
Dieses Kapitel ist aktuell noch in Bearbeiten (wip).
Verwandte Seiten
Nur für PEIQ-Mitarbeiter:
https://peiq.atlassian.net/wiki/spaces/CORE/pages/1295351973