Zwei Nachbesserungen an Post 6: eine Slide mehr und Zeichnungen, die nicht mehr flach aussehen. DIE FUENFTE SLIDE KOMMT VON DER WEBSITE Die App gibt es noch nicht, und die Website sagt das bereits. In components/sections/ChatDemoSection.tsx steht unter der Fahne comingSoon genau dieser Zustand: ein Handy-Mockup, verwischt, und darueber ein Absperrband aus dem Bau -- gedreht um -13 Grad, in accent-yellow F1B729 mit Kanten in 171106, darauf immer wieder Schutzhelm und BALD VERFUEGBAR. Ein Zwischenstand hatte hier einen selbst erfundenen gelben Aufkleber "In Arbeit". Das war eine zweite Bildsprache neben einer vorhandenen. Uebernommen ist jetzt die der Website, samt Winkel, Farben und Wortlaut. Auch der Inhalt des Schirms kommt von dort und nicht aus dem Pitch-Paket: Heizungsprojekt Schulz, "4 Mitglieder · 2 online", die vier Nachrichten aus seedMessages, die Blasenfarben 0D6E6E fuer eigene und FFFFFF mit Rand E9E7E5 fuer fremde, der warme Grund hsl(30 17% 95.5%). Ueberschrift und Fliesstext ebenso: "Der Chat fuer unterwegs wird gerade gebaut." Das Geraet selbst ist eine bewusste Abweichung. Die Website zeichnet nur einen hellen Umriss, border 4px D1D5DB; auf einer Slide, die selbst hell ist, faellt der in sich zusammen und sieht nach Platzhalter aus. Hier steht ein richtiges Geraet: dunkler Korpus, heller Grat, Schirm eingelassen, Insel und Tasten. Die Abweichung betrifft den Rahmen, nicht den Inhalt. Verwischt wird schwaecher als dort -- auf der Website liegt das Handy gross neben Fliesstext und darf unlesbar sein, hier ist es klein, und bei voller Staerke blieb Brei. DIE TIEFE Zwei Anlaeufe waren falsch. Der erste legte graue Flaechen hinter die Elemente: das nimmt den Zeichnungen ihre Durchsichtigkeit und setzt einen Kasten auf den Punktgrund, der dort nicht hingehoert. Wieder raus, die Zeichnungen sind wieder durchsichtig. Der zweite waren bessere Schatten allein. Richtig, aber zu wenig. Die Schatten des Produkts sind in ui/theme.css gestaffelt und nicht einlagig: --shadow-md 0 4px 16px -2px + 0 2px 4px -1px --shadow-lg 0 12px 32px -4px + 0 4px 8px -2px Zwei Lagen, weil eine allein nicht beides kann: die enge dunkle Kante setzt das Element auf die Flaeche, die weite helle hebt es davon ab. In SVG zwei feDropShadow im selben Filter. Vorher stand dort einer mit dy 7. Gebracht hat es der Stapel. post1.html hat ihn als Bildrahmen im CSS, fuer Screenshots; hier ist er in SVG nachgebaut, mit denselben Werten: .sheet-mid rotate(-2.4deg) translate(-2.2%, 3%) scale(.975) .sheet-back rotate( 3.2deg) translate( 3%, 5.5%) scale(.95) Er gibt Tiefe, die ein Schatten allein nicht schafft, und sagt, dass hinter der einen Ansicht weitere liegen. Die hinteren Blaetter sind leer -- Andeutung, keine Kopie. Auf Slide 1 und 2, wo ein Bildschirm zu sehen ist; nicht auf Slide 3, wo ein Ausschnitt einer Unterhaltung steht, und nicht auf Slide 4, die eine Ueberlagerung ist. AUS DER QUELLE NACHGEHOLT Beim gruendlichen Durchgang durch GeneralTeamChatPage.tsx sind drei Dinge aufgefallen, die vorher fehlten oder falsch waren: - Die Datumsmarke "Heute · 30.07.2026" ueber dem ersten Beitrag und die Zeile "Maike Berger schreibt gerade ..." ueber dem Eingabefeld. Beides gibt der Unterhaltung Struktur, ohne eine Flaeche zu behaupten. - Der offene Kanal ist grau hinterlegt mit Rand und shadow-sm, nicht violett. - Die Blase muss so breit sein, wie ihr Anhang es braucht. Vorher richtete sie sich nur nach dem Fliesstext, und "Materialliste pruefen · faellig 31.07.2026" wurde abgeschnitten -- an einer Stelle, an der der Titel die Aussage traegt. ZWEI FALLEN Gedrehte Blaetter ragen aus dem Kasten. Das hinterste steht um 3,2 Grad gedreht und um 3 und 5,5 Prozent verschoben; seine Ecken lagen bis zu 24 px ausserhalb der 92-px-Schutzzone. Der Ueberstand wird jetzt gerechnet: stapelRand() schickt die vier Ecken durch dieselbe Kette wie das Blatt. getBBox() kennt keine Beschneidung. Das Absperrband war erst auf die 175 % der Website gezogen und am Geraet abgeschnitten -- im Bild richtig, in der Messung ein Ueberstand von 146 px, den es nicht gab. Es ist jetzt nur so lang, wie es bei -13 Grad quer ueber das Geraet sein muss. GEPRUEFT Raender 93 / 227 / 110 / 140 / 350, Luft 116 / 79 / 190 / 141 / 77 px, alle Ueberschriften innerhalb der Schutzzone, 214 CSS-Regeln, Konsole ohne Fehler, fuenf PNGs aus dem echten Ausgabeweg bei 2160 x 2700. Downloads blieb leer, der Projektstand unveraendert. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
21 KiB
HiveGrid Social — Design-Library & Post-Generator
Eigenständige Werkbank für HiveGrid-Social-Grafiken. Slides werden im Browser als HTML gebaut, im Canvas bearbeitet und pixelgenau als Instagram-taugliche PNGs exportiert.
Das Repo ist bewusst autark. Keine CDN-Verweise, keine Google-Fonts zur Laufzeit, keine Pfade in andere Repos. Alles, was ein Post braucht — Schrift, Logos, Mockups, Screenshots, Bibliotheken — liegt hier.
Starten
./serve.sh # http://127.0.0.1:4321
Downloads landen direkt in ~/Downloads, ohne Browser-Dialog.
Projekte
| Projekt | Datei | Inhalt | Übergabe |
|---|---|---|---|
| Post 1 · Lösung | post1.html |
Carousel, Anzahl frei | |
| Post 2 · Die Geschichte | post2.html |
Carousel, 6 Slides, erscheint 12.08. | POST-2.md |
| Post 2 · Alternative | post2-alt.html |
Derselbe Beitrag im Theme modern |
|
| Post 3 · Verbinden statt ersetzen | post3.html |
Einzelbild, Theme modern, erscheint 17.08. |
|
| Post 4 · Workflow-Engine | post4.html |
Carousel, 4 Slides, Theme modern, erscheint 19.08. |
POST-4.md |
| Post 5 · Projektmanagement | post5.html |
Carousel, 5 Slides, Theme modern, erscheint 21.08. |
POST-5.md |
| Post 6 · Team-Chat | post6.html |
Carousel, 5 Slides, Theme modern, erscheint 26.08. |
POST-6.md |
Alle Streifen nebeneinander zeigt uebersicht.html, erreichbar über
Projekt → Alle Projekte im Streifen. Die Seite baut die Slides nicht selbst
nach: jedes Projekt kommt als iframe mit ?nur=streifen, und in diesem Modus
blendet die Post-Seite ihre Bedienoberfläche aus, zeigt den Streifen in
natürlicher Größe und speichert nichts — drei Kacheln, die beim Schließen
ihren Stand zurückschreiben, wären genau die Falle aus POST-2.md §6.
Jeder Streifen ist auf die Fensterbreite eingepasst, gescrollt wird nur
hoch und runter — kein Zoom, weder außen noch im Streifen.
Post 2 gibt es zweimal, in zwei Themes. Projekt und Theme sind zwei
verschiedene Dinge: das Projekt sagt, welcher Beitrag, das Theme, wie er
aussieht. notebook ist die Zeichenblock-Optik mit Raster und Marker,
modern der ruhige Grund mit farbigem Akzentwort und schwebenden Karten.
Beide zeigen denselben Beitrag mit denselben Texten.
Die Themes stehen in rules.md §1a mit ihren Unterschieden.
Wer eine Visualisierung ändert, muss an beide Dateien denken.
Post 3 ist ein Einzelbild, keine Slidefolge: eine Haltung, die man
durchwischen muss, ist keine. Sein Bild ist das Wabenfeld der Startseite,
nachgebaut aus HoneycombSection.tsx — dieselbe Achsrechnung, dieselben
Zellnummern, dieselbe Belegung, damit es wiedererkennbar bleibt und keine
Anmutung davon ist. Die vier Waben „In Arbeit" fehlen: auf der Startseite sind
sie ein Versprechen, im Beitrag wären sie ein Eingeständnis.
Post 4 zeigt einen einzigen echten Ablauf, nicht sechs Behauptungen über
Automatisierung: den Vorgang aus assets/screens/workflow.png. Die Bausteine
sind nachgebaut aus NodeWorkflowEngine und WorkflowEngineClickDummy des
Pitch-Pakets, in Markenfarben statt in den UI-Farben des Produkts — Teal trägt
die Arbeit, Gelb den einen Akzent, Anthrazit die Entscheidung.
Vier Slides. Der Redaktionsplan nennt fünf bis sieben, aber das ist eine Spanne und kein Soll: eine Slide, die nichts hinzufügt, kostet einen Wisch und gibt nichts zurück.
| Slide | Was sie leistet | Ansicht | Quelle der Texte |
|---|---|---|---|
| 1 | was es ist | ein Ablauf auf dem Canvas | Knoten aus assets/screens/workflow.png, Notiz aus WORKFLOW_PRESETS, Anordnung eigen |
| 2 | was ihn startet | Auslöser-Auswahl | assets/screens/workflow-bausteine.png |
| 3 | was dann passiert | Aktionen-Auswahl | NodeWorkflowEngine, Rubriken des Katalog |
| 4 | dass man nicht bei null anfängt | drei Vorlagen | GENERAL_WORKFLOW_PRESETS |
Slide 2 und 3 sind eine Funktion mit zwei Rubriken, weil es im Produkt eine Auswahl ist: „Auslöser" und „Aktionen" stehen dort untereinander im selben Feld. Getrennt gezeichnet wären es zwei Bilder, die zufällig gleich aussehen. Die Kachelfarbe kommt dabei aus der Kategorie, nicht aus dem Knotentyp — im Screenshot tragen alle Auslöser eine gelbe Kachel und die Aktion eine blaue, samt Punkt vor der Rubrik. Auf dem Canvas ist es anders, dort färbt die Wurzelkomponente je Art. Beides stimmt, es sind zwei Ansichten.
Das Farbsystem stammt aus der Wurzelkomponente und ist keine Dekoration: grün fängt an, rot ändert Daten, blau meldet, amber macht eine Aufgabe daraus, violett entscheidet, grau ist ein Fremdsystem. Deshalb sind auf Slide 3 alle Kacheln grün — jede Vorlage startet mit einem Auslöser.
Die Kartenform auf Slide 3 ist nicht aus dem Projekt. Im Werkzeug werden Vorlagen nur geladen, nicht als Galerie gezeigt; es gibt dort keine Ansicht, an die man sich halten könnte. Wörtlich sind die Namen, Beschreibungen und Startbausteine, gebaut ist die Form. Der Unterschied gehört benannt.
Text mittig, Titel ohne Fließtext. Die Visualisierungen sitzen 896 px breit
bei x 92, also links wie rechts 92 px Rand — ein linksbündiger Textblock
darüber steht sichtbar aus der Achse. Die Titel-Slide trägt nur die
Überschrift: der Ablauf darunter sagt, was gemeint ist, und ein Fließtext
wiederholte es in Prosa. Dafür fiel hier dieselbe Korrektur an wie in
post3.html — ein leerer Fließtext darf keinen leeren Absatz erzeugen, sonst
schiebt sein Zeilenabstand die Zeichnung nach unten.
Die Gabel auf Slide 1 kommt früher als im Screenshot, und ein Schritt fehlt. Alle drei echten Abläufe verzweigen erst an Position 3 oder 4 — das füllt ein hochkantes Format schlecht, weil über und unter dem Stamm nichts steht, solange er läuft. Hier gabelt es nach dem zweiten Knoten, und zwischen „Formular eingegangen" und „Passender Lead?" fehlt dadurch „Daten vereinheitlichen". Alle sechs Knoten heißen wörtlich wie in
workflow.pngund tragen dessen Farben, aber diese eine Kante ist zusammengezogen: ein Ablauf, den es genau so gibt, ist es nicht mehr — einer, den es geben könnte, schon. Die Anordnung ist ohnehin eigen, im Werkzeug zieht man Knoten mit der Maus.
Kein PDS im Beitrag. Von den sechs Vorlagen nennen drei das
Branchenprogramm — zwei im Namen, eine in der Beschreibung. Der Beitrag
richtet sich an Betriebe allgemein, nicht an die, die zufällig dieses eine
Programm fahren. Übrig bleibt genau die Gruppe GENERAL_WORKFLOW_PRESETS, in
der das Wort kein einziges Mal vorkommt — also keine Auswahl nach Geschmack,
sondern die vollständige zweite Gruppe. Gekürzt wurde nichts: aus „Offene
Angebote aus PDS erkennen" ein „Offene Angebote erkennen" zu machen wäre die
bequeme Lösung und kein Zitat mehr. Lieber eine Karte weniger.
Alle Produkttexte auf den Slides sind wortgleich aus der Quelle, Titel wie Beschreibungen. Wo ein Name nicht in eine Zeile passte, steht er zweizeilig — gekürzt wird nicht, denn aus „Daten vereinheitlichen" ein „Prüfen" zu machen ist keine Kürzung, sondern ein anderer Name.
Der Knoten ist die echte Komponente. NodeItem aus
NodeWorkflowEngine.tsx des Pitch-Pakets: quadratisch 128 × 128, rounded-lg,
6 px Rand, Titel und Beschreibung unter dem Feld, beim Auslöser die linke
Flanke voll gerundet. Genau so rendert es auch assets/screens/workflow.png.
Ein Zwischenstand zeichnete stattdessen breite Karten mit farbiger Kante links
und einem Block „BESCHREIBUNG" — abgemalt vom Pitch-Bild 02_Präsentation/03.
Im Code des Projekts gibt es das nirgends, und der Kommentar behauptete
trotzdem, es sei ein Nachbau der Komponente.
Die Farben sind die des Produkts, nicht die der Marke. Aufgelöst aus
ui/theme.css über die ganze Token-Kette (surface-ui-subtle-green-default
→ --color-ui-green-100 → --color-green-100), nicht aus dem Bild geschätzt:
| Rolle | Fläche | Zeichen |
|---|---|---|
| Auslöser | #DCFCE4 |
#148134 |
| Daten | #FEE2E2 |
#C52020 |
| Entscheidung | #F0E7FF |
#691CD4 |
| Meldung | #D5EFFF |
#003BEB |
| Abschluss | #FCF6C5 |
#9B5E0D |
Ein Zwischenstand hatte sie durch Markenfarben ersetzt, weil rules.md §2 diese
Töne nicht kennt. Das ist zurückgenommen: der Beitrag zeigt die Oberfläche, und
ihre Farbe trägt Bedeutung — grün fängt an, rot arbeitet an Daten, violett
entscheidet, blau meldet, gelb schließt ab. Umgefärbt wäre es eine
Nacherzählung. Der Rand ist border-default #E5E5E5, also der Wert, vor dem
rules.md §5 warnt; hier trägt er, weil die Felder farbig gefüllt sind.
Der Notizzettel auf Slide 1 ist StickyNote.tsx aus dem Pitch-Paket
(rounded-md, Kopfleiste h-8, Text #424242, sechs Farbpaare) mit dem
grünen Zettel aus dem Preset form-to-pds, Text unverändert. Zettel sind das,
was einen Ablauf im Werkzeug von einem Diagramm unterscheidet.
Was hier bewusst nicht steht: ein erfundener Vorgang. Ein Zwischenstand hatte eine Slide mit einem Aktivitätenverlauf samt Uhrzeiten. Nichts davon war gemessen. Bei einem Produkt vor dem Start ist eine erfundene Uhrzeit keine Veranschaulichung, sondern ein Beleg, den es nicht gibt.
Slide 1 trägt einen Ablauf, kein Stichwort. Im Profilraster ist sie eine Kachel von rund 150 px, auf 3:4 beschnitten — dort ist kein Wort lesbar. Was ankommt, ist die Form: eine Kette, die sich gabelt.
Was über die 1080 px einer Seite hinausragt, landet auf der Nachbarslide — das
durchgehende Blatt aus rules.md §5 liegt in jeder Slide. Ein Prüfskript misst
das nach; alle sechs Zeichnungen bleiben auf der Sicherheitszone.
Sein Grund ist gepunktet statt leer: die Arbeitsfläche des Workflow-Editors,
mit den Werten aus WorkflowEditor.tsx der Website. Der Punktgrund steht als
dritte Stellung unter Versuch → Punkte und ist die Voreinstellung dieses
Projekts. Warum das Theme modern hier von seinem ruhigen Grund abweicht, steht
im CSS bei .layer-raster.
Post 5 zeigt die Pipeline von vier Seiten. Das Demo-Projekt hat dafür vier
Bildschirme — Schablone, Board, Liste, Detail — und jeder bekommt eine Slide,
dazu die Karte aus der Nähe. Anders als bei Post 4 wird nichts umgefärbt:
eine Pipeline lebt davon, dass man das Gewerk an der Farbe erkennt, ohne zu
lesen, und dass der Fuß einer Karte sich mit ihrer Priorität färbt. Die
Zuordnung Gewerk zu Ton ist CATEGORY_TONES, die Plättchenfarben sind
ui/theme.css.
| Slide | Screen | Was sie leistet |
|---|---|---|
| 1 | 4A | das Board selbst, drei Phasen mit Anzahl, Summe und Karten |
| 2 | 4A | eine Karte groß |
| 3 | 4B | „Vom Verkauf in die Abwicklung": dasselbe Projekt in Auftragsabwicklung SHK, mit dem Knopf für den Pipelinewechsel |
| 4 | 4C | dieselben Projekte als Tabelle |
| 5 | 3 | der Feldeditor, offen auf „Aufmaß erledigt" |
Es sind zwei Pipelines, nicht eine. Das Board gehört zu
Vertrieb: Anlagen-Verkauf, das Projekt in der Detailansicht liegt in
Auftragsabwicklung SHK, und ein Knopf schiebt es von der einen in die andere.
Das ist der Unterschied zwischen Vertriebs- und Abwicklungs-Projektmanagement,
und Slide 3 ist deshalb die Pointe des Beitrags. Möglich ist beides in einer
Software, weil die Felder an der Pipeline hängen und nicht am Programm — das
zeigt Slide 5.
Alle Zahlen sind gerechnet, keine ist gesetzt. Anzahl und Summe je Spalte kommen aus denselben Datensätzen wie die Karten.
Die Karte ist aus dem Code nachgebaut, nicht aus dem Screenshot. Der erste
Anlauf war von assets/screens/pipelines.png abgemalt und lag an drei Stellen
daneben, die im Bild nicht zu erkennen waren. Der Rest steht in
POST-5.md §7.
Eine Richtigstellung. Ein früherer Stand behauptete hier, die Detailansicht sei nur ein Entwurfs-PNG. Falsch: geprüft worden waren die Beschriftungen des Bildes
07_Screen-4b_Karten-Detail.png, und die kommen im Code wirklich nicht vor — den Bildschirm gibt es trotzdem, unterapp/(screens)/4b/, nur anders beschriftet. Die Abwesenheit einer Zeichenkette beweist die Abwesenheit eines Bildschirms nicht.
Post 6 zeigt den Team-Chat, nachgebaut aus GeneralTeamChatPage des
Pitch-Pakets. Anders als die Pipeline mit ihren vier eigenen Bildschirmen gibt
es vom Chat nur eine Fassung, unter /allgemein/team-chat. Die Inhalte darin
sind trotzdem aus dem Gewerk: Wärmepumpe Müller, Montagetermin,
Baustellenfotos.
| Slide | Was sie leistet |
|---|---|
| 1 | Kanalliste und Verlauf nebeneinander, mit Filterzeile und Eingabefeld |
| 2 | die Chatliste groß: Projektkanäle, Direktnachrichten, Gruppe |
| 3 | Fotos, die Aufgabe daraus, die Bestätigung im Projekt |
| 4 | das Menü hinter dem Plus im Eingabefeld |
| 5 | das Handy-Mockup der Website, verwischt, mit Absperrband |
Slide 3 ist der Kern, und sie ist keine Konstruktion: im Werkzeug folgen die drei Nachrichten genau so aufeinander. Tobias schickt die Baustellenfotos, darauf eine Nachricht mit angehängter Aufgabe, darauf die Systemzeile „Aufgabe „Materialliste prüfen" im Projekt erstellt". Die letzte Zeile macht den Unterschied: die Aufgabe liegt danach im Projekt, nicht nur im Verlauf.
Slide 5 kommt von der Website, nicht aus dem Pitch-Paket. Die App gibt es
noch nicht, und ChatDemoSection.tsx hat den Zustand bereits: ein Handy-Mockup
mit blur(3px) und darüber ein Absperrband aus dem Bau, -13° gedreht, in
#F1B729 mit Kanten in #171106, darauf Schutzhelm und „BALD VERFÜGBAR".
Auch Inhalt, Blasenfarben, Überschrift und Fließtext sind die der Website. Ein
Zwischenstand hatte hier einen selbst erfundenen Aufkleber; das war eine eigene
Bildsprache neben einer vorhandenen.
Die Tiefe kommt aus dem Stapel und gestaffelten Schatten, nicht aus
Flächen. Ein Zwischenstand legte graue Flächen hinter die Elemente; das nimmt
den Zeichnungen ihre Durchsichtigkeit und setzt einen Kasten auf den
Punktgrund. Stattdessen zweierlei: die echten Schatten aus ui/theme.css, die
dort gestaffelt sind (enge dunkle Kante plus weite helle, in SVG zwei
feDropShadow im selben Filter), und der Stapel aus post1.html, in SVG
nachgebaut mit denselben Winkeln, die dort im CSS stehen. Die hinteren Blätter
sind leer: Andeutung, keine Kopie. Auf Slide 1 und 2, wo ein Bildschirm zu
sehen ist; nicht auf Slide 3, wo ein Ausschnitt einer Unterhaltung steht.
Dazu die Datumsmarke und die Zeile „Maike Berger schreibt gerade …" aus der Quelle, die der Unterhaltung Struktur geben, ohne eine Fläche zu behaupten.
Die Bildergalerie ist eine Anhangkarte, kein Bild. Im Werkzeug lädt
GalleryPreview zwei Fotos von Unsplash. Fremde Fotos in einen Beitrag zu
setzen, der von der eigenen Baustelle spricht, wäre eine Behauptung über
Material, das wir nicht haben.
Die vierzehn Partner-Marken liegen unter assets/partner/ und sind, wie alles
andere hier, aus der Website gespiegelt statt verlinkt. Sechs davon sind
PNG und damit dieselbe Wette wie ein Screenshot (§7 in rules.md), deshalb
prüft der Export sie einzeln nach — wabenZonen() in post3.html.
Der Redaktionsplan für alle weiteren Beiträge liegt in
redaktionsplan/, gebaut mit python3 redaktionsplan/bauen.py.
Slides anlegen und wegnehmen
Wie viele Slides ein Post hat, steht nicht fest. Unter der Slide-Auswahl:
| Knopf | Wirkung |
|---|---|
+ Neu |
leere Slide dahinter einfügen |
Kopie |
die gewählte Slide samt Text, Bild und Verschiebungen verdoppeln |
Löschen |
die gewählte Slide wegnehmen (die letzte bleibt stehen) |
← → |
eine Position nach vorn oder hinten |
Bei einer einzigen Slide ist der Post ein Einzelbild — die Kopfzeile sagt es, und der ZIP-Knopf verschwindet.
Unter Inhalt (nur diese Slide) stehen Tag, Überschrift, Fließtext und die
Auswahl des Screenshots. Getippt wird Text, keine Auszeichnung: *Wort* setzt
den Akzent, ein Zeilenumbruch bricht die Zeile um. Das Rahmenformat folgt beim
Wechsel automatisch dem Seitenverhältnis der gewählten Aufnahme.
Die Tags sind gestalterisch ausgeblendet (
visibility: hiddenauf.badge). Der eingetippte Tag beschriftet deshalb vorerst nur den Slide-Knopf im Bedienfeld.
Eigene Bilder importieren
Unter Eigene Bilder wählst du Dateien aus dem Finder, oder du ziehst sie direkt auf eine Slide. Beim Ablegen wird das Bild dort zum zweiten Bild und lässt sich im Bearbeiten-Modus frei schieben und in der Größe ändern; über den Knopf importierst du nur und ordnest danach unter Inhalt zu.
Die Datei geht byteweise unverändert an den Server und liegt danach unter
assets/eigene/. Nichts wird neu kodiert, skaliert oder umbenannt — nur
Zeichen, die in einem Dateinamen nichts zu suchen haben, weichen einem
Bindestrich.
assets/eigene/ importierte Bilder, gehören mit in den Commit
Der Umweg über den Server ist Absicht. Ein Foto als Base64 im Projektstand wäre größer als der gesamte übrige Stand und machte jeden Diff unlesbar. So steht dort nur der Pfad.
Die Auswahllisten unter Inhalt holt der Generator beim Start vom Server
(/bilder), importierte Bilder stehen deshalb sofort darin — mit ★
gekennzeichnet.
Mitgelieferte Slides bleiben Vorlagen. Der Stand speichert für sie nur einen Verweis und die Felder, die du überschrieben hast — eine Änderung an der Vorlage im Code kommt dadurch weiterhin bei allen an, die sie nicht angefasst haben. Selbst angelegte Slides stehen vollständig im Stand.
Das Projekt speichert seinen Stand — Einstellungen, Layouts, Muster und alle Verschiebungen aus dem Canvas überleben einen Reload. „Projekt zurücksetzen" wirft ihn weg.
Der Stand liegt im Repo
Nicht nur im Browser: jede Änderung landet auch in state/<projekt>.json.
Diese Dateien gehören mit in den Commit. Nur so hat die andere Maschine
nach git pull denselben Stand.
state/post1.json Post 1 · Lösung
state/post1-merk.json Rückfallpunkt
Beim Laden gewinnt die Datei, der localStorage ist nur der Rückfall, wenn der Server nicht läuft. Wer den Stand ändert, muss also committen und pushen — sonst sieht ihn niemand sonst. Gibt es die Datei noch nicht, wird der Stand aus dem Browser einmalig hineingeschrieben.
Bedienung
| Taste | Wirkung |
|---|---|
← → |
Slide wechseln (im Bearbeiten-Modus: Element verschieben) |
E |
Bearbeiten an/aus |
W |
Streifen ⇄ Einzelansicht |
V |
Variante hell/dunkel |
L M I |
Layout · Muster · Intensität |
C G T |
Durchgehend · Tag-Ausrückung · Perspektive |
D A |
Slide laden · alle als ZIP |
Im Bearbeiten-Modus lassen sich Elemente ziehen und mit den Pfeiltasten
pixelweise schieben (⇧ = 10 px).
Ein angeklicktes Element öffnet sein eigenes Feld rechts. Damit ist die Oberfläche geteilt: links die Slide und alles Allgemeine, rechts das eine Element.
| Im Element-Feld | Wirkung |
|---|---|
Text |
Beschriftung des Elements, *Wort* setzt den Akzent |
Schrift / Breite, A− A+ |
Größe |
X Y |
Stelle auf der Slide, gezählt ab der Mitte, bezogen auf die obere linke Ecke |
Ebene |
wie z-index — höher liegt weiter vorn. Leer heißt Standard |
Links Mitte Rechts, Oben Mitte Unten |
an der Slide ausrichten, 92 px Rand |
Position / Größe angleichen |
denselben Wert auf allen Slides |
Löschen |
nimmt es aus der Slide. Es taucht darunter als „… zurück" wieder auf |
Der Streifen ist eine durchgehende Fläche. Jede Slide trägt das gesamte Blatt, ein Element lässt sich also über den ganzen Post schieben und nicht nur in die Nachbar-Slide.
Auf der Fläche bewegen
| Maus | Wirkung |
|---|---|
| Ziehen | Ausschnitt schieben |
| Rad | Zoomen, auf den Zeiger zu |
⇧ + Rad |
Waagerecht schieben |
| Leertaste-Ziehen, mittlere Taste | Schieben, auch im Bearbeiten-Modus |
Ein gewöhnliches Mausrad genügt, ohne Zusatztaste. Im Bearbeiten-Modus zieht
die linke Taste das Element unter dem Zeiger — die Fläche schiebt man dort mit
gedrückter Leertaste oder der mittleren Taste. Fit unten rechts setzt den
Maßstab zurück.
Aufbau
assets/
├── brand/ Wortmarke hell/dunkel, G-Marke (SVG + PNG), Wabe, Geerkens
├── partner/ die 14 Marken des Wabenfelds (DATEV, KWP, pds, Bauhow, Aircall,
│ Onepage, PandaDoc, Hallo Petra, Claude, OpenAI, Google Drive,
│ Google Calendar, MS Outlook, MS Teams)
├── mockups/ Geräte-Mockups (Displays ausgeknockt, Screenshot liegt dahinter)
├── screens/ Software-Screenshots
├── eigene/ selbst importierte Bilder
└── fonts/ Manrope 400–800, lokal
vendor/ html-to-image, JSZip
state/ Projektstände, gehören ins Repo
serve.py Statischer Server + /save, /state, /upload, /bilder
rules.md Gestaltungsregeln, Farbwerte, Export-Wissen
Regeln
rules.md ist die Arbeitsgrundlage. Farbwerte, Geometrie, Typografie,
Layout-Template, Instagram-Export und die Liste der Fallen, in die wir schon
getappt sind. Vor jeder Änderung an der Gestaltung dort nachsehen.
Marken-Werte stammen aus der Website (HiveGrid-Website) und sind hier
gespiegelt, nicht verlinkt. Ändert sich dort etwas, muss es hier
nachgezogen werden.