Technische Redaktion · Hilfe & Dokumentation Intern
EID HUB · Interne Dokumentation

Handbuch für die
Technische Redaktion

Alles, was du für den täglichen Umgang mit Editor, Kanban-Board und Redaktionsplan brauchst – kompakt, direkt nachschlagbar.

⌨️

Editor

Der Content Designer im Browser – kein lokaler Build notwendig

1 Kategorie wählen & Beitrag laden

Der Editor arbeitet mit JSON-Dateien pro Kategorie. Jede Kategorie entspricht einer Datei im data/-Ordner — z. B. agile.json, leadership.json, podcast.json.

  1. In der linken Leiste sind alle verfügbaren Kategorien und deren Beiträge direkt aufgelistet. Klicke dort auf eine Kategorie (Agile, Leadership, Projektmanagement, Team, Podcast), um sie aufzuklappen.
  2. Klicke auf den gewünschten Beitragstitel in der Liste — alle Meta- und Contentfelder im Editor werden sofort befüllt.
  3. Nutze das Suchfeld oben in der Leiste, um nach Titel, Slug oder Kategorie zu filtern. Bei vielen Einträgen ist das deutlich schneller als scrollen.
  4. Das Template-Dropdown oben im Editor erkennt den Typ automatisch (blog, page, landingpage, podcast, team). Nur beim Template blog ist der FAQ-Tab freigeschaltet.
💡 Tipp

Die Seitenleiste zeigt immer den aktuell geladenen Beitrag markiert an. Willst du schnell zwischen Artikeln wechseln, bleib in der Leiste — der Editor lädt den neuen Datensatz ohne Seitenwechsel.

2 HTML-Editor: Visuell & Code

Der Content-Bereich hat sechs Tabs. Die zwei wichtigsten für die Redaktion:

Tab Wofür Wann nutzen
Visuell WYSIWYG-Editor mit Toolbar (H2, H3, Fett, Kursiv, Listen, Links) Standardarbeit: Text schreiben, strukturieren, Links setzen
HTML Direkter Code-Editor (CodeMirror mit Syntax-Highlighting) Feinarbeit, bestehende HTML-Blöcke einfügen, Fehler bereinigen
Preview Gerenderte Vorschau des HTML-Inhalts Letzte Sichtkontrolle vor dem Export
SEO Google-Snippet-Vorschau + Zeichenzähler Prüfen ob Titel und Beschreibung passen
FAQ FAQ-Paare verwalten (nur Blog) FAQ-Blöcke hinzufügen, bearbeiten, sortieren
Assets Eingebundene Bilder im Überblick Nach Drag & Drop prüfen, assets.json erstellen

Toolbar-Befehle (Visuell-Tab):
Markiere Text und klicke H2/H3 für Überschriften, B/I/U für Formatierung, „• Liste" oder „1. Liste" für Aufzählungen. „Link" fragt per Popup nach der URL. „Clean" entfernt alle Inline-Formate — nützlich bei eingefügtem Text aus Word.

HTML-formatieren: Im HTML-Tab gibt es den Button „HTML formatieren" — er fügt korrektes Einrücken ein, ohne den Inhalt zu verändern. Nützlich nach manuellem Code-Einfügen.

Bilder per Drag & Drop: Bild direkt in die Dropzone oben ziehen. Der Editor berechnet einen SHA-1-Hash und fügt einen <img src="/assets/HASH.ext">-Tag ein. Das Bild muss anschließend über assets.json ins Build übergeben werden (→ Tab Assets).

⚠️ Wichtig

Visuell und HTML sind live synchronisiert. Änderungen in einem Tab werden sofort in den anderen übernommen. Arbeite nicht gleichzeitig in beiden.

3 SEO-Editor

Die SEO-Felder befinden sich im Meta-Bereich links oben, die Vorschau im SEO-Tab.

FeldEmpfehlungHinweis
title Interner Arbeitstitel, kann länger sein Wird nicht direkt im <title>-Tag verwendet
seo_title 50–60 Zeichen — erscheint im Browser-Tab und Google Zähler im SEO-Tab zeigt grün/gelb/rot
meta_description 140–160 Zeichen — der Teaser in der Suchergebnisliste Wichtigstes Klick-Element nach dem Titel
slug Pfad ohne Domain, z. B. /wissenshub/agile/scrum-basics/ Immer mit führendem und abschließendem /
image_featured Vollständige URL oder lokaler /assets/HASH.jpg-Pfad Wird als OG-Image genutzt (Social Sharing)
ℹ️ Zeichenzähler

Der SEO-Tab zeigt Farb-Indikatoren: grün = optimaler Bereich, gelb = grenzwertig, rot = zu kurz oder zu lang. Ziel: beide Felder dauerhaft grün.

4 Linter

Der Linter ist im HTML-Tab sichtbar und läuft automatisch bei jeder Änderung im Code-Editor. Er meldet Probleme in drei Schweregrade:

Fehler (rot)
🔴

Ungültige HTML-Struktur – z. B. nicht geschlossene Tags, verschachtelte Fehler. Muss vor dem Export behoben werden.

Warnung (gelb)
🟡

Potenzielle Probleme – z. B. <img> ohne alt-Attribut, leere Absätze. Sollte behoben werden.

OK (grün)
🟢

Keine Probleme gefunden. Bereit für Export.

💡 Praxis

Nach dem Einfügen von HTML aus externen Quellen (CMS-Kopien, Word-Export) immer Linter prüfen. Häufigster Fehler: fehlende alt-Attribute bei Bildern und doppelt geöffnete Block-Elemente.

5 FAQ bearbeiten & hinzufügen

Der FAQ-Tab ist nur beim Template blog aktiv. FAQs werden als strukturiertes Array gespeichert — nicht als reiner HTML-Block — damit Google sie als FAQ-Rich-Result erkennt.

  1. Neue Frage hinzufügen: Button „+ Frage hinzufügen" klicken. Ein neues Eingabepaar (Frage / Antwort) erscheint am Ende der Liste.
  2. Frage & Antwort in Klartext eingeben — kein HTML, keine Sonderzeichen. Der Editor generiert das HTML und JSON-LD automatisch.
  3. Reihenfolge ändern: Die ↑ / ↓ -Buttons neben jedem FAQ-Paar verschieben den Eintrag in der Liste. Die Reihenfolge im Export entspricht der Anzeigereihenfolge auf der Seite.
  4. Eintrag löschen: Rotes „✕"-Symbol neben dem Paar.
  5. Legacy-Import: Falls altes FAQ-HTML (mit <h3>-Fragen und <p>-Antworten) vorhanden ist, in das „Legacy-HTML"-Textfeld einfügen und „Aus Legacy-HTML importieren" klicken. Der Parser extrahiert die Paare automatisch.
  6. Optional: „FAQ-HTML in content_faq generieren" schreibt den fertigen HTML-Block als Fallback – nützlich zur Kontrolle, nicht für den normalen Workflow.
ℹ️ Schema.org

Beim JSON-Export werden FAQs als faq: [{q, a}] gespeichert. Der Build erzeugt daraus automatisch einen <script type="application/ld+json">-Block mit FAQPage-Schema — keine manuelle Pflege nötig.

6 Artikel speichern & exportieren

Der Editor speichert nicht automatisch in eine Datei — alles läuft im Browser. Der Export-Workflow hat zwei Schritte:

  1. Alle Felder prüfen (Linter grün, SEO-Felder ausgefüllt, Preview kontrolliert).
  2. Button „JSON exportieren" klicken. Das Textfeld rechts füllt sich mit dem kompletten JSON-Array — der aktuelle Datensatz ersetzt den ursprünglichen Eintrag.
  3. Button „Copy" klicken, um die JSON-Daten in die Zwischenablage zu kopieren.
  4. Die Ziel-Datei (agile.json, leadership.json etc.) im Projektordner öffnen, den vollständigen Inhalt ersetzen und speichern.
  5. Build starten: deno task build (oder generate.bat auf Windows) erzeugt die statischen HTML-Seiten aus den aktualisierten JSONs.
⚠️ Achtung

Beim Export wird immer der vollständige Array ausgegeben — nicht nur der aktive Datensatz. Beim Zurückschreiben in die JSON-Datei daher stets den gesamten Inhalt ersetzen, niemals nur einen Abschnitt herauskopieren.

💡 Bilder (Assets)

Bilder, die per Drag & Drop eingefügt wurden, müssen separat übergeben werden. Im Assets-Tab „assets.json erzeugen" klicken, kopieren und dem Entwickler übergeben — oder direkt unter dist/assets/ ablegen, bevor der Build läuft.

7 Freigabeworkflow

Artikel durchlaufen vor Veröffentlichung einen definierten Prozess. Der Editor spiegelt den Status im Kanban-Board wider:

Entwurf→
Review→
Freigegeben→
Veröffentlicht
  1. Entwurf fertigstellen: Alle Pflichtfelder ausgefüllt, Linter grün, Kanban-Karte auf „In Arbeit" setzen.
  2. Review anfragen: Kanban-Karte in Spalte „Review" verschieben. Kommentar mit kurzer Zusammenfassung der Änderungen hinterlassen.
  3. Freigabe durch Redaktionsleitung: Nach Prüfung wird die Karte auf „Freigegeben" gesetzt. Erst dann darf der JSON-Export in die Produktions-Datei eingespielt werden.
  4. Veröffentlichung: Build ausführen, Deployment anstoßen, Kanban-Karte auf „Veröffentlicht" setzen und Datum im Kommentar notieren.
🗂️

Kanban-Board

Übersicht über alle Content-Aufgaben und deren aktuellen Status

1 Statusworkflow

Das Board ist in fünf Spalten eingeteilt. Jede Karte darf sich immer nur in einer Spalte befinden. Vorwärtsbewegung ist der Normalfall — Rückbewegungen (z. B. von Review zurück auf In Arbeit) sind möglich und müssen im Kommentar begründet werden.

SpalteBedeutungVerantwortlich
Idee Thema ist vorgeschlagen, noch kein Auftrag. Herkunft: Redaktionsplan, spontaner Einfall, SEO-Keyword. Redaktionsleitung
In Arbeit Artikel wird aktiv geschrieben oder überarbeitet. JSON-Datei ist geöffnet, Editor in Benutzung. Zugewiesene Autorin / Autor
Review Inhalt ist fertig, wartet auf Korrekturlesung und Freigabe. Redaktionsleitung / Lektorat
Freigegeben Freigabe erteilt. Bereit für JSON-Export und Build. Redaktionsleitung
Veröffentlicht Artikel ist live. Datum und URL im Kommentar vermerkt. Technik / DevOps
⚠️ Keine stillen Sprünge

Karten nie ohne Kommentar über mehrere Spalten springen. Wer eine Karte bewegt, hinterlässt einen kurzen Kommentar mit Datum und Begründung — besonders bei Rückbewegungen.

2 Beschreibung & Kommentare

Jede Karte hat zwei Textbereiche:

Beschreibung — Das ist der Auftrag. Hier steht: Zielgruppe, Keyword-Fokus, Tonalität, gewünschte Länge, Besonderheiten (z. B. „FAQ ergänzen", „Bestehenden Artikel aktualisieren"). Die Beschreibung wird beim Anlegen der Karte von der Redaktionsleitung gefüllt und sollte danach nicht mehr verändert werden.

Kommentare — Das ist das Log. Jede Statusänderung, Rückfrage, Feedback-Runde oder Entscheidung wird als Kommentar dokumentiert. Format: [Datum] [Name]: Nachricht.

💡 Gute Kommentare

„2025-06-12 · Marie: Linter-Fehler behoben, img-alt ergänzt. Ready for Review."
Schlechte Kommentare: „ok", „fertig", „geändert" — immer mit Kontext!
Das Log ist das Gedächtnis des Teams, besonders wenn Artikel Monate später wieder angepackt werden.

3 Felder & Metadaten

Jede Karte trägt folgende Standardfelder. Sie helfen beim Filtern und Priorisieren:

FeldInhaltPflicht
Titel Arbeitstitel des Artikels (darf vom späteren SEO-Titel abweichen) ✅
Kategorie Agile / Leadership / Projektmanagement / Team / Podcast ✅
Zieldatum Geplantes Veröffentlichungsdatum laut Redaktionsplan ✅
Zugewiesen an Name der verantwortlichen Person ✅
Slug Finaler URL-Pfad — wird beim Anlegen definiert, nicht mehr ändern ✅
Keyword Primäres SEO-Keyword (ein Begriff, kein Satz) empfohlen
Priorität Hoch / Mittel / Niedrig — für die Sortierung innerhalb einer Spalte empfohlen
Links Direkt-Link zur Seite nach Veröffentlichung nach Publish
ℹ️ Slug-Regel

Der Slug wird einmal beim Anlegen der Karte festgelegt und danach nicht mehr verändert — auch nicht wenn der Titel sich ändert. Slug-Änderungen nach Veröffentlichung erfordern eine 301-Redirect-Konfiguration und müssen mit der Technik abgestimmt werden.

📅

Redaktionsplan

Grobe Ausrichtung — kein Gesetz

1 Wie liest man den Redaktionsplan?

Der Redaktionsplan ist eine Übersichtstabelle mit geplanten Themen, Kategorien und Zeitrahmen. Er gibt der Redaktion Orientierung für die nächsten Wochen und Monate — nicht mehr und nicht weniger.

Typische Spalten im Plan:

SpalteBedeutung
KW / Monat Angestrebter Veröffentlichungszeitraum (Kalenderwoche oder Monat)
Thema / Arbeitstitel Vorläufiger Titel — kann sich bis zur Veröffentlichung ändern
Kategorie Inhaltliche Zuordnung (Agile, Leadership usw.)
Format Artikel, Podcast-Zusammenfassung, Checkliste, Gastbeitrag …
Status Grober Stand — Details laufen über das Kanban-Board
Anmerkung Kontext, Ideen, Quellen, Bezug zu Kampagnen oder Produkten
ℹ️ Leseprinzip

Plane immer von links nach rechts: Was ist diese Woche fällig? Was kommt nächste Woche? Alles dahinter ist Ausrichtung, keine Verpflichtung. Der verbindliche Auftrag entsteht erst, wenn eine Kanban-Karte angelegt und einer Person zugewiesen wurde.

2 Reichweite & Grenzen des Plans

Der Redaktionsplan ist bewusst grob gehalten. Er gibt strategische Impulse und verhindert blinde Flecken in der Themenabdeckung — er ist kein Sprint-Backlog und kein Vertrag.

📌 Wichtig zu verstehen

Themen können sich verschieben. Aktuelle Ereignisse, Kundenanfragen oder neue Produkte können Themen vorrücken lassen oder verdrängen. Das ist normal und gewollt — Agilität gilt auch für die Redaktion.

Termine im Plan sind Richtwerte. Verbindliche Deadlines werden ausschließlich im Kanban-Board als Zieldatum gepflegt. Ein Datum im Redaktionsplan ohne Kanban-Karte hat keine Verbindlichkeit.

Was der Plan leistet:

  1. Sicherstellung einer ausgewogenen Kategorienmischung über Wochen und Monate.
  2. Frühzeitige Abstimmung zwischen Redaktion, Produktteam und Vertrieb (z. B. Artikel passend zu einer Kampagne).
  3. Vorplanung von aufwändigen Formaten (Podcasts, Gastartikel, Webinare), die Vorlaufzeit brauchen.
  4. Gemeinsames Verständnis für Themenfelder, die EID HUB in der nächsten Zeit aktiv bespielen will.

Was der Plan nicht leistet: Detailplanung, Zuweisung von Aufgaben, Tracking von Einzelfortschritten — dafür gibt es das Kanban-Board. Nie den Redaktionsplan als Ersatz für eine Kanban-Karte behandeln.

💡 Faustregel

Redaktionsplan = „Was wollen wir insgesamt erzählen?"
Kanban-Board = „Wer macht was bis wann – und wo stehen wir gerade?"

↑