| name | component-guidance-data |
| description | Fiori guidelines for data display components such as Table, List, Tree, Avatar, Calendar, Icons, etc |
| metadata | {"tags":["components","data","display","visualization"],"keywords":["table","list","tree","avatar","avatar-group","calendar","carousel","icon","title","object-identifier","object-number","object-status","object-marker","object-list","feed-list","grid-list","micro-process-flow","generic-tile","generic-tag","illustrated-message","info-label","variant-management"],"component_count":23} |
Component Guidance - Data Display
Components for displaying collections and structured data.
When to Use This Skill
Use this skill when:
- The user asks "Should I use [component] for [use case]?"
- The user needs to choose between similar components
- The user asks about component best practices
- The user wants to know when NOT to use a component
This skill covers: Avatar, Avatar Group, Calendar, Carousel, Feed Input, Feed List Item, Generic Tag, Generic Tile, Grid List, Icon, Illustrated Message, Info Label, List, Micro Process Flow, Object Identifier, Object List, Object Marker, Object Number, Object Status, Table, Title, Tree, Variant Management
Avatar
Description:
Avatars are visual representations of users, products, or business entities, helping people quickly identify them within an application. Users can be shown with their own photos or initials, while products can be depicted with representative images or logos.
When to use:
- Display user photos, initials, or placeholders for personal identification
- Show standardized images for business content such as products, parts, logos, or campaign visuals
- Represent concepts or entities with icons when images aren't available
- Present images with transparent backgrounds when needed for clarity or design fit
- Provide placeholder images when no other source image is available
- Apply avatars consistently in places like lists, cards, and headers to create familiarity and a uniform visual pattern across the interface
When to avoid:
- ❌ Display pictures in a sequence, such as a slideshow or carousel → Use
fd-carousel instead
- ❌ Display an interactive icon → Use
fd-button with an icon inside instead
Best practices:
- ✅ Use a circle shape (
fd-avatar--circle) for people
- ✅ Use a square shape for product or business-related images (default shape)
- ✅ Use the predefined sizes:
fd-avatar--xs, fd-avatar--s, fd-avatar--m, fd-avatar--l, fd-avatar--xl
- ✅ For product icons, replace the default icon with a more suitable icon for your use case
- ✅ Provide a clear alternative text (
alt attribute) for the avatar image
- ✅ For interactive avatars with badges, provide both a tooltip and alternative text
- ⚠️ Avoid unnecessarily large image files (optimize images)
- ⚠️ Avoid badges on avatars smaller than size S
- ❌ Don't attach click actions directly to icons in the avatar (wrap in a button instead)
Avatar Group
Description:
The avatar group is a visual element that displays several avatars together, indicating that more than one person or business entity is associated with an item. It's typically used to represent a group of people who belong together – for example, members of a project team or department.
When to use:
- Display a group of at least two people
- Display several people who share something in common, such as a project or a team
- Show team members, collaborators, or participants
- Indicate multiple people associated with an item or task
When to avoid:
- ❌ Display a gallery of simple images → Use carousel instead
- ❌ Display a single avatar → Use
fd-avatar instead
- ❌ Show visual content other than avatars
- ❌ Show unrelated media or content types
Best practices:
- ✅ Always display avatar groups horizontally
- ✅ Use the group type when it's more important to show the avatar group as a whole
- ✅ Use the individual type when users need to focus on each person in the avatar group
- ✅ Use the avatar group to display at least two avatars
- ✅ Use size S by default for most layouts
- ⚠️ Use sizes M or L only when avatars are key to the page
- ⚠️ Display at minimum two avatars (for single avatar, use
fd-avatar)
Calendar
Description:
The calendar lets users select single dates, multiple days, entire weeks, or date ranges. It displays all time-related data (year, month, week, day, date) at a glance and is typically used within a date picker pattern combined with input group and popover.
When to use:
- Select a single date, multiple days, entire weeks, or a date range
- Display multiple months at once
- Calendar needs to be always visible and prominent
- Users need to see year, month, week, weekday and date at a glance (e.g., selecting based on day of week)
- Support locale-specific date formats by allowing visual date selection
- Highlight special days or hide/disable specific days
When to avoid:
- ❌ Power users entering data fast → Use date picker instead
- ❌ Keyboard is primary input device → Use date picker instead
- ❌ Limited screen space where permanent calendar display takes too much room → Use date picker instead
- ❌ Primary goal is selecting a date range → Use date range selection instead
- ❌ Displaying range of weekdays in a single row → Use calendar date interval instead
- ❌ Comparing calendars from different people → Use planning calendar instead
- ❌ Selecting combined date and time values → Use date/time picker instead
Best practices:
- ✅ Use within date picker pattern (calendar + input group + popover) rather than standalone
- ✅ Enable visual date selection to bypass locale-specific format interpretation
- ✅ Highlight special days when relevant to user's task
- ✅ Allow navigation between months and years
- ⚠️ Calendar is rarely used as a standalone component - usually part of date picker pattern
- ⚠️ Consider date picker for keyboard-heavy or data-entry workflows
Carousel
Description:
The carousel allows users to browse through a set of items, displaying one or several items at a time with navigation to next or previous items. It's best suited for browsing images and includes optional paging indicators. The content area automatically adjusts to available screen space.
When to use:
- Display items that need strong visual representation
- Show items sequentially or side by side
- Browse through a set of images where viewing one by one helps distinguish between items
- Comparison scenarios where displaying several items side by side is useful
- Any sap.m control can be contained (not limited to images)
When to avoid:
- ❌ Displaying uniform items that don't benefit from individual presentation
- ❌ Items that don't require sequential browsing or visual distinction
Best practices:
- ✅ Use paging indicator to show user's current position in the set
- ✅ Content area automatically adjusts to available screen space
- ✅ Navigation buttons float on left/right or appear in page indicator area (non-touch devices)
- ✅ Support swipe gestures on touchable devices (buttons hidden automatically)
- ✅ Add visually hidden div with
role="region" and aria-live="polite" as sibling to .fd-carousel
- ✅ Update aria-live region dynamically via JavaScript for content changes
- ✅ Display Message Page with
sap-icon--document for empty state (no pages loaded)
- ⚠️ Ensure accessibility by announcing content changes to screen readers
- ⚠️ Navigation method adapts automatically: buttons for non-touch, swipe for touch devices
Feed Input
Description:
The feed input is designed for users to type notes or comments and post them to a corresponding feed. It handles small amounts of unformatted text across multiple instances like notes or feed entries.
When to use:
- User needs to input small amounts of text without formatting
- Multiple instances are expected, such as notes or feed entries
- Adding comments or posts to a feed
- Quick text input for social or collaborative features
When to avoid:
- ❌ User needs to format text (rich text editor) → Use rich text editor instead
- ❌ Only a single text box instance is needed → Use textarea (multiple lines) or text control (single line) instead
Best practices:
- ✅ Use for unformatted text input only
- ✅ Design for multiple instances (feed scenarios)
- ✅ Keep interface simple and focused on quick text entry
- ⚠️ Consider textarea for single-instance multi-line text needs
- ⚠️ Consider text control for single-line text input
Feed List Item
Description:
The feed list displays feed list items that each consist of a username, written entry, optional image, and a byline (timestamp or attribute as free text). It's designed for displaying homogenous feed entries.
When to use:
- Multiple instances are expected, such as notes or feed entries
- Items in the feed list are homogenous
- User needs to input small amounts of text without formatting
- Display existing feed entries with username, content, and metadata
When to avoid:
- ❌ User needs to format text (rich text editor) → Use rich text editor instead
- ❌ Only a single text box instance is needed → Use Text Area instead
- ❌ Displaying empty fields for user to input feed entries → Use Feed Input instead
Best practices:
- ✅ Each item includes username, written entry, and optional image
- ✅ Include byline with timestamp or attribute as free text
- ✅ Keep items homogenous for consistent feed appearance
- ✅ Use Feed Input component for creating new feed entries
- ⚠️ Feed list is for displaying existing entries, not for input
- ⚠️ Pair with Feed Input for complete feed functionality
Generic Tag
Description:
Generic tag displays complementary information like key performance indicators (KPIs) or status details, providing additional context without users leaving the current page. Typically appears in dynamic page headers or object page header areas following the title.
When to use:
- Display complementary information for an object (e.g., KPI)
- Show status details or additional context
- Place in dynamic page header or object page header area following the title
- Provide non-intrusive contextual information
When to avoid:
- ❌ Decorative purposes
- ❌ Navigation
Best practices:
- ✅ Use for complementary information like KPIs and status
- ✅ Place in header area following the title
- ✅ Provide additional context without requiring page navigation
- ✅ Use in dynamic page header or object page header area
- ⚠️ Should be informational, not interactive or decorative
- ⚠️ Not for navigation purposes
Generic Tile
Description:
Generic tile is a container representing an app on the SAP Fiori launchpad home page. Displays various content types including icons, information text, titles, KPIs, counters, and charts. Tiles automatically move to the next row when horizontal space is insufficient.
When to use:
- Display apps on SAP Fiori launchpad home page
- Show content types: KPIs, charts, icons, information text, titles, counters
- Use icons on basic launch tiles or monitoring tiles (when not showing KPI or chart)
- Display different content types based on data from the app
When to avoid:
- ❌ Using tiles anywhere other than launchpad home page
- ❌ Showing content types not described in guidelines (videos, animations, gifs)
- ❌ Using status area for error messages
- ❌ Using tile subtitle for explanations (only for differentiators like specific data views)
- ❌ Using icons on KPI tiles (only on basic launch or monitoring tiles)
- ❌ Showing icons next to counter expecting 5+ digits
- ❌ Developing custom icons (use standard icons only)
Best practices:
- ✅ Only use on launchpad home page
- ✅ Show icons to help distinguish tiles when not showing KPI or chart
- ✅ Use short tile names
- ✅ Use modifiers:
fd-numeric-content__scale--text, fd-tile--feed, fd-tile--double, fd-tile--container—list
- ✅ Use deviation arrows:
sap-icon--down or sap-icon--up in scale factor area
- ✅ Tiles automatically wrap to next row when space is insufficient
- ⚠️ Icons only on basic launch or monitoring tiles, not KPI tiles
- ⚠️ Avoid icons next to counters with 5+ digits
- ⚠️ Use subtitle only for differentiators, not explanations
Grid List
Description:
Grid list displays items in a grid format (not rows), ideal for visual content like images, charts, and object cards that benefit from more height. Usually used as an alternative view for lists or tables, focusing on complete items rather than cells.
When to use:
- Visual content that benefits from rectangular card format (images, charts, object cards)
- Focus on complete items rather than individual cells
- Display homogeneous set of basic data
- Sort, group, or filter simple data sets
- Alternative view for tables or lists when content benefits from grid format
When to avoid:
- ❌ Content not appropriate for card format (e.g., wall of text) → Use table instead
- ❌ Selecting one item from very small number without viewing details → Use select or combo box instead
- ❌ Data structured hierarchically → Use tree instead
- ❌ Overview of large amount of data → Use chart instead
- ❌ Layout purposes only → Use layout container like CSS Grid instead
- ❌ Managing complex datasets needing extensive sorting, grouping, filtering, or editing → Use table instead
Best practices:
- ✅ Best for visual content (images, charts, object cards)
- ✅ Items displayed in grid, not rows
- ✅ Focus on complete items rather than cells
- ✅ Use for homogeneous basic data sets
- ✅ Good alternative view format for lists or tables
- ⚠️ Content should profit from rectangular card-like format
- ⚠️ Not suitable for hierarchical data or complex dataset management
Icon
Description:
Icons provide visual clarity, save screen space, and guide users during navigation. Used as visual elements within other components or independently (when readable by screen readers or have tooltips). Non-interactive by nature for illustrative purposes only.
When to use:
- Display icon for illustrative purposes without interaction states (non-interactive icon/pictogram)
- Pair icon with another communication method (text or tooltip)
- Use as visual elements within other components
- Save screen space while maintaining clarity
- Guide users during navigation
When to avoid:
- ❌ Icon needs to be selected or have interaction states → Use transparent button style instead
Best practices:
- ✅ Use for illustrative purposes only (non-interactive)
- ✅ Always pair with text or tooltip for accessibility
- ✅ Ensure screen reader compatibility
- ✅ For interactive icons, use transparent button style (see Button component)
- ⚠️ Icons alone don't provide sufficient accessibility without text/tooltip
- ⚠️ For selectable icons, use Button component with transparent style
Illustrated Message
Description:
Illustrated messages engage users and add personality using SVG illustrations (from SAP Moments library), paired with heading, description, and optional call-to-action button. Available in sizes: Large (default), Medium, Small, Extra Small, and Base (no illustration). Supports responsive container for Large size.
When to use:
- Clarify situations with engaging visuals (empty states, errors, success)
- Add personality to user experience
- Explain reason for empty state
- Provide details and next steps
- Guide users with optional call-to-action button
- Use SVG illustrations from SAP Moments library
When to avoid:
- ❌ When simple text message suffices without visual engagement
- ❌ Dense data displays where illustrations distract
Best practices:
- ✅ Always pair illustration with message (heading + description)
- ✅ Heading explains reason for state, preferably single line
- ✅ Description adds details and next steps (3 lines or less)
- ✅ Include CTA button when there's a clear next step (optional but recommended)
- ✅ Use sizes: Large (
.fd-illustrated-message), Medium (--medium), Small (--small), Extra Small (--xsmall), Base (--base, no illustration)
- ✅ Use
.fd-illustrated-message-responsive-container for Large size responsiveness (inline content query)
- ✅ Legacy modifiers still supported:
--scene (Large), --dialog (Medium), --spot (Small), --dot (Extra Small)
- ⚠️ Illustration must come from SAP Moments library (use SVG)
- ⚠️ Base type has no illustration (text only)
Info Label
Description:
Info Label is a small non-interactive numeric or text-based label (BTP component). Primary use is adding user-defined characteristics to objects. Supports 10 accent colors and display mode.
When to use:
- Add user-defined characteristic to an object
- Display small non-interactive numeric or text-based labels
- Categorize or tag objects with visual color coding
- Display mode for larger presentation (use
fd-info-label--display)
When to avoid:
- ❌ Interactive labels or tags → Use different component
- ❌ Large amounts of text → Use other text components
Best practices:
- ✅ Use accent color modifiers:
fd-info-label--accent-color-1 through --accent-color-10
- ✅ Accent colors: 1-Mango, 2-Red, 3-Raspberry, 4-Pink, 5-Indigo, 6-Blue, 7-Teal (Default), 8-Green, 9-Cyan, 10-Grey
- ✅ Use
fd-info-label--display modifier for display mode
- ✅ Default accent is Teal (accent-color-7)
- ✅ Non-interactive by design
- ⚠️ BTP-specific component
- ⚠️ Use for small labels only (numeric or short text)
List
Description:
Lists display homogeneous basic data, distinguished from tables (which handle complex data). Used in master lists for master-detail scenarios with flexible column layout, popovers, and dialogs. Supports byline variant for additional content and semantic status.
When to use:
- Display homogeneous set of basic data
- Sort, group, or filter simple datasets
- Display single-level hierarchy (simpler than tree table)
- Include additional text in list items (byline list with
fd-list--byline)
- Present semantic status in list items (byline list)
- Display accounts in user menu (subline with third line)
When to avoid:
- ❌ Managing complex datasets needing extensive sorting, grouping, filtering, or editing → Use table instead
- ❌ Working with complex hierarchies → Use tree instead
- ❌ Including objects in list items (when using byline list) → Use Object List instead
Best practices:
- ✅ Use for homogeneous basic data (not complex data)
- ✅ Use in master-detail scenarios with flexible column layout
- ✅ Use in popovers or dialogs
- ✅ Add
fd-list--byline modifier for byline list (additional text/semantic status)
- ✅ Byline list extends standard list items with additional content
- ✅ Support single-level hierarchies (simpler use case)
- ⚠️ Lists for basic data, tables for complex data
- ⚠️ Use tree for complex hierarchies, not list
Micro Process Flow
Description:
Micro Process Flow visualizes the state of individual items in a linear workflow. Can be embedded in lists or tables. Responsive, adapts to parent container size. Supports simple wrap or overflow with navigation arrows for long processes.
When to use:
- Show state of each step in linear, multi-step process
- Display progress of multiple items in list or table
- Default layout: icons with circular background, semantic colors, click events (SAP icon font)
- Custom layout: replace with other controls (status indicator, button, label, link, avatar)
- Dependent steps (default): connector lines between steps when completion is precondition for next step
- Independent steps: no connectors when steps can be processed in any order
When to avoid:
- ❌ Single-step process → Use progress indicator or object status instead
- ❌ Complex non-linear workflow → Use process flow instead
Best practices:
- ✅ Responsive: adapts to parent container size
- ✅ Simple wrap: steps wrap to new line if don't fit width
- ✅ Overflow mode: navigation arrows with hidden step count, scroll horizontally
- ✅ Default layout: icons with circular background, semantic colors, SAP icon font
- ✅ Custom layout: supports status indicator, button, label, link, avatar
- ✅ Dependent steps: use connector lines, indicate transition state with icons
- ✅ Independent steps: no connectors for non-sequential processing
- ⚠️ Use dependent steps when completion is precondition for next step
- ⚠️ Use independent steps when any-order processing is allowed
Object Identifier
Description:
Object Identifier is short text representing the key identifier of an object, displayed in containers, tables, panels, popovers, and more. Text wraps if insufficient horizontal space. Comprises title text, optional descriptive text, and optional active state (link-like) that can trigger events.
When to use:
- Indicate key identifier on an object
- Display text instead of ID for easy readability
- Distinguish objects by IDs (display as descriptive text below title)
- Need interactive link-like behavior (active state) to trigger events
When to avoid:
- ❌ Displaying system messages
- ❌ Decorative purposes only
Best practices:
- ✅ Display text instead of ID for easy user readability
- ✅ If IDs necessary to distinguish objects, show as descriptive text below title text
- ✅ Comprises title text and optional descriptive text
- ✅ Optional active state resembles link and can trigger events
- ✅ Text wraps when insufficient horizontal space
- ✅ Can be displayed in various container types (tables, panels, popovers)
- ⚠️ Prioritize readable text over raw IDs
- ⚠️ Not for system messages or decorative purposes
Object List
Description:
Object list consists of object list items providing quick object overviews. Each item shows essential information for prioritizing objects. Can display title, avatar, object display components (Identifier, Number, Attribute, Marker, Status), introductory text, icon, and status line with indicator icons.
When to use:
- Display brief details to user
- Quick overview of objects
- Show essential information for object identification and prioritization
- Display object display components: Object Identifier, Object Number, Object Attribute, Object Marker, Object Status
- Show introductory text (e.g., "Forwarded by...", "On Behalf of...")
- Display status line with indicator icons (locked, favorites, flagged for follow-up)
When to avoid:
- ❌ Displaying detailed information to user
- ❌ Triggering more than one event (each item should contain one link)
Best practices:
- ✅ Show only essential information for prioritization
- ✅ Avoid long descriptive texts (limited space, will truncate)
- ✅ Each item provides quick overview of object
- ✅ Use semantic status modifiers:
fd-object-number--positive/negative/critical/informative, fd-object-status--positive/negative/critical/informative
- ✅ Can display: title, avatar, object components, introductory text, icon, status line
- ✅ Each object list item should contain one link
- ⚠️ Text space is limited - avoid long descriptions
- ⚠️ Only one event per item
Object Marker
Description:
Object Marker indicates technical status of an object (draft, unsaved changes, locked, favorite, flagged). Displays technical state, not business lifecycle status. Can be represented as icon only, icon with text, or text only, depending on screen size.
When to use:
- Indicate technical status of object
- Display technical states: draft, unsaved changes, locked, favorite, flagged
- Adapt presentation to screen size (icon only, icon + text, text only)
When to avoid:
- ❌ Displaying status of object in business lifecycle → Use different component
Best practices:
- ✅ Use for technical status only (not business lifecycle)
- ✅ Represents states: draft, unsaved changes, locked, favorite, flagged
- ✅ Adaptive representation: icon only, icon with text, or text only
- ✅ Adjust display based on screen size
- ⚠️ Not for business lifecycle status
- ⚠️ Specifically for technical state indicators
Object Number
Description:
Object Number represents a numeric attribute of an object and its unit. Displayed with semantics to provide insight about object's value. Supports semantic statuses via modifier classes (neutral, positive, negative, critical, informative).
When to use:
- Display key number of an object
- Display one or more numeric attributes of an object (e.g., for comparison)
- Emphasize (bold) for key numeric attributes on page or line item status in table
When to avoid:
- ❌ Displaying system messages
- ❌ Decorative purposes only
Best practices:
- ✅ Properly describe and make semantically understandable (accessibility)
- ✅ If color describes value as negative, accompany with icon, label, unit, or attribute
- ✅ Color should not be only way value state is conveyed
- ✅ Use semantic status modifiers:
fd-object-number--positive, --negative, --critical, --informative (neutral is default)
- ✅ Emphasize (bold) for key numeric attributes or table line item status
- ✅ Display with unit for clarity
- ⚠️ Ensure accessibility - don't rely on color alone for value state
- ⚠️ Include icon, label, unit, or attribute with color indicators
Object Status
Description:
Object Status is a short text that represents the semantic status of an object. It has a semantic color and an optional icon. Typically used in dynamic page headers and as status attributes of line items in tables.
When to use:
- Display semantic status of an object with text and color
- Show status attribute in table line items
- Indicate object state in dynamic page headers
- Provide quick visual indication of object status with semantic meaning
When to avoid:
- ❌ Displaying detailed system messages → Use
fd-message-strip instead
- ❌ Long status descriptions → Keep text short and concise
- ❌ Non-semantic decorative text → Use plain text instead
Best practices:
- ✅ Use semantic color modifiers:
fd-object-status--positive, --negative, --critical, --informative (neutral is default)
- ✅ Add optional icon to reinforce status meaning
- ✅ Keep status text short and concise
- ✅ Color should not be only way status is conveyed (accessibility)
- ✅ Include icon or clear text label alongside color
- ✅ Use in tables for line item status indication
- ✅ Display in dynamic page headers for object-level status
- ⚠️ Ensure accessibility - don't rely on color alone for status meaning
- ⚠️ Accompany semantic colors with icons or descriptive text
- ❌ Don't use for lengthy descriptions or messages
Table
Description:
Table contains set of line items with rows (each showing one line item) and columns. Items can contain data or interactive elements. Two groups: fully responsive tables and desktop-centric tables. Responsive table offers flexibility, grid table for large datasets (>1,000 rows) and analytical use cases.
When to use:
- Display large amounts of data in tabular form
- Flexible, visually appealing table content (responsive table)
- Focus on working with line items, not individual cells
- Select one or more items needing details to choose correctly
- Line items independent, no cross-column operations needed
- Single implementation for all devices
- Display >1,000 rows simultaneously (grid table)
- Cell-level and spatial relationships important (grid table)
- Comparing items is major use case (grid table)
- Need analytical table without analytical binding (grid table)
When to avoid:
- ❌ Simple hierarchical dataset → Use Tree instead
- ❌ Hierarchical master list for master-detail with Flexible Column Layout → Use Tree
- ❌ Tree table would be too complex → Use Tree
- ❌ Selecting hierarchical items with few details → Use Tree
- ❌ Very few items (under 5) → Consider List or Card layout
Best practices:
- ✅ Use responsive table for flexible content and visual appeal
- ✅ Responsive table allows multiple components and different item templates
- ✅ Use grid table for >1,000 rows
- ✅ Grid table maintains stable layout regardless of screen width
- ✅ Grid table cells contain only one component
- ✅ Include sorting, filtering, and search for large datasets
- ✅ Provide selection for line items when needed
- ✅ Use pagination for very large datasets
- ✅ Make column headers clear and descriptive
- ⚠️ Choose table type based on use case (responsive vs grid)
- ⚠️ Consider performance with large datasets
- ❌ Don't use table for hierarchical data - use Tree
Title
Description:
Title is a simple, large-sized text with additional semantic information for accessibility. Unlike manually styled headings, titles can be used by assistive technologies (screen readers) to create hierarchical site map for faster navigation. Used by panel, toolbar, list components.
When to use:
- Set title above table or form
- Show text in page header
- Create semantic heading hierarchy
- Need assistive technology support for navigation
- Used in panel, toolbar, or list components
- Display section or content headings
When to avoid:
- ❌ Text inside a text block → Use paragraph or span
- ❌ Text inside a form element → Use form label or legend
- ❌ Inline text within paragraphs → Use span or emphasis
- ❌ Decorative text without semantic meaning → Use styled text
Best practices:
- ✅ Provides semantic information for accessibility
- ✅ Used by screen readers for hierarchical site navigation
- ✅ Use above tables or forms as headings
- ✅ Use in page headers
- ✅ Use proper heading level (H1-H6) for document structure
- ✅ Maintain logical heading hierarchy
- ✅ Used by panel, toolbar, list components
- ✅ Large-sized text with semantic meaning
- ⚠️ Different from manually styled headings - has semantic value
- ⚠️ Don't skip heading levels (e.g., H1 to H4)
- ❌ Don't use inside text blocks or form elements
Tree
Description:
Tree displays and works with hierarchical item sets. Nodes contain additional items, leaves don't. Single top-most node is root. Similar to List but hierarchical. Used in master lists (Flexible Column Layout), Popovers, Dialogs, Dynamic Page Layout. Expandable/collapsible nodes with dynamic indentation.
When to use:
- Display key identifier of hierarchically structured items
- Select one or more items from hierarchical set
- Hierarchy has restricted levels (up to ~12) and items (~200)
- Master list in Flexible Column Layout master-detail
- Single implementation for all devices
- Navigate hierarchical data structures
- Expand/collapse hierarchical nodes
When to avoid:
- ❌ Select from very small non-hierarchical items → Use Select or Combobox instead
- ❌ Items not structured hierarchically → Use List instead
- ❌ Only two hierarchy levels → Use grouped List instead
- ❌ Categorization based on item details → Use analytical table with multi-level grouping
- ❌ Large hierarchy (>12 levels or >200 items) → Consider alternative visualization
Best practices:
- ✅ Container for hierarchical items with expand/collapse
- ✅ Dynamic indentation per level when expanding nodes
- ✅ Root contains
expanded-level-* class tracking current level
- ✅ Same indentation rules for compact and cozy modes
- ✅ Add
fd-tree__content--wrap for text wrapping (default: no wrap)
- ✅ Use
fd-tree--active for all navigable items
- ✅ Use
fd-tree__item-container--active for specific navigable items
- ✅ Use
is-selected class for selection (radio/checkbox)
- ✅ Use
is-navigated class for previously navigated items
- ✅ Support hover, selected, active states
- ✅ Up to ~12 levels and ~200 items
- ⚠️ Default: items non-interactive, add states as needed
- ⚠️ Consider performance with large hierarchies
- ❌ Don't use for flat lists or simple two-level grouping
Variant Management
Description:
Variant Management stores filter settings (filter parameters, selection fields, layout) defined in components like filter bar. Enables users to load, save, and change variants. In table context, saves and manages table settings including layout, column visibility, sorting, and grouping.
When to use:
- Store filter settings from filter bar
- Save filter parameters, selection fields, and layout
- Load, save, and change filter variants
- Manage table settings (layout, columns, sorting, grouping)
- Allow users to save personalized views
- Enable switching between different filter configurations
- Store table personalization settings
When to avoid:
- ❌ Simple filtering without save/load needs → Use basic filters
- ❌ No personalization required → Don't add variant management
- ❌ Single fixed view → No need for variants
- ❌ Temporary filters not worth saving → Use inline filters
Best practices:
- ✅ Store filter settings from filter bar
- ✅ Include filter parameters, selection fields, and layout
- ✅ Enable load, save, and change variant operations
- ✅ In tables: save layout, column visibility, sorting, grouping
- ✅ Allow users to name and manage their variants
- ✅ Provide default/standard variants
- ✅ Allow marking favorite/default variant
- ✅ Support sharing variants between users when appropriate
- ✅ Include variant descriptions for clarity
- ✅ Allow deleting user-created variants
- ⚠️ Clearly distinguish between personal and shared variants
- ⚠️ Protect system/standard variants from deletion
- ❌ Don't force variant usage for simple scenarios
