(this page was created automatically. In case of formatting issues, please visit the official Wiki Page)

Boardlet

Overview

• Dynamic Boardlet is automatically created when a boardlet from the app boardlet library is used.
• It provides a consistent framework with header, body, and footer sections.
• Each section can hold other dynamic components.

Specs

General Tokens

Boardlet Sections Tokens

Structure

(Configured in General Properties)

• displayName – sets the display name of the component shown in the structure panel. For example, "Customer Dashboard" allows for easy identification of the boardlet’s purpose in the component structure.

Header

Appears at the top of the boardlet and typically includes:

• titleTranslations/title – the main heading text for the boardlet, which can be localized through translations.
• moreIconVisible – controls whether an overflow menu icon appears in the header.
• leftIcon – an optional icon displayed at the left side of the header.
• rightIcon – an optional icon displayed at the right side of the header.
• elements – an array of components to display in the header, typically including action icons or menus.
• layout – controls whether elements are arranged horizontally or vertically within the header.

Body

The body section is the main content area of the boardlet and can contain any combination of components:

• elements – an array of dynamic elements to be displayed in the body section.
• layout – controls whether elements are arranged horizontally or vertically within the body.

Footer

The footer section appears at the bottom of the boardlet and typically includes action buttons:

• elements – an array of components to display in the footer, typically button components.
• layout – controls whether elements are arranged horizontally or vertically within the footer.

Styling

(Configured in Visual Properties)

• title – the shown title of the element.
• boardletNameTranslations – defines the displayed name of the boardlet in different languages. Example: {"en-US": "Customer Insights", "de-DE": "Kundeneinblicke"} ensures proper localization of the boardlet name.
• layout – determines how elements are arranged within the boardlet. Options include horizontal (elements side by side) or vertical (elements stacked).
• scrollingEnabled – enables internal scrolling for the boardlet content. Content exceeding the height becomes scrollable.
• showHeader – controls the visibility of the boardlet header section.
• showFooter – controls the visibility of the boardlet footer section.

Actions & Variants

(Configured in Events)

• events – configures the events that the component can trigger and respond to.
• ON_INIT – triggered when the boardlet component is initialized. Can be used to perform setup operations like loading initial data.
• ON_DESTROY – triggered when the boardlet component is removed from the DOM. Useful for cleanup operations and releasing resources.

(Configured in Visual Properties)

• boardletType – sets the visual style of the boardlet. Options include Normal (standard bordered container) or Ghost (borderless container).

Tests

(Configured in Testing Hooks)

• dataTestId – sets the testing hook ID for automated testing. For example, setting it to "customer-dashboard-boardlet" allows test scripts to reliably locate this component.

Authorization

(Configured in Authorization)

• visibilityPolicySetId – determines the visibility of the component based on specified policy sets. For example, setting it to "adminOnlyPolicy" restricts the boardlet to users with admin privileges.

Links

Figma: https://www.figma.com/design/yck1tcUXgdQ5aYX6iUAwrO/GE---Astronaut-Design-System?node-id=11550-252668&t=iosNC2AkSTGs5lMh-1 Life style guide: https://e1-dev.k8s.myapp.de/live-style-guide/id5/2-boardlet

Guidelines

Header / Toolbar

• Every boardlet must always include a toolbar on the right side.
• The toolbar can exist in two variations:
• First actionbar – actions that affect the boardlet itself.
• Second actionbar – actions that affect the content inside the boardlet. Always separated by a dividing line and cannot exist alone.
• Limit toolbars to three visible actions. Additional actions must be grouped into an overflow menu under the “more” icon.
• The “more” action is mandatory in every boardlet toolbar.

Footer

• The footerbar always controls the workflow of the boardlet.
• Workflow-related actions are always placed at the bottom right. Hierarchy flows from bottom right to bottom left.
• Allowed footerbar layouts:
• Tabs only.
• Tabs with buttons (maximum two).
• Buttons only (maximum two).
• Tabs with actionbar (secondary option, e.g., kiosk mode).
• The footerbar has a fixed height and may never be multiline.

Usage

• Pick the visual emphasis that matches the page context by setting boardletType to Normal (bordered) for stronger separation or Ghost (borderless) when the Boardlet should blend into surrounding content.
• Keep the header action area compact: place at most three immediate actions in the headerand expose the rest via the mandatory overflow by setting moreIconVisible: true.
• Use the footer only for workflow-related actions or tabs. If there is no workflow, hide the region (showFooter: false) so the layout stays clean.

Sizing & Layout

• Prevent clipping when content grows by enabling internal scrolling with scrollingEnabled: true; this preserves container height and reduces layout shifts.
• Reduce visual noise by hiding unused chrome (showHeader: false, showFooter: false) instead of leaving empty regions.
• Provide quick, recognizable affordances in the header by configuring leftIcon and/or rightIcon with symbols that match the Boardlet’s purpose (e.g., info, settings).

States & Feedback

• Control presence of major regions at runtime with showHeader and showFooter to reflect task needs (e.g., hide footer after workflow completes).
• Expose additional actions via overflow by toggling moreIconVisible; when true, users have a stable “more” entry point even when visible actions are limited.

Interactions & Events

• Release resources and listeners on teardown with events.ON_DESTROY to keep the UI responsive and stable over time.
• Provide deterministic automation hooks for QA and a11y testing with dataTestId so scripts can reliably target the Boardlet across builds.

Visibility & Authorization

• Restrict who can see the Boardlet by supplying visibilityPolicySetId; when a user doesn’t match the policy, the component remains hidden, preventing accidental exposure of content or actions.

Content & Localization

• Localize all user-facing copy with boardletNameTranslations and titleTranslations/title to match the user’s locale; keep labels short and specific so truncation is unlikely in tighter layout configurations.
• Use displayName for internal structure-panel clarity without changing end-user text; this helps maintain a clean authoring experience across large boards.

Dos & Don’ts

Accessibility

• Provide localized output to assistive tech by filling boardletNameTranslations and titleTranslations/title for all supported locales.
• Maintain predictable reading and navigation order by keeping section visibility (showHeader, showFooter) and section layout stable during interaction.
• Ensure overflow actions remain discoverable by enabling moreIconVisible, so important commands are reachable without shrinking targets.
• Expose dataTestId to support automated accessibility checks and regression testing.
• Avoid using color alone to convey meaning; augment with recognizable leftIcon/rightIcon and clear titleTranslations/title text.