PEIQ Knowledge Base

Hilfestellung zum objektübergreifenden Vorlagenbau

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. 

vor eingestellte Objekte führt zu unterschiedlichen Ausgaben

 

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.

 

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

 

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?

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

 

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?

Verwandte Seiten

 

Nur für PEIQ-Mitarbeiter:

https://peiq.atlassian.net/wiki/spaces/CORE/pages/1295351973