Design manually and by AI

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 authorization 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

dbxapp: classic 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 crucial that the existing dbxMenu output, 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. Create design manually with dbxDesign admin

The standard manual path is the Design Studio 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 pagebar or STEAL for a material-stressed horizontal shell.

Step 2: Defining 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 layout 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. Select Bootstrap 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, “Windowbar only” retains only the bar necessary for dbxapp windows. Set the new design as a front-end standard only immediately if the preview has already been tested.

Step 6: Production and control

After submitting, dbxDesign admin creates the package in staging, checks mandatory files, paths, content slot and metadata and publishes it only afterwards. Then the open the design with View design 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. Where: 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 placeholders used by dbxapp such as Design manually and by AI, dbxdocs, dbx/design/dbxdocs/css/skin-dunkel.css and skin-dunkel theme-dark do not remove.
• core.js?design=dbxdocs, 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.

CSS structure 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. Create or change design with dbxKi

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: Selecting 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: Writing 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 like 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 generates 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: Reply 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 dbxForm confirmation Applying Design executes the change. Before the exchange, a ZIP backup is automatically created for updates. After that, dbxDesignService validates 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

• dbxContent page with headings, lists, tables, images 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

Acceptance 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.
• All writing actions retain dbxForm and module protection.
• The design references only own or expressly common dbxapp resources.

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 markup is not replaced.

After an AI response, files are missing.

For updates, the response may contain a delta. dbxKi complements it in 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 requirements, use the wizard for complex design dbxKi.
4. Always choose an independent target design; Change existing designs only explicitly in update mode.
5. Check preview and file list.
6. Release over dbxForm and record the automatic backup.
7. Test Navigation, dbxContent, dbxForm, dbxReport, Shop, Ajax and Mobile View.
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