How I started to build
custom visuals

• IBCS als Anspruch: Szenario-Notation (AC solide, PY grau, PL Umriss, FC schraffiert), Varianz-Panels, gleiche Skalen — das können die Core-Visuals nicht.
• Lizenzrechnung: Zebra BI & Co. sind stark, aber Kosten skalieren pro Empfänger und Jahr.
• Ownership: Ein eigenes Visual gehört dem Unternehmen — Funktionen exakt für den eigenen Abschluss-Workflow.
• Aber: „Wir bauen ein Custom Visual" war nicht der erste Schritt. Genau darum geht diese Session.

Dieses Gantt ist selbst ein Power-BI-Visual: die MIT-lizenzierte Vega-Spec aus dem PMO Toolkit (Devon Locher, nach David Bacci), gerendert über Deneb — adoptiert statt selbst gebaut.

• Eine HTML-Datei, ein SVG, keine Toolchain. Waterfall und IBCS-Chart zuerst als Standalone-Prototypen — F12 ist der Debugger, F5 der Build.
• Fachlogik ohne SDK-Reibung klären: Wie berechnet sich die Brücke? Wo sitzen Labels bei negativen Werten? Wie verhält sich die Skala?
• Der Prototyp wird zur Spezifikation: Später wurde die HTML-Logik fast 1:1 nach TypeScript portiert.
• Nebeneffekt: Stakeholder können den Prototyp anklicken, bevor eine Zeile Visual-Code existiert.

Säulen mit AC/PY/PL/FC, darüber ΔPL-Balken und ΔPL-%-Nadeln — Referenzachse in Plan-Notation (Doppellinie), Kommentar-Marker mit Fußnoten.

• Deneb = zertifiziertes Custom Visual, in dem Charts als Vega-Lite-JSON leben — kein eigener Build, kein eigenes Deployment.
• Templates mit Platzhaltern (__0__, __1__, …) machen Specs wiederverwendbar — daraus wurde ein eigener Chart-Builder im Browser.
• Stärken: Säulen-/Balken-Varianten, Wasserfälle, KPI-Kacheln — schnell gebaut, leicht zu teilen.
• Eigenheiten: named dataset, pbiContainer-Signale, Quoting — Deneb ist Power-BI-Vega, nicht Browser-Vega.

• Anforderung: Projektplan mit einklappbaren Phasen, Pan/Zoom, Abhängigkeitspfeilen, Meilensteinen.
• Vega-Lite kann das nicht — klickbares Collapse braucht Signals, Event-Streams, berechnete Layouts: Raw Vega.
• Entscheidung: adoptieren statt bauen. Die MIT-lizenzierte Gantt-Spec aus dem PMO Toolkit übernommen, Attribution behalten, Eigenheiten gelernt.
• Lektion: Erst schauen, was die Community unter freier Lizenz gelöst hat — und an der Grenze von deklarativ zu imperativ beginnt das eigene Visual.

• Setup: pbiviz new → TypeScript + capabilities.json (Datenrollen, Objekte) + FormattingModel für den Formatbereich.
• Rendern: ein SVG, von Hand aufgebaut — die Logik kam fertig aus den HTML-Prototypen.
• Paketieren: npx pbiviz package → eine .pbiviz-Datei, Import in Desktop oder zentral im Organizational Store.
• Ease-of-use-Prinzip: Neue Features entweder als Dropdown-Modus oder feld-gesteuert (Feld leer = nichts ändert sich).

• Problem: Der Visual-Sandbox-Zyklus (paketieren → importieren → klicken) ist zäh zum Testen.
• Lösung: esbuild bündelt das Visual mit einem API-Shim, eine Test-HTML mockt den Host — 40+ Szenarien rendern in headless Chromium, ein Befehl, ein Screenshot-Tapetenwerk.
• Interaktion echt testen: Zoom, Aufklappen, Buttons mit echten Maus-Klicks auf Koordinaten — synthetische Events haben uns einmal belogen.
• Jedes Feature = ein Testfall. Regressionen fallen als Pixel auf, nicht als Support-Ticket.

GuV-Wasserfall mit ΔPY-Stufen (IBCS Chart-Template 12): Die offiziellen IBCS-Templates dienten als Ziel-Katalog — Abgleich, Lücke finden, Lücke bauen.

Wasserfall-Brücken als Small Multiples, nach Wirkung sortiert — die IBCS-Regel „gleiche Skalen" ist im Code erzwungen, nicht per Konvention erhofft.

PL/PY-Summen, Ist-Vergleich, Kaskade, Δ%-Nadeln, doppelte Überleitung — und oben rechts: ΔPY|ΔPL-Umschalter, die per persistProperties im Bericht gespeichert werden.

Wesentlichkeits-Schwellen (unwesentliche Δ grau), YTD-Button, und Kommentar-Erfassung per Klick — gespeichert in der Berichtsdatei, nicht in einer Excel-Nebenbuchhaltung.

• Z-Order frisst Klicks: Interaktive Flächen nach dem Chart-Inhalt zeichnen — sonst schlucken Marks die Events.
• Host-Styles nie überschreiben: style.cssText = … auf dem Host-Element hat uns ein Layout zerlegt. Nur additiv stylen.
• Format-Strings multiplizieren: „0.0 %" heißt in Power BI ×100 — Testdaten entsprechend bauen.
• Ein Feature, eine Version, ein Testfall — und alte Pakete löschen, sonst importiert garantiert jemand das falsche.
• Erst adoptieren, dann bauen: MIT-Specs wie der PMO-Gantt sind Abkürzungen mit Attribution.
• Format-Pane kontextsensitiv halten: Optionen nur zeigen, wenn das passende Feld gefüllt ist — sonst erschlägt der Formatbereich.

• Organizational Store: zentral geprüft, eine Version für alle, zentral abschaltbar — Microsofts empfohlener Weg für interne Visuals.
• Tenant-Settings: Wer darf .pbiviz importieren? Gilt „nur zertifizierte"? Desktop braucht zusätzlich Gruppenrichtlinien.
• Vertrauen belegen: Eigenentwicklung = Code-Review möglich; keine externen Calls, kein Datenabfluss — per Review beweisbar.
• Lizenz klären: unser Deck: MIT mit Autor-Nennung — Nutzung frei, Attribution bleibt.