1. Aufbau und Zuständigkeiten

Die Trennung ist bewusst einfach: dbxContent liefert den Inhalt, die Module liefern ihre Funktionen und das ausgewählte Design bildet die äußere Schale. Ein Design darf deshalb Layout, Farben, Typografie, Abstände, Branding, Logo, Menüform, Hintergrund und Footer ändern. Es darf nicht die Berechtigungsprüfung oder die Datenverarbeitung eines Moduls ersetzen.

Designpaket

Jedes Design liegt eigenständig unter dbx/design/<designname>/. Wesentliche Bestandteile sind:

dbx/design/mein-design/
├── design.json          Metadaten, Layout und verfügbare Skins
├── htm/default.htm      Hauptschale mit genau einem [dbx:content]
├── htm/logo.htm         optionaler Logo-Baustein
├── htm/branding.htm     optionaler Branding-Baustein
├── htm/footer.htm       optionaler Footer-Baustein
├── css/                 design-eigene Stylesheets
└── img/                 design-eigene Bilder und Texturen

Die Design-Slots [dbx:logo], [dbx:branding] und [dbx:footer] halten erzeugte Schalen übersichtlich. Der Inhalts-Slot [dbx:content] muss genau einmal vorhanden bleiben. Assets eines Designs sollen nicht heimlich auf private Dateien eines anderen Designs verweisen.

Design und Skin

Das Design bestimmt Struktur und Grundstil. Ein Skin ist eine Farbvariante innerhalb dieses Designs. In der Designauswahl werden die Skins deshalb unter ihrem jeweiligen Design gruppiert. Ein neues Design sollte nur die tatsächlich unterstützten Skins in design.json veröffentlichen.

2. Die drei vorhandenen Designs als Beispiele

dbXapp: klassische horizontale Anwendungsschale

Lernpunkt: Eine klare Grundstruktur kann über Skins farblich variiert werden, ohne Menüs, Module oder Inhalte umzubauen.

Flowers: eigenständiges Branding mit Seitenmenü

Lernpunkt: Ein Design darf die Seitenaufteilung deutlich verändern. Entscheidend ist, dass die vorhandenen dbxMenu-Ausgaben, Systemaktionen und Inhaltsbereiche erhalten bleiben.

STEAL: Materialstil bei vertrauter Bedienung

Lernpunkt: Nicht jedes neue Erscheinungsbild benötigt eine neue Seitenarchitektur. Häufig ist ein sauber begrenztes Design-Update sicherer und schneller.

3. Design manuell mit dbxDesign_admin erstellen

Der manuelle Standardweg führt über das Design Studio. Der dortige Wizard erzeugt ein vollständiges, eigenständiges und geprüftes Designpaket. Das Ausgangsdesign bleibt unangetastet.

Schritt 1: Ausgangsdesign wählen

1. Im Hauptmenü System → Design Studio öffnen.
2. Bei einem passenden Design Personalisieren wählen oder den allgemeinen Design-Wizard starten.
3. Das Ausgangsdesign nach der benötigten Struktur auswählen: dbXapp für ein oberes Menü, Flowers als Beispiel für eine Seitenleiste oder STEAL für eine materialbetonte horizontale Schale.

Schritt 2: Identität festlegen

• Technischer Name: kurz, eindeutig und dauerhaft, zum Beispiel meine-firma. Daraus entsteht der Designordner.
• Design-Titel: verständliche Bezeichnung für die Auswahl.
• Beschreibung: Zweck, Zielgruppe und Stil knapp dokumentieren.

Schritt 3: Seitenaufteilung und Menü

Der Wizard bietet drei Grundlayouts:

• Menü oben: geeignet für Verwaltungsoberflächen und breite Arbeitsbereiche.
• Menü links: geeignet für Markenauftritte, viele Hauptpunkte und eine ruhige Inhaltsachse.
• Hybrid: Branding oben und Navigation links.

Danach Menüform, Inhaltsbreite und Footer wählen. „Kompakt“ ist sinnvoll bei vielen Einträgen, „Tabs“ wirkt technisch und klar, „Pills“ freundlicher und weicher. Die Vorschau zeigt die grundsätzliche Aufteilung, ersetzt aber nicht den späteren Test mit echten Untermenüs.

Schritt 4: Branding, Logo und Farben

1. Markenname und Claim eintragen.
2. Bootstrap-Icon oder eigenes Logo wählen. Für Logos PNG, JPG, WEBP oder GIF bis 5 MB verwenden.
3. Primär-, Sekundär- und Akzentfarbe definieren.
4. Hintergrund-, Flächen- und Textfarbe so wählen, dass Texte und Bedienelemente ausreichend Kontrast besitzen.
5. Typografie und Ecken passend zum Markencharakter festlegen.

Schritt 5: Footer und Standarddesign

Der vollständige Footer enthält Text, Rechtelinks und Fensterleiste. „Minimal“ reduziert die Informationen, „Nur Fensterleiste“ erhält ausschließlich die für dbxapp-Fenster nötige Leiste. Das neue Design nur dann sofort als Frontend-Standard setzen, wenn die Vorschau bereits geprüft wurde.

Schritt 6: Erzeugen und kontrollieren

Nach dem Absenden erstellt dbxDesign_admin das Paket im Staging, prüft Pflichtdateien, Pfade, Inhalts-Slot und Metadaten und veröffentlicht es erst danach. Anschließend das Design über Design ansehen öffnen und die Prüfliste in Abschnitt 6 abarbeiten.

4. Design-Dateien gezielt manuell bearbeiten

Für Feinarbeit können Entwickler die Dateien des neu erzeugten Designpakets bearbeiten. Dabei gilt: Änderungen bleiben im Designordner. Kernel-Klassen, Module, DD/FD und Datenbanktabellen sind keine Designbestandteile.

Verbindliche Regeln

• [dbx:content] genau einmal erhalten.
• Die von dbxapp verwendeten Platzhalter wie {dbx:title}, {dbx:design}, {dbx:skin_css} und {dbx:skin_class} nicht entfernen.
• core.js?design={dbx:design}, dbxMenu-Aufrufe, Admin-Menü, Fenster-Dock und Rechtelinks funktionsfähig lassen.
• Keine PHP-Fachlogik in HTML oder CSS nachbauen.
• Keine externen Build-Abhängigkeiten voraussetzen. Das Paket muss nach dem Kopieren eigenständig funktionieren.
• Neue Bilder und Texturen unter dem eigenen img/-Ordner ablegen und relativ referenzieren.
• Änderungen in design.json mit Titel, Beschreibung, Layout, Revision und Skins nachvollziehbar dokumentieren.

CSS sinnvoll strukturieren

Mit Variablen für Farben, Flächen, Radius und Schatten beginnen. Danach Schale, Menü, Content, Formulare, Reports und responsive Regeln trennen. Designselektoren immer auf die Designklasse am body begrenzen. So beeinflusst eine Regel nicht versehentlich andere Designs oder den Editor.

body.mein-design {
  --design-primary: #245a87;
  --design-surface: #ffffff;
  --design-text: #17212b;
}

body.mein-design #dbxHeader { … }
body.mein-design .dbx-form { … }
body.mein-design .dbx-report { … }

Hover, Fokus, Aktivzustand und deaktivierte Elemente getrennt prüfen. Ein hübscher Normalzustand reicht nicht: Tastaturfokus und aktive Menüpunkte müssen eindeutig sichtbar bleiben.

5. Design mit dbxKi erstellen oder ändern

Für einen vollständigen visuellen Entwurf, eine umfangreiche Stiländerung oder viele aufeinander abgestimmte Dateien ist dbxKi → KI-Designauftrag vorgesehen. dbxKi gibt der KI das Ausgangsdesign und einen verbindlichen technischen Vertrag mit. Die KI erhält keine Berechtigung, beliebige Serveraktionen auszuführen.

Schritt 1: Aufgabe wählen

• Bestehendes Design ändern: Quelle und Ziel sind identisch. Geeignet für Verbesserungen wie neue Menüoberflächen, bessere Formfelder oder optimierte Mobilansichten.
• Neues Design entwickeln: Ein vorhandenes Design dient als kompatible Basis, das Ergebnis erhält einen freien technischen Zielnamen.

Schritt 2: Ein gutes Briefing schreiben

Das Feld Briefing / Ziel beschreibt das gewünschte Ergebnis, nicht einzelne CSS-Befehle. Danach die Leitfragen für Aufteilung, Menü, Branding, Footer sowie Mobil und Barrierefreiheit ausfüllen.

Beispiel: „Erstelle ein hochwertiges Edelstahl-Design für eine technische B2B-Anwendung. Die Aufteilung bleibt wie dbXapp. Menüs wirken wie glattes Chrom, Hintergründe wie dezentes Riffelblech. Aktive Punkte und Tastaturfokus müssen deutlich erkennbar sein. Formulare bleiben ruhig und gut lesbar. Alle Module, Ajax-Aktionen und Rechte funktionieren unverändert.“

Die Option Systemverhalten, Module, Ajax, openWin und alle Rechte unverändert erhalten aktiviert lassen. Sie beschreibt eine nicht verhandelbare Kompatibilitätsgrenze.

Schritt 3: Auftragspaket exportieren

dbxKi erzeugt ein ZIP mit Briefing, Kontext, Dateiliste, Ausgangsdesign und Ergebnisvertrag. Die KI soll die enthaltene 00-START.md und KI-AUFTRAG.md abarbeiten. Direkte Datenbankänderungen, PHP-Module oder eigene Fremdwerkzeuge gehören nicht in eine Designantwort.

Schritt 4: Antwort-ZIP

Die KI liefert nur neue oder geänderte Dateien unter result/design/ und ein Manifest:

manifest.json
result/design/htm/default.htm
result/design/css/design-custom.css
result/design/img/…

{
  "contract": "dbx.design.result.v1",
  "mode": "create oder update",
  "source_design": "dbxapp",
  "target_design": "mein-design",
  "summary": "Kurze Beschreibung"
}

Schritt 5: Importieren und prüfen

1. Antwort-ZIP im Importblock auswählen.
2. ZIP prüfen starten. Zu diesem Zeitpunkt wird das aktive Design noch nicht verändert.
3. Dateiliste kontrollieren: neu, geändert oder unverändert.
4. Prüfen, ob ausschließlich Design-Dateien enthalten sind und das Ziel korrekt ist.

dbxKi begrenzt Dateianzahl und Paketgröße, verhindert unsichere ZIP-Pfade, validiert das Manifest und kontrolliert jede Ergebnisdatei. Bei einem neuen Design wird das Delta im Staging mit dem Ausgangsdesign zu einem vollständigen Paket zusammengesetzt.

Schritt 6: Anwenden

Erst die dbxForm-Bestätigung Design anwenden führt die Änderung aus. Vor dem Austausch wird bei Updates automatisch ein ZIP-Backup erstellt. Danach validiert dbxDesignService das vollständige Ergebnis und aktiviert nur ein gültiges Design. Die Vorschau-Sitzung und das temporäre Staging werden anschließend entfernt.

Wann Wizard, wann dbxKi?

6. Kompatibilität und Tests

Ein Design ist erst fertig, wenn die Anwendung und nicht nur eine einzelne Contentseite funktioniert. Nach jeder Erstellung oder größeren Änderung mindestens folgende Bereiche prüfen:

Navigation und Schale

• Hauptmenü, Admin-Menü und mehrstufige Untermenüs mit Maus, Touch und Tastatur.
• Aktiv-, Hover-, Fokus- und Deaktiviert-Zustände.
• Design-/Skin-Auswahl, Sprachwahl, Benutzer-Menü und Warenkorb.
• Footer, Fenster-Dock, minimierte Fenster und „Alle Fenster schließen“.

Fachkomponenten

• dbxContent-Seite mit Überschriften, Listen, Tabellen, Bildern und langen Texten.
• dbxForm mit Textfeld, Auswahl, Checkbox, Datei, Hinweis, Validierungsfehler und Bestätigung.
• dbxReport als Tabelle, inklusive vieler Spalten, Footer und mobiler Darstellung.
• Shop-Katalog, Produktdetail, Warenkorb und Kasse.
• Ajax-Aktionen, Dialoge, openWin, Hinweise und Bestätigungen.

Ansichtsgrößen

Abnahmekriterien

• Keine PHP-, JavaScript- oder Templatefehler.
• Keine sichtbaren Platzhalter wie [dbx:…] oder {dbx:…}.
• Keine fehlenden lokalen Bilder, Fonts oder Stylesheets.
• Textkontrast mindestens 4,5:1 für normalen Text; Fokus sichtbar.
• Alle schreibenden Aktionen behalten dbxForm- und Modulschutz.
• Das Design referenziert nur eigene oder ausdrücklich gemeinsame dbxapp-Ressourcen.

7. Typische Fehler und Lösungen

Das Design erscheint nicht in der Auswahl.

design.json, technischer Name und Pflichtdateien prüfen. Danach das Design Studio neu laden.

Inhalt fehlt oder erscheint doppelt.

[dbx:content] muss in der Hauptschale genau einmal vorkommen.

Ein Menü sieht gut aus, Untermenüs aber nicht.

Nicht nur die erste Ebene gestalten. Verschachtelte Listen, lange Titel, aktive Kinder und offene Zustände separat testen.

Hover ist kaum lesbar.

Vorder- und Hintergrundfarbe gemeinsam definieren. Nicht auf Textschatten als einzigen Kontrast verlassen.

Formulare wirken im neuen Design beschädigt.

Native Eingaben, Selects, Textareas, Datei-Uploads, Fokus, Fehler und deaktivierte Felder gemeinsam prüfen. dbxForm-Markup nicht ersetzen.

Nach einer KI-Antwort fehlen Dateien.

Bei Updates darf die Antwort ein Delta enthalten. dbxKi ergänzt es im Staging aus dem Ausgangsdesign. Das Manifest muss Quelle, Ziel und Modus korrekt nennen.

Die KI-ZIP wird abgewiesen.

Vertrag dbx.design.result.v1, Ordner result/design/, sichere relative Pfade und erlaubte Designdateien prüfen.

Eine Änderung soll zurückgenommen werden.

Das beim Anwenden erzeugte Design-Backup verwenden. Vor manuellen Änderungen zusätzlich über das Design Studio ein ZIP herunterladen.

8. Empfohlener Standardablauf

1. Ziel und Zielgruppe schriftlich festhalten.
2. Passendes Ausgangsdesign anhand der benötigten Aufteilung wählen.
3. Für Standardanforderungen den Wizard, für komplexe Gestaltung dbxKi verwenden.
4. Immer ein eigenständiges Ziel-Design wählen; bestehende Designs nur bewusst im Update-Modus ändern.
5. Vorschau und Dateiliste prüfen.
6. Über dbxForm freigeben und das automatische Backup notieren.
7. Navigation, dbxContent, dbxForm, dbxReport, Shop, Ajax und Mobilansicht testen.
8. Erst danach als Standarddesign setzen.
9. Designziel, Revision, besondere Assets und Testergebnis in design.json beziehungsweise der Projektdokumentation nachführen.

Design Studio öffnen KI-Designauftrag öffnen