1. Building and responsibilities

The separation is deliberately simple: dbxContent provides the content, the modules provide their functions and the selected design forms the outer shell. A design may therefore change layout, colors, typography, distances, branding, logo, menu shape, background and footer. It shall not replace the eligibility check or data processing of a module.

Design package

Each design is independently under dbx/design/<designname>/. Essential components are:

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

The design slots [dbx:logo], [dbx:branding] and [dbx:footer] keep the shells produced clear. The Content Slot [dbx:content] It has to be there just once. Assets of one design should not secretly point to private files of another design.

Design and skin

The design determines structure and basic style. A skin is a color variation within this design. In the design selection, the skins are therefore grouped under their respective design. A new design should only include the actually supported skins in design.json publishing.

2. The three existing designs as examples

dbXappclassic horizontal application shell

Point of learning: A clear basic structure can be varied in color via skins without rebuilding menus, modules or content.

Flowers: independent branding with side menu

Point of learning: A design may significantly change the page layout. It is important that the existing dbxMenu-Expenditure, system actions and content areas are maintained.

STEAL: Material style with familiar operation

Point of learning: Not every new appearance needs a new page architecture. Often, a cleanly limited design update is safer and faster.

3. Design manually with dbxDesign_admin Created

The standard manual path leads over the Design Studio. The Wizard there produces a complete, independent and tested design package. The initial design remains untouched.

Step 1: Select initial design

1. In the main menu System Design Studio open.
2. With a suitable design Personalisation Choose or choose the general Design wizard start.
3. Select the initial design according to the required structure: dbXapp for an upper menu, Flowers as an example of a sidebar or STEAL for a material-stressed horizontal shell.

Step 2: Define identity

• Technical name: short, clear and permanent, for example meine-firma. This creates the design folder.
• Design title: understandable name for the selection.
• Description: Briefly document purpose, target group and style.

Step 3: Page division and menu

The Wizard offers three basic layouts:

• Menu above: Suitable for administration interfaces and wide workspaces.
• Menu left: Suitable for brand appearances, many main points and a quiet content axis.
• Hybrid: Branding above and navigation left.

Then choose menu shape, content width and footer. “Compact” makes sense for many entries, “Tabs” looks technical and clear, “Pills” more friendly and softer. The preview shows the basic division, but does not replace the later test with real submenus.

Step 4: Branding, logo and colors

1. Register the brand name and claim.
2. BootstrapChoose icon or own logo. For logos use PNG, JPG, WEBP or GIF up to 5 MB.
3. Define primary, secondary and accent color.
4. Select background, area and text color so that text and controls have sufficient contrast.
5. Typography and corners to match the brand character.

Step 5: Footer and Standard Design

The full footer contains text, right links and window bar. "Minimal" reduces the information, "Window strip only" receives only the for dbxapp-Window necessary bar. Set the new design as a front-end standard only immediately if the preview has already been tested.

Step 6: Generate and control

After sending it, dbxDesign_admin the package in staging, checks mandatory files, paths, content slot and metadata and publishes it only afterwards. Then the design over View design open and process the checklist in Section 6.

4. Design files targeted manually

For fine-tuning, developers can edit the files of the newly created design package. The following applies: Changes remain in the design folder. Kernel classes, modules, DD/FD and database tables are not design components.

Binding rules

• [dbx:content] Received exactly once.
• The dbxapp used placeholders such as {dbx:title}, {dbx:design}, {dbx:skin_css} and {dbx:skin_class} do not remove.
• core.js?design={dbx:design}, dbxMenu-Calls, admin menu, window dock and right links.
• Do not replicate PHP logic in HTML or CSS.
• Do not require external build dependencies. The package must function independently after copying.
• New images and textures under your own img/-Put down folders and reference them relatively.
• Amendments to design.json with title, description, layout, revision and skins traceable document.

Structuring CSS sensibly

Start with variables for colors, areas, radius and shadows. Then separate the shell, menu, content, forms, reports and responsive rules. Design selectors always on the design class body limitation. Thus, a rule does not accidentally affect other designs or the 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 { … }

Check hover, focus, active state and deactivated elements separately. A pretty normal state is not enough: keyboard focus and active menu items must remain clearly visible.

5. Design with dbxKi Create or modify

For a complete visual design, an extensive style change or many coordinated files is dbxKi AI design task provided. dbxKi provides the AI with the initial design and a binding technical contract. The AI does not get permission to perform any server actions.

Step 1: Choose a task

• Change existing design: Source and destination are identical. Suitable for improvements such as new menu interfaces, better shape fields or optimized mobile views.
• Developing a new design: An existing design serves as a compatible basis, the result is given a free technical target name.

Step 2: Write a good briefing

The field Briefing / Objective describes the desired result, not individual CSS commands. Then fill in the key questions for distribution, menu, branding, footer as well as mobile and accessibility.

Example: Create a high-quality stainless steel design for a technical B2B application. The division remains as dbXapp. Menus look like smooth chrome, backgrounds like subtle ribbed sheet. Active points and keyboard focus must be clearly visible. Forms remain calm and easy to read. All modules, Ajax actions and rights work unchanged.

The option System behavior, modules, Ajax, openWin and all rights unchanged Leave activated. It describes a non-negotiable compatibility limit.

Step 3: Export order package

dbxKi creates a ZIP with briefing, context, file list, initial design and results contract. The AI should contain the 00-START.md and KI-AUFTRAG.md processing. Direct database changes, PHP modules or own third-party tools do not belong in a design response.

Step 4: Response ZIP

The AI only delivers new or modified files under result/design/ and a manifesto:

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"
}

Step 5: Import and Check

1. Select the answer ZIP in the import block.
2. Check the zip start. At this point, the active design is not yet changed.
3. Check the file list: New, modified or unchanged.
4. Check that only design files are included and the target is correct.

dbxKi Limits file number and packet size, prevents insecure ZIP paths, validates the manifest and controls each result file. In a new design, the delta is assembled in staging with the initial design into a complete package.

Step 6: Apply

First the dbxFormConfirmation Applying Design executes the change. Before the exchange, a ZIP backup is automatically created for updates. Then validated dbxDesignService the full result and activates only one valid design. The preview session and temporary staging are then removed.

When Wizard, When dbxKi?

6. Compatibility and testing

A design is only finished when the application and not just a single content page works. After each creation or major change, consider at least the following areas:

Navigation and shell

• Main menu, admin menu and multi-level submenus with mouse, touch and keyboard.
• Active, hover, focus and deactivated states.
• Design/Skin selection, language choice, user menu and shopping cart.
• Footer, window dock, minimized windows and “Close all windows”.

Technical components

• dbxContentPage with headings, lists, tables, pictures and long text.
• dbxForm with text field, selection, checkbox, file, note, validation error and confirmation.
• dbxReport as a table, including many columns, footers and mobile display.
• Shop catalogue, product detail, shopping cart and checkout.
• Ajax actions, dialogues, openWin, notices and confirmations.

View sizes

Removal criteria

• No PHP, JavaScript or template errors.
• No visible placeholders such as [dbx:…] or {dbx:…}.
• No missing local images, fonts or style sheets.
• text contrast at least 4,5:1 for normal text; Focus visible.
• Keep all writing actions dbxForm- and module protection.
• The design references only own or expressly common dbxappResources.

7. Typical errors and solutions

The design does not appear in the selection.

design.json, technical name and mandatory files. Then reload the Design Studio.

Content is missing or appears double.

[dbx:content] must occur exactly once in the main shell.

A menu looks good, but submenus do not.

Not just the first level. Test nested lists, long titles, active children, and open states separately.

Hover is hardly readable.

Define foreground and background color together. Do not rely on text shadows as the only contrast.

Forms appear damaged in the new design.

Check native inputs, selects, text areas, file uploads, focus, errors and deactivated fields together. dbxForm-Do not replace markup.

After an AI response, files are missing.

For updates, the response may contain a delta. dbxKi It complements staging from the initial design. The manifest must correctly state the source, destination and mode.

The AI-ZIP is rejected.

Contract dbx.design.result.v1, folders result/design/Check safe relative paths and allowed design files.

An amendment is to be withdrawn.

Use the design backup created when applied. Before manual changes, additionally download a ZIP via the Design Studio.

8. Recommended standard sequence

1. Aim and target group in writing.
2. Select a suitable initial design based on the required division.
3. For standard Wizard requirements, for complex design dbxKi use.
4. Always choose an independent target design; Change existing designs only consciously in update mode.
5. Check preview and file list.
6. Over dbxForm release and record the automatic backup.
7. navigation; dbxContent, dbxForm, dbxReport, shop, Ajax and mobile view test.
8. Only then set as a standard design.
9. Design goal, revision, special assets and test result in design.json or the project documentation.

Open Design Studio Opening an AI design task