Archives

Overview Page – Fixed Card Layout

Self-Contained Cards

The fixed card layout is a layout for the overview page. It comes with predefined card characteristics that support automatic, easy and fast card design. The cards have a fixed width, and the height is determined by the card type and the embedded control.

The cards are ordered in responsive and collapsible columns. The number of columns is also fixed to keep the focus on the middle of the screen and show the set of cards in a compact display (a kind of letterboxing). For more information, see Responsiveness.

Before you start designing cards for an overview page, see the best practices.

At a Glance

  • Easy and fast card design using predefined card framework

  • Fixed card width and predefined height

  • Arbitrary card order

Overview page – Fixed card layout
Overview page – Fixed card layout

Fixed Card Sizes

Grid

The grid is based on rows and columns. The spacing of 1 rem between the cards is always stable. Furthermore, there is a minimum width of 20 rem per card (corresponding to the column width). The columns with the cards adapt to the available screen real estate (also see Responsiveness).

Based on the underlying grid, users can rearrange the cards (see Rearranging Cards – Behavior).

Fixed card layout – Grid
Fixed card layout – Grid

The cards are arranged as a “Z” flow: cards are ordered from left to right, starting with the first card on the top left of the page. For example, if a 5-column layout is reduced to 4-column layout, the fifth card drops to the next row, assuming the leftmost position underneath the first card.

There is no limit on the number of cards included. However, be careful not to overwhelm your users.

For general information on cards, see Cards.

Fixed card layout – Z flow
Fixed card layout – Z flow

Card Sizes per Type

The card size is determined by the predefined card characteristics and maximum content for a given card type. As a result, the card types differ in height. The stack card and corresponding quick view card are handled independently.

List Card

The height of list cards can vary, depending on the number of text fields. Show no more than five standard list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Standard list item
Standard list item
Extended list item
Extended list item

Bar Chart List Card

The height of  bar chart list cards can vary, depending on the number of text fields. Show no more than five standard/condensed list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Standard list item
Standard list item
Condensed list item
Condensed list item
Extended list item
Extended list item

Link List Card (Variant Type “List”)

The link list card with the variant type “list”  is limited to a maximum of six links. There is no limit to the number of links for the variant type “image”.

Table Card

The height of table cards can vary, depending on the number of table cells. Tables are limited to a maximum of 3 columns and 3 rows, with a maximum of 3 lines of text per row. To see the full result set, the user needs to navigate to the parent app.

Rearranging Cards – Behavior

Drag and Drop

Users can reposition cards on the overview page by dragging them to a different location. As the user drags a card, it swaps places with any cards in its path. As soon as a neighbouring card is touched, the position of that card becomes the new target location for the card being dragged. A dashed line offers a preview of the new position.

To drag a card, the user has to long press on a card instead of just clicking. It doesn’t matter where the cursor is positioned – cards can be dragged from both the header and content areas. The mouse cursor also changes to indicate that the card can be dragged. Releasing the mouse or lifting the finger from the touch surface completes the move. To avoid gaps, cards always snap to the next free space in the row, or to the start of the next row.

In addition, users can personalize their own overview page by hiding cards.

Fixed card layout – Drag and drop
Fixed card layout – Drag and drop

Getting Started

In the fixed card layout, you can’t influence the amount of information on each card. However, you can define the card order. Before you design your overview page, take a look at the best practices, which outline how to best use cards for an optimal user experience.

Responsiveness

The fixed card layout uses padding on both sides. The cards are displayed inside collapsible columns, making the page fully responsive. When the user resizes the browser or uses a smaller screen, the columns containing the cards collapse. To view all the cards, the user just scrolls down. In this way, the layout can accommodate typical laptop screens, larger desktop monitors, and mobile devices.

The width of the cards is tied to the column width. Breakpoints for the different screen resolutions determine whether the column width is 20 or 25 rem. The cards inside the columns adapt their width and content automatically. By contrast, the height of the cards is flexible, and depends on the content and type of card (see Card Sizes per Type).

  • Phone: 1 column
  • Tablet (portrait): 2 columns
  • Laptop / tablet (landscape): 3 columns
  • Large desktop: 4 columns
  • Extended monitor: 5 columns (maximum)
Fixed card layout – Size S
Fixed card layout – Size S
Fixed card layout – Size M
Fixed card layout – Size M
Fixed card layout – Size L
Fixed card layout – Size L

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Overview Page (SAP Fiori Element)

View, Filter, and Take Immediate Action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page.

The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

At a Glance

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Micro actions let users react on the spot

Overview page – Fixed card layout
Overview page – Fixed card layout

Usage

Use the overview page if:

  • You want to provide an entry-level view of content related to a specific domain or role.
  • Users needs to filter and react to information from at least two different applications to complete their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page.
  • You plan to have at least three cards. These cards should not all be of the same type.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page instead.
  • You want to show information about one object only. In this case, use the object page instead.
  • You just represent one application and less than three cards. In this case, use the object page instead.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

As you can see in the picture, the overall content scope (shown in gray) becomes more focused with each interaction step. An overview page brings together information from different sources that support a specific task or information need. Only provide an overview app for a role if it makes sense to do so.

If a role or user has several main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, with information for managing team performance reviews. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that the user is responsible for in the role of quality manager.

Metaphor – Different entry points in SAP Fiori
Metaphor – Different entry points in SAP Fiori

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps. In addition, users can also access the navigation menu in the shell bar, which allows fast and easy navigation to other apps. The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window.

In the screen flow, always position the overview page app between the SAP Fiori launchpad home page and the SAP Fiori app. The overview page doesn’t replace the SAP Fiori launchpad home page. Never start overview page apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards.

The card layout determines the size and position of the cards.
Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

The overview page can consume four different variants of the dynamic page. These variants support different user needs and provide flexibility for application designers. None of the variants include the footer toolbar.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar. In addition, the variant management control lets users share user-defined variants (Save View feature).

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. The initial default uses the collapsed mode, because content is already available on the cards, and users can start right away. When the user scrolls or clicks, the header content expands as defined. The header title offers the Share menu, which enables the actions „Send Email“ and „Save as Tile“.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text (“Header Title” in the example below). This text serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M

Variant 4 – Text in the Header Title and Smart Filter Bar

In this variant, the header title contains a text (“Header Title” in the example below), and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M

Overview Page Layout

The fixed card layout describes the position, size, and characteristics of cards in the content area below the dynamic page header. The layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes.

Only place cards on the overview page. Never add tiles.

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the user actions menu under Manage Cards. A dialog appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Each overview page app has its own Manage Cards setting. Users who work with several overview pages can personalize the cards shown for each one.

Overview page – 'Manage cards' dialog after initial loading
Overview page – 'Manage cards' dialog after initial loading

Cards

Overview page – Variety of different card types (extract)
Overview page – Variety of different card types (extract)

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. The overview page can contain several cards that reference the same (parent) application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Cards can display different types of content. They can show a chart, a list, a table, informative text, or a combination of two elements.  However, cards never have editable fields.

When designing cards, make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

For more information about cards and card types, see the dedicated articles:

Best Practices

Before you start designing an overview page, familiarize yourself with following best practices to optimize the user experience. They reflect the basic findings of multiple usability tests across different scenarios and user groups.

  • Make a conscious decision on the number of cards: Show only cards that really support the specific role context or task.
  • Accentuate the most important information: Semantic colors in texts, charts, and images attract more attention.
  • Offer a well-balanced mixture of card types: Diversity makes it easy to recognize, select, and read information.
  • Define a deliberate card order: Users assume that cards at the top of the page are more important than others.
  • Group similar topics: Users assume that related cards will be shown next to each other.
  • Choose easy-to-read and actionable texts: If the user needs to take action, use the active voice (for example “Reorder Soon” when stocks are running low).
  • Be semantically consistent: Users expect crucial terms like „urgent“ or “out of stock” to be highlighted with semantic colors.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

List Report Floorplan

Information
This article contains general guidelines for the list report floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki. You can also refer to the SAP Fiori elements feature map to see which controls and capabilities are supported for list reports.

Intro

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items within a large set of items by searching, filtering, sorting, and grouping.
  • Users need to display the whole dataset using different visualizations (for example, as a table or as a chart), without requiring interactions between these visualizations. An example use case might be reporting.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. Views can be switched using tabs, segmented buttons, or a select control.
  • Drilldown is rarely or never used, or is only available via navigation to another page, and not as free or flexible drilldown within the page itself.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, and the item or an identifying data point is known to the user (such as a barcode). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the worklist floorplan instead.
  • Users need to extract knowledge or insights from data, either to better understand the current situation, or to identify the root cause for a certain value.  Use the analytical list page instead.
  • Charts are not only used for visualization. Users need to switch between integrated chart and table views (hybrid view). Use the analytical list page instead.
  • Users need to see the impact of their action on a KPI. Use the analytical list page instead.
  • Users need to see not only the result, but also the impact of their filter settings directly in a chart representation. Use the analytical list page instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions, such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a chart, you can display the chart on its own (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.
Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Header Title

Variant Management

Variant management is optional. If you use variants, apply them to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before the dataset is updated. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the format Filtered By (x): followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use the header toolbar for non-finalizing global actions, such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

Header Content

Search

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search terms and the filter criteria.

The search generally searches across all available columns of the table, regardless of whether or not they are visible. In rare cases, some columns might not be included due to technical constraints. If the search does not apply to multiple columns, do not offer the search field.

Filters

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

Since the list report loads automatically when the page loads, ensure that mandatory filter fields always have default values to avoid error messages.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

The header content collapses when the user scrolls down the page (with a responsive table, list, or tree only), and expands again when the user scrolls back up. To avoid this automatic expand/collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.

Users can expand and collapse the header content manually by clicking the background of the title bar. The dynamic page header can also be expanded/collapsed using the Collapse Header ( ) and Expand Header ( ) arrows at the bottom of the header area.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title.

When starting the application, expand the header content if no query was fired (and the table is therefore empty). Otherwise, collapse the header content.

Header Content - Expand / Collapse Behavior

  • List Report - Collapsed Filter Bar

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. Multiple views involve one or more of the following:

  • Showing the same table, but with different columns.
  • Showing the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

There are two options for switching between different views:

The first option is to replace the table title with a content switch. Use this approach if all views share the same sort and group states, as well as the same actions.

The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country/Region, View by Customer, …)

The second option for switching views is to show each view in a tab container of the icon tab bar. Use this approach if all views show different states of the same data (sort states, group states, as well as item selection). Using tabs also allows you to offer different actions on the table toolbar for each view.

Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items are selected, or if the action cannot be applied to the selected items. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are no items to display, use the “no data” text of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    To start, set the relevant filters.
  • The filter was executed, but no items were found. This can also happen if the list report was opened by a related app, and the filter criteria were transferred automatically:
    No data found. Try adjusting the filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is being used for a different target.
    Only show navigation indicators for target pages the user is authorized to access.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer toolbar
Footer toolbar

Actions

Places for actions in the list report
Places for actions in the list report

(1) Global actions in the header toolbar
(2) Table actions in the table toolbar
(3) Line item actions
(4) Finalizing actions in the footer toolbar

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

If you are using an icon tab bar, be aware that each tab contains its own table toolbar.

When to Enable, Disable, or Hide Actions

Indicate whether an action is available. Some actions are always available (such as Create for new objects). Other actions are only relevant if items have been selected (for example, Edit at item level, Remove, object-specific actions, or actions that change the status of an item).

Enable the following actions:

  • All Add/Create actions, unless the user needs to specify where in the table the new item should be added.
  • Edit actions that switch the entire table to edit mode (independent of the selected items).
    If the user triggers the Edit button, replace it with Save and Cancel buttons (see Editing the Whole Table).
  • Item-dependent actions that can be applied to some or all of the selected items.

Disable the following actions:

  • Item-dependent actions when no items have been selected.
  • Add/Create actions where the user needs to specify the insert position in the table, but either no item has been selected, or more than one item has been selected.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information, also see UI Element States – Control States.

Partial Processing

Enable the user to apply the changes to as many of the selected items as possible.

If an action can’t be applied to all selected items, show a warning message before executing the action:

  • Indicate the number of selected items that can’t be processed (out of the total number of selected items).
  • Give a reason why the action can’t be applied to these items.
  • Let the user choose whether to apply the action to the remaining items anyway or cancel the action.

See an example here.

Note: In some scenarios, you might not be able to identify whether an action can be applied to all selected items before executing it. If the system is unable to apply the action to all items, show a message after executing the action.

Sort, Group, Personalization

Decide if you need to provide a sorting, grouping or personalization for your use case. If you offer more than one of these actions, offer them as single actions. We recommend keeping them in the following order: Sort, Group, Personalization.

More Information

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or the line item is in the wrong state.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

List Report Floorplan

Information
This article contains general guidelines for the list report floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki. You can also refer to the SAP Fiori elements feature map to see which controls and capabilities are supported for list reports.

Intro

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items within a large set of items by searching, filtering, sorting, and grouping.
  • Users need to display the whole dataset using different visualizations (for example, as a table or as a chart), without requiring interactions between these visualizations. An example use case might be reporting.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. Views can be switched using tabs, segmented buttons, or a select control.
  • Drilldown is rarely or never used, or is only available via navigation to another page, and not as free or flexible drilldown within the page itself.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, and the item or an identifying data point is known to the user (such as a barcode). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the worklist floorplan instead.
  • Users need to extract knowledge or insights from data, either to better understand the current situation, or to identify the root cause for a certain value.  Use the analytical list page instead.
  • Charts are not only used for visualization. Users need to switch between integrated chart and table views (hybrid view). Use the analytical list page instead.
  • Users need to see the impact of their action on a KPI. Use the analytical list page instead.
  • Users need to see not only the result, but also the impact of their filter settings directly in a chart representation. Use the analytical list page instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions, such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a chart, you can display the chart on its own (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.
Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Header Title

Variant Management

Variant management is optional. If you use variants, apply them to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before the dataset is updated. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the format Filtered By (x): followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use the header toolbar for non-finalizing global actions, such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

Header Content

Search

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search terms and the filter criteria.

The search generally searches across all available columns of the table, regardless of whether or not they are visible. In rare cases, some columns might not be included due to technical constraints. If the search does not apply to multiple columns, do not offer the search field.

Filters

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

The header content collapses when the user scrolls down the page (with a responsive table, list, or tree only), and expands again when the user scrolls back up. To avoid this automatic expand/collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.

Users can expand and collapse the header content manually by clicking the background of the title bar. The dynamic page header can also be expanded/collapsed using the Collapse Header ( ) and Expand Header ( ) arrows at the bottom of the header area.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title.

When starting the application, expand the header content if no query was fired (and the table is therefore empty). Otherwise, collapse the header content.

Header Content - Expand / Collapse Behavior

  • List Report - Collapsed Filter Bar

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. Multiple views involve one or more of the following:

  • Showing the same table, but with different columns.
  • Showing the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

There are two options for switching between different views:

The first option is to replace the table title with a content switch. Use this approach if all views share the same sort and group states, as well as the same actions.

The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country/Region, View by Customer, …)

The second option for switching views is to show each view in a tab container of the icon tab bar. Use this approach if all views show different states of the same data (sort states, group states, as well as item selection). Using tabs also allows you to offer different actions on the table toolbar for each view.

Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items are selected, or if the action cannot be applied to the selected items. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are no items to display, use the “no data” text of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    To start, set the relevant filters.
  • The filter was executed, but no items were found. This can also happen if the list report was opened by a related app, and the filter criteria were transferred automatically:
    No data found. Try adjusting the filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is being used for a different target.
    Only show navigation indicators for target pages the user is authorized to access.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer toolbar
Footer toolbar

Actions

Places for actions in the list report
Places for actions in the list report

(1) Global actions in the header toolbar
(2) Table actions in the table toolbar
(3) Line item actions
(4) Finalizing actions in the footer toolbar

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

If you are using an icon tab bar, be aware that each tab contains its own table toolbar.

When to Enable, Disable, or Hide Actions

Indicate whether an action is available. Some actions are always available (such as Create for new objects). Other actions are only relevant if items have been selected (for example, Edit at item level, Remove, object-specific actions, or actions that change the status of an item).

Enable the following actions:

  • All Add/Create actions, unless the user needs to specify where in the table the new item should be added.
  • Edit actions that switch the entire table to edit mode (independent of the selected items).
    If the user triggers the Edit button, replace it with Save and Cancel buttons (see Editing the Whole Table).
  • Item-dependent actions that can be applied to some or all of the selected items.

Disable the following actions:

  • Item-dependent actions when no items have been selected.
  • Add/Create actions where the user needs to specify the insert position in the table, but either no item has been selected, or more than one item has been selected.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information, also see UI Element States – Control States.

Partial Processing

Enable the user to apply the changes to as many of the selected items as possible.

If an action can’t be applied to all selected items, show a warning message before executing the action:

  • Indicate the number of selected items that can’t be processed (out of the total number of selected items).
  • Give a reason why the action can’t be applied to these items.
  • Let the user choose whether to apply the action to the remaining items anyway or cancel the action.

See an example here.

Note: In some scenarios, you might not be able to identify whether an action can be applied to all selected items before executing it. If the system is unable to apply the action to all items, show a message after executing the action.

Sort, Group, Personalization

Decide if you need to provide a sorting, grouping or personalization for your use case. If you offer more than one of these actions, offer them as single actions. We recommend keeping them in the following order: Sort, Group, Personalization.

More Information

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or the line item is in the wrong state.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Overview Page (SAP Fiori Element)

View, Filter, and Take Immediate Action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page.

The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

At a Glance

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Micro actions let users react on the spot

Overview page
Overview page

When to Use

Use the overview page if:

  • You want to provide an entry-level view of content related to a specific domain or role.
  • Users needs to filter and react to information from at least two different applications to complete their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page.
  • You plan to have at least three cards. These cards should not all be of the same type.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page.
  • You want to show information about one object only. In this case, use the object page.
  • You just represent one application and less than three cards. In this case, use the object page.

SAP Fiori Launchpad Home Page, Overview Page, and Object Page

The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

As you can see in the picture, the overall content scope (shown in gray) becomes more focused with each interaction step. An overview page brings together information from different sources that support a specific task or information need. Only provide an overview app for a role if it makes sense to do so.

If a role or user has several main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, with information for managing team performance reviews. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that the user is responsible for in the role of quality manager.

Metaphor – Different entry points in SAP Fiori
Metaphor – Different entry points in SAP Fiori

Components

The basic structure and appearance of the overview page is governed by the dynamic page layout, and is divided into a header area and a content area.

This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards.

Two different layouts are available, which determine the size and position of the cards: fixed card layout and resizable card layout.

Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

The dynamic page header comprises the header title and expandable/collapsible header content. Three different header variants are available for overview pages. 

In the overview page, the header content is used for the smart filter bar with the live update mode (variant 1 and variant 2): the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar.

Users can expand/collapse and pin the header content with the two icon buttons below the smart filter bar:

  1. Expand/collapse header:  or   
  2. Pin/unpin header content:  

Dynamic Page Variants for the Overview Page

The header title (either text or variant management) is mandatory, while the header content (smart filter bar) is optional. Variant 3 shows only a text in the header title.

Variant 1 Variant 2 Variant 3
Dynamic page header Yes Yes Yes
Header title Variant Management Text Text
Header content Smart Filter Bar Smart Filter Bar –
Page content Cards Cards Cards

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management and the header content includes the smart filter bar. The initial default uses the collapsed mode, because content is already available on the cards, and users can start right away. When the user scrolls or clicks, the header content expands as defined. The header title offers the Share menu, which enables the actions Send Email and Save as Tile.

Dynamic page variant 1 – Expanded mode
Dynamic page variant 1 – Expanded mode

Variant 2– Text in the Header Title and Smart Filter Bar

In this variant, the header title contains a text (Header Title in the example below) and the header content area contains the smart filter bar. The initial default uses the collapsed mode, because content is already available on the cards, and users can start right away. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 2 – Expanded mode
Dynamic page variant 2 – Expanded mode

Variant 3 – Text in the Header Title

In the third variant, the header title contains a text (Header Title in the example below). This text serves the same purpose as the former page subtitle. The header content is empty (auto hidden) and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 3 – Expanded/collapsed mode
Dynamic page variant 3 – Expanded/collapsed mode

Overview Page Layout

Fixed card layout
Fixed card layout
Resizable card layout
Resizable card layout

The overview page layout describes the position, size, and characteristics of cards in the content area below the dynamic page header.

There are two layout variants:

Only place cards on the overview page. Never add tiles.

Fixed Card Layout vs. Resizable Card Layout

Fixed Card Layout Resizable Card Layout
Fixed card width and predefined height Resizable card sizes (grid-based)
Users can’t influence the card size Users can influence the card size individually
Predefined static card characteristics Flexible content insights (such as more items, zoom, or different levels of detail)
Lower implementation effort – defined card patterns Higher implementation effort – content strategy required
Self-contained cards Highly interactive and flexible cards
Fast overview and navigation Fast overview, navigation, and investigation
Cards can be swapped Drag and drop supported for cards
Maximum of 5 card columns (letterboxing) Unlimited number of columns

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the user actions menu under Manage Cards. A dialog appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Each overview page app has its own Manage Cards setting. Users who work with several overview pages can personalize the cards shown for each one.

Overview page – 'Manage Cards' dialog after initial loading
Overview page – 'Manage Cards' dialog after initial loading

Behaviour and Interaction 

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps. In addition, users can also access the navigation menu in the shell bar, which allows fast and easy navigation to other apps. The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new browser window.

In the screen flow, always position the overview page app between the SAP Fiori launchpad home page and the SAP Fiori app. The overview page doesn’t replace the SAP Fiori launchpad home page. Never start overview page apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Cards

Overview page – Different card types (selection)
Overview page – Different card types (selection)

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. The overview page can contain several cards that reference the same underlying application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Cards can display different types of content. They can show a chart, a list, a table, informative text, or a combination of two elements. Cards can also vary in size, depending on the selected layout. However, cards never have editable fields.

When designing cards, make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

For more information about cards and card types, see the dedicated topics:

Responsivess

The overview page is fully responsive and can accommodate typical laptop screens as well as larger desktop monitors. The responsive behaviour differs for the two layout types – fixed card layout and the resizable card layout.

Both feature responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes. For more information on each card type, follow the respective links.

Top Tips

Before you start designing an overview page, familiarize yourself with following best practices to optimize the user experience. They reflect the basic findings of multiple usability tests across different scenarios and user groups.

  • Make a conscious decision on the number of cards: Show only cards that really support the specific role context or task.
  • Accentuate the most important information: Semantic colors in texts, charts, attract more attention. The same applies to larger cards.
  • Offer a well-balanced mixture of card types: Diversity makes it easy to recognize, select, and read information.
  • Define a deliberate card order: Users assume that bigger cards and cards at the top of the page are more important than others.
  • Group similar topics: Users assume that related cards will be shown next to each other.
  • Choose easy-to-read and actionable texts: If the user needs to take action, use the active voice (for example “Reorder Soon” when stocks are running low).
  • Be semantically consistent: Users expect crucial terms like “Urgent” or “Out of Stock” to be highlighted with semantic colors.

Related Links

Elements and Controls

Implementation

Overview Page – Resizable Card Layout

Unlimited Possibilities for Designing Cards 

The resizable card layout is a layout for the overview page. It enables users to define a personalized card layout by changing not only the position of a card, but also its size, and thus how the card content is presented.

This layout gives users much greater flexibility in tailoring the overview page to their specific business needs. And it allows app teams to offer varying levels of detail for any given card. Whenever the size of a card changes, the content adapts automatically to show the most relevant information in the available space.

At a Glance

  • Flexible card dimensions (grid-based)
  • More flexibility to define individual card layouts
  • Responsive and adaptive card content
  • Applying progressive disclosure principles
Overview page – Resizable card layout
Overview page – Resizable card layout

Unlike the fixed card layout, cards in the resizable card layout do not have fixed dimensions. In addition, the number of columns in the resizable layout is no longer limited (also see letterboxing).

The cards are positioned on an underlying grid, making it possible to arrange and resize cards in a flexible, yet guided manner. You can offer different views of the card content for different dimensions of the various card types. For example, you can show more items, zoom in or out, or change the granularity of a dataset.

The resizable card layout does not replace the fixed card layout.

Usage

Use the resizable card layout if:

  • You want to give users the flexibility to rearrange and adapt their overview page as they need.
  • You want to help users focus by applying progressive disclosure principles.
  • You want to make use of different card sizes.
  • You want to show more content (for example, more items or an additional level of detail)

Do not use the resizable card layout if:

  • Your card content doesn’t react properly to a change in size. Use the fixed card layout instead.
  • You are not able to invest UX and development resources for creating and prioritizing additional content. Use the fixed card layout instead.
  • You want to use the resizing functionality on mobile devices. Resizing and rearranging cards is currently not possible on mobile devices.

Flexible Card Sizes

Grid

Cards can be increased and decreased vertically in rows of 1 rem and horizontally in steps of 20 rem (minimum width). These dimensions facilitate both a high degree of flexibility and measured guidance. The card content responds immediately to a change in size.

The grid provides a guided resizing and repositioning experience. This ensures that the cards are always correctly aligned on the overview page as the user moves or resizes them.

Resizable card layout – Grid
Resizable card layout – Grid

Card Anatomy

A card is made up of a mandatory header and a content area.

Mini Header

The smallest representation of the card is the header. The card can be collapsed to only its header height. We call this the “mini header” card height.

Mini Content

The “mini content” height of a card is defined by the next suitable size for a card when it is resized. The minimum height for the card content depends on the card type, and must be as high as the smallest representation of the content. In a list card, for example, first list item needs to fit in.

To avoid states with cut or unsubstantial content, there are no resizing steps between mini header and mini content.

Card anatomy
Card anatomy
Minimum heights for a card in the resizable card layout
Minimum heights for a card in the resizable card layout
Example of Card Sizes
Example of Card Sizes

Dealing with White Space

If no additional content is available, the user still can make the card bigger, resulting in white space.

Resizing Parameters

The card content depends on the available space, which in turn determines how many items are shown, how each item is displayed, and the level of detail (granularity). How the content is resized depends on the type of card. For example, table cards can have fewer columns when the size of the card is decreased. By contrast, the content shown for each item on list cards remains the same.

Space

When a card is resized, the content adapts responsively. 

Example: List card
When the size of a card is reduced, texts might be truncated or wrapped. When the card size is increased again, the text is shown in full and previously wrapped text moves back onto one line. The line item content itself is unchanged.

Resizing for a list card
Resizing for a list card

Items

When you increase the size of a list or table card, more line items are shown.

Resizing for a table card
Resizing for a table card

Granularity

If you increase the size of an analytical card, more data points are revealed. In this example, the donut chart on the larger card shows more individual product categories.

Resizing for an analytical card (donut chart)
Resizing for an analytical card (donut chart)

Rearranging Cards – Behavior

When a user long presses on a card instead of just clicking, the mouse cursor changes to indicate that the card can be dragged. Cards can be dragged from both the header and content areas. 

Cards always strive towards the top of the page (uplift mode). When you move or stretch cards horizontally, the existing cards you displace are pushed downwards.

Resizing cards / rearranging cards using drag and drop
Resizing cards / rearranging cards using drag and drop

Getting Started

UX and DEV Investment Required

To enable users to benefit fully from the resizable card functionality, you need to define additional content that is revealed progressively as the card size grows. You will need to develop a content strategy to prioritize the chunks of information for each card type, and hence the order in which these additional chunks of information appear. For instance, the content strategy for a table card should answer the following questions:

  • What should be the initial size of the card in the layout?
  • Which table columns do you want to show in the card with the minimum width?
  • Which table columns do you want to add when the card width is increased by one, two, three, … horizontal steps?

Keep in mind that the overview page is an SAP Fiori element.

Developer Hint
If you want to enable the resizable card layout for an existing overview page with the fixed card layout, consider the investment you’ll need to make in additional and meaningful content.

Set Initial Card Sizes

Set an initial order and initial dimensions for each card as a default. Do this for the mini header, the mini content, and for bigger card sizes. In cards with content, define the exact number of items included in the content area.

Consider the best practices for designing an overview page and the principles for resizing the cards. It’s important to provide a meaningful starting point for users. If users change the card size or order, the initial app default can always be restored using the Manage Cards setting in the user actions menu.

Important: Do not provide only mini headers in the initial layout for your overview page.

Block Card Resizing

App teams can block the resize feature for each card individually. In this case, the cards can’t be resized by users and the resize icon is not shown on the card. Use this feature judiciously and only if you really have to. The majority of cards should be resizable. Otherwise, users are likely to be confused, and might feel driven to check the resizing behavior for each card.

Alternative approach

If you want to make use of the different card sizes, but don’t want to allow resizing for users at all, you can block the resizing function for all cards (independently of the initial card size). This allows you to use different card sizes and the same (limited) personalization features as in the fixed card layout. Because none of the cards are resizable, users won’t be confused.

Letterboxing

The resizable card layout uses different letterboxing behavior than the fixed card layout: to handle different card sizes more flexibly, the resizable card layout does not have a fixed number of columns. Cards take up the the available screen real estate and adapt accordingly (also see responsiveness). As a result, larger screens can be almost completely filled.

Responsiveness

Information
Resizing is not supported on mobile devices. However, users can resize cards freely in smaller windows on a desktop device.

UI controls inside the cards react responsively when cards are resized. On mouse-release, additional content might be loaded, or content might be removed to reflect the new dimensions.

The number of grid columns in the layout is dependent on the width of the browser window. The breakpoints are defined as follows:

Width of Browser Window Number of Card Columns Displayed
Less than 656 px 1 column
656 – 975 px 2 columns
976 – 1359 px 3 columns
1360 – 1679 px 4 columns
1680 – 1999 px 5 columns
More than 2000 px 6 columns or more

There is no limitation to the number of columns. You can also design for bigger screens.

Resizable card layout – Size L
Resizable card layout – Size L
Resizable card layout – Size M
Resizable card layout – Size M
Resizable card layout – Size S
Resizable card layout – Size S

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Overview Page – Fixed Card Layout

Self-Contained Cards

The fixed card layout is a layout for the overview page. It comes with predefined card characteristics that support automatic, easy and fast card design. The cards have a fixed width, and the height is determined by the card type and the embedded control.

The cards are ordered in responsive and collapsible columns. The number of columns is also fixed to keep the focus on the middle of the screen and show the set of cards in a compact display (a kind of letterboxing). For more information, see Responsiveness.

The fixed card layout is one of two layout options for the overview page. The other is the resizable card layout.

Before you start designing cards for an overview page, see the best practices.

At a Glance

  • Easy and fast card design using predefined card framework

  • Fixed card width and predefined height

  • Arbitrary card order

Overview page – Fixed card layout
Overview page – Fixed card layout

Fixed Card Sizes

Grid

The grid is based on rows and columns. The spacing of 1 rem between the cards is always stable. Furthermore, there is a minimum width of 20 rem per card (corresponding to the column width). The columns with the cards adapt to the available screen real estate (also see Responsiveness).

Based on the underlying grid, users can rearrange the cards (see Rearranging Cards – Behavior).

Fixed card layout – Grid
Fixed card layout – Grid

The cards are arranged as a “Z” flow: cards are ordered from left to right, starting with the first card on the top left of the page. For example, if a 5-column layout is reduced to 4-column layout, the fifth card drops to the next row, assuming the leftmost position underneath the first card.

There is no limit on the number of cards included. However, be careful not to overwhelm your users.

For general information on cards, see Cards.

Fixed card layout – Z flow
Fixed card layout – Z flow

Card Sizes per Type

The card size is determined by the predefined card characteristics and maximum content for a given card type. As a result, the card types differ in height. The stack card and corresponding quick view card are handled independently.

List Card

The height of list cards can vary, depending on the number of text fields. Show no more than five standard list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Standard list item
Standard list item
Extended list item
Extended list item

Bar Chart List Card

The height of  bar chart list cards can vary, depending on the number of text fields. Show no more than five standard/condensed list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Standard list item
Standard list item
Condensed list item
Condensed list item
Extended list item
Extended list item

Link List Card (Variant Type “List”)

The link list card with the variant type “list”  is limited to a maximum of six links. There is no limit to the number of links for the variant type “image”.

Table Card

The height of table cards can vary, depending on the number of table cells. Tables are limited to a maximum of 3 columns and 3 rows, with a maximum of 3 lines of text per row. To see the full result set, the user needs to navigate to the parent app.

Rearranging Cards – Behavior

Drag and Drop

Users can reposition cards on the overview page by dragging them to a different location. As the user drags a card, it swaps places with any cards in its path. As soon as a neighbouring card is touched, the position of that card becomes the new target location for the card being dragged. A dashed line offers a preview of the new position.

To drag a card, the user has to long press on a card instead of just clicking. It doesn’t matter where the cursor is positioned – cards can be dragged from both the header and content areas. The mouse cursor also changes to indicate that the card can be dragged. Releasing the mouse or lifting the finger from the touch surface completes the move. To avoid gaps, cards always snap to the next free space in the row, or to the start of the next row.

In addition, users can personalize their own overview page by hiding cards.

Fixed card layout – Drag and drop
Fixed card layout – Drag and drop

Getting Started

In the fixed card layout, you can’t influence the amount of information on each card. However, you can define the card order. Before you design your overview page, take a look at the best practices, which outline how to best use cards for an optimal user experience.

Responsiveness

The fixed card layout uses padding on both sides. The cards are displayed inside collapsible columns, making the page fully responsive. When the user resizes the browser or uses a smaller screen, the columns containing the cards collapse. To view all the cards, the user just scrolls down. In this way, the layout can accommodate typical laptop screens, larger desktop monitors, and mobile devices.

The width of the cards is tied to the column width. Breakpoints for the different screen resolutions determine whether the column width is 20 or 25 rem. The cards inside the columns adapt their width and content automatically. By contrast, the height of the cards is flexible, and depends on the content and type of card (see Card Sizes per Type).

  • Phone: 1 column
  • Tablet (portrait): 2 columns
  • Laptop / tablet (landscape): 3 columns
  • Large desktop: 4 columns
  • Extended monitor: 5 columns (maximum)
Fixed card layout – Size S
Fixed card layout – Size S
Fixed card layout – Size M
Fixed card layout – Size M
Fixed card layout – Size L
Fixed card layout – Size L

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Overview Page (SAP Fiori Element)

View, Filter, and Take Immediate Action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page.

The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

At a Glance

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Micro actions let users react on the spot

Overview page
Overview page

Usage

Use the overview page if:

  • You want to provide an entry-level view of content related to a specific domain or role.
  • Users needs to filter and react to information from at least two different applications to complete their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page.
  • You plan to have at least three cards. These cards should not all be of the same type.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page instead.
  • You want to show information about one object only. In this case, use the object page instead.
  • You just represent one application and less than three cards. In this case, use the object page instead.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

As you can see in the picture, the overall content scope (shown in gray) becomes more focused with each interaction step. An overview page brings together information from different sources that support a specific task or information need. Only provide an overview app for a role if it makes sense to do so.

If a role or user has several main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, with information for managing team performance reviews. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that the user is responsible for in the role of quality manager.

Metaphor – Different entry points in SAP Fiori
Metaphor – Different entry points in SAP Fiori

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps. In addition, users can also access the navigation menu in the shell bar, which allows fast and easy navigation to other apps. The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window.

In the screen flow, always position the overview page app between the SAP Fiori launchpad home page and the SAP Fiori app. The overview page doesn’t replace the SAP Fiori launchpad home page. Never start overview page apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards.

Two different layouts are available, which determine the size and position of the cards: fixed card layout and resizable card layout.

Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

The overview page can consume four different variants of the dynamic page. These variants support different user needs and provide flexibility for application designers. None of the variants include the footer toolbar.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar. In addition, the variant management control lets users share user-defined variants (Save View feature).

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. The initial default uses the collapsed mode, because content is already available on the cards, and users can start right away. When the user scrolls or clicks, the header content expands as defined. The header title offers the Share menu, which enables the actions „Send Email“ and „Save as Tile“.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text (“Header Title” in the example below). This text serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M

Variant 4 – Text in the Header Title and Smart Filter Bar

In this variant, the header title contains a text (“Header Title” in the example below), and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M

Overview Page Layout

Fixed card layout
Fixed card layout
Resizable card layout
Resizable card layout

The overview page layout describes the position, size, and characteristics of cards in the content area below the dynamic page header.

There are two layout variants:

The fixed and resizable card layouts are fully responsive and can accommodate typical laptop screens as well as larger desktop monitors. Both feature responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes. For more information on each card type, follow the respective links.

Only place cards on the overview page. Never add tiles.

Fixed Card Layout vs. Resizable Card Layout

Fixed Card Layout Resizable Card Layout
Fixed card width and predefined height Resizable card sizes (grid-based)
Users can’t influence the card size Users can influence the card size individually
Predefined static card characteristics Flexible content insights (such as more items, zoom, or changed granularity)
Lower implementation effort – defined card patterns Higher implementation effort – content strategy required
Self-contained cards Highly interactive and flexible cards
Fast overview and navigation Fast overview, navigation, and investigation
Cards can be swapped Drag and drop supported for cards
Maximum of 5 card columns (letterboxing) Unlimited number of columns

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the user actions menu under Manage Cards. A dialog appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Each overview page app has its own Manage Cards setting. Users who work with several overview pages can personalize the cards shown for each one.

Overview page – 'Manage cards' dialog after initial loading
Overview page – 'Manage cards' dialog after initial loading

Cards

Overview page – Variety of different card types (extract)
Overview page – Variety of different card types (extract)

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. The overview page can contain several cards that reference the same (parent) application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Cards can display different types of content. They can show a chart, a list, a table, informative text, or a combination of two elements.  However, cards never have editable fields.

When designing cards, make sure that you define and format the texts on all the cards consistently.

For more information about cards and card types, see the dedicated articles:

Best Practices

Before you start designing an overview page, familiarize yourself with following best practices to optimize the user experience. They reflect the basic findings of multiple usability tests across different scenarios and user groups.

  • Make a conscious decision on the number of cards: Show only cards that really support the specific role context or task.
  • Accentuate the most important information: Semantic colors in texts, charts, and images attract more attention.
  • Offer a well-balanced mixture of card types: Diversity makes it easy to recognize, select, and read information.
  • Define a deliberate card order: Users assume that cards at the top of the page are more important than others.
  • Group similar topics: Users assume that related cards will be shown next to each other.
  • Choose easy-to-read and actionable texts: If the user needs to take action, use the active voice (for example “Reorder Soon” when stocks are running low).
  • Be semantically consistent: Users expect crucial terms like „urgent“ or “out of stock” to be highlighted with semantic colors.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

Overview Page – Card

Cards – Harmonized and Powerful Information

Each task or topic on an overview page is represented by a card. The overview page acts as a UI framework for organizing multiple cards for one role on a single page .

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. Technically, a card is a smart component that uses UI annotations to render its content. Cards allow you to show application content from different sources side by side – without requiring the user to switch screens. Cards differ in the content they display: They can show a chart, a list, a table, informative text, or a combination of two elements. However, cards never have editable fields.

Cards can focus on a single object or topic, or on a group of objects. 

The overview page can contain several cards that reference the same (parent) application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Before you start designing cards for an overview page, see the best practices.

At a Glance

  • Cards are small previews of application content.
  • Each card represents a specific topic, task, or perspective.
  • Cards help users to focus by applying progressive disclosure principles.
  • Cards are powerful and beautiful.
  • Cards offer a variety of visualizations.
Overview page with different card types (extract)
Overview page with different card types (extract)

Card Anatomy

Each card comprises two components: a header area and a content area. The header and content areas are mandatory. A footer area is only used for actions in the quick view card.

The interactive navigation in the header and content areas is represented by a hover effect.

When designing cards, make sure that you define and format the texts on all the cards consistently. For details , check out the UI text guidelines for the overview page.

Card anatomy
Card anatomy

Card Header

The card header area is mandatory, and serves three purposes:

  • It indicates what the card is about.
  • It functions as a navigation area for opening the parent app, whereby the whole header area is clickable. We highly recommend offering this navigation to enable users to move seamlessly to the app details without losing focus on the task in hand  (exception: link list card). 
  • A counter shows how many items are on the card in relation to the total number of relevant items.

The height of the header area is variable; it expands vertically to accommodate the text. The header area can contain two text fields: a mandatory title, and an optional subtitle. The primary purpose of the header area is to identify the content source, summarize the focus of the card (title), show any relevant parameters (subtitle), and offer navigation to the content source (parent app).

Title

The title is mandatory and represents the card’s “point of view”. In one or two words, it explains why this card exists and why a user might want to use it. It is a natural language reflection of the annotated view. Titles that exceed three lines are truncated with the ellipsis (…).

Subtitle

The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The use of the subtitle can differ, depending on the card type. Subtitles that exceed one line are truncated with the ellipsis (…).

Card header with counter
Card header with counter

Counter

The counter in the header area indicates how many items are showing on the card in relation to the total number of relevant items:

Format: [Items on Card] of [Total Items]
Example: 5 of 40 

The counter is right-aligned and is never truncated (the title wraps instead). The width of the counter is flexible, depending on the amount of data. [Items on Card] can show a maximum three digits, and [Total Items] a maximum of four digits. For larger numbers, a scaling factor is shown. If all the relevant items are visible on the card, no counter is shown. There is also no counter if there is an issue loading a card, or no items are found for the filter criteria.

In the resizable card layout, the card counter adapts to the card size. If the user increases the size of a card with a scaled counter, the counter shows the exact number of items (without the scaling factor). The scaling factor appears when values exceed 1000.

Card Content

The content area is mandatory and is reserved for application content. Content is currently displayed on cards by embedding SAPUI5 controls that specify the properties and data format. For example, an embedded standard list control provides formatting, such as row height, font sizes, and the number of text blocks.

The resizable card layout also has a special kind of the content area, called mini content. It describes the minimum height for the card content.

Card Types

The overview page supports the following standard card types:

Appearance

Texts in Cards

Make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

Formatting Dates, Times, Amounts, and Currencies

Apply the following formats:

  • Dates: The default is the relative date format (for example, Today). However, you can also use the medium date format (such as Aug 7, 2015).
  • Times: Times are not visible by default, but if you need to show a time, use the short format (for example, 11:28 AM).
  • Integers/Float/Currencies: Use the short format (for example, 1K for 1000).

Refresh Behavior

You can set a specific refresh interval for the card content. All cards are refreshed at once.

Keep the user in mind: the shorter the refresh interval, the more disruptive it is for users.

Navigation and Interaction

The navigation and interaction depends on the technical card type:

The view switch enables you to reduce the number of similar cards and avoid repeating information.

Single-Object Cards

Cards that feature content with a single focal point, detail, or entity are called single-object cards. An example is a quick view card with information about a particular product. Analytical cards are also single-object cards. The header area of this card type always navigates to this specific focal point, detail, or entity. The content area can also have interaction areas (for example, a section in a chart, or a telephone number for a contact). However, only quick view cards can have actions in the footer area.

Interaction for a single-object card
Interaction for a single-object card

Object Group Cards

Cards that feature a subset of items grouped by a common criterion are called object group cards. A typical example would be a list of purchase orders grouped by delivery date, amount, or supplier. The cards do not have actions, but each row or list item is selectable, thus providing direct navigation to the object details within the parent application. The header area of this card type always navigates to all items in the list or table. Object group cards include all types of list cards, bar chart list cards, and table cards.

Interaction for an object group card
Interaction for an object group card

Link List Cards

Link list cards allow you to display a collection of links or images that can reference both internal and external targets.

  • Links can navigate to a target or open a popover with additional information.
  • Clicking an image opens an image carousel.
Interaction for a link list card
Interaction for a link list card

Stack Cards

A stack card is a special card type for showing a collection of single-object cards. Stack cards have 3 components with different navigation areas:

  • The top-level stack card opens the collection and contains two clickable areas: the left area navigates to the parent app (with the list of all items), and the right area opens the object stream.
  • The object stream shows individual cards that represent objects from the parent application. The object stream heading links to the parent application, while individual cards can contain links and actions relating to the respective object. A Close button returns the user to the stack card.
  • The last card in the object stream is the placeholder card. The entire card is navigable and leads the user directly to the parent application.
Interaction for a stack card
Interaction for a stack card
Interaction for a placeholder card
Interaction for a placeholder card

View Switch

You can use a view switch to offer several different content areas on one card, which can help to reduce the number of cards on the overview page. The user chooses the view using a select control. You can only combine views that have a common denominator. The options offered by the select control merely offer different perspectives. For example, a card “Purchasing Spend” (title in the header area) could offer two views “By Material Group” and “By Supplier” (options in the select control). The view switch is located in the upper part of the content area.

You can use the view switch for the following cards:

View switch
View switch

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

  • No links

Overview Page – Custom Card

Adaption of standard cards

Custom cards allow you to define the appearance of a card on an overview page, and the type of content that appears in the card content area. They offer additional flexibility when you require features that are not offered by the standard cards for overview pages.

Information
Keep in mind:

  • A card is not a substitute for an application.
  • A card focuses on the most important task-related data. It lets the user view, filter, and react to information quickly.
  • The content must be defined for a specific context. Do not display irrelevant or unclear content.

Usage

Use a custom card if:

  • Your use case cannot be satisfied in any way by the standard cards provided for the overview page. Always consider the requirements below before using a custom card.

Do not use the custom card if:

  • You can satisfy your use case to a certain extent with the existing standard cards. Even if there are technical or visual limitations, stick with the standard cards if they are still workable for your scenario.
  • You are not using the overview page floorplan.

Standard Requirements

Custom cards must meet the standard SAP Fiori requirements, especially:

  • Responsiveness: Ensure that the cards can run on different devices (touch, mouse and keyboard), using breakpoints supported by SAPUI5.
  • Cozy/compact: Provide different control dimensions as described by the visual design. If your existing design already covers both use cases (mouse and touch input), you do not have to provide two different designs. For more information on cozy and compact form factors, see content density.
  • Theming: Custom designs must allow theming and use the LESS parameters provided by the official Belize theme. Implementation of the customized design must be tested in all themes (high-contrast white, high-contrast black, and Belize Deep).
  • Accessibility: Support keyboard navigation and screen readers (as stipulated by accessibility requirements).
  • Browsers: Support all types of browser.
  • Performance: Ensure the performance of the implementation is satisfactory.
Information
Be aware that implementing a custom card costs time and effort for development.

Components

Custom cards have two components:

  • A mandatory header area
  • A mandatory content area
Custom card – card components
Custom card – card components

Header Area

The title and subtitle of custom cards follow the guidelines for standard titles and subtitles.

From the header area, users can navigate to the parent app. Since the entire header area is clickable, only one navigation target is allowed. We highly recommend offering this navigation option to give users access to the full-blown app with the complete set of results and actions. If a card displays a subset of grouped items, use a text label to show how many of the relevant items are showing on the card. Also refer to the guidelines for the overview page card header.

If a card features content with a single focal point (detail/entity), the header area navigation must always lead to this specific focal point. If a card features a subset of items grouped by a common criterion, the header area navigation must always lead to all items.

Custom card – header area
Custom card – header area

Content Area

The content area is reserved for application content and shows an entry-level view of the content. The use case determines what should be shown in the content area of a custom card. The content must adhere to the standard content guidelines.

Make sure that the content is responsive.

Provide a stable context for the content area and sustain it when the user navigates away from the overview page into another app. Transfer any sort or filter criteria to the application. In other words, show the same context, but with additional information.

Custom card – content area
Custom card – content area

Card Size

Follow the guidelines for the fixed card layout or the resizable card layout. Make sure that the card is responsive whichever layout you use.

Guidelines

Custom cards inherit the drag and drop behavior from the standard cards. Only place custom cards on the overview page itself (not in the object stream).

Custom cards must:

  • Provide information that is relevant for the user’s specific domain or role
  • Offer an entry-level view of application content
  • Represent a single topic, task, or context
  • Provide a stable context and sustain it after navigating from the overview page to another application
  • Be integrated in the Manage Cards dialog (show/hide cards)
  • React on filtering (when a smart filter bar is used)
  • Follow the guidelines for formatting dates, times, amounts, currencies, as well as for truncation (ellipsis). These guidelines are the same as for standard cards.
  • Contain consistent texts and formatting, aligned with the other cards on the overview page. Check the UI text guidelines for the overview page for details.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Introduction to SAP Fiori Elements

SAP Fiori elements (formerly known as smart templates) provide a framework for the most common application patterns.

The application team selects the relevant floorplan and adds semantic and structural data using metadata annotations. The framework then generates the application screen.

SAP Fiori elements ensure design consistency and compliance with the latest design guidelines, while reducing the amount of frontend code needed to build SAP Fiori apps.

Information
SAP Fiori elements are part of the SAPUI5 delivery.
SAP Fiori elements – The production line for UIs
SAP Fiori elements – The production line for UIs

Supported Floorplans and Layouts

The following floorplans are available as SAP Fiori elements:

The SAP Fiori elements framework supports the dynamic page layout for all available floorplans. In addition, the flexible column layout is supported for all available floorplans except the overview page, which is not allowed within the flexible column layout.

SAP Fiori elements use the global edit flow, which includes draft handling, or the local edit flow without draft handling. SAP Fiori elements also offer message handling.

Overview page
Overview page
List report
List report
Worklist
Worklist
Analytical list page
Analytical list page
Object page
Object page

Usage

You can use the SAP Fiori elements framework if the floorplan and layout you need for your app design are supported. The overview page floorplan, analytical list page floorplan, dynamic page layout, and flexible column layout are all fully supported. If you want to use the object page or list report floorplans, check the respective guideline articles to see which features are supported for SAP Fiori elements.

If you want to use floorplans that are not supported by the SAP Fiori elements framework, or if you require several features that are not supported by the respective floorplan in SAP Fiori elements, you should go with a freestyle app instead.

One of the big benefits of SAP Fiori elements is the reduction in development effort. This is especially important for features like draft handling or the flexible column layout. If you need these features in your app, you should go with SAP Fiori elements.

For an overview of all available floorplans and layouts, see Overview – Layouts, Floorplans, and Frameworks.

For more information on when to use SAP Fiori elements, see the usage guide.

Responsiveness

The responsiveness of SAP Fiori elements depends on the responsiveness of the floorplans and controls used in your app.

The SAP Fiori elements framework lets you influence the responsiveness of certain controls. For example, you can adapt the overflow behavior of actions and fields in the overflow toolbar, or change the pop-in behavior of columns in a responsive table.

Developer Hint
You can use the priority annotation to influence the responsive behavior of certain controls. This annotation supports the values “high”, “medium”, and “low”.

Adjustments

The behavior and interaction generally follows the guidelines for the respective floorplan or concept. If the guideline offers choices, the SAP Fiori elements framework offers the most generic option or, where possible, provides different options to choose from.

For example, the default table for list reports is the responsive table (or, for aggregated services, the analytical table). Other table types are offered as well, but have to be actively enabled by the application developer.

Deviations from the guidelines are sometimes necessary due to technical limitations, which are listed in the respective guideline artices. These limitations are usually short term and will be solved in future releases.

Developer Hint
You can adjust certain features by implementing breakouts, by adapting the manifest.json of your app, or through annotations or UI adaptation.

Mandatory Adjustments

Some UI texts provided by the SAP Fiori element contain generic placeholders. Always replace the default placeholders with an application-specific text.

Developer Hint
For more information about placeholder texts in SAP Fiori elements, see Replacing Standard UI Texts.

Examples of generic and adjusted texts:

Default Text Adjusted Example
List Report Create Object Create Sales Order
Object Page New Object New Sales Order
Overview Page Could not perform action Unable to approve the request

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object Page Floorplan

Information
This article contains general guidelines for the object page floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki. You can also refer to the SAP Fiori elements feature map to see which controls and capabilities are supported for object pages.

Intro

The object page floorplan is used to display and categorize all relevant information about an object. Categorized content can be accessed quickly using anchor or tab navigation, and users can switch from display to edit mode to change the content. To create a new object, users can switch to create mode.

The object page floorplan comes with a flexible, responsive layout and a dynamic page header that can be adapted to display simple and complex business objects. This allows you to adjust the layout to a wide range of use cases.

Object page floorplan
Object page floorplan

Warning

  • Always build the object page using the dynamic page header and not the former object page header. Using the old object page header creates issues that can’t be fixed retrospectively. Using the dynamic header will also ensure consistency across all floorplans and provide greater flexibility. For details, see the Header section below.
  • Do not use the current implementation of the “page variant” feature in SAP Fiori elements. This feature is technically available for object pages, but we are still working on the final design.

When to Use

Use the object page floorplan if:

  • Users need to display, create, or edit an object.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

Use instead:
  • Users need to edit several items at the same time.
  • Users need to find relevant items without knowing the exact item details.
List report floorplan
  • Users need to be guided through a series of steps when a new object is created.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected.
 Wizard floorplan
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner).
 Initial page floorplan
  • Users need a way to analyze data step by step from different perspectives. They need to drill down to investigate a root cause and act on transactional content within one page.
  • Users need to interact with interdependent chart and table views (rather than using charts for visualization only).
 Analytical list page

Components

The object page consists of the following elements:

  • Dynamic page header (mandatory)
  • Navigation bar (optional)
  • Content area (mandatory)

The image below provides an overview of the object page components.

Schematic visualization of the object page
Schematic visualization of the object page
  1. Dynamic page header
  2. Navigation bar
  3. Content area
  4. Shell bar
  5. Breadcrumbs
  6. Global actions
  7. Header content
  8. Footer toolbar

The following sections explain these components in more detail.

Dynamic Page Header (mandatory)

The dynamic page header contains key information about the object and provides the user with the necessary context. The header also contains global actions for the object, such as Edit or Delete.

The header consists of the following elements:

  1. Breadcrumbs (optional)
  2. Title (mandatory)
  3. Subtitle (optional)
  4. Object marker (optional)
  5. Header toolbar with global actions (optional)
  6. Visual indicator for header features (mandatory if the header can be collapsed and expanded)
  7. Header content (optional)
Object page with the dynamic header
Object page with the dynamic header

If the object page is used in the flexible column layout, it can also contain navigation actions.

Please note:

  • To display images and placeholders in the header, use the avatar control.
  • The subtitle is now below the title. (In the former object page header it was next to the title.)

For an example of an object page with the dynamic page header, see this SAPUI5 sample. A sample with an image can be found here.

For more information, see the Dynamic Page Header section for the dynamic page layout.

Warning
Always build the object page using the dynamic page header and not the former object page header. Using the old object page header creates issues that can’t be fixed retrospectively. Using the dynamic header will also ensure consistency across all floorplans and provide greater flexibility. For details, see the Header section below.
Developer Hint
To use the dynamic page header in SAP Fiori Elements, set the class “objectPageHeaderType” to “Dynamic”.

Breadcrumbs

A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.

Header Content (optional)

The header content displays app-specific contextual information. You build the content using containers, called facets.

The facets are arranged inline with a left float. Each facet adapts its size to the content and makes optimal use of the space without truncating the texts. If the facets do not all fit on one line, those on the right wrap to the line below.

The header content is hidden by scrolling down the page or clicking the collapse indicator.

There are several types of header facets for different kinds of data. The facets must be implemented by the app team for standalone object pages. For SAP Fiori elements, they are predefined.

The following header facets are available:

Form Facet (Dataset)

You can use the form facet to display datasets.

A form facet consists of:

  1. Title (optional)
  2. Label-text pair (not more than 5)
  • The labels can be invisible, but need to have a text for accessibility purposes.
  • The labels can be icons, but need to have a text for accessibility purposes.
  • Each text can hold a link.
Developer Hint
For non-SAP Fiori element object pages only:

For each label-value pair in the form header facet, use a sap.m.Label and a sap.m.Text or sap.m.Link, nested within an sap.m.HBox.

Header facet - Form facets
Header facet - Form facets

Plain Text Facet

You can use the plain text facet to display a continuous text in the header.

A plain text facet consists of:

  1. Title (optional)
  2. Text

You can have links inline in the continuous text. They can navigate to another page or open a quick view. The text can contain more than one link, with different actions.

The default width of the facet is 300 px. The width of the facet doesn’t adapt to its content, but when the headline is broader than the facet width, the header wraps. You can also set a specific width to make optimal use of the given space.

Developer Hint
For non-SAP Fiori element object pages only:

To set the width of the plain text facet, nest the text within an sap.m.HBox and set the property:width of the sap.m.HBox.

Header facet - Plain text facet with default width
Header facet - Plain text facet with default width
Header facet - Plain text facet with custom width
Header facet - Plain text facet with custom width

Image Facet

You can use the image facet to show a picture of the object or a user profile. The header can have either one image facet or no image facet. The position of the image facet is fixed to the left. The image can have a press event. The default press event enlarges the image. When the header collapses, the image facet moves to the left of the title and becomes smaller.

Guidelines
Always use the avatar control for the image in the header. This applies to both expanded and collapsed images.
Header facet – Image facet specification
Header facet – Image facet specification

Key Value Facet

You can use the key value facet to highlight important data or KPIs.

A key value facet contains:

  1. Title
  2. Text or number in a larger font size

If the key value facet is used with a text, such as a status, you can also display an icon to the right of the text. This icon must only be used as a visual cue for the text it relates to, and not to add more information.

Developer Hint
For non-SAP Fiori element object pages only:

Larger value texts are now possible following the introduction of new properties for the object status and object number.

Header facet – Key value facets with KPIs and a status
Header facet – Key value facets with KPIs and a status

Micro Chart Facet

A micro chart facet consists of:

  1. Title (mandatory)
  2. Subtitle (optional)
  3. Micro chart (mandatory)
  4. Footer (optional)

To display the unit used in the micro chart, use the footer.

The following micro charts can be used in the micro chart facet:

The micro chart facet can have a click or tap event on the chart itself. This can lead to a page with a bigger chart or open a quick view, for example.

For more information, see Micro Charts.

Header facet – Micro chart facets
Header facet – Micro chart facets

Progress Indicator Facet

A progress indicator facet consists of:

  1. Title (mandatory)
  2. Progress indicator
  3. Subtitle (optional)
  4. Footer (optional)

For more information, see Progress Indicator.

Header facet - Progress indicator facet
Header facet - Progress indicator facet

Rating Indicator Facet

You can use this facet to display a rating indicator, which can be modified to fit your use case.

A rating indicator facet consists of:

  1. Title
  2. Rating indicator
  3. Supplementary texts (1-2)

We recommend the following property settings when using the rating indicator in header facets:

  • 5 symbols as the default.
  • Use the Favorite icon as the symbol.
  • Display half-stars to represent decimal values.

The rating indicator facet can be used for two different use cases: aggregated rating and single-value rating.

Aggregated rating:

A typical example of an aggregated rating is the average of several user reviews for a product.

The aggregated rating facet consists of:

  1. Title (mandatory)
  2. Subtitle (optional): Indicates the amount of data being aggregated.
  3. Rating indicator
  4. Footer (mandatory): Displays the exact aggregation value. Use the format “<average rating> out of <maximum rating>”. For the average rating, use the exact value with one decimal place.

Single value rating:

The single value rating facet consists of:

  1. Title (mandatory)
  2. Subtitle (optional): Displays supplementary text
  3. Rating indicator
Header facet - Rating indicator facet with aggregated rating and single value rating
Header facet - Rating indicator facet with aggregated rating and single value rating

Navigation Bar (optional)

If your content is simple and you need only one section, use the dynamic page layout. In the dynamic page layout with one section, the header area can’t be edited when the page is in edit mode.

If your content is complex and you need several sections, use the object page layout. You can only have several sections in the object page layout. In the object page layout with several sections, it’s also possible to edit the header area when the page is in edit mode. However, try to avoid having an editable header and move the content from the header to the sections instead.

If you need only one section, but require an editable header, use the object page layout. An object page with only one section doesn’t have any anchor bars. However, a temporary anchor bar and section for editing the header content should be added when edit mode is triggered.

If the content is complex there are two ways to structure it:

  • Anchor bar navigation (default)
  • Tab bar navigation

Anchor Bar Navigation

The anchor bar consists of a series of links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking a link navigates to the respective section. The anchor bar remains visible when the user scrolls down the page.

Use anchor bar navigation when the content belongs together but users might want to jump to specific parts directly.

For more information, see Anchor Bar Navigation below.

Tab Bar Navigation

The tabs are a series of links to subpages, arranged horizontally at the top of the page. Clicking a link navigates to the respective subpage. The tabs remain visible when the user scrolls down the page.

Use tab bar navigation if your page covers different topics that each have complex content, such as long tables or lists.

For more information, see Tab Bar Navigation below.

Anchor Bar Navigation

The anchor bar is the default navigation control for the object page. It consists of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint
Make sure that the UpperCaseAchorBar property is disabled and that you enter the anchor bar labels in title case (for example: Contact Information).

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow button on the right of the navigation bar () opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow menu button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the page.



Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow menu button
  8. Overflow menu dropdown
  9. Section (hover) in overflow menu
  10. Section in overflow menu
  11. Subsection in overflow menu

Behavior and Interaction

Click / Select: Action:
Anchor link Scrolls page directly to the content of the selected section (not to the title).
Arrow next to section anchor with several subsections Opens the submenu.
Item in the overflow list Scrolls the page to the content of the respective section or subsection (not to the title).
Keyboard left and right arrows Move between anchor links.
Fade area to the left or right of the anchor bar Causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
Overflow scroll button (right arrow) Scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
Overflow menu button () Displays a hierarchical dropdown list with all the sections and subsections of the page.

Tab Bar Navigation

As an alternative to the anchor bar, you can also use the tab bar for navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. The tab bar navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Navigation

As an alternative to the anchor bar, you can also use the tab bar for navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. The tab bar navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional, but the default state is set to “true” and a dropdown arrow is shown next to the tab. Clicking on the dropdown arrow displays a dropdown menu with the subsection anchors for that tab. Applications can decide which tabs are enabled for anchor subnavigation by setting their property to “true”.



Object page – Tab navigation
Object page – Tab navigation
  1. Anchor/tab bar navigation
  2. First section
  3. Second section

Content Area

The object page content consists of sections and subsections arranged in a column layout.

Sections

Sections are containers for subsections. They provide the basic structure for navigation and are directly reflected in the navigation bar.

The first section doesn’t have a title.

All the following sections consist of:

  1. Title with item counter (counter is optional)
  2. Subsections

Sections cannot contain controls.

If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for local actions at the subsection level.

Subsections

Subsections are containers for actual content.

A subsection consists of:

  1. Title with item counter (counter is optional)
  2. Toolbar with actions (optional)
  3. Content
  4. Mixable related content (optional)
  5. Controls inside subsection (optional)

Subsection content is arranged according to the column layout approach for the respective screen size.

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can always choose to display everything by selecting the Show All button at the bottom right of the subsection.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Extra large: 4 columns
  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

If you are using the object page without object page blocks, you can use the column layout for forms, which automatically distributes form groups across the columns in the object page.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.

To show and hide blocks, you can use a Show More / Show Less toggle button. Do not use the panel container in the object page content area.

Object page – Blocks
Object page – Blocks

Tables

If a section or subsection contains only one table and no other content, remove the table title to avoid having duplicate titles for the table. In this case, the section or subsection title acts as the table title.

Depending on the number of table items, use one of the following loading behaviors:

Number of Table Items: Use:
Up to 20 Items can be displayed right away
Up to 100 Lazy loading
More than 50-100 but less than 400 Tab navigation
More than 400 or tab approach is unsuitable Navigation to list report

If a table is expected to have more than 20 items, use one of the 3 options below for long tables.

For all three options, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Avoid grouping.

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial number of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, only use this option for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. To enable the scroll-to-load behavior, the table must be the only or last element within a tab.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, restrict the size of the table in the object page to a reasonable number of items. We recommend only showing a preview of no more than 20 items. Ideally, you should have about 10 items. This can be achieved by prefiltering and/or sorting the table, and, if necessary, setting a fixed number of items (such as the top 10). To enable the user to work with the entire table, offer navigation to a separate list report containing the full table. To do this, place a right-aligned link below the table with the label Show All (x), where x represents the total number of items in the table.

Table with navigation to a separate list report
Table with navigation to a separate list report

The object page loads in a “growing” mode. This means that the object page loads section by section to show users some content before the whole page is loaded. Scrolling down the page triggers loading for the sections below. Hidden items in sections are only loaded (and rendered) by clicking the Show More button for the section.

If the loading takes a long time, a busy indicator is shown on top of the section or item until the content it loaded and visible.

Busy indicators for sections still loading
Busy indicators for sections still loading

Representation of Child Pages

In object pages with drilldown navigation, child pages are represented in two ways:

  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Paging buttons: Up and down arrows in the layout action area allow the user to navigate between subitems without going back to the original list.

Footer Toolbar

The footer toolbar is used in edit and create mode for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

Behavior and Interaction

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create).

Edit

In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see Manage Objects – Create, Edit, Delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only in the new header section. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

If your object page has no anchor bar in display mode, and the header section has only a few editable fields, do not add navigation in edit mode.

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit in a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Create and Edit Subobjects

The following options are available for creating or editing subobjects:

  • Navigation to a subobject page
  • Inline create or inline edit in a table
  • Dialog containing the fields of the object

If the subobject has less than 8 fields, use a dialog or the inline create/edit option (no separate page for the subobject). Exceptions can apply if additional content for the subobject is available but not part of the edit process, or if other apps need to offer deep links to the subobject page.

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:

  • Who made the changes
  • When the last changes were made

The popover closes when the user clicks or taps outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, dispaly the placeholder text “New ” (for example, New Purchase Order). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL). The layout for size XL contains four columns.

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The default layout for size L (desktop) contains three columns. If you want to display two content elements that require an equal amount of space, you can also use an optional two-column layout (for example, two tables next to each other). Do not use the two-column layout with forms.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Guidelines

Dynamic Page Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing clear context.

Developer Hint
How to achieve a small header:

  • The header container is always optional. If there is no important data to be displayed, you can omit it. In this case, only the header title bar is shown.
  • Omit the image if it is not necessary. It is generally the tallest element in a header container.
  • Use a light theme to reduce the emphasis on the header if it doesn’t contain much information.
  • Consider moving information from the header into a general information section.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Use icons only for generic actions (such as  for Share). For all business actions, use text buttons.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.

For more information, see Action Placement.

Image Facet

If you intend to use images in the object header, consider the following:

  • How will the user manage the images?
  • How will the system block people without permission from editing images?
  • How will these images be reflected in other floorplans if they are part of the object?
  • If there are a large number of items, how would a user be able to manage images without having to navigate from page to page?
  • Will the organization be able to manage the images?

Tab Navigation

If you have a complex object page, use the tab navigation approach. This can be useful when a complex object page has performance issues in a flat view, or in response to a specific user preference.

Content Area

  • Avoid using the object page as a universal container for masses of information. Use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.
  • Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request.
  • Only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


Worklist Floorplan

Information
This article contains general guidelines for the worklist floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the worklist floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

A worklist displays a collection of items that a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan is on processing the items. This differs from the list report floorplan, which focuses on finding and acting on relevant items from a large dataset.

Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Users need to work with multiple views of the same content (for example, items that are “Open”, “In Process”, or “Completed”. Users can switch between views using the tab bar.

Do not use the worklist floorplan if:

  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (charts or tables). In this case, use the list report floorplan instead.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping. Use the list report floorplan instead.

Structure

The worklist floorplan is based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, KPI information (if relevant), and a header toolbar with global actions, such as Share.
  • The content area: Use this to display:
    • An icon tab bar in the content area
    • One table (per tab)
    • You can use any kind of table and list. To ensure that the application runs on all devices, we recommend using the responsive table.
Basic structure
Basic structure

Responsiveness and Adaptiveness

In general, the worklist floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

Worklist floorplan - Size S
Worklist floorplan - Size S
Worklist floorplan - Size M
Worklist floorplan - Size M
Worklist floorplan - Size L/XL
Worklist floorplan - Size L/XL

Guidelines

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a table.

Simple worklist without tabs
Simple worklist without tabs

Worklist with Tabs

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs show different perspectives on the same dataset.

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red for the Error tab).

Worklist with tab categories
Worklist with tab categories

Worklist with KPI

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI within the KPI container next to the page title as an object status.

Worklist with KPI
Worklist with KPI

Header Title

Variant Management

Variant management is optional. If used, apply it to the whole page. Use the variants to save and restore all settings, including selected tabs, all tables, and all personalization settings.

If variant management is not needed, just show a title that describes the current view instead.

Header Toolbar (Global Actions)

Use this for non-finalizing global actions such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

In addition, offer any other global, non-finalizing actions that are needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Page Content

Tab Bar

The tab bar is part of the page content container, which means that the tab bar is not “sticky” and will scroll away when the user scrolls down the page.

Use the icon tab bar. Display the number of items shown in the table on each tab (sap.m.IconTabFilter, property: count). Only use icons if you need to display semantic colors on the icon tab bar.

The tab bar works as a filter on the content below.

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. For filter, sort, and group, show a view settings dialog with only the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items or only unsuitable items are selected. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table actions, see the guidelines for the table toolbar and for managing objects.

Table

If there are no items to display, use the “no data text” of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • The search was executed, but no items were found: No items found. Try adjusting your search criteria.
  • By opening a related app, the filter criteria were transferred automatically, but no items were found: No items found. Check the search and filter settings.

There are three types of navigation at item level in the worklist floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation. In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation. Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is used for a different target.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually a list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting. In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object, as well as a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Actions

Places for actions in the worklist
Places for actions in the worklist

The worklist offers four locations for actions:

(1) Global actions in the header toolbar
(2) Table actions in the table toolbar
(3) Line item actions
(4) Finalizing actions in the footer toolbar

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the standard Share action.

The Share button opens an action sheet that contains actions like Save as Tile (if the SAP Fiori Launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space in the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table Actions

Place actions that affect the content of a table in the table toolbar (2).

When to Enable, Disable, or Hide Actions

Indicate whether an action is available. Some actions are always available (such as Create for new objects). Other actions are only relevant if items have been selected (for example, Edit at item level, Remove, object-specific actions, or actions that change the status of an item).

Enable the following actions:

  • All Add/Create actions, unless the user needs to specify where in the table the new item should be added.
  • Edit actions that switch the entire table to edit mode (independent of the selected items).
    If the user triggers the Edit button, replace it with Save and Cancel buttons (see Editing the Whole Table).
  • Item-dependent actions that can be applied to some or all of the selected items.

Disable the following actions:

  • Item-dependent actions when no items have been selected.
  • Add/Create actions where the user needs to specify the insert position in the table, but either no item has been selected, or more than one item has been selected.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information, also see UI Element States – Control States.

Partial Processing

Enable the user to apply the changes to as many of the selected items as possible.

If an action can’t be applied to all selected items, show a warning message before executing the action:

  • Indicate the number of selected items that can’t be processed (out of the total number of selected items).
  • Give a reason why the action can’t be applied to these items.
  • Let the user choose whether to apply the action to the remaining items anyway or cancel the action.

See an example here.

Note: In some scenarios, you might not be able to identify whether an action can be applied to all selected items before executing it. If the system is unable to apply the action to all items, show a message after executing the action.

Sort, Group, Personalization

Decide if you need to provide a sorting, grouping or personalization for your use case. If you offer more than one of these actions, offer them as single actions. We recommend keeping them in the following order: Sort, Group, Personalization.

More Information

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this option only for specific, frequently-used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or if the line item has the wrong state, for example.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen. Once the user has completed the task, the app should:

  • Return the user to the worklist
  • Remove the processed item from the list, or move it to a “completed” section
  • Confirm the user’s action with a message toast

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Worklist Floorplan

Information
This article contains general guidelines for the worklist floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the worklist floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

A worklist displays a collection of items that a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan is on processing the items. This differs from the list report floorplan, which focuses on finding and acting on relevant items from a large dataset.

Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Users need to work with multiple views of the same content (for example, items that are “Open”, “In Process”, or “Completed”. Users can switch between views using the tab bar.

Do not use the worklist floorplan if:

  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (charts or tables). In this case, use the list report floorplan instead.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping. Use the list report floorplan instead.

Structure

The worklist floorplan is based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, KPI information (if relevant), and a header toolbar with global actions, such as Share.
  • The content area: Use this to display:
    • An icon tab bar in the content area
    • One table (per tab)
    • You can use any kind of table and list. To ensure that the application runs on all devices, we recommend using the responsive table.
Basic structure
Basic structure

Responsiveness and Adaptiveness

In general, the worklist floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

Worklist floorplan - Size S
Worklist floorplan - Size S
Worklist floorplan - Size M
Worklist floorplan - Size M
Worklist floorplan - Size L/XL
Worklist floorplan - Size L/XL

Guidelines

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a table.

Simple worklist without tabs
Simple worklist without tabs

Worklist with Tabs

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs show different perspectives on the same dataset.

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red for the Error tab).

Worklist with tab categories
Worklist with tab categories

Worklist with KPI

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI within the KPI container next to the page title as an object status.

Worklist with KPI
Worklist with KPI

Header Title

Variant Management

Variant management is optional. If used, apply it to the whole page. Use the variants to save and restore all settings, including selected tabs, all tables, and all personalization settings.

If variant management is not needed, just show a title that describes the current view instead.

Header Toolbar (Global Actions)

Use this for non-finalizing global actions such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

In addition, offer any other global, non-finalizing actions that are needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Page Content

Tab Bar

The tab bar is part of the page content container, which means that the tab bar is not “sticky” and will scroll away when the user scrolls down the page.

Use the icon tab bar. Display the number of items shown in the table on each tab (sap.m.IconTabFilter, property: count). Only use icons if you need to display semantic colors on the icon tab bar.

The tab bar works as a filter on the content below.

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. For filter, sort, and group, show a view settings dialog with only the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items or only unsuitable items are selected. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table actions, see the guidelines for the table toolbar and for managing objects.

Table

If there are no items to display, use the “no data text” of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • The search was executed, but no items were found: No items found. Try adjusting your search criteria.
  • By opening a related app, the filter criteria were transferred automatically, but no items were found: No items found. Check the search and filter settings.

There are three types of navigation at item level in the worklist floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation. In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation. Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is used for a different target.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually a list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting. In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object, as well as a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Actions

Placement for actions in the worklist
Placement for actions in the worklist

The worklist offers four locations for actions:

(1) Global actions in the header toolbar
(2) Table actions in the table toolbar
(3) Line item actions
(4) Finalizing actions in the footer toolbar

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the standard Share action.

The Share button opens an action sheet that contains actions like Save as Tile (if the SAP Fiori Launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space in the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table Actions

Place actions that affect the content of a table in the table toolbar (2).

When to Enable, Disable, or Hide Actions

Indicate whether an action is available. Some actions are always available (such as Create for new objects). Other actions are only relevant if items have been selected (for example, Edit at item level, Remove, object-specific actions, or actions that change the status of an item).

Enable the following actions:

  • All Add/Create actions, unless the user needs to specify where in the table the new item should be added.
  • Edit actions that switch the entire table to edit mode (independent of the selected items).
    If the user triggers the Edit button, replace it with Save and Cancel buttons (see Editing the Whole Table).
  • Item-dependent actions that can be applied to some or all of the selected items.

Disable the following actions:

  • Item-dependent actions when no items have been selected.
  • Add/Create actions where the user needs to specify the insert position in the table, but either no item has been selected, or more than one item has been selected.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information, also see UI Element States – Control States.

Partial Processing

Enable the user to apply the changes to as many of the selected items as possible.

If an action can’t be applied to all selected items, show a warning message before executing the action:

  • Indicate the number of selected items that can’t be processed (out of the total number of selected items).
  • Give a reason why the action can’t be applied to these items.
  • Let the user choose whether to apply the action to the remaining items anyway or cancel the action.

See an example here.

Note: In some scenarios, you might not be able to identify whether an action can be applied to all selected items before executing it. If the system is unable to apply the action to all items, show a message after executing the action.

Sort, Group, Personalization

Decide if you need to provide a sorting, grouping or personalization for your use case. If you offer more than one of these actions, offer them as single actions. We recommend keeping them in the following order: Sort, Group, Personalization.

More Information

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this option only for specific, frequently-used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or if the line item has the wrong state, for example.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen. Once the user has completed the task, the app should:

  • Return the user to the worklist
  • Remove the processed item from the list, or move it to a “completed” section
  • Confirm the user’s action with a message toast

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object Page Floorplan

Information
This article contains general guidelines for the object page floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the object page floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

The object page floorplan allows the user to display, create, or edit an object. This is the recommended floorplan for representing both simple and complex objects in SAP Fiori. The object page floorplan comes with a flexible header, a choice of anchor or tab navigation, and a flexible, responsive layout. These features make it adaptable for a wide range of use cases.

Object page floorplan
Object page floorplan

Usage

Use the object page floorplan if:

  • Users need to see, edit, or create an item with all its details.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

  • Users want to edit several items at the same time. Use the list report floorplan instead.
  • Users need to find relevant items without knowing the exact item details. Use the list report floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner). Use the initial page floorplan instead.
  • Users need to be guided through a series of steps when a new object is created. Use the wizard floorplan instead.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected. Use the wizard floorplan instead.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL).

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The layout for size XL (large display) contains four columns.

The default layout for size L (desktop) contains three columns. If you want to display two content elements that require an equal amount of space, you can also use an optional two-column layout (for example, two tables next to each other). Do not use the two-column layout with forms.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Structure

Warning
Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility. For details, see the Header section below.

The object page is a full screen floorplan with a display mode, a create mode, and an edit mode.

In all modes, the object page contains:

  • A dynamic header
  • A navigation bar (optional)
  • A content area

The following sections explain these components in more detail.

Schematic visualization of the object page
Schematic visualization of the object page

Header

The header is the uppermost element of the object page floorplan. It contains key information about the business object and provides the user with the necessary context. The header also contains global actions for the object.

Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility.

The header consists of the following elements:

  1. Title (mandatory)
  2. Subtitle (optional)
  3. Global actions (optional)
  4. Object marker (optional, placed in the key information container of the dynamic header)
  5. Header content (optional)
  6. Breadcrumbs (optional)
  7. Visual indicator (mandatory if the header can be collapsed and expanded)
Object page with the dynamic header
Object page with the dynamic header

If the object page is used in the flexible column layout, it can also contain navigation actions.

Please note:

  • To display images and placeholders in the header, use the avatar control.
  • The subtitle is now below the title. (For the former object page header it was next to the title.)

For an example of an object page with the dynamic header, see this SAPUI5 sample. A sample with an image can be found here.

For more information, see the Dynamic Header section for the dynamic page layout.

Header Facets

The header content is optional and is located below the title.

It can be used to display app-specific contextual information. You build the content using smaller content containers, called facets. Each facet contains a distinct information set, as described below. If there aren’t any facets, the header content is always hidden.

The facets are arranged in line with a left float. Each facet adapts its size to the content and makes optimal use of the space without truncating the texts. If the facets do not all fit on one line, those on the right wrap to the line below.

If the header collapses, the header content is hidden. If the header content is empty, you can also hide it.

There are several types of header facets, depending on the data that they display. The facets need to be handmade for stand-alone object pages.

Form Facet (Dataset)

The form facet can be used to display datasets in the header. It consists of a headline and up to five label-text pairs.

  • The headline is optional.
  • The form facet contains at least one label-text pair, and a maximum of 5 pairs.
  • The labels can be invisible, but need to have a text for accessibility purposes.
  • The labels can be icons, but need to have a text for accessibility purposes.
  • Each text in a label-text pair can have a press event.

Form facets are typically used for document information (such as creator and creation time), address or contact information, and general information.

Developer Hint
For non-SAP Fiori element object pages only:

For each label-value pair in the form header facet, use a sap.m.Label and a sap.m.Text or sap.m.Link, nested within an sap.m.HBox.

Header facet - Form facets
Header facet - Form facets

Plain Text Facet

The plain text facet can be used to display a continuous text in the header. It consists of a headline and a continuous text.

  • The width of the facet does not depend on its content, but can be set. The default width of the facet is 300px.
  • The headline is optional.
  • If the headline is broader than the facet width, the headline will wrap.
  • Press events are only available inline in the continuous text. These can be links that navigate to another page or open a quick view. There can be more than one link in the continuous text with different actions.
Developer Hint
For non-SAP Fiori element object pages only:

To set the width of the plain text facet, nest the text within an sap.m.HBox and set the property:width of the sap.m.HBox.

Header facet - Plain text facet with default width
Header facet - Plain text facet with default width
Header Facet - Plain text facet with custom width
Header Facet - Plain text facet with custom width

Image Facet

The image facet can hold exactly one image. The header can have only one image facet, or no image facet.

The image can be:

  • Square or circular
  • An icon
  • Initials consisting of two letters

The image can have a press event. The default press event enlarges the image.

When the header collapses, the image facet moves to the left of the title and becomes smaller.

Recommended usage:

  • Use round images for people, especially for portraits. If no image is available for a person, use the person’s initials instead (first letters of the first and last names).
  • Use square images for all other images. If no image is available for an object, show a suitable icon.

Always make it clear to users how they can upload and manage images. This either be done in edit mode on the object page, or using an external tool. External tools can be helpful if there are a lot of images.

Developer Hint
Always use the avatar control for the image in the header. This applies to both expanded and collapsed images.
Header facet – Image facet specification
Header facet – Image facet specification

Key Value Facet

The key value facet contains a label in a smaller font size and a text or number in a bigger font size. It can be used to highlight important data or KPIs.

If the key value facet is used with a text, such as a status, you can also display an icon to the right of the text. This icon must only be used to visually support the text it relates to, and not to add an another aspect of meaning.

Developer Hint
For non-SAP Fiori element object pages only:

Larger value texts are now possible with the introduction of new properties for the Object Status and Object Number.

Header facet – Key value facets with KPIs and a status
Header facet – Key value facets with KPIs and a status

Micro Chart Facet

The micro chart facet consists of a headline, a subtitle, a micro chart, and a footer.

The headline and the micro chart are mandatory while the subtitle and the footer are optional. To display the unit used in the micro chart, use the footer.

The following micro charts can be used in the micro chart facet:

The micro chart facet can have a click or tap event on the chart itself. This could  lead to a page with a bigger chart or open a quick view, for example.

For more information see micro charts.

Header facet – Micro chart facets
Header facet – Micro chart facets

Progress Indicator Facet

The progress indicator facet consists of a mandatory headline and a progress indicator (sap.m.progressIndicator). In addition, it can have two supplementary texts: a subtitle and a footer.

Header facet - Progress indicator facet
Header facet - Progress indicator facet

Rating Indicator Facet

The rating indicator facet consists of a headline, a rating indicator, and one or two supplementary texts, which are dependent on the use case.

The rating indicator can be modified as described in the rating indicator article.

We recommend the following property settings when using the rating indicator in header facets:

  • 5 symbols as the default.
  • Use the Favorite icon as the symbol.
  • Display half-stars to represent decimal values.

The rating indicator facet can be used for two different use cases, which are described below.

  1. Aggregated rating:

    A typical example of an aggregated rating is the average of several user reviews for a product. The facet for aggregated rating has a mandatory header, an optional subtitle, the rating indicator itself, and a footer.

    Use the subtitle to indicate the amount of data being aggregated. For example, if you show an average rating, the subtitle shows the number of ratings.

    In the footer, display exact aggregation value. Use the format “<average rating> out of <maximum rating>”. For the average rating, use the exact value with one decimal place.
    Example: 2.2 out of 5

  2. Single value rating:

If you display the rating as a single value, the facet has a mandatory header, an optional subtitle, and the rating indicator itself. Here, you can use the subtitle for a supplementary text. Do not use a footer.

Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with singe value rating
Header facet - Rating indicator facet with singe value rating

Toolbars

The object page supports two toolbars:

  • Header toolbar: Use this toolbar for global actions, such as Edit, Delete, Copy, and Share.
  • Floating toolbar: Use this toolbar for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

This applies to all object page modes (display, edit, and create).

Navigation

There are three ways to navigate within the object page:

  • Anchor bar (by default)
  • No navigation (flat scrollable page)
  • Tabs

Usage

  • To offer a flat page for a simple object, use the dynamic page to prevent having sections and navigation. Create the header in the same way as for the object page.
  • For more complex objects, use anchor or tab navigation.

Anchor Bar and Overflow

The anchor bar is the default navigation control for the object page. It consist of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint

Anchor Bar and Overflow

Use title case for the anchor bar texts. To do this, you need to change the default capitalization (block caps) by changing the the property upperCaseAnchorBar to “false”.

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow overview button on the right of the navigation bar ( ) opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow overview button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the document.

Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow overview button
  8. Overflow overview dropdown
  9. Section (hover) in overflow overview
  10. Section in overflow overview
  11. Subsection in overflow overview

Behavior and Interaction

  • Clicking an anchor link scrolls the page to the selected section.
  • Clicking a section anchor that contains more than one subsection opens a subsection menu.
  • Clicking a subsection scrolls the page to the selected subsection. The keyboard left and right arrows allow the user to move between the anchor links.
  • Hovering over the fade area to the left or right of the anchor bar causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
  • Clicking the overflow scroll button (right arrow) scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
  • Clicking the overflow overview button ( ) displays a hierarchical dropdown list with all the sections and subsections of the document. Clicking an item in the overflow list scrolls to the respective section or subsection.

Hiding the Navigation

You can hide the navigation bar from the object page, leaving a flat, scrollable object. We recommend using this flat view for simple content that doesn’t require anchor navigation.

Tab Navigation

As an alternative to anchor navigation, you can also opt for tab navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. Tab navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional and the default state is “false”. If the state is set to “true”, a dropdown arrow is shown next to the tab. Clicking on the tab displays a dropdown menu with the subsection anchors for that tab.

Object page – Tab navigation
Object page – Tab navigation

Breadcrumbs

If the object page uses a hierarchical parent-child drilldown, you can offer a breadcrumb for navigation.

Content Area

The object page content consists of sections and subsections arranged in a column layout. For large documents, you can enable a lazy loading mechanism (property: enableLazyLoading) to mitigate the loading time.

Sections

Sections are containers for subsections. They provide the basic structure for navigation, and are directly reflected in the navigation bar. Sections can have a title, subsections, and actions. However, they cannot contain controls.

Use title case for the section title (property titleUppercase = “false”). The title can have an item counter, which is displayed in parentheses. If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Global actions are always placed at subsection level. Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for global actions at the subsection level.

Subsections

Subsections are the containers for actual content. Always place individual controls inside the subsections. Subsection content is arranged according to the column layout approach for the respective screen size. A subsection can include containers for different controls (mixed content).

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can also display everything by selecting the Show All button at the bottom right of the subsection.

Each subsection can have a toolbar, which is placed at subsection header level on the right. The toolbar contains actions that affect the content of the subsection.

Subsections can have an item counter, which is displayed in parentheses next to the subsection header.

You can include various types of related content in one subsection. The layout blocks for the object page give you the flexibility to combine different content types.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Extra large: 4 columns
  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times, and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

If you are using the object page without object page blocks, you can use the column layout for forms, which automatically distributes form groups across the columns in the object page.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.

To show and hide blocks, you can use a Show More / Show Less toggle button. Do not use the panel conainer in the object page content area.

Object page – Blocks
Object page – Blocks

Tables

If a section or subsection contains only one table and no other content, remove the table title to avoid having duplicate titles for the table. In this case, the section or subsection title acts as the table title.

If you want to embed analytical tables, grid tables, or tree tables in an object page, use an object page with tabs, and place each table in its own tab. Because the analytical, grid, and tree tables have their own vertical scroll bars, they are not allowed within scrollable object pages. If you are using a scrollable object page without tabs, use a responsive table instead, and offer navigation to a list report with the respective table type.

In an object page, tables with up to 20 expected items can be displayed right away without lazy loading.

If a table is expected to have more than 20 items, use one of the following 3 options for long tables:

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial amount of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, this option should be used only for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. Here it is important to place the table within a tab as the only or at least the last element and to enable the scroll to load behavior.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, the table itself should be restricted to a reasonable amount of items. We recommend only showing a preview of the data in the table, which should not contain more than 20 items. Ideally, you should have about 10 items. This can be either be achieved by prefiltering and/or by sorting the table, and if necessary, by restricting it to a fixed amount of items (such as top 10). To provide the user with a way to work with the entire table, a navigation to a separate list report containing the full table must be offered.  This navigation should be located below the table in the form of a right-aligned link labelled Show All (x), with x representing the total amount of items in the table.

For all of the three options mentioned above, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Grouping should be avoided.

Table with navigation to a separate list report
Table with navigation to a separate list report

Child Page Representation

In object pages with drilldown navigation, child pages are represented in two ways:

  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Item navigation arrows: Up and down arrows in the layout action area allow the user to navigate between subitems without going back to the original list.

Behavior and Interaction

Edit

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create). In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area for edit mode to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see manage objects – create, edit, delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

If your object page has no anchor bar in display mode, and the header section has only a few editable fields, do not add navigation in edit mode.

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit on a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Create and Edit Subobjects

The following options are available for creating or editing subobjects:

  • Navigation to a subobject page
  • Inline create or inline edit in a table
  • Dialog containing the fields of the object

If the subobject has less than 8 fields, use a dialog or the inline create/edit option (no separate page for the subobject). Exceptions can apply if additional content for the subobject is available but not part of the edit process, or if other apps need to offer deep links to the subobject page.

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:
•Who made the changes
•When the last changes were made

The popover closes when the user clicks or taps the Close icon or anywhere outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, use the placeholder text “New ” (for example, “New Purchase Order”). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Guidelines

Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing clear context.

If you intend to use images in the header for an object, consider the following:

  • How will the user manage the images?
  • How will the system block people without permission from editing images?
  • How will these images be reflected in other floorplans if they are part of the object?
  • If there are a large number of items, how would a user be able to manage images without having to navigate from page to page?
  • Will the organization be able to manage the images?
Developer Hint
How to achieve a small header:

  • The header container is always optional. If there is no important data to be displayed, you can omit it. In this case, only the header title bar is shown.
  • Omit the image if it is not necessary. It is generally the tallest element in a header container.
  • Use a light theme to reduce the emphasis on the header if it doesn’t contain much information.
  • Consider moving information from the header into a general information section.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.

Tab Navigation

Use tab navigation if you need a facet approach to your content. This could be due to performance issues in a flat view, or in response to a specific user preference.

Not a Content Dump

Avoid using the object page as a universal container for masses of information. You should use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.

Simplify Content for Your Users

Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request. Furthermore, only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


Introduction to SAP Fiori Elements

SAP Fiori elements (formerly known as smart templates) provide a framework for the most common application patterns.

The application team selects the relevant floorplan and adds semantic and structural data using metadata annotations. The framework then generates the application screen.

SAP Fiori elements ensure design consistency and compliance with the latest design guidelines, while reducing the amount of frontend code needed to build SAP Fiori apps.

Information
SAP Fiori elements are part of the SAPUI5 delivery.
SAP Fiori elements – The production line for UIs
SAP Fiori elements – The production line for UIs

Supported Floorplans and Layouts

The following floorplans are available as SAP Fiori elements:

The SAP Fiori elements framework supports the dynamic page layout for all available floorplans. In addition, the flexible column layout is supported for all available floorplans except the overview page, which is not allowed within the flexible column layout.

SAP Fiori elements use the global edit flow, which includes draft handling, or the local edit flow without draft handling. SAP Fiori elements also offer message handling.

Overview page
Overview page
List report
List report
Worklist
Worklist
Analytical list page
Analytical list page
Object page
Object page

Usage

You can use the SAP Fiori elements framework if the floorplan and layout you need for your app design are supported. The overview page floorplan, analytical list page floorplan, dynamic page layout, and flexible column layout are all fully supported. If you want to use the object page or list report floorplans, check the respective guideline articles to see which features are supported for SAP Fiori elements.

If you want to use floorplans that are not supported by the SAP Fiori elements framework, or if you require several features that are not supported by the respective floorplan in SAP Fiori elements, you should go with a freestyle app instead.

One of the big benefits of SAP Fiori elements is the reduction in development effort. This is especially important for features like draft handling or the flexible column layout. If you need these features in your app, you should go with SAP Fiori elements.

For an overview of all available floorplans and layouts, see Overview – Layouts, Floorplans, and Frameworks.

Responsiveness

The responsiveness of SAP Fiori elements depends on the responsiveness of the floorplans and controls used in your app.

The SAP Fiori elements framework lets you influence the responsiveness of certain controls. For example, you can adapt the overflow behavior of actions and fields in the overflow toolbar, or change the pop-in behavior of columns in a responsive table.

Developer Hint
You can use the priority annotation to influence the responsive behavior of certain controls. This annotation supports the values “high”, “medium”, and “low”.

Adjustments

The behavior and interaction generally follows the guidelines for the respective floorplan or concept. If the guideline offers choices, the SAP Fiori elements framework offers the most generic option or, where possible, provides different options to choose from.

For example, the default table for list reports is the responsive table (or, for aggregated services, the analytical table). Other table types are offered as well, but have to be actively enabled by the application developer.

Deviations from the guidelines are sometimes necessary due to technical limitations, which are listed in the respective guideline artices. These limitations are usually short term and will be solved in future releases.

Developer Hint
You can adjust certain features by implementing breakouts, by adapting the manifest.json of your app, or through annotations or UI adaptation.

Mandatory Adjustments

Some UI texts provided by the SAP Fiori element contain generic placeholders. Always replace the default placeholders with an application-specific text. For more information about placeholder texts in SAP Fiori elements, see Replacing Standard UI Texts.

Examples of generic and adjusted texts:

Default Text Adjusted Example
List Report Create Object Create Sales Order
Object Page New Object New Sales Order
Overview Page Could not perform action Unable to approve the request

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Introduction to SAP Fiori Elements

SAP Fiori elements (formerly known as smart templates) provide a framework for the most common application patterns.

The application team selects the relevant floorplan and adds semantic and structural data using metadata annotations. The framework then generates the application screen.

SAP Fiori elements ensure design consistency and compliance with the latest design guidelines, while reducing the amount of frontend code needed to build SAP Fiori apps.

Information
SAP Fiori elements are part of the SAPUI5 delivery.
SAP Fiori elements – The production line for UIs
SAP Fiori elements – The production line for UIs

Supported Floorplans and Layouts

The following floorplans are available as SAP Fiori elements:

The SAP Fiori elements framework supports the dynamic page layout for all available floorplans. In addition, the flexible column layout is supported for all available floorplans except the overview page, which is not allowed within the flexible column layout.

SAP Fiori elements use the global edit flow, which includes draft handling, or the local edit flow without draft handling. SAP Fiori elements also offer message handling.

Overview page
Overview page
List report
List report
Worklist
Worklist
Analytical list page
Analytical list page
Object page
Object page

Usage

You can use the SAP Fiori elements framework if the floorplan and layout you need for your app design are supported. The overview page floorplan, analytical list page floorplan, dynamic page layout, and flexible column layout are all fully supported. If you want to use the object page or list report floorplans, check the respective guideline articles to see which features are supported for SAP Fiori elements.

If you want to use floorplans that are not supported by the SAP Fiori elements framework, or if you require several features that are not supported by the respective floorplan in SAP Fiori elements, you should go with a freestyle app instead.

One of the big benefits of SAP Fiori elements is the reduction in development effort. This is especially important for features like draft handling or the flexible column layout. If you need these features in your app, you should go with SAP Fiori elements.

For an overview of all available floorplans and layouts, see Overview – Layouts, Floorplans, and Frameworks.

For more information on when to use SAP Fiori elements, see the usage guide.

Responsiveness

The responsiveness of SAP Fiori elements depends on the responsiveness of the floorplans and controls used in your app.

The SAP Fiori elements framework lets you influence the responsiveness of certain controls. For example, you can adapt the overflow behavior of actions and fields in the overflow toolbar, or change the pop-in behavior of columns in a responsive table.

Developer Hint
You can use the priority annotation to influence the responsive behavior of certain controls. This annotation supports the values “high”, “medium”, and “low”.

Adjustments

The behavior and interaction generally follows the guidelines for the respective floorplan or concept. If the guideline offers choices, the SAP Fiori elements framework offers the most generic option or, where possible, provides different options to choose from.

For example, the default table for list reports is the responsive table (or, for aggregated services, the analytical table). Other table types are offered as well, but have to be actively enabled by the application developer.

Deviations from the guidelines are sometimes necessary due to technical limitations, which are listed in the respective guideline artices. These limitations are usually short term and will be solved in future releases.

Developer Hint
You can adjust certain features by implementing breakouts, by adapting the manifest.json of your app, or through annotations or UI adaptation.

Mandatory Adjustments

Some UI texts provided by the SAP Fiori element contain generic placeholders. Always replace the default placeholders with an application-specific text. For more information about placeholder texts in SAP Fiori elements, see Replacing Standard UI Texts.

Examples of generic and adjusted texts:

Default Text Adjusted Example
List Report Create Object Create Sales Order
Object Page New Object New Sales Order
Overview Page Could not perform action Unable to approve the request

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object Page Floorplan

Information
This article contains general guidelines for the object page floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the object page floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

The object page floorplan allows the user to display, create, or edit an object. This is the recommended floorplan for representing both simple and complex objects in SAP Fiori. The object page floorplan comes with a flexible header, a choice of anchor or tab navigation, and a flexible, responsive layout. These features make it adaptable for a wide range of use cases.

Object page floorplan
Object page floorplan

Usage

Use the object page floorplan if:

  • Users need to see, edit, or create an item with all its details.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

  • Users want to edit several items at the same time. Use the list report floorplan instead.
  • Users need to find relevant items without knowing the exact item details. Use the list report floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner). Use the initial page floorplan instead.
  • Users need to be guided through a series of steps when a new object is created. Use the wizard floorplan instead.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected. Use the wizard floorplan instead.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL).

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The layout for size XL (large display) contains four columns.

The default layout for size L (desktop) contains three columns. If you want to display two content elements that require an equal amount of space, you can also use an optional two-column layout (for example, two tables next to each other). Do not use the two-column layout with forms.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Structure

Warning
Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility. For details, see the Header section below.

The object page is a full screen floorplan with a display mode, a create mode, and an edit mode.

In all modes, the object page contains:

  • A dynamic header
  • A navigation bar (optional)
  • A content area

The following sections explain these components in more detail.

Schematic visualization of the object page
Schematic visualization of the object page

Header

The header is the uppermost element of the object page floorplan. It contains key information about the business object and provides the user with the necessary context. The header also contains global actions for the object.

Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility.

The header consists of the following elements:

  1. Title (mandatory)
  2. Subtitle (optional)
  3. Global actions (optional)
  4. Object marker (optional, placed in the key information container of the dynamic header)
  5. Header content (optional)
  6. Breadcrumbs (optional)
  7. Visual indicator (mandatory if the header can be collapsed and expanded)
Object page with the dynamic header
Object page with the dynamic header

If the object page is used in the flexible column layout, it can also contain navigation actions.

Please note:

  • To display images and placeholders in the header, use the avatar control.
  • The subtitle is now below the title. (For the former object page header it was next to the title.)

For an example of an object page with the dynamic header, see this SAPUI5 sample. A sample with an image can be found here.

For more information, see the Dynamic Header section for the dynamic page layout.

Header Facets

The header content is optional and is located below the title.

It can be used to display app-specific contextual information. You build the content using smaller content containers, called facets. Each facet contains a distinct information set, as described below. If there aren’t any facets, the header content is always hidden.

The facets are arranged in line with a left float. Each facet adapts its size to the content and makes optimal use of the space without truncating the texts. If the facets do not all fit on one line, those on the right wrap to the line below.

If the header collapses, the header content is hidden. If the header content is empty, you can also hide it.

There are several types of header facets, depending on the data that they display. The facets need to be handmade for stand-alone object pages.

Form Facet (Dataset)

The form facet can be used to display datasets in the header. It consists of a headline and up to five label-text pairs.

  • The headline is optional.
  • The form facet contains at least one label-text pair, and a maximum of 5 pairs.
  • The labels can be invisible, but need to have a text for accessibility purposes.
  • The labels can be icons, but need to have a text for accessibility purposes.
  • Each text in a label-text pair can have a press event.

Form facets are typically used for document information (such as creator and creation time), address or contact information, and general information.

Developer Hint
For non-SAP Fiori element object pages only:

For each label-value pair in the form header facet, use a sap.m.Label and a sap.m.Text or sap.m.Link, nested within an sap.m.HBox.

Header facet - Form facets
Header facet - Form facets

Plain Text Facet

The plain text facet can be used to display a continuous text in the header. It consists of a headline and a continuous text.

  • The width of the facet does not depend on its content, but can be set. The default width of the facet is 300px.
  • The headline is optional.
  • If the headline is broader than the facet width, the headline will wrap.
  • Press events are only available inline in the continuous text. These can be links that navigate to another page or open a quick view. There can be more than one link in the continuous text with different actions.
Developer Hint
For non-SAP Fiori element object pages only:

To set the width of the plain text facet, nest the text within an sap.m.HBox and set the property:width of the sap.m.HBox.

Header facet - Plain text facet with default width
Header facet - Plain text facet with default width
Header Facet - Plain text facet with custom width
Header Facet - Plain text facet with custom width

Image Facet

The image facet can hold exactly one image. The header can have only one image facet, or no image facet.

The image can be:

  • Square or circular
  • An icon
  • Initials consisting of two letters

The image can have a press event. The default press event enlarges the image.

When the header collapses, the image facet moves to the left of the title and becomes smaller.

Recommended usage:

  • Use round images for people, especially for portraits. If no image is available for a person, use the person’s initials instead (first letters of the first and last names).
  • Use square images for all other images. If no image is available for an object, show a suitable icon.

Always make it clear to users how they can upload and manage images. This either be done in edit mode on the object page, or using an external tool. External tools can be helpful if there are a lot of images.

Developer Hint
Always use the avatar control for the image in the header. This applies to both expanded and collapsed images.
Header facet – Image facet specification
Header facet – Image facet specification

Key Value Facet

The key value facet contains a label in a smaller font size and a text or number in a bigger font size. It can be used to highlight important data or KPIs.

If the key value facet is used with a text, such as a status, you can also display an icon to the right of the text. This icon must only be used to visually support the text it relates to, and not to add an another aspect of meaning.

Developer Hint
For non-SAP Fiori element object pages only:

Larger value texts are now possible with the introduction of new properties for the Object Status and Object Number.

Header facet – Key value facets with KPIs and a status
Header facet – Key value facets with KPIs and a status

Micro Chart Facet

The micro chart facet consists of a headline, a subtitle, a micro chart, and a footer.

The headline and the micro chart are mandatory while the subtitle and the footer are optional. To display the unit used in the micro chart, use the footer.

The following micro charts can be used in the micro chart facet:

The micro chart facet can have a click or tap event on the chart itself. This could  lead to a page with a bigger chart or open a quick view, for example.

For more information see micro charts.

Header facet – Micro chart facets
Header facet – Micro chart facets

Progress Indicator Facet

The progress indicator facet consists of a mandatory headline and a progress indicator (sap.m.progressIndicator). In addition, it can have two supplementary texts: a subtitle and a footer.

Header facet - Progress indicator facet
Header facet - Progress indicator facet

Rating Indicator Facet

The rating indicator facet consists of a headline, a rating indicator, and one or two supplementary texts, which are dependent on the use case.

The rating indicator can be modified as described in the rating indicator article.

We recommend the following property settings when using the rating indicator in header facets:

  • 5 symbols as the default.
  • Use the Favorite icon as the symbol.
  • Display half-stars to represent decimal values.

The rating indicator facet can be used for two different use cases, which are described below.

  1. Aggregated rating:

    A typical example of an aggregated rating is the average of several user reviews for a product. The facet for aggregated rating has a mandatory header, an optional subtitle, the rating indicator itself, and a footer.

    Use the subtitle to indicate the amount of data being aggregated. For example, if you show an average rating, the subtitle shows the number of ratings.

    In the footer, display exact aggregation value. Use the format “<average rating> out of <maximum rating>”. For the average rating, use the exact value with one decimal place.
    Example: 2.2 out of 5

  2. Single value rating:

If you display the rating as a single value, the facet has a mandatory header, an optional subtitle, and the rating indicator itself. Here, you can use the subtitle for a supplementary text. Do not use a footer.

Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with singe value rating
Header facet - Rating indicator facet with singe value rating

Toolbars

The object page supports two toolbars:

  • Header toolbar: Use this toolbar for global actions, such as Edit, Delete, Copy, and Share.
  • Floating toolbar: Use this toolbar for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

This applies to all object page modes (display, edit, and create).

Navigation

There are three ways to navigate within the object page:

  • Anchor bar (by default)
  • No navigation (flat scrollable page)
  • Tabs

Usage

  • To offer a flat page for a simple object, use the dynamic page to prevent having sections and navigation. Create the header in the same way as for the object page.
  • For more complex objects, use anchor or tab navigation.

Anchor Bar and Overflow

The anchor bar is the default navigation control for the object page. It consist of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint

Anchor Bar and Overflow

Use title case for the anchor bar texts. To do this, you need to change the default capitalization (block caps) by changing the the property upperCaseAnchorBar to “false”.

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow overview button on the right of the navigation bar ( ) opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow overview button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the document.

Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow overview button
  8. Overflow overview dropdown
  9. Section (hover) in overflow overview
  10. Section in overflow overview
  11. Subsection in overflow overview

Behavior and Interaction

  • Clicking an anchor link scrolls the page to the selected section.
  • Clicking a section anchor that contains more than one subsection opens a subsection menu.
  • Clicking a subsection scrolls the page to the selected subsection. The keyboard left and right arrows allow the user to move between the anchor links.
  • Hovering over the fade area to the left or right of the anchor bar causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
  • Clicking the overflow scroll button (right arrow) scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
  • Clicking the overflow overview button ( ) displays a hierarchical dropdown list with all the sections and subsections of the document. Clicking an item in the overflow list scrolls to the respective section or subsection.

Hiding the Navigation

You can hide the navigation bar from the object page, leaving a flat, scrollable object. We recommend using this flat view for simple content that doesn’t require anchor navigation.

Tab Navigation

As an alternative to anchor navigation, you can also opt for tab navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. Tab navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional and the default state is “false”. If the state is set to “true”, a dropdown arrow is shown next to the tab. Clicking on the tab displays a dropdown menu with the subsection anchors for that tab.

Object page – Tab navigation
Object page – Tab navigation

Breadcrumbs

If the object page uses a hierarchical parent-child drilldown, you can offer a breadcrumb for navigation.

Content Area

The object page content consists of sections and subsections arranged in a column layout. For large documents, you can enable a lazy loading mechanism (property: enableLazyLoading) to mitigate the loading time.

Sections

Sections are containers for subsections. They provide the basic structure for navigation, and are directly reflected in the navigation bar. Sections can have a title, subsections, and actions. However, they cannot contain controls.

Use title case for the section title (property titleUppercase = “false”). The title can have an item counter, which is displayed in parentheses. If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Global actions are always placed at subsection level. Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for global actions at the subsection level.

Subsections

Subsections are the containers for actual content. Always place individual controls inside the subsections. Subsection content is arranged according to the column layout approach for the respective screen size. A subsection can include containers for different controls (mixed content).

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can also display everything by selecting the Show All button at the bottom right of the subsection.

Each subsection can have a toolbar, which is placed at subsection header level on the right. The toolbar contains actions that affect the content of the subsection.

Subsections can have an item counter, which is displayed in parentheses next to the subsection header.

You can include various types of related content in one subsection. The layout blocks for the object page give you the flexibility to combine different content types.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Extra large: 4 columns
  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times, and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

If you are using the object page without object page blocks, you can use the column layout for forms, which automatically distributes form groups across the columns in the object page.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.
Object page – Blocks
Object page – Blocks

Tables

If a section or subsection contains only one table and no other content, remove the table title to avoid having duplicate titles for the table. In this case, the section or subsection title acts as the table title.

If you want to embed analytical tables, grid tables, or tree tables in an object page, use an object page with tabs, and place each table in its own tab. Because the analytical, grid, and tree tables have their own vertical scroll bars, they are not allowed within scrollable object pages. If you are using a scrollable object page without tabs, use a responsive table instead, and offer navigation to a list report with the respective table type.

In an object page, tables with up to 20 expected items can be displayed right away without lazy loading.

If a table is expected to have more than 20 items, use one of the following 3 options for long tables:

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial amount of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, this option should be used only for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. Here it is important to place the table within a tab as the only or at least the last element and to enable the scroll to load behavior.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, the table itself should be restricted to a reasonable amount of items. We recommend only showing a preview of the data in the table, which should not contain more than 20 items. Ideally, you should have about 10 items. This can be either be achieved by prefiltering and/or by sorting the table, and if necessary, by restricting it to a fixed amount of items (such as top 10). To provide the user with a way to work with the entire table, a navigation to a separate list report containing the full table must be offered.  This navigation should be located below the table in the form of a right-aligned link labelled Show All (x), with x representing the total amount of items in the table.

For all of the three options mentioned above, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Grouping should be avoided.

Table with navigation to a separate list report
Table with navigation to a separate list report

Child Page Representation

In object pages with drilldown navigation, child pages are represented in two ways:

  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Item navigation arrows: Up and down arrows in the layout action area allow the user to navigate between subitems without going back to the original list.

Behavior and Interaction

Edit

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create). In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area for edit mode to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see manage objects – create, edit, delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit on a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Create and Edit Subobjects

The following options are available for creating or editing subobjects:

  • Navigation to a subobject page
  • Inline create or inline edit in a table
  • Dialog containing the fields of the object

If the subobject has less than 8 fields, use a dialog or the inline create/edit option (no separate page for the subobject). Exceptions can apply if additional content for the subobject is available but not part of the edit process, or if other apps need to offer deep links to the subobject page.

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:
•Who made the changes
•When the last changes were made

The popover closes when the user clicks or taps the Close icon or anywhere outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, use the placeholder text “New ” (for example, “New Purchase Order”). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Guidelines

Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing clear context.

If you intend to use images in the header for an object, consider the following:

  • How will the user manage the images?
  • How will the system block people without permission from editing images?
  • How will these images be reflected in other floorplans if they are part of the object?
  • If there are a large number of items, how would a user be able to manage images without having to navigate from page to page?
  • Will the organization be able to manage the images?
Developer Hint
How to achieve a small header:

  • The header container is always optional. If there is no important data to be displayed, you can omit it. In this case, only the header title bar is shown.
  • Omit the image if it is not necessary. It is generally the tallest element in a header container.
  • Use a light theme to reduce the emphasis on the header if it doesn’t contain much information.
  • Consider moving information from the header into a general information section.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.

Tab Navigation

Use tab navigation if you need a facet approach to your content. This could be due to performance issues in a flat view, or in response to a specific user preference.

Not a Content Dump

Avoid using the object page as a universal container for masses of information. You should use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.

Simplify Content for Your Users

Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request. Furthermore, only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


List Report Floorplan

Information
This article contains general guidelines for the list report floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the list report floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items within a large set of items by searching, filtering, sorting, and grouping.
  • Users need to display the whole dataset using different visualizations (for example, as a table or as a chart), without requiring interactions between these visualizations. An example use case might be reporting.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. Views can be switched using tabs, segmented buttons, or a select control.
  • Drilldown is rarely or never used, or is only available via navigation to another page, and not as free or flexible drilldown within the page itself.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, and the item or an identifying data point is known to the user (such as a barcode). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the worklist floorplan instead.
  • Users need to extract knowledge or insights from data, either to better understand the current situation, or to identify the root cause for a certain value.  Use the analytical list page instead.
  • Charts are not only used for visualization. Users need to switch between integrated chart and table views (hybrid view). Use the analytical list page instead.
  • Users need to see the impact of their action on a KPI. Use the analytical list page instead.
  • Users need to see not only the result, but also the impact of their filter settings directly in a chart representation. Use the analytical list page instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions, such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a chart, you can display the chart on its own (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.
Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Header Title

Variant Management

Variant management is optional. If you use variants, apply them to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before the dataset is updated. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the format Filtered By (x): followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use the header toolbar for non-finalizing global actions, such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

Header Content

Search

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search terms and the filter criteria.

The search generally searches across all available columns of the table, regardless of whether or not they are visible. In rare cases, some columns might not be included due to technical constraints. If the search does not apply to multiple columns, do not offer the search field.

Filters

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

The header content collapses when the user scrolls down the page (with a responsive table, list, or tree only), and expands again when the user scrolls back up. To avoid this automatic expand/collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.

Users can expand and collapse the header content manually by clicking the background of the title bar. The dynamic page header can also be expanded/collapsed using the Collapse Header ( ) and Expand Header ( ) arrows at the bottom of the header area.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title.

When starting the application, expand the header content if no query was fired (and the table is therefore empty). Otherwise, collapse the header content.

Header Content - Expand / Collapse Behavior

  • List Report (Floorplan + SAP Fiori Element) Header Collapsed - 1.56

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. Multiple views involve one or more of the following:

  • Showing the same table, but with different columns.
  • Showing the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

There are two options for switching between different views:

The first option is to replace the table title with a content switch. Use this approach if all views share the same sort and group states, as well as the same actions.

The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country/Region, View by Customer, …)

The second option for switching views is to show each view in a tab container of the icon tab bar. Use this approach if all views show different states of the same data (sort states, group states, as well as item selection). Using tabs also allows you to offer different actions on the table toolbar for each view.

Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items are selected, or if the action cannot be applied to the selected items. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions
Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are no items to display, use the “no data” text of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    To start, set the relevant filters.
  • The filter was executed, but no items were found. This can also happen if the list report was opened by a related app, and the filter criteria were transferred automatically:
    No data found. Try adjusting the filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is being used for a different target.
    Only show navigation indicators for target pages the user is authorized to access.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer toolbar
Footer toolbar

Actions

Places for actions in the list report
Places for actions in the list report

(1) Global actions in the header toolbar
(2) Table actions in the table toolbar
(3) Line item actions
(4) Finalizing actions in the footer toolbar

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no item is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

If qualifying items can be identified before the action is executed, show a message about how many of the selected items the action will be applied to. In other cases, show a corresponding message after the action was executed.

Hide actions that cannot be used at all (for example, because the user has no authorization). If you are using an icon tab bar, be aware that each tab contains its own table toolbar.

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or the line item is in the wrong state.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Analytical List Page (SAP Fiori Element)

Analytical list page – Size XL
Analytical list page – Size XL

The analytical list page (ALP) offers a unique way to analyze data step by step from different perspectives, to investigate a root cause through drilldown, and to act on transactional content. All this can be done seamlessly within one page. The purpose of the analytical list page is to identify interesting areas within datasets or significant single instances using data visualization and business intelligence.

Visualizations help users to recognize facts and situations, and reduce the number of interaction steps needed to gain insights or to identify significant single instances. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

The main target group are users who work on transactional content. They benefit from fully transparent business object data and direct access to business actions. In addition, they have access to analytical views and functions without having to switch between systems. These include KPIs, a visual filter where filter values are enriched by measures and visualizations, and a combined table/chart view with drill-in capabilities (hybrid view). Users can interact with the chart to dig deep into the data. The visualization enables them to identify spikes, deviations and abnormalities more quickly, and to take appropriate action right away.

Usage

Use the analytical list page if:

  • Users need to extract key information to understand the current situation or identify a root cause. The way the data is presented is crucial for giving them the insights they need to take the right action.
  • Users need a way to analyze data step by step from different perspectives, investigate a root cause through drilldown, and act on transactional content within one page.
  • In addition to the filtered dataset, users need to see the impact of their filter settings in a chart (visual filter).
  • Users need to switch between integrated chart and table views (hybrid view).
  • Users need to see the impact of their action on a global key performance indicator (KPI).
  • Users need to find and act on relevant items out of a large set of items by searching, filtering, sorting, grouping, drilling down, and slicing and dicing.

Do not use the analytical list page if:

  • Drilldown is rarely used, not used at all, or is only needed after navigating to another page, rather than as free or flexible drilldown within the page itself. In this case, a list report might be sufficient for your use case.
  • Users need different visualizations for the entire dataset (for example, as a table or chart), but don’t need to work with both visualizations on the same page (for example, in a reporting scenario). In this case, a list report might be sufficient.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping, without using drilldown or “slice and dice”. In this case, consider using a list report.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. They want to be able to switch views using tabs, segmented buttons, or a select control. In this case, consider using a list report.
  • Users need to see or edit a single item with all its details. Use the object page floorplan instead.
  • Users need to find a specific item, and the item or an identifying data point is known to the user (such as a barcode). In this case, use the initial page floorplan.
  • Users need to work through a comparably small set of items, one by one. In this case, use the worklist floorplan.
  • Users have a trivial use case that does require the use of a chart, but that do not involve identifying a root cause, analyzing data, or drilldown. Instead, use a list report with a table/chart switch.

Structure

This section describes the basic layout of the analytical list page, as well as the different layout variants.

Basic Layout

The shell bar is on top of the analytical list page. The page itself uses the dynamic page layout and has two main areas:

  1. Analytical list page header: The page header has two states: collapsed and expanded. The content shown depends on the state. The user can easily switch the state using the visual indicator.
  2. Analytical list page content area: This area combines three different views and a view switch:
    • Hybrid view (combined chart and table view)
    • Chart-only view
    • Table-only view

All elements are described in more detail in the Components section below.

Analytical list page - Basic layout
Analytical list page - Basic layout

Layout Variants

The layout of the analytical list page is quite flexible. Depending on the state of the analytical page header and the view in the content area, different content is displayed.

For example, the expanded page header allows users to display either the visual filter bar or the filter bar, while the page content area can display either a hybrid view, a chart-only view, or a table-only view.

Analytical List Page Layout Variants

  • ALP - Visual Filter Bar - Expanded
  • ALP - Compact Filter Bar - Hybrid View
  • ALP - Collapsed Filter Bar - Chart and Table View
  • ALP - Visual Filter Bar - Expanded - Chart View
  • ALP - Compact Filter Bar - Expanded - Chart View
  • ALP - Filter Bar - Collapsed - Chart View
  • ALP - Visual Filter Bar - Expanded - Table View
  • ALP - Collapsed Filter Bar - Table View
  • ALP - Filter Bar - Collapsed - Table View

Responsiveness

The analytical list page is responsive, except for the global KPIs. Apps with one or more global KPIs are not supported on screen sizes smaller than size L (desktop).

Likewise, the analytical list page is only fully supported in the flexible column layout if no global KPIs are used. If you use the analytical list page with global KPIs within the flexible column layout, the column should have at least size M.

Size S

On size S, the analytical list page supports both the chart-only and table-only views. The table-only view supports only the responsive table. If no responsive table is available, the chart-only view is displayed without a view switch toggle.

Global KPIs are not supported on size S.

Size M

On size M, the analytical list page supports both the chart-only and table-only views. You can use a responsive table or analytical table in the table-only view.

Chart-only view - Size S
Chart-only view - Size S
Table-only view - Size S
Table-only view - Size S
Chart-only view - Size M
Chart-only view - Size M
Table-only view - Size M
Table-only view - Size M

Component Overview

Analytical List Page Header

The page header can be expanded and collapsed on click/tap. Different content is shown in the expanded and collapsed states. For more information about the basic behavior of the header, see Dynamic Page Header.

Collapsed Header

The collapsed page header contains the following elements:

Collapsed analytical list page header
Collapsed analytical list page header

Expanded Header

The expanded page header contains the following elements:

Expanded analytical list page header showing the visual filter bar
Expanded analytical list page header showing the visual filter bar
Expanded analytical page header showing compact filters in the filter bar
Expanded analytical page header showing compact filters in the filter bar

Analytical List Page Content Area

The analytical list page content area contains the following elements:

  • View switch (   |    |    )
  • Hybrid view: View with one chart, chart toolbar, one table, and a table toolbar
  • Chart-only view: View with one chart and a chart toolbar
  • Table-only view: View with one table and a table toolbar

Analytical List Page Content Area

  • Hybrid view
  • Chart-only view
  • Table-only view

Analytical List Page Header

Variant Management

Variant management in the analytical list page allows users to save a page variant whenever there are changes in the underlying structures of the filter/content area. Variant management for the page is handled by the standard SAPUI5 page variant management.

Currently, the page variant captures the following states across the page:

  • Filter view switch state: Visual filter bar or filter bar
  • Filter set: The filters set in the visual filter bar and filter bar
  • Filter selections: Selected values in the visual filter bar and filter bar
  • Content view switch state: hybrid view  , chart-only view  , or table-only view  
  • Chart and table configurations, such as measures and dimensions used, sort order, or grouping
  • Chart drill-down state, based on the current selections (slice & dice)
  • Table entry switch state: Hide (  ) or Show  (  ) selected table records
Standard page variant management
Standard page variant management

Global KPI Tags and Cards

Use a global KPI tag (= global key performance indicator tag) if you would like to show a global KPI related to the task in hand. The global KPI value changes only if an action is executed on the transactional content. For example, the user needs to know the effect of releasing sales orders on a related global KPI, or the effect of posting an accounting document on certain financial global KPIs.

You can display a maximum of three global KPIs. Clicking a global KPI tag opens a global KPI card that displays more details on the KPI.

The global KPI tags and corresponding KPI cards are independent of the filter area. This means that global KPI tags do not react to filters set in the visual filter bar and filter bar.

A global KPI tag has four components:

  • Global KPI label
  • Global KPI value
  • Global KPI color and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator

Global KPI Label

The global KPI label is an abbreviation of the complete global KPI title. It is formed using the first three letters of the first three words of the global KPI title.
Examples: AMR for Actual Monthly Revenue, TAR for Total Advertising Revenue, or LPC for Landing Page Conversation Rates

If there is only one word in the global KPI title, the first three letters of the word are displayed. Example: CON for Contracts

If the global KPI title has only two words, only the first letters of these two words are displayed. Examples: AC for Actual Costs, SG for Sales Growth

KPI label abbreviation: AC
KPI label abbreviation: AC

Global KPI Value

The global KPI value is displayed using a semantic color and a scaling factor. Relative values are shown with a percentage sign and one decimal place.
Examples: 0.3%, 82.9%
Absolute values are shown without decimal places, a currency, or a unit of measure.
Examples: 2K, 75K, 30M, 14B

KPI values: 2K and 0.3%
KPI values: 2K and 0.3%

Global KPI Color and Criticality Indicator

The color of the global KPI value is based on the thresholds defined for the particular KPI in the annotation. The global KPI tag also uses a line to indicate the criticality. The color of the line is the same as that of the global KPI value.

KPI color and criticality indicator
KPI color and criticality indicator

Global KPI Card

Clicking the KPI tag opens the analytical card, which displays more information about the current value of the global KPI, the global KPI target, the deviation from the target, and how the global KPI has evolved over time.

Global KPI card
Global KPI card

Filter Area: Visual Filter Bar and Filter Bar

The filter area allows users to filter the result set, which feeds the main content area. The analytical list page comes with two filter types: compact filters in the filter bar, and the visual filter bar. Always design both visual filters and compact filters (filter bar) for your app. We recommend setting the visual filter bar as the default, but this is no longer mandatory. You can opt to use the (compact) filter bar as the default if your app has the required parameter values, if your main use case involves date ranges, or if your users often need to combine multiple filters in different ways.

Currently, any visual filter configured in the visual filter bar must always be displayed as a compact filter in the filter bar as well. By contrast, a filter configured as a compact filter in the filter bar may or may not be configured for display as a visual filter. This means that it’s possible to have a smaller set of visual filters and a larger set of compact filters.

Both filter types supports two different modes: live update and manual update. Use the live update mode for both filter types as the default whenever possible. Apply the same mode to both filter types: the visual filter bar and the filter bar. For example, if you use the live update mode in the visual filter bar, you should also use the live update mode for the filter bar.

Visual filter bar
Visual filter bar
Filter bar
Filter bar

Filter Type Switch

Users can toggle between the compact filters    (filter bar) and    (visual filter bar) in the upper-right area of the page header. The filter type switch is a core feature of the analytical list page and is mandatory. The switch is only displayed when the page header is expanded. Once the header collapses, it disappears.

Filter type switch
Filter type switch

Carrying Forward Filter Selections

Visual Filter to Compact Filter

Any values selected in the visual filters are always carried forward to the corresponding compact filters.

Compact Filter to Visual Filter

Filter dimensions that are part of a visual filter are synced to the visual filter. If the dimension value(s) chosen in the compact filter are part of a visual filter, they are shown as selected chart dimensions in the visual filter (single or multiple selections).

Filter dimensions that are not part of the visual filter, parameter values, and interval-based dimensions are applied to the filter query and the content is refreshed.

To show complex conditions, click the link for the number of selected items at the top of the visual filter.

Visual Filter Bar

The visual filter bar combines measures or item counts with filter values. The visual filter bar becomes more powerful if you match measures to the filter dimension instead of just item counts. Use the visual filter bar if you would like to give the user a condensed overview of the data in the dataset. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

Chart Types in the Visual Filter Bar

Currently, the visual filter bar supports three interactive chart types:

These interactive charts are also referred to as visual filters.

Interactive Donut Chart

The interactive donut chart in the visual filter bar is used for non-time-related data (for example, categories) and displays only the top or bottom two values. The rest are aggregated into the “Other” section.

Interactive donut chart
Interactive donut chart
Interactive donut chart with semantic colors
Interactive donut chart with semantic colors

Interactive Line Chart

The interactive line chart is used exclusively for displaying time series data, and can show a maximum of six data points. Always show the first or last six data points (for example, last six days, last six months, first six days, and so on).

Interactive line chart
Interactive line chart
Interactive line chart with semantic colors
Interactive line chart with semantic colors

Interactive Bar Chart

The interactive bar chart can be used for non-time-related data (for example, categories) and has a maximum of three filter values. These filter values show the top three or bottom three entries.

Interactive bar chart
Interactive bar chart
Interactive bar chart with semantic colors
Interactive bar chart with semantic colors

Using Interactive Charts

The interactive charts come with the following features and rules:

  • Minimum number of interactive charts: Show at least three visual filters and try to use different chart types.
  • Filter title:
    • Use the following naming convention for the filter title, using title case:
      [Measure Name] by [Dimension Name] | [Scale Factor] [Unit of Measure].
      Examples:
      Project Costs by Project | K EUR
      Sales Volume by Commodity | M PC
    • For an item count, use the following naming convention for the filter title, using title case:
      Number of [Dimension] | [Scale Factor] [Unit of Measure].
      Examples:
      Number of Products | PC
      Number of Contracts by Month
    • Note that for some use cases, it might be appropriate to replace “Number” with a different expression. Bear in mind that the space for displaying the filter title is limited. If the measure and/or dimension names are longer than the predefined space, the text will be truncated.
Filter title with truncation
Filter title with truncation
Filter title without truncation
Filter title without truncation
  • Filter-to-filter dependencies: Ideally, the filters depend on each other. By selecting one or several chart data points, users can perform a quick analysis of the dataset.
    Examples: Supplier with the lowest supplier performance this year, product with the highest sales volume in March in the EMEA region
  • Adding additional filter values: All charts have a maximum number of filter values that can be displayed within the chart itself. More filter values can be selected using the value help or the select popover.
  • Selected values: Any data point or segment that is selected in the visual filter’s interactive charts will remain selected even when the user changes the measure, chart type, or sort order in any of the charts. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.
  • Semantic colouring: All interactive charts support semantic colors to indicate the criticality of filter values.
  • How to design a visual filter: To design a visual filter, choose a meaningful measure out of the dataset and match it to a filter dimension. If no measures or no meaningful measures are available, use an item count instead. Have a look at the visual filter bar article for more information.

Filter Dialog

In the filter dialog, the user can switch between the visual filter bar filters and the filter bar filters using a toggle button. The standard filter dialog is explained in the Filter Bar article. The part for the visual filter is further explained below.

Filter Dialog for Visual Filters

The filter dialog is launched by clicking the Adapt Filters ([number of applied filters]) link in the page header area. In the filter dialog for visual filters, the user can choose which filter fields are shown in the visual filter bar, and make the following changes:

  • Add visual filters
  • Delete visual filters
  • Hide visual filters in the visual filter bar
  • Search for visual filters
  • Change the sort order  of each visual filter
  • Change the chart type   of each visual filter
  • Switch to other measures  in the visual filter display

Analytical List Page Content Area

The content area shows different visualizations of the selected data. In the hybrid view, users can interact with both the chart and table visualizations at the same time. In addition, the analytical list page supports a chart-only view and a table-only view. The analytical list page always comes with all three views. Offering additional views or even tabs would add too much complexity, and is neither supported nor recommended.

Check out the following sections for more details on the hybrid view, chart-only view, and table-only view.

Hybrid View

The hybrid view uses both chart and table visualizations at the same time. It enables users to analyze data step by step from different perspectives. Users can interact with both the chart and the table, and drill down through either the smart chart or table entries to investigate a root cause. They can also act directly on transactional content. In the initial view of the chart, visualize the most important aspects of the whole dataset in the chart.

Example: The view shows all the suppliers the user is responsible for, organized by value. By drilling down the material to the plant with the highest/lowest volume, the user can see if materials need to be shifted from one plant to another. The corresponding transactional data is shown in an analytical table below the chart, which might also offer an action for shifting the material.

Analytical list page - Hybrid view
Analytical list page - Hybrid view

Chart-Only View

The chart-only view enables users to analyze data step by step from different perspectives, and to investigate a root cause through drilldown, without direct access to transactional content. The smart chart control provides the chart visualization in the chart-only and hybrid views: it is used to display the dataset as a chart. The smart chart drilldown functionality provides a convenient way to analyze the dataset. In addition, the smart chart offers detailed information on the chart data and a breadcrumb that shows the drilldown path. Ensure that you show the most important aspects of the dataset in the chart.

This mode is perfect for applications with analytical data that can easily be represented visually using charts, but doesn’t need to be linked to the transactional dataset.

Analytical list page - Chart-only view
Analytical list page - Chart-only view

Table-Only View

The table view provides access to transactional content. The user can act on single or multiple objects, and navigate to the object details or to other applications.

Depending on the use case, you can opt to use either the analytical table or the responsive table.

Snapping or scrolling is not available for desktop-focused tables, such as the analytical table. Scrolling is only available when the responsive table is used. The table entries are loaded using lazy loading.

Users can apply filters at table level using the Settings button ( ). For analytical tables, filtering is also available at column level. For more information, see Analytical Table (ALV) – Filter.

Analytical list page - Table-only view
Analytical list page - Table-only view

Behavior and Interaction

Open and View the Global KPI Card via the Global KPI Tag

Clicking/tapping a KPI tag opens the KPI card, which shows the details for the particular KPI.

Select Filters in the Visual Filter

Unlike micro charts, the visual filter charts are interactive. In live search mode, selecting a filter value triggers data filtering in the content area. Both single and multiple selection are supported.

To select a filter value, the user clicks on a value in the chart. The filter can be removed by either clicking on the value help link, or by clicking on the same value in the chart again. The user can select more filter values using the value help or select popover.

Any data point that is selected in a chart still remains selected when the user selects a data point in another chart. Filter values react on each other. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.

Switch Views: Hybrid, Chart-Only, and Table-Only

Users can switch between the hybrid view, chart-only view, and table-only view.

If the user selects values and then switches the view, the selection remains intact. See the table below for more details.

Switch Description
Hybrid view to table view Table selection remains intact
Hybrid view to chart view Chart selection remains intact
Chart view to hybrid view Chart selection remains intact; corresponding table selections are displayed
Table view to hybrid view Table selection remains intact

Show/Hide Table Entries in Hybrid View and Table View

The table toolbar for the analytical list page offers a Show   and Hide    table entries feature as a toggle switch in the hybrid and table views:

  • If the Show icon is active, the table shows all items. These include highlighted entries (where values are selected in the chart) and non-highlighted entries.
  • If the Hide icon is active, the table shows only items that are selected in the chart.

For example, if the user selects SAP’s Sales Revenue for 2012 as Customer in the chart, all records relating to SAP’s Sales Revenue for 2012 are highlighted (but not selected) in the table. Note that the record is still highlighted even if Customer not displayed as a column in the table. If the table rows are grouped, the entire grouping is highlighted, even if only one record within the grouped set is affected by the chart selection. All values that are not selected in the chart are “hidden” and are not shown in this table mode.

Guidelines

Show the filter dimension with one measure in the visual filter, not multiple measures

Filter dimensions in the compact filters (filter bar) have exactly one representation in the visual filter bar.
Do not show the same filter dimension with two or more different measures at the same time in the visual filter bar. The example shows the filter Dimension Year with two different measures Revenue and Quantity. Showing the filter dimensionYear twice is not in sync with the compact filter, where it is shown only once. Furthermore, matching between the two filter types will not work.

If the use case requires you to show a dimension with different measures, consider using an overview page instead.

Do
For each dimension display exactly one representation in the visual filter bar.
For each dimension display exactly one representation in the visual filter bar.
Don't
Do not use the same filter dimension with different measures
Do not use the same filter dimension with different measures

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Overview Page (SAP Fiori Element)

View, Filter, and Take Immediate Action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page.

The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

At a Glance

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Micro actions let users react on the spot

Overview page – Fixed card layout
Overview page – Fixed card layout

Usage

Use the overview page if:

  • You want to provide an entry-level view of content related to a specific domain or role.
  • Users needs to filter and react to information from at least two different applications to complete their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page.
  • You plan to have at least three cards. These cards should not all be of the same type.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page instead.
  • You want to show information about one object only. In this case, use the object page instead.
  • You just represent one application and less than three cards. In this case, use the object page instead.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

As you can see in the picture, the overall content scope (shown in gray) becomes more focused with each interaction step. An overview page brings together information from different sources that support a specific task or information need. Only provide an overview app for a role if it makes sense to do so.

If a role or user has several main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, with information for managing team performance reviews. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that the user is responsible for in the role of quality manager.

Metaphor – Different entry points in SAP Fiori
Metaphor – Different entry points in SAP Fiori

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps. In addition, users can also access the navigation menu in the shell bar, which allows fast and easy navigation to other apps. The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window.

In the screen flow, always position the overview page app between the SAP Fiori launchpad home page and the SAP Fiori app. The overview page doesn’t replace the SAP Fiori launchpad home page. Never start overview page apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Usually, several floorplans can be combined in one app. The overview page floorplan is an exception.
Usually, several floorplans can be combined in one app. The overview page floorplan is an exception.

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards.

The card layout determines the size and position of the cards.
Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

The overview page can consume four different variants of the dynamic page. These variants support different user needs and provide flexibility for application designers. None of the variants include the footer toolbar.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar. In addition, the variant management control lets users share user-defined variants (Save View feature).

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. The initial default uses the collapsed mode, because content is already available on the cards, and users can start right away. When the user scrolls or clicks, the header content expands as defined. The header title offers the Share menu, which enables the actions „Send Email“ and „Save as Tile“.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 (default) – Collapsed mode for size XL/L/M
Dynamic page variant 1 (default) – Collapsed mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Collapsed mode for size S
Dynamic page variant 1 – Collapsed mode for size S
Share menu
Share menu

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text (“Header Title” in the example below). This text serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size S
Dynamic page variant 2 – Expanded/collapsed mode for size S

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size S
Dynamic page variant 3 – Size S

Variant 4 – Text in the Header Title and Smart Filter Bar

In this variant, the header title contains a text (“Header Title” in the example below), and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Collapsed mode for size XL/L/M
Dynamic page variant 4 – Collapsed mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Collapsed mode for size S
Dynamic page variant 4 – Collapsed mode for size S

Overview Page Layout

The fixed card layout describes the position, size, and characteristics of cards in the content area below the dynamic page header. The layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes.

Only place cards on the overview page. Never add tiles.

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the User Menu under Manage Cards. A dialog appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Each overview page app has its own Manage Cards setting. Users who work with several overview pages can personalize the cards shown for each one.

Overview page – 'Manage cards' dialog after initial loading
Overview page – 'Manage cards' dialog after initial loading

Cards

Overview page – Variety of different card types (extract)
Overview page – Variety of different card types (extract)

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. The overview page can contain several cards that reference the same (parent) application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Cards can display different types of content. They can show a chart, a list, a table, informative text, or a combination of two elements.  However, cards never have editable fields.

When designing cards, make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

For more information about cards and card types, see the dedicated articles:

Best Practices

Before you start designing an overview page, familiarize yourself with following best practices to optimize the user experience. They reflect the basic findings of multiple usability tests across different scenarios and user groups.

  • Make a conscious decision on the number of cards: Show only cards that really support the specific role context or task.
  • Accentuate the most important information: Semantic colors in texts, charts, and images attract more attention.
  • Offer a well-balanced mixture of card types: Diversity makes it easy to recognize, select, and read information.
  • Define a deliberate card order: Users assume that cards at the top of the page are more important than others.
  • Group similar topics: Users assume that related cards will be shown next to each other.
  • Choose easy-to-read and actionable texts: If the user needs to take action, use the active voice (for example “Reorder Soon” when stocks are running low).
  • Be semantically consistent: Users expect crucial terms like „urgent“ or “out of stock” to be highlighted with semantic colors.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

Overview Page (SAP Fiori Element)

View, Filter, and Take Immediate Action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page.

The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

At a Glance

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Micro actions let users react on the spot

Overview page – Fixed card layout
Overview page – Fixed card layout

Usage

Use the overview page if:

  • You want to provide an entry-level view of content related to a specific domain or role.
  • Users needs to filter and react to information from at least two different applications to complete their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page.
  • You plan to have at least three cards. These cards should not all be of the same type.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page instead.
  • You want to show information about one object only. In this case, use the object page instead.
  • You just represent one application and less than three cards. In this case, use the object page instead.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

As you can see in the picture, the overall content scope (shown in gray) becomes more focused with each interaction step. An overview page brings together information from different sources that support a specific task or information need. Only provide an overview app for a role if it makes sense to do so.

If a role or user has several main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, with information for managing team performance reviews. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that the user is responsible for in the role of quality manager.

Metaphor – Different entry points in SAP Fiori
Metaphor – Different entry points in SAP Fiori

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps. In addition, users can also access the navigation menu in the shell bar, which allows fast and easy navigation to other apps. The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window.

In the screen flow, always position the overview page app between the SAP Fiori launchpad home page and the SAP Fiori app. The overview page doesn’t replace the SAP Fiori launchpad home page. Never start overview page apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Usually, several floorplans can be combined in one app. The overview page floorplan is an exception.
Usually, several floorplans can be combined in one app. The overview page floorplan is an exception.

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards.

The card layout determines the size and position of the cards.
Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

The overview page can consume four different variants of the dynamic page. These variants support different user needs and provide flexibility for application designers. None of the variants include the footer toolbar.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar. In addition, the variant management control lets users share user-defined variants (Save View feature).

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. The initial default uses the collapsed mode, because content is already available on the cards, and users can start right away. When the user scrolls or clicks, the header content expands as defined. The header title offers the Share menu, which enables the actions „Send Email“ and „Save as Tile“.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 (default) – Collapsed mode for size XL/L/M
Dynamic page variant 1 (default) – Collapsed mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Collapsed mode for size S
Dynamic page variant 1 – Collapsed mode for size S
Share menu
Share menu

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text (“Header Title” in the example below). This text serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size S
Dynamic page variant 2 – Expanded/collapsed mode for size S

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size S
Dynamic page variant 3 – Size S

Variant 4 – Text in the Header Title and Smart Filter Bar

In this variant, the header title contains a text (“Header Title” in the example below), and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Collapsed mode for size XL/L/M
Dynamic page variant 4 – Collapsed mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Collapsed mode for size S
Dynamic page variant 4 – Collapsed mode for size S

Overview Page Layout

The fixed card layout describes the position, size, and characteristics of cards in the content area below the dynamic page header. The layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes.

Only place cards on the overview page. Never add tiles.

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the Me Area under Manage Cards. A dialog appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Each overview page app has its own Manage Cards setting. Users who work with several overview pages can personalize the cards shown for each one.

Overview page – 'Manage Cards' dialog
Overview page – 'Manage Cards' dialog
Overview page – 'Manage cards' dialog after initial loading
Overview page – 'Manage cards' dialog after initial loading

Cards

Overview page – Variety of different card types (extract)
Overview page – Variety of different card types (extract)

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. The overview page can contain several cards that reference the same (parent) application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Cards can display different types of content. They can show a chart, a list, a table, informative text, or a combination of two elements.  However, cards never have editable fields.

When designing cards, make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

For more information about cards and card types, see the dedicated articles:

Best Practices

Before you start designing an overview page, familiarize yourself with following best practices to optimize the user experience. They reflect the basic findings of multiple usability tests across different scenarios and user groups.

  • Make a conscious decision on the number of cards: Show only cards that really support the specific role context or task.
  • Accentuate the most important information: Semantic colors in texts, charts, and images attract more attention.
  • Offer a well-balanced mixture of card types: Diversity makes it easy to recognize, select, and read information.
  • Define a deliberate card order: Users assume that cards at the top of the page are more important than others.
  • Group similar topics: Users assume that related cards will be shown next to each other.
  • Choose easy-to-read and actionable texts: If the user needs to take action, use the active voice (for example “Reorder Soon” when stocks are running low).
  • Be semantically consistent: Users expect crucial terms like „urgent“ or “out of stock” to be highlighted with semantic colors.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

Worklist Floorplan

Information
This article contains general guidelines for the worklist floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the worklist floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

A worklist displays a collection of items that a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan is on processing the items. This differs from the list report floorplan, which focuses on finding and acting on relevant items from a large dataset.

Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Users need to work with multiple views of the same content (for example, items that are “Open”, “In Process”, or “Completed”. Users can switch between views using the tab bar.

Do not use the worklist floorplan if:

  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (charts or tables). In this case, use the list report floorplan instead.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping. Use the list report floorplan instead.

Layout

The worklist floorplan is based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, KPI information (if relevant), and a header toolbar with global actions, such as Share.
  • The content area: Use this to display:
    • An icon tab bar in the content area
    • One table (per tab)
    • You can use any kind of table and list. To ensure that the application runs on all devices, we recommend using the responsive table.
Basic structure
Basic structure

Responsiveness and Adaptiveness

In general, the worklist floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

Worklist floorplan - Size S
Worklist floorplan - Size S
Worklist floorplan - Size M
Worklist floorplan - Size M
Worklist floorplan - Size L
Worklist floorplan - Size L

Guidelines

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a table.

Simple worklist without tabs
Simple worklist without tabs

Worklist with Tabs

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs show different perspectives on the same dataset.

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red for the Error tab).

Worklist with tab categories
Worklist with tab categories

Worklist with KPI

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI within the KPI container next to the page title as an object status.

Worklist with KPI
Worklist with KPI

Header Title

Variant Management

Variant management is optional. If used, apply it to the whole page. Use the variants to save and restore all settings, including selected tabs, all tables, and all personalization settings.

If variant management is not needed, just show a title that describes the current view instead.

Header Toolbar (Global Actions)

Use this for non-finalizing global actions such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

In addition, offer any other global, non-finalizing actions that are needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Page Content

Tab Bar

The tab bar is part of the page content container, which means that the tab bar is not “sticky” and will scroll away when the user scrolls down the page.

Use the icon tab bar. Display the number of items shown in the table on each tab (sap.m.IconTabFilter, property: count). Only use icons if you need to display semantic colors on the icon tab bar.

The tab bar works as a filter on the content below.

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. For filter, sort, and group, show a view settings dialog with only the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items or only unsuitable items are selected. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table actions, see the guidelines for the table toolbar and for managing objects.

Table

If there are no items to display, use the “no data text” of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • The search was executed, but no items were found: No items found. Try adjusting your search criteria.
  • By opening a related app, the filter criteria were transferred automatically, but no items were found: No items found. Check the search and filter settings.

There are three types of navigation at item level in the worklist floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation. In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation. Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is used for a different target.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually a list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting. In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object, as well as a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Actions

The worklist offers four locations for actions: global actions, table actions, line item actions, and finalizing actions.

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the standard Share action.

The Share button opens an action sheet that contains actions like Save as Tile (if the SAP Fiori Launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space in the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

Global actions
Global actions

2. Table Actions

Place actions that affect the content of a table in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no item is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on table actions, see the guidelines for the table toolbar and for managing objects.

Toolbar actions
Toolbar actions

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this option only for specific, frequently-used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or if the line item has the wrong state, for example.

Inline actions
Inline actions

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Finalizing actions
Finalizing actions

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen. Once the user has completed the task, the app should:

  • Return the user to the worklist
  • Remove the processed item from the list, or move it to a “completed” section
  • Confirm the user’s action with a message toast

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object Page Floorplan

Information
This article contains general guidelines for the object page floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the object page floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

The object page floorplan allows the user to display, create, or edit an object. This is the recommended floorplan for representing both simple and complex objects in SAP Fiori. The object page floorplan comes with a flexible header, a choice of anchor or tab navigation, and a flexible, responsive layout. These features make it adaptable for a wide range of use cases.

Object page floorplan
Object page floorplan

Usage

Use the object page floorplan if:

  • Users need to see, edit, or create an item with all its details.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

  • Users want to edit several items at the same time. Use the list report floorplan instead.
  • Users need to find relevant items without knowing the exact item details. Use the list report floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner). Use the initial page floorplan instead.
  • Users need to be guided through a series of steps when a new object is created. Use the wizard floorplan instead.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected. Use the wizard floorplan instead.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL).

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The layout for size XL (large display) contains four columns.

The default layout for size L (desktop) contains three columns. If you want to display two content elements that require an equal amount of space, you can also use an optional two-column layout (for example, two tables next to each other). Do not use the two-column layout with forms.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Structure

Warning
Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility. For details, see the Header section below.

The object page is a full screen floorplan with a display mode, a create mode, and an edit mode.

In all modes, the object page contains:

  • A dynamic header
  • A navigation bar (optional)
  • A content area

The following sections explain these components in more detail.

Schematic visualization of the object page
Schematic visualization of the object page

Header

The header is the uppermost element of the object page floorplan. It contains key information about the business object and provides the user with the necessary context. The header also contains global actions for the object.

Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility.

The header consists of the following elements:

  1. Title (mandatory)
  2. Subtitle (optional)
  3. Global actions (optional)
  4. Object marker (optional, placed in the key information container of the dynamic header)
  5. Header content (optional)
  6. Breadcrumbs (optional)
  7. Visual indicator (mandatory if the header can be collapsed and expanded)
Object page with the dynamic header
Object page with the dynamic header

If the object page is used in the flexible column layout, it can also contain navigation actions.

Please note:

  • To display images and placeholders in the header, use the avatar control.
  • The subtitle is now below the title. (For the former object page header it was next to the title.)

For an example of an object page with the dynamic header, see this SAPUI5 sample. A sample with an image can be found here.

For more information, see the Dynamic Header section for the dynamic page layout.

Header Facets

The header content is optional and is located below the title.

It can be used to display app-specific contextual information. You build the content using smaller content containers, called facets. Each facet contains a distinct information set, as described below. If there aren’t any facets, the header content is always hidden.

The facets are arranged in line with a left float. Each facet adapts its size to the content and makes optimal use of the space without truncating the texts. If the facets do not all fit on one line, those on the right wrap to the line below.

If the header collapses, the header content is hidden. If the header content is empty, you can also hide it.

There are several types of header facets, depending on the data that they display. The facets need to be handmade for stand-alone object pages.

Form Facet (Dataset)

The form facet can be used to display datasets in the header. It consists of a headline and up to five label-text pairs.

  • The headline is optional.
  • The form facet contains at least one label-text pair, and a maximum of 5 pairs.
  • The labels can be invisible, but need to have a text for accessibility purposes.
  • The labels can be icons, but need to have a text for accessibility purposes.
  • Each text in a label-text pair can have a press event.

Form facets are typically used for document information (such as creator and creation time), address or contact information, and general information.

Developer Hint
For non-SAP Fiori element object pages only:

For each label-value pair in the form header facet, use a sap.m.Label and a sap.m.Text or sap.m.Link, nested within an sap.m.HBox.

Header facet - Form facets
Header facet - Form facets

Plain Text Facet

The plain text facet can be used to display a continuous text in the header. It consists of a headline and a continuous text.

  • The width of the facet does not depend on its content, but can be set. The default width of the facet is 300px.
  • The headline is optional.
  • If the headline is broader than the facet width, the headline will wrap.
  • Press events are only available inline in the continuous text. These can be links that navigate to another page or open a quick view. There can be more than one link in the continuous text with different actions.
Developer Hint
For non-SAP Fiori element object pages only:

To set the width of the plain text facet, nest the text within an sap.m.HBox and set the property:width of the sap.m.HBox.

Header facet - Plain text facet with default width
Header facet - Plain text facet with default width
Header Facet - Plain text facet with custom width
Header Facet - Plain text facet with custom width

Image Facet

The image facet can hold exactly one image. The header can have only one image facet, or no image facet.

The image can be:

  • Square or circular
  • An icon
  • Initials consisting of two letters

The image can have a press event. The default press event enlarges the image.

When the header collapses, the image facet moves to the left of the title and becomes smaller.

Recommended usage:

  • Use round images for people, especially for portraits. If no image is available for a person, use the person’s initials instead (first letters of the first and last names).
  • Use square images for all other images. If no image is available for an object, show a suitable icon.

Always make it clear to users how they can upload and manage images. This either be done in edit mode on the object page, or using an external tool. External tools can be helpful if there are a lot of images.

Developer Hint
Always use the avatar control for the image in the header. This applies to both expanded and collapsed images.
Header facet – Image facet specification
Header facet – Image facet specification

Key Value Facet

The key value facet contains a label in a smaller font size and a text or number in a bigger font size. It can be used to highlight important data or KPIs.

If the key value facet is used with a text, such as a status, you can also display an icon to the right of the text. This icon must only be used to visually support the text it relates to, and not to add an another aspect of meaning.

Developer Hint
For non-SAP Fiori element object pages only:

Larger value texts are currently only available in SAP Fiori elements. For non-SAP Fiori element apps, the value texts have the same size as the label, as custom CSS should not be used.

Header facet – Key value facets with KPIs and a status
Header facet – Key value facets with KPIs and a status

Micro Chart Facet

The micro chart facet consists of a headline, a subtitle, a micro chart, and a footer.

The headline and the micro chart are mandatory while the subtitle and the footer are optional. To display the unit used in the micro chart, use the footer.

The following micro charts can be used in the micro chart facet:

The micro chart facet can have a click or tap event on the chart itself. This could  lead to a page with a bigger chart or open a quick view, for example.

For more information see micro charts.

Header facet – Micro chart facets
Header facet – Micro chart facets

Progress Indicator Facet

The progress indicator facet consists of a mandatory headline and a progress indicator (sap.m.progressIndicator). In addition, it can have two supplementary texts: a subtitle and a footer.

Header facet - Progress indicator facet
Header facet - Progress indicator facet

Rating Indicator Facet

The rating indicator facet consists of a headline, a rating indicator, and one or two supplementary texts, which are dependent on the use case.

The rating indicator can be modified as described in the rating indicator article.

We recommend the following property settings when using the rating indicator in header facets:

  • 5 symbols as the default.
  • Use the Favorite icon as the symbol.
  • Display half-stars to represent decimal values.

The rating indicator facet can be used for two different use cases, which are described below.

  1. Aggregated rating:

    A typical example of an aggregated rating is the average of several user reviews for a product. The facet for aggregated rating has a mandatory header, an optional subtitle, the rating indicator itself, and a footer.

    Use the subtitle to indicate the amount of data being aggregated. For example, if you show an average rating, the subtitle shows the number of ratings.

    In the footer, display exact aggregation value. Use the format “<average rating> out of <maximum rating>”. For the average rating, use the exact value with one decimal place.
    Example: 2.2 out of 5

  2. Single value rating:

If you display the rating as a single value, the facet has a mandatory header, an optional subtitle, and the rating indicator itself. Here, you can use the subtitle for a supplementary text. Do not use a footer.

Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with singe value rating
Header facet - Rating indicator facet with singe value rating

Toolbars

The object page supports two toolbars:

  • Header toolbar: Use this toolbar for global actions, such as Edit, Delete, Copy, and Share.
  • Floating toolbar: Use this toolbar for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

This applies to all object page modes (display, edit, and create).

Navigation

There are three ways to navigate within the object page:

  • Anchor bar (by default)
  • No navigation (flat scrollable page)
  • Tabs

Usage

  • To offer a flat page for a simple object, use the dynamic page to prevent having sections and navigation. Create the header in the same way as for the object page.
  • For more complex objects, use anchor or tab navigation.

Anchor Bar and Overflow

The anchor bar is the default navigation control for the object page. It consist of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint

Anchor Bar and Overflow

Use title case for the anchor bar texts. To do this, you need to change the default capitalization (block caps) by changing the the property upperCaseAnchorBar to “false”.

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow overview button on the right of the navigation bar ( ) opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow overview button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the document.

Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow overview button
  8. Overflow overview dropdown
  9. Section (hover) in overflow overview
  10. Section in overflow overview
  11. Subsection in overflow overview

Behavior and Interaction

  • Clicking an anchor link scrolls the page to the selected section.
  • Clicking a section anchor that contains more than one subsection opens a subsection menu.
  • Clicking a subsection scrolls the page to the selected subsection. The keyboard left and right arrows allow the user to move between the anchor links.
  • Hovering over the fade area to the left or right of the anchor bar causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
  • Clicking the overflow scroll button (right arrow) scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
  • Clicking the overflow overview button ( ) displays a hierarchical dropdown list with all the sections and subsections of the document. Clicking an item in the overflow list scrolls to the respective section or subsection.

Hiding the Navigation

You can hide the navigation bar from the object page, leaving a flat, scrollable object. We recommend using this flat view for simple content that doesn’t require anchor navigation.

Tab Navigation

As an alternative to anchor navigation, you can also opt for tab navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. Tab navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional and the default state is “false”. If the state is set to “true”, a dropdown arrow is shown next to the tab. Clicking on the tab displays a dropdown menu with the subsection anchors for that tab.

Object page – Tab navigation
Object page – Tab navigation

Breadcrumbs

If the object page uses a hierarchical parent-child drilldown, you can offer a breadcrumb for navigation.

Content Area

The object page content consists of sections and subsections arranged in a column layout. For large documents, you can enable a lazy loading mechanism (property: enableLazyLoading) to mitigate the loading time.

Sections

Sections are containers for subsections. They provide the basic structure for navigation, and are directly reflected in the navigation bar. Sections can have a title, subsections, and actions. However, they cannot contain controls.

Use title case for the section title (property titleUppercase = “false”). The title can have an item counter, which is displayed in parentheses. If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Global actions are always placed at subsection level. Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for global actions at the subsection level.

Subsections

Subsections are the containers for actual content. Always place individual controls inside the subsections. Subsection content is arranged according to the column layout approach for the respective screen size. A subsection can include containers for different controls (mixed content).

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can also display everything by selecting the Show All button at the bottom right of the subsection.

Each subsection can have a toolbar, which is placed at subsection header level on the right. The toolbar contains actions that affect the content of the subsection.

Subsections within the same section are separated by a gray horizontal line. Subsections can have an item counter, which is displayed in parentheses next to the subsection header.

You can include various types of related content in one subsection. The layout blocks for the object page give you the flexibility to combine different content types.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Extra large: 4 columns
  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times, and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

If you are using the object page without object page blocks, you can use the column layout for forms, which automatically distributes form groups across the columns in the object page.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.
Object page – Blocks
Object page – Blocks

Contacts

The contacts on the object page are technically a list, but they can be represented visually as a card.

The cards can contain:

  • An image (optional)
  • A title (mandatory)
  • A subtitle (optional)
  • A text snippet consisting of two lines maximum (optional)

A single card covers the column’s entire horizontal space. To avoid alignment problems, all cards are the same height. The card with the most content defines the overall height for all cards. The image can be rectangular or round. It shows in the top left corner of the card. The content of the card never truncates. If there is not enough space to display the information, it wraps onto the next line.

Content type – Contacts
Content type – Contacts

Tables

If a section or subsection contains only one table and no other content, remove the table title to avoid having duplicate titles for the table. In this case, the section or subsection title acts as the table title.

In an object page, tables with up to 20 expected items can be displayed right away without lazy loading.

If a table is expected to have more than 20 items, use one of the following 3 options for long tables:

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial amount of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, this option should be used only for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. Here it is important to place the table within a tab as the only or at least the last element and to enable the scroll to load behavior.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, the table itself should be restricted to a reasonable amount of items. We recommend only showing a preview of the data in the table, which should not contain more than 20 items. Ideally, you should have about 10 items. This can be either be achieved by prefiltering and/or by sorting the table, and if necessary, by restricting it to a fixed amount of items (such as top 10). To provide the user with a way to work with the entire table, a navigation to a separate list report containing the full table must be offered.  This navigation should be located below the table in the form of a right-aligned link labelled Show All (x), with x representing the total amount of items in the table.

If you want to embed analytical tables, grid tables, or tree tables in an object page, use an object page with tabs and place each table in its own tab. Because the analytical, grid, and tree tables have their own vertical scroll bars, they are not allowed within scrollable object pages. If you are using a scrollable object page without tabs, use a responsive table instead, and offer navigation to a list report with the respective table type.

For all of the three options mentioned above, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Grouping should be avoided.

Table with navigation to a separate list report
Table with navigation to a separate list report

Child Page Representation

In object pages with drilldown navigation, child pages are represented in two ways:

  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Item navigation arrows: Up and down arrows in the layout action area allow the user to navigate between subitems without going back to the original list.

Behavior and Interaction

Edit

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create). In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area for edit mode to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see manage objects – create, edit, delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit on a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Create and Edit Subobjects

The following options are available for creating or editing subobjects:

  • Navigation to a subobject page
  • Inline create or inline edit in a table
  • Dialog containing the fields of the object

If the subobject has less than 8 fields, use a dialog or the inline create/edit option (no separate page for the subobject). Exceptions can apply if additional content for the subobject is available but not part of the edit process, or if other apps need to offer deep links to the subobject page.

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:
•Who made the changes
•When the last changes were made

The popover closes when the user clicks or taps the Close icon or anywhere outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, use the placeholder text “New ” (for example, “New Purchase Order”). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Guidelines

Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing clear context.

If you intend to use images in the header for an object, consider the following:

  • How will the user manage the images?
  • How will the system block people without permission from editing images?
  • How will these images be reflected in other floorplans if they are part of the object?
  • If there are a large number of items, how would a user be able to manage images without having to navigate from page to page?
  • Will the organization be able to manage the images?
Developer Hint
How to achieve a small header:

  • The header container is always optional. If there is no important data to be displayed, you can omit it. In this case, only the header title bar is shown.
  • Omit the image if it is not necessary. It is generally the tallest element in a header container.
  • Use a light theme to reduce the emphasis on the header if it doesn’t contain much information.
  • Consider moving information from the header into a general information section.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.

Tab Navigation

Use tab navigation if you need a facet approach to your content. This could be due to performance issues in a flat view, or in response to a specific user preference.

Not a Content Dump

Avoid using the object page as a universal container for masses of information. You should use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.

Simplify Content for Your Users

Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request. Furthermore, only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


List Report Floorplan

Information
This article contains general guidelines for the list report floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the list report floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items within a large set of items by searching, filtering, sorting, and grouping.
  • Users need to display the whole dataset using different visualizations (for example, as a table or as a chart), without requiring interactions between these visualizations. An example use case might be reporting.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. Views can be switched using tabs, segmented buttons, or a select control.
  • Drilldown is rarely or never used, or is only available via navigation to another page, and not as free or flexible drilldown within the page itself.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, and the item or an identifying data point is known to the user (such as a barcode). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the worklist floorplan instead.
  • Users need to extract knowledge or insights from data, either to better understand the current situation, or to identify the root cause for a certain value.  Use the analytical list page instead.
  • Charts are not only used for visualization. Users need to switch between integrated chart and table views (hybrid view). Use the analytical list page instead.
  • Users need to see the impact of their action on a KPI. Use the analytical list page instead.
  • Users need to see not only the result, but also the impact of their filter settings directly in a chart representation. Use the analytical list page instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions, such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a chart, you can display the chart on its own (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.
Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Header Title

Variant Management

Variant management is optional. If you use variants, apply them to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before the dataset is updated. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the format Filtered By (x): followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use the header toolbar for non-finalizing global actions, such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

Header Content

The header content collapses when the user scrolls down the page (with a responsive table, list, or tree only), and expands again when the user scrolls back up. To avoid this automatic expand / collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.

Users can expand and collapse the header content manually by clicking the background of the title bar. The dynamic page header can also be expanded/collapsed using the Collapse Header ( ) and Expand Header ( ) arrows at the bottom of the header area.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title.

When starting the application, expand the header content if no query was fired (and the table is therefore empty). Collapse the header content in other cases.

Header Content - Expand / Collapse Behavior

  • List Report (Floorplan + SAP Fiori Element) Header Collapsed - 1.56

Filter Bar

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search terms and the filter criteria.

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. Multiple views involve one or more of the following:

  • Showing the same table, but with different columns.
  • Showing the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

There are two options for switching between different views:

The first option is to replace the table title with a content switch. Use this approach if all views share the same sort and group states, as well as the same actions.

The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country/Region, View by Customer, …)

The second option for switching views is to show each view in a tab container of the icon tab bar. Use this approach if all views show different states of the same data (sort states, group states, as well as item selection). Using tabs also allows you to offer different actions on the table toolbar for each view.

Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items are selected, or if the action cannot be applied to the selected items. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions
Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are no items to display, use the “no data” text of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    To start, set the relevant filters.
  • The filter was executed, but no items were found. This can also happen if the list report was opened by a related app, and the filter criteria were transferred automatically:
    No data found. Try adjusting the filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is being used for a different target.
    Only show navigation indicators for target pages the user is authorized to access.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer toolbar
Footer toolbar

Actions

Places for actions in the list report
Places for actions in the list report

(1) Global actions in the header toolbar
(2) Table actions in the table toolbar
(3) Line item actions
(4) Finalizing actions in the footer toolbar

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no item is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

If qualifying items can be identified before the action is executed, show a message about how many of the selected items the action will be applied to. In other cases, show a corresponding message after the action was executed.

Hide actions that cannot be used at all (for example, because the user has no authorization). If you are using an icon tab bar, be aware that each tab contains its own table toolbar.

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or the line item is in the wrong state.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object Page Floorplan

Information
This article contains general guidelines for the object page floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the object page floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

The object page floorplan allows the user to display, create, or edit an object. This is the recommended floorplan for representing both simple and complex objects in SAP Fiori. The object page floorplan comes with a flexible header, a choice of anchor or tab navigation, and a flexible, responsive layout. These features make it adaptable for a wide range of use cases.

Object page floorplan
Object page floorplan

Usage

Use the object page floorplan if:

  • Users need to see, edit, or create an item with all its details.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

  • Users want to edit several items at the same time. Use the list report floorplan instead.
  • Users need to find relevant items without knowing the exact item details. Use the list report floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner). Use the initial page floorplan instead.
  • Users need to be guided through a series of steps when a new object is created. Use the wizard floorplan instead.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected. Use the wizard floorplan instead.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL).

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The layout for size XL (large display) contains four columns.

The default layout for size L (desktop) contains three columns. If you want to display two content elements that require an equal amount of space, you can also use an optional two-column layout (for example, two tables next to each other). Do not use the two-column layout with forms.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Structure

Warning
Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility. For details, see the Header section below.

The object page is a full screen floorplan with a display mode, a create mode, and an edit mode.

In all modes, the object page contains:

  • A dynamic header
  • A navigation bar (optional)
  • A content area

The following sections explain these components in more detail.

Schematic visualization of the object page
Schematic visualization of the object page

Header

The header is the uppermost element of the object page floorplan. It contains key information about the business object and provides the user with the necessary context. The header also contains global actions for the object.

Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility.

The header consists of the following elements:

  1. Title (mandatory)
  2. Subtitle (optional)
  3. Global actions (optional)
  4. Object marker (optional, placed in the key information container of the dynamic header)
  5. Header content (optional)
  6. Breadcrumbs (optional)
  7. Visual indicator (mandatory if the header can be collapsed and expanded)
Object page with the dynamic header
Object page with the dynamic header

If the object page is used in the flexible column layout, it can also contain navigation actions.

Please note:

  • To display images and placeholders in the header, use the avatar control.
  • The subtitle is now below the title. (For the former object page header it was next to the title.)

For an example of an object page with the dynamic header, see this SAPUI5 sample. A sample with an image can be found here.

For more information, see the Dynamic Header section for the dynamic page layout.

Header Facets

The header content is optional and is located below the title.

It can be used to display app-specific contextual information. You build the content using smaller content containers, called facets. Each facet contains a distinct information set, as described below. If there aren’t any facets, the header content is always hidden.

The facets are arranged in line with a left float. Each facet adapts its size to the content and makes optimal use of the space without truncating the texts. If the facets do not all fit on one line, those on the right wrap to the line below.

If the header collapses, the header content is hidden. If the header content is empty, you can also hide it.

There are several types of header facets, depending on the data that they display. The facets need to be handmade for stand-alone object pages.

Form Facet (Dataset)

The form facet can be used to display datasets in the header. It consists of a headline and up to five label-text pairs.

  • The headline is optional.
  • The form facet contains at least one label-text pair, and a maximum of 5 pairs.
  • The labels can be invisible, but need to have a text for accessibility purposes.
  • The labels can be icons, but need to have a text for accessibility purposes.
  • Each text in a label-text pair can have a press event.

Form facets are typically used for document information (such as creator and creation time), address or contact information, and general information.

Developer Hint
For non-SAP Fiori element object pages only:

For each label-value pair in the form header facet, use a sap.m.Label and a sap.m.Text or sap.m.Link, nested within an sap.m.HBox.

Header facet - Form facets
Header facet - Form facets

Plain Text Facet

The plain text facet can be used to display a continuous text in the header. It consists of a headline and a continuous text.

  • The width of the facet does not depend on its content, but can be set. The default width of the facet is 300px.
  • The headline is optional.
  • If the headline is broader than the facet width, the headline will wrap.
  • Press events are only available inline in the continuous text. These can be links that navigate to another page or open a quick view. There can be more than one link in the continuous text with different actions.
Developer Hint
For non-SAP Fiori element object pages only:

To set the width of the plain text facet, nest the text within an sap.m.HBox and set the property:width of the sap.m.HBox.

Header facet - Plain text facet with default width
Header facet - Plain text facet with default width
Header Facet - Plain text facet with custom width
Header Facet - Plain text facet with custom width

Image Facet

The image facet can hold exactly one image. The header can have only one image facet, or no image facet.

The image can be:

  • Square or circular
  • An icon
  • Initials consisting of two letters

The image can have a press event. The default press event enlarges the image.

When the header collapses, the image facet moves to the left of the title and becomes smaller.

Recommended usage:

  • Use round images for people, especially for portraits. If no image is available for a person, use the person’s initials instead (first letters of the first and last names).
  • Use square images for all other images. If no image is available for an object, show a suitable icon.

Always make it clear to users how they can upload and manage images. This either be done in edit mode on the object page, or using an external tool. External tools can be helpful if there are a lot of images.

Developer Hint
Always use the avatar control for the image in the header. This applies to both expanded and collapsed images.
Header facet – Image facet specification
Header facet – Image facet specification

Key Value Facet

The key value facet contains a label in a smaller font size and a text or number in a bigger font size. It can be used to highlight important data or KPIs.

If the key value facet is used with a text, such as a status, you can also display an icon to the right of the text. This icon must only be used to visually support the text it relates to, and not to add an another aspect of meaning.

Developer Hint
For non-SAP Fiori element object pages only:

Larger value texts are currently only available in SAP Fiori elements. For non-SAP Fiori element apps, the value texts have the same size as the label, as custom CSS should not be used.

Header facet – Key value facets with KPIs and a status
Header facet – Key value facets with KPIs and a status

Micro Chart Facet

The micro chart facet consists of a headline, a subtitle, a micro chart, and a footer.

The headline and the micro chart are mandatory while the subtitle and the footer are optional. To display the unit used in the micro chart, use the footer.

The following micro charts can be used in the micro chart facet:

The micro chart facet can have a click or tap event on the chart itself. This could  lead to a page with a bigger chart or open a quick view, for example.

For more information see micro charts.

Header facet – Micro chart facets
Header facet – Micro chart facets

Progress Indicator Facet

The progress indicator facet consists of a mandatory headline and a progress indicator (sap.m.progressIndicator). In addition, it can have two supplementary texts: a subtitle and a footer.

Header facet - Progress indicator facet
Header facet - Progress indicator facet

Rating Indicator Facet

The rating indicator facet consists of a headline, a rating indicator, and one or two supplementary texts, which are dependent on the use case.

The rating indicator can be modified as described in the rating indicator article.

We recommend the following property settings when using the rating indicator in header facets:

  • 5 symbols as the default.
  • Use the Favorite icon as the symbol.
  • Display half-stars to represent decimal values.

The rating indicator facet can be used for two different use cases, which are described below.

  1. Aggregated rating:

    A typical example of an aggregated rating is the average of several user reviews for a product. The facet for aggregated rating has a mandatory header, an optional subtitle, the rating indicator itself, and a footer.

    Use the subtitle to indicate the amount of data being aggregated. For example, if you show an average rating, the subtitle shows the number of ratings.

    In the footer, display exact aggregation value. Use the format “<average rating> out of <maximum rating>”. For the average rating, use the exact value with one decimal place.
    Example: 2.2 out of 5

  2. Single value rating:

If you display the rating as a single value, the facet has a mandatory header, an optional subtitle, and the rating indicator itself. Here, you can use the subtitle for a supplementary text. Do not use a footer.

Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with singe value rating
Header facet - Rating indicator facet with singe value rating

Toolbars

The object page supports two toolbars:

  • Header toolbar: Use this toolbar for global actions, such as Edit, Delete, Copy, and Share.
  • Floating toolbar: Use this toolbar for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

This applies to all object page modes (display, edit, and create).

Navigation

There are three ways to navigate within the object page:

  • Anchor bar (by default)
  • No navigation (flat scrollable page)
  • Tabs

Usage

  • To offer a flat page for a simple object, use the dynamic page to prevent having sections and navigation. Create the header in the same way as for the object page.
  • For more complex objects, use anchor or tab navigation.

Anchor Bar and Overflow

The anchor bar is the default navigation control for the object page. It consist of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint

Anchor Bar and Overflow

Use title case for the anchor bar texts. To do this, you need to change the default capitalization (block caps) by changing the the property upperCaseAnchorBar to “false”.

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow overview button on the right of the navigation bar ( ) opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow overview button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the document.

Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow overview button
  8. Overflow overview dropdown
  9. Section (hover) in overflow overview
  10. Section in overflow overview
  11. Subsection in overflow overview

Behavior and Interaction

  • Clicking an anchor link scrolls the page to the selected section.
  • Clicking a section anchor that contains more than one subsection opens a subsection menu.
  • Clicking a subsection scrolls the page to the selected subsection. The keyboard left and right arrows allow the user to move between the anchor links.
  • Hovering over the fade area to the left or right of the anchor bar causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
  • Clicking the overflow scroll button (right arrow) scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
  • Clicking the overflow overview button ( ) displays a hierarchical dropdown list with all the sections and subsections of the document. Clicking an item in the overflow list scrolls to the respective section or subsection.

Hiding the Navigation

You can hide the navigation bar from the object page, leaving a flat, scrollable object. We recommend using this flat view for simple content that doesn’t require anchor navigation.

Tab Navigation

As an alternative to anchor navigation, you can also opt for tab navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. Tab navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional and the default state is “false”. If the state is set to “true”, a dropdown arrow is shown next to the tab. Clicking on the tab displays a dropdown menu with the subsection anchors for that tab.

Object page – Tab navigation
Object page – Tab navigation

Breadcrumbs

If the object page uses a hierarchical parent-child drilldown, you can offer a breadcrumb for navigation.

Content Area

The object page content consists of sections and subsections arranged in a column layout. For large documents, you can enable a lazy loading mechanism (property: enableLazyLoading) to mitigate the loading time.

Sections

Sections are containers for subsections. They provide the basic structure for navigation, and are directly reflected in the navigation bar. Sections can have a title, subsections, and actions. However, they cannot contain controls.

Use title case for the section title (property titleUppercase = “false”). The title can have an item counter, which is displayed in parentheses. If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Global actions are always placed at subsection level. Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for global actions at the subsection level.

Subsections

Subsections are the containers for actual content. Always place individual controls inside the subsections. Subsection content is arranged according to the column layout approach for the respective screen size. A subsection can include containers for different controls (mixed content).

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can also display everything by selecting the Show All button at the bottom right of the subsection.

Each subsection can have a toolbar, which is placed at subsection header level on the right. The toolbar contains actions that affect the content of the subsection.

Subsections within the same section are separated by a gray horizontal line. Subsections can have an item counter, which is displayed in parentheses next to the subsection header.

You can include various types of related content in one subsection. The layout blocks for the object page give you the flexibility to combine different content types.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Extra large: 4 columns
  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times, and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

If you are using the object page without object page blocks, you can use the column layout for forms, which automatically distributes form groups across the columns in the object page.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.
Object page – Blocks
Object page – Blocks

Contacts

The contacts on the object page are technically a list, but they can be represented visually as a card.

The cards can contain:

  • An image (optional)
  • A title (mandatory)
  • A subtitle (optional)
  • A text snippet consisting of two lines maximum (optional)

A single card covers the column’s entire horizontal space. To avoid alignment problems, all cards are the same height. The card with the most content defines the overall height for all cards. The image can be rectangular or round. It shows in the top left corner of the card. The content of the card never truncates. If there is not enough space to display the information, it wraps onto the next line.

Content type – Contacts
Content type – Contacts

Tables

In an object page, tables with up to 20 expected items can be displayed right away without lazy loading.

If a table is expected to have more than 20 items, use one of the following 3 options for long tables:

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial amount of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, this option should be used only for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. Here it is important to place the table within a tab as the only or at least the last element and to enable the scroll to load behavior.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, the table itself should be restricted to a reasonable amount of items. We recommend only showing a preview of the data in the table, which should not contain more than 20 items. Ideally, you should have about 10 items. This can be either be achieved by prefiltering and/or by sorting the table, and if necessary, by restricting it to a fixed amount of items (such as top 10). To provide the user with a way to work with the entire table, a navigation to a separate list report containing the full table must be offered.  This navigation should be located below the table in the form of a right-aligned link labelled Show All (x), with x representing the total amount of items in the table.

In the object page, we recommend that you do not use the analytical, grid and tree tables. Instead, use a responsive table and offer navigation to a list report with the table types mentioned above.

For all of the three options mentioned above, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Grouping should be avoided.

Table with navigation to a separate list report
Table with navigation to a separate list report

Child Page Representation

In object pages with drilldown navigation, child pages are represented in two ways:

  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Item navigation arrows: Up and down arrows in the layout action area allow the user to navigate between subitems without going back to the original list.

Behavior and Interaction

Edit

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create). In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area for edit mode to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see manage objects – create, edit, delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit on a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Create and Edit Subobjects

The following options are available for creating or editing subobjects:

  • Navigation to a subobject page
  • Inline create or inline edit in a table
  • Dialog containing the fields of the object

If the subobject has less than 8 fields, use a dialog or the inline create/edit option (no separate page for the subobject). Exceptions can apply if additional content for the subobject is available but not part of the edit process, or if other apps need to offer deep links to the subobject page.

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:
•Who made the changes
•When the last changes were made

The popover closes when the user clicks or taps the Close icon or anywhere outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, use the placeholder text “New ” (for example, “New Purchase Order”). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Guidelines

Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing clear context.

If you intend to use images in the header for an object, consider the following:

  • How will the user manage the images?
  • How will the system block people without permission from editing images?
  • How will these images be reflected in other floorplans if they are part of the object?
  • If there are a large number of items, how would a user be able to manage images without having to navigate from page to page?
  • Will the organization be able to manage the images?
Developer Hint
How to achieve a small header:

  • The header container is always optional. If there is no important data to be displayed, you can omit it. In this case, only the header title bar is shown.
  • Omit the image if it is not necessary. It is generally the tallest element in a header container.
  • Use a light theme to reduce the emphasis on the header if it doesn’t contain much information.
  • Consider moving information from the header into a general information section.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.

Tab Navigation

Use tab navigation if you need a facet approach to your content. This could be due to performance issues in a flat view, or in response to a specific user preference.

Not a Content Dump

Avoid using the object page as a universal container for masses of information. You should use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.

Simplify Content for Your Users

Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request. Furthermore, only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


Wizard Floorplan

The wizard floorplan allows users to complete a long or unfamiliar task by dividing it into sections and guiding the user through it. The wizard consists of the walkthrough screen, where the form sections are revealed in sequence after each one is completed, and the summary page, where the form is displayed in read-only mode for assessment and final submission. You can use the wizard both in full-screen and flexible column layout.

Wizard - Steps
Wizard - Steps

Usage

When to Use the Wizard Floorplan

The wizard aims to help users by dividing large or complex tasks into segments. Use the wizard if the user has to accomplish a long task (such as filling out a long questionnaire) or a task that is unfamiliar to the user. The flow should consist of a minimum of 3 and a maximum of 8 steps.

The wizard can be used for both create and edit scenarios. If your application contains both, consider using the same means for both scenarios – either the wizard, or another create/edit screen (edit flow or object page).

When Not to Use the Wizard Floorplan

If you have a task with only 2 steps or a format that the user is familiar with (for example, it is part of their daily routine), do not use the wizard as it only adds unnecessary clicks to the process. If your process needs more than 8 steps, the wizard will not support those steps as the process is too long and can be confusing for the user. In this case, you should consider restructuring the task.

Consider if the classic edit screens (edit flow or object page) are more suitable for your use case.

Structure

The wizard has two main screens: the walkthrough screen, where users complete a segmented task, and the summary screen, where they can check the data they are about to submit. Wizard content is not restricted to forms; other content such as a value help dialog can also be used.

Walkthrough Screen

The walkthrough screen is the wizard’s main screen. After triggering the wizard, the user is taken to the walkthrough screen, which shows only the first section of the form. Once the user has filled out all the necessary fields, a Step XY button appears, which allows the user to move to the next step. When the user has completed the last section of the wizard, the button label changes to Review and the user is taken to the summary screen.

The wizard footer is used to display the Cancel button, which exits the wizard. If the user has modified any fields, a data loss message also prompts the user. You can also use a Save as Draft function in the footer if the form is long and the user may have to save it before finishing it.

Walkthrough screen in full screen layout
Walkthrough screen in full screen layout

The title in the header toolbar above the wizard remains unchanged during all the wizard steps. Align this title left, and make it clear to users where they are and what they are doing (for example, New Sales Order or Sales Order 4815162342). Especially in edit scenarios, it is vital to give users a unique identifier for the object they are changing.

Header toolbar with title
Header toolbar with title

The progress bar/anchor navigation below the header highlights the completed steps and the current step. It also allows the user to navigate between steps by clicking on any of the circles.

The progress bar exhibits a grouping behavior if there are multiple steps and the screen width is reduced. This behavior is the same on smartphone, tablet, and desktop screens.

Wizard header and anchor navigation
Wizard header and anchor navigation
Wizard tooltip – Grouped steps
Wizard tooltip – Grouped steps

In certain use cases, the steps in the wizard depend on the choices the user makes along the way. The user’s entries for one step determine the follow-on steps (“branching”). In these cases, a dotted line shows that more steps will follow.

Wizard branching
Wizard branching

Since the wizard is a lightweight way to create or edit objects, applications can use a quick confirmation popup instead of the heavier data loss message, when the user selects Cancel.

If the wizard is used to create an object, the text on the popup should read Discard this <object>?’ (see image below). If the wizard is used to edit an object, use the text Discard changes? In both cases, the action on the popup should be Discard.

Structure – Quick confirmation
Structure – Quick confirmation

Summary Screen

On the summary screen, users can check all their entries before the object is actually created or changed. The summary screen has no progress bar or anchor navigation, and shows the form sections for all the steps in read-only mode.

To allow the user to go back and edit entries, provide an Edit button either in the footer toolbar or in each form section:

  • If you place the Edit button is placed in the footer toolbar, the user is taken back to the first section of the wizard.
  • If you offer Edit buttons for each section of the form, the user jumps to that particular step.

Alternatively, users can click or tap the Back button to go to the previous step. From there, they can scroll or tap through the sections.

The main action on the summary page should be the final action after completing the wizard, such as Create or Save.

Wizard summary page example
Wizard summary page example

Layout

Thanks to the wizard’s responsive behavior, it can be used both in a full-screen layout as well as in the flexible column layout. Since there are no subsequent pages after the wizard, it will always occupy the rightmost column – there is no navigation from the wizard to a next page. After completion (or cancellation), the user will always come back to the page the wizard was triggered from.

Wizard in full screen layout
Wizard in full screen layout
Wizard in flexible column layout (2/3)
Wizard in flexible column layout (2/3)
Wizard in flexible column layout (1/3)
Wizard in flexible column layout (1/3)

Types

There are two types of wizard – “standard” and “branching” – which differ in terms of the functions they offer.

Use the standard type if:

  • The total number of steps is known in advance.
  • The number of steps does not change during usage.
  • There is linear progression from one step to the next.

Use the branching type if:

  • The total number of steps is not known.
  • The number of steps may change during usage.
  • There is non-linear progression. In other words, the user’s choice during one step determines which step comes next.

In both types of wizard you can let users skip steps. Label these steps as “Optional”.

Styles

In addition to the functional types, there are also different visual styles.

Numbers and Icons

By default, both versions use a number inside a circle to represent each step. You can also use icons instead of numbers to help users identify the steps. If you plan to use icons, be sure to assign icons to all the steps (not just to some). The icons you choose should be unique and not look too similar. This will ensure that users do not get individual steps confused with one another.

Steps represented by numbers
Steps represented by numbers
Steps represented by icons
Steps represented by icons

Labels

To help users identify the individual steps even more easily, app developers can assign labels. As with icons, labels must be applied to all or none of the steps.

If there is enough horizontal space, all labels are shown.

All labels are visible
All labels are visible

As the width is reduced, the steps outside the currently selected one do not show labels.

Labels - reduced width
Labels - reduced width

Finally, the unselected and outermost steps are stacked on top of each other to further accommodate the reduced space.

Stacked labels
Stacked labels

Users can still easily access steps inside a stack. A single click opens a list of steps inside this stack.

Labels - stacked popover
Labels - stacked popover

Optional Steps

For optional steps, add an (Optional) label. Place the (Optional) label below the content label for the step.

Do
Correct: '(Optional)' label below the content label for the step
Correct: '(Optional)' label below the content label for the step
Don't
Incorrect: '(Optional)' label directly after the label for the step
Incorrect: '(Optional)' label directly after the label for the step

Explanatory Texts

Ideally, the headlines and field labels for each step should provide enough information for users to complete their tasks. However, if additional explanations are needed, applications can put a simple text underneath a step’s headline – either via the sap.m.Text or the sap.m.FormattedText control.

Responsiveness

The wizard supports all common screen sizes and is available in cozy and compact modes, as well as high-contrast black (HCB).

Wizard – Size S
Wizard – Size S
Wizard – Size M
Wizard – Size M
Wizard – Size L
Wizard – Size L

Behavior and Interaction

Navigation, Error- and Draft Handling

Navigation

Users can trigger the wizard app from another application, from the launchpad, or from a notification. The wizard always starts at the initial walkthrough page and ends after the user has clicked the main action (such as Create or Submit) on the summary screen. The Step XY button is only used on the walkthrough page. This button loads the next section of the form. On the summary page, the user can use either the Edit button in the footer or the “back” arrow to return to the wizard and edit any of the fields.

Modifying dependent steps: If there are steps that depend on each other (for example, a selection in step 2 triggers an additional step) and the user modifies the parent step, the dependent step is changed or deleted. Beforehand, the user is warned that data will be lost.

Error Handling

Error handling is done via message popovers. When the user clicks the Step XY button, the form sections and fields should be validated. When the user clicks the Create button on the summary page, the entire form is validated. If there are any errors, the user stays on the walkthrough page, the message popover is displayed, and clicking any of the error items scrolls the page to the relevant field, which is also highlighted in red.

Section validation differs from validation of the entire form. In the first case, correct data entry in the form fields is validated. In the second case, the entire form is checked for backend system errors (such as duplicated data entry).

Draft Handling

If a draft already exists when a user enters the wizard, show a dialog to inform the user. For more information, please visit the draft handling article.

Dynamic Page

Header

Even though the wizard floorplan consumes the dynamic page, the wizard’s header does not allow snapping. Due to the nature of the wizard floorplan, the wizard brings its own step-based header that is already very space-saving.

Footer Toolbar

Contrary to the header, the footer toolbar of the wizard floorplan conforms to the standard layout and uses the sap.m.bar control.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • Wizard (SAPUI5 API reference)
  • Wizard (SAPUI5 samples)
  • Form (SAPUI5 API reference)
  • Form (SAPUI5 samples)

Initial Page Floorplan

The initial page floorplan allows the user to navigate to a single object to view or edit it. The interaction point on the screen is a single input field that relies on assisted input to direct the user to the object in as few steps as possible (using features such as value help and live search). If you need to display more than one object, use the list report floorplan instead.

Initial screen – Empty state
Initial screen – Empty state
Initial screen – Showing object
Initial screen – Showing object

Usage

Use the initial page floorplan if the user only needs to work on one object at a time. In this case, the list report floorplan would include a redundant step for viewing a list of items found by the search.

A typical use case for the initial page floorplan is a barcode scanning app, where each new scan leads to an object with input fields. Once the user has submitted the entries, the screen is shown in read-only mode. The cursor returns to the input field, ready for the user to scan the next object.

Do not use the initial screen floorplan if the search is supposed to return a list of objects. This is the scenario for the list report floorplan.

It is also advisable to use only one input field for finding the object. If you need to include detail views, or allow the user to switch between views, offer these features when displaying the object itself.

Structure

The initial page is a full screen floorplan based on the object page, with a dynamic header and a content area.

Header area

The header area can contain the same content as in the object page, except for the title, which is replaced by an input field. The header initially displays in collapsed mode, but expands when the user performs a search or finds an object using the value help dialog.

Content area

The content area is used to display the object. It can contain sections, subsections, forms, and tables.

Structure of the initial screen
Structure of the initial screen

Responsiveness

The initial page features a single interaction point for the user: the input field near the top of the screen. Place the input field inside the header section. Configure the width to fit the width of the longest text (allowing some additional space for other languages), but do not make it significantly wider.  When you set the maximum width of the input field, also consider the width available on mobile devices.

The field should never be as wide as the screen (except for on smartphone screens).

Initial page floorplan - Size S
Initial page floorplan - Size S
Initial page floorplan - Size M
Initial page floorplan - Size M
Initial page floorplan - Size L
Initial page floorplan - Size L

Flows and Interaction

Initial Screen with Live Search

The input field serves as the single starting point for finding the object. The assisted input uses the live search feature (search-as-you-type) to speed up the search. The live search feature can show anything from one attribute to an entire table of values. It is possible to show a message such as “Enter ID manually or scan barcode” using the message page to guide the user.

Live Search

  • Initial page search 1
  • Initial page search 2
  • Initial page search 3

Initial Screen with Value Help Dialog

If multiple hits are possible for the same search terms, you may need to implement a value help dialog. This dialog lets the user narrow down the list of items based on more specific criteria. When the user selects an object from the list, the dialog closes and the object is displayed in the content area (no additional navigation is required).

Value Help Dialog

  • Initial page with value help 1
  • Initial page with value help 2
  • Initial page with value help 3

Behavior of the Search Field

The dynamic header content is initially collapsed and cannot be expanded. The input field is located in the header area of the object page and should be on focus if no other additional actions are provided. This allows the user to enter the search term directly without clicking into the field. Only consider using this if there are no other elements that could be blocked by it, such as the on-screen keyboard on touch devices.

Once the user finds an object, the dynamic header expands and displays the relevant information for the object.

The dynamic header collapses on scrolling or by user interaction, but the input field for performing a different search is always visible.

Collapsing the dynamic header on scroll or by user interaction
Collapsing the dynamic header on scroll or by user interaction

If the user enters new search terms in the input field, the focus moves away from the field and the app triggers a new search. If no results are found, the initial view of the page is shown – with a collapsed header and a corresponding message in the content area.

If the user deletes the search term and moves the focus away from the input field (or clicks ENTER), the screen becomes blank again.
If the user deletes the search term and moves the focus away from the input field (or clicks ENTER), the screen becomes blank again.
If a search is executed, but no documents are found, the screen becomes blank again, and a corresponding message is displayed.
If a search is executed, but no documents are found, the screen becomes blank again, and a corresponding message is displayed.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Analytical List Page (SAP Fiori Element)

Analytical list page – Size XL
Analytical list page – Size XL

The analytical list page (ALP) offers a unique way to analyze data step by step from different perspectives, to investigate a root cause through drilldown, and to act on transactional content. All this can be done seamlessly within one page. The purpose of the analytical list page is to identify interesting areas within datasets or significant single instances using data visualization and business intelligence.

Visualizations help users to recognize facts and situations, and reduce the number of interaction steps needed to gain insights or to identify significant single instances. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

The main target group are users who work on transactional content. They benefit from fully transparent business object data and direct access to business actions. In addition, they have access to analytical views and functions without having to switch between systems. These include KPIs, a visual filter where filter values are enriched by measures and visualizations, and a combined table/chart view with drill-in capabilities (hybrid view). Users can interact with the chart to dig deep into the data. The visualization enables them to identify spikes, deviations and abnormalities more quickly, and to take appropriate action right away.

Usage

Use the analytical list page if:

  • Users need to extract key information to understand the current situation or identify a root cause. The way the data is presented is crucial for giving them the insights they need to take the right action.
  • Users need a way to analyze data step by step from different perspectives, investigate a root cause through drilldown, and act on transactional content within one page.
  • In addition to the filtered dataset, users need to see the impact of their filter settings in a chart (visual filter).
  • Users need to switch between integrated chart and table views (hybrid view).
  • Users need to see the impact of their action on a global key performance indicator (KPI).
  • Users need to find and act on relevant items out of a large set of items by searching, filtering, sorting, grouping, drilling down, and slicing and dicing.

Do not use the analytical list page if:

  • Drilldown is rarely used, not used at all, or is only needed after navigating to another page, rather than as free or flexible drilldown within the page itself. In this case, a list report might be sufficient for your use case.
  • Users need different visualizations for the entire dataset (for example, as a table or chart), but don’t need to work with both visualizations on the same page (for example, in a reporting scenario). In this case, a list report might be sufficient.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping, without using drilldown or “slice and dice”. In this case, consider using a list report.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. They want to be able to switch views using tabs, segmented buttons, or a select control. In this case, consider using a list report.
  • Users need to see or edit a single item with all its details. Use the object page floorplan instead.
  • Users need to find a specific item, and the item or an identifying data point is known to the user (such as a barcode). In this case, use the initial page floorplan.
  • Users need to work through a comparably small set of items, one by one. In this case, use the worklist floorplan.
  • Users have a trivial use case that does require the use of a chart, but that do not involve identifying a root cause, analyzing data, or drilldown. Instead, use a list report with a table/chart switch.

Structure

This section describes the basic layout of the analytical list page, as well as the different layout variants.

Basic Layout

The shell bar is on top of the analytical list page. The page itself uses the dynamic page layout and has two main areas:

  1. Analytical list page header: The page header has two states: collapsed and expanded. The content shown depends on the state. The user can easily switch the state using the visual indicator.
  2. Analytical list page content area: This area combines three different views and a view switch:
    • Hybrid view (combined chart and table view)
    • Chart-only view
    • Table-only view

All elements are described in more detail in the Components section below.

Analytical list page - Basic layout
Analytical list page - Basic layout

Layout Variants

The layout of the analytical list page is quite flexible. Depending on the state of the analytical page header and the view in the content area, different content is displayed.

For example, the expanded page header allows users to display either the visual filter bar or the filter bar, while the page content area can display either a hybrid view, a chart-only view, or a table-only view.

Analytical List Page Layout Variants

  • ALP - Visual Filter Bar - Expanded
  • ALP - Compact Filter Bar - Hybrid View
  • ALP - Collapsed Filter Bar - Chart and Table View
  • ALP - Visual Filter Bar - Expanded - Chart View
  • ALP - Compact Filter Bar - Expanded - Chart View
  • ALP - Filter Bar - Collapsed - Chart View
  • ALP - Visual Filter Bar - Expanded - Table View
  • ALP - Collapsed Filter Bar - Table View
  • ALP - Filter Bar - Collapsed - Table View

Responsiveness

The analytical list page is responsive, except for the global KPIs. Apps with one or more global KPIs are not supported on screen sizes smaller than size L (desktop).

Likewise, the analytical list page is only fully supported in the flexible column layout if no global KPIs are used. If you use the analytical list page with global KPIs within the flexible column layout, the column should have at least size M.

Size S

On size S, the analytical list page supports both the chart-only and table-only views. The table-only view supports only the responsive table. If no responsive table is available, the chart-only view is displayed without a view switch toggle.

Global KPIs are not supported on size S.

Size M

On size M, the analytical list page supports both the chart-only and table-only views. You can use a responsive table or analytical table in the table-only view.

Chart-only view - Size S
Chart-only view - Size S
Table-only view - Size S
Table-only view - Size S
Chart-only view - Size M
Chart-only view - Size M
Table-only view - Size M
Table-only view - Size M

Component Overview

Analytical List Page Header

The page header can be expanded and collapsed on click/tap. Different content is shown in the expanded and collapsed states. For more information about the basic behavior of the header, see Dynamic Page Header.

Collapsed Header

The collapsed page header contains the following elements:

Collapsed analytical list page header
Collapsed analytical list page header

Expanded Header

The expanded page header contains the following elements:

Expanded analytical list page header showing the visual filter bar
Expanded analytical list page header showing the visual filter bar
Expanded analytical page header showing compact filters in the filter bar
Expanded analytical page header showing compact filters in the filter bar

Analytical List Page Content Area

The analytical list page content area contains the following elements:

  • View switch (   |    |    )
  • Hybrid view: View with one chart, chart toolbar, one table, and a table toolbar
  • Chart-only view: View with one chart and a chart toolbar
  • Table-only view: View with one table and a table toolbar

Analytical List Page Content Area

  • Hybrid view
  • Chart-only view
  • Table-only view

Analytical List Page Header

Variant Management

Variant management in the analytical list page allows users to save a page variant whenever there are changes in the underlying structures of the filter/content area. Variant management for the page is handled by the standard SAPUI5 page variant management.

Currently, the page variant captures the following states across the page:

  • Filter view switch state: Visual filter bar or filter bar
  • Filter set: The filters set in the visual filter bar and filter bar
  • Filter selections: Selected values in the visual filter bar and filter bar
  • Content view switch state: hybrid view  , chart-only view  , or table-only view  
  • Chart and table configurations, such as measures and dimensions used, sort order, or grouping
  • Chart drill-down state, based on the current selections (slice & dice)
  • Table entry switch state: Hide (  ) or Show  (  ) selected table records
Standard page variant management
Standard page variant management

Global KPI Tags and Cards

Use a global KPI tag (= global key performance indicator tag) if you would like to show a global KPI related to the task in hand. The global KPI value changes only if an action is executed on the transactional content. For example, the user needs to know the effect of releasing sales orders on a related global KPI, or the effect of posting an accounting document on certain financial global KPIs.

You can display a maximum of three global KPIs. Clicking a global KPI tag opens a global KPI card that displays more details on the KPI.

The global KPI tags and corresponding KPI cards are independent of the filter area. This means that global KPI tags do not react to filters set in the visual filter bar and filter bar.

A global KPI tag has four components:

  • Global KPI label
  • Global KPI value
  • Global KPI color and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator

Global KPI Label

The global KPI label is an abbreviation of the complete global KPI title. It is formed using the first three letters of the first three words of the global KPI title.
Examples: AMR for Actual Monthly Revenue, TAR for Total Advertising Revenue, or LPC for Landing Page Conversation Rates

If there is only one word in the global KPI title, the first three letters of the word are displayed. Example: CON for Contracts

If the global KPI title has only two words, only the first letters of these two words are displayed. Examples: AC for Actual Costs, SG for Sales Growth

KPI label abbreviation: AC
KPI label abbreviation: AC

Global KPI Value

The global KPI value is displayed using a semantic color and a scaling factor. Relative values are shown with a percentage sign and one decimal place.
Examples: 0.3%, 82.9%
Absolute values are shown without decimal places, a currency, or a unit of measure.
Examples: 2K, 75K, 30M, 14B

KPI values: 2K and 0.3%
KPI values: 2K and 0.3%

Global KPI Color and Criticality Indicator

The color of the global KPI value is based on the thresholds defined for the particular KPI in the annotation. The global KPI tag also uses a line to indicate the criticality. The color of the line is the same as that of the global KPI value.

KPI color and criticality indicator
KPI color and criticality indicator

Global KPI Card

Clicking the KPI tag opens the analytical card, which displays more information about the current value of the global KPI, the global KPI target, the deviation from the target, and how the global KPI has evolved over time.

Global KPI card
Global KPI card

Filter Area: Visual Filter Bar and Filter Bar

The filter area allows users to filter the result set, which feeds the main content area. The analytical list page comes with two filter types: compact filters in the filter bar, and the visual filter bar. Always design both visual filters and compact filters (filter bar) for your app. We recommend setting the visual filter bar as the default, but this is no longer mandatory. You can opt to use the (compact) filter bar as the default if your app has the required parameter values, if your main use case involves date ranges, or if your users often need to combine multiple filters in different ways.

Currently, any visual filter configured in the visual filter bar must always be displayed as a compact filter in the filter bar as well. By contrast, a filter configured as a compact filter in the filter bar may or may not be configured for display as a visual filter. This means that it’s possible to have a smaller set of visual filters and a larger set of compact filters.

Both filter types supports two different modes: live update and manual update. Use the live update mode for both filter types as the default whenever possible. Apply the same mode to both filter types: the visual filter bar and the filter bar. For example, if you use the live update mode in the visual filter bar, you should also use the live update mode for the filter bar.

Visual filter bar
Visual filter bar
Filter bar
Filter bar

Filter Type Switch

Users can toggle between the compact filters    (filter bar) and    (visual filter bar) in the upper-right area of the page header. The filter type switch is a core feature of the analytical list page and is mandatory. The switch is only displayed when the page header is expanded. Once the header collapses, it disappears.

Filter type switch
Filter type switch

Carrying Forward Filter Selections

Visual Filter to Compact Filter

Any values selected in the visual filters are always carried forward to the corresponding compact filters.

Compact Filter to Visual Filter

Filter dimensions that are part of a visual filter are synced to the visual filter. If the dimension value(s) chosen in the compact filter are part of a visual filter, they are shown as selected chart dimensions in the visual filter (single or multiple selections).

Filter dimensions that are not part of the visual filter, parameter values, and interval-based dimensions are applied to the filter query and the content is refreshed.

To show complex conditions, click the link for the number of selected items at the top of the visual filter.

Visual Filter Bar

The visual filter bar combines measures or item counts with filter values. The visual filter bar becomes more powerful if you match measures to the filter dimension instead of just item counts. Use the visual filter bar if you would like to give the user a condensed overview of the data in the dataset. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

Chart Types in the Visual Filter Bar

Currently, the visual filter bar supports three interactive chart types:

These interactive charts are also referred to as visual filters.

Interactive Donut Chart

The interactive donut chart in the visual filter bar is used for non-time-related data (for example, categories) and displays only the top or bottom two values. The rest are aggregated into the “Other” section.

Interactive donut chart
Interactive donut chart
Interactive donut chart with semantic colors
Interactive donut chart with semantic colors

Interactive Line Chart

The interactive line chart is used exclusively for displaying time series data, and can show a maximum of six data points. Always show the first or last six data points (for example, last six days, last six months, first six days, and so on).

Interactive line chart
Interactive line chart
Interactive line chart with semantic colors
Interactive line chart with semantic colors

Interactive Bar Chart

The interactive bar chart can be used for non-time-related data (for example, categories) and has a maximum of three filter values. These filter values show the top three or bottom three entries.

Interactive bar chart
Interactive bar chart
Interactive bar chart with semantic colors
Interactive bar chart with semantic colors

Using Interactive Charts

The interactive charts come with the following features and rules:

  • Minimum number of interactive charts: Show at least three visual filters and try to use different chart types.
  • Filter title:
    • Use the following naming convention for the filter title, using title case:
      [Measure Name] by [Dimension Name] | [Scale Factor] [Unit of Measure].
      Examples:
      Project Costs by Project | K EUR
      Sales Volume by Commodity | M PC
    • For an item count, use the following naming convention for the filter title, using title case:
      Number of [Dimension] | [Scale Factor] [Unit of Measure].
      Examples:
      Number of Products | PC
      Number of Contracts by Month
    • Note that for some use cases, it might be appropriate to replace “Number” with a different expression. Bear in mind that the space for displaying the filter title is limited. If the measure and/or dimension names are longer than the predefined space, the text will be truncated.
Filter title with truncation
Filter title with truncation
Filter title without truncation
Filter title without truncation
  • Filter-to-filter dependencies: Ideally, the filters depend on each other. By selecting one or several chart data points, users can perform a quick analysis of the dataset.
    Examples: Supplier with the lowest supplier performance this year, product with the highest sales volume in March in the EMEA region
  • Adding additional filter values: All charts have a maximum number of filter values that can be displayed within the chart itself. More filter values can be selected using the value help.
  • Selected values: Any data point or segment that is selected in the visual filter’s interactive charts will remain selected even when the user changes the measure, chart type, or sort order in any of the charts. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.
  • Semantic colouring: All interactive charts support semantic colors to indicate the criticality of filter values.
  • How to design a visual filter: To design a visual filter, choose a meaningful measure out of the dataset and match it to a filter dimension. If no measures or no meaningful measures are available, use an item count instead. Have a look at the visual filter bar article for more information.

Filter Dialog

In the filter dialog, the user can switch between the visual filter bar filters and the filter bar filters using a toggle button. The standard filter dialog is explained in the Filter Bar article. The part for the visual filter is further explained below.

Filter Dialog for Visual Filters

The filter dialog is launched by clicking the Adapt Filters ([number of applied filters]) link in the page header area. In the filter dialog for visual filters, the user can choose which filter fields are shown in the visual filter bar, and make the following changes:

  • Add visual filters
  • Delete visual filters
  • Hide visual filters in the visual filter bar
  • Search for visual filters
  • Change the sort order  of each visual filter
  • Change the chart type   of each visual filter
  • Switch to other measures  in the visual filter display

Analytical List Page Content Area

The content area shows different visualizations of the selected data. In the hybrid view, users can interact with both the chart and table visualizations at the same time. In addition, the analytical list page supports a chart-only view and a table-only view. The analytical list page always comes with all three views. Offering additional views or even tabs would add too much complexity, and is neither supported nor recommended.

Check out the following sections for more details on the hybrid view, chart-only view, and table-only view.

Hybrid View

The hybrid view uses both chart and table visualizations at the same time. It enables users to analyze data step by step from different perspectives. Users can interact with both the chart and the table, and drill down through either the smart chart or table entries to investigate a root cause. They can also act directly on transactional content. In the initial view of the chart, visualize the most important aspects of the whole dataset in the chart.

Example: The view shows all the suppliers the user is responsible for, organized by value. By drilling down the material to the plant with the highest/lowest volume, the user can see if materials need to be shifted from one plant to another. The corresponding transactional data is shown in an analytical table below the chart, which might also offer an action for shifting the material.

Analytical list page - Hybrid view
Analytical list page - Hybrid view

Chart-Only View

The chart-only view enables users to analyze data step by step from different perspectives, and to investigate a root cause through drilldown, without direct access to transactional content. The smart chart control provides the chart visualization in the chart-only and hybrid views: it is used to display the dataset as a chart. The smart chart drilldown functionality provides a convenient way to analyze the dataset. In addition, the smart chart offers detailed information on the chart data and a breadcrumb that shows the drilldown path. Ensure that you show the most important aspects of the dataset in the chart.

This mode is perfect for applications with analytical data that can easily be represented visually using charts, but doesn’t need to be linked to the transactional dataset.

Analytical list page - Chart-only view
Analytical list page - Chart-only view

Table-Only View

The table view provides access to transactional content. The user can act on single or multiple objects, and navigate to the object details or to other applications.

Depending on the use case, you can opt to use either the analytical table or the responsive table.

Snapping or scrolling is not available for desktop-focused tables, such as the analytical table. The table entries are loaded with lazy loading.

Users can apply filters at table level using the Settings button ( ). For analytical tables, filtering is also available at column level. For more information, see Analytical Table (ALV) – Filter.

Analytical list page - Table-only view
Analytical list page - Table-only view

Behavior and Interaction

Open and View the Global KPI Card via the Global KPI Tag

Clicking/tapping a KPI tag opens the KPI card, which shows the details for the particular KPI.

Select Filters in the Visual Filter

Unlike micro charts, the visual filter charts are interactive. In live search mode, selecting a filter value triggers data filtering in the content area. Both single and multiple selection are supported.

To select a filter value, the user clicks on a value in the chart. The filter can be removed by either clicking on the value help link, or by clicking on the same value in the chart again. The user can select more filter values using the value help.

Any data point that is selected in a chart still remains selected when the user selects a data point in another chart. Filter values react on each other. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.

Switch Views: Hybrid, Chart-Only, and Table-Only

Users can switch between the hybrid view, chart-only view, and table-only view.

If the user selects values and then switches the view, the selection remains intact. See the table below for more details.

Switch Description
Hybrid view to table view Table selection remains intact
Hybrid view to chart view Chart selection remains intact
Chart view to hybrid view Chart selection remains intact; corresponding table selections are displayed
Table view to hybrid view Table selection remains intact

Show/Hide Table Entries in Hybrid View and Table View

The table toolbar for the analytical list page offers a Show   and Hide    table entries feature as a toggle switch in the hybrid and table views:

  • If the Show icon is active, the table shows all items. These include highlighted entries (where values are selected in the chart) and non-highlighted entries.
  • If the Hide icon is active, the table shows only items that are selected in the chart.

For example, if the user selects SAP’s Sales Revenue for 2012 as Customer in the chart, all records relating to SAP’s Sales Revenue for 2012 are highlighted (but not selected) in the table. Note that the record is still highlighted even if Customer not displayed as a column in the table. If the table rows are grouped, the entire grouping is highlighted, even if only one record within the grouped set is affected by the chart selection. All values that are not selected in the chart are “hidden” and are not shown in this table mode.

Guidelines

Show the filter dimension with one measure in the visual filter, not multiple measures

Filter dimensions in the compact filters (filter bar) have exactly one representation in the visual filter bar.
Do not show the same filter dimension with two or more different measures at the same time in the visual filter bar. The example shows the filter Dimension Year with two different measures Revenue and Quantity. Showing the filter dimensionYear twice is not in sync with the compact filter, where it is shown only once. Furthermore, matching between the two filter types will not work.

If the use case requires you to show a dimension with different measures, consider using an overview page instead.

Do
For each dimension display exactly one representation in the visual filter bar.
For each dimension display exactly one representation in the visual filter bar.
Don't
Do not use the same filter dimension with different measures
Do not use the same filter dimension with different measures

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • No links.

Object Page – Snapping Header

Warning
Do not use the object page header described in this article to build new object page apps. This article will be deprecated with guideline version 1.56.

From release 1.54, always use the dynamic header instead. The dynamic header ensures consistency across all floorplans and provides greater flexibility. For more information, see the Object Page Floorplan article.

Intro

The snapping header is the uppermost element of the object page layout. It summarizes selected data and actions in a visually prioritized position to let the user quickly grasp the most relevant information.

This snapping header control is only available for the object page floorplan.

Usage

Use the snapping header if:

  • You are using the SAP Fiori element for the object page floorplan.
  • You are creating an object page manually based on the object page floorplan.

Do not use the snapping header if:

  • You are using any other floorplan.

Responsiveness

The snapping header is designed to provide maximum flexibility. It adapts automatically to small, medium, and large screen sizes.

The header title and subtitle never truncate. If necessary, the text wraps to the next line.

The toolbar follows the standard toolbar overflow guidelines by adding the available buttons to the overflow menu from right to left.

Object Header Content Priority

Each facet in the header content area has a priority assigned to it. Content prioritization aims to support responsive behavior. Priorities allow less important content to be omitted from rendering, depending on the screen space available. The user can always access omitted content on request.

Three priority types are available: high, medium, and low. According to the screen size, the facets are distributed as follows:

  • Size L/XL: The facets with high, medium, and low priority are displayed.
  • Size M: The facets with high and medium priority are displayed.
  • Size S: Only the facets with high priority are shown.
Snapping header – Responsiveness – Size L/XL
Snapping header – Responsiveness – Size L/XL
Snapping header – Responsiveness – Size M
Snapping header – Responsiveness – Size M
Snapping header – Responsiveness – Size S
Snapping header – Responsiveness – Size S
Snapping header content priority for sizes S, M, and L
Snapping header content priority for sizes S, M, and L

Components

The snapping header comprises two main control elements:

  • Mandatory: Title bar (sap.uxap.ObjectPageHeader)
  • Optional: Header content (sap.uxap.ObjectPageHeaderContent)

There are different states for the snapping header. You can find further information within Behavior and Interaction.

Title Bar

The title bar comprises the following elements:

  • Header title (mandatory): The title is always visible.
  • Header subtitle (optional)
  • Title bar image (optional): The image has a shape parameter (square or with a round mask) and a placeholder parameter. The placeholder is displayed if no specific image is available.
  • Toolbar: The toolbar contains the global actions for the floorplan. The actions should be represented only with buttons, text, or an icon. They can be transparent, regular, highlighted, or semantic. All buttons go from right to left into the overflow. Buttons should be arranged according to the current use case and always in a consistent visual order (see guidelines for examples). If there are no global actions, the toolbar is not shown. Note that the object page uses the sap.m.Toolbar control instead of sap.m.OverflowToolbar.
  • Child page visualization: Each object page can have drilldown navigation. The child object page can only be reached through the parent object page. A narrow vertical stripe at the left side of the snapping header helps to differentiate the child object page from the parent object page.

The title bar can also contain the following optional indicators:

  • Favorite (property: markFavorite)
  • Flagged (property: markFlagged)
  • Locked (propertly: markLocked)
  • Selector (property: showTitleSelector)
  • Unsaved Changes (property: markChanges)

The title bar control also supports breadcrumb navigation. For more information scroll to section Line Item Navigation.

Snapping header – Structure
Snapping header – Structure

Header Content

The header content is optional and located below the title bar.

You can use the header content (sap.uxap.ObjectPageHeaderContent) to display app-specific contextual information. You build the content using smaller content containers, called facets. Each facet contains a distinct information set, as described below. If there aren’t any facets, the header content is always hidden.

The facets are arranged in line with a left float. Each facet adapts its size to the content and makes optimal use of the space without truncating the texts. If the facets do not all fit on one line, those on the right wrap to the line below.

If the snapping header collapses, the header content is hidden. If the header content is empty, you can also hide it.

Header container – Floating content
Header container – Floating content

Header Facets

There are several types of header facets, depending on the data that they display. The facets need to be handmade for stand-alone object pages.

Form Facet (Dataset)

The form facet can be used to display datasets in the snapping header. It consists of a headline and up to five label-text pairs.

  • The headline is optional
  • Contains at least one but maximum five label-text pairs
  • The labels can be invisible, but need to have a text for accessibility reasons
  • The labels can be icons, but need to have a text for accessibility reasons
  • Each text of a label-text pair can have a press event

Examples for the usage of form facets are document information such as creator and creation time, an address or contact information, and general information.

Developer Hint
For non-SAP Fiori element object pages only:

For each label value pair in the form header facet, a sap.m.Label and a sap.m.Text or sap.m.Link should be used and nested within an sap.m.HBox.

Header Facet - Form facets
Header Facet - Form facets

Plain Text Facet

The plain text facet can be used to display a continuous text in the snapping header. It consists of a headline and a continuous text.

  • The width of the facet does not depend on its content, but can be set. The default width of the facet is 300px.
  • The headline is optional.
  • If the headline is broader than the facet width, the headline will wrap.
  • Press events are only available inline in the continuous text. These can be links that navigate to another page or open a quick view. There can be more than one link in the continuous text with different actions.
Developer Hint
For non-SAP Fiori element object pages only:

To set the width of the plain text facet, nest the text within an sap.m.HBox and set the property:width of the sap.m.HBox.

Header facet - Plain text facet with default width
Header facet - Plain text facet with default width
Header Facet - Plain text facet with custom width
Header Facet - Plain text facet with custom width

Image Facet

The image facet can hold exactly one image. The snapping header can only hold one or no image facet.

  • The image can be either square or circular.
  • The image can also hold an icon.
  • The image can also hold initials consisting of two letters.
  • The image can have a press event. The default press event is the enlargement of the image.

When the header collapses, the image facet will move to the right of the title and become smaller.

Recommended usage of the different properties:

  • Images of people, especially portraits, should be round. If there’s no image available for a person, initials (first letters from first and last name) should be used instead.
  • All other images should be square. If there is no image available for an object, an appropriate icon should be shown instead.

In all cases it should be clear how the images will be managed and uploaded. This can either be via the edit mode of the object page or, especially when there are a lot of images, via an external tool.

Header facet – Image facet specification
Header facet – Image facet specification

Key Value Facet

The key value facet holds a label in a smaller font size and a text or number in a bigger font size. It can be used to highlight important data or KPIs of the object.

If the key value facet is used with a text such as a status, it can also have an icon on the right side next to the text. This icon has to belong to the text and should only visually support but not expand it.

Developer Hint
For non-SAP Fiori element object pages only:

Larger value texts are currently only available in SAP Fiori elements. For non-SAP Fiori element apps, the value texts have the same size as the label, as custom CSS should not be used.

Header Facet – Key value facets with KPIs and a status
Header Facet – Key value facets with KPIs and a status

Micro Chart Facet

The micro chart facet consists of a headline, a subtitle, a micro chart and a footer.

The headline and the micro chart are mandatory while the subtitle and the footer are optional. To display the unit used in the micro chart, the footer should be used.

The following micro charts can be used in the micro chart facet:

  • Bullet Chart
  • Column Chart
  • Trend Chart
  • Comparison Chart
  • Delta Chart
  • Harvey Ball Chart
  • Radial Chart

The micro chart facet can have a click or tap event on the chart itself. This could for example lead to a page with a bigger chart or open a quickview.

For more information see micro charts.

Header facet – Micro Chart Facets
Header facet – Micro Chart Facets

Progress Indicator Facet

The progress indicator facet consists of a mandatory headline and a progress indicator (sap.m.progressIndicator). Further it can have two optional supplementary texts: a subtitle and a footer.

Header Facet - Progress indicator facet
Header Facet - Progress indicator facet

 Rating Indicator Facet

The rating indicator facet consists of a headline, a rating indicator, and one or two supplementary texts, which are dependent on the use case as described below.

The rating indicator can be modified as described in the rating indicator article.

We recommend the following properties for the rating indicator used in the header facets:

  • We recommend using 5 symbols as the default.
  • We recommend using the Favorite icon as symbols.
  • We recommend using the option to also display half-stars to represent decimal values.

 

The rating indicator facet can be used for two different use cases, which are described below.

  1. Aggregated rating:

    When displaying an aggregated rating, which could be for example the average of several user reviews for a product, the facet can have a mandatory header, an optional subtitle, the rating indicator itself, and a footer.

    The subtitle should display the amount of data that the aggregation is based on. For example, in the case of an average rating, the subtitle would display the number of ratings.

    The footer should display the exact value of the aggregation in the format “2.2 out of 5”, where “2.2” indicates the exact value of the aggregation and “5” indicates the maximum value of the rating.

  2. Single value rating:

When displaying the rating as a single value, the facet can have a mandatory header, an optional subtitle and the rating indicator itself. Here the subtitle can be used as supplementary text and a footer should not be used.

Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with singe value rating
Header facet - Rating indicator facet with singe value rating

Behavior and Interaction

The snapping header has different types of behavior that can be combined:

  • Snapping
  • Title bar only
  • Header content always shown
  • Child page visualization
  • Line item navigation
  • Edit

By default, the snapping is enabled and title bar and header content are shown (expanded).

Snapping

The snapping header is always expanded for all display sizes when the user opens the object page.

When the user scrolls down the page, the header content snaps closed (collapses), leaving only the title bar. This allows the user to see more of the object page content.

You can specify which information is shown in the title bar in the expanded and collapsed states. In the example shown here, the snapping header has been configured to show only the image in the title bar when the header content area is collapsed.

Snapping header – Expanded
Snapping header – Expanded
Snapping header – Collapsed
Snapping header – Collapsed

Title Bar Only

If there is no need for the header content, the title bar-only mode can be used. This means that there is no header content shown at all, but only the title bar. This also means that there is no snapping behavior as the title bar is always shown.

Header Content Always Shown

The snapping header can stay expanded while the user scrolls down the page if the property alwaysShowContentHeader is set to true for the object page layout (sap.uxap.ObjectPageLayout). This behavior is available only for desktops.

Child Page Visualization

Each object page can have drilldown navigation. The child object page can only be reached through the parent object page. A narrow vertical stripe at the left side of the snapping header helps to differentiate the child object page from the parent object page. To navigate between the child object pages of one parent object page, arrows are displayed within the header bar of the page. To easily navigate back to the object page, breadcrumbs are used. To enable the child page visualization use property:isChildPage of sap.uxap.ObjectPageLayout.

Snapping header - Child page visualization
Snapping header - Child page visualization

Line Item Navigation

The snapping header for the object page can contain a breadcrumb that shows the navigation path for the current item. This feature was developed specifically for line item navigation within the object page.

The breadcrumb is located above the title in the title bar. The interaction is typical of a breadcrumb navigation pattern: all links in the breadcrumb chain point to a URL and are triggered by a press event.

If there is not enough space to show the full breadcrumb, it defaults to a dropdown control. In this case, the breadcrumb shows only the immediate parent of the current item. The   symbol indicates that further information is available in a dropdown list.

The dropdown list reveals all the links in the breadcrumb chain. The user reads the breadcrumb from bottom to top: the root object is at the bottom of the list, the immediate parent is at the top, and the current item is selected.

Snapping Header - Breadcrumbs
Snapping Header - Breadcrumbs

Edit

There are two different ways to edit the header information:

  • Global edit
  • Partial edit

Please note: the grand majority of object pages do not have editable header content. Therefore, the object header should not be editable by default.

Global Edit

A button in the header toolbar triggers the edit mode. For more information on global edit, see object page.

The visible facets can differ in create, edit, and display mode. If there aren’t any facets in one mode, the header content is not displayed. Choose which information supports the user best in his or her current task.

The mental model behind this possibility assumes that there are a number of header facets assigned to one given application. You can define which facets are shown in which mode.

Once the edit mode is activated, the header content is moved to a section in the content area of the object page. This section is assigned the anchor label Header. This is the first section in the document. All other sections are displayed in the order in which they had been displayed in display mode. If they’re editable, the object page title, subtitle, and image appear in the header content section. They also remain visible in the header title bar. If these are changed, they will update only as a preview.

If the image is changed in edit mode, the image in the header title bar should update only as a preview. The user will have to save the document to actually enable the changes.

Exemplary scenarios when switching from display to edit mode:

  • When all of the header elements are editable
    All of the header elements are displayed as editable forms in the Header section. The header content hides as no facets are displayed.
  • When independent header facets are present in edit mode

    All of the header elements are displayed as editable forms in the Header section. A new facet that is related to the data the user is editing is displayed in the object page header content area. This header facet is not present in display mode.
  • When only some of the header elements are editable
    All of the header elements are displayed in the Header section, but the content that is not editable is displayed as read-only to keep the layout consistent.

Partial Edit

Partial edit is used when the object page consists of large datasets and the user wants to be able to edit only the object header. Edit mode is triggered by a button that is located on the bottom right of the snapping header.

When there are only a few elements to be edited, the Edit Header button opens a dialog. When there are more editable elements, the button triggers a subpage. This subpage contains all editable data from the header without the toolbar, the navigation, and the breadcrumbs.

Style

The snapping header is available with both flavours of the Belize theme:

  • Belize (light flavor)
  • Belize Deep (dark flavor)
Snapping header – Belize
Snapping header – Belize
Snapping header – Belize Deep
Snapping header – Belize Deep

Guidelines

Breadcrumbs
Use breadcrumb navigation only on the object page, and only where there is a hierarchical drilldown within the object (line item navigation). For other types of navigation, see the SAP Fiori navigation patterns.

Header Toolbar
Do not use input fields, selects, checkboxes, search fields, or similar controls in the header toolbar. Use buttons only.

Header Content Area
Place only meaningful information in the header content containers. The content should help the user in the object context, or provide useful reference information.

Keep the header as clean and uncluttered as possible to allow users to take in the content at a glance. If there is too much information in the header, consider placing an overview section in the content area of the object page floorplan.

Themes

Until theme parameters are available for the snapping header, we recommend using the light flavor. This will avoid any contrast issues that might arise with the dark theme in the current implementation.

Images
When images are used in the object page header, you should consider the following needs:

  • How will the user manage the images?
  • How will the system block people without permission for image editing?
  • How will these images be reflected in other floorplans if they are part of the object?
  • If there are a large number of items, how would a company be able to manage images without having to navigate from page to page?
  • Will the company be able to manage the images?
Developer Hint
How to achieve a small header:

  • The header container is always optional. If there is no important data to be displayed, you can omit it. In this case, only the header title bar will be shown.
  • Omit the image if it is not necessary. It is generally the tallest element in a header container.
  • Use a light theme to reduce the emphasis in the header if there is not much information on it.
  • You can always place the information from the header into a general information section.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

List Report Floorplan

Information
This article contains general guidelines for the list report floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the list report floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items within a large set of items by searching, filtering, sorting, and grouping.
  • Users need to display the whole dataset using different visualizations (for example, as a table or as a chart), without requiring interactions between these visualizations. An example use case might be reporting.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. Views can be switched using tabs, segmented buttons, or a select control.
  • Drilldown is rarely or never used, or is only available via navigation to another page, and not as free or flexible drilldown within the page itself.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, and the item or an identifying data point is known to the user (such as a barcode). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the worklist floorplan instead.
  • Users need to extract knowledge or insights from data, either to better understand the current situation, or to identify the root cause for a certain value.  Use the analytical list page instead.
  • Charts are not only used for visualization. Users need to switch between integrated chart and table views (hybrid view). Use the analytical list page instead.
  • Users need to see the impact of their action on a KPI. Use the analytical list page instead.
  • Users need to see not only the result, but also the impact of their filter settings directly in a chart representation. Use the analytical list page instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions, such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a chart, you can display the chart on its own (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.
Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Header Title

Variant Management

Variant management is optional. If you use variants, apply them to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before the dataset is updated. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the format Filtered By (x): followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use the header toolbar for non-finalizing global actions, such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

Header Content

The header content collapses when the user scrolls down the page (with a responsive table, list, or tree only), and expands again when the user scrolls back up. To avoid this automatic expand / collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.

Users can expand and collapse the header content manually by clicking the background of the title bar. The dynamic page header can also be expanded/collapsed using the Collapse Header ( ) and Expand Header ( ) arrows at the bottom of the header area.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title.

When starting the application, expand the header content if no query was fired (and the table is therefore empty). Collapse the header content in other cases.

Header Content - Expand / Collapse Behavior

  • List Report (Floorplan + SAP Fiori Element) Header Collapsed - 1.56

Filter Bar

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search terms and the filter criteria.

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. Multiple views involve one or more of the following:

  • Showing the same table, but with different columns.
  • Showing the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

There are two options for switching between different views:

The first option is to replace the table title with a content switch. Use this approach if all views share the same sort and group states, as well as the same actions.

The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country, View by Customer, …)

The second option for switching views is to show each view in a tab container of the icon tab bar. Use this approach if all views show different states of the same data (sort states, group states, as well as item selection). Using tabs also allows you to offer different actions on the table toolbar for each view.

Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items are selected, or if the action cannot be applied to the selected items. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions
Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are no items to display, use the “no data” text of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    To start, set the relevant filters.
  • The filter was executed, but no items were found. This can also happen if the list report was opened by a related app, and the filter criteria were transferred automatically:
    No data found. Try adjusting the filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is being used for a different target.
    Only show navigation indicators for target pages the user is authorized to access.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer toolbar
Footer toolbar

Actions

Places for actions in the list report
Places for actions in the list report

(1) Global actions in the header toolbar
(2) Table actions in the table toolbar
(3) Line item actions
(4) Finalizing actions in the footer toolbar

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no item is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

If qualifying items can be identified before the action is executed, show a message about how many of the selected items the action will be applied to. In other cases, show a corresponding message after the action was executed.

Hide actions that cannot be used at all (for example, because the user has no authorization). If you are using an icon tab bar, be aware that each tab contains its own table toolbar.

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or the line item is in the wrong state.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Overview – Layouts, Floorplans, and Frameworks

SAP Fiori has a simple user interface hierarchy, designed to make the user interaction easy and intuitive. In general, the SAP Fiori launchpad is the main entry point. All the apps available to a user are presented as tiles in the app finder, while the home page shows a personalized view of tiles the user has selected. The shell bar offers an enterprise search and other services, which are available across all apps.

Most app designs are based on one of two basic page layouts:

The layout for a full screen page contains only one floorplan. The flexible column layout can also show two or even three floorplans next to each other. The term “floorplan” represents different layout types for whole pages. The floorplan defines the structure of the controls used, and how to handle different use cases.

Layouts and floorplans can be built with SAP Fiori elements, or built from scratch (freestyle apps).

Overview of layouts and floorplans
Overview of layouts and floorplans

Overview of Layouts

Layout Use Case SAP Fiori Elements
Dynamic Page Layout The dynamic page is a layout control designed to support various floorplans and use cases. The design of the dynamic page header helps users to focus on the actual page content, but still ensures that important header information and actions are readily available.  Available
Flexible Column Layout The flexible column layout is a layout control that displays multiple floorplans on a single page. This allows faster and more fluid navigation between multiple floorplans than the usual page-by-page navigation. The flexible column layout offers different layouts with up to three columns. Users can expand the column they want to focus on, switch between different layouts, and view the right-hand column in full screen mode.  Available

Note: The full screen layout and split screen layout were deprecated with version 1.48.

Overview of Floorplans

Floorplan Use Case SAP Fiori Elements
Analytical List Page The analytical list page offers dynamic data visualization and business intelligence capabilities that enable users to analyze data step by step from different perspectives. Users can drill down to investigate a root cause, and act on transactional content.  Available
List Report The list report floorplan enables users to view and work with a large set of items. It offers powerful features for finding and acting on relevant items.  Available
Worklist A worklist displays a collection of items that a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it. Available
Overview Page The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.  Available
Object Page The object page floorplan allows the user to display, create, or edit an object. This is now the recommended floorplan for representing both simple and complex objects in SAP Fiori.  Available
Initial Page The initial page floorplan allows the user to navigate to a single object to view or edit it. The interaction point on the screen is a single input field that relies on assisted input to direct the user to the object in as few steps as possible (using features such as value help and live search).
Wizard The wizard floorplan allows users to complete a long or unfamiliar task by dividing it into sections and guiding the user through it.

Additional Layout Options

Layout Use Case
Multi Instance The multi-instance layout allows users to open multiple documents in a tabular view. After selecting items from a list, the user opens them in a tab container.
Dynamic Side Content Dynamic side content is a layout control that displays additional content to help the user better understand the data being displayed on the screen. The display of the side content adapts flexibly to different screen sizes.
Additional layout options
Additional layout options

Overview of Frameworks

Framework Use Case
Analysis Path  Analysis Path Framework (APF) is a framework for creating interactive, chart-oriented analytical drilldown apps by configuration.
SAP Smart Business SAP Smart Business drilldown is an analytical app. It enables the user to view and analyze the data for one key performance indicator (KPI).

Analytical List Page (SAP Fiori Element)

Analytical list page – Size XL
Analytical list page – Size XL

The analytical list page (ALP) offers a unique way to analyze data step by step from different perspectives, to investigate a root cause through drilldown, and to act on transactional content. All this can be done seamlessly within one page. The purpose of the analytical list page is to identify interesting areas within datasets or significant single instances using data visualization and business intelligence.

Visualizations help users to recognize facts and situations, and reduce the number of interaction steps needed to gain insights or to identify significant single instances. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

The main target group are users who work on transactional content. They benefit from fully transparent business object data and direct access to business actions. In addition, they have access to analytical views and functions without having to switch between systems. These include KPIs, a visual filter where filter values are enriched by measures and visualizations, and a combined table/chart view with drill-in capabilities (hybrid view). Users can interact with the chart to dig deep into the data. The visualization enables them to identify spikes, deviations and abnormalities more quickly, and to take appropriate action right away.

Usage

Use the analytical list page if:

  • Users need to extract key information to understand the current situation or identify a root cause. The way the data is presented is crucial for giving them the insights they need to take the right action.
  • Users need a way to analyze data step by step from different perspectives, investigate a root cause through drilldown, and act on transactional content within one page.
  • In addition to the filtered dataset, users need to see the impact of their filter settings in a chart (visual filter).
  • Users need to switch between integrated chart and table views (hybrid view).
  • Users need to see the impact of their action on a global key performance indicator (KPI).
  • Users need to find and act on relevant items out of a large set of items by searching, filtering, sorting, grouping, drilling down, and slicing and dicing.

Do not use the analytical list page if:

  • Drilldown is rarely used, not used at all, or is only needed after navigating to another page, rather than as free or flexible drilldown within the page itself. In this case, a list report might be sufficient for your use case.
  • Users need different visualizations for the entire dataset (for example, as a table or chart), but don’t need to work with both visualizations on the same page (for example, in a reporting scenario). In this case, a list report might be sufficient.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping, without using drilldown or “slice and dice”. In this case, consider using a list report.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. They want to be able to switch views using tabs, segmented buttons, or a select control. In this case, consider using a list report.
  • Users need to see or edit a single item with all its details. Use the object page floorplan instead.
  • Users need to find a specific item, and the item or an identifying data point is known to the user (such as a barcode). In this case, use the initial page floorplan.
  • Users need to work through a comparably small set of items, one by one. In this case, use the worklist floorplan.
  • Users have a trivial use case that does require the use of a chart, but that do not involve identifying a root cause, analyzing data, or drilldown. Instead, use a list report with a table/chart switch.

Structure

This section describes the basic layout of the analytical list page, as well as the different layout variants.

Basic Layout

The shell bar is on top of the analytical list page. The page itself uses the dynamic page layout and has two main areas:

  1. Analytical list page header: The page header has two states: collapsed and expanded. The content shown depends on the state. The user can easily switch the state using the visual indicator.
  2. Analytical list page content area: This area combines three different views and a view switch:
    • Hybrid view (combined chart and table view)
    • Chart-only view
    • Table-only view

All elements are described in more detail in the Components section below.

Analytical list page - Basic layout
Analytical list page - Basic layout

Layout Variants

The layout of the analytical list page is quite flexible. Depending on the state of the analytical page header and the view in the content area, different content is displayed.

For example, the expanded page header allows users to display either the visual filter bar or the filter bar, while the page content area can display either a hybrid view, a chart-only view, or a table-only view.

Analytical List Page Layout Variants

  • Analytical list page - Hybrid view (collapsed)
  • Analytical list page - Hybrid view with visual filters (expanded)
  • Analytical list page - Hybrid view with compact filters (expanded)
  • Analytical list page - Chart view (collapsed)
  • Analytical list page - Chart view with visual filters (expanded)
  • Analytical list page - Chart view with compact filters (expanded)
  • Analytical list page - Table view (collapsed)
  • Analytical list page - Table view with visual filters (expanded)
  • Analytical list page - Table view with compact filters (expanded)

Responsiveness

The analytical list page is responsive, except for the global KPIs. Apps with one or more global KPIs are not supported on screen sizes smaller than size L (desktop).

Likewise, the analytical list page is only fully supported in the flexible column layout if no global KPIs are used. If you use the analytical list page with global KPIs within the flexible column layout, the column should have at least size M.

Size S

On size S, the analytical list page supports both the chart-only and table-only views. The table-only view supports only the responsive table. If no responsive table is available, the chart-only view is displayed without a view switch toggle.

Global KPIs are not supported on size S.

Size M

On size M, the analytical list page supports both the chart-only and table-only views. You can use a responsive table or analytical table in the table-only view.

Chart-only view - Size S
Chart-only view - Size S
Table-only view - Size S
Table-only view - Size S
Chart-only view - Size M
Chart-only view - Size M
Table-only view - Size M
Table-only view - Size M

Component Overview

Analytical List Page Header

The page header can be expanded and collapsed on click/tap. Different content is shown in the expanded and collapsed states.

Collapsed Header

The collapsed page header contains the following elements:

Collapsed analytical list page header
Collapsed analytical list page header

Expanded Header

The expanded page header contains the following elements:

Expanded analytical list page header showing the visual filter bar
Expanded analytical list page header showing the visual filter bar
Expanded analytical page header showing compact filters in the filter bar
Expanded analytical page header showing compact filters in the filter bar

Analytical List Page Content Area

The analytical list page content area contains the following elements:

  • View switch (   |    |    )
  • Hybrid view: View with one chart, chart toolbar, one table, and a table toolbar
  • Chart-only view: View with one chart and a chart toolbar
  • Table-only view: View with one table and a table toolbar

Analytical List Page Content Area

  • Hybrid view
  • Chart-only view
  • Table-only view

Analytical List Page Header

Variant Management

Variant management in the analytical list page allows users to save a page variant whenever there are changes in the underlying structures of the filter/content area. Variant management for the page is handled by the standard SAPUI5 page variant management.

Currently, the page variant captures the following states across the page:

  • Filter view switch state: Visual filter bar or filter bar
  • Filter set: The filters set in the visual filter bar and filter bar
  • Filter selections: Selected values in the visual filter bar and filter bar
  • Content view switch state: hybrid view  , chart-only view  , or table-only view  
  • Chart and table configurations, such as measures and dimensions used, sort order, or grouping
  • Chart drill-down state, based on the current selections (slice & dice)
  • Table entry switch state: Hide (  ) or Show  (  ) selected table records
Standard page variant management
Standard page variant management

Global KPI Tags and Cards

Use a global KPI tag (= global key performance indicator tag) if you would like to show a global KPI related to the task in hand. The global KPI value changes only if an action is executed on the transactional content. For example, the user needs to know the effect of releasing sales orders on a related global KPI, or the effect of posting an accounting document on certain financial global KPIs.

You can display a maximum of three global KPIs. Clicking a global KPI tag opens a global KPI card that displays more details on the KPI.

The global KPI tags and corresponding KPI cards are independent of the filter area. This means that global KPI tags do not react to filters set in the visual filter bar and filter bar.

A global KPI tag has four components:

  • Global KPI label
  • Global KPI value
  • Global KPI color and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator

Global KPI Label

The global KPI label is an abbreviation of the complete global KPI title. It is formed using the first three letters of the first three words of the global KPI title.
Examples: AMR for Actual Monthly Revenue, TAR for Total Advertising Revenue, or LPC for Landing Page Conversation Rates

If there is only one word in the global KPI title, the first three letters of the word are displayed. Example: CON for Contracts

If the global KPI title has only two words, only the first letters of these two words are displayed. Examples: AC for Actual Costs, SG for Sales Growth

KPI label abbreviation: AC
KPI label abbreviation: AC

Global KPI Value

The global KPI value is displayed using a semantic color and a scaling factor. Relative values are shown with a percentage sign and one decimal place.
Examples: 0.3%, 82.9%
Absolute values are shown without decimal places, a currency, or a unit of measure.
Examples: 2K, 75K, 30M, 14B

KPI values: 2K and 0.3%
KPI values: 2K and 0.3%

Global KPI Color and Criticality Indicator

The color of the global KPI value is based on the thresholds defined for the particular KPI in the annotation. The global KPI tag also uses a line to indicate the criticality. The color of the line is the same as that of the global KPI value.

KPI color and criticality indicator
KPI color and criticality indicator

Global KPI Card

Clicking the KPI tag opens the analytical card, which displays more information about the current value of the global KPI, the global KPI target, the deviation from the target, and how the global KPI has evolved over time.

Global KPI card
Global KPI card

Filter Area: Visual Filter Bar and Filter Bar

The filter area allows users to filter the result set, which feeds the main content area. The analytical list page comes with two filter types: compact filters in the filter bar, and the visual filter bar. Always design both visual filters and compact filters (filter bar) for your app. We recommend setting the visual filter bar as the default, but this is no longer mandatory. You can opt to use the (compact) filter bar as the default if your app has the required parameter values, if your main use case involves date ranges, or if your users often need to combine multiple filters in different ways.

Currently, any visual filter configured in the visual filter bar must always be displayed as a compact filter in the filter bar as well. By contrast, a filter configured as a compact filter in the filter bar may or may not be configured for display as a visual filter. This means that it’s possible to have a smaller set of visual filters and a larger set of compact filters.

Both filter types supports two different modes: live update and manual update. Use the live update mode for both filter types as the default whenever possible. Apply the same mode to both filter types: the visual filter bar and the filter bar. For example, if you use the live update mode in the visual filter bar, you should also use the live update mode for the filter bar.

Visual filter bar
Visual filter bar
Filter bar
Filter bar

Filter Type Switch

Users can toggle between the compact filters    (filter bar) and the visual filter bar    in the upper-right area of the page header. The filter type switch is a core feature of the analytical list page and is mandatory. The switch is only displayed when the page header is expanded. Once the header collapses, it disappears.

Filter type switch
Filter type switch

Carrying Forward Filter Selections

Visual Filter to Compact Filter

Any values selected in the visual filters are always carried forward to the corresponding compact filters.

Compact Filter to Visual Filter

Filter dimensions that are part of a visual filter are synced to the visual filter. If the dimension value(s) chosen in the compact filter are part of a visual filter, they are shown as selected chart dimensions in the visual filter (single or multiple selections).

Filter dimensions that are not part of the visual filter, parameter values, and interval-based dimensions are applied to the filter query and the content is refreshed.

To show complex conditions, click the link for the number of selected items at the top of the visual filter.

Visual Filter Bar

The visual filter bar combines measures or item counts with filter values. The visual filter bar becomes more powerful if you match measures to the filter dimension instead of just item counts. Use the visual filter bar if you would like to give the user a condensed overview of the data in the dataset. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

Chart Types in the Visual Filter Bar

Currently, the visual filter bar supports three interactive chart types:

These interactive charts are also referred to as visual filters.

Interactive Donut Chart

The interactive donut chart in the visual filter bar is used for non-time-related data (for example, categories) and displays only the top or bottom two values. The rest are aggregated into the “Other” section.

Interactive donut chart
Interactive donut chart
Interactive donut chart with semantic colors
Interactive donut chart with semantic colors

Interactive Line Chart

The interactive line chart is used exclusively for displaying time series data, and can show a maximum of six data points. Always show the first or last six data points (for example, last six days, last six months, first six days, and so on).

Interactive line chart
Interactive line chart
Interactive line chart with semantic colors
Interactive line chart with semantic colors

Interactive Bar Chart

The interactive bar chart can be used for non-time-related data (for example, categories) and has a maximum of three filter values. These filter values show the top three or bottom three entries.

Interactive bar chart
Interactive bar chart
Interactive bar chart with semantic colors
Interactive bar chart with semantic colors

The interactive charts come with a number of features and rules:

  • Minimum number of interactive charts: Show at least three visual filters and try to use different chart types.
  • Filter title: Use the following naming convention for the filter title, using title case: [Measure Name] by [Dimension Name] in [Scale Factor] [Unit of Measure]. For example, Project Costs by Project in K EUR, Sales Volume by Commodity in M PC. For an item count, use the following naming convention for the filter title, using title case: Number of [Dimension] in [Scale Factor] [Unit of Measure]. For example, Number of Products in PC or Number of Contracts by Month. Note that for some use cases, it might be appropriate to replace Number with a different expression.
  • Filter-to-filter dependencies: Ideally, the filters depend on each other. By selecting one or several chart data points, users can perform a quick analysis of the dataset.
    Examples: Supplier with the lowest supplier performance this year, product with the highest sales volume in March in the EMEA region
  • Adding additional filter values: All charts have a maximum number of filter values that can be displayed within the chart itself. More filter values can be selected using the value help.
  • Selected values: Any data point or segment that is selected in the visual filter’s interactive charts will remain selected even when the user changes the measure, chart type, or sort order in any of the charts. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.
  • Semantic colouring: All interactive charts support semantic colors to indicate the criticality of filter values.
  • How to design a visual filter: To design a visual filter, choose a meaningful measure out of the dataset and match it to a filter dimension. If no measures or no meaningful measures are available, use an item count instead. Have a look at the visual filter bar article for more information.

Filter Dialog

In the filter dialog, the user can switch between the visual filter bar filters and the filter bar filters using a toggle button. The standard filter dialog is explained in the Filter Bar article. The part for the visual filter is further explained below.

Filter Dialog for Visual Filters

The filter dialog is launched by clicking the Adapt Filters ([number of applied filters]) link in the page header area. In the filter dialog for visual filters, the user can choose which filter fields are shown in the visual filter bar, and make the following changes:

  • Add visual filters
  • Delete visual filters
  • Hide visual filters in the visual filter bar
  • Search for visual filters
  • Change the sort order  of each visual filter
  • Change the chart type   of each visual filter
  • Switch to other measures  in the visual filter display

Analytical List Page Content Area

The content area shows different visualizations of the selected data. In the hybrid view, users can interact with both the chart and table visualizations at the same time. In addition, the analytical list page supports a chart-only view and a table-only view. The analytical list page always comes with all three views. Offering additional views or even tabs would add too much complexity, and is neither supported nor recommended.

Check out the following sections for more details on the hybrid view, chart-only view, and table-only view.

Hybrid View

The hybrid view uses both chart and table visualizations at the same time. It enables users to analyze data step by step from different perspectives. Users can interact with both the chart and the table, and drill down through either the smart chart or table entries to investigate a root cause. They can also act directly on transactional content. In the initial view of the chart, visualize the most important aspects of the whole dataset in the chart.

Example: The view shows all the suppliers the user is responsible for, organized by value. By drilling down the material to the plant with the highest/lowest volume, the user can see if materials need to be shifted from one plant to another. The corresponding transactional data is shown in an analytical table below the chart, which might also offer an action for shifting the material.

Analytical list page - Hybrid view
Analytical list page - Hybrid view

Chart-Only View

The chart-only view enables users to analyze data step by step from different perspectives, and to investigate a root cause through drilldown, without direct access to transactional content. The smart chart control provides the chart visualization in the chart-only and hybrid views: it is used to display the dataset as a chart. The smart chart drilldown functionality provides a convenient way to analyze the dataset. In addition, the smart chart offers detailed information on the chart data and a breadcrumb that shows the drilldown path. Ensure that you show the most important aspects of the dataset in the chart.

This mode is perfect for applications with analytical data that can easily be represented visually using charts, but doesn’t need to be linked to the transactional dataset.

Analytical list page - Chart-only view
Analytical list page - Chart-only view

Table-Only View

The table view provides access to transactional content. The user can act on single or multiple objects, and navigate to the object details or to other applications.

Depending on the use case, you can opt to use either the analytical table or the responsive table.

Snapping or scrolling is not available for desktop-focused tables, such as the analytical table. The table entries are loaded with lazy loading.

Analytical list page - Table-only view
Analytical list page - Table-only view

Behavior and Interaction

Global KPI Card/Tag

Clicking/tapping a KPI tag opens the KPI card, which shows the details for the particular KPI.

Select Filters in the Visual Filter

Unlike micro charts, the visual filter charts are interactive. In live search mode, selecting a filter value triggers data filtering in the content area. Both single and multiple selection are supported.

To select a filter value, the user clicks on a value in the chart. The filter can be removed by either clicking on the value help link, or by clicking on the same value in the chart again. The user can select more filter values using the value help.

Any data point that is selected in a chart still remains selected when the user selects a data point in another chart. Filter values react on each other. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.

Switch Views: Hybrid, Chart-Only, and Table-Only

Users can switch between the hybrid view, chart-only view, and table-only view.

If the user selects values and then switches the view, the selection remains intact. See the table below for more details.

Switch Description
Hybrid view to table view Table selection remains intact
Hybrid view to chart view Chart selection remains intact
Chart view to hybrid view Chart selection remains intact; corresponding table selections are displayed
Table view to hybrid view Table selection remains intact

Show/Hide Table Entries in Hybrid View and Table View

The table toolbar for the analytical list page offers a Show   and Hide    table entries feature as a toggle switch in the hybrid and table views:

  • If the Show icon is active, the table shows all items. These include highlighted entries (where values are selected in the chart) and non-highlighted entries.
  • If the Hide icon is active, the table shows only items that are selected in the chart.

For example, if the user selects SAP’s Sales Revenue for 2012 as Customer in the chart, all records relating to SAP’s Sales Revenue for 2012 are highlighted (but not selected) in the table. Note that the record is still highlighted even if Customer not displayed as a column in the table. If the table rows are grouped, the entire grouping is highlighted, even if only one record within the grouped set is affected by the chart selection. All values that are not selected in the chart are “hidden” and are not shown in this table mode.

Guidelines

Show the filter dimension with one measure in the visual filter, not multiple measures

Filter dimensions in the compact filters (filter bar) have exactly one representation in the visual filter bar.
Do not show the same filter dimension with two or more different measures at the same time in the visual filter bar. The example shows the filter Dimension Year with two different measures Revenue and Quantity. Showing the filter dimensionYear twice is not in sync with the compact filter, where it is shown only once. Furthermore, matching between the two filter types will not work.

If the use case requires you to show a dimension with different measures, consider using an overview page instead.

Do
For each dimension display exactly one representation in the visual filter bar.
For each dimension display exactly one representation in the visual filter bar.
Don't
Do not use the same filter dimension with different measures
Do not use the same filter dimension with different measures

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • No links.

Worklist Floorplan

Information
This article contains general guidelines for the worklist floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the worklist floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

A worklist displays a collection of items that a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan is on processing the items. This differs from the list report floorplan, which focuses on finding and acting on relevant items from a large dataset.

Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Users need to work with multiple views of the same content (for example, items that are “Open”, “In Process”, or “Completed”. Users can switch between views using the tab bar.

Do not use the worklist floorplan if:

  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (charts or tables). In this case, use the list report floorplan instead.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping. Use the list report floorplan instead.

Layout

The worklist floorplan is based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, KPI information (if relevant), and a header toolbar with global actions, such as Share.
  • The content area: Use this to display:
    • An icon tab bar in the content area
    • One table (per tab)
    • You can use any kind of table and list. To ensure that the application runs on all devices, we recommend using the responsive table.
Basic structure
Basic structure

Responsiveness and Adaptiveness

In general, the worklist floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

Worklist floorplan - Size S
Worklist floorplan - Size S
Worklist floorplan - Size M
Worklist floorplan - Size M
Worklist floorplan - Size L
Worklist floorplan - Size L

Guidelines

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a table.

Simple worklist without tabs
Simple worklist without tabs

Worklist with Tabs

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs show different perspectives on the same dataset.

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red for the Error tab).

Worklist with tab categories
Worklist with tab categories

Worklist with KPI

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI within the KPI container next to the page title as an object status.

Worklist with KPI
Worklist with KPI

Header Title

Variant Management

Variant management is optional. If used, apply it to the whole page. Use the variants to save and restore all settings, including selected tabs, all tables, and all personalization settings.

If variant management is not needed, just show a title that describes the current view instead.

Header Toolbar (Global Actions)

Use this for non-finalizing global actions such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

In addition, offer any other global, non-finalizing actions that are needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Page Content

Tab Bar

The tab bar is part of the page content container, which means that the tab bar is not “sticky” and will scroll away when the user scrolls down the page.

Use the icon tab bar. Display the number of items shown in the table on each tab (sap.m.IconTabFilter, property: count). Only use icons if you need to display semantic colors on the icon tab bar.

The tab bar works as a filter on the content below.

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. For filter, sort, and group, show a view settings dialog with only the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items or only unsuitable items are selected. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table actions, see the guidelines for the table toolbar and for managing objects.

Table

If there are no items to display, use the “no data text” of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • The search was executed, but no items were found: No items found. Try adjusting your search criteria.
  • By opening a related app, the filter criteria were transferred automatically, but no items were found: No items found. Check the search and filter settings.

There are three types of navigation at item level in the worklist floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation. In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation. Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is used for a different target.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually a list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting. In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object, as well as a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Actions

The worklist offers four locations for actions: global actions, table actions, line item actions, and finalizing actions.

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the standard Share action.

The Share button opens an action sheet that contains actions like Save as Tile (if the SAP Fiori Launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space in the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

Global actions
Global actions

2. Table Actions

Place actions that affect the content of a table in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no item is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on table actions, see the guidelines for the table toolbar and for managing objects.

Toolbar actions
Toolbar actions

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this option only for specific, frequently-used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or if the line item has the wrong state, for example.

Inline actions
Inline actions

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Finalizing actions
Finalizing actions

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen. Once the user has completed the task, the app should:

  • Return the user to the worklist
  • Remove the processed item from the list, or move it to a “completed” section
  • Confirm the user’s action with a message toast

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Wizard Floorplan

The wizard floorplan allows users to complete a long or unfamiliar task by dividing it into sections and guiding the user through it. The wizard consists of the walkthrough screen, where the form sections are revealed in sequence after each one is completed, and the summary page, where the form is displayed in read-only mode for assessment and final submission. You can use the wizard both in full-screen and flexible column layout.

Wizard - Steps
Wizard - Steps

Usage

When to Use the Wizard Floorplan

The wizard aims to help users by dividing large or complex tasks into segments. Use the wizard if the user has to accomplish a long task (such as filling out a long questionnaire) or a task that is unfamiliar to the user. The flow should consist of a minimum of 3 and a maximum of 8 steps.

The wizard can be used for both create and edit scenarios. If your application contains both, consider using the same means for both scenarios – either the wizard, or another create/edit screen (edit flow or object page).

When Not to Use the Wizard Floorplan

If you have a task with only 2 steps or a format that the user is familiar with (for example, it is part of their daily routine), do not use the wizard as it only adds unnecessary clicks to the process. If your process needs more than 8 steps, the wizard will not support those steps as the process is too long and can be confusing for the user. In this case, you should consider restructuring the task.

Consider if the classic edit screens (edit flow or object page) are more suitable for your use case.

Structure

The wizard has two main screens: the walkthrough screen, where users complete a segmented task, and the summary screen, where they can check the data they are about to submit. Wizard content is not restricted to forms; other content such as a value help dialog can also be used.

Walkthrough Screen

The walkthrough screen is the wizard’s main screen. After triggering the wizard, the user is taken to the walkthrough screen, which shows only the first section of the form. Once the user has filled out all the necessary fields, a Step XY button appears, which allows the user to move to the next step. When the user has completed the last section of the wizard, the button label changes to Review and the user is taken to the summary screen.

The wizard footer is used to display the Cancel button, which exits the wizard. If the user has modified any fields, a data loss message also prompts the user. You can also use a Save as Draft function in the footer if the form is long and the user may have to save it before finishing it.

Walkthrough screen in full screen layout
Walkthrough screen in full screen layout

The title in the header toolbar above the wizard remains unchanged during all the wizard steps. Align this title left, and make it clear to users where they are and what they are doing (for example, Create Sales Order or Edit Sales Order 4815162342). Especially in edit scenarios, it is vital to give users a unique identifier for the object they are changing.

Header toolbar with title
Header toolbar with title

The progress bar/anchor navigation below the header highlights the completed steps and the current step. It also allows the user to navigate between steps by clicking on any of the circles.

The progress bar exhibits a grouping behavior if there are multiple steps and the screen width is reduced. This behavior is the same on smartphone, tablet, and desktop screens.

Wizard header and anchor navigation
Wizard header and anchor navigation
Wizard tooltip – Grouped steps
Wizard tooltip – Grouped steps

In certain use cases, the steps in the wizard depend on the choices the user makes along the way. The user’s entries for one step determine the follow-on steps (“branching”). In these cases, a dotted line shows that more steps will follow.

Wizard branching
Wizard branching

Since the wizard is a lightweight way to create or edit objects, applications can use a quick confirmation popup instead of the heavier data loss message, when the user selects Cancel.

If the wizard is used to create an object, the text on the popup should read ‘Discard this ?’ (see image below).If the wizard is used to edit an object, please use the text ‘”Discard changes?” In both cases, the action on the popup should be Discard.

Structure – Quick confirmation
Structure – Quick confirmation

Summary Screen

On the summary screen, users can check all their entries before the object is actually created or changed. The summary screen has no progress bar or anchor navigation, and shows the form sections for all the steps in read-only mode.

To allow the user to go back and edit entries, provide an Edit button either in the footer toolbar or in each form section:

  • If you place the Edit button is placed in the footer toolbar, the user is taken back to the first section of the wizard.
  • If you offer Edit buttons for each section of the form, the user jumps to that particular step.

Alternatively, users can click or tap the Back button to go to the previous step. From there, they can scroll or tap through the sections.

The main action on the summary page should be the final action after completing the wizard, such as Create or Save.

Wizard summary page example
Wizard summary page example

Layout

Thanks to the wizard’s responsive behavior, it can be used both in a full-screen layout as well as in the flexible column layout. Since there are no subsequent pages after the wizard, it will always occupy the rightmost column – there is no navigation from the wizard to a next page. After completion (or cancellation), the user will always come back to the page the wizard was triggered from.

Wizard in full screen layout
Wizard in full screen layout
Wizard in flexible column layout (2/3)
Wizard in flexible column layout (2/3)
Wizard in flexible column layout (1/3)
Wizard in flexible column layout (1/3)

Types

There are two types of wizard – “standard” and “branching” – which differ in terms of the functions they offer.

Use the standard type if:

  • The total number of steps is known in advance.
  • The number of steps does not change during usage.
  • There is linear progression from one step to the next.

Use the branching type if:

  • The total number of steps is not known.
  • The number of steps may change during usage.
  • There is non-linear progression. In other words, the user’s choice during one step determines which step comes next.

In both types of wizard you can let users skip steps. Label these steps as “Optional”.

Styles

In addition to the functional types, there are also different visual styles.

Numbers and Icons

By default, both versions use a number inside a circle to represent each step. You can also use icons instead of numbers to help users identify the steps. If you plan to use icons, be sure to assign icons to all the steps (not just to some). The icons you choose should be unique and not look too similar. This will ensure that users do not get individual steps confused with one another.

Steps represented by numbers
Steps represented by numbers
Steps represented by icons
Steps represented by icons

Labels

To help users identify the individual steps even more easily, app developers can assign labels. As with icons, labels must be applied to all or none of the steps.

If there is enough horizontal space, all labels are shown.

All labels are visible
All labels are visible

As the width is reduced, the steps outside the currently selected one do not show labels.

Labels - reduced width
Labels - reduced width

Finally, the unselected and outermost steps are stacked on top of each other to further accommodate the reduced space.

Stacked labels
Stacked labels

Users can still easily access steps inside a stack. A single click opens a list of steps inside this stack.

Labels - stacked popover
Labels - stacked popover

Optional Steps

For optional steps, add an (Optional) label. Place the (Optional) label below the content label for the step.

Do
Correct: '(Optional)' label below the content label for the step
Correct: '(Optional)' label below the content label for the step
Don't
Incorrect: '(Optional)' label directly after the label for the step
Incorrect: '(Optional)' label directly after the label for the step

Explanatory Texts

Ideally, the headlines and field labels for each step should provide enough information for users to complete their tasks. However, if additional explanations are needed, applications can put a simple text underneath a step’s headline – either via the sap.m.Text or the sap.m.FormattedText control.

Responsiveness

The wizard supports all common screen sizes and is available in cozy and compact modes, as well as high-contrast black (HCB).

Wizard – Size S
Wizard – Size S
Wizard – Size M
Wizard – Size M
Wizard – Size L
Wizard – Size L

Behavior and Interaction

Navigation, Error- and Draft Handling

Navigation

Users can trigger the wizard app from another application, from the launchpad, or from a notification. The wizard always starts at the initial walkthrough page and ends after the user has clicked the main action (such as Submit) on the summary screen. The Step XY button is only used on the walkthrough page. This button loads the next section of the form. On the summary page, the user can use either the Edit button in the footer or the “back” arrow to return to the wizard and edit any of the fields.

Modifying dependent steps: If there are steps that depend on each other (for example, a selection in step 2 triggers an additional step) and the user modifies the parent step, the dependent step is changed or deleted. Beforehand, the user is warned that data will be lost.

Error Handling

Error handling is done via message popovers. When the user clicks the Step XY button, the form sections and fields should be validated. When the user clicks the Submit button on the summary page, the entire form is validated. If there are any errors, the user stays on the walkthrough page, the message popover is displayed, and clicking any of the error items scrolls the page to the relevant field, which is also highlighted in red.

Section validation differs from validation of the entire form. In the first case, correct data entry in the form fields is validated. In the second case, the entire form is checked for backend system errors (such as duplicated data entry).

Draft Handling

If a draft already exists when a user enters the wizard, show a dialog to inform the user. For more information, please visit the draft handling article.

Dynamic Page

Header

Even though the wizard floorplan consumes the dynamic page, the wizard’s header does not allow snapping. Due to the nature of the wizard floorplan, the wizard brings its own step-based header that is already very space-saving.

Footer Toolbar

Contrary to the header, the footer toolbar of the wizard floorplan conforms to the standard layout and uses the sap.m.bar control.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • Wizard (SAPUI5 API reference)
  • Wizard (SAPUI5 samples)
  • Form (SAPUI5 API reference)
  • Form (SAPUI5 samples)

Object Page Floorplan

Information
This article contains general guidelines for the object page floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the object page floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

The object page floorplan allows the user to display, create, or edit an object. This is the recommended floorplan for representing both simple and complex objects in SAP Fiori. The object page floorplan comes with a flexible header, a choice of anchor or tab navigation, and a flexible, responsive layout. These features make it adaptable for a wide range of use cases.

Object page floorplan
Object page floorplan

Usage

Use the object page floorplan if:

  • Users need to see, edit, or create an item with all its details.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

  • Users want to edit several items at the same time. Use the list report floorplan instead.
  • Users need to find relevant items without knowing the exact item details. Use the list report floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner). Use the initial page floorplan instead.
  • Users need to be guided through a series of steps when a new object is created. Use the wizard floorplan instead.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected. Use the wizard floorplan instead.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL).

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The layout for size XL (large display) contains four columns.

The default layout for size L (desktop) contains three columns. You can also use an optional two-column layout.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Structure

Warning
Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility. More information can be found here.

The object page is a full screen floorplan with a display mode, a create mode, and an edit mode.

In all modes, the object page contains:

  • A dynamic header (formerly the snapping header)
  • A navigation bar
  • A content area

The following sections explain these components in more detail.

Schematic visualization of the object page
Schematic visualization of the object page

Header

The header is the uppermost element of the object page floorplan. It contains key information about the business object and provides the user with the necessary context. The header also contains global actions for the object.

Ensure that you build the object page using the dynamic header and not the former object page header. This ensures consistency across all floorplans and provides greater flexibility.

For an example of the object page with the dynamic header, see this SAPUI5 sample. An example with an image can be found here.

Object page with the dynamic header
Object page with the dynamic header

Please note:

  • To display images and placeholders in the header, use the avatar control.
  • The object header facets described in the snapping header article should be also used in the new dynamic header.
  • The subtitle is now below the title. (For the object page header it was next to the title.)

Toolbars

The object page supports two toolbars:

  • Header toolbar: Use this toolbar for global actions such as Edit, Delete, Copy and Share.
  • Floating toolbar: Use this toolbar for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

This applies to all object page modes (display, edit, and create).

Responsive overflow toolbar
Responsive overflow toolbar

Navigation

There are three ways to navigate within the object page:

  • Anchor bar (by default)
  • No navigation (flat scrollable page)
  • Tabs

Usage

  • To offer a flat page for a simple object, remove the navigation.
  • For more complex objects, use the anchor or tab navigation.
Object page – Anchor navigation
Object page – Anchor navigation

Anchor Bar and Overflow

The anchor bar is the default navigation control for the object page. It consist of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint

Anchor Bar and Overflow

Use title case for the anchor bar texts. To do this, you need to change the default capitalization (block caps) by changing the the property upperCaseAnchorBar to “false”.

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow overview button on the right of the navigation bar ( ) opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow overview button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the document.

Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow overview button
  8. Overflow overview dropdown
  9. Section (hover) in overflow overview
  10. Section in overflow overview
  11. Subsection in overflow overview

Behavior and Interaction

  • Clicking an anchor link scrolls the page to the selected section.
  • Clicking a section anchor that contains more than one subsection opens a subsection menu.
  • Clicking a subsection scrolls the page to the selected subsection. The keyboard left and right arrows allow the user to move between the anchor links.
  • Hovering over the fade area to the left or right of the anchor bar causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
  • Clicking the overflow scroll button (right arrow) scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
  • Clicking the overflow overview button ( ) displays a hierarchical dropdown list with all the sections and subsections of the document. Clicking an item in the overflow list scrolls to the respective section or subsection.

Hiding the Navigation

You can hide the navigation bar from the object page, leaving a flat, scrollable object. We recommend using this flat view for simple content that doesn’t require anchor navigation.

Tab Navigation

As an alternative to anchor navigation, you can also opt for tab navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. Tab navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional and the default state is “false”. If the state is set to “true”, a dropdown arrow is shown next to the tab. Clicking on the tab displays a dropdown menu with the subsection anchors for that tab.

Object page – Tab navigation
Object page – Tab navigation

Breadcrumbs

If the object page uses a hierarchical parent-child drilldown, you can offer a breadcrumb for navigation. The breadcrumb is part of the snapping header.

Content Area

The object page content consists of sections and subsections arranged in a column layout. For large documents, you can enable a lazy loading mechanism (property: enableLazyLoading) to mitigate the loading time.

Sections

Sections are containers for subsections. They provide the basic structure for navigation, and are directly reflected in the navigation bar. Sections can have a title, subsections, and actions. However, they cannot contain controls.

Use title case for the section title (property titleUppercase = “false”). The title can have an item counter, which is displayed in parentheses. If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Global actions are always placed at subsection level. Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for global actions at the subsection level.

Subsections

Subsections are the containers for actual content. Always place individual controls inside the subsections. Subsection content is arranged according to the column layout approach for the respective screen size. A subsection can include containers for different controls (mixed content).

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can also display everything by selecting the Show All button at the bottom right of the subsection.

Each subsection can have a toolbar, which is placed at subsection header level on the right. The toolbar contains actions that affect the content of the subsection.

Subsections within the same section are separated by a gray horizontal line. Subsections can have an item counter, which is displayed in parentheses next to the subsection header.

You can include various types of related content in one subsection. The layout blocks for the object page give you the flexibility to combine different content types.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times, and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.
Object page – Blocks
Object page – Blocks

Contacts

The contacts on the object page are technically a list, but they can be represented visually as a card.

The cards can contain:

  • An image (optional)
  • A title (mandatory)
  • A subtitle (optional)
  • A text snippet consisting of two lines maximum (optional)

A single card covers the column’s entire horizontal space. To avoid alignment problems, all cards are the same height. The card with the most content defines the overall height for all cards. The image can be rectangular or round. It shows in the top left corner of the card. The content of the card never truncates. If there is not enough space to display the information, it wraps onto the next line.

Content type – Contacts
Content type – Contacts

Tables

In an object page, tables with up to 20 expected items can be displayed right away without lazy loading.

If a table is expected to have more than 20 items, use one of the following 3 options for long tables:

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial amount of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, this option should be used only for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. Here it is important to place the table within a tab as the only or at least the last element and to enable the scroll to load behavior.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, the table itself should be restricted to a reasonable amount of items. We recommend only showing a preview of the data in the table, which should not contain more than 20 items. Ideally, you should have about 10 items. This can be either be achieved by prefiltering and/or by sorting the table, and if necessary, by restricting it to a fixed amount of items (such as top 10). To provide the user with a way to work with the entire table, a navigation to a separate list report containing the full table must be offered.  This navigation should be located below the table in the form of a right-aligned link labelled Show All (x), with x representing the total amount of items in the table.

In the object page, we recommend that you do not use the analytical, grid and tree tables. Instead, use a responsive table and offer navigation to a list report with the table types mentioned above.

For all of the three options mentioned above, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Grouping should be avoided.

Table with navigation to a separate list report
Table with navigation to a separate list report

Child Page Representation

In object pages with drilldown navigation, child pages are represented in three ways:

  • Visual representation in the header: A narrow blue band is displayed in the left margin of the snapping header.
  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Item navigation arrows: Up and down arrows in the application toolbar allow the user to navigate between subitems without going back to the original list.

Behavior and Interaction

Edit

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create). In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area for edit mode to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see manage objects – create, edit, delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

Object page – Global edit with header container and independent header facets
Object page – Global edit with header container and independent header facets

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit on a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Object page – Partial edit with dialog
Object page – Partial edit with dialog

Create and Edit Subobjects

The following options are available for creating or editing subobjects:

  • Navigation to a subobject page
  • Inline create or inline edit in a table
  • Dialog containing the fields of the object

If the subobject has less than 8 fields, use a dialog or the inline create/edit option (no separate page for the subobject). Exceptions can apply if additional content for the subobject is available but not part of the edit process, or if other apps need to offer deep links to the subobject page.

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:
•Who made the changes
•When the last changes were made

The popover closes when the user clicks or taps the Close icon or anywhere outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, use the placeholder text “New ” (for example, “New Purchase Order”). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Guidelines

Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing a clear context.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.

Tab Navigation

Use tab navigation if you need a facet approach to your content. This could be due to performance issues in a flat view, or in response to a specific user preference.

Not a Content Dump

Avoid using the object page as a universal container for masses of information. You should use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.

Simplify Content for Your Users

Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request. Furthermore, only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


List Report Floorplan

Information
This article contains general guidelines for the list report floorplan. Note that some features may not be available if you are using the SAP Fiori elements implementation.

For the latest information on SAP Fiori elements, see the documentation and SAP Community wiki.

You can also refer to the list report floorplan article for guideline version 1.52, which includes the main features of the SAP Fiori elements implementation. However, please note that this page is no longer updated.

Intro

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items within a large set of items by searching, filtering, sorting, and grouping.
  • Users need to display the whole dataset using different visualizations (for example, as a table or as a chart), without requiring interactions between these visualizations. An example use case might be reporting.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. Views can be switched using tabs, segmented buttons, or a select control.
  • Drilldown is rarely or never used, or is only available via navigation to another page, and not as free or flexible drilldown within the page itself.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, and the item or an identifying data point is known to the user (such as a barcode). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the worklist floorplan instead.
  • Users need to extract knowledge or insights from data, either to better understand the current situation, or to identify the root cause for a certain value.  Use the analytical list page instead.
  • Charts are not only used for visualization. Users need to switch between integrated chart and table views (hybrid view). Use the analytical list page instead.
  • Users need to see the impact of their action on a KPI. Use the analytical list page instead.
  • Users need to see not only the result, but also the impact of their filter settings directly in a chart representation. Use the analytical list page instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions, such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a chart, you can display the chart on its own (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.
Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Header Title

Variant Management

Variant management is optional. If you use variants, apply them to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before the dataset is updated. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the format Filtered By (x): followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use the header toolbar for non-finalizing global actions, such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

Header Content

The header content collapses when the user scrolls down the page (with a responsive table, list, or tree only), and expands again when the user scrolls back up. To avoid this automatic expand / collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.
Users can also expand and collapse the header content by clicking the background of the title bar.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title.

When starting the application, expand the header content if no query was fired (and the table is therefore empty). Collapse the header content in other cases.

Header Content - Expand / Collapse Behavior

  • List Report (Floorplan + SAP Fiori Element) Header Collapsed - 1.54

Filter Bar

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search terms and the filter criteria.

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. Multiple views involve one or more of the following:

  • Showing the same table, but with different columns.
  • Showing the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

There are two options for switching between different views:

The first option is to replace the table title with a content switch. Use this approach if all views share the same sort and group states, as well as the same actions.

The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country, View by Customer, …)

The second option for switching views is to show each view in a tab container of the icon tab bar. Use this approach if all views show different states of the same data (sort states, group states, as well as item selection). Using tabs also allows you to offer different actions on the table toolbar for each view.

Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items are selected, or if the action cannot be applied to the selected items. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions
Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are no items to display, use the “no data” text of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    No filters set. To start, enter your search and filter settings and run the search.
  • The filter was executed, but no items were found. This can also happen if the list report was opened by a related app, and the filter criteria were transferred automatically:
    No items found. Check the search and filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is being used for a different target.
    Only show navigation indicators for target pages the user is authorized to access.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer toolbar
Footer toolbar

Actions

Places for actions in the list report
Places for actions in the list report

(1) Global actions in the header toolbar
(2) Table actions in the table toolbar
(3) Line item actions
(4) Finalizing actions in the footer toolbar

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no item is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

If qualifying items can be identified before the action is executed, show a message about how many of the selected items the action will be applied to. In other cases, show a corresponding message after the action was executed.

Hide actions that cannot be used at all (for example, because the user has no authorization). If you are using an icon tab bar, be aware that each tab contains its own table toolbar.

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or the line item is in the wrong state.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Initial Page Floorplan

The initial page floorplan allows the user to navigate to a single object to view or edit it. The interaction point on the screen is a single input field that relies on assisted input to direct the user to the object in as few steps as possible (using features such as value help and live search). If you need to display more than one object, use the list report floorplan instead.

Initial screen – Empty state
Initial screen – Empty state
Initial screen – Showing object
Initial screen – Showing object

Usage

Use the initial page floorplan if the user only needs to work on one object at a time. In this case, the list report floorplan would include a redundant step for viewing a list of items found by the search.

A typical use case for the initial page floorplan is a barcode scanning app, where each new scan leads to an object with input fields. Once the user has submitted the entries, the screen is shown in read-only mode. The cursor returns to the input field, ready for the user to scan the next object.

Do not use the initial screen floorplan if the search is supposed to return a list of objects. This is the scenario for the list report floorplan.

It is also advisable to use only one input field for finding the object. If you need to include detail views, or allow the user to switch between views, offer these features when displaying the object itself.

Structure

Using the Object Page and Dynamic Header (Recommended)

As of SAPUI5 release 1.54, you can implement the initial page layout using the object page with the dynamic header (recommended).

Header

The header contains the same header content as in the object page, such as the header action toolbar and the actions to expand, collapse, and pin the header. The title of the header has been replaced by an input (search) field. If value help is offered, it is shown in a dialog control.

Content

The content area will look like the content area of the object page. It can contain sections, subsections, forms, tables, and cards (see object page).

New design of initial page using the object page layout and dynamic header
New design of initial page using the object page layout and dynamic header

Using the Full Screen Layout

The initial page layout is based on the full screen layout, and uses the same structure. The launchpad shell bar is always available at the top of SAP Fiori apps. The app title (application header) reflects the title of the launch tile, such as “Manage Products”. However, instead of showing an object header or filter bar in the header section, the initial page displays only an input field. If value help is offered, it is shown in a dialog control. The content area is used to display the object. The object should be displayed following one of the floorplans outlined in the guidelines.

Structure of the initial screen
Structure of the initial screen

Responsiveness

The initial page features a single interaction point for the user: the input field near the top of the screen. Place the input field inside the header section. Configure the width to fit the width of the longest text (allowing some additional space for other languages), but do not make it significantly wider.  When you set the maximum width of the input field, also consider the width available on mobile devices.

The field should never be as wide as the screen (except for on smartphone screens).

Initial page floorplan in size S
Initial page floorplan in size S
Initial page floorplan in size M
Initial page floorplan in size M
Initial page floorplan in size XL
Initial page floorplan in size XL

Flows and Interaction

Initial Screen with Live Search

The input field serves as the single starting point for finding the object. The assisted input uses the live search feature (search-as-you-type) to speed up the search. The live search feature can show anything from one attribute to an entire table of values. It is possible to show a message such as “Enter ID manually or scan barcode” using the message page to guide the user.

Live Search

Initial Screen with Value Help Dialog

If multiple hits are possible for the same search terms, you may need to implement a value help dialog. This dialog lets the user narrow down the list of items based on more specific criteria. When the user selects an object from the list, the dialog closes and the object is displayed in the content area (no additional navigation is required).

Value Help Dialog

Behavior of the Search Field

The input field is located in the header area of the page, but moves down the page when the user scrolls down. The field does not appear when a subpage is opened.

Once the page has loaded, the search field should be on focus if no other additional action is provided. This allows the user to enter the search term directly without clicking into the field. You should only consider using this if there are no other elements that could be blocked by it, such as the on-screen keyboard on touch devices.

Behavior of the search field
Behavior of the search field

If the user enters new search terms in the input field, the focus moves away from the field and the app triggers a new search. If no results are found, the user sees a blank page with a corresponding message. If the input field is left blank, no message is shown.

If the search term is deleted and focus moves away from the input field (or Enter is clicked), the screen becomes blank again
If the search term is deleted and focus moves away from the input field (or Enter is clicked), the screen becomes blank again
If a search is executed but no documents are found, the screen becomes blank again and an orange warning appears around the input field
If a search is executed but no documents are found, the screen becomes blank again and an orange warning appears around the input field

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object Page – Snapping Header

The snapping header is the uppermost element of the object page layout. It summarizes selected data and actions in a visually prioritized position to let the user quickly grasp the most relevant information.

This snapping header control is only available for the object page floorplan.

Information
The dynamic page also has a “snapping header” feature (called dynamic page header) and looks quite similar. However, this is part of the dynamic page control, and is technically not the same as the snapping header for the object page.

Usage

Use the snapping header if:

  • You are using the SAP Fiori element for the object page floorplan.
  • You are creating an object page manually based on the object page floorplan.

Do not use the snapping header if:

  • You are using any other floorplan.

Responsiveness

The snapping header is designed to provide maximum flexibility. It adapts automatically to small, medium, and large screen sizes.

The header title and subtitle never truncate. If necessary, the text wraps to the next line.

The toolbar follows the standard toolbar overflow guidelines by adding the available buttons to the overflow menu from right to left.

Object Header Content Priority

Each facet in the header content area has a priority assigned to it. Content prioritization aims to support responsive behavior. Priorities allow less important content to be omitted from rendering, depending on the screen space available. The user can always access omitted content on request.

Three priority types are available: high, medium, and low. According to the screen size, the facets are distributed as follows:

  • Size L/XL: The facets with high, medium, and low priority are displayed.
  • Size M: The facets with high and medium priority are displayed.
  • Size S: Only the facets with high priority are shown.
Snapping header – Responsiveness – Size L/XL
Snapping header – Responsiveness – Size L/XL
Snapping header – Responsiveness – Size M
Snapping header – Responsiveness – Size M
Snapping header – Responsiveness – Size S
Snapping header – Responsiveness – Size S
Snapping header content priority for sizes S, M, and L
Snapping header content priority for sizes S, M, and L

Components

The snapping header comprises two main control elements:

  • Mandatory: Title bar (sap.uxap.ObjectPageHeader)
  • Optional: Header content (sap.uxap.ObjectPageHeaderContent)

There are different states for the snapping header. You can find further information within Behavior and Interaction.

Title Bar

The title bar comprises the following elements:

  • Header title (mandatory): The title is always visible.
  • Header subtitle (optional)
  • Title bar image (optional): The image has a shape parameter (square or with a round mask) and a placeholder parameter. The placeholder is displayed if no specific image is available.
  • Toolbar: The toolbar contains the global actions for the floorplan. The actions should be represented only with buttons, text, or an icon. They can be transparent, regular, highlighted, or semantic. All buttons go from right to left into the overflow. Buttons should be arranged according to the current use case and always in a consistent visual order (see guidelines for examples). If there are no global actions, the toolbar is not shown. Note that the object page uses the sap.m.Toolbar control instead of sap.m.OverflowToolbar.
  • Child page visualization: Each object page can have drilldown navigation. The child object page can only be reached through the parent object page. A narrow vertical stripe at the left side of the snapping header helps to differentiate the child object page from the parent object page.

The title bar can also contain the following optional indicators:

  • Favorite (property: markFavorite)
  • Flagged (property: markFlagged)
  • Locked (propertly: markLocked)
  • Selector (property: showTitleSelector)
  • Unsaved Changes (property: markChanges)

The title bar control also supports breadcrumb navigation. For more information scroll to section Line Item Navigation.

Snapping header – Structure
Snapping header – Structure

Header Content

The header content is optional and located below the title bar.

You can use the header content (sap.uxap.ObjectPageHeaderContent) to display app-specific contextual information. You build the content using smaller content containers, called facets. Each facet contains a distinct information set, as described below. If there aren’t any facets, the header content is always hidden.

The facets are arranged in line with a left float. Each facet adapts its size to the content and makes optimal use of the space without truncating the texts. If the facets do not all fit on one line, those on the right wrap to the line below.

If the snapping header collapses, the header content is hidden. If the header content is empty, you can also hide it.

Header container – Floating content
Header container – Floating content

Header Facets

There are several types of header facets, depending on the data that they display. The facets need to be handmade for stand-alone object pages.

Form Facet (Dataset)

The form facet can be used to display datasets in the snapping header. It consists of a headline and up to five label-text pairs.

  • The headline is optional
  • Contains at least one but maximum five label-text pairs
  • The labels can be invisible, but need to have a text for accessibility reasons
  • The labels can be icons, but need to have a text for accessibility reasons
  • Each text of a label-text pair can have a press event

Examples for the usage of form facets are document information such as creator and creation time, an address or contact information, and general information.

Developer Hint
For non-SAP Fiori element object pages only:

For each label value pair in the form header facet, a sap.m.Label and a sap.m.Text or sap.m.Link should be used and nested within an sap.m.HBox.

Header Facet - Form facets
Header Facet - Form facets

Plain Text Facet

The plain text facet can be used to display a continuous text in the snapping header. It consists of a headline and a continuous text.

  • The width of the facet does not depend on its content, but can be set. The default width of the facet is 300px.
  • The headline is optional.
  • If the headline is broader than the facet width, the headline will wrap.
  • Press events are only available inline in the continuous text. These can be links that navigate to another page or open a quick view. There can be more than one link in the continuous text with different actions.
Developer Hint
For non-SAP Fiori element object pages only:

To set the width of the plain text facet, nest the text within an sap.m.HBox and set the property:width of the sap.m.HBox.

Header facet - Plain text facet with default width
Header facet - Plain text facet with default width
Header Facet - Plain text facet with custom width
Header Facet - Plain text facet with custom width

Image Facet

The image facet can hold exactly one image. The snapping header can only hold one or no image facet.

  • The image can be either square or circular.
  • The image can also hold an icon.
  • The image can also hold initials consisting of two letters.
  • The image can have a press event. The default press event is the enlargement of the image.

When the header collapses, the image facet will move to the right of the title and become smaller.

Recommended usage of the different properties:

  • Images of people, especially portraits, should be round. If there’s no image available for a person, initials (first letters from first and last name) should be used instead.
  • All other images should be square. If there is no image available for an object, an appropriate icon should be shown instead.

In all cases it should be clear how the images will be managed and uploaded. This can either be via the edit mode of the object page or, especially when there are a lot of images, via an external tool.

Header facet – Image facet specification
Header facet – Image facet specification

Key Value Facet

The key value facet holds a label in a smaller font size and a text or number in a bigger font size. It can be used to highlight important data or KPIs of the object.

If the key value facet is used with a text such as a status, it can also have an icon on the right side next to the text. This icon has to belong to the text and should only visually support but not expand it.

Developer Hint
For non-SAP Fiori element object pages only:

Larger value texts are currently only available in SAP Fiori elements. For non-SAP Fiori element apps, the value texts have the same size as the label, as custom CSS should not be used.

Header Facet – Key value facets with KPIs and a status
Header Facet – Key value facets with KPIs and a status

Micro Chart Facet

The micro chart facet consists of a headline, a subtitle, a micro chart and a footer.

The headline and the micro chart are mandatory while the subtitle and the footer are optional. To display the unit used in the micro chart, the footer should be used.

The following micro charts can be used in the micro chart facet:

  • Bullet Chart
  • Column Chart
  • Trend Chart
  • Comparison Chart
  • Delta Chart
  • Harvey Ball Chart
  • Radial Chart

The micro chart facet can have a click or tap event on the chart itself. This could for example lead to a page with a bigger chart or open a quickview.

For more information see micro charts.

Header facet – Micro Chart Facets
Header facet – Micro Chart Facets

Progress Indicator Facet

The progress indicator facet consists of a mandatory headline and a progress indicator (sap.m.progressIndicator). Further it can have two optional supplementary texts: a subtitle and a footer.

Header Facet - Progress indicator facet
Header Facet - Progress indicator facet

 Rating Indicator Facet

The rating indicator facet consists of a headline, a rating indicator, and one or two supplementary texts, which are dependent on the use case as described below.

The rating indicator can be modified as described in the rating indicator article.

We recommend the following properties for the rating indicator used in the header facets:

  • We recommend using 5 symbols as the default.
  • We recommend using the Favorite icon as symbols.
  • We recommend using the option to also display half-stars to represent decimal values.

 

The rating indicator facet can be used for two different use cases, which are described below.

  1. Aggregated rating:

    When displaying an aggregated rating, which could be for example the average of several user reviews for a product, the facet can have a mandatory header, an optional subtitle, the rating indicator itself, and a footer.

    The subtitle should display the amount of data that the aggregation is based on. For example, in the case of an average rating, the subtitle would display the number of ratings.

    The footer should display the exact value of the aggregation in the format “2.2 out of 5”, where “2.2” indicates the exact value of the aggregation and “5” indicates the maximum value of the rating.

  2. Single value rating:

When displaying the rating as a single value, the facet can have a mandatory header, an optional subtitle and the rating indicator itself. Here the subtitle can be used as supplementary text and a footer should not be used.

Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with singe value rating
Header facet - Rating indicator facet with singe value rating

Behavior and Interaction

The snapping header has different types of behavior that can be combined:

  • Snapping
  • Title bar only
  • Header content always shown
  • Child page visualization
  • Line item navigation
  • Edit

By default, the snapping is enabled and title bar and header content are shown (expanded).

Snapping

The snapping header is always expanded for all display sizes when the user opens the object page.

When the user scrolls down the page, the header content snaps closed (collapses), leaving only the title bar. This allows the user to see more of the object page content.

You can specify which information is shown in the title bar in the expanded and collapsed states. In the example shown here, the snapping header has been configured to show only the image in the title bar when the header content area is collapsed.

Snapping header – Expanded
Snapping header – Expanded
Snapping header – Collapsed
Snapping header – Collapsed

Title Bar Only

If there is no need for the header content, the title bar-only mode can be used. This means that there is no header content shown at all, but only the title bar. This also means that there is no snapping behavior as the title bar is always shown.

Header Content Always Shown

The snapping header can stay expanded while the user scrolls down the page if the property alwaysShowContentHeader is set to true for the object page layout (sap.uxap.ObjectPageLayout). This behavior is available only for desktops.

Child Page Visualization

Each object page can have drilldown navigation. The child object page can only be reached through the parent object page. A narrow vertical stripe at the left side of the snapping header helps to differentiate the child object page from the parent object page. To navigate between the child object pages of one parent object page, arrows are displayed within the header bar of the page. To easily navigate back to the object page, breadcrumbs are used. To enable the child page visualization use property:isChildPage of sap.uxap.ObjectPageLayout.

Snapping header - Child page visualization
Snapping header - Child page visualization

Line Item Navigation

The snapping header for the object page can contain a breadcrumb that shows the navigation path for the current item. This feature was developed specifically for line item navigation within the object page.

The breadcrumb is located above the title in the title bar. The interaction is typical of a breadcrumb navigation pattern: all links in the breadcrumb chain point to a URL and are triggered by a press event.

If there is not enough space to show the full breadcrumb, it defaults to a dropdown control. In this case, the breadcrumb shows only the immediate parent of the current item. The   symbol indicates that further information is available in a dropdown list.

The dropdown list reveals all the links in the breadcrumb chain. The user reads the breadcrumb from bottom to top: the root object is at the bottom of the list, the immediate parent is at the top, and the current item is selected.

Snapping Header - Breadcrumbs
Snapping Header - Breadcrumbs

Edit

There are two different ways to edit the header information:

  • Global edit
  • Partial edit

Please note: the grand majority of object pages do not have editable header content. Therefore, the object header should not be editable by default.

Global Edit

A button in the header toolbar triggers the edit mode. For more information on global edit, see object page.

The visible facets can differ in create, edit, and display mode. If there aren’t any facets in one mode, the header content is not displayed. Choose which information supports the user best in his or her current task.

The mental model behind this possibility assumes that there are a number of header facets assigned to one given application. You can define which facets are shown in which mode.

Once the edit mode is activated, the header content is moved to a section in the content area of the object page. This section is assigned the anchor label Header. This is the first section in the document. All other sections are displayed in the order in which they had been displayed in display mode. If they’re editable, the object page title, subtitle, and image appear in the header content section. They also remain visible in the header title bar. If these are changed, they will update only as a preview.

If the image is changed in edit mode, the image in the header title bar should update only as a preview. The user will have to save the document to actually enable the changes.

Exemplary scenarios when switching from display to edit mode:

  • When all of the header elements are editable
    All of the header elements are displayed as editable forms in the Header section. The header content hides as no facets are displayed.
  • When independent header facets are present in edit mode

    All of the header elements are displayed as editable forms in the Header section. A new facet that is related to the data the user is editing is displayed in the object page header content area. This header facet is not present in display mode.
  • When only some of the header elements are editable
    All of the header elements are displayed in the Header section, but the content that is not editable is displayed as read-only to keep the layout consistent.

Partial Edit

Partial edit is used when the object page consists of large datasets and the user wants to be able to edit only the object header. Edit mode is triggered by a button that is located on the bottom right of the snapping header.

When there are only a few elements to be edited, the Edit Header button opens a dialog. When there are more editable elements, the button triggers a subpage. This subpage contains all editable data from the header without the toolbar, the navigation, and the breadcrumbs.

Style

The snapping header is available with both flavours of the Belize theme:

  • Belize (light flavor)
  • Belize Deep (dark flavor)
Snapping header – Belize
Snapping header – Belize
Snapping header – Belize Deep
Snapping header – Belize Deep

Guidelines

Breadcrumbs
Use breadcrumb navigation only on the object page, and only where there is a hierarchical drilldown within the object (line item navigation). For other types of navigation, see the SAP Fiori navigation patterns.

Header Toolbar
Do not use input fields, selects, checkboxes, search fields, or similar controls in the header toolbar. Use buttons only.

Header Content Area
Place only meaningful information in the header content containers. The content should help the user in the object context, or provide useful reference information.

Keep the header as clean and uncluttered as possible to allow users to take in the content at a glance. If there is too much information in the header, consider placing an overview section in the content area of the object page floorplan.

Themes

Until theme parameters are available for the snapping header, we recommend using the light flavor. This will avoid any contrast issues that might arise with the dark theme in the current implementation.

Images
When images are used in the object page header, you should consider the following needs:

  • How will the user manage the images?
  • How will the system block people without permission for image editing?
  • How will these images be reflected in other floorplans if they are part of the object?
  • If there are a large number of items, how would a company be able to manage images without having to navigate from page to page?
  • Will the company be able to manage the images?
Developer Hint
How to achieve a small header:

  • The header container is always optional. If there is no important data to be displayed, you can omit it. In this case, only the header title bar will be shown.
  • Omit the image if it is not necessary. It is generally the tallest element in a header container.
  • Use a light theme to reduce the emphasis in the header if there is not much information on it.
  • You can always place the information from the header into a general information section.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Overview Page – Stack Card | Quick View Card

Take Action on the Overview Page 

As well as giving users access to content from multiple applications using different visualizations, the overview page can also let users take immediate action. This is supported by a special interaction pattern with a set of closely-integrated card types: the stack card, object stream, and quick view card. These three card types are only ever used together, and navigation between them has been optimized to best support user needs.

A stack card is a collection of quick view cards, which provide a footer area with actions. These quick view cards are displayed in the object stream (overlay). The advantage of using stack cards is that users don’t have to leave the overview page, and therefore don’t lost their focus.

Overview page – Navigation overview of stack card, object stream, and and quick view card
Overview page – Navigation overview of stack card, object stream, and and quick view card

Explanation:

  1. Stack card (left side): Opens the parent application (such as a list report with all approvals).
  2. Stack card (right side): Opens the object stream.
  3. Heading of the object stream: A link that navigates to the parent application (such as a list report with all approvals).
  4. Single quick view cards within the object stream: Offer navigation to the object details (such as an object page with the selected approval), as well as actions.
  5. Placeholder card: The last card a one-click area and navigates directly to the parent application (such as a list report with all approvals).

Stack Card

A stack card is a special collection of single-object quick view cards, based on a topic or action. Unlike the other card types, the top-level stack cards don’t show any application content. Instead, they act as an entry point to an object stream containing multiple cards.

Stack cards have the following components:

  • The title is the top element and is always required. It is used as the heading for the detail view, and comprises 1-2 lines of text.
  • The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The purpose of the subtitle is explain the content of the stack in one line, so its usage depends on the context.
  • The stack content count indicates the number of cards in the stack (object stream). The object stream can contain up to 20 cards. Below the number of cards in the stack, you see the total number of items returned for the annotated view (for example, “20 of 42”).

The top-level stack card contains two clickable navigation areas:

  • The left area and View All link navigate to the parent application, where the user can see all the objects returned for the annotated view (42 in the example above). The placeholder card and heading inside the object stream have the same navigation target.
  • The right area opens the object stream, which contains a scrollable collection of cards presented in an overlay format. The user can browse individual cards, with the option to view, inspect, or take action.

Overview Page – Stack Card Components

  • Overview page - stack card
  • Stack card components
  • Stack card interaction

Object Stream

Overview page – Object stream
Overview page – Object stream

Clicking the right-hand area of the stack card opens the object stream. The object stream appears on top of the overview page as a modeless overlay, and serves as a layer for showing quick view cards with actions. The overlay has heading on the top left, and a Close button on the right. The heading is the same as the stack card title, and links to the full result set in the parent application (same target as the left-side navigation on the stack card and the navigation from the placeholder card). Clicking outside the overlay area also closes the object stream.

The object stream can have up to 20 cards (maximum), which all get their content from the same parent application. By default, the cards are ordered chronologically, with the most recent items first. However, app developers can define the best object stream sorting option for their own needs and content. If the number of cards exceeds the available space in the overlay window, an arrow icon appears on the right for scrolling. Mobile device users can swipe to see more cards. If the object stream is empty, the stack link is not active and the overlay cannot be opened. The stack count number displays 0. If only one item is returned, the object stream contains just a single card.

The header area of the quick view cards in the object stream navigates to the detail view for that specific object in the parent application. The footer area of the quick view cards can also offer actions.

Object Stream – Scroll Arrows

Scroll arrows only appear on desktop devices. If all the cards in the object stream fit on the screen, the arrows are not visible. If the number of cards exceeds the available space, an arrow icon appears on the right when the user mouses over the object stream overlay. Mousing over the arrow button area scrolls the cards across the screen from right to left. As soon as the first card on the left moves out of the visible overlay area, a second arrow appears on the left for moving in the other direction. Once the last card is in full view, the arrow on the right disappears.

Placeholder Card

If the number of items returned for the annotated view exceeds the maximum 20 cards allowed in the object stream, a placeholder card is added automatically at the end of the stream (as card 21). The entire placeholder card is navigable, and takes the user to the full result set in the parent application.

The text on the placeholder card is composed as follows:

See all [total] [items] in the“[app name]” app.

Where:

  • The values for [total] and [app name] are supplied by the system.
  • The term for [items] must be rephrased by the app team to reflect the type of item or business object. For more information, see Mandatory Adjustments.

Examples:

  • See all 42 items awaiting approval in the “Approve Leave Requests” app.
  • See all 42 purchase orders awaiting approval in the “Approve Purchase Orders” app.
Overview page – Placeholder card
Overview page – Placeholder card

Object Stream – Tablet Version

On tablet devices, the modeless overlay expands horizontally. It also expands vertically to accommodate the card height and allow space for the title and Close button. The user can swipe through cards and perform micro actions. Swiping a card into view moves the entire object stream. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

Object Stream – Phone Version

On smartphones, the overview page layout collapses to a single column in both portrait and landscape modes. Tapping the right-hand navigation area of a stack card opens the object stream on top of the overview page in a new full screen window.

The object stream expands horizontally and vertically to accommodate the card height, and to allow space for the title and Close button. The user can swipe through the cards and perform micro actions. Swiping a card moves the entire object stream. Since the cards are too large to fit on the screen in landscape mode, users can also scroll vertically to see the full card content. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

Object Stream on Mobile Devices

  • Overview page – Object stream interaction size M (landscape)
  • Overview page – Object stream interaction size M (portrait)
  • Overview page – Object stream interaction size S (lportrait)
  • Overview page – Object stream interaction size S (landscape)

Quick View Card

Quick view cards are single-object cards. They display the basic details for one object, such as the name, address, and phone numbers for a contact. This card type is only available within the object stream; you can’t place quick view cards on the overview page itself. The quick view card inherits the SAPUI5 element sap.m.QuickView.

The header area contains a static text, such as Purchase Order, and an optional dynamic text, such as 1005-3345. In this way, each card header can show different content. Clicking on the header area of the card opens the detailed view of the object in the corresponding parent app. If the content area of a card cannot display all the information, a scrollbar appears on the right. Only the footer area of the quick view card can provide actions. The footer bar is a specific feature of the card anatomy for quick view cards.

Card anatomy of the quick view card
Card anatomy of the quick view card
Quick view card for a contact
Quick view card for a contact
Quick view card for a product
Quick view card for a product
Quick view card for a purchase order
Quick view card for a purchase order

Actions on Cards

Only quick view cards within an object stream can have actions in the footer area. The overflow toolbar manages how the actions are displayed. All actions are right-aligned. Any actions that don’t fit into the available space move into the overflow action sheet, represented by the ellipsis ( ). A maximum of six actions are allowed in the footer area. Only offer actions the user really needs in the specific context.

Footer area with additional actions in the overflow
Footer area with additional actions in the overflow

There are two possible types of action: navigation and function import. Any combination of navigation and function import actions is allowed. Error or confirmation messages are displayed directly on the overview page. Always overwrite the predefined default text for errors in a message box: Formulate your message in plain language (without code), describe the issue precisely, and suggest a constructive solution.

Type: Navigation

Navigation is “intent-based” and takes the user to a different SAP Fiori app that specializes in executing an action. Navigation actions are always multi-click (meaning they can be repeated over and over). The destination screen opens in the same browser window, and any error or task confirmation messages are handled by the supporting application, not the overview page.

Type: Function Import

Function imports are custom OData service operations for actions. These actions are handled by the overview page, rather than by another SAP Fiori app. The interaction depends on whether or not the action requires user input:

  • If the action requires additional user input, the input parameters are handled directly on the overview screen without further navigation. A dialog appears on top of the card, allowing the user to enter data or make a selection. An example of additional input might be the rejection reason for a “Reject” action.
  • If the action has no input parameters, the action request is sent immediately. Once the action has been completed, the card disappears from the object stream.

Action on Phone

If an action on a card requires an input dialog box, use a full screen dialog on smartphones.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links
 

Overview Page – Fixed Card Layout

Self-Contained Cards

The fixed card layout is a layout for the overview page. It comes with predefined card characteristics that support automatic, easy and fast card design. The cards have a fixed width, and the height is determined by the card type and the embedded control.

The cards are ordered in responsive and collapsible columns. The number of columns is also fixed to keep the focus on the middle of the screen and show the set of cards in a compact display (a kind of letterboxing). For more information, see Responsiveness.

Before you start designing cards for an overview page, see the best practices.

At a Glance

  • Easy and fast card design due to predefinitions

  • Fixed card width and pre-defined height

  • Arbitrary card order

Overview page – Fixed card layout
Overview page – Fixed card layout

Fixed Card Sizes

Grid

The grid is based on rows and columns. The spacing of 1 rem between the cards is always stable. Furthermore, there is a minimum width of 20 rem per card (corresponding to the column width). The columns with the cards adapt to the available screen real estate (also see Responsiveness).

Based on the underlying grid, users can rearrange the cards (see Rearranging Cards – Behavior).

Fixed card layout – Grid
Fixed card layout – Grid

The cards are arranged as a “Z” flow: cards are ordered from left to right, starting with the first card on the top left of the page. For example, if a 5-column layout is reduced to 4-column layout, the fifth card drops to the next row, assuming the leftmost position underneath the first card.

There is no limit on the number of cards included. However, be careful not to overwhelm your users.

For general information on cards, see Cards.

Fixed card layout – Z flow
Fixed card layout – Z flow

Card Sizes per Type

The card size is determined by the predefined card characteristics and maximum content for a given card type. As a result, the card types differ in height. The stack card and corresponding quick view card are handled independently.

List Card

The height of list cards can vary, depending on the number of text fields. Show no more than five standard list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Standard list item
Standard list item
Extended list item
Extended list item

Bar Chart List Card

The height of  bar chart list cards can vary, depending on the number of text fields. Show no more than five standard/condensed list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Standard list item
Standard list item
Condensed list item
Condensed list item
Extended list item
Extended list item

Link List Card (Variant Type “List”)

The link list card with the variant type “list”  is limited to a maximum of six links. There is no limit to the number of links for the variant type “image”.

Table Card

The height of table cards can vary, depending on the number of table cells. Tables are limited to a maximum of 3 columns and 3 rows, with a maximum of 3 lines of text per row. To see the full result set, the user needs to navigate to the parent app.

Rearranging Cards – Behavior

Drag and Drop

Users can reposition cards on the overview page by dragging them to a different location. As the user drags a card, it swaps places with any cards in its path. As soon as a neighbouring card is touched, the position of that card becomes the new target location for the card being dragged. A dashed line offers a preview of the new position.

To drag a card, the user has to long press on a card instead of just clicking. It doesn’t matter where the cursor is positioned – cards can be dragged from both the header and content areas. The mouse cursor also changes to indicate that the card can be dragged. Releasing the mouse or lifting the finger from the touch surface completes the move. To avoid gaps, cards always snap to the next free space in the row, or to the start of the next row.

In addition, users can personalize their own overview page by hiding cards.

Fixed card layout – Drag and drop
Fixed card layout – Drag and drop

Getting Started

In the fixed card layout, you can’t influence the amount of information on each card. However, you can define the card order. Before you design your overview page, take a look at the best practices, which outline how to best use cards for an optimal user experience.

Responsiveness

The fixed card layout uses padding on both sides. The cards are displayed inside collapsible columns, making the page fully responsive. When the user resizes the browser or uses a smaller screen, the columns containing the cards collapse. To view all the cards, the user just scrolls down. In this way, the layout can accommodate typical laptop screens, larger desktop monitors, and mobile devices.

The width of the cards is tied to the column width. Breakpoints for the different screen resolutions determine whether the column width is 20 or 25 rem. The cards inside the columns adapt their width and content automatically. By contrast, the height of the cards is flexible, and depends on the content and type of card (see Card Sizes per Type).

  • Phone: 1 column
  • Tablet (portrait): 2 columns
  • Laptop / tablet (landscape): 3 columns
  • Large desktop: 4 columns
  • Extended monitor: 5 columns (maximum)
Fixed card layout – Size L
Fixed card layout – Size L
Fixed card layout – Size M
Fixed card layout – Size M
Fixed card layout – Size S
Fixed card layout – Size S

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Overview Page – Resizable Card Layout

Unlimited Possibilities for Designing Cards 

The resizable card layout is a layout for the overview page. It enables users to define a personalized card layout by changing not only the position of a card, but also its size, and thus how the card content is presented.

This layout gives users much greater flexibility in tailoring the overview page to their specific business needs. And it allows app teams to offer varying levels of detail for any given card. Whenever the size of a card changes, the content adapts automatically to show the most relevant information in the available space.

At a Glance

  • Flexible card dimensions (grid-based)
  • More flexibility to define individual card layouts
  • Responsive and adaptive card content
  • Applying progressive disclosure principles
Overview page - Resizable card layout
Overview page - Resizable card layout

Unlike the fixed card layout, cards in the resizable card layout do not have fixed dimensions. In addition, the number of columns in the resizable layout is no longer limited (also see letterboxing).

The cards are positioned on an underlying grid, making it possible to arrange and resize cards in a flexible, yet guided manner. You can offer different views of the card content for different dimensions of the various card types. For example, you can show more items, zoom in or out, or change the granularity of a dataset.

The resizable card layout does not replace the fixed card layout.

Usage

Use the resizable card layout if:

  • You want to give users the flexibility to rearrange and adapt their overview page as they need.
  • You want to help users focus by applying progressive disclosure principles.
  • You want to make use of different card sizes.
  • You want to show more content (for example, more items or an additional level of detail)

Do not use the resizable card layout if:

  • Your card content doesn’t react properly to a change in size. Use the fixed card layout instead.
  • You are not able to invest UX and development resources for creating and prioritizing additional content. Use the fixed card layout instead.
  • You want to use the resizing functionality on mobile devices. Resizing and rearranging cards is currently not possible on mobile devices.

Flexible Card Sizes

Grid

Cards can be increased and decreased vertically in rows of 1 rem and horizontally in steps of 20 rem (minimum width). These dimensions facilitate both a high degree of flexibility and measured guidance. The card content responds immediately to a change in size.

The grid provides a guided resizing and repositioning experience. This ensures that the cards are always correctly aligned on the overview page as the user moves or resizes them.

Resizable card layout – Grid
Resizable card layout – Grid

Card Anatomy

A card is made up of a mandatory header and a content area.

Mini Header

The smallest representation of the card is the header. The card can be collapsed to only its header height. We call this the “mini header” card height.

Mini Content

The “mini content” height of a card is defined by the next suitable size for a card when it is resized. The minimum height for the card content depends on the card type, and must be as high as the smallest representation of the content. In a list card, for example, first list item needs to fit in.

To avoid states with cut or unsubstantial content, there are no resizing steps between mini header and mini content.

Card anatomy
Card anatomy
Minimum heights for a card in the resizable card layout
Minimum heights for a card in the resizable card layout

Examples of Card Sizes

Dealing with White Space

If no additional content is available, the user still can make the card bigger, resulting in white space.

Resizing Parameters

The card content depends on the available space, which in turn determines how many items are shown, how each item is displayed, and the level of detail (granularity). How the content is resized depends on the type of card. For example, table cards can have fewer columns when the size of the card is decreased. By contrast, the content shown for each item on list cards remains the same.

Space

When a card is resized, the content adapts responsively. 

Example: List card
When the size of a card is reduced, texts might be truncated or wrapped. When the card size is increased again, the text is shown in full and previously wrapped text moves back onto one line. The line item content itself is unchanged.

Resizing for a list card
Resizing for a list card

Items

When you increase the size of a list or table card, more line items are shown.

Resizing for a table card
Resizing for a table card

Granularity

If you increase the size of an analytical card, more data points are revealed. In this example, the donut chart on the larger card shows more individual product categories.

Resizing for an analytical card (donut chart)
Resizing for an analytical card (donut chart)

Rearranging Cards – Behavior

When a user long presses on a card instead of just clicking, the mouse cursor changes to indicate that the card can be dragged. Cards can be dragged from both the header and content areas. 

Cards always strive towards the top of the page (uplift mode). When you move or stretch cards horizontally, the existing cards you displace are pushed downwards.

Resizing cards / rearranging cards using drag and drop
Resizing cards / rearranging cards using drag and drop

Getting Started

UX and DEV Investment Required

To enable users to benefit fully from the resizable card functionality, you need to define additional content that is revealed progressively as the card size grows. You will need to develop a content strategy to prioritize the chunks of information for each card type, and hence the order in which these additional chunks of information appear. For instance, the content strategy for a table card should answer the following questions:

  • What should be the initial size of the card in the layout?
  • Which table columns do you want to show in the card with the minimum width?
  • Which table columns do you want to add when the card width is increased by one, two, three, … horizontal steps?

Keep in mind that the overview page is an SAP Fiori element.

Developer Hint
If you want to enable the resizable card layout for an existing overview page with the fixed card layout, consider the investment you’ll need to make in additional and meaningful content.

Set Initial Card Sizes

Set an initial order and initial dimensions for each card as a default. Do this for the mini header, the mini content, and for bigger card sizes. In cards with content, define the exact number of items included in the content area.

Consider the best practices for designing an overview page and the principles for resizing the cards. It’s important to provide a meaningful starting point for users. If users change the card size or order, the initial app default can always be restored using the Manage Cards setting in the user menu.

Important: Do not provide only mini headers in the initial layout for your overview page.

Block Card Resizing

App teams can block the resize feature for each card individually. In this case, the cards can’t be resized by users and the resize icon is not shown on the card. Use this feature judiciously and only if you really have to. The majority of cards should be resizable. Otherwise, users are likely to be confused, and might feel driven to check the resizing behavior for each card.

Alternative approach

If you want to make use of the different card sizes, but don’t want to allow resizing for users at all, you can block the resizing function for all cards (independently of the initial card size). This allows you to use different card sizes and the same (limited) personalization features as in the fixed card layout. Because none of the cards are resizable, users won’t be confused.

Letterboxing

The resizable card layout uses different letterboxing behavior than the fixed card layout: to handle different card sizes more flexibly, the resizable card layout does not have a fixed number of columns. Cards take up the the available screen real estate and adapt accordingly (also see responsiveness). As a result, larger screens can be almost completely filled.

Responsiveness

Information
Resizing is not supported on mobile devices. However, users can resize cards freely in smaller windows on a desktop device.

UI controls inside the cards react responsively when cards are resized. On mouse-release, additional content might be loaded, or content might be removed to reflect the new dimensions.

The number of grid columns in the layout is dependent on the width of the browser window. The breakpoints are defined as follows:

Width of Browser Window Number of Card Columns Displayed
Less than 656 px 1 column
656 – 975 px 2 columns
976 – 1359 px 3 columns
1360 – 1679 px 4 columns
1680 – 1999 px 5 columns
More than 2000 px 6 columns or more

There is no limitation to the number of columns. You can also design for bigger screens.

Resizable card layout – Size L
Resizable card layout – Size L
Resizable card layout – Size M
Resizable card layout – Size M
Resizable card layout – Size S
Resizable card layout – Size S

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Worklist Floorplan

A worklist displays a collection of items that a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan is on processing the items. This differs from the list report floorplan, which focuses on finding and acting on relevant items from a large dataset.

The worklist floorplan can be implemented in two ways:

  • Using the corresponding SAPUI5 controls in a dynamic page layout. This gives you much greater flexibility, but also costs more development time.
  • Using the SAP Fiori element for the worklist. This generates the floorplan from OData annotations, which brings down development time. However, the SAP Fiori element worklist is restricted to the most common features. Details on the SAP Fiori element for the worklist are included at the end of each section.
Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Users need to work with multiple views of the same content (for example, items that are “Open”, “In Process”, or “Completed”. Users can switch between views using the tab bar.

Do not use the worklist floorplan if:

  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (charts or tables). In this case, use the list report floorplan instead.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping. Use the list report floorplan instead.

Layout

The worklist floorplan is based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, KPI information (if relevant), and a header toolbar with global actions, such as Share.
  • The content area: Use this to display:
    • An icon tab bar in the content area
    • One table (per tab)
    • You can use any kind of table and list. To ensure that the application runs on all devices, we recommend using the responsive table.

SAP Fiori Element Worklist

The SAP Fiori element worklist does not support:

Basic structure
Basic structure

Responsiveness and Adaptiveness

In general, the worklist floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

Worklist floorplan - Size S
Worklist floorplan - Size S
Worklist floorplan - Size M
Worklist floorplan - Size M
Worklist floorplan - Size L
Worklist floorplan - Size L

SAP Fiori Element Worklist

The SAP Fiori element worklist automatically replaces grid tables with responsive tables on smartphones.
For tree tables, there is no meaningful fallback solution for smartphones.

Guidelines

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a table.

Simple worklist without tabs
Simple worklist without tabs

Worklist with Tabs

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs show different perspectives on the same dataset.

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red for the Error tab).

Worklist with tab categories
Worklist with tab categories

Worklist with KPI

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI within the KPI container next to the page title as an object status.

Worklist with KPI
Worklist with KPI

Header Title

Variant Management

Variant management is optional. If used, apply it to the whole page. Use the variants to save and restore all settings, including selected tabs, all tables, and all personalization settings.

If variant management is not needed, just show a title that describes the current view instead.

Header Toolbar (Global Actions)

Use this for non-finalizing global actions such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

In addition, offer any other global, non-finalizing actions that are needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Page Content

Tab Bar

The tab bar is part of the page content container, which means that the tab bar is not “sticky” and will scroll away when the user scrolls down the page.

Use the icon tab bar. Display the number of items shown in the table on each tab (sap.m.IconTabFilter, property: count). Only use icons if you need to display semantic colors on the icon tab bar.

The tab bar works as a filter on the content below.

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. For filter, sort, and group, show a view settings dialog with only the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items or only unsuitable items are selected. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table actions, see the guidelines for the table toolbar and for managing objects.

Table

If there are no items to display, use the “no data text” of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • The search was executed, but no items were found: No items found. Try adjusting your search criteria.
  • By opening a related app, the filter criteria were transferred automatically, but no items were found: No items found. Check the search and filter settings.

There are three types of navigation at item level in the worklist floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation. In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation. Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is used for a different target.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually a list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting. In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object, as well as a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

SAP Fiori Element Worklist

The SAP Fiori element worklist supports only simple content (manifest.json: quickVariantSelection or quickVariantSelectionX). Multiple content is not supported. If you use tabs with multiple views, the counters for the tabs are turned off by default. Turn them on, unless this causes performance problems (manifest.json: showCounts).

Only smart tables are supported. Since charts cannot be displayed, no view switch is needed.

The table toolbar supports:

  • Table title (annotation: UI.HeaderInfo, property: TypeNamePlural)
  • Item count: Turned on by default
  • Variant management for the table layout: Although the layout variant is turned on by default, it should not be used in most cases. If the layout variant is turned off, the table layouts are stored together with the page variant (manifest.json: smartVariantManagement).
  • Search field
  • Several standard and custom actions (see below)

Actions cannot be grouped using a menu button on the table toolbar.

Within the SAP Fiori element worklist, you can use the responsive table, grid table, analytical table, or tree table within the smart table.

The smart table supports:

  • No selection, single selection, or multiple selection (manifest.json: multiSelect). With multiple selection, the SAP Fiori element worklist triggers the action for all selected items. If an error occurs with one or more of the selected items, it can be handled in the following ways (annotation: OperationGroupingType):
    • Partial processing: A message is displayed for the items with issues. All other items are processed. The message displayed is generic and must be replaced.
    • Roll-back: A messageis displayed. All items are reverted. The message displayed is generic and must be replaced.
  • Text control in line items
  • Rating indicator within line items (annotation: UI.DataPoint)
  • Progress indicator within line items (annotation: UI.DataPoint)
  • Indicator for the editing status within the rows (for example Draft or Locked by [user]). Users can filter the table by editing status in the filter bar.
  • Line item navigation to different targets (maintain detail pages in manifest.json):
    • Navigation to a related object pagewithin the app (default). Apps can override this behavior and define their own navigation target. The target can also depend on specific conditions defined by the app (maintain detail pages in manifest.json).
    • Cross navigation to another SAP Fiori app or to another system
  • Link and smart link to show details in a quick view or to navigate. A quick view can be used as part of the smart link or for displaying contact details. For navigation, the target can be any web page, another app, or a related object page within the same app.
  • Line item actions as text or icon buttons (such as Approve and Reject).
  • Any control that the corresponding table allows by using breakout columns.

At present, the smart table does not support:

  • The object number. This is only available if you use a breakout column. Without a breakout, amounts appear as standard text only.

Only the responsive table supports:

  • A column that displays the object identifier, including the object name and ID (annotations: Common.SemanticKey with Common.Text)
  • Images in line items (annotation: UI.IsImageURL)
  • The object status control in line items: Use of a specific status, such as Out of Stock, in connection with one of the semantic colors and/or a status icon (criticality annotations). The object status provides different categories: success, warning, error, and none. To sort a column by object status, the SAP Fiori element worklist sorts this column by these categories. If more than one value is used in a category, take care that these values are sorted in a meaningful way within the category (for example, alphabetically).
  • A progress indicator in line items (annotation: UI.DataPoint)
  • Smart area micro charts, smart bullet micro charts, and smart radial micro charts in line items (annotation: UI.Chart)

Only the grid table, analytical table, and tree table support:

  • App-specific column widths: While the SAP Fiori element worklist calculates the width of each column automatically, this calculation is not always perfect. Apps can override the calculated width per column.

Changing the alignment of table content is only possible with UI adaptation.

Because the SAP Fiori element worklist does not support editing use cases, the message button is not supported on the footer toolbar.
Actions cannot be grouped using a menu button on the footer toolbar.

Actions

The worklist offers four locations for actions: global actions, table actions, line item actions, and finalizing actions.

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the standard Share action.

The Share button opens an action sheet that contains actions like Save as Tile (if the SAP Fiori Launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space in the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

Global actions
Global actions

2. Table Actions

Place actions that affect the content of a table in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no item is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on table actions, see the guidelines for the table toolbar and for managing objects.

Toolbar actions
Toolbar actions

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this option only for specific, frequently-used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or if the line item has the wrong state, for example.

Inline actions
Inline actions

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Finalizing actions
Finalizing actions

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen. Once the user has completed the task, the app should:

  • Return the user to the worklist
  • Remove the processed item from the list, or move it to a “completed” section
  • Confirm the user’s action with a message toast

SAP Fiori Elements

To see which features are available in the SAP Fiori Element Worklist, use the table below.

Feature Status Comment
 Header Title
Title only (no variant management) Supported
Variant management – page variant Supported
Variant management – only for filter settings Supported Not recommended
Filter information Supported
Global actions Not Supported
Generic action: Share Supported
Generic action: Show Filters / Hide Filters (with grid table, analytical table, tree table only) Supported
Content Area
General Layout
Simple content Supported One table only
Mutiple views – single toolbar (segmented buttons / select) Supported
Multiple views – one toolbar each (tabs) Supported
Multiple content Not Supported
Tabs
Item counts on tabs Supported
Table Toolbar
Title Supported
Item count Supported
Sort/filter/group via view settings dialog Not Supported Do not show filter settings on the table toolbar
Sort/filter/group via P13n dialog Supported Do not show filter settings on the table toolbar
View switch Not Supported
Alternative visualization: chart view Not Supported
Alternative visualization: table and chart view Not Supported
Other alternative visualizations Not Supported
Layout variant Supported Not recommended
App-specific actions with partial processing

(In case of errors, display a message for the items with issues. Process all other items.)

 Supported Change the generic message texts
App-specific actions with roll-back

(In case of errors, display a message. All items are reverted.)

 Supported Change the generic message texts
Enable/disable actions, depending on selection Supported
Grouping of actions (menu button) Not Supported
Overflow handling for toolbar Supported
Generic action: Edit Not Supported
Table
Table type: responsive table Supported
Table type: grid table Supported
Table type: analytical table Supported
Table type: tree table Supported
Table type: list Not Supported
Table type: tree Not Supported
Selection: Table items are not selectable Supported
Selection: single selection Supported
Selection: multi-selection Supported
App-specific column widths (grid table, analytical table, tree table only) Not Supported
Content: text Supported
Content: rating indicator Supported
Content: progress indicator Supported
Content: editing status Supported
Content: actions (text or icon buttons) Supported
Content: object identifier (responsive table only) Supported
Content: images (responsive table only) Supported
Content: object status (responsive table only) Supported
Content: smart area/bullet/radial micro chart (responsive table only) Supported
Any other content the underlying table allows Supported Via break-out only
Aligning content within columns Not Supported
Generic “no data” text Supported
Custom “no data” text Not Supported
Navigation: Line item navigation via navigation indicator (within app, cross-app, any target) Supported
Navigation: Line item navigation via link with/without quick view (within app, cross-app, any target) Supported
Footer Toolbar
Messaging button and message popover Not Supported
Finalizing actions Supported
Grouping of actions (menu button) Not Supported
 Actions
Global Actions
Generic action: Show Filters / Hide Filters Supported
Generic action: Share (icon button) Supported
App-specific actions Not Supported
Grouping of actions (menu button) Not Supported
Table / Chart Actions
Enabling / disabling actions, depending on the current selection Supported
Grouping of actions (menu button) Not Supported
Generic action: Add (via object page) Supported Draft handling is supported
Generic action: Add (via dialog) Supported Via break-out only
Generic action: Add (via new row) Not Supported
Generic action: Delete Supported
Generic action: Sort (via view settings dialog) Not Supported
Generic action: Sort (via P13n dialog) Not Supported
Generic action: Filter (via view settings dialog) Not Supported Do not use filter settings on the table
Generic action: Filter (via P13n dialog) Not Supported Do not use filter settings on the table
Generic action: Group (via view settings dialog) Not Supported
Generic action: Group (via P13n dialog) Not Supported
Generic action: Column Settings (via table personalization dialog) Not Supported
Generic action: Column Settings (via P13n dialog) Not Supported
Generic action: view settings, combining sort, filter, group, and column settings (via P13n dialog) Supported Not recommended. If used, turn-off filter settings.
Generic action: Export to Spreadsheet Supported
Generic action: Maximize Supported
App-specific actions as text button Supported
App-specific actions as icon-only button Not Supported
App-specific actions with partial processing Supported
App-specific actions with roll-back Supported
App-specific action in emphasized style Supported Use this only for one single action
App-specific action in positive/negative style Supported
App-specific action: trigger immediately Supported
App-specific action: needs user confirmation Supported
App-specific action: needs additional user input Supported
App-specific action: triggers navigation (within app, cross-app) Supported
App-specific action: triggers any other behavior Supported Via break-out only
Line Item Actions
App-specific actions as text button Supported
App-specific actions as icon-only button Supported
Generic action: Delete (icon-only button) Not Supported
Finalizing Actions
App-specific actions Supported
Grouping of actions (menu button) Not Supported

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

List Report (Floorplan + SAP Fiori Element)

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

You can implement the list report floorplan in two ways:

  • Use the corresponding SAPUI5 controls in a dynamic page layout. This gives you much greater flexibility, at the expense of more development time.
  • Use the SAP Fiori element for the list report. This generates the floorplan from OData annotations and reduces development time. However, the SAP Fiori element list report is limited to the most common features. Details on the SAP Fiori element for the list report are included at the end of each section.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items within a large set of items by searching, filtering, sorting, and grouping.
  • Users need to display the whole dataset using different visualizations (for example, as a table or as a chart), without requiring interactions between these visualizations. An example use case might be reporting.
    Note that this feature only applies to the freestyle list report floorplan, and not to the list report SAP Fiori element.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. Views can be switched using tabs, segmented buttons, or a select control.
  • Drilldown is rarely or never used, or is only available via navigation to another page, and not as free or flexible drilldown within the page itself.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, and the item or an identifying data point is known to the user (such as a barcode). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the worklist floorplan instead.
  • Users need to extract knowledge or insights from data, either to better understand the current situation, or to identify the root cause for a certain value.  Use the analytical list page instead.
  • Charts are not only used for visualization. Users need to switch between integrated chart and table views (hybrid view). Use the analytical list page instead.
  • Users need to see the impact of their action on a KPI. Use the analytical list page instead.
  • Users need to see not only the result, but also the impact of their filter settings directly in a chart representation. Use the analytical list page instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions, such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a chart, you can display the chart on its own (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.

SAP Fiori Element List Report

The SAP Fiori element list report does not support:

Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

SAP Fiori Element List Report

The SAP Fiori element list report automatically replaces grid tables and analytical tables with responsive tables on smartphones.
For tree tables, there is no meaningful fallback solution for smartphones.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

Header Title

Variant Management

Variant management is optional. If you use variants, apply them to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before the dataset is updated. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the format Filtered By (x): followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use the header toolbar for non-finalizing global actions, such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

SAP Fiori Element List Report

If variant management is not used, a default title repeats the text from the shell bar. Use this text only if there is no better alternative. In any other case, replace the title with one that better describes the current view.

In the header toolbar, Share and Show Filters / Hide Filters are supported as standard actions. App-specific actions can be added using a breakout.

By default, the variant management control saves the filter settings only. Change this setting to also save the table layout settings (manifest.json: smartVariantManagement).

Be aware that the SAP Fiori element list report does not support charts in the content area.

Header Content

The header content collapses when the user scrolls down the page (with a responsive table, list, or tree only), and expands again when the user scrolls back up. To avoid this automatic expand / collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.
Users can also expand and collapse the header content by clicking the background of the title bar.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title.

When starting the application, expand the header content if no query was fired (and the table is therefore empty). Collapse the header content in other cases.

Header Content - Expand / Collapse Behavior

  • List Report (Floorplan + SAP Fiori Element) Header Expanded - 1.48
  • List Report (Floorplan + SAP Fiori Element) Header Collapsed - 1.48

Filter Bar

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search terms and the filter criteria.

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

SAP Fiori Element List Report

The pin setting for the header content is not persisted.

In manual update mode, the content is grayed out whenever the user changes a filter after pressing Go, even if the change is reverted.
Within the smart filter bar, app-specific filters are also possible. Apart from the combo box, select, input field (with or without value help), date picker, and search field, you can also deploy other controls using breakout options. One example would be the rating indicator (SmartFilterBar, annotation: UI.SelectionFields).

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. Multiple views involve one or more of the following:

  • Showing the same table, but with different columns.
  • Showing the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

There are two options for switching between different views:

The first option is to replace the table title with a content switch. Use this approach if all views share the same sort and group states, as well as the same actions.

The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country, View by Customer, …)

The second option for switching views is to show each view in a tab container of the icon tab bar. Use this approach if all views show different states of the same data (sort states, group states, as well as item selection). Using tabs also allows you to offer different actions on the table toolbar for each view.

Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items are selected, or if the action cannot be applied to the selected items. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions
Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are no items to display, use the “no data” text of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    No filters set. To start, enter your search and filter settings and run the search.
  • The filter was executed, but no items were found. This can also happen if the list report was opened by a related app, and the filter criteria were transferred automatically:
    No items found. Check the search and filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is being used for a different target.
    Only show navigation indicators for target pages the user is authorized to access.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer toolbar
Footer toolbar

SAP Fiori Element List Report

The SAP Fiori element list report supports only simple content and multiple views (manifest.json: quickVariantSelection or quickVariantSelectionX). Multiple content is not supported. If you use tabs with multiple views, the counters for tabs are turned off by default. Turn them on, unless this causes performance problems (manifest.json: showCounts).

Only smart tables are supported. In case of multiple views, one view can contain either a smart table or a smart chart.

The table toolbar supports:

  • Table title (annotation: UI.HeaderInfo, property: TypeNamePlural)
  • Item count: Turned on by default.
  • Variant management for the table layout: Although it is turned on by default, it should not be used in most cases. If the layout variant is turned off, the table layouts are stored together with the page variant (manifest.json: smartVariantManagement).
  • Several standard and custom actions (see below)
Actions cannot be grouped using a menu button on the table toolbar.

Within the SAP Fiori element list report, you can use the responsive table, grid table, analytical table, or tree table within the smart table (manifest.json: tableType).

The smart table supports:

  • No selection, single selection, or multiple selection (manifest.json: multiSelect). With multiple selection, the SAP Fiori element list report triggers the action for all selected items. If an error occurs with one or more of the selected items, it can be handled in the following ways (annotation: OperationGroupingType):
    • Partial processing: A message is displayed for the items with issues. All other items are processed. The message displayed is generic and must be replaced.
    • Roll-back: A message is displayed. All items are reverted. The message displayed is generic and must be replaced.
  • Displaying the generic “no data” text if the table is empty.
  • Highlighting items with semantic colors.
  • Text control in line items
  • Rating indicator within line items (annotation: UI.DataPoint)
  • Progress indicator within line items (annotation: UI.DataPoint)
  • Indicator for the editing status within the rows (for example Draft or Locked by [user]). Users can filter the table by editing status in the filter bar.
  • Line item navigation to different targets (maintain detail pages in manifest.json). Authorization rights for the targets are checked per table. Where available, the navigation indicators are displayed for all line items (but not for hidden items). Possible targets include:
    • Navigation to a related object page within the app (default). Apps can override this behavior and define their own navigation target. The target can also depend on specific conditions defined by the app (maintain detail pages in manifest.json).
    • Cross navigation to another SAP Fiori app or to another system
  • Link and smart link to show details in a quick view or to navigate. A quick view can be used as part of the smart link or for displaying contact details. For navigation, the target can be any web page, another app, or a related object page within the same app.
  • Line item actions as text or icon buttons (such as Approve and Reject).
  • Any control that the corresponding table allows by using breakout columns.

At present, the smart table does not support:

  • The object number control. This is only available if you use a breakout column. Without a breakout, amounts appear as standard text only.
  • Highlighting items with a neutral color. Exception: newly created items.

Only the responsive table supports:

  • A column that displays the object identifier, including the object name and ID (annotations: Common.SemanticKey with Common.Text)
  • Images in line items (annotation: UI.IsImageURL)
  • The object status control in line items: Use of a specific status such as Out of Stock in connection with one of the semantic colors and/or a status icon (criticality annotations).
    The object status provides different categories: negative (property: error), critical (property: warning), positive (property: success), and neutral (property: none). When a column is sorted by object status, the SAP Fiori element list report sorts by these categories. If a category has multiple values, ensure that the values within the category are sorted in a meaningful way (for example, alphabetically).
  • A progress indicator in line items (annotation: UI.DataPoint)
  • Smart area micro charts, smart bullet micro charts, and smart radial micro charts in line items (annotation: UI.Chart)
It is not possible to change the alignment of table content.

Because the SAP Fiori element list report does not support inline editing, the message button is not supported on the footer toolbar.

Actions cannot be grouped using a menu button on the footer toolbar.

Actions

Places for actions in the list report
Places for actions in the list report

(1) Global actions in the header toolbar
(2) Table actions in the table toolbar
(3) Line item actions
(4) Finalizing actions in the footer toolbar

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

SAP Fiori Element List Report

The header toolbar provides the following built-in actions:

  • Show Filters / Hide Filters (if needed)
  • Share

App-specific actions can be added using a breakout.  They cannot be grouped using a menu button on the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no item is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

If qualifying items can be identified before the action is executed, show a message about how many of the selected items the action will be applied to. In other cases, show a corresponding message after the action was executed.

Hide actions that cannot be used at all (for example, because the user has no authorization). If you are using an icon tab bar, be aware that each tab contains its own table toolbar.

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

SAP Fiori Element List Report

The table toolbar provides the following built-in actions:

  • Add: An icon button that triggers an object page for creating an item. If this function is not needed, or if you want users to add or create items differently (for example, in a dialog), turn it off. If you use this button, replace the generic tooltip Create Object with a more specific text, such as Create Purchase Order.
    Draft handling is supported (recommended). (annotation: Creatable)
  • Delete: A text button to delete selected items. Delete is enabled as soon as deletable items are selected. If this function is not needed, turn it off. (annotation: Deletable)
  • View Settings (sort, group, column settings): In contrast to the guidelines above, only one button is shown for sort, group, and columns settings. The icon button always opens the p13n-dialog with all features enabled. The less complex view settings dialog cannot be used.
    The SAP Fiori element list report also allows users to add filter settings within the p13n-dialog. This feature is only available if an explicit layout variant is being used for the table, which should not usually be the case. Do not use this feature.
  • In addition, you can add app-specific actions, such as Copy or Approve. These actions are displayed as text buttons. App-specific actions can be enabled or disabled, depending on the items selected in the table. If an action applies to only some of the selected items, display a corresponding message.

There are 3 types of app-specific action:

  • The system simply triggers the action.
  • The action requires user confirmation. Use this for critical actions that have severe consequences. A message box appears, and the user needs to confirm the action. The message displayed is generic and must be replaced (annotation: IsActionCritical).
  • The action needs additional user input, such as an approval comment. The system opens a dialog with one or more user input elements in which the user enters the required data. The system can pre-fill data if applicable (function import with parameters).

App-specific actions can also trigger navigation to another app or to a related object page within the same app. The navigation can depend on zero selected items, or on one selected item.

Actions cannot be grouped using a menu button.
Actions in the smart table toolbar
Actions in the smart table toolbar

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. This can be the case if the user has no authorization or the line item is in the wrong state.

SAP Fiori Element List Report

Actions cannot be grouped using a menu button.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

SAP Fiori Element List Report

Actions cannot be grouped using a menu button.

SAP Fiori Element

Use the table below to see which features are available for the “list report” SAP Fiori element.

Feature Status Comment
 Header Title
 Title only (no variant management) Supported
Variant management: Page variant Supported
Variant management: Only for filter settings Supported Not recommended
Filter information Supported
Global actions Supported
Generic action: Share Supported
Generic action: Show Filters / Hide Filters (only with grid table, analytical table, and tree table) Supported
Header Content
General
Persisting pin state Not Supported
Filter Bar
Search field Supported
Mandatory fields Supported
Default values Supported
Live update mode Supported
Manual update mode (Go button) Supported Use only in case of performance problems
Any control in the filter bar Supported Via breakout only
Content Area
General Layout
Simple content Supported One table only
Mutiple views: Single toolbar (segmented buttons / select) Supported
Multiple views: One toolbar each (tabs) Supported
Multiple content Not Supported
Tabs
Item counts on tabs Supported
Table Toolbar
Title Supported
Item count Supported
Sort / Filter / Group via View Settings dialog Not Supported Do not show filter settings on the table toolbar
Sort / Filter / Group via P13n dialog Supported Do not show filter settings on the table toolbar
View switch Not Supported
Alternative visualization: Chart view Not Supported
Alternative visualization: Table and chart view Not Supported
Other alternative visualizations Not Supported
Layout variant Supported Not recommended
App-specific actions with partial processing

(In case of errors, display a message for the items with issues. Process all other items.)

 Supported Change the generic message texts
App-specific actions with roll-back

(In case of errors, display a message. All items are reverted.)

 Supported Change the generic message texts
Enable/disable actions, depending on selection Supported
Grouping of actions (menu button) Not Supported
Overflow handling for toolbar Supported
Generic action: Edit Not Supported
Table
Table type: Responsive table Supported
Table type: Grid table Supported
Table type: Analytical table Supported
Table type: Tree table Supported
Table type: List Not Supported
Table type: Tree Not Supported
Selection: Table items are not selectable Supported
Selection: Single selection Supported
Selection: Multi-selection Supported
App-specific column widths (only grid table, analytical table, and tree table) Not Supported
Content: Text Supported
Content: Rating indicator Supported
Content: Progress indicator Supported
Content: Editing status Supported
Content: Actions (text or icon buttons) Supported
Content: Object identifier (responsive table only) Supported
Content: Images (responsive table only) Supported
Content: Object status (responsive table only) Supported
Content: Smart area / bullet / radial micro chart (responsive table only) Supported
Content: Any other content as long as the underlying table allows it Supported Via breakout only
Aligning content within columns Not Supported
Generic “No data” text Supported
Custom “No data” text Not Supported
Navigation: Line Item navigation via navigation indicator (within app, cross-app, any target) Supported
Navigation: Line Item navigation via link with/without quick view (within app, cross-app, any target) Supported
Footer Toolbar
Messaging button and message popover Not Supported
Finalizing actions Supported
Grouping of actions (menu button) Not Supported
 Actions
Global Actions
Generic action: Show Filters / Hide Filters Supported
Generic action: Share (icon button) Supported
App-specific actions Supported  Via breakout only
Grouping of actions (menu button) Not Supported
Table / Chart Actions
Enable/disable actions depending on the current selection Supported
Grouping of actions (menu button) Not Supported
Generic action: Add (via object page) Supported Draft handling is supported
Generic action: Add (via dialog) Supported Via breakout only
Generic action: Add (via new row) Not Supported
Generic action: Delete Supported
Generic action: Sort (via View Settings dialog) Not Supported
Generic action: Sort (via P13n dialog) Not Supported
Generic action: Filter (via View Settings dialog) Not Supported Do not use filter settings on the table
Generic action: Filter (via P13n dialog) Not Supported Do not use filter settings on the table
Generic action: Group (via View Settings dialog) Not Supported
Generic action: Group (via P13n dialog) Not Supported
Generic action: Column settings (via table personalization dialog) Not Supported
Generic action: Column settings (via P13n dialog) Not Supported
Generic action: View settings – combines sort, filter, group, and column settings (via P13n dialog) Supported Not recommended. If used, turn off filter settings.
Generic action: Export to Spreadsheet Supported
Generic action: Maximize Supported
App-specific actions as text button Supported
App-specific actions as icon-only button Not Supported
App-specific actions with partial processing Supported
App-specific actions with roll-back Supported
App-specific action in emphasized style Supported Use this only for a single action
App-specific action in positive/negative style Supported
App-specific action: Trigger immediately Supported
App-specific action: Needs user confirmation Supported
App-specific action: Needs additional user input Supported
App-specific action: Triggers navigation (within app, cross-app) Supported
App-specific action: Triggers any other behavior Supported Via breakout only
Line Item Actions
App-specific actions as text button Supported
App-specific actions as icon-only button Supported
Generic action: Delete (icon-only button) Not Supported
Finalizing Actions
App-specific actions Supported
Grouping of actions (menu button) Not Supported

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Analytical List Page (SAP Fiori Element)

Analytical list page – Size XL
Analytical list page – Size XL

The analytical list page (ALP) offers a unique way to analyze data step by step from different perspectives, to investigate a root cause through drilldown, and to act on transactional content. All this can be done seamlessly within one page. The purpose of the analytical list page is to identify interesting areas within datasets or significant single instances using data visualization and business intelligence.

Visualizations help users to recognize facts and situations, and reduce the number of interaction steps needed to gain insights or to identify significant single instances. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

The main target group are users who work on transactional content. They benefit from fully transparent business object data and direct access to business actions. In addition, they have access to analytical views and functions without having to switch between systems. These include KPIs, a visual filter where filter values are enriched by measures and visualizations, and a combined table/chart view with drill-in capabilities (hybrid view). Users can interact with the chart to dig deep into the data. The visualization enables them to identify spikes, deviations and abnormalities more quickly, and to take appropriate action right away.

Usage

Use the analytical list page if:

  • Users need to extract key information to understand the current situation or identify a root cause. The way the data is presented is crucial for giving them the insights they need to take the right action.
  • Users need a way to analyze data step by step from different perspectives, investigate a root cause through drilldown, and act on transactional content within one page.
  • In addition to the filtered dataset, users need to see the impact of their filter settings in a chart (visual filter).
  • Users need to switch between integrated chart and table views (hybrid view).
  • Users need to see the impact of their action on a global key performance indicator (KPI).
  • Users need to find and act on relevant items out of a large set of items by searching, filtering, sorting, grouping, drilling down, and slicing and dicing.

Do not use the analytical list page if:

  • Drilldown is rarely used, not used at all, or is only needed after navigating to another page, rather than as free or flexible drilldown within the page itself. In this case, a list report might be sufficient for your use case.
  • Users need different visualizations for the entire dataset (for example, as a table or chart), but don’t need to work with both visualizations on the same page (for example, in a reporting scenario). In this case, a list report might be sufficient.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping, without using drilldown or “slice and dice”. In this case, consider using a list report.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. They want to be able to switch views using tabs, segmented buttons, or a select control. In this case, consider using a list report.
  • Users need to see or edit a single item with all its details. Use the object page floorplan instead.
  • Users need to find a specific item, and the item or an identifying data point is known to the user (such as a barcode). In this case, use the initial page floorplan.
  • Users need to work through a comparably small set of items, one by one. In this case, use the worklist floorplan.

Structure

This section describes the basic layout of the analytical list page, as well as the different layout variants.

Basic Layout

The shell bar is on top of the analytical list page. The page itself uses the dynamic page layout and has two main areas:

  1. Analytical list page header: The page header has two states: collapsed and expanded. The content shown depends on the state. The user can easily switch the state using the visual indicator.
  2. Analytical list page content area: This area combines three different views and a view switch:
    • Hybrid view (combined chart and table view)
    • Chart-only view
    • Table-only view

All elements are described in more detail in the Components section below.

Analytical list page - Basic layout
Analytical list page - Basic layout

Layout Variants

The layout of the analytical list page is quite flexible. Depending on the state of the analytical page header and the view in the content area, different content is displayed.

For example, the expanded page header allows users to display either the visual filter bar or the filter bar, while the page content area can display either a hybrid view, a chart-only view, or a table-only view.

Analytical List Page Layout Variants

  • Analytical list page - Hybrid view (collapsed)
  • Analytical list page - Hybrid view with visual filters (expanded)
  • Analytical list page - Hybrid view with compact filters (expanded)
  • Analytical list page - Chart view (collapsed)
  • Analytical list page - Chart view with visual filters (expanded)
  • Analytical list page - Chart view with compact filters (expanded)
  • Analytical list page - Table view (collapsed)
  • Analytical list page - Table view with visual filters (expanded)
  • Analytical list page - Table view with compact filters (expanded)

Responsiveness

The analytical list page is responsive, except for the global KPIs. Apps with one or more global KPIs are not supported on screen sizes smaller than size L (desktop).

Likewise, the analytical list page is only fully supported in the flexible column layout if no global KPIs are used. If you use the analytical list page with global KPIs within the flexible column layout, the column should have at least size M.

Size S

On size S, the analytical list page supports both the chart-only and table-only views. The table-only view supports only the responsive table. If no responsive table is available, the chart-only view is displayed without a view switch toggle.

Global KPIs are not supported on size S.

Size M

On size M, the analytical list page supports both the chart-only and table-only views. You can use a responsive table or analytical table in the table-only view.

Chart-only view - Size S
Chart-only view - Size S
Table-only view - Size S
Table-only view - Size S
Chart-only view - Size M
Chart-only view - Size M
Table-only view - Size M
Table-only view - Size M

Component Overview

Analytical List Page Header

The page header can be expanded and collapsed on click/tap. Different content is shown in the expanded and collapsed states.

Collapsed Header

The collapsed page header contains the following elements:

Collapsed analytical list page header
Collapsed analytical list page header

Expanded Header

The expanded page header contains the following elements:

Expanded analytical list page header showing the visual filter bar
Expanded analytical list page header showing the visual filter bar
Expanded analytical page header showing compact filters in the filter bar
Expanded analytical page header showing compact filters in the filter bar

Analytical List Page Content Area

The analytical list page content area contains the following elements:

  • View switch (   |    |    )
  • Hybrid view: View with one chart, chart toolbar, one table, and a table toolbar
  • Chart-only view: View with one chart and a chart toolbar
  • Table-only view: View with one table and a table toolbar

Analytical List Page Content Area

  • Hybrid view
  • Chart-only view
  • Table-only view

Analytical List Page Header

Variant Management

Variant management in the analytical list page allows users to save a page variant whenever there are changes in the underlying structures of the filter/content area. Variant management for the page is handled by the standard SAPUI5 page variant management.

Currently, the page variant captures the following states across the page:

  • Filter view switch state: Visual filter bar or filter bar
  • Filter set: The filters set in the visual filter bar and filter bar
  • Filter selections: Selected values in the visual filter bar and filter bar
  • Content view switch state: hybrid view  , chart-only view  , or table-only view  
  • Chart and table configurations, such as measures and dimensions used, sort order, or grouping
  • Chart drill-down state, based on the current selections (slice & dice)
  • Table entry switch state: Hide (  ) or Show  (  ) selected table records
Standard page variant management
Standard page variant management

Global KPI Tags and Cards

Use a global KPI tag (= global key performance indicator tag) if you would like to show a global KPI related to the task in hand. The global KPI value changes only if an action is executed on the transactional content. For example, the user needs to know the effect of releasing sales orders on a related global KPI, or the effect of posting an accounting document on certain financial global KPIs.

You can display a maximum of three global KPIs. Clicking a global KPI tag opens a global KPI card that displays more details on the KPI.

The global KPI tags and corresponding KPI cards are independent of the filter area. This means that global KPI tags do not react to filters set in the visual filter bar and filter bar.

A global KPI tag has four components:

  • Global KPI label
  • Global KPI value
  • Global KPI color and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator

Global KPI Label

The global KPI label is an abbreviation of the complete global KPI title. It is formed using the first three letters of the first three words of the global KPI title.
Examples: AMR for Actual Monthly Revenue, TAR for Total Advertising Revenue, or LPC for Landing Page Conversation Rates

If there is only one word in the global KPI title, the first three letters of the word are displayed. Example: CON for Contracts

If the global KPI title has only two words, only the first letters of these two words are displayed. Examples: AC for Actual Costs, SG for Sales Growth

KPI label abbreviation: AC
KPI label abbreviation: AC

Global KPI Value

The global KPI value is displayed using a semantic color and a scaling factor. Relative values are shown with a percentage sign and one decimal place.
Examples: 0.3%, 82.9%
Absolute values are shown without decimal places, a currency, or a unit of measure.
Examples: 2K, 75K, 30M, 14B

KPI values: 2K and 0.3%
KPI values: 2K and 0.3%

Global KPI Color and Criticality Indicator

The color of the global KPI value is based on the thresholds defined for the particular KPI in the annotation. The global KPI tag also uses a line to indicate the criticality. The color of the line is the same as that of the global KPI value.

KPI color and criticality indicator
KPI color and criticality indicator

Global KPI Card

Clicking the KPI tag opens the analytical card, which displays more information about the current value of the global KPI, the global KPI target, the deviation from the target, and how the global KPI has evolved over time.

Global KPI card
Global KPI card

Filter Area: Visual Filter Bar and Filter Bar

The filter area allows users to filter the result set, which feeds the main content area. The analytical list page comes with two filter types: compact filters in the filter bar, and the visual filter bar. Always design both a visual filter and compact filters (filter bar) for your app. Use the visual filter bar as the default. Recommendation: Only use the compact filters in the filter bar as the default filter mode if parameter values are required.

Currently, any visual filter configured in the visual filter bar must always be displayed as a compact filter in the filter bar as well. By contrast, a filter configured as a compact filter in the filter bar may or may not be configured for display as a visual filter.

Both filter types supports two different modes: live update and manual update. Use the live update mode for both filter types as the default whenever possible. Apply the same mode to both filter types: the visual filter bar and the filter bar. For example, if you use the live update mode in the visual filter bar, you should also use the live update mode for the filter bar.

Visual filter bar
Visual filter bar
Filter bar
Filter bar

Filter Type Switch

Users can toggle between the compact filters    (filter bar) and the visual filter bar    in the upper-right area of the page header. The filter type switch is a core feature of the analytical list page and is mandatory. The switch is only displayed when the page header is expanded. Once the header collapses, it disappears.

Filter type switch
Filter type switch

Carrying Forward Filter Selections

Visual Filter to Compact Filter

Any values selected in the visual filters are always carried forward to the corresponding compact filters.

Compact Filter to Visual Filter

Filter dimensions that are part of a visual filter are synced to the visual filter. If the dimension value(s) chosen in the compact filter are part of a visual filter, they are shown as selected chart dimensions in the visual filter (single or multiple selections).

Filter dimensions that are not part of the visual filter, parameter values, and interval-based dimensions are applied to the filter query and the content is refreshed.

To show complex conditions, click the link for the number of selected items at the top of the visual filter.

Visual Filter Bar

The visual filter bar combines measures or item counts with filter values. The visual filter bar becomes more powerful if you match measures to the filter dimension instead of just item counts. Use the visual filter bar if you would like to give the user a condensed overview of the data in the dataset. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

Chart Types in the Visual Filter Bar

Currently, the visual filter bar supports three interactive chart types:

These interactive charts are also referred to as visual filters.

Interactive Donut Chart

The interactive donut chart in the visual filter bar is used for non-time-related data (for example, categories) and displays only the top or bottom two values. The rest are aggregated into the “Other” section.

Interactive donut chart
Interactive donut chart
Interactive donut chart with semantic colors
Interactive donut chart with semantic colors

Interactive Line Chart

The interactive line chart is used exclusively for displaying time series data, and can show a maximum of six data points. Always show the first or last six data points (for example, last six days, last six months, first six days, and so on).

Interactive line chart
Interactive line chart
Interactive line chart with semantic colors
Interactive line chart with semantic colors

Interactive Bar Chart

The interactive bar chart can be used for non-time-related data (for example, categories) and has a maximum of three filter values. These filter values show the top three or bottom three entries.

Interactive bar chart
Interactive bar chart
Interactive bar chart with semantic colors
Interactive bar chart with semantic colors

The interactive charts come with a number of features and rules:

  • Minimum number of interactive charts: Show at least three visual filters and try to use different chart types.
  • Filter title: Use the following naming convention for the filter title, using title case: <Measure Name> by <Dimension Name> in <Scale Factor> <Unit of Measure>. For example, Project Costs by Project in K EUR, Sales Volume by Commodity in M PC. For an item count, use the following naming convention for the filter title, using title case: Number of <Dimension> in <Scale Factor> <Unit of Measure>. For example, Number of Products in PC or Number of Contracts by Month. Note that for some use cases, it might be appropriate to replace Number with a different expression.
  • Filter-to-filter dependencies: Ideally, the filters depend on each other. By selecting one or several chart data points, users can perform a quick analysis of the dataset.
    Examples: Supplier with the lowest supplier performance this year, product with the highest sales volume in March in the EMEA region
  • Adding additional filter values: All charts have a maximum number of filter values that can be displayed within the chart itself. More filter values can be selected using the value help.
  • Selected values: Any data point or segment that is selected in the visual filter’s interactive charts will remain selected even when the user changes the measure, chart type, or sort order in any of the charts. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.
  • Semantic colouring: All interactive charts support semantic colors to indicate the criticality of filter values.
  • How to design a visual filter: To design a visual filter, choose a meaningful measure out of the dataset and match it to a filter dimension. If no measures or no meaningful measures are available, use an item count instead. Have a look at the visual filter bar article for more information.

Filter Dialog

In the filter dialog, the user can switch between the visual filter bar filters and the filter bar filters using a toggle button. The standard filter dialog is explained in the Filter Bar article. The part for the visual filter is further explained below.

Filter Dialog for Visual Filters

The filter dialog is launched by clicking the Adapt Filters (<number of applied filters>) link in the page header area. In the filter dialog for visual filters, the user can choose which filter fields are shown in the visual filter bar, and make the following changes:

  • Add visual filters
  • Delete visual filters
  • Hide visual filters in the visual filter bar
  • Search for visual filters
  • Change the sort order  of each visual filter
  • Change the chart type   of each visual filter
  • Switch to other measures  in the visual filter display

Analytical List Page Content Area

The content area shows different visualizations of the selected data. In the hybrid view, users can interact with both the chart and table visualizations at the same time. In addition, the analytical list page supports a chart-only view and a table-only view. The analytical list page always comes with all three views. Offering additional views or even tabs would add too much complexity, and is neither supported nor recommended.

Check out the following sections for more details on the hybrid view, chart-only view, and table-only view.

Hybrid View

The hybrid view uses both chart and table visualizations at the same time. It enables users to analyze data step by step from different perspectives. Users can interact with both the chart and the table, and drill down through either the smart chart or table entries to investigate a root cause. They can also act directly on transactional content. In the initial view of the chart, visualize the most important aspects of the whole dataset in the chart.

Example: The view shows all the suppliers the user is responsible for, organized by value. By drilling down the material to the plant with the highest/lowest volume, the user can see if materials need to be shifted from one plant to another. The corresponding transactional data is shown in an analytical table below the chart, which might also offer an action for shifting the material.

Analytical list page - Hybrid view
Analytical list page - Hybrid view

Chart-Only View

The chart-only view enables users to analyze data step by step from different perspectives, and to investigate a root cause through drilldown, without direct access to transactional content. The smart chart control provides the chart visualization in the chart-only and hybrid views: it is used to display the dataset as a chart. The smart chart drilldown functionality provides a convenient way to analyze the dataset. In addition, the smart chart offers detailed information on the chart data and a breadcrumb that shows the drilldown path. Ensure that you show the most important aspects of the dataset in the chart.

This mode is perfect for applications with analytical data that can easily be represented visually using charts, but doesn’t need to be linked to the transactional dataset.

Analytical list page - Chart-only view
Analytical list page - Chart-only view

Table-Only View

The table view provides access to transactional content. The user can act on single or multiple objects, and navigate to the object details or to other applications.

Depending on the use case, you can opt to use either the analytical table or the responsive table.

Snapping or scrolling is not available for desktop-focused tables, such as the analytical table. The table entries are loaded with lazy loading.

Analytical list page - Table-only view
Analytical list page - Table-only view

Behavior and Interaction

Global KPI Tag/Card

Clicking/tapping a KPI tag opens the KPI card, which shows the details for the particular KPI.

Select Filters in the Visual Filter

Unlike micro charts, the visual filter charts are interactive. In live search mode, selecting a filter value triggers data filtering in the content area. Both single and multiple selection are supported.

To select a filter value, the user clicks on a value in the chart. The filter can be removed by either clicking on the value help link, or by clicking on the same value in the chart again. The user can select more filter values using the value help.

Any data point that is selected in a chart still remains selected when the user selects a data point in another chart. Filter values react on each other. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.

Switch Views: Hybrid, Chart-Only, and Table-Only

Users can switch between the hybrid view, chart-only view, and table-only view.

If the user selects values and then switches the view, the selection remains intact. See the table below for more details.

Switch Description
Hybrid view to table view Table selection remains intact
Hybrid view to chart view Chart selection remains intact
Chart view to hybrid view Chart selection remains intact; corresponding table selections are displayed
Table view to hybrid view Table selection remains intact

Show/Hide Table Entries in Hybrid View and Table View

The table toolbar for the analytical list page offers a Show   and Hide    table entries feature as a toggle switch in the hybrid and table views:

  • If the Show icon is active, the table shows all items. These include highlighted entries (where values are selected in the chart) and non-highlighted entries.
  • If the Hide icon is active, the table shows only items that are selected in the chart.

For example, if the user selects SAP’s Sales Revenue for 2012 as Customer in the chart, all records relating to SAP’s Sales Revenue for 2012 are highlighted (but not selected) in the table. Note that the record is still highlighted even if Customer not displayed as a column in the table. If the table rows are grouped, the entire grouping is highlighted, even if only one record within the grouped set is affected by the chart selection. All values that are not selected in the chart are “hidden” and are not shown in this table mode.

Guidelines

Show the filter dimension with one measure in the visual filter, not multiple measures

Filter dimensions in the compact filters (filter bar) have exactly one representation in the visual filter bar.
Do not show the same filter dimension with two or more different measures at the same time in the visual filter bar. The example shows the filter Dimension Year with two different measures Revenue and Quantity. Showing the filter dimensionYear twice is not in sync with the compact filter, where it is shown only once. Furthermore, matching between the two filter types will not work.

If the use case requires you to show a dimension with different measures, consider using an overview page instead.

Do
For each dimension display exactly one representation in the visual filter bar.
For each dimension display exactly one representation in the visual filter bar.
Don't
Do not use the same filter dimension with different measures
Do not use the same filter dimension with different measures

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • No links.

Object Page (Floorplan + SAP Fiori Element)

The object page floorplan allows the user to display, create, or edit an object. This is now the recommended floorplan for representing both simple and complex objects in SAP Fiori. It has replaced the flat object view floorplan and is set to replace the object view floorplan. The object page floorplan comes with a flexible header, a choice of anchor or tab navigation, and a flexible, responsive layout. These features make it adaptable for a wide range of use cases.

You can implement the object page floorplan in two ways:

  • Use the pre-built SAP Fiori element (formerly known as a smart template). This implementation uses OData annotations, and allows you to speed up development if the supported feature set matches your requirements. For an overview of the supported features, see the SAP Fiori Element section.
  • Implement the floorplan yourself using the respective SAPUI5 controls.
Object page floorplan
Object page floorplan

Usage

Use the object page floorplan if:

  • Users need to see, edit, or create an item with all its details.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

  • Users want to edit several items at the same time. Use the list report floorplan instead.
  • Users need to find relevant items without knowing the exact item details. Use the list report floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner). Use the initial page floorplan instead.
  • Users need to be guided through a series of steps when a new object is created. Use the wizard floorplan instead.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected. Use the wizard floorplan instead.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL).

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The layout for size XL (large display) contains four columns.

The default layout for size L (desktop) contains three columns. You can also use an optional two-column layout.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Structure

The object page is a full screen floorplan with a display mode, a create mode, and an edit mode.

In all modes, the object page contains:

  • A snapping header
  • A navigation bar
  • A content area

The following sections explain these components in more detail.

Schematic visualization of object page
Schematic visualization of object page

Snapping Header

The snapping header is the uppermost element of the object page floorplan. It contains key information about the business object and provides the user with the necessary context. The header also contains global actions for the object.

Toolbars

The object page supports two toolbars:

  • Header toolbar: Use this toolbar for global actions such as Edit, Delete, Copy and Share.
  • Floating toolbar: Use this toolbar for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

This applies to all object page modes (display, edit, and create).

Responsive overflow toolbar
Responsive overflow toolbar

Navigation

There are three ways to navigate within the object page:

  • Anchor bar (by default)
  • No navigation (flat scrollable page)
  • Tabs

Usage

  • To offer a flat page for a simple object, remove the navigation.
  • For more complex objects, use the anchor or tab navigation.
Object page – Anchor navigation
Object page – Anchor navigation

Anchor Bar and Overflow

The anchor bar is the default navigation control for the object page. It consist of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint

Anchor Bar and Overflow

Use title case for the anchor bar texts. To do this, you need to change the default capitalization (block caps) by changing the the property upperCaseAnchorBar to “false”.

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow overview button on the right of the navigation bar ( ) opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow overview button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the document.

Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow overview button
  8. Overflow overview dropdown
  9. Section (hover) in overflow overview
  10. Section in overflow overview
  11. Subsection in overflow overview

Behavior and Interaction

  • Clicking an anchor link scrolls the page to the selected section.
  • Clicking a section anchor that contains more than one subsection opens a subsection menu.
  • Clicking a subsection scrolls the page to the selected subsection. The keyboard left and right arrows allow the user to move between the anchor links.
  • Hovering over the fade area to the left or right of the anchor bar causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
  • Clicking the overflow scroll button (right arrow) scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
  • Clicking the overflow overview button ( ) displays a hierarchical dropdown list with all the sections and subsections of the document. Clicking an item in the overflow list scrolls to the respective section or subsection.

Hiding the Navigation

An object page can be used in a similar way to a flat object view. This is achieved by hiding the navigation bar from the object page, leaving a flat scrollable object. We recommend using this flat view for simple content that doesn’t require anchor navigation.

Tab Navigation

As an alternative to anchor navigation, you can also opt for tab navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. Tab navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional and the default state is “false”. If the state is set to “true”, a dropdown arrow is shown next to the tab. Clicking on the tab displays a dropdown menu with the subsection anchors for that tab.

Object page – Tab navigation
Object page – Tab navigation

Breadcrumbs

If the object page uses a hierarchical parent-child drilldown, you can offer a breadcrumb for navigation. The breadcrumb is part of the snapping header.

Content Area

The object page content consists of sections and subsections arranged in a column layout. For large documents, you can enable a lazy loading mechanism (property: enableLazyLoading) to mitigate the loading time.

Sections

Sections are containers for subsections. They provide the basic structure for navigation, and are directly reflected in the navigation bar. Sections can have a title, subsections, and actions. However, they cannot contain controls.

Use title case for the section title (property titleUppercase = “false”). The title can have an item counter, which is displayed in parentheses. If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Global actions are always placed at subsection level. Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for global actions at the subsection level.

Subsections

Subsections are the containers for actual content. Always place individual controls inside the subsections. Subsection content is arranged according to the column layout approach for the respective screen size. A subsection can include containers for different controls (mixed content).

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can also display everything by selecting the Show All button at the bottom right of the subsection.

Each subsection can have a toolbar, which is placed at subsection header level on the right. The toolbar contains actions that affect the content of the subsection.

Subsections within the same section are separated by a gray horizontal line. Subsections can have an item counter, which is displayed in parentheses next to the subsection header.

You can include various types of related content in one subsection. The layout blocks for the object page give you the flexibility to combine different content types.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times, and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.
Object page – Blocks
Object page – Blocks

Contacts

The contacts on the object page are technically a list, but they can be represented visually as a card.

The cards can contain:

  • An image (optional)
  • A title (mandatory)
  • A subtitle (optional)
  • A text snippet consisting of two lines maximum (optional)

A single card covers the column’s entire horizontal space. To avoid alignment problems, all cards are the same height. The card with the most content defines the overall height for all cards. The image can be rectangular or round. It shows in the top left corner of the card. The content of the card never truncates. If there is not enough space to display the information, it wraps onto the next line.

Content type – Contacts
Content type – Contacts

Tables

In an object page, tables with up to 20 expected items can be displayed right away without lazy loading.

If a table is expected to have more than 20 items, use one of the following 3 options for long tables:

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial amount of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, this option should be used only for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. Here it is important to place the table within a tab as the only or at least the last element and to enable the scroll to load behavior.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, the table itself should be restricted to a reasonable amount of items. We recommend only showing a preview of the data in the table, which should not contain more than 20 items. Ideally, you should have about 10 items. This can be either be achieved by prefiltering and/or by sorting the table, and if necessary, by restricting it to a fixed amount of items (such as top 10). To provide the user with a way to work with the entire table, a navigation to a separate list report containing the full table must be offered.  This navigation should be located below the table in the form of a right-aligned link labelled Show All (x), with x representing the total amount of items in the table.

In the object page, we recommend that you do not use the analytical, grid and tree tables. Instead, use a responsive table and offer navigation to a list report with the table types mentioned above.

For all of the three options mentioned above, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Grouping should be avoided.

Table with navigation to a separate list report
Table with navigation to a separate list report

Child Page Representation

In object pages with drilldown navigation, child pages are represented in three ways:

  • Visual representation in the header: A narrow blue band is displayed in the left margin of the snapping header.
  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Item navigation arrows: Up and down arrows in the application toolbar allow the user to navigate between subitems without going back to the original list.

Behavior and Interaction

Edit

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create). In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area for edit mode to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see manage objects – create, edit, delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

Object page – Global edit with header container and independent header facets
Object page – Global edit with header container and independent header facets

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit on a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Object page – Partial edit with dialog
Object page – Partial edit with dialog

Create and Edit Subobjects

The following options are available for creating or editing subobjects:

  • Navigation to a subobject page
  • Inline create or inline edit in a table
  • Dialog containing the fields of the object

If the subobject has less than 8 fields, use a dialog or the inline create/edit option (no separate page for the subobject). Exceptions can apply if additional content for the subobject is available but not part of the edit process, or if other apps need to offer deep links to the subobject page.

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:
•Who made the changes
•When the last changes were made

The popover closes when the user clicks or taps the Close icon or anywhere outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, use the placeholder text “New ” (for example, “New Purchase Order”). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Guidelines

Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing a clear context.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.

Tab Navigation

Use tab navigation if you need a facet approach to your content. This could be due to performance issues in a flat view, or in response to a specific user preference. If you need to use icons, tabs as process steps, or tabs as filters, use the object view floorplan.

Not a Content Dump

Avoid using the object page as a universal container for masses of information. You should use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.

Simplify Content for Your Users

Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request. Furthermore, only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Naming Guidelines and Launchpad Shell Bar – Page Title and Navigation Menu.

SAP Fiori Element

Use the table below to see which features are available for the “object page” SAP Fiori element.

Feature Status Comments
Snapping Header
General
Fiori 2.0 merged header Supported
Header always expanded Supported
Header container on/off Supported
Header container on/off in different modes Supported
Header container expand on click Supported
Child page navigation Supported
Subtitle optional Supported
Arrow icon showTitleSelector Not Supported
Breadcrumbs Supported
Favorite behavior Not Supported With indicator next to the title.
Flag behavior Not Supported With indicator next to the title.
Unsaved changes behavior Supported With indicator next to the title.
Lock behavior Supported With indicator next to the title.
Header Facets
Different header facets in different modes Supported
Wrapping behavior for header facets Supported
Image facet square Supported
Image facet round Supported
Image header facet with placeholder Supported
Image header facet in different sizes Supported
Key value facet with unit Supported
Key value header facet with trend Not Supported
Key value facet with same text/numeric size Supported
Microchart header facet Partially supported Currently available for bullet and area charts.
Microchart header facet subtile optional Supported
Microchart header facet footer optional Supported
Microchart header facet with rating indicator Supported
Microchart header facet with progress bar Supported
Form header facet with optional labels Supported
Form header facet with icons as labels Not Supported
Form header facet with links as values Supported
Form header facet value with semantic color Supported
Key value header facet with link as value Supported
Key value header facet with semantic color on value Supported
Plain text header facet Supported
Breakout header facet Not Supported This also includes adding controls to existing header facets.
Toolbar
Header toolbar select, combo box, multi-combo box Not Supported
Header toolbar semantic buttons Supported
Header toolbar highlight buttons Supported
Header toolbar segmented buttons Not Supported
Toolbar overflow Supported
Toolbar overflow prioritization Supported
Icons as buttons Supported
Action sheet in buttons Supported
Prioritization of custom actions in toolbar Supported
Show Edit Header button (partial edit) Not Supported
Navigation
Navigation hidden if object has only one subsection Supported
Counts in anchors and section/subsection headers Not Supported
Carousel overflow for horizontal navigation Supported
Mobile navigation behavior (dropdown) Supported
Navigation overflow overview button Supported
Tab navigation Supported
Tab with anchor subnavigation Not Supported
Anchor behavior Supported
Content
General
Partial edit Not Supported
Forms in content Supported For more on the form features, see the forms article.
Actions in forms Partially Supported Currently only via breakout. Actions go into the subsection toolbar.
Timeline in content Not Supported
Carousel in content Not Supported
Contact cards in content Partially Supported
Mixed content Supported
Block controls Not Supported
Lazy loading Work in Progress
Side panel Not Supported
Scroll to specific section on loading Not Supported
Layout
Content layout in size S (1 column) Supported
Content layout in size M (2 columns) Supported
Content layout in size L (3 columns) Supported
Content layout in size L (2 columns) – optional layout Not Supported
Content layout in size XL (4 columns) Supported
Sections and Subsections
Toolbar in subsections Not Supported
Toolbar in sections Not Supported
Toolbar in sections containing only one subsection Not Supported
Subsection toolbar with custom actions Not Supported
Subsection toolbar with buttons Not Supported
Subsection toolbar with highlighted buttons Not Supported
Subsection toolbar with semantic buttons Not Supported
Subsection toolbar with segmented buttons Not Supported
Subsection toolbar with select combo box or multi-combo box Not Supported
Subsection toolbar with buttons with actions sheets Not Supported
Use of priorities in sections/subsections Not Supported
Tables
Responsive list in content Not Supported
Responsive table in content Supported For specific table features, see the guidelines for tables.
Grid table in content Supported For specific table features, see the guidelines for tables.
Display responsive table instead of grid table on mobile devices Supported For specific table features, see the guidelines for tables.
Analytical table in content Supported For specific table features, see the guidelines for tables.
Display responsive table instead of analytical table on mobile devices  Supported For specific table features, see the guidelines for tables.
Tree table in content Not Supported

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


Overview Page (SAP Fiori Element)

View, Filter, and Take Immediate Action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page.

The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

At a Glance

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Micro actions let users react on the spot

Overview page – Fixed card layout
Overview page – Fixed card layout

Usage

Use the overview page if:

  • You want to provide an entry-level view of content related to a specific domain or role.
  • Users needs to filter and react to information from at least two different applications to complete their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page.
  • You plan to have at least three cards. These cards should not all be of the same type.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page instead.
  • You want to show information about one object only. In this case, use the object page instead.
  • You just represent one application and less than three cards. In this case, use the object page instead.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

As you can see in the picture, the overall content scope (shown in gray) becomes more focused with each interaction step. An overview page brings together information from different sources that support a specific task or information need. Only provide an overview app for a role if it makes sense to do so.

If a role or user has several main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, with information for managing team performance reviews. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that the user is responsible for in the role of quality manager.

Metaphor – Different entry points in SAP Fiori
Metaphor – Different entry points in SAP Fiori

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps. In addition, users can also access the navigation menu in the shell bar, which allows fast and easy navigation to other apps. The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window.

In the screen flow, always position the overview page app between the SAP Fiori launchpad home page and the SAP Fiori app. The overview page doesn’t replace the SAP Fiori launchpad home page. Never start overview page apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Usually, several floorplans can be combined in one app. The overview page floorplan is an exception.
Usually, several floorplans can be combined in one app. The overview page floorplan is an exception.

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards.

The card layout determines the size and position of the cards.
Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

The overview page can consume four different variants of the dynamic page. These variants support different user needs and provide flexibility for application designers. None of the variants include the footer toolbar.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar. In addition, the variant management control lets users share user-defined variants (Save View feature).

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. The initial default uses the collapsed mode, because content is already available on the cards, and users can start right away. When the user scrolls or clicks, the header content expands as defined. The header title offers the Share menu, which enables the actions „Send Email“ and „Save as Tile“.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 (default) – Collapsed mode for size XL/L/M
Dynamic page variant 1 (default) – Collapsed mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Collapsed mode for size S
Dynamic page variant 1 – Collapsed mode for size S
Share menu
Share menu

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text (“Header Title” in the example below). This text serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size S
Dynamic page variant 2 – Expanded/collapsed mode for size S

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size S
Dynamic page variant 3 – Size S

Variant 4 – Text in the Header Title and Smart Filter Bar

In this variant, the header title contains a text (“Header Title” in the example below), and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Collapsed mode for size XL/L/M
Dynamic page variant 4 – Collapsed mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Collapsed mode for size S
Dynamic page variant 4 – Collapsed mode for size S

Overview Page Layout

The fixed card layout describes the position, size, and characteristics of cards in the content area below the dynamic page header. The layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes.

Only place cards on the overview page. Never add tiles.

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the Me Area under Manage Cards. A dialog appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Each overview page app has its own Manage Cards setting. Users who work with several overview pages can personalize the cards shown for each one.

Overview page – 'Manage Cards' dialog
Overview page – 'Manage Cards' dialog
Overview page – 'Manage cards' dialog after initial loading
Overview page – 'Manage cards' dialog after initial loading

Cards

Overview page – Variety of different card types (extract)
Overview page – Variety of different card types (extract)

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. The overview page can contain several cards that reference the same (parent) application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Cards can display different types of content. They can show a chart, a list, a table, informative text, or a combination of two elements.  However, cards never have editable fields.

When designing cards, make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

For more information about cards and card types, see the dedicated articles:

Best Practices

Before you start designing an overview page, familiarize yourself with following best practices to optimize the user experience. They reflect the basic findings of multiple usability tests across different scenarios and user groups.

  • Make a conscious decision on the number of cards: Show only cards that really support the specific role context or task.
  • Accentuate the most important information: Semantic colors in texts, charts, and images attract more attention.
  • Offer a well-balanced mixture of card types: Diversity makes it easy to recognize, select, and read information.
  • Define a deliberate card order: Users assume that cards at the top of the page are more important than others.
  • Group similar topics: Users assume that related cards will be shown next to each other.
  • Choose easy-to-read and actionable texts: If the user needs to take action, use the active voice (for example “Reorder Soon” when stocks are running low).
  • Be semantically consistent: Users expect crucial terms like „urgent“ or “out of stock” to be highlighted with semantic colors.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

Overview Page – List Card

Lists with Different Flavors

List cards display a set of items or links in a list format. The overview page supports three types of list card: list card, bar chart list card, and link list card.  You can also icons and images. For general information on cards, see Cards.

List Card

Overview page – List cards
Overview page – List cards

List cards are a type of object group card, and display a set of items in a vertical list. List cards use the sap.m.List container in the content area.

Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set. The counter indicates how many items are showing on the card in relation to the total number of relevant items: [Items on Card] of [Total Items], as in 5 of 40.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application. Only aggregate list items in exceptional cases.

Because the header area and line items are based on the same result set, they must always link to the same target application. You can also integrate a view switch inside the content area of a card.

List Item Types

Two different list item types are available:

  • The standard list item always shows 3 pieces of information and inherits the properties of the SAPUI5 control sap.m.StandardListItem.
    You can also show an (optional) icon or image on the left.
  • The extended list item can show up to 6 pieces of information and inherits the properties of the SAPUI5 control sap.m.ObjectListItem.

In addition, you can display the data on the right-hand side in semantic colors.

You can only use one type of list item on any given card.

Standard list item
Standard list item
Extended list item
Extended list item

Size of a List Card

The height of list cards can vary, depending on the number of text fields. Show no more than five standard list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Bar Chart List Card

Overview page – Bar chart list cards
Overview page – Bar chart list cards

Bar chart list cards are a type of object group card, and display a set of items in a vertical list. Unlike list cards, bar chart list cards are embedded in another component: the comparison micro chart. This allows you to display negative values and use semantic colors.

Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set. The counter indicates how many items are showing on the card in relation to the total number of relevant items: [Items on Card] of [Total Items], as in 5 of 35.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application. Only aggregate list items in exceptional cases.

Because the header area and line items are based on the same result set, they must always link to the same target application. You can also integrate a view switch inside the content area of a card.

Bar Chart List Item Types

Three different list item types are available:

  • The standard list item always shows 3 pieces of information.
  • The condensed list item can show up to 4 pieces of information.
  • The extended list item can show up to 6 pieces of information.

You can only use one type of list item on any given card.

Standard list item
Standard list item
Condensed list item
Condensed list item
Extended list item
Extended list item

Size of a Bar Chart List Card

The height can vary, depending on the number of text fields. Show no more than five standard/condensed list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Link List Card

Link list cards allow you to display a collection of links or images that can reference both internal and external targets. Links and images are handled as two separate variants: list and image.

Variant Type: List

Overview page – Link list cards (list variant)
Overview page – Link list cards (list variant)

The list variant shows a collection of links that can navigate to a target or open a popover with additional information. You can also show an optional subtitle below the link with a description or additional information. The link text and subtitle are each limited to one line.

You can display an icon or image before each link. For example, you might want to include app icons for set of links to recently-used apps, or images for a list of recent contacts. Use icons and images consistently:

  • If you opt to use icons, show an icon before every link.
  • If you include images, use a placeholder for images that are not available.

Variant Type: Image

The image variant uses the sap.m.Carousel control to display one or more images. If the carousel contains only one image, the Previous and Next icons and the paging indicator are not visible. The link and an optional subtitle are displayed above the carousel. The link text and subtitle are each limited to one line.

Overview page - Link list card (image variant)
Overview page - Link list card (image variant)

Size of a Link List Card

Link list cards with the variant type “list” can have a maximum of 6 links. There is no maximum limit for cards the variant type “image”.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Overview Page (SAP Fiori Element)

View, Filter, and Take Immediate Action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page.

The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

At a Glance

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Micro actions let users react on the spot

Overview page – Fixed card layout
Overview page – Fixed card layout

Usage

Use the overview page if:

  • You want to provide an entry-level view of content related to a specific domain or role.
  • Users needs to filter and react to information from at least two different applications to complete their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page.
  • You plan to have at least three cards. These cards should not all be of the same type.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page instead.
  • You want to show information about one object only. In this case, use the object page instead.
  • You just represent one application and less than three cards. In this case, use the object page instead.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

As you can see in the picture, the overall content scope (shown in gray) becomes more focused with each interaction step. An overview page brings together information from different sources that support a specific task or information need. Only provide an overview app for a role if it makes sense to do so.

If a role or user has several main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, with information for managing team performance reviews. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that the user is responsible for in the role of quality manager.

Metaphor – Different entry points in SAP Fiori
Metaphor – Different entry points in SAP Fiori

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps. In addition, users can also access the navigation menu in the shell bar, which allows fast and easy navigation to other apps. The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window.

In the screen flow, always position the overview page app between the SAP Fiori launchpad home page and the SAP Fiori app. The overview page doesn’t replace the SAP Fiori launchpad home page. Never start overview page apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Usually, several floorplans can be combined in one app. The overview page floorplan is an exception.
Usually, several floorplans can be combined in one app. The overview page floorplan is an exception.

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards.

The card layout determines the size and position of the cards.
Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

The overview page can consume four different variants of the dynamic page. These variants support different user needs and provide flexibility for application designers. None of the variants include the footer toolbar.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar. In addition, the variant management control lets users share user-defined variants (Save View feature).

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. The initial default uses the collapsed mode, because content is already available on the cards, and users can start right away. When the user scrolls or clicks, the header content expands as defined. The header title offers the Share menu, which enables the actions „Send Email“ and „Save as Tile“.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 (default) – Collapsed mode for size XL/L/M
Dynamic page variant 1 (default) – Collapsed mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Collapsed mode for size S
Dynamic page variant 1 – Collapsed mode for size S
Share menu
Share menu

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text (“Header Title” in the example below). This text serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size XL/L/M
Dynamic page variant 2 – Expanded/collapsed mode for size S
Dynamic page variant 2 – Expanded/collapsed mode for size S

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size S
Dynamic page variant 3 – Size S

Variant 4 – Text in the Header Title and Smart Filter Bar

In this variant, the header title contains a text (“Header Title” in the example below), and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Collapsed mode for size XL/L/M
Dynamic page variant 4 – Collapsed mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Collapsed mode for size S
Dynamic page variant 4 – Collapsed mode for size S

Overview Page Layout

The fixed card layout describes the position, size, and characteristics of cards in the content area below the dynamic page header. The layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes.

Only place cards on the overview page. Never add tiles.

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the Me Area under Manage Cards. A dialog appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Each overview page app has its own Manage Cards setting. Users who work with several overview pages can personalize the cards shown for each one.

Overview page – 'Manage Cards' dialog
Overview page – 'Manage Cards' dialog
Overview page – 'Manage cards' dialog after initial loading
Overview page – 'Manage cards' dialog after initial loading

Cards

Overview page – Variety of different card types (extract)
Overview page – Variety of different card types (extract)

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. The overview page can contain several cards that reference the same (parent) application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Cards can display different types of content. They can show a chart, a list, a table, informative text, or a combination of two elements.  However, cards never have editable fields.

When designing cards, make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

For more information about cards and card types, see the dedicated articles:

Best Practices

Before you start designing an overview page, familiarize yourself with following best practices to optimize the user experience. They reflect the basic findings of multiple usability tests across different scenarios and user groups.

  • Make a conscious decision on the number of cards: Show only cards that really support the specific role context or task.
  • Accentuate the most important information: Semantic colors in texts, charts, and images attract more attention.
  • Offer a well-balanced mixture of card types: Diversity makes it easy to recognize, select, and read information.
  • Define a deliberate card order: Users assume that cards at the top of the page are more important than others.
  • Group similar topics: Users assume that related cards will be shown next to each other.
  • Choose easy-to-read and actionable texts: If the user needs to take action, use the active voice (for example “Reorder Soon” when stocks are running low).
  • Be semantically consistent: Users expect crucial terms like „urgent“ or “out of stock” to be highlighted with semantic colors.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

Overview Page – Resizable Card Layout

Unlimited Possibilities for Designing Cards 

The resizable card layout is a layout for the overview page. It enables users to define a personalized card layout by changing not only the position of a card, but also its size, and thus how the card content is presented.

This layout gives users much greater flexibility in tailoring the overview page to their specific business needs. And it allows app teams to offer varying levels of detail for any given card. Whenever the size of a card changes, the content adapts automatically to show the most relevant information in the available space.

At a Glance

  • Flexible card dimensions (grid-based)
  • More flexibility to define individual card layouts
  • Responsive and adaptive card content
  • Applying progressive disclosure principles
Overview page - Resizable card layout
Overview page - Resizable card layout

Unlike the fixed card layout, cards in the resizable card layout do not have fixed dimensions. In addition, the number of columns in the resizable layout is no longer limited (also see letterboxing).

The cards are positioned on an underlying grid, making it possible to arrange and resize cards in a flexible, yet guided manner. You can offer different views of the card content for different dimensions of the various card types. For example, you can show more items, zoom in or out, or change the granularity of a dataset.

The resizable card layout does not replace the fixed card layout.

Usage

Use the resizable card layout if:

  • You want to give users the flexibility to rearrange and adapt their overview page as they need.
  • You want to help users focus by applying progressive disclosure principles.
  • You want to make use of different card sizes.
  • You want to show more content (for example, more items or an additional level of detail)

Do not use the resizable card layout if:

  • Your card content doesn’t react properly to a change in size. Use the fixed card layout instead.
  • You are not able to invest UX and development resources for creating and prioritizing additional content. Use the fixed card layout instead.
  • You want to use the resizing functionality on mobile devices. Resizing and rearranging cards is currently not possible on mobile devices.

Flexible Card Sizes

Grid

Cards can be increased and decreased vertically in rows of 1 rem and horizontally in steps of 20 rem. These dimensions facilitate both a high degree of flexibility and measured guidance. The card content responds immediately to a change in size.

The grid provides a guided resizing and repositioning experience. This ensures that the cards are always correctly aligned on the overview page as the user moves or resizes them.

Resizable card layout – Grid
Resizable card layout – Grid

Card Anatomy

A card is made up of a mandatory header and a content area.

Mini Header

The smallest representation of the card is the header. The card can be collapsed to only its header height. We call this the “mini header” card height.

Mini Content

The “mini content” height of a card is defined by the next suitable size for a card when it is resized. The minimum height for the card content depends on the card type, and must be as high as the smallest representation of the content. In a list card, for example, first list item needs to fit in.

To avoid states with cut or unsubstantial content, there are no resizing steps between mini header and mini content.

Card anatomy
Card anatomy
Minimum heights for a card in the resizable card layout
Minimum heights for a card in the resizable card layout

Examples of Card Sizes

Dealing with White Space

If no additional content is available, the user still can make the card bigger, resulting in white space.

Resizing Parameters

The card content depends on the available space, which in turn determines how many items are shown, how each item is displayed, and the level of detail (granularity). How the content is resized depends on the type of card. For example, table cards can have fewer columns when the size of the card is decreased. By contrast, the content shown for each item on list cards remains the same.

Space

When a card is resized, the content adapts responsively. 

Example: List card
When the size of a card is reduced, texts might be truncated or wrapped. When the card size is increased again, the text is shown in full and previously wrapped text moves back onto one line. The line item content itself is unchanged.

Resizing for a list card
Resizing for a list card

Items

When you increase the size of a list or table card, more line items are shown.

Resizing for a table card
Resizing for a table card

Granularity

If you increase the size of an analytical card, more data points are revealed. In this example, the donut chart on the larger card shows more individual product categories.

Resizing for an analytical card (donut chart)
Resizing for an analytical card (donut chart)

Rearranging Cards – Behavior

When a user long presses on a card instead of just clicking, the mouse cursor changes to indicate that the card can be dragged. Cards can be dragged from both the header and content areas. 

Cards always strive towards the top of the page (uplift mode). When you move or stretch cards horizontally, the existing cards you displace are pushed downwards.

Resizing cards / rearranging cards using drag and drop
Resizing cards / rearranging cards using drag and drop

Getting Started

UX and DEV Investment Required

To enable users to benefit fully from the resizable card functionality, you need to define additional content that is revealed progressively as the card size grows. You will need to develop a content strategy to prioritize the chunks of information for each card type, and hence the order in which these additional chunks of information appear. For instance, the content strategy for a table card should answer the following questions:

  • What should be the initial size of the card in the layout?
  • Which table columns do you want to show in the card with the minimum width?
  • Which table columns do you want to add when the card width is increased by one, two, three, … horizontal steps?

Keep in mind that the overview page is an SAP Fiori element.

Developer Hint
If you want to enable the resizable card layout for an existing overview page with the fixed card layout, consider the investment you’ll need to make in additional and meaningful content.

Set Initial Card Sizes

Set an initial order and initial dimensions for each card as a default. Do this for the mini header, the mini content, and for bigger card sizes. In cards with content, define the exact number of items included in the content area.

Consider the best practices for designing an overview page and the principles for resizing the cards. It’s important to provide a meaningful starting point for users. If users change the card size or order, the initial app default can always be restored using the Manage Cards setting in the Me Area.

Important: Do not provide only mini headers in the initial layout for your overview page.

Block Card Resizing

App teams can block the resize feature for each card individually. In this case, the cards can’t be resized by users and the resize icon is not shown on the card. Use this feature judiciously and only if you really have to. The majority of cards should be resizable. Otherwise, users are likely to be confused, and might feel driven to check the resizing behavior for each card.

Alternative approach

If you want to make use of the different card sizes, but don’t want to allow resizing for users at all, you can block the resizing function for all cards (independently of the initial card size). This allows you to use different card sizes and the same (limited) personalization features as in the fixed card layout. Because none of the cards are resizable, users won’t be confused.

Letterboxing

The resizable card layout uses different letterboxing behavior than the fixed card layout: to handle different card sizes more flexibly, the resizable card layout does not have a fixed number of columns. Cards take up the the available screen real estate and adapt accordingly (also see responsiveness). As a result, larger screens can be almost completely filled.

Responsiveness

Information
Resizing is not supported on mobile devices. However, users can resize cards freely in smaller windows on a desktop device.

UI controls inside the cards react responsively when cards are resized. On mouse-release, additional content might be loaded, or content might be removed to reflect the new dimensions.

The number of grid columns in the layout is dependent on the width of the browser window. The breakpoints are defined as follows:

Width of Browser Window Number of Card Columns Displayed
Less than 656 px 1 column
656 – 975 px 2 columns
976 – 1359 px 3 columns
1360 – 1679 px 4 columns
1680 – 1999 px 5 columns
More than 2000 px 6 columns or more

There is no limitation to the number of columns. You can also design for bigger screens.

Resizable card layout – Size L
Resizable card layout – Size L
Resizable card layout – Size M
Resizable card layout – Size M
Resizable card layout – Size S
Resizable card layout – Size S

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Overview Page – Card

Cards – Harmonized and Powerful Information

Each task or topic on an overview page is represented by a card. The overview page acts as a UI framework for organizing multiple cards for one role on a single page .

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. Technically, a card is a smart component that uses UI annotations to render its content. Cards allow you to show application content from different sources side by side – without requiring the user to switch screens. Cards differ in the content they display: They can show a chart, a list, a table, informative text, or a combination of two elements. However, cards never have editable fields.

Cards can focus on a single object or topic, or on a group of objects. 

The overview page can contain several cards that reference the same (parent) application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Before you start designing cards for an overview page, see the best practices.

At a Glance

  • Cards are small previews of application content.
  • Each card represents a specific topic, task, or perspective.
  • Cards help users to focus by applying progressive disclosure principles.
  • Cards are powerful and beautiful.
  • Cards offer a variety of visualizations.
Overview page with different card types (extract)
Overview page with different card types (extract)

Card Anatomy

Each card comprises two components: a header area and a content area. The header and content areas are mandatory. A footer area is only used for actions in the quick view card.

The interactive navigation in the header and content areas is represented by a hover effect.

When designing cards, make sure that you define and format the texts on all the cards consistently. For details , check out the UI text guidelines for the overview page.

Card anatomy
Card anatomy
Hover effect on cards
Hover effect on cards

Card Header

The card header area is mandatory, and serves three purposes:

  • It indicates what the card is about.
  • It functions as a navigation area for opening the parent app, whereby the whole header area is clickable. We highly recommend offering this navigation to enable users to move seamlessly to the app details without losing focus on the task in hand  (exception: link list card). 
  • A counter shows how many items are on the card in relation to the total number of relevant items.

The height of the header area is variable; it expands vertically to accommodate the text. The header area can contain two text fields: a mandatory title, and an optional subtitle. The primary purpose of the header area is to identify the content source, summarize the focus of the card (title), show any relevant parameters (subtitle), and offer navigation to the content source (parent app).

Title

The title is mandatory and represents the card’s “point of view”. In one or two words, it explains why this card exists and why a user might want to use it. It is a natural language reflection of the annotated view. Titles that exceed three lines are truncated with the ellipsis (…).

Subtitle

The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The use of the subtitle can differ, depending on the card type. Subtitles that exceed one line are truncated with the ellipsis (…).

Card header with counter
Card header with counter

Counter

The counter in the header area indicates how many items are showing on the card in relation to the total number of relevant items:

Format: [Items on Card] of [Total Items]
Example: 5 of 40 

The counter is right-aligned and is never truncated (the title wraps instead). The width of the counter is flexible, depending on the amount of data. [Items on Card] can show a maximum three digits, and [Total Items] a maximum of four digits. For larger numbers, a scaling factor is shown. If all the relevant items are visible on the card, no counter is shown. There is also no counter if there is an issue loading a card, or no items are found for the filter criteria.

Card counter in different cases
Card counter in different cases

Card Content

The content area is mandatory and is reserved for application content. Content is currently displayed on cards by embedding SAPUI5 controls that specify the properties and data format. For example, an embedded standard list control provides formatting, such as row height, font sizes, and the number of text blocks.

Card Types

The overview page supports the following standard card types:

Appearance

Texts in Cards

Make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

Formatting Dates, Times, Amounts, and Currencies

Apply the following formats:

  • Dates: The default is the relative date format (for example, Today). However, you can also use the medium date format (such as Aug 7, 2015).
  • Times: Times are not visible by default, but if you need to show a time, use the short format (for example, 11:28 AM).
  • Integers/Float/Currencies: Use the short format (for example, 1K for 1000).

Refresh Behavior

You can set a specific refresh interval for the card content. All cards are refreshed at once.

Keep the user in mind: the shorter the refresh interval, the more disruptive it is for users.

Navigation and Interaction

The navigation and interaction depends on the technical card type:

The view switch enables you to reduce the number of similar cards and avoid repeating information.

Single-Object Cards

Cards that feature content with a single focal point, detail, or entity are called single-object cards. An example is a quick view card with information about a particular product. Analytical cards are also single-object cards. The header area of this card type always navigates to this specific focal point, detail, or entity. The content area can also have interaction areas (for example, a section in a chart, or a telephone number for a contact). However, only quick view cards can have actions in the footer area.

Interaction for a single-object card
Interaction for a single-object card

Object Group Cards

Cards that feature a subset of items grouped by a common criterion are called object group cards. A typical example would be a list of purchase orders grouped by delivery date, amount, or supplier. The cards do not have actions, but each row or list item is selectable, thus providing direct navigation to the object details within the parent application. The header area of this card type always navigates to all items in the list or table. Object group cards include all types of list cards, bar chart list cards, and table cards.

Interaction for an object group card
Interaction for an object group card

Link List Cards

Link list cards allow you to display a collection of links or images that can reference both internal and external targets.

  • Links can navigate to a target or open a popover with additional information.
  • Clicking an image opens an image carousel.
Interaction for a link list card
Interaction for a link list card

Stack Cards

A stack card is a special card type for showing a collection of single-object cards. Stack cards have 3 components with different navigation areas:

  • The top-level stack card opens the collection and contains two clickable areas: the left area navigates to the parent app (with the list of all items), and the right area opens the object stream.
  • The object stream shows individual cards that represent objects from the parent application. The object stream heading links to the parent application, while individual cards can contain links and actions relating to the respective object. A Close button returns the user to the stack card.
  • The last card in the object stream is the placeholder card. The entire card is navigable and leads the user directly to the parent application.
Interaction for a stack card
Interaction for a stack card
Interaction for a placeholder card
Interaction for a placeholder card

View Switch

You can use a view switch to offer several different content areas on one card, which can help to reduce the number of cards on the overview page. The user chooses the view using a select control. You can only combine views that have a common denominator. The options offered by the select control merely offer different perspectives. For example, a card “Purchasing Spend” (title in the header area) could offer two views “By Material Group” and “By Supplier” (options in the select control). The view switch is located in the upper part of the content area.

You can use the view switch for the following cards:

View switch
View switch

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

  • No links

Overview Page – Table Card

Table cards are a type of object group card, and display a set of items in a table format. Table cards use the responsive SAPUI5 control sap.m.Table. For general information on cards, see Cards.

Overview page – Table cards
Overview page – Table cards

Navigation

Clicking the header area of a table card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set. The counter indicates how many items are showing on the card in relation to the total number of relevant items: [Items on Card] of [Total Items], as in 3 of 10.

Clicking a list item (row) on the card opens the detail view for that specific object in the same parent application. You can also use the smart link control in table cards. However, only use smart links if they add genuine value in your use case. Otherwise, you risk confusing users by offering too many navigation targets.

All three columns can show either a data field or a data point. Data points can use semantic colors.

Because the header area and line items are based on the same result set, they must always link to the same target application. You can also integrate a view switch inside the content area of a card.

Size of a Table Card

The height can vary depending on the number of table cells. Tables are limited to a maximum of 3 columns and 3 rows, with a maximum of 3 lines of text per row. To see the full result set, the user needs to navigate to the parent app.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

List Report (Floorplan + SAP Fiori Element)

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

The list report floorplan can be implemented in two ways:

  • Using the corresponding SAPUI5 controls in a dynamic page layout. This gives you much greater flexibility, but at the expense of more development time.
  • Using the SAP Fiori element for the list report. This generates the floorplan from OData annotations, which brings down development time. However, the SAP Fiori element list report is restricted to the most common features. Details on the SAP Fiori element for the list report are included at the end of each section.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items within a large set of items by searching, filtering, sorting, and grouping.
  • Users need to display the whole dataset using different visualizations (for example, as a table and a chart), without requiring interactions between these visualizations. An example use case might be reporting.
    Please note that this feature only applies to the freestyle list report floorplan, and not to the list report SAP Fiori element.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. Views can be switched using tabs, segmented buttons, or a select.
  • Drilldown is rarely or never used, or is only available via navigation to another page, and not as free or flexible drilldown within the page itself.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (for example, if a barcode scanner is used to identify the item). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the work list floorplan instead.
  • Users need a way to analyze data step by step from different perspectives and to investigate and act on a root cause by drilling down to transactional content within one page. Use the analytical list page instead.
  • Charts are not only used for visualization, but users need to interact between charts and table views. Use the analytical list page instead.
  • Users need to see the impact of their action on a KPI. Use the analytical list page instead.
  • Users need to see not only the result, but also the impact of their filter settings directly in a chart representation. Use the analytical list page instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a charts, they can be displayed exclusively (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.

SAP Fiori Element List Report

The SAP Fiori element list report does not support:

Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

SAP Fiori Element List Report

The SAP Fiori element list report automatically replaces grid tables and analytical tables with responsive tables on smartphones.
For tree tables, there is no meaningful fallback solution for smartphones.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Header Title

Variant Management

Variant management is optional. If used, apply it to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before executing. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the following format: Filtered By (x):, followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use this for non-finalizing global actions such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

SAP Fiori Element List Report

If variant management is not used, a default title repeats the text from the shell bar. Use this text only if there is no better alternative. In any other case, replace the title with one that better describes the current view.

In the header toolbar, only Share is supported. There is no possibility to add app-specific actions.

By default, the variant management control saves the filter settings only. Change this setting to also save the table layout settings (manifest.json: smartVariantManagement).

Be aware that the SAP Fiori element list report does not support charts in the content area.

Header Content

The header content collapses when scrolling down the page (with responsive table, list, or tree only), and expands again when scrolling back up. To avoid this automatic expand/collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.
Users can also expand and collapse the header content by clicking the background of the title bar.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title.

When starting the application, expand the header content if no query was fired (and the table is therefore empty). In other cases, collapse the header content.

Header Content - Expand / Collapse Behavior

  • List Report (Floorplan + SAP Fiori Element) Header Expanded - 1.48
  • List Report (Floorplan + SAP Fiori Element) Header Collapsed - 1.48

Filter Bar

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search and filter criteria.

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

SAP Fiori Element List Report

The pin setting for the header content is not persisted.

In manual update mode, the content is grayed out whenever the user changes a filter after pressing Go, even if the change is reverted.
Within the smart filter bar, app-specific filters are also possible. Apart from the combo box, select, input field (with or without value help), date picker, and search field, you can also deploy other controls by using breakout options, such as the rating indicator (SmartFilterBar, annotation: UI.SelectionFields).

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. A view consists of one or more of the following:

  • Displaying different columns of the same table
  • Displaying the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

There are two options for switching between different views:

The first option is to replace the table title with a content switch. Use this approach if all views share the same sort and group states, as well as the same actions.

The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country, View by Customer, …)

The second option for switching views is to show each view in a tab container of the icon tab bar. Use this approach if all views show different states of the same data (sort states, group states, as well as item selection). Using tabs also allows you to offer different actions on the table toolbar for each view.

Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no or only non-fitting items are selected. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions
Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are not items to display, use the “no data text” of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    No filters set. To start, enter your search and filter settings and run the search.
  • The filter was executed, but no items were found:
    No items found. Try adjusting your search and filter settings.
  • By opening a related app, the filter criteria were transferred automatically, but no items were found:
    No items found. Check the search and filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid, analytical, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is used for a different target.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer toolbar
Footer toolbar

SAP Fiori Element List Report

The SAP Fiori element list report supports only simple content and multiple views (manifest.json: quickVariantSelection or quickVariantSelectionX). Multiple content is not supported. If you use tabs with multiple views, the counters for tabs are turned off by default. Turn them on, unless this causes performance problems (manifest.json: showCounts).

Only smart tables are supported. Since charts cannot be displayed, no view switch is needed.

The table toolbar supports:

  • Table title (annotation: UI.HeaderInfo, property: TypeNamePlural)
  • Item count: Turned on by default.
  • Variant management for the table layout: Although it is turned on by default, it should not be used in most cases. If the layout variant is turned off, the table layouts are stored together with the page variant (manifest.json: smartVariantManagement).
  • Several standard and custom actions (see below)

Actions cannot be grouped using a menu button on the table toolbar.

Within the SAP Fiori element list report, you can use the responsive table, grid table, analytical table, or tree table within the smart table.

The smart table supports:

  • No selection, single selection, or multiple selection (manifest.json: multiSelect). With multiple selection, the SAP Fiori element list report triggers the action for all selected items. If an error occurs with one or more of the selected items, it can be handled in the following ways (annotation: OperationGroupingType):
    • Partial processing: A message is displayed for the items with issues. All other items are processed. The message displayed is generic and must be replaced.
    • Roll-back: A message is displayed. All items are reverted. The message displayed is generic and must be replaced.
  • Text control in line items
  • Rating indicator within line items (annotation: UI.DataPoint)
  • Progress indicator within line items (annotation: UI.DataPoint)
  • Indicator for the editing status within the rows (for example Draft or Locked by [user]). Users can filter the table by editing status in the filter bar.
  • Line item navigation to different targets (maintain detail pages in manifest.json):
    • Navigation to a related object page within the app (default). Apps can override this behavior and define their own navigation target. The target can also depend on specific conditions defined by the app (maintain detail pages in manifest.json).
    • Cross navigation to another SAP Fiori app or to another system
  • Link and smart link to show details in a quick view or to navigate. A quick view can be used as part of the smart link or for displaying contact details. For navigation, the target can be any web page, another app, or a related object page within the same app.
  • Line item actions as text or icon buttons (such as Approve and Reject).
  • Any control that the corresponding table allows by using breakout columns.

At present, the smart table does not support:

  • The object number control. This is only available if you use a breakout column. Without a breakout, amounts appear as standard text only.

Only the responsive table supports:

  • A column that displays the object identifier, including the object name and ID (annotations: Common.SemanticKey with Common.Text)
  • Images in line items (annotation: UI.IsImageURL)
  • The object status control in line items: Use of a specific status such as Out of Stock in connection with one of the semantic colors and/or a status icon (criticality annotations).
    The object status provides different categories: negative (property: error), critical (property: warning), positive (property: success), and neutral (property: none). When a column is sorted by object status, the SAP Fiori element list report sorts by these categories. If a category has multiple values, ensure that the values within the category are sorted in a meaningful way (for example, alphabetically).
  • A progress indicator in line items (annotation: UI.DataPoint)
  • Smart area micro charts, smart bullet micro charts, and smart radial micro charts in line items (annotation: UI.Chart)
It is not possible to change the alignment of table content.

Because the SAP Fiori element list report does not support editing use cases, the message button is not supported on the footer toolbar.
Actions cannot be grouped using a menu button on the footer toolbar.

Actions

Places for actions in the list report: header toolbar, table toolbar, line item, or footer toolbar
Places for actions in the list report: header toolbar, table toolbar, line item, or footer toolbar

The list report offers four locations for actions: global actions, table actions, line item actions, and finalizing actions.

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no action is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

Hide actions that cannot be used at all (for example, because the user has no authorization). If you are using an icon tab bar, please be aware that each tab contains its own table toolbar.

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

SAP Fiori Element List Report

The table toolbar provides the following built-in actions:

  • Add: An icon button that triggers an object page for creating an item. If this function is not needed, or if you want users to add or create items differently (for example, in a dialog), turn it off. If you use this button, replace the generic tooltip Create Object with a more specific text, such as Create Purchase Order.
    Draft handling is supported (recommended). (annotation: Creatable)
  • Delete: A text button to delete selected items. Delete is enabled as soon as deletable items are selected. If this function is not needed, turn it off. (annotation: Deletable)
  • View Settings (sort, group, column settings): In contrast to the guidelines above, only one button is shown for sort, group, and columns settings. The icon button always opens the p13n-dialog with all features enabled. The less complex view settings dialog cannot be used.
    The SAP Fiori element list report also allows users to add filter settings within the p13n-dialog. This feature is only available if an explicit layout variant is being used for the table, which should not usually be the case. Do not use this feature.
  • In addition, you can add app-specific actions, such as Copy or Approve. These actions are displayed as text buttons. App-specific actions can be enabled or disabled, depending items selected in the table.

There are 3 types of app-specific action:

  • The system simply triggers the action.
  • The action requires user confirmation. Use this for critical actions that have severe consequences. A message box appears, and the user needs to confirm the action. The message displayed is generic and must be replaced (annotation: IsActionCritical).
  • The action needs additional user input, such as an approval comment. The system opens a dialog with one or more user input elements in which the user enters the required data. The system can pre-fill data if applicable (function import with parameters).

App-specific actions can also trigger navigation to another app or to a related object page within the same app. The navigation can depend on zero selected items, or on one selected item.

Actions cannot be grouped using a menu button.

Actions in the smart table toolbar
Actions in the smart table toolbar

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Line item actions are not usually disabled. Hide actions which cannot be used at all (for example, because the user has no authorization, or because the line item is in the “wrong” state).

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information finalizing actions, see the guidelines for the footer toolbar.

SAP Fiori Element

Use the table below to see which features are available for the “list report” SAP Fiori element.

Feature Status Comment
Header Title
Title only (no variant management) Supported
Variant management: Page variant Supported
Variant management: Only for filter settings Supported Not recommended
Filter information Supported
Global actions Not Supported
Generic action: Share Supported
Generic action: Show Filters / Hide Filters (only with grid table, analytical table, and tree table) Supported
Header Content
General
Persisting pin state Not Supported
Filter Bar
Search field Supported
Mandatory fields Supported
Default values Supported
Live update mode Supported
Manual update mode (Go button) Supported Use only in case of performance problems
Any control in the filter bar Supported Via breakout only
Content Area
General Layout
Simple content Supported One table only
Mutiple views: Single toolbar (segmented buttons / select) Supported
Multiple views: One toolbar each (tabs) Supported
Multiple content Not Supported
Tabs
Item counts on tabs Supported
Table Toolbar
Title Supported
Item count Supported
Sort / Filter / Group via View Settings dialog Not Supported Do not show filter settings on the table toolbar
Sort / Filter / Group via P13n dialog Supported Do not show filter settings on the table toolbar
View switch Not Supported
Alternative visualization: Chart view Not Supported
Alternative visualization: Table and chart view Not Supported
Other alternative visualizations Not Supported
Layout variant Supported Not recommended
App-specific actions with partial processing

(In case of errors, display a message for the items with issues. Process all other items.)

 Supported Change the generic message texts
App-specific actions with roll-back

(In case of errors, display a message. All items are reverted.)

 Supported Change the generic message texts
Enable/disable actions, depending on selection Supported
Grouping of actions (menu button) Not Supported
Overflow handling for toolbar Supported
Generic action: Edit Not Supported
Table
Table type: Responsive table Supported
Table type: Grid table Supported
Table type: Analytical table Supported
Table type: Tree table Supported
Table type: List Not Supported
Table type: Tree Not Supported
Selection: Table items are not selectable Supported
Selection: Single selection Supported
Selection: Multi-selection Supported
App-specific column widths (only grid table, analytical table, and tree table) Not Supported
Content: Text Supported
Content: Rating indicator Supported
Content: Progress indicator Supported
Content: Editing status Supported
Content: Actions (text or icon buttons) Supported
Content: Object identifier (responsive table only) Supported
Content: Images (responsive table only) Supported
Content: Object status (responsive table only) Supported
Content: Smart area / bullet / radial micro chart (responsive table only) Supported
Content: Any other content as long as the underlying table allows it Supported Via breakout only
Aligning content within columns Not Supported
Generic “No data” text Supported
Custom “No data” text Not Supported
Navigation: Line Item navigation via navigation indicator (within app, cross-app, any target) Supported
Navigation: Line Item navigation via link with/without quick view (within app, cross-app, any target) Supported
Footer Toolbar
Messaging button and message popover Not Supported
Finalizing actions Supported
Grouping of actions (menu button) Not Supported
 Actions
Global Actions
Generic action: Show Filters / Hide Filters Supported
Generic action: Share (icon button) Supported
App-specific actions Not Supported
Grouping of actions (menu button) Not Supported
Table / Chart Actions
Enable/disable actions depending on the current selection Supported
Grouping of actions (menu button) Not Supported
Generic action: Add (via object page) Supported Draft handling is supported
Generic action: Add (via dialog) Supported Via breakout only
Generic action: Add (via new row) Not Supported
Generic action: Delete Supported
Generic action: Sort (via View Settings dialog) Not Supported
Generic action: Sort (via P13n dialog) Not Supported
Generic action: Filter (via View Settings dialog) Not Supported Do not use filter settings on the table
Generic action: Filter (via P13n dialog) Not Supported Do not use filter settings on the table
Generic action: Group (via View Settings dialog) Not Supported
Generic action: Group (via P13n dialog) Not Supported
Generic action: Column settings (via table personalization dialog) Not Supported
Generic action: Column settings (via P13n dialog) Not Supported
Generic action: View settings – combines sort, filter, group, and column settings (via P13n dialog) Supported Not recommended. If used, turn off filter settings.
Generic action: Export to Spreadsheet Supported
Generic action: Maximize Supported
App-specific actions as text button Supported
App-specific actions as icon-only button Not Supported
App-specific actions with partial processing Supported
App-specific actions with roll-back Supported
App-specific action in emphasized style Supported Use this only for a single action
App-specific action in positive/negative style Supported
App-specific action: Trigger immediately Supported
App-specific action: Needs user confirmation Supported
App-specific action: Needs additional user input Supported
App-specific action: Triggers navigation (within app, cross-app) Supported
App-specific action: Triggers any other behavior Supported Via breakout only
Line Item Actions
App-specific actions as text button Supported
App-specific actions as icon-only button Supported
Generic action: Delete (icon-only button) Not Supported
Finalizing Actions
App-specific actions Supported
Grouping of actions (menu button) Not Supported

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

List Report (Floorplan + SAP Fiori Element)

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

You can implement the list report floorplan in two ways:

  • Use the corresponding SAPUI5 controls in a dynamic page layout. This gives you much greater flexibility, at the expense of more development time.
  • Use the SAP Fiori element for the list report. This generates the floorplan from OData annotations and reduces development time. However, the SAP Fiori element list report will be limited to the most common features. Details on the SAP Fiori element for the list report are included at the end of each section.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items within a large set of items by searching, filtering, sorting, and grouping.
  • Users need to display the whole dataset using different visualizations (for example, as a table and a chart), without requiring interactions between these visualizations. An example use case might be reporting.
    Please note that this feature only applies to the freestyle list report floorplan, and not to the list report SAP Fiori element.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. Views can be switched using tabs, segmented buttons, or a select.
  • Drilldown is rarely or never used, or is only available via navigation to another page, and not as free or flexible drilldown within the page itself.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (for example, if a barcode scanner is used to identify the item). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the work list floorplan instead.
  • Users need a way to analyze data step by step from different perspectives and to investigate and act on a root cause by drilling down to transactional content within one page. Use the analytical list page instead.
  • Charts are not only used for visualization, but users need to interact between charts and table views. Use the analytical list page instead.
  • Users need to see the impact of their action on a KPI. Use the analytical list page instead.
  • Users need to see not only the result, but also the impact of their filter settings directly in a chart representation. Use the analytical list page instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a charts, they can be displayed exclusively (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.

SAP Fiori Element List Report

The SAP Fiori element list report does not support:

Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

SAP Fiori Element List Report

The SAP Fiori element list report automatically replaces grid tables and analytical tables with responsive tables on smartphones.
For tree tables, there is no meaningful fallback solution for smartphones.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Components and Launchpad Shell Bar – Page Title and Navigation Menu.

Header Title

Variant Management

Variant management is optional. If used, apply it to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before executing. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the following format: Filtered By (x):, followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use this for non-finalizing global actions such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

SAP Fiori Element List Report

If variant management is not used, a default title repeats the text from the shell bar. Use this text only if there is no better alternative. In any other case, replace the title with one that better describes the current view.

In the header toolbar, Share and Show Filters / Hide Filters are supported as standard actions. App-specific actions can be added using a breakout.

By default, the variant management control saves the filter settings only. Change this setting to also save the table layout settings (manifest.json: smartVariantManagement).

Be aware that the SAP Fiori element list report does not support charts in the content area.

Header Content

The header content collapses when scrolling down the page (with responsive table, list, or tree only), and expands again when scrolling back up. To avoid this automatic expand / collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.
Users can also expand and collapse the header content by clicking the background of the title bar.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title.

When starting the application, expand the header content if no query was fired (and therefore the table is empty). Collapse the header content in other cases.

Header Content - Expand / Collapse Behavior

  • List Report (Floorplan + SAP Fiori Element) Header Expanded - 1.48
  • List Report (Floorplan + SAP Fiori Element) Header Collapsed - 1.48

Filter Bar

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search and filter criteria.

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

SAP Fiori Element List Report

The pin setting for the header content is not persisted.

In manual update mode, the content is grayed out whenever the user changes a filter after pressing Go, even if the change is reverted.
Within the smart filter bar, app-specific filters are also possible. Apart from the combo box, select, input field (with or without value help), date picker, and search field, you can also deploy other controls by using breakout options, such as the rating indicator (SmartFilterBar, annotation: UI.SelectionFields).

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. A view consists of one or more of the following:

  • Displaying different columns of the same table
  • Displaying the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

There are two options for switching between different views:

The first option is to replace the table title with a content switch. Use this approach if all views share the same sort and group states, as well as the same actions.

The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country, View by Customer, …)

The second option for switching views is to show each view in a tab container of the icon tab bar. Use this approach if all views show different states of the same data (sort states, group states, as well as item selection). Using tabs also allows you to offer different actions on the table toolbar for each view.

Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no or only non-fitting items are selected. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions
Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are no items to display, use the “no data text” of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    No filters set. To start, enter your search and filter settings and run the search.
  • The filter was executed, but no items were found:
    No items found. Try adjusting your search and filter settings.
  • By opening a related app, the filter criteria were transferred automatically, but no items were found:
    No items found. Check the search and filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid, analytical, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is used for a different target.
    Only show navigation indicators for target pages the user is authorized to access.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer toolbar
Footer toolbar

SAP Fiori Element List Report

The SAP Fiori element list report supports only simple content and multiple views (manifest.json: quickVariantSelection or quickVariantSelectionX). Multiple content is not supported. If you use tabs with multiple views, the counters for tabs are turned off by default. Turn them on, unless this causes performance problems (manifest.json: showCounts).

Only smart tables are supported. Since charts cannot be displayed, no view switch is needed.

The table toolbar supports:

  • Table title (annotation: UI.HeaderInfo, property: TypeNamePlural)
  • Item count: Turned on by default.
  • Variant management for the table layout: Although it is turned on by default, it should not be used in most cases. If the layout variant is turned off, the table layouts are stored together with the page variant (manifest.json: smartVariantManagement).
  • Several standard and custom actions (see below)
Actions cannot be grouped using a menu button on the table toolbar.

Within the SAP Fiori element list report, you can use the responsive table, grid table, analytical table, or tree table within the smart table (manifest.json: tableType).

The smart table supports:

  • No selection, single selection, or multiple selection (manifest.json: multiSelect). With multiple selection, the SAP Fiori element list report triggers the action for all selected items. If an error occurs with one or more of the selected items, it can be handled in the following ways (annotation: OperationGroupingType):
    • Partial processing: A message is displayed for the items with issues. All other items are processed. The message displayed is generic and must be replaced.
    • Roll-back: A message is displayed. All items are reverted. The message displayed is generic and must be replaced.
  • Text control in line items
  • Rating indicator within line items (annotation: UI.DataPoint)
  • Progress indicator within line items (annotation: UI.DataPoint)
  • Indicator for the editing status within the rows (for example Draft or Locked by [user]). Users can filter the table by editing status in the filter bar.
  • Line item navigation to different targets (maintain detail pages in manifest.json). Authorization rights for the targets are checked per table. Where available, the navigation indicators are displayed for all line items (but not for hidden items). Possible targets include:
    • Navigation to a related object page within the app (default). Apps can override this behavior and define their own navigation target. The target can also depend on specific conditions defined by the app (maintain detail pages in manifest.json).
    • Cross navigation to another SAP Fiori app or to another system
  • Link and smart link to show details in a quick view or to navigate. A quick view can be used as part of the smart link or for displaying contact details. For navigation, the target can be any web page, another app, or a related object page within the same app.
  • Line item actions as text or icon buttons (such as Approve and Reject).
  • Any control that the corresponding table allows by using breakout columns.

At present, the smart table does not support:

  • The object number control. This is only available if you use a breakout column. Without a breakout, amounts appear as standard text only.

Only the responsive table supports:

  • A column that displays the object identifier, including the object name and ID (annotations: Common.SemanticKey with Common.Text)
  • Images in line items (annotation: UI.IsImageURL)
  • The object status control in line items: Use of a specific status such as Out of Stock in connection with one of the semantic colors and/or a status icon (criticality annotations).
    The object status provides different categories: negative (property: error), critical (property: warning), positive (property: success), and neutral (property: none). When a column is sorted by object status, the SAP Fiori element list report sorts by these categories. If a category has multiple values, ensure that the values within the category are sorted in a meaningful way (for example, alphabetically).
  • A progress indicator in line items (annotation: UI.DataPoint)
  • Smart area micro charts, smart bullet micro charts, and smart radial micro charts in line items (annotation: UI.Chart)
It is not possible to change the alignment of table content.

Because the SAP Fiori element list report does not support inline editing, the message button is not supported on the footer toolbar.

Actions cannot be grouped using a menu button on the footer toolbar.

Actions

Places for actions in the list report: header toolbar, table toolbar, line item, or footer toolbar
Places for actions in the list report: header toolbar, table toolbar, line item, or footer toolbar

The list report offers four locations for actions: global actions, table actions, line item actions, and finalizing actions.

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

SAP Fiori Element List Report

The header toolbar provides the following built-in actions:

  • Show Filters / Hide Filters (if needed)
  • Share

App-specific actions can be added using a breakout.  They cannot be grouped using a menu button on the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no item is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

Hide actions that cannot be used at all (for example, because the user has no authorization). If you are using an icon tab bar, please be aware that each tab contains its own table toolbar.

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

SAP Fiori Element List Report

The table toolbar provides the following built-in actions:

  • Add: An icon button that triggers an object page for creating an item. If this function is not needed, or if you want users to add or create items differently (for example, in a dialog), turn it off. If you use this button, replace the generic tooltip Create Object with a more specific text, such as Create Purchase Order.
    Draft handling is supported (recommended). (annotation: Creatable)
  • Delete: A text button to delete selected items. Delete is enabled as soon as deletable items are selected. If this function is not needed, turn it off. (annotation: Deletable)
  • View Settings (sort, group, column settings): In contrast to the guidelines above, only one button is shown for sort, group, and columns settings. The icon button always opens the p13n-dialog with all features enabled. The less complex view settings dialog cannot be used.
    The SAP Fiori element list report also allows users to add filter settings within the p13n-dialog. This feature is only available if an explicit layout variant is being used for the table, which should not usually be the case. Do not use this feature.
  • In addition, you can add app-specific actions, such as Copy or Approve. These actions are displayed as text buttons. App-specific actions can be enabled or disabled, depending items selected in the table.

There are 3 types of app-specific action:

  • The system simply triggers the action.
  • The action requires user confirmation. Use this for critical actions that have severe consequences. A message box appears, and the user needs to confirm the action. The message displayed is generic and must be replaced (annotation: IsActionCritical).
  • The action needs additional user input, such as an approval comment. The system opens a dialog with one or more user input elements in which the user enters the required data. The system can pre-fill data if applicable (function import with parameters).

App-specific actions can also trigger navigation to another app or to a related object page within the same app. The navigation can depend on zero selected items, or on one selected item.

Actions cannot be grouped using a menu button.
Actions in the smart table toolbar
Actions in the smart table toolbar

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Do not disable line item actions. If an action cannot be used, hide it. For example, hide line items if the user has no authorization or the line item is in the wrong state.

SAP Fiori Element List Report

Actions cannot be grouped using a menu button.

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information finalizing actions, see the guidelines for the footer toolbar.

SAP Fiori Element List Report

Actions cannot be grouped using a menu button.

SAP Fiori Element

Use the table below to see which features are available for the “list report” SAP Fiori element.

Feature Status Comment
 Header Title
 Title only (no variant management) Supported
Variant management: Page variant Supported
Variant management – Only for filter settings Supported Not recommended
Filter information Supported
Global actions Supported
Generic action: Share Supported
Generic action: Show Filters / Hide Filters (only with grid table, analytical table, and tree table) Supported
Header Content
General
Persisting pin state Not Supported
Filter Bar
Search field Supported
Mandatory fields Supported
Default values Supported
Live update mode Supported
Manual update mode (Go button) Supported Use only in case of performance problems
Any control in the filter bar Supported Via breakout only
Content Area
General Layout
Simple content Supported One table only
Mutiple views: Single toolbar (segmented buttons / select) Supported
Multiple views: One toolbar each (tabs) Supported
Multiple content Not Supported
Tabs
Item counts on tabs Supported
Table Toolbar
Title Supported
Item count Supported
Sort / Filter / Group via View Settings dialog Not Supported Do not show filter settings on the table toolbar
Sort / Filter / Group via P13n dialog Supported Do not show filter settings on the table toolbar
View switch Not Supported
Alternative visualization: Chart view Not Supported
Alternative visualization: Table and chart view Not Supported
Other alternative visualizations Not Supported
Layout variant Supported Not recommended
App-specific actions with partial processing

(In case of errors, display a message message for the items with issues. Process all other items.)

 Supported Change the generic message texts
App-specific actions with roll-back

(In case of errors, display a message. All items are reverted.)

 Supported Change the generic message texts
Enable/disable actions, depending on selection Supported
Grouping of actions (menu button) Not Supported  
Overflow handling for toolbar Supported
Generic action: Edit Not Supported
Table
Table type: Responsive table Supported
Table type: Grid table Supported
Table type: Analytical table Supported
Table type: Tree table Supported
Table type: List Not Supported
Table type: Tree Not Supported
Selection: Table items are not selectable Supported
Selection: Single selection Supported
Selection: Multi-selection Supported
App-specific column widths (only grid table, analytical table, and tree table) Not Supported
Content: Text Supported
Content: Rating indicator Supported
Content: Progress indicator Supported
Content: Editing status Supported
Content: Actions (text or icon buttons) Supported
Content: Object identifier (responsive table only) Supported
Content: Images (responsive table only) Supported
Content: Object status (responsive table only) Supported
Content: Smart area / bullet / radial micro chart (responsive table only) Supported
Content: Any other content as long as the underlying table allows it Supported Via breakout only
Aligning content within columns Not Supported
Generic “No data” text Supported
Custom “No data” text Not Supported
Navigation: Line Item navigation via navigation indicator (within app, cross-app, any target) Supported
Navigation: Line Item navigation via link with/without quick view (within app, cross-app, any target) Supported
Footer Toolbar
Messaging button and message popover Not Supported
Finalizing actions Supported
Grouping of actions (menu button) Not Supported  
 Actions
Global Actions
Generic action: Show Filters / Hide Filters Supported
Generic action: Share (icon button) Supported
App-specific actions Supported Via breakout only
Grouping of actions (menu button) Not Supported
Table / Chart Actions
Enable/disable actions depending on the current selection Supported
Grouping of actions (menu button) Not Supported
Generic action: Add (via object page) Supported Draft handling is supported
Generic action: Add (via dialog) Supported Via breakout only
Generic action: Add (via new row) Not Supported
Generic action: Delete Supported
Generic action: Sort (via View Settings dialog) Not Supported
Generic action: Sort (via P13n dialog) Not Supported
Generic action: Filter (via View Settings dialog) Not Supported Do not use filter settings on the table
Generic action: Filter (via P13n dialog) Not Supported Do not use filter settings on the table
Generic action: Group (via View Settings dialog) Not Supported
Generic action: Group (via P13n dialog) Not Supported
Generic action: Column settings (via table personalization dialog) Not Supported
Generic action: Column settings (via P13n dialog) Not Supported
Generic action: View settings – combines sort, filter, group, and column settings (via P13n dialog) Supported Not recommended. If used, turn off filter settings.
Generic action: Export to Spreadsheet Supported
Generic action: Maximize Supported
App-specific actions as text button Supported
App-specific actions as icon-only button Not Supported
App-specific actions with partial processing Supported
App-specific actions with roll-back Supported
App-specific action in emphasized style Supported Use this only for a single action
App-specific action in positive/negative style Supported
App-specific action: Trigger immediately Supported
App-specific action: Needs user confirmation Supported
App-specific action: Needs additional user input Supported
App-specific action: Triggers navigation (within app, cross-app) Supported
App-specific action: Triggers any other behavior Supported Via breakout only
Line Item Actions
App-specific actions as text button Supported
App-specific actions as icon-only button Supported
Generic action: Delete (icon-only button) Not Supported
Finalizing Actions
App-specific actions Supported
Grouping of actions (menu button) Not Supported

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Analytical List Page (SAP Fiori Element)

The analytical list page (ALP) offers a unique way to analyze data step by step from different perspectives, to investigate a root cause through drilldown, and to act on transactional content. All this can be done seamlessly within one page.

The purpose of the analytical list page is to identify interesting areas within datasets or significant single instances using data visualization and business intelligence.

Visualizations help users to recognize facts and situations, and reduce the number of interaction steps needed to gain insights or to identify significant single instances. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

The main target group are users who work on transactional content. They benefit from fully transparent business object data and direct access to business actions. In addition, they have access to analytical views and functions without having to switch between systems. These include KPIs, a visual filter where filter values are enriched by measures and visualizations, and a combined table/chart view with drill-in capabilities (hybrid view). Users can interact with the chart to dig deep into the data. The visualization enables them to identify spikes, deviations and abnormalities more quickly, and to take appropriate action.

Analytical list page – Size XL
Analytical list page – Size XL

Usage

Use the analytical list page if:

  • Users need a way to analyze data step by step from different perspectives, investigate a root cause through drilldown, and act on transactional content within one page.
  • In addition to the filtered dataset, users need to see the impact of their filter settings in a chart representation (visual filter).
  • Users need to interact between charts and table views (hybrid-view).
  • Users need to see the impact of their action on a KPI.
  • Users need to find and act on relevant items out of a large set of items by searching, filtering, sorting, grouping, drilling down, and slicing and dicing.

Do not use the analytical list page if:

  • Drilldown is rarely used, not used at all, or is only needed after navigating to another page, rather than as free or flexible drilldown within the page itself. In this case, a list report might be sufficient for your use case.
  • Users need different visualizations for the entire dataset (for example, as a table or as a chart), but don’t need interaction between these visualizations (for example, in a reporting scenario). In this case, a list report might be sufficient.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping, without using drilldown or “slice and dice”. In this case, consider using a list report instead.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. They want to be able to switch views using tabs, segmented buttons, or a select control. In this case, consider using a list report instead.
  • Users need to see or edit a single item with all its details. Use the object page floorplan instead.
  • Users need to find a specific item, where the item or an identifying data point is known to the user (for example, if a barcode identifies the item). In this case, use the initial page floorplan.
  • Users need to work through a comparably small set of items, one by one. In this case, use the worklist floorplan instead.

Structure

This section describes the basic layout of the analytical list page, as well as the different variants of the layout.

Basic Layout

In addition to the shell bar, the analytical list page contains three main elements:

  1. Page title: Contains the page variant (variant management) and global KPIs. It also provides access to the KPI card (containing additional information), the visual filter dialog, and the switch for changing the filter mode.
  2. Page header: Consists of the visual filter bar or the filter bar.
  3. Page content: Consists of either a hybrid view (a combination of a chart and a table), a chart-only view, or a table-only view.

All elements are described in more detail in the sections below.

Analytical list page - Basic layout
Analytical list page - Basic layout

Layout Variants

The layout of the analytical list page is quite flexible. The page header allows users to display either the visual filter bar or the filter bar, while the page content can display either a hybrid view (chart/table combination), a table-only view, or a chart-only view. These choices result in various layout variants.

Layout Variants for the Analytical List Page

Dynamic Page

The analytical list page incorporates the dynamic page layout. The header content snaps on click/tap (in the entire header title area). The KPI tags and the global actions are visible and actionable in both the expanded and collapsed modes. The segmented button for switching the filter type disappears when the header content collapses.
  • Header expanded
  • Header snapped

Page Title

The page title contains variant management (for the page variant) and global KPIs. It also provides access to the KPI card (containing additional information), the visual filter dialog, and to the switch that enables the user to change the filter mode.

Variant Management

Variant management in the analytical list page allows users to save a page variant whenever there are changes in the underlying structures of the filter/content area. Variant management for the page is handled by the standard SAPUI5 page variant management.

Currently, the page variant captures the filter selections, filter mode, view mode, Hide icon state  , and Show  icon state  , as well as chart and table configurations (such as measures and dimensions used, sort order, or grouping). The selection of the content view switch (hybrid view  , chart-only view  , table-only view   ) is not part of variant management.

KPI Tags

Use a KPI tag if you would like to show a KPI related to the task in hand. The KPI value changes only if an action is executed on the transactional content. For example, the user needs to know the effect of releasing sales orders on a related KPI, or the effect of posting an accounting document on certain financial KPIs.

You can display a maximum of three KPIs. Clicking a KPI tag opens a card that displays more details on the KPI. The KPI card is explained in more detail in the next section.

3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator

KPI Label: The KPI label is an abbreviation of the KPI. It is formed using the first three letters of the first three words of the KPI title. If there is only one word in the KPI title, the first three letters of the word are displayed. If the KPI title has only two words, only the first letters of these two words are displayed.

KPI label excerpt: AC
KPI label excerpt: AC

KPI Value: The KPI value is displayed using a semantic color and a scaling factor. Relative values are shown with a percentage sign and one decimal place (the actual value is rounded off to 0 decimal places). Absolute values are shown without decimal places, a currency, or a unit of measure.

KPI values excerpts: 2K and 0.3%
KPI values excerpts: 2K and 0.3%

KPI Color and Criticality Indicator: The color of the KPI value is based on the thresholds defined for the particular KPI in the annotation. The KPI tag also uses a line to indicate the criticality. The color of the line is the same as that of the KPI value.

KPI color and criticality indicator
KPI color and criticality indicator

KPI Card

Clicking the KPI tag opens the analytical card, which displays more information about the current value of the KPI, the KPI target, the deviation from the target, and how the KPI has evolved over time.

Visual Filter Dialog

The analytical list page offers two filter modes for filtering the data displayed in the content area: the filter bar and visual filter. In the filter dialog, the user can choose which filter fields are shown in the filter bar. The filter dialog is launched by clicking the Filters (x) button in the page title area.

Visual filter vs. filter bar: Currently, any filter configured as a visual filter is always displayed as a compact filter. A filter configured for the filter bar may or may not be configured for display as a visual filter.

Visual filter configuration: For visual filters, the filter dialog enables the user to make changes to the sort order  , to change the chart type  , and to use different measures  in the visual filter display.

Visual filter selections: Any data point or segment that is selected in a chart will remain selected even when the user changes the measure, chart type, or sort order in any of the charts. If a selected record falls outside the top/bottom three records being displayed, the Selected (x) status next to the chart shows the number of selected records.

Analytical list page - Visual filter dialog
Analytical list page - Visual filter dialog

Filter Type Switch

Users can toggle between two filter modes: compact filters and visual filters.

Analytical list page - Filter type switch
Analytical list page - Filter type switch
  • Filter switch - Compact filter
  • Filter switch - Visual filter

Page Header (Filter Area)

The filter area allows users to filter the result set, which feeds the main content area. Two types of filters are supported: compact filters and visual filters. This section describes the visual filter bar in more detail.

Note: Changing the filters in the filter area has no effect on the KPI values shown in the KPI tags and KPI card.

Visual Filter

As a core feature of the analytical list page, the visual filter combines measures or item counts with filter values. The visual filter becomes more powerful if you match measures to the filter dimension instead of just item counts. Use the visual filter bar if you would like to give the user a condensed overview of the data in the dataset. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly. Ideally, the filters depend on each other. By selecting one or several chart data points, users can perform a quick analysis of the dataset.
Examples: Supplier with the lowest supplier performance this year; product with the highest sales volume in March in the EMEA region

Always design both a visual filter and a compact filter. To design a visual filter, choose a meaningful measure out of the dataset and match it to a filter dimension. If no measures or no meaningful measures are available, use an item count instead. Choose an appropriate chart type. Always use a line chart to show a time series. Do not use a line chart to show categories; use a bar chart instead.

Filter Title

Use the following naming convention for the filter title, using title case: <Measure Name> by <Dimension Name> in <Scale Factor> <Unit of Measure>. For example, Project Costs by Project in K EUR, Sales Volume by Commodity in M PC.

Example of a filter title
Example of a filter title

Filter Charts

Currently, the visual filter supports three chart types (interactive charts): the interactive bar chart, the interactive line chart, and the interactive donut chart. The bar chart can have a maximum of three filter values. For the donut chart, only the top or bottom two values are shown; the rest are aggregated into the “Other” section. The line chart can display a maximum of six data points. Show the latest six data points (for example, last six days, last six months, and so on). Always use a line chart to show a time series. Do not use a line chart to show categories; use a bar chart instead. More filter values can be selected using the value help.

Analytical list page - Interactive donut chart
Analytical list page - Interactive donut chart
Analytical list page - Interactive line chart
Analytical list page - Interactive line chart
Analytical list page - Interactive bar chart
Analytical list page - Interactive bar chart

Live Update / Manual Update

The visual filter bar supports two different modes: live update and manual update. Both the compact and visual filters use the same mode.

Page Content

The content area shows the main content and provides different visualizations of the data. This is the main working area, where users can interact with both the chart and table visualizations at the same time (hybrid view). Chart visualization increases the joy of use, and enables users to spot relevant data more quickly. In addition to the hybrid view, the analytical list page supports a chart-only view and a table-only view. All three views are explained in detail in this section.

Controls

The smart chart is used to display the dataset as a chart. The smart chart drilldown functionality provides a convenient way to analyze the dataset. In addition, the smart chart offers detailed information on the chart data and a breadcrumb that shows the drilldown path. The smart chart is used in the hybrid view and the chart-only view.

If the data contains measures, the analytical list page renders the data in an analytical table, which supports data grouping and aggregation at different levels. If the dataset does not contain any measures, the analytical list page uses the responsive table to render the data. The analytical or responsive table is used in the hybrid view or the table-only view.

Hybrid View

The hybrid view uses both chart and table visualizations at the same time. It enables users to analyze data step by step from different perspectives and then drill down to investigate a root cause. Users can interact with both the chart and the table, and act directly on transactional content. In the initial view of the chart, visualize the most important aspects of the whole dataset.

Example: The view shows all the suppliers the user is responsible for, organized by value. By drilling down the material to the plant with the highest/lowest volume, the user can see if materials need to be shifted from one plant to another. The action for shifting the material might be derived directly from the transactional data, which is shown in an analytical table below the chart.

Analytical list page - Hybrid view
Analytical list page - Hybrid view

Table-Only View

The table view provides access to transactional content. The user can act on single or multiple objects, and navigate to the object details or to other applications.

The table used within the analytical list page is either an analytical table or a responsive table. The analytical list page relies on the dataset to determine which table should be used. If the dataset contains measures, the data is rendered in an analytical table that supports data grouping and aggregation at different levels. If the dataset does not contain any measures, the data is rendered in a responsive table.

Analytical list page - Table-only view
Analytical list page - Table-only view

Chart-Only View

The chart-only view enables users to analyze data step by step from different perspectives, and to investigate a root cause through drilldown, without direct access to transactional content. The smart chart control provides the chart visualization.

This mode is perfect for applications with analytical data that can easily be represented visually using charts, but doesn’t need to be linked to the transactional dataset.

Analytical list page - Chart-only view
Analytical list page - Chart-only view

Responsiveness

The analytical list page only supports desktop devices.

Behavior and Interaction

KPI Tag and KPI Card

Clicking a KPI tag opens the KPI card, which shows the details for the KPI.

Select Filters in the Visual Filter

Unlike micro charts, the visual filter charts are interactive. If the live search is being used, selecting a filter value triggers data filtering in the content area. Both single and multiple selection are supported.

To select a filter value, the user clicks on a value in the chart. The filter can be removed by either clicking on the label Selected (<number of filters>), or by clicking on the same value in the chart again. The user can select more filter values using the value help.

Any data point that is selected in a chart still remains selected when the user selects a data point in another chart. Filter values react on each other. If a selected record falls outside the top/bottom three records being displayed, the Selected (x) status next to the chart shows the number of selected records.

Selected Filter Values in the Visual Filter Bar

  • Visual filter - Select dimension - Product
  • Visual Filter - Select Dimension Quarter - 1.48

Filter Type Switch

Users can toggle between two filter modes: compact filters and visual filters.

Carrying forward filter selections from the visual filter to the compact filter
Any values selected in the visual filter are always carried forward to the compact filters.

Carrying forward filter selections from the compact filter to the visual filter
Filter dimensions that are part of the visual filter are synced to the visual filter. These values are shown as selected chart dimensions in the visual filter (single or multiple selections) or show up as selected in the Selected (x) link depending on whether the dimension value chosen in the compact filter is part of the visual filter or not.
Filter dimensions that are not part of the visual filter, parameter values, and interval-based dimensions are applied to the filter query and content is refreshed.
Complex conditions are shown in the Selected link for the visual filter.

Snap Visual Filter Bar to Top

To save space, users can snap the visual filter bar to the top.

Switch Views: Hybrid, Chart-Only, and Table-Only

Users can switch between the different views: hybrid, chart-only, and table-only. If the user selects values and then switches the view, the selection remains intact. See the table below for more details.

Switch Description
Hybrid view to table view Table selection remains intact
Hybrid view to chart view Chart selection remains intact
Chart view to hybrid view Chart selection remains intact; corresponding table selections are displayed
Table view to hybrid view Table selection remains intact

Hybrid View

In the hybrid view, the chart and table interact. A selection in the chart is reflected automatically in the table. The data in the table reacts to the chart selection by highlighting all the records that are affected by the chosen dimension value. For example, if user chooses Country=ABC in the chart, all records relating to country ABC in the table are highlighted. Note that this still holds even if Country itself is not a dimension displayed in the table. Any grouping is highlighted if there is a record within the grouped set that is affected by the chart selection.

Show / Hide Icons

The Show icon  and the Hide icon   are available in the table toolbar in the hybrid and table-only views. If the Show icon is active, the table only shows items that are selected in the chart. The other entries are “hidden”. In this case, all entries in the table are highlighted. If the Hide icon is active, the table shows all items. In this case, the table has both highlighted entries (where values are selected in the chart) and non-highlighted entries.

Chart Selection - Eye Icon Setting - Table Behavior

  • Show icon - Show all
  • Hide icon - Only show items selected in the chart

Guidelines

Visual Filter

  • Always configure both a visual filter and a compact filter.
  • Use the visual filter as the default whenever possible.
  • If parameter values are required, we recommend using the compact filter as the default filter mode.
  • Use the live search for both filter types whenever possible.
  • Always use a line chart to show a time series. Do not use a line chart to show categories; use a bar chart instead.

Content Area

  • Hybrid view / chart-only view: Show the most important aspects of the dataset in the main chart.

Layout

  • Do not use tabs in the analytical list page.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • No links.

Overview Page – Fixed Card Layout

Self-Contained Cards

The fixed card layout is a layout for the overview page. It comes with predefined card characteristics that support automatic, easy and fast card design. The cards have a fixed width, and the height is determined by the card type and the embedded control.

The cards are ordered in responsive and collapsible columns. The number of columns is also fixed to keep the focus on the middle of the screen and show the set of cards in a compact display (a kind of letterboxing). For more information, see Responsiveness.

Before you start designing cards for an overview page, see the best practices.

At a Glance

  • Easy and fast card design due to predefinitions

  • Fixed card width and pre-defined height

  • Arbitrary card order

Overview page – Fixed card layout
Overview page – Fixed card layout

Fixed Card Sizes

Grid

The grid is based on rows and columns. The spacing of 1 rem between the cards is always stable. The columns with the cards adapt to the available screen real estate (also see Responsiveness).

Based on the underlying grid, users can rearrange the cards (see Rearranging Cards – Behavior).

Fixed card layout – Grid
Fixed card layout – Grid

The cards are arranged as a “Z” flow: cards are ordered from left to right, starting with the first card on the top left of the page. For example, if a 5-column layout is reduced to 4-column layout, the fifth card drops to the next row, assuming the leftmost position underneath the first card.

There is no limit on the number of cards included. However, be careful not to overwhelm your users.

For general information on cards, see Cards.

Fixed card layout – Z flow
Fixed card layout – Z flow

Card Sizes per Type

The card size is determined by the predefined card characteristics and maximum content for a given card type. As a result, the card types differ in height. The stack card and corresponding quick view card are handled independently.

List Card

The height of list cards can vary, depending on the number of text fields. Show no more than five standard list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Standard list item
Standard list item
Extended list item
Extended list item

Bar Chart List Card

The height of  bar chart list cards can vary, depending on the number of text fields. Show no more than five standard/condensed list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Standard list item
Standard list item
Condensed list item
Condensed list item
Extended list item
Extended list item

Link List Card (Variant Type “List”)

The link list card with the variant type “list”  is limited to a maximum of six links. There is no limit to the number of links for the variant type “image”.

Table Card

The height of table cards can vary, depending on the number of table cells. Tables are limited to a maximum of 3 columns and 3 rows, with a maximum of 3 lines of text per row. To see the full result set, the user needs to navigate to the parent app.

Rearranging Cards – Behavior

Drag and Drop

Users can reposition cards on the overview page by dragging them to a different location. As the user drags a card, it swaps places with any cards in its path. As soon as a neighbouring card is touched, the position of that card becomes the new target location for the card being dragged. A dashed line offers a preview of the new position.

To drag a card, the user has to long press on a card instead of just clicking. It doesn’t matter where the cursor is positioned – cards can be dragged from both the header and content areas. The mouse cursor also changes to indicate that the card can be dragged. Releasing the mouse or lifting the finger from the touch surface completes the move. To avoid gaps, cards always snap to the next free space in the row, or to the start of the next row.

In addition, users can personalize their own overview page by hiding cards.

Fixed card layout – Drag and drop
Fixed card layout – Drag and drop

Getting Started

In the fixed card layout, you can’t influence the amount of information on each card. However, you can define the card order. Before you design your overview page, take a look at the best practices, which outline how to best use cards for an optimal user experience.

Responsiveness

The fixed card layout uses padding on both sides. The cards are displayed inside collapsible columns, making the page fully responsive. When the user resizes the browser or uses a smaller screen, the columns containing the cards collapse. To view all the cards, the user just scrolls down. In this way, the layout can accommodate typical laptop screens, larger desktop monitors, and mobile devices.

The width of the cards is tied to the column width. Breakpoints for the different screen resolutions determine whether the column width is 20 or 25 rem. The cards inside the columns adapt their width and content automatically. By contrast, the height of the cards is flexible, and depends on the content and type of card (see Card Sizes per Type).

  • Phone: 1 column
  • Tablet (portrait): 2 columns
  • Laptop / tablet (landscape): 3 columns
  • Large desktop: 4 columns
  • Extended monitor: 5 columns (maximum)
Fixed card layout – Size L
Fixed card layout – Size L
Fixed card layout – Size M
Fixed card layout – Size M
Fixed card layout – Size S
Fixed card layout – Size S

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Overview Page – Custom Card

Adaption of standard cards

Custom cards allow you to define the appearance of a card on an overview page, and the type of content that appears in the card content area. They offer additional flexibility when you require features that are not offered by the standard cards for overview pages.

Information
Keep in mind:

  • A card is not a substitute for an application.
  • A card focuses on the most important task-related data. It lets the user view, filter, and react to information quickly.
  • The content must be defined for a specific context. Do not display irrelevant or unclear content.

Usage

Use a custom card if:

  • Your use case cannot be satisfied in any way by the standard cards provided for the overview page. Always consider the requirements below before using a custom card.

Do not use the custom card if:

  • You can satisfy your use case to a certain extent with the existing standard cards. Even if there are technical or visual limitations, stick with the standard cards if they are still workable for your scenario.
  • You are not using the overview page floorplan.

Standard Requirements

Custom cards must meet the standard SAP Fiori requirements, especially:

  • Responsiveness: Ensure that the cards can run on different devices (touch, mouse and keyboard), using breakpoints supported by SAPUI5.
  • Cozy/compact: Provide different control dimensions as described by the visual design. If your existing design already covers both use cases (mouse and touch input), you do not have to provide two different designs. For more information on cozy and compact form factors, see content density.
  • Theming: Custom designs must allow theming and use the LESS parameters provided by the official Belize theme. Implementation of the customized design must be tested in all themes (high-contrast white, high-contrast black, and Belize Deep).
  • Accessibility: Support keyboard navigation and screen readers (as stipulated by accessibility requirements).
  • Browsers: Support all types of browser.
  • Performance: Ensure the performance of the implementation is satisfactory.
Information
Be aware that implementing a custom card costs time and effort for development.

Components

Custom cards have two components:

  • A mandatory header area
  • A mandatory content area
Custom card – card components
Custom card – card components

Header Area

The title and subtitle of custom cards follow the guidelines for standard titles and subtitles.

From the header area, users can navigate to the parent app. Since the entire header area is clickable, only one navigation target is allowed. We highly recommend offering this navigation option to give users access to the full-blown app with the complete set of results and actions. If a card displays a subset of grouped items, use a text label to show how many of the relevant items are showing on the card. Also refer to the guidelines for the overview page card header.

If a card features content with a single focal point (detail/entity), the header area navigation must always lead to this specific focal point. If a card features a subset of items grouped by a common criterion, the header area navigation must always lead to all items.

Custom card – header area
Custom card – header area

Content Area

The content area is reserved for application content and shows an entry-level view of the content. The use case determines what should be shown in the content area of a custom card. The content must adhere to the standard content guidelines.

Make sure that the content is responsive.

Provide a stable context for the content area and sustain it when the user navigates away from the overview page into another app. Transfer any sort or filter criteria to the application. In other words, show the same context, but with additional information.

Custom card – content area
Custom card – content area

Card Size

Follow the guidelines for the fixed card layout. Make sure that the card is responsive.

Guidelines

Custom cards inherit the drag and drop behavior from the standard cards. Only place custom cards on the overview page itself (not in the object stream).

Custom cards must:

  • Provide information that is relevant for the user’s specific domain or role
  • Offer an entry-level view of application content
  • Represent a single topic, task, or context
  • Provide a stable context and sustain it after navigating from the overview page to another application
  • Be integrated in the Manage Cards dialog (show/hide cards)
  • React on filtering (when a smart filter bar is used)
  • Follow the guidelines for formatting dates, times, amounts, currencies, as well as for truncation (ellipsis). These guidelines are the same as for standard cards.
  • Contain consistent texts and formatting, aligned with the other cards on the overview page. Check the UI text guidelines for the overview page for details.

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori overview page.

Elements and Controls

Implementation

  • No links

Overview Page – Resizable Card Layout

Unlimited Possibilities for Designing Cards 

The resizable card layout is a layout for the overview page. It enables users to define a personalized card layout by changing not only the position of a card, but also its size, and thus how the card content is presented.

This layout gives users much greater flexibility in tailoring the overview page to their specific business needs. And it allows app teams to offer varying levels of detail for any given card. Whenever the size of a card changes, the content adapts automatically to show the most relevant information in the available space.

At a Glance

  • Flexible card dimensions (grid-based)
  • More flexibility to define individual card layouts
  • Responsive and adaptive card content
Overview page - Resizable card layout
Overview page - Resizable card layout

Unlike the fixed card layout, cards in the resizable card layout do not have fixed dimensions. In addition, the number of columns in the resizable layout is no longer limited (also see letterboxing).

The cards are positioned on an underlying grid, making it possible to arrange and resize cards in a flexible, yet guided manner. You can offer different views of the card content for different dimensions of the various card types. For example, you can show more items, zoom in or out, or change the granularity of a dataset.

The resizable card layout does not replace the fixed card layout.

Usage

Use the resizable card layout if:

  • You want to give users the flexibility to rearrange and adapt their overview page as they need.
  • You want to help users focus by applying progressive disclosure principles.
  • You want to make use of different card sizes.
  • You want to show more content (for example, more items or an additional level of detail)

Do not use the resizable card layout if:

  • Your card content doesn’t react properly to a change in size. Use the fixed card layout instead.
  • You are not able to invest UX and development resources for creating and prioritizing additional content. Use the fixed card layout instead.
  • You want to use the resizing functionality on mobile devices. Resizing and rearranging cards is currently not possible on mobile devices.

Flexible Card Sizes

Grid

Cards can be increased and decreased vertically in rows of 1 rem and horizontally in steps of 20 rem. These dimensions facilitate both a high degree of flexibility and measured guidance. The card content responds immediately to a change in size.

The grid provides a guided resizing and repositioning experience. This ensures that the cards are always correctly aligned on the overview page as the user moves or resizes them.

Resizable card layout – Grid
Resizable card layout – Grid

Card Anatomy

A card is made up of a mandatory header and a content area.

Mini Header

The smallest representation of the card is the header. The card can be collapsed to only its header height. We call this the “mini header” card height.

Mini Content

The “mini content” height of a card is defined by the next suitable size for a card when it is resized. The minimum height for the card content depends on the card type, and must be as high as the smallest representation of the content. In a list card, for example, first list item needs to fit in.

To avoid states with cut or unsubstantial content, there are no resizing steps between mini header and mini content.

Card anatomy
Card anatomy
Minimum heights for a card in the resizable card layout
Minimum heights for a card in the resizable card layout

Examples of Card Sizes

Dealing with White Space

White space at the bottom of lists

To prevent content from being cut off, the next line item in a list does not appear until the card height is sufficient for the full line item to fit in. If a line item comprises several rows, this can result in white space at the bottom of the list (until the card is stretched enough to show the next whole item).

White space when there is no additional content

If no additional content is available, the user still can make the card bigger, resulting in white space.

Resizing Parameters

The card content depends on the available space, which in turn determines how many items are shown, how each item is displayed, and the level of detail (granularity). How the content is resized depends on the type of card. For example, table cards can have fewer columns when the size of the card is decreased. By contrast, the content shown for each item on list cards remains the same.

Space

When a card is resized, the content adapts responsively. 

Example: List card
When the size of a card is reduced, texts might be truncated or wrapped. When the card size is increased again, the text is shown in full and previously wrapped text moves back onto one line. The line item content itself is unchanged.

Resizing for a list card
Resizing for a list card

Items

When you increase the size of a list or table card, more line items are shown.

Resizing for a table card
Resizing for a table card

Granularity

If you increase the size of an analytical card, more data points are revealed. In this example, the summary category “other” in the donut chart is broken down into individual product categories.

Resizing for an analytical card (donut chart)
Resizing for an analytical card (donut chart)

Rearranging Cards – Behavior

When a user long presses on a card instead of just clicking, the mouse cursor changes to indicate that the card can be dragged. Cards can be dragged from both the header and content areas. 

Cards always strive towards the top of the page (uplift mode). When you move or stretch cards horizontally, the existing cards you displace are pushed downwards.

Resizing cards / rearranging cards using drag and drop
Resizing cards / rearranging cards using drag and drop

Getting Started

UX and DEV Investment Required

To enable users to benefit fully from the resizable card functionality, you need to define additional content that is revealed progressively as the card size grows. You will need to develop a content strategy to prioritize the chunks of information for each card type, and hence the order in which these additional chunks of information appear. For instance, the content strategy for a table card should answer the following questions:

  • What should be the initial size of the card in the layout?
  • Which table columns do you want to show in the card with the minimum width?
  • Which table columns do you want to add when the card width is increased by one, two, three, … horizontal steps?

Keep in mind that the overview page is an SAP Fiori element.

Developer Hint
If you want to enable the resizable card layout for an existing overview page with the fixed card layout, consider the investment you’ll need to make in additional and meaningful content.

Set Initial Card Sizes

Set an initial order and initial dimensions for each card as a default. Do this for the mini header, the mini content, and for bigger card sizes. In cards with content, define the exact number of items included in the content area.

Consider the best practices for designing an overview page and the principles for resizing the cards. It’s important to provide a meaningful starting point for users. If users change the card size or order, the initial app default can always be restored using the Manage Cards setting in the Me Area.

Important: Do not provide only mini headers in the initial layout for your overview page.

Block Card Resizing

App teams can block the resize feature for each card individually. In this case, the cards can’t be resized by users and the resize icon is not shown on the card. Use this feature judiciously and only if you really have to. The majority of cards should be resizable. Otherwise, users are likely to be confused, and might feel driven to check the resizing behavior for each card.

Alternative approach

If you want to make use of the different card sizes, but don’t want to allow resizing for users at all, you can block the resizing function for all cards (independently of the initial card size). This allows you to use different card sizes and the same (limited) personalization features as in the fixed card layout. Because none of the cards are resizable, users won’t be confused.

Letterboxing

The resizable card layout uses different letterboxing behavior than the fixed card layout: to handle different card sizes more flexibly, the resizable card layout does not have a fixed number of columns. Cards take up the the available screen real estate and adapt accordingly (also see responsiveness). As a result, larger screens can be almost completely filled.

Responsiveness

Information
Resizing is not supported on mobile devices. However, users can resize cards freely in smaller windows on a desktop device.

UI controls inside the cards react responsively when cards are resized. On mouse-release, additional content might be loaded, or content might be removed to reflect the new dimensions.

The number of grid columns in the layout is dependent on the width of the browser window. The breakpoints are defined as follows:

Width of Browser Window Number of Card Columns Displayed
Less than 656 px 1 column
656 – 975 px 2 columns
976 – 1359 px 3 columns
1360 – 1679 px 4 columns
1680 – 1999 px 5 columns
More than 2000 px 6 columns or more

There is no limitation to the number of columns. You can also design for bigger screens.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • No links

Wizard Floorplan

The wizard floorplan allows users to complete a long or unfamiliar task by dividing it into sections and guiding the user through it. The wizard consists of the walkthrough screen, where the form sections are revealed in sequence after each one is completed, and the summary page, where the form is displayed in read-only mode for assessment and final submission. You can use the wizard both in full-screen and flexible column layout.

Wizard - Steps
Wizard - Steps

Usage

When to Use the Wizard Floorplan

The wizard aims to help users by dividing large or complex tasks into segments. Use the wizard if the user has to accomplish a long task (such as filling out a long questionnaire) or a task that is unfamiliar to the user. The flow should consist of a minimum of 3 and a maximum of 8 steps.

The wizard can be used for both create and edit scenarios. If your application contains both, consider using the same means for both scenarios – either the wizard, or another create/edit screen (edit flow or object page).

When Not to Use the Wizard Floorplan

If you have a task with only 2 steps or a format that the user is familiar with (for example, it is part of their daily routine), do not use the wizard as it only adds unnecessary clicks to the process. If your process needs more than 8 steps, the wizard will not support those steps as the process is too long and can be confusing for the user. In this case, you should consider restructuring the task.

Consider if the classic edit screens (edit flow or object page) are more suitable for your use case.

Structure

The wizard has two main screens: the walkthrough screen, where users complete a segmented task, and the summary screen, where they can check the data they are about to submit. Wizard content is not restricted to forms; other content such as a value help dialog can also be used.

Walkthrough Screen

The walkthrough screen is the wizard’s main screen. After triggering the wizard, the user is taken to the walkthrough screen, which shows only the first section of the form. Once the user has filled out all the necessary fields, a Step XY button appears, which allows the user to move to the next step. When the user has completed the last section of the wizard, the button label changes to Review and the user is taken to the summary screen.

The wizard footer is used to display the Cancel button, which exits the wizard. If the user has modified any fields, a data loss message also prompts the user. You can also use a Save as Draft function in the footer if the form is long and the user may have to save it before finishing it.

Walkthrough screen in full screen layout
Walkthrough screen in full screen layout

The title in the header toolbar above the wizard remains unchanged during all the wizard steps. Align this title left, and make it clear to users where they are and what they are doing (for example, Create Sales Order or Edit Sales Order 4815162342). Especially in edit scenarios, it is vital to give users a unique identifier for the object they are changing.

Header toolbar with title
Header toolbar with title

The progress bar/anchor navigation below the header highlights the completed steps and the current step. It also allows the user to navigate between steps by clicking on any of the circles.

The progress bar exhibits a grouping behavior if there are multiple steps and the screen width is reduced. This behavior is the same on smartphone, tablet, and desktop screens.

Wizard header and anchor navigation
Wizard header and anchor navigation
Wizard tooltip – Grouped steps
Wizard tooltip – Grouped steps

In certain use cases, the steps in the wizard depend on the choices the user makes along the way. The user’s entries for one step determine the follow-on steps (“branching”). In these cases, a dotted line shows that more steps will follow.

Wizard branching
Wizard branching

Since the wizard is a lightweight way to create or edit objects, applications can use a quick confirmation popup instead of the heavier data loss message, when the user selects Cancel.

If the wizard is used to create an object, the text on the popup should read ‘Discard this ?’ (see image below).If the wizard is used to edit an object, please use the text ‘”Discard changes?” In both cases, the action on the popup should be Discard.

Structure – Quick confirmation
Structure – Quick confirmation

Summary Screen

On the summary screen, users can check all their entries before the object is actually created or changed. The summary screen has no progress bar or anchor navigation, and shows the form sections for all the steps in read-only mode.

To allow the user to go back and edit entries, provide an Edit button either in the footer toolbar or in each form section:

  • If you place the Edit button is placed in the footer toolbar, the user is taken back to the first section of the wizard.
  • If you offer Edit buttons for each section of the form, the user jumps to that particular step.

Alternatively, users can click or tap the Back button to go to the previous step. From there, they can scroll or tap through the sections.

The main action on the summary page should be the final action after completing the wizard, such as Create or Save.

Wizard summary page example
Wizard summary page example

Layout

Thanks to the wizard’s responsive behavior, it can be used both in a full-screen layout as well as in the flexible column layout. Since there are no subsequent pages after the wizard, it will always occupy the rightmost column – there is no navigation from the wizard to a next page. After completion (or cancellation), the user will always come back to the page the wizard was triggered from.

Wizard in full screen layout
Wizard in full screen layout
Wizard in flexible column layout (2/3)
Wizard in flexible column layout (2/3)
Wizard in flexible column layout (1/3)
Wizard in flexible column layout (1/3)

Types

There are two types of wizard – “standard” and “branching” – which differ in terms of the functions they offer.

Use the standard type if:

  • The total number of steps is known in advance.
  • The number of steps does not change during usage.
  • There is linear progression from one step to the next.

Use the branching type if:

  • The total number of steps is not known.
  • The number of steps may change during usage.
  • There is non-linear progression. In other words, the user’s choice during one step determines which step comes next.

Styles

In addition to the functional types, there are also different visual styles.

Numbers and Icons

By default, both versions use a number inside a circle to represent each step. You can also use icons instead of numbers to help users identify the steps. If you plan to use icons, be sure to assign icons to all the steps (not just to some). The icons you choose should be unique and not look too similar. This will ensure that users do not get individual steps confused with one another.

Steps represented by numbers
Steps represented by numbers
Steps represented by icons
Steps represented by icons

Labels

To help users identify the individual steps even more easily, app developers can assign labels. As with icons, labels must be applied to all or none of the steps.

If there is enough horizontal space, all labels are shown.

All labels are visible
All labels are visible

As the width is reduced, the steps outside the currently selected one do not show labels.

Labels - reduced width
Labels - reduced width

Finally, the unselected and outermost steps are stacked on top of each other to further accommodate the reduced space.

Stacked labels
Stacked labels

Users can still easily access steps inside a stack. A single click opens a list of steps inside this stack.

Labels - stacked popover
Labels - stacked popover

Explanatory Texts

Ideally, the headlines and field labels for each step should provide enough information for users to complete their tasks. However, if additional explanations are needed, applications can put a simple text underneath a step’s headline – either via the sap.m.Text or the sap.m.FormattedText control.

Responsiveness

The wizard supports all common screen sizes and is available in cozy and compact modes, as well as high-contrast black (HCB).

Wizard – Size S
Wizard – Size S
Wizard – Size M
Wizard – Size M
Wizard – Size L
Wizard – Size L

Behavior and Interaction

Navigation, Error- and Draft Handling

Navigation

Users can trigger the wizard app from another application, the launchpad, or a notification. The wizard always starts at the initial walkthrough page and ends after the user has clicked the main action (such as Submit) on the summary screen. The Step XY button is only used on the walkthrough page, and its purpose is to load the next section of the form.On the summary page, the user can use either the Edit button in the footer or the “back” arrow to return to the wizard and edit any of the fields.Modifying dependent steps: If there are steps that depend on each other (for example, a selection in step 2 triggers an optional step) and the user modifies the parent step, the dependent step is changed or deleted. This first triggers a warning message (when the input control loses focus) that data will be lost.

Error Handling

Error handling is done via message popovers. When the user clicks the Step XY button, the form sections and fields should be validated. When the user clicks the Submit button on the summary page, the entire form is validated. If there are any errors, the user stays on the walkthrough page, the message popover is displayed, and clicking any of the error items scrolls the page to the relevant field, which is also highlighted in red.

Section validation differs from validation of the entire form. In the first case, correct data entry in the form fields is validated. In the second case, the entire form is checked for backend system errors (such as duplicated data entry).

Draft Handling

If a draft already exists when a user enters the wizard, show a dialog to inform the user. For more information, please visit the draft handling article.

Dynamic Page

Header

Even though the wizard floorplan consumes the dynamic page, the wizard’s header does not allow snapping. Due to the nature of the wizard floorplan, the wizard brings its own step-based header that is already very space-saving.

Footer Toolbar

Contrary to the header, the footer toolbar of the wizard floorplan conforms to the standard layout and uses the sap.m.bar control.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • Wizard (SAPUI5 API reference)
  • Wizard (SAPUI5 samples)
  • Form (SAPUI5 API reference)
  • Form (SAPUI5 samples)

Analytical List Page (SAP Fiori Element)

The analytical list page (ALP) offers a unique way to analyze data step by step from different perspectives, to investigate a root cause through drilldown, and to act on transactional content. All this can be done seamlessly within one page.

The purpose of the analytical list page is to identify interesting areas within datasets or significant single instances using data visualization and business intelligence.

Visualizations help users to recognize facts and situations, and reduce the number of interaction steps needed to gain insights or to identify significant single instances. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly.

The main target group are users who work on transactional content. They benefit from fully transparent business object data and direct access to business actions. In addition, they have access to analytical views and functions without having to switch between systems. These include KPIs, a visual filter where filter values are enriched by measures and visualizations, and a combined table/chart view with drill-in capabilities (hybrid view). Users can interact with the chart to dig deep into the data. The visualization enables them to identify spikes, deviations and abnormalities more quickly, and to take appropriate action.

Analytical list page – Size XL
Analytical list page – Size XL

Usage

Use the analytical list page if:

  • Users need to extract key information to understand the current situation or identify a root cause. The way the data is presented is crucial for giving them the insights they need to take the right action.
  • Users need a way to analyze data step by step from different perspectives, investigate a root cause through drilldown, and act on transactional content within one page.
  • In addition to the filtered dataset, users need to see the impact of their filter settings in a chart representation (visual filter).
  • Users need to interact between charts and table views (hybrid-view).
  • Users need to see the impact of their action on a KPI.
  • Users need to find and act on relevant items out of a large set of items by searching, filtering, sorting, grouping, drilling down, and slicing and dicing.

Do not use the analytical list page if:

  • Drilldown is rarely used, not used at all, or is only needed after navigating to another page, rather than as free or flexible drilldown within the page itself. In this case, a list report might be sufficient for your use case.
  • Users need different visualizations for the entire dataset (for example, as a table or as a chart), but don’t need interaction between these visualizations (for example, in a reporting scenario). In this case, a list report might be sufficient.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping, without using drilldown or “slice and dice”. In this case, consider using a list report instead.
  • Users need to work with multiple views of the same content, for example on items that are “Open”, “In Process”, or “Completed”. They want to be able to switch views using tabs, segmented buttons, or a select control. In this case, consider using a list report instead.
  • Users need to see or edit a single item with all its details. Use the object page floorplan instead.
  • Users need to find a specific item, where the item or an identifying data point is known to the user (for example, if a barcode identifies the item). In this case, use the initial page floorplan.
  • Users need to work through a comparably small set of items, one by one. In this case, use the worklist floorplan instead.

Structure

This section describes the basic layout of the analytical list page, as well as the different variants of the layout.

Basic Layout

In addition to the shell bar, the analytical list page contains three main elements:

  1. Page title: Contains the page variant (variant management) and global KPIs. It also provides access to the KPI card (containing additional information), the visual filter dialog, and the switch for changing the filter mode.
  2. Page header: Consists of the visual filter bar or the filter bar.
  3. Page content: Consists of either a hybrid view (a combination of a chart and a table), a chart-only view, or a table-only view.

All elements are described in more detail in the sections below.

Analytical list page - Basic layout
Analytical list page - Basic layout

Layout Variants

The layout of the analytical list page is quite flexible. The page header allows users to display either the visual filter bar or the filter bar, while the page content can display either a hybrid view (chart/table combination), a table-only view, or a chart-only view. These choices result in various layout variants.

Layout Variants for the Analytical List Page

Flexible Column Layout

The analytical list page supports the flexible column layout from size M upwards on desktop devices.

 

Dynamic Page

The analytical list page incorporates the dynamic page layout. The header content snaps on click/tap (in the entire header title area). The KPI tags and the global actions are visible and actionable in both the expanded and collapsed modes. The segmented button for switching the filter type disappears when the header content collapses.
  • Header expanded
  • Header snapped

Page Title

The page title contains variant management (for the page variant) and global KPIs. It also provides access to the KPI card (containing additional information), global actions, the visual filter dialog, and the switch for changing the filter mode.

Variant Management

Variant management in the analytical list page allows users to save a page variant whenever there are changes in the underlying structures of the filter/content area. Variant management for the page is handled by the standard SAPUI5 page variant management.

Currently, the page variant captures the filter selections, filter mode, view mode, Hide icon state  , and Show  icon state  , as well as chart and table configurations (such as measures and dimensions used, sort order, or grouping). The selection of the content view switch (hybrid view  , chart-only view  , table-only view   ) is not part of variant management.

KPI Tags

Use a KPI tag if you would like to show a KPI related to the task in hand. The KPI value changes only if an action is executed on the transactional content. For example, the user needs to know the effect of releasing sales orders on a related KPI, or the effect of posting an accounting document on certain financial KPIs.

You can display a maximum of three KPIs. Clicking a KPI tag opens a card that displays more details on the KPI. The KPI card is explained in more detail in the next section.

3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator
3 KPI tags including KPI labels, KPI values, KPI color, and criticality indicator

KPI Label: The KPI label is an abbreviation of the KPI. It is formed using the first three letters of the first three words of the KPI title. If there is only one word in the KPI title, the first three letters of the word are displayed. If the KPI title has only two words, only the first letters of these two words are displayed.

KPI label excerpt
KPI label excerpt

KPI Value: The KPI value is displayed using a semantic color and a scaling factor. Relative values are shown with a percentage sign and one decimal place (the actual value is rounded off to 0 decimal places). Absolute values are shown without decimal places, a currency, or a unit of measure.

KPI value excerpts: 2K and 0.3%
KPI value excerpts: 2K and 0.3%

KPI Color and Criticality Indicator: The color of the KPI value is based on the thresholds defined for the particular KPI in the annotation. The KPI tag also uses a line to indicate the criticality. The color of the line is the same as that of the KPI value.

KPI color and criticality indicator
KPI color and criticality indicator

KPI Card

Clicking the KPI tag opens the analytical card, which displays more information about the current value of the KPI, the KPI target, the deviation from the target, and how the KPI has evolved over time.

Visual Filter Dialog

The analytical list page offers two filter modes for filtering the data displayed in the content area: the filter bar and visual filter. In the filter dialog, the user can choose which filter fields are shown in the filter bar. The filter dialog is launched by clicking the Filters (x) button in the page title area.

Visual filter vs. filter bar: Currently, any filter configured as a visual filter is always displayed as a compact filter. A filter configured for the filter bar may or may not be configured for display as a visual filter.

Visual filter configuration: For visual filters, the filter dialog enables the user to make changes to the sort order  , to change the chart type  , and to use different measures  in the visual filter display.

Visual filter selections: Any data point or segment that is selected in a chart will remain selected even when the user changes the measure, chart type, or sort order in any of the charts. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.

Analytical list page - Visual filter dialog
Analytical list page - Visual filter dialog

Filter Type Switch

Users can toggle between two filter modes: compact filters and visual filters.

Compact and Visual Filters

  • Visual filter
  • Compact filter

Page Header (Filter Area)

The filter area allows users to filter the result set, which feeds the main content area. Two types of filters are supported: compact filters and visual filters. This section describes the visual filter bar in more detail.

Note: Changing the filters in the filter area has no effect on the KPI values shown in the KPI tags and KPI card.

Visual Filter

As a core feature of the analytical list page, the visual filter combines measures or item counts with filter values. The visual filter becomes more powerful if you match measures to the filter dimension instead of just item counts. Use the visual filter bar if you would like to give the user a condensed overview of the data in the dataset. Chart visualization increases the joy of use, and enables users to spot relevant data more quickly. Ideally, the filters depend on each other. By selecting one or several chart data points, users can perform a quick analysis of the dataset.
Examples: Supplier with the lowest supplier performance this year; product with the highest sales volume in March in the EMEA region

Always design both a visual filter and a compact filter. To design a visual filter, choose a meaningful measure out of the dataset and match it to a filter dimension. If no measures or no meaningful measures are available, use an item count instead. Choose an appropriate chart type. Always use a line chart to show a time series. Do not use a line chart to show categories; use a bar chart instead. Try to show at least three visual filters and try to use different chart types.

More filter values can be selected using the value help. The visual filter supports semantic colors to indicate criticality.

Filter Title

For a measure, use the following naming convention for the filter title, using title case: <Measure Name> by <Dimension Name> in <Scale Factor> <Unit of Measure>. For example, Project Costs by Project in K EUR, Sales Volume by Commodity in M PC.

For an item count, use the following naming convention for the filter title, using title case: Number of <Dimension> in <Scale Factor> <Unit of Measure>. For example, Number of Products in PC or Number of Contracts by Month. Note that for some use cases, it might be appropriate to replace Number with a different expression. 

Example of a filter title
Example of a filter title

Filter Charts

Currently, the visual filter supports three chart types (interactive charts): the interactive bar chart, the interactive line chart, and the interactive donut chart. The bar chart can have a maximum of three filter values. For the donut chart, only the top or bottom two values are shown; the rest are aggregated into the “Other” section. The line chart can display a maximum of six data points. Show the latest six data points (for example, last six days, last six months, and so on). Always use a line chart to show a time series. Do not use a line chart to show categories; use a bar chart instead. More filter values can be selected using the value help. The visual filter charts support semantic colors to indicate the criticality of filter values.

Analytical list page - Interactive donut chart
Analytical list page - Interactive donut chart
Analytical list page - Interactive line chart
Analytical list page - Interactive line chart
Analytical list page - Interactive bar chart
Analytical list page - Interactive bar chart

Show the filter dimension with one measure in the visual filter, not multiple measures

Filter dimensions in the compact filter (filter bar) have exactly one representation in the visual filter.
Do not show the same filter dimension with two or more different measures at the same time in the visual filter bar. The example shows the filter Dimension Year with two different measures Revenue and Quantity. Showing the filter dimensionYear twice is not in sync with the compact filter, where it is shown only once. Furthermore, matching between the two filter types will not work.

If the use case requires you to show a dimension with different measures, consider using an overview page instead.

Do
For each dimension, display exactly one representation in the visual filter bar.
For each dimension, display exactly one representation in the visual filter bar.
Don't
Do not use the same filter dimension with different measures.
Do not use the same filter dimension with different measures.

Live Update / Manual Update

The visual filter bar supports two different modes: live update and manual update. Both the compact and visual filters use the same mode.

Page Content

The content area shows the main content and provides different visualizations of the data. This is the main working area, where users can interact with both the chart and table visualizations at the same time (hybrid view). Chart visualization increases the joy of use, and enables users to spot relevant data more quickly. In addition to the hybrid view, the analytical list page supports a chart-only view and a table-only view. The analytical list page always comes with all three views, which are explained in detail in this section.

Controls

The smart chart is used to display the dataset as a chart. The smart chart drilldown functionality provides a convenient way to analyze the dataset. In addition, the smart chart offers detailed information on the chart data and a breadcrumb that shows the drilldown path. The smart chart is used in the hybrid view and the chart-only view.

Depending on the use case, application development can opt to use either the analytical table or the responsive table.

Hybrid View

The hybrid view uses both chart and table visualizations at the same time. It enables users to analyze data step by step from different perspectives and then drill down to investigate a root cause. Users can interact with both the chart and the table, and act directly on transactional content. In the initial view of the chart, visualize the most important aspects of the whole dataset.

Example: The view shows all the suppliers the user is responsible for, organized by value. By drilling down the material to the plant with the highest/lowest volume, the user can see if materials need to be shifted from one plant to another. The action for shifting the material might be derived directly from the transactional data, which is shown in an analytical table below the chart.

Analytical list page - Hybrid view
Analytical list page - Hybrid view

Table-Only View

The table view provides access to transactional content. The user can act on single or multiple objects, and navigate to the object details or to other applications.

Depending on the use case, application development can opt to use either the analytical table or the responsive table.

Analytical list page - Table-only view
Analytical list page - Table-only view

Chart-Only View

The chart-only view enables users to analyze data step by step from different perspectives, and to investigate a root cause through drilldown, without direct access to transactional content. The smart chart control provides the chart visualization.

This mode is perfect for applications with analytical data that can easily be represented visually using charts, but doesn’t need to be linked to the transactional dataset.

Analytical list page - Chart-only view
Analytical list page - Chart-only view

Responsiveness

The analytical list page supports the flexible column layout from size M upwards on desktop devices.

Behavior and Interaction

KPI Tag and KPI Card

Clicking a KPI tag opens the KPI card, which shows the details for the KPI.

Select Filters in the Visual Filter

Unlike micro charts, the visual filter charts are interactive. If the live search is being used, selecting a filter value triggers data filtering in the content area. Both single and multiple selection are supported.

To select a filter value, the user clicks on a value in the chart. The filter can be removed by either clicking on the value help link, or by clicking on the same value in the chart again. The user can select more filter values using the value help.

Any data point that is selected in a chart still remains selected when the user selects a data point in another chart. Filter values react on each other. If a selected record falls outside the top/bottom three records being displayed, the number of selected records is shown in parentheses at the top right of the chart.

Applying Visual Filters

  • (1) Select visual filter
  • (2) Visual filter applied

Filter Type Switch

Users can toggle between two filter modes: compact filters and visual filters.

Carrying forward filter selections from the visual filter to the compact filter
Any values selected in the visual filter are always carried forward to the compact filters.

Carrying forward filter selections from the compact filter to the visual filter
Filter dimensions that are part of the visual filter are synced to the visual filter. If the dimension value(s) chosen in the compact filter are part of the visual filter, they are shown as selected chart dimensions in the visual filter (single or multiple selections).

Filter dimensions that are not part of the visual filter, parameter values, and interval-based dimensions are applied to the filter query and the content is refreshed.

To show complex conditions, click the link for the number of selected items at the top of the visual filter.

Snap Visual Filter Bar to Top

To save space, users can snap the visual filter bar to the top.

Switch Views: Hybrid, Chart-Only, and Table-Only

Users can switch between the different views: hybrid, chart-only, and table-only. If the user selects values and then switches the view, the selection remains intact. See the table below for more details.

Switch Description
Hybrid view to table view Table selection remains intact
Hybrid view to chart view Chart selection remains intact
Chart view to hybrid view Chart selection remains intact; corresponding table selections are displayed
Table view to hybrid view Table selection remains intact

Show/Hide Table Entries in Hybrid View and Table View

The table toolbar for the analytical list page offers a Show   and Hide    table entries feature as a toggle switch in the hybrid and table views:

  • If the Show icon is active, the table shows all items. These include highlighted entries (where values are selected in the chart) and non-highlighted entries.
  • If the Hide icon is active, the table shows only items that are selected in the chart.

For example, if the user selects New Line Design as Customer in the chart, all records relating to New Line Design are highlighted (but not selected) in the table. Note that the record is still highlighted even if Customer is not displayed as a column in the table. If the table rows are grouped, the entire grouping is highlighted, even if only one record within the grouped set is affected by the chart selection. All values that are not selected in the chart are “hidden” and are not shown in this table mode.

Show/Hide Items Selected in the Chart

  • Show all items
  • Show only items selected in the chart

Guidelines

Visual Filter

  • Always configure both a visual filter and a compact filter.
  • Use the visual filter as the default whenever possible.
  • If parameter values are required, we recommend using the compact filter as the default filter mode.
  • Use the live search for both filter types whenever possible.
  • Always use a line chart to show a time series. Do not use a line chart to show categories; use a bar chart instead.
  • Use the following naming convention for the filter title, using title case: <Measure Name> by <Dimension Name> in <Scale Factor> <Unit of Measure>.
    For example, Project Costs by Project in K EUR, Sales Volume by Commodity in M PC.
  • Filter dimensions in the compact filter bar have exactly one representation in the visual filter.

Content Area

  • Hybrid view / chart-only view: Show the most important aspects of the dataset in the main chart.

Layout

  • Do not use tabs in the analytical list page.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • No links.

Introduction to SAP Fiori Elements

SAP Fiori elements (formerly known as smart templates) provide a framework for the most common application patterns.

The application team selects the relevant floorplan and adds semantic and structural data using metadata annotations. The framework then generates the application screen.

SAP Fiori elements ensure design consistency and compliance with the latest design guidelines, while reducing the amount of frontend code needed to build SAP Fiori apps.

Information
SAP Fiori elements are part of the SAPUI5 delivery.
SAP Fiori elements – The production line for UIs
SAP Fiori elements – The production line for UIs

Supported Floorplans and Layouts

The following floorplans are available as SAP Fiori elements:

The SAP Fiori elements framework supports the dynamic page layout for all available floorplans. In addition, the flexible column layout is supported for all available floorplans except the overview page, which is not allowed within the flexible column layout.

SAP Fiori elements use the global edit flow, which includes draft handling, or the local edit flow without draft handling. SAP Fiori elements also offer message handling.

Overview page
Overview page
List report
List report
Worklist
Worklist
Analytical list page
Analytical list page
Object page
Object page

Usage

You can use the SAP Fiori elements framework if the floorplan and layout you need for your app design are supported. The overview page floorplan, analytical list page floorplan, dynamic page layout, and flexible column layout are all fully supported. If you want to use the object page or list report floorplans, check the respective guideline articles to see which features are supported for SAP Fiori elements.

If you want to use floorplans that are not supported by the SAP Fiori elements framework, or if you require several features that are not supported by the respective floorplan in SAP Fiori elements, you should go with a freestyle app instead.

One of the big benefits of SAP Fiori elements is the reduction in development effort. This is especially important for features like draft handling or the flexible column layout. If you need these features in your app, you should go with SAP Fiori elements.

For an overview of all available floorplans and layouts, see Overview – Layouts, Floorplans, and Frameworks.

Responsiveness

The responsiveness of SAP Fiori elements depends on the responsiveness of the floorplans and controls used in your app.

The SAP Fiori elements framework lets you influence the responsiveness of certain controls. For example, you can adapt the overflow behavior of actions and fields in the overflow toolbar, or change the pop-in behavior of columns in a responsive table.

Developer Hint
You can use the priority annotation to influence the responsive behavior of certain controls. This annotation supports the values “high”, “medium”, and “low”.

Adjustments

The behavior and interaction generally follows the guidelines for the respective floorplan or concept. If the guideline offers choices, the SAP Fiori elements framework offers the most generic option or, where possible, provides different options to choose from.

For example, the default table for list reports is the responsive table (or, for aggregated services, the analytical table). Other table types are offered as well, but have to be actively enabled by the application developer.

Deviations from the guidelines are sometimes necessary due to technical limitations, which are listed in the respective guideline artices. These limitations are usually short term and will be solved in future releases.

Developer Hint
You can adjust certain features by implementing breakouts, by adapting the manifest.json of your app, or through annotations or UI adaptation.

Mandatory Adjustments

Some UI texts provided by the SAP Fiori element contain generic placeholders. Always replace the default placeholders with an application-specific text. For more information about placeholder texts in SAP Fiori elements, see Replacing Standard UI Texts.

Examples of generic and adjusted texts:

Default Text Adjusted Example
List Report Create Object Create Sales Order
Object Page New Object New Sales Order
Overview Page Could not perform action Unable to approve the request

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Overview Page (SAP Fiori Element)

Overview page
Overview page

View, filter, and take immediate action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page. The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

At a glance

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Easy filtering

  • Micro actions let users react on the spot

Usage

Use the overview page if:

  • You want to provide an entry-level view of content related to a specific domain or role.
  • Users needs to filter and react to information from at least two different applications to complete their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page.
  • You plan to have at least three cards. These cards should not all be of the same type.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page instead.
  • You want to show information about one object only. In this case, use the object page instead.
  • You just represent one application and less than three cards. In this case, use the object page instead.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

Different entry points in SAP Fiori
Different entry points in SAP Fiori

As you can see in the picture above, the overall content scope (shown in gray) becomes more focused with each interaction step. The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

Only provide an overview app for a role if it makes sense to do so. An overview page brings together information from different sources that support a specific task focus or information need. If a role or user has several such main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, and allow him or her to manage the performance reviews of the team. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that he or she is responsible for in the role of quality manager.

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps.

The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window. In the screen flow, always position the overview app between the SAP Fiori launchpad home page and the SAP Fiori app. Never start overview apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Responsiveness

The overview page floorplan is fully responsive. The card layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes.

Overview page – Size L/XL
Overview page – Size L/XL
Overview page – Size M
Overview page – Size M
Overview page – Size S
Overview page – Size S

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards. The card layout determines the size and position of the cards.

Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

Dynamic Page in the Overview Page

The overview page can consume four different versions of the dynamic page, giving you the flexibility to support different requirements. All the variants have two things in common:

  • The footer toolbar is not included.
  • There are no global actions in the header title.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar. In addition, the variant management control lets users share user-defined variants (Save Variant feature).

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. The initial default uses the snapped mode, since content is already available on the cards and users can start right away. When the user scrolls or clicks, the header content expands as defined. The header title offers the share menu, which enables the actions Send Email and Save as Tile.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Snapped mode for size XL/L/M
Dynamic page variant 1 – Snapped mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Snapped mode for size S
Dynamic page variant 1 – Snapped mode for size S
Share menu
Share menu

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text, which serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/snapped mode for size XL/L/M
Dynamic page variant 2 – Expanded/snapped mode for size XL/L/M
Dynamic page variant 2 – Expanded/snapped mode for size S
Dynamic page variant 2 – Expanded/snapped mode for size S

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size S
Dynamic page variant 3 – Size S

Variant 4 – Text in the Header Title and Smart Filter Bar

In this variant, the header title contains a text, and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Snapped mode for size XL/L/M
Dynamic page variant 4 – Snapped mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Snapped mode for size S
Dynamic page variant 4 – Snapped mode for size S

Overview Page Layout

The overview page layout describes the position and size of cards in the content area below the dynamic page header (header title and header content).

Only place cards on the overview page. Never add tiles.

Card Layout

The card layout contains responsive (collapsible) columns of cards. The card width is fixed, and the height is determined by the card type and the embedded control.

There is no limit on the number of cards included. To view all the cards, the user just scrolls down.

Fixed card layout
Fixed card layout

The card layout uses padding on both sides. The cards are displayed inside collapsible columns, making the page fully responsive. When the user resizes the browser or uses a smaller screen, the columns containing the cards collapse. In this way, the layout can accommodate typical laptop screens, larger desktop monitors, and mobile devices:

  • Phone: 1 column
  • Tablet (portrait): 2 columns
  • Laptop / tablet (landscape): 3 columns
  • Large desktop: 4 columns
  • Extended monitor: 5 columns (maximum)

The width of the cards is tied to the column width. Breakpoints for the different screen resolutions determine whether the column width is 20 or 25 rem. The cards inside the columns adapt their width automatically. By contrast, the height of the cards is flexible, and depends on the content and type of card.

Rearranging Cards

Users can reposition cards on the overview page by dragging them to a different location. As the user drags a card, it swaps place with any cards in its path. Releasing the mouse or lifting the finger from the touch surface completes the move. To avoid gaps, cards always snap to the next free space in the row, or to the start of the next row.

The cards are arranged as a “Z” flow: cards are ordered from left to right, starting with the first card on the top left of the page. For example, if a 5-column layout is reduced to 4-column layout, the fifth card drops to the next row, assuming the leftmost position underneath the first card.

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the Me Area under Manage Cards. A dialog appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Overview page – Manage cards
Overview page – Manage cards
Overview page – 'Manage Cards' dialog (initial loading status)
Overview page – 'Manage Cards' dialog (initial loading status)

Cards

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. Technically, a card is a smart component that uses UI annotations to render its content. Cards differ in the content they display: They can show a chart, a list, a table, informative text, or a combination of two elements. However, cards never have editable fields.

Cards can focus on a single object or topic, or on a group of objects.

You can set a specific refresh interval for the card content. All cards are refreshed at once, so the shorter the refresh interval, the more disruptive it is for users.

Card Components

Each card has three components: a header area, a content area, and a footer area. The header and content areas are mandatory. The footer area is only used for actions in the quick view card.

Make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

Overview page – card components
Overview page – card components

Card Header

The card header area is mandatory, and serves three purposes:

  • It indicates what the card is about.
  • It functions as a navigation area for opening the parent app, whereby the whole header area is clickable. We recommend offering this navigation on all cards (exception: link list card). 
  • A counter shows how many items are on the card in relation to the total number of relevant items.

The height of the header area is variable; it expands vertically to accommodate the text. The header area can contain two text fields: a mandatory title, and an optional subtitle. The primary purpose of the header area is to identify the content source, summarize the focus of the card (title), show any relevant parameters (subtitle), and offer navigation to the content source (parent app).

Title

The title is mandatory and represents the card’s “point of view”. In one or two words, it explains why this card exists and why a user might want to use it. It is a natural language reflection of the annotated view. Titles that exceed three lines are truncated with the ellipsis (…).

Subtitle

The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The use of the subtitle can differ, depending on the card type. Subtitles that exceed one line are truncated with the ellipsis (…).

Card header with counter
Card header with counter

Counter 
The counter in the header area indicates how many items are showing on the card in relation to the total number of relevant items:

Format: [Items on Card] of [Total Items]
Example: 5 of 40 

The counter is right-aligned and is never truncated (the title wraps instead). The width of the counter is flexible, depending on the amount of data. [Items on Card] can show a maximum three digits, and [Total Items] a maximum of four digits. For larger numbers, a scaling factor is shown. If there is an issue loading a card, or no items are found for the filter criteria, no counter is shown.

Card header with all counted items
Card header with all counted items
Card header with scaled counter
Card header with scaled counter
Card header without the counter
Card header without the counter

Card Content

The content area is mandatory and is reserved for application content. Content is currently displayed on cards by embedding SAPUI5 controls that specify the properties and data format. For example, an embedded standard list control provides formatting, such as row height, font sizes, and the number of text blocks.

Card Footer

On quick view cards that display information on a single object or data point, you can use the footer area to offer related actions. In this case, the overflow toolbar control is used. The height of the footer bar is fixed.

Card footer area with actions
Card footer area with actions

Formatting Dates, Times, Amounts, and Currencies

Apply the following formats:

  • Dates: The default is the relative date format (for example, Today). However, you can also use the medium date format (such as Aug 7, 2015).
  • Times: Times are not visible per default, but if you need to show a time, use the short format (for example, 11:28 AM).
  • Integers/Float/Currencies: Use the short format (for example, 1K for 1000).

Navigation and Interaction

The navigation and interaction depends on the technical card type:

This section looks at the different technical card types, how card views can be combined, and how to incorporate actions.

Single-Object Cards

Cards that feature content with a single focal point, detail, or entity are called single-object cards. An example is a quick view card with information about a particular product. Analytical cards are also single-object cards. The header area of this card type always navigates to this specific focal point, detail, or entity. The content area can also have interaction areas (for example, a section in a chart, or a telephone number for a contact). However, only quick view cards can have actions in the footer area.

Interaction for a single-object card
Interaction for a single-object card

Object Group Cards

Cards that feature a subset of items grouped by a common criterion are called object group cards. A typical example would be a list of purchase orders grouped by delivery date, amount, or supplier. The cards do not have actions, but each row or list item is selectable, thus providing direct navigation to the object details within the parent application. The header area of this card type always navigates to all items in the list or table. Object group cards include all types of list cards, bar chart list cards, and table cards.

Interaction for an object group card
Interaction for an object group card

Link List Cards

Link list cards allow you to display a collection of links or images that can reference both internal and external targets.

  • Links can navigate to a target or open a popover with additional information.
  • Clicking an image opens an image carousel.
Interaction for a link list card
Interaction for a link list card

Stack Cards

A stack card is a special card type for showing a collection of single-object cards. Stack cards have 3 components with different navigation areas:

  • The top-level stack card opens the collection and contains two clickable areas: the left area navigates to the parent app, and the right area opens the object stream.
  • The object stream shows individual cards that represent objects from the parent application. The object stream heading links to the parent application, while individual cards can contain links and actions relating to the respective object. A Close button returns the user to the stack card.
  • The last card in the object stream is the placeholder card. The entire card is navigable and leads the user directly to the parent application.
Interaction for a stack card
Interaction for a stack card
Interaction for a placeholder card
Interaction for a placeholder card

View Switch

You can use a view switch to offer several different content areas on one card, which can help to reduce the number of cards on the overview page. The user chooses the view using a select control. You can only combine views that have a common denominator. The options offered by the select control merely offer different perspectives. For example, a card “Purchasing Spend” (title in the header area) could offer two views “By Material Group” and “By Supplier” (options in the select control). The view switch is located in the upper part of the content area.

You can use the view switch for the following cards:

View switch
View switch

Actions on Cards

Only quick view cards within an object stream can have actions in the footer area. The overflow toolbar manages how the actions are displayed. All actions are right-aligned. Any actions that don’t fit into the available space move into the overflow action sheet, represented by the ellipsis ( ). A maximum of six actions are allowed in the footer area. Only offer actions the user really needs in the specific context.

Footer area with additional actions in the overflow
Footer area with additional actions in the overflow

There are two possible types of action: navigation and function import. Any combination of navigation and function import actions is allowed. Error or confirmation messages are displayed directly on the overview page. Always overwrite the predefined default text for errors in a message box: Formulate your message in plain language (without code), describe the issue precisely, and suggest a constructive solution.

Type: Navigation

Navigation is “intent-based” and takes the user to a different SAP Fiori app that specializes in executing an action. Navigation actions are always multi-click (meaning they can be repeated over and over). The destination screen opens in the same browser window, and any error or task confirmation messages are handled by the supporting application, and not by the overview page.

Type: Function Import

Function imports are custom OData service operations for actions. These actions are handled by the overview page, rather than by another SAP Fiori app. The interaction depends on whether or not the action requires user input:

  • If the action requires additional user input, the input parameters are handled directly on the overview screen without further navigation. A dialog appears on top of the card, allowing the user to enter data or make a selection. An example of additional input might be the rejection reason for a “Reject” action.
  • If the action has no input parameters, the action request is sent immediately. Once the action has been completed, the card disappears from the object stream.

Action on Phone

If an action on a card requires an input dialog box, use a full screen dialog on smartphones.

Card Types

The overview page supports the following standard card types:

Analytical Card

Analytical cards are used for data visualization. They are single-object cards that consist of two areas: a header area that displays the aggregated value of a key measure (KPI), and a chart area that displays a representation of data in graphical format. Analytical cards do not contain a footer area.

The KPI header is mandatory for analytical cards used on the overview page. The KPI header includes the title (mandatory), the KPI with the respective unit (mandatory), and a subtitle (optional). The subtitle can show the filter criteria used for the chart, and can contain up to two lines of text. The KPI itself uses the semantic colors red (negative), green (positive), or gray (neutral). You can also display a percentage indicator (optional) or triangle indicator showing an upward or downward trend (optional).

For more information, see analytical card.

The following (VizFrame) charts are available:

List Card

List cards are a type of object group card, and display a set of items in a vertical list. List cards use the sap.m.List container in the content area.

 

List Card Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set. The counter indicates how many items are showing on the card in relation to the total number of relevant items: [Items on Card] of [Total Items], as in 5 of 40.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application. Only aggregate list items in exceptional cases.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

List Item Types

Two different list item types are available:

  • The standard list item always shows 3 pieces of information and inherits the properties of the SAPUI5 control sap.m.StandardListItem.
  • The extended list item can show up to 6 pieces of information and inherits the properties of the SAPUI5 control sap.m.ObjectListItem.

You can only use one type of list item on any given card.

 

Size of a List Card

List cards resize according to the content available. The height can vary, depending on the number of text fields. Show no more than five standard list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

In addition, you can display the data on the right-hand side in semantic colors.

List card with standard list item
List card with standard list item
List card with extended list item
List card with extended list item

Bar Chart List Card

Bar chart list cards are a type of object group card, and display a set of items in a vertical list. Unlike list cards, bar chart list cards are embedded in another component: the comparison micro chart. This allows you to display negative values and use semantic colors.

 

Bar Chart List Card Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set. The counter indicates how many items are showing on the card in relation to the total number of relevant items: [Items on Card] of [Total Items], as in 5 of 35.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application. Only aggregate list items in exceptional cases.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

Bar Chart List Item Types

Three different list item types are available:

  • The standard list item always shows 3 pieces of information.
  • The condensed list item can show up to 4 pieces of information.
  • The extended list item can show up to 6 pieces of information.

You can only use one type of list item on any given card.

 

Size of a Bar Chart List Card

Bar chart list cards resize according to the content available. The height can vary, depending on the number of text fields. Show no more than five standard/condensed list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Bar chart list card with standard list item
Bar chart list card with standard list item
Bar chart list card with condensed list item
Bar chart list card with condensed list item
Bar chart list card with extended list item
Bar chart list card with extended list item

Link List Card

Link list cards allow you to display a collection of links or images that can reference both internal and external targets. Links and images are handled as two separate variants:

 

Variant Type: List

The list variant shows a collection of links that can navigate to a target or open a popover with additional information. You can also show an optional subtitle below the link with a description or additional information. The link text and subtitle are each limited to one line.

You can display an icon or image before each link. For example, you might want to include app icons for set of links to recently-used apps, or images for a list of recent contacts. Use icons and images consistently:

  • If you opt to use icons, show an icon before every link.
  • If you include images, use a placeholder for images that are not available.
Link list card – Variant type
Link list card – Variant type "list"
Link list card – Variant type
Link list card – Variant type "list" with icons
Link list card – Variant type
Link list card – Variant type "list" with images

Variant Type: Image

The image variant uses the sap.m.Carousel control to display one or more images. If the carousel contains only one image, the Previous and Next icons and the paging indicator are not visible. The link and an optional subtitle are displayed above the carousel. The link text and subtitle are each limited to one line.

Link list card – Variant type
Link list card – Variant type "image"

Table Card

Table cards are a type of object group card, and display a set of items in a table format. Table cards use the responsive SAPUI5 control sap.m.Table.

 

Table Card Navigation

Clicking the header area of a table card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set. The counter indicates how many items are showing on the card in relation to the total number of relevant items: [Items on Card] of [Total Items], as in 3 of 10.

Clicking a list item (row) on the card opens the detail view for that specific object in the same parent application. You can also use the smart link control in table cards. However, we recommend using smart links only if they crucial for your use case. Otherwise, you risk confusing users with multiple navigation targets.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

Size of a Table Card

Table cards resize according to the content available. The height can vary depending on the number of table cells. Tables are limited to a maximum of 3 columns and 3 rows, with a maximum of 3 lines of text per row. To see the full result set, the user needs to navigate to the parent app. All three columns can show either a data field or a data point. Data points can use semantic colors.

Table card
Table card

Stack Card

A stack card is a special collection of single-object quick view cards, based on a topic or action. Unlike the other card types, the top-level stack cards don’t show any application content. Instead, they act as an entry point to an object stream containing multiple cards.

Stack cards have the following components:

  • The title is the top element and is always required. It is used as the heading for the detail view, and comprises 1-2 lines of text.
  • The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The purpose of the subtitle is explain the content of the stack in one line, so its usage depends on the context.
  • The stack content count indicates the number of cards in the stack (object stream). The object stream can contain up to 20 cards. Below the number of cards in the stack, you see the total number of items returned for the annotated view (for example, “20 of 42”).

Overview Page - Stack Card

The top-level stack card contains two clickable navigation areas:

  • The left area and View All link navigate to the parent application, where the user can see all the objects returned for the annotated view (42 in the example above). The placeholder card and heading inside the object stream have the same navigation target.
  • The right area opens the object stream, which contains a scrollable collection of cards presented in an overlay format. The user can browse individual cards, with the option to view, inspect, or take action.

Quick View Card

Quick view cards are single-object cards. They display the basic details for one object, such as the name, address, and phone numbers for a contact. This card type is only available within the object stream; you can’t place quick view cards on the overview page itself. The quick view card inherits the SAPUI5 element sap.m.QuickView.

The header area contains a static text, such as Purchase Order, and an optional dynamic text, such as 1005-3345. In this way, each card header can show different content. Clicking on the header area of the card opens the detailed view of the object in the corresponding parent app. If the content area of a card cannot display all the information, a scrollbar appears on the right. Only the footer area of the quick view card can currently provide actions.

Quick view card for a contact
Quick view card for a contact
Quick view card for a product
Quick view card for a product
Quick view card for a purchase order
Quick view card for a purchase order

Object Stream

Overview page – Object stream
Overview page – Object stream

Clicking the right-hand area of the stack card opens the object stream. The object stream appears on top of the overview page as a modeless overlay, and serves as a layer for showing quick view cards with actions. The overlay has heading on the top left, and a Close button on the right. The heading is the same as the stack card title, and links to the full result set in the parent application (same target as the left-side navigation on the stack card and the navigation from the placeholder card). Clicking outside the overlay area also closes the object stream.

The object stream can have up to 20 cards, which all get their content from the same parent application. By default, the cards are ordered chronologically, with the most recent items first. However, app developers can define the best object stream sorting option for their own needs and custom content. If the number of cards exceeds the available space in the overlay window, an arrow icon appears on the right for scrolling. Mobile device users can swipe to see more cards. If the object stream is empty, the stack link is not active and the overlay cannot be opened. The stack count number displays 0. If only one item is returned, the object stream contains just a single card.

The header area of the quick view cards in the object stream navigates to the detail view for that specific object in the parent application. The footer area of the quick view cards can also offer actions.

 

Object Stream – Scroll Arrows

Scroll arrows only appear on desktop devices. If all the cards in the object stream fit on the screen, the arrows are not visible. If the number of cards exceeds the available space, an arrow icon appears on the right when the user mouses over the object stream overlay. Mousing over the arrow button area scrolls the cards across the screen from right to left. As soon as the first card on the left moves out of the visible overlay area, a second arrow appears on the left for moving in the other direction. Once the last card is in full view, the arrow on the right disappears.

Object Stream – Placeholder Card

If the number of items returned for the annotated view exceeds the maximum 20 cards allowed in the object stream, a placeholder card is added automatically at the end of the stream (as card 21). The entire placeholder card is navigable, and takes the user to the full result set in the parent application.

The text on the placeholder card is composed as follows:

See all [total] [items] in the“[app name]” app.

Where:

  • The values for [total] and [app name] are supplied by the system.
  • The term for [items] must be rephrased by the app team to reflect the type of item or business object.

Examples:

  • See all 42 items awaiting approval in the “Approve Leave Requests” app.
  • See all 42 purchase orders awaiting approval in the “Approve Purchase Orders” app.
Overview page – Placeholder card
Overview page – Placeholder card

Object Stream – Tablet Version

On tablet devices, the modeless overlay expands horizontally. It also expands vertically to accommodate the card height and allow space for the title and Close button. The user can swipe through cards and perform micro actions. Swiping a card in view moves the entire object stream. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

 

Object Stream – Phone Version

On smartphones, the overview page layout collapses to a single column in both portrait and landscape modes. Tapping on the right-hand navigation area of a stack card opens the object stream on top of the overview page in a new full screen window.

The object stream expands horizontally and vertically to accommodate the card height, and to allow space for the title and Close button. The user can swipe through the cards and perform micro actions. Swiping a card moves the entire object stream. Since the cards are too large to fit on the screen in landscape mode, users can also scroll vertically to see the full card content. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

  • Overview page – Object stream interaction size M (landscape)
  • Overview page – Object stream interaction size M (portrait)
  • Overview page – Object stream interaction size S (lportrait)
  • Overview page – Object stream interaction size S (landscape)

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

Object Page (Floorplan + SAP Fiori Element)

The object page floorplan allows the user to display, create, or edit an object. This is now the recommended floorplan for representing both simple and complex objects in SAP Fiori. It has replaced the flat object view floorplan and is set to replace the object view floorplan. The object page floorplan comes with a flexible header, a choice of anchor or tab navigation, and a flexible, responsive layout. These features make it adaptable for a wide range of use cases.

You can implement the object page floorplan in two ways:

  • Use the pre-built SAP Fiori element (formerly known as a smart template). This implementation uses OData annotations, and allows you to speed up development if the supported feature set matches your requirements. For an overview of the supported features, see the SAP Fiori Element section.
  • Implement the floorplan yourself using the respective SAPUI5 controls.
Object page floorplan
Object page floorplan

Usage

Use the object page floorplan if:

  • Users need to see, edit, or create an item with all its details.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

  • Users want to edit several items at the same time. Use the list report floorplan instead.
  • Users need to find relevant items without knowing the exact item details. Use the list report floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner). Use the initial page floorplan instead.
  • Users need to be guided through a series of steps when a new object is created. Use the wizard floorplan instead.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected. Use the wizard floorplan instead.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL).

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The layout for size XL (large display) contains four columns.

The default layout for size L (desktop) contains three columns. You can also use an optional two-column layout.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Structure

The object page is a full screen floorplan with a display mode, a create mode, and an edit mode.

In all modes, the object page contains:

  • A snapping header
  • A navigation bar
  • A content area

The following sections explain these components in more detail.

Schematic visualization of object page
Schematic visualization of object page

Snapping Header

The snapping header is the uppermost element of the object page floorplan. It contains key information about the business object and provides the user with the necessary context. The header also contains global actions for the object.

Toolbars

The object page supports two toolbars:

  • Header toolbar: Use this toolbar for global actions such as Edit, Delete, Copy and Share.
  • Floating toolbar: Use this toolbar for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

This applies to all object page modes (display, edit, and create).

Responsive overflow toolbar
Responsive overflow toolbar

Navigation

There are three ways to navigate within the object page:

  • Anchor bar (by default)
  • No navigation (flat scrollable page)
  • Tabs

Usage

  • To offer a flat page for a simple object, remove the navigation.
  • For more complex objects, use the anchor or tab navigation.
Object page – Anchor navigation
Object page – Anchor navigation

Anchor Bar and Overflow

The anchor bar is the default navigation control for the object page. It consist of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint

Anchor Bar and Overflow

Use title case for the anchor bar texts. To do this, you need to change the default capitalization (block caps) by changing the the property upperCaseAnchorBar to “false”.

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow overview button on the right of the navigation bar ( ) opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow overview button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the document.

Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow overview button
  8. Overflow overview dropdown
  9. Section (hover) in overflow overview
  10. Section in overflow overview
  11. Subsection in overflow overview

Behavior and Interaction

  • Clicking an anchor link scrolls the page to the selected section.
  • Clicking a section anchor that contains more than one subsection opens a subsection menu.
  • Clicking a subsection scrolls the page to the selected subsection. The keyboard left and right arrows allow the user to move between the anchor links.
  • Hovering over the fade area to the left or right of the anchor bar causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
  • Clicking the overflow scroll button (right arrow) scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
  • Clicking the overflow overview button ( ) displays a hierarchical dropdown list with all the sections and subsections of the document. Clicking an item in the overflow list scrolls to the respective section or subsection.
Object page – Anchor behavior and interaction
Object page – Anchor behavior and interaction

Hiding the Navigation

An object page can be used in a similar way to a flat object view. This is achieved by hiding the navigation bar from the object page, leaving a flat scrollable object. We recommend using this flat view for simple content that doesn’t require anchor navigation.

Tab Navigation

As an alternative to anchor navigation, you can also opt for tab navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. Tab navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional and the default state is “false”. If the state is set to “true”, a dropdown arrow is shown next to the tab. Clicking on the tab displays a dropdown menu with the subsection anchors for that tab.

Object page – Tab navigation
Object page – Tab navigation

Breadcrumbs

If the object page uses a hierarchical parent-child drilldown, you can offer a breadcrumb for navigation. The breadcrumb is part of the snapping header.

Content Area

The object page content consists of sections and subsections arranged in a column layout. For large documents, you can enable a lazy loading mechanism (property: enableLazyLoading) to mitigate the loading time.

Sections

Sections are containers for subsections. They provide the basic structure for navigation, and are directly reflected in the navigation bar. Sections can have a title, subsections, and actions. However, they cannot contain controls.

Use title case for the section title (property titleUppercase = “false”). The title can have an item counter, which is displayed in parentheses. If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Global actions are always placed at subsection level. Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for global actions at the subsection level.

Subsections

Subsections are the containers for actual content. Always place individual controls inside the subsections. Subsection content is arranged according to the column layout approach for the respective screen size. A subsection can include containers for different controls (mixed content).

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can also display everything by selecting the Show All button at the bottom right of the subsection.

Each subsection can have a toolbar, which is placed at subsection header level on the right. The toolbar contains actions that affect the content of the subsection.

Subsections within the same section are separated by a gray horizontal line. Subsections can have an item counter, which is displayed in parentheses next to the subsection header.

You can include various types of related content in one subsection. The layout blocks for the object page give you the flexibility to combine different content types.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times, and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.
Object page – Blocks
Object page – Blocks

Contacts

The contacts on the object page are technically a list, but they can be represented visually as a card.

The cards can contain:

  • An image (optional)
  • A title (mandatory)
  • A subtitle (optional)
  • A text snippet consisting of two lines maximum (optional)

A single card covers the column’s entire horizontal space. To avoid alignment problems, all cards are the same height. The card with the most content defines the overall height for all cards. The image can be rectangular or round. It shows in the top left corner of the card. The content of the card never truncates. If there is not enough space to display the information, it wraps onto the next line.

Content type – Contacts
Content type – Contacts

Tables

In an object page, tables with up to 20 expected items can be displayed right away without lazy loading.

If a table is expected to have more than 20 items, use one of the following 3 options for long tables:

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial amount of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, this option should be used only for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. Here it is important to place the table within a tab as the only or at least the last element and to enable the scroll to load behavior.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, the table itself should be restricted to a reasonable amount of items. We recommend only showing a preview of the data in the table, which should not contain more than 20 items. Ideally, you should have about 10 items. This can be either be achieved by prefiltering and/or by sorting the table, and if necessary, by restricting it to a fixed amount of items (such as top 10). To provide the user with a way to work with the entire table, a navigation to a separate list report containing the full table must be offered.  This navigation should be located below the table in the form of a right-aligned link labelled Show All (x), with x representing the total amount of items in the table.

In the object page, we recommend that you do not use the analytical, grid and tree tables. Instead, use a responsive table and offer navigation to a list report with the table types mentioned above.

For all of the three options mentioned above, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Grouping should be avoided.

Table with navigation to a separate list report
Table with navigation to a separate list report

Child Page Representation

In object pages with drilldown navigation, child pages are represented in three ways:

  • Visual representation in the header: A narrow blue band is displayed in the left margin of the snapping header.
  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Item navigation arrows: Up and down arrows in the application toolbar allow the user to navigate between subitems without going back to the original list.

Behavior and Interaction

Edit

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create). In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area for edit mode to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see manage objects – create, edit, delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

Object page – Global edit with header container and independent header facets
Object page – Global edit with header container and independent header facets

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit on a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Object page – Partial edit with dialog
Object page – Partial edit with dialog

Create and Edit Subobjects

The following options are available for creating or editing subobjects:

  • Navigation to a subobject page
  • Inline create or inline edit in a table
  • Dialog containing the fields of the object

If the subobject has less than 8 fields, use a dialog or the inline create/edit option (no separate page for the subobject). Exceptions can apply if additional content for the subobject is available but not part of the edit process, or if other apps need to offer deep links to the subobject page.

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:
•Who made the changes
•When the last changes were made

The popover closes when the user clicks or taps the Close icon or anywhere outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, use the placeholder text “New ” (for example, “New Purchase Order”). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Guidelines

Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing a clear context.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.
Do
Object page floorplan – Good example of how to arrange actions
Object page floorplan – Good example of how to arrange actions
Don't
Object page floorplan – Bad example of how to arrange actions
Object page floorplan – Bad example of how to arrange actions

Tab Navigation

Use tab navigation if you need a facet approach to your content. This could be due to performance issues in a flat view, or in response to a specific user preference. If you need to use icons, tabs as process steps, or tabs as filters, use the object view floorplan.

Not a Content Dump

Avoid using the object page as a universal container for masses of information. You should use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.

Simplify Content for Your Users

Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request. Furthermore, only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Components and Launchpad Shell Bar – Page Title and Navigation Menu.

SAP Fiori Element

Use the table below to see which features are available for the “object page” SAP Fiori element.

Feature Status Comments
Snapping Header
General
Fiori 2.0 merged header Supported
Header always expanded Supported
Header container on/off Supported
Header container on/off in different modes Supported
Header container expand on click Supported
Child page navigation Supported
Subtitle optional Supported
Arrow icon showTitleSelector Not Supported
Breadcrumbs Supported
Favorite behavior Not Supported With indicator next to the title.
Flag behavior Not Supported With indicator next to the title.
Unsaved changes behavior Supported With indicator next to the title.
Lock behavior Supported With indicator next to the title.
Header Facets
Different header facets in different modes Supported
Wrapping behavior for header facets Supported
Image facet square Supported
Image facet round Supported
Image header facet with placeholder Supported
Image header facet in different sizes Supported
Key value facet with unit Supported
Key value header facet with trend Not Supported
Key value facet with same text/numeric size Supported
Microchart header facet Partially supported Currently available for bullet and area charts.
Microchart header facet subtile optional Supported
Microchart header facet footer optional Supported
Microchart header facet with rating indicator Supported
Microchart header facet with progress bar Supported
Form header facet with optional labels Supported
Form header facet with icons as labels Not Supported
Form header facet with links as values Supported
Form header facet value with semantic color Supported
Key value header facet with link as value Supported
Key value header facet with semantic color on value Supported
Plain text header facet Supported
Breakout header facet Not Supported This also includes adding controls to existing header facets.
Toolbar
Header toolbar select, combo box, multi-combo box Not Supported
Header toolbar semantic buttons Supported
Header toolbar highlight buttons Supported
Header toolbar segmented buttons Not Supported
Toolbar overflow Supported
Toolbar overflow prioritization Supported
Icons as buttons Supported
Action sheet in buttons Supported
Prioritization of custom actions in toolbar Supported
Show Edit Header button (partial edit) Not Supported
Navigation
Navigation hidden if object has only one subsection Supported
Counts in anchors and section/subsection headers Not Supported
Carousel overflow for horizontal navigation Supported
Mobile navigation behavior (dropdown) Supported
Navigation overflow overview button Supported
Tab navigation Supported
Tab with anchor subnavigation Not Supported
Anchor behavior Supported
Content
General
Partial edit Not Supported
Forms in content Supported For more on the form features, see the forms article.
Actions in forms Partially Supported Currently only via breakout. Actions go into the subsection toolbar.
Timeline in content Not Supported
Carousel in content Not Supported
Contact cards in content Partially Supported
Mixed content Supported
Block controls Not Supported
Lazy loading Work in Progress
Side panel Not Supported
Scroll to specific section on loading Not Supported
Layout
Content layout in size S (1 column) Supported
Content layout in size M (2 columns) Supported
Content layout in size L (3 columns) Supported
Content layout in size L (2 columns) – optional layout Not Supported
Content layout in size XL (4 columns) Supported
Sections and Subsections
Toolbar in subsections Not Supported
Toolbar in sections Not Supported
Toolbar in sections containing only one subsection Not Supported
Subsection toolbar with custom actions Not Supported
Subsection toolbar with buttons Not Supported
Subsection toolbar with highlighted buttons Not Supported
Subsection toolbar with semantic buttons Not Supported
Subsection toolbar with segmented buttons Not Supported
Subsection toolbar with select combo box or multi-combo box Not Supported
Subsection toolbar with buttons with actions sheets Not Supported
Use of priorities in sections/subsections Not Supported
Tables
Responsive list in content Not Supported
Responsive table in content Supported For specific table features, see the guidelines for tables.
Grid table in content Supported For specific table features, see the guidelines for tables.
Display responsive table instead of grid table on mobile devices Supported For specific table features, see the guidelines for tables.
Analytical table in content Supported For specific table features, see the guidelines for tables.
Display responsive table instead of analytical table on mobile devices  Supported For specific table features, see the guidelines for tables.
Tree table in content Not Supported

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


Block Layout

Information

This layout has been designed specifically for the tool landscape for the SAP Cloud Platform. It is not intended for use in regular SAP Fiori applications. 

Intro

The block layout is used to display content in a section-based manner. It features horizontal and vertical subdivisions and full-width banners seen frequently in contemporary Web design. Background colors are attached directly to these areas within the layout. As well, special full-width sections of the block layout enable horizontal scrolling through a set of areas.

General page structure of a tool using the block layout
General page structure of a tool using the block layout
Block layout standalone
Block layout standalone

Usage

Example use cases include landing pages and catalog-like pages. In landing pages, the block layout may serve as a banner-like presentation of illustrative icons with associated text. By placing pictorial and textual elements side by side in different areas, a content relationship is established. In catalog-like layouts, the block layout serves as a flexible container for diverging content, such as headings, explanatory texts, code snippets, remarks, and examples.

It is also possible to have clickable blocks with their own hover and pressed states.

There are four types of block layout: layout only (default), light, and accent background colors, as well as a variant for dashboard pages.

Schematic block layout
Schematic block layout
Schematic block layout with a section scrolling horizontally
Schematic block layout with a section scrolling horizontally

Use the block layout if:

  • You want to display section-based content. Place elements next to each other to indicate a content relationship.
  • You want to display KPIs in the dashboard-variant. Do not use other variants for KPIs.

Do not use the block layout if:

  • You want to display properties or features of one content item. Use the object page floorplan instead. Links within a block must lead to areas outside of the block. As well, enable controls to update only their own containers and not other containers.

Layout

The block layout is divided into horizontal sections, which take on the full width of the available screen real estate. Their screen height is determined by their inner content, which prevents vertical scrolling. If needed, the width of sections can also be set to the following predefined ratios (for the sizes XL, L and M):

  • 1 block: 100%
  • 2 blocks: 75% and 25% / 25% and 75%
  • 2 blocks: 50% and 50%
  • 3 blocks: 2 × 25% and 50% / 50% and 2 × 25% / 25% and 50% and 25%
  • 3 blocks: 3 × 33%
  • 4 blocks: 4 × 25%

Horizontal scrolling sections always have a width of 100%.

Responsiveness

The block layout offers responsive behavior. There are three breakpoints, which results in four supported sizes: XL, L, M, and S. As with the responsive grid (another generic layout control), these breakpoints apply both to the page and block layout. However, the page layout’s breakpoints react to screen width, whereas the breakpoints of the block layout react to the width of the control itself.

Ratios of areas in different contexts

Blocks per section XL, L M S
1 100%  100% 100%
2 75% and 25%
25% and 75%		 75% and 25%
or
25% and 75%		 100% each*
100% each*
2 50% and 50%  50% and 50% 100% each*
3 2 × 25% and 50%
50% and 2 × 25%
25% and 50% and 25%		 2 x 50% and 100% over two rows
or
100% and 2 x 50% over two rows		 100% each*
100% each*
100% each*
3 3 × 33%  3 x 33% 100% each*
4 4 × 25%  2 x 50% over two rows 100% each*

*Blocks wrap and are displayed underneath each other

Responsive behavior of sections and areas
Responsive behavior of sections and areas
Responsive behavior of sections and areas
Responsive behavior of sections and areas
Responsive behavior of a section with horizontal scrolling
Responsive behavior of a section with horizontal scrolling

The width of the horizontal scrolling area in different device contexts

XL, L M S
22.5% or 40% depending on the number of areas
3 to 5 areas: 40%
6 to 10 areas: 22.5%		 40% 90%

Types

There are four types of block layouts:

  1. Default: This layout does not use any background colors.
  2. Light: Areas use predefined colors found in the SAP Fiori 2.0 visual design language. These colors follow a specific order specified in the control. If there are more than four areas, the background colors start over from the initial color.
  3. Accent: Each row contains a range of colors derived from one accent color, and these colors are used alternately. If required by the control, you can display multiple gray blocks: the different shades of gray will then be displayed alternately, beginning with the initial color.
  4. Dashboard: This layout type uses spacing around the blocks. It is mainly used for applications that display charts in the blocks.

Colors

Cell Colors

Colors can be set for each individual cell. There are 10 pre-defined color sets, each with 4 different shades. To change the background of a particular cell, set the block layout’s background color set (main color) (property: backgroundColorSet) and background color shade (shade) (property: backgroundColorSet) accordingly.

The available colors are shown below.

Available Colors

Color set 1, with shades A to D
Color set 1, with shades A to D
Color set 3, with shades A to D
Color set 3, with shades A to D
Color set 5, with shades A to D
Color set 5, with shades A to D
Color set 7, with shades A to D
Color set 7, with shades A to D
Color set 9, with shades A to D
Color set 9, with shades A to D
Color set 2, with shades A to D
Color set 2, with shades A to D
Color set 4, with shades A to D
Color set 4, with shades A to D
Color set 6, with shades A to D
Color set 6, with shades A to D
Color set 8, with shades A to D
Color set 8, with shades A to D
Color set 10, with shades A to D
Color set 10, with shades A to D

Row Color Sets

For rows in the “Light” and the “Accent” variant of the block layout, you may choose between different row color sets (property:rowColorSet). These sets enable different starting colors for the row coloring, preventing color coalescence in the responsive behavior of the block layout.

Images

Images may be placed as background images within one block. The predefined paddings do not apply to blocks with images; images are displayed in the entire block.
If needed, the title control may be placed above the images.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Wizard Floorplan

The wizard floorplan allows users to complete a long or unfamiliar task by dividing it into sections and guiding the user through it. The wizard consists of the walkthrough screen, where the form sections are revealed in sequence after each one is completed, and the summary page, where the form is displayed in read-only mode for assessment and final submission. You can use the wizard both in full-screen and flexible column layout.

Wizard - Steps
Wizard - Steps

Usage

When to Use the Wizard Floorplan

The wizard aims to help users by dividing large or complex tasks into segments. Use the wizard if the user has to accomplish a long task (such as filling out a long questionnaire) or a task that is unfamiliar to the user. The flow should consist of a minimum of 3 and a maximum of 8 steps.

The wizard can be used for both create and edit scenarios. If your application contains both, consider using the same means for both scenarios – either the wizard, or another create/edit screen (edit flow or object page).

When Not to Use the Wizard Floorplan

If you have a task with only 2 steps or a format that the user is familiar with (for example, it is part of their daily routine), do not use the wizard as it only adds unnecessary clicks to the process. If your process needs more than 8 steps, the wizard will not support those steps as the process is too long and can be confusing for the user. In this case, you should consider restructuring the task.

Consider if the classic edit screens (edit flow or object page) are more suitable for your use case.

Structure

The wizard has two main screens: the walkthrough screen, where users complete a segmented task, and the summary screen, where they can check the data they are about to submit. Wizard content is not restricted to forms; other content such as a value help dialog can also be used.

Walkthrough Screen

The walkthrough screen is the wizard’s main screen. After triggering the wizard, the user is taken to the walkthrough screen, which shows only the first section of the form. Once the user has filled out all the necessary fields, a Step XY button appears, which allows the user to move to the next step. When the user has completed the last section of the wizard, the button label changes to Review and the user is taken to the summary screen.

The wizard footer is used to display the Cancel button, which exits the wizard. If the user has modified any fields, a data loss message also prompts the user. You can also use a Save as Draft function in the footer if the form is long and the user may have to save it before finishing it.

Walkthrough screen in full screen layout
Walkthrough screen in full screen layout

The title in the header toolbar above the wizard remains unchanged during all the wizard steps. Align this title left, and make it clear to users where they are and what they are doing (for example, Create Sales Order or Edit Sales Order 4815162342). Especially in edit scenarios, it is vital to give users a unique identifier for the object they are changing.

Header toolbar with title
Header toolbar with title

The progress bar/anchor navigation below the header highlights the completed steps and the current step. It also allows the user to navigate between steps by clicking on any of the circles.

The progress bar exhibits a grouping behavior if there are multiple steps and the screen width is reduced. This behavior is the same on smartphone, tablet, and desktop screens.

Wizard header and anchor navigation
Wizard header and anchor navigation
Wizard tooltip – Grouped steps
Wizard tooltip – Grouped steps

In certain use cases, the steps in the wizard depend on the choices the user makes along the way. The user’s entries for one step determine the follow-on steps (“branching”). In these cases, a dotted line shows that more steps will follow.

Wizard branching
Wizard branching

Since the wizard is a lightweight way to create or edit objects, applications can use a quick confirmation popup instead of the heavier data loss message, when the user selects Cancel.

If the wizard is used to create an object, the text on the popup should read ‘Discard this ?’ (see image below).If the wizard is used to edit an object, please use the text ‘”Discard changes?” In both cases, the action on the popup should be Discard.

Structure – Quick confirmation
Structure – Quick confirmation

Summary Screen

On the summary screen, users can check all their entries before the object is actually created or changed. The summary screen has no progress bar or anchor navigation, and shows the form sections for all the steps in read-only mode.

To allow the user to go back and edit entries, provide an Edit button either in the footer toolbar or in each form section:

  • If you place the Edit button is placed in the footer toolbar, the user is taken back to the first section of the wizard.
  • If you offer Edit buttons for each section of the form, the user jumps to that particular step.

Alternatively, users can click or tap the Back button to go to the previous step. From there, they can scroll or tap through the sections.

The main action on the summary page should be the final action after completing the wizard, such as Create or Save.

Wizard summary page example
Wizard summary page example

Layout

Thanks to the wizard’s responsive behavior, it can be used both in a full-screen layout as well as in the flexible column layout. Since there are no subsequent pages after the wizard, it will always occupy the rightmost column – there is no navigation from the wizard to a next page. After completion (or cancellation), the user will always come back to the page the wizard was triggered from.

Wizard in full screen layout
Wizard in full screen layout
Wizard in flexible column layout (2/3)
Wizard in flexible column layout (2/3)
Wizard in flexible column layout (1/3)
Wizard in flexible column layout (1/3)

Types

There are two types of wizard – “standard” and “branching” – which differ in terms of the functions they offer.

Use the standard type if:

  • The total number of steps is known in advance.
  • The number of steps does not change during usage.
  • There is linear progression from one step to the next.

Use the branching type if:

  • The total number of steps is not known.
  • The number of steps may change during usage.
  • There is non-linear progression. In other words, the user’s choice during one step determines which step comes next.

Styles

In addition to the functional types, there are also different visual styles.

Numbers and Icons

By default, both versions use a number inside a circle to represent each step. You can also use icons instead of numbers to help users identify the steps. If you plan to use icons, be sure to assign icons to all the steps (not just to some). The icons you choose should be unique and not look too similar. This will ensure that users do not get individual steps confused with one another.

Steps represented by numbers
Steps represented by numbers
Steps represented by icons
Steps represented by icons

Labels

To help users identify the individual steps even more easily, app developers can assign labels. As with icons, labels must be applied to all or none of the steps.

If there is enough horizontal space, all labels are shown.

All labels are visible
All labels are visible

As the width is reduced, the steps outside the currently selected one do not show labels.

Labels - reduced width
Labels - reduced width

Finally, the unselected and outermost steps are stacked on top of each other to further accommodate the reduced space.

Stacked labels
Stacked labels

Users can still easily access steps inside a stack. A single click opens a list of steps inside this stack.

Labels - stacked popover
Labels - stacked popover

Explanatory Texts

Ideally, the headlines and field labels for each step should provide enough information for users to complete their tasks. However, if additional explanations are needed, applications can put a simple text underneath a step’s headline – either via the sap.m.Text or the sap.m.FormattedText control.

Responsiveness

The wizard supports all common screen sizes and is available in cozy and compact modes, as well as high-contrast black (HCB).

Wizard – Size S
Wizard – Size S
Wizard – Size M
Wizard – Size M
Wizard – Size L
Wizard – Size L

Behavior and Interaction

Navigation, Error- and Draft Handling

Navigation

Users can trigger the wizard app from another application, the launchpad, or a notification. The wizard always starts at the initial walkthrough page and ends after the user has clicked the main action (such as Submit) on the summary screen. The Step XY button is only used on the walkthrough page, and its purpose is to load the next section of the form.On the summary page, the user can use either the Edit button in the footer or the “back” arrow to return to the wizard and edit any of the fields.Modifying dependent steps: If there are steps that depend on each other (for example, a selection in step 2 triggers an optional step) and the user modifies the parent step, the dependent step is changed or deleted. This first triggers a warning message (when the input control loses focus) that data will be lost.

Error Handling

Error handling is done via message popovers. When the user clicks the Step XY button, the form sections and fields should be validated. When the user clicks the Submit button on the summary page, the entire form is validated. If there are any errors, the user stays on the walkthrough page, the message popover is displayed, and clicking any of the error items scrolls the page to the relevant field, which is also highlighted in red.

Section validation differs from validation of the entire form. In the first case, correct data entry in the form fields is validated. In the second case, the entire form is checked for backend system errors (such as duplicated data entry).

Draft Handling

If a draft already exists when a user enters the wizard, show a dialog to inform the user. For more information, please visit the draft handling article.

Dynamic Page

Header

Even though the wizard floorplan consumes the dynamic page, the wizard’s header does not allow snapping. Due to the nature of the wizard floorplan, the wizard brings its own step-based header that is already very space-saving.

Footer Toolbar

Contrary to the header, the footer toolbar of the wizard floorplan conforms to the standard layout and uses the sap.m.bar control.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • Wizard (SAPUI5 API reference)
  • Wizard (SAPUI5 samples)
  • Form (SAPUI5 API reference)
  • Form (SAPUI5 samples)

Worklist Floorplan

A worklist displays a collection of items that a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan is on processing the items. This differs from the list report floorplan, which focuses on finding and acting on relevant items from a large dataset.

The worklist floorplan can be implemented in two ways:

  • Using the corresponding SAPUI5 controls in a dynamic page layout. This gives you much greater flexibility, but also costs more development time.
  • Using the SAP Fiori element for the worklist. This generates the floorplan from OData annotations, which brings down development time. However, the SAP Fiori element worklist is restricted to the most common features. Details on the SAP Fiori element for the worklist are included at the end of each section.
Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Users need to work with multiple views of the same content (for example, items that are “Open”, “In Process”, or “Completed”. Users can switch between views using the tab bar.

Do not use the worklist floorplan if:

  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (charts or tables). In this case, use the list report floorplan instead.
  • Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping. Use the list report floorplan instead.

Layout

The worklist floorplan is based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, tab bar information (if the header is collapsed), and a header toolbar with global actions, such as Share.
  • The content area: Use this to display:
    • An icon tab bar in the content area
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table and list. If you use charts, they can be displayed exclusively (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time. To ensure that the application runs on all devices, we recommend using the responsive table.

SAP Fiori Element Worklist

The SAP Fiori element worklist does not support:

Basic structure
Basic structure

Responsiveness and Adaptiveness

In general, the worklist floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

Worklist floorplan - Size S
Worklist floorplan - Size S
Worklist floorplan - Size M
Worklist floorplan - Size M
Worklist floorplan - Size L
Worklist floorplan - Size L

SAP Fiori Element Worklist

The SAP Fiori element worklist automatically replaces grid tables and analytical tables with responsive tables on smartphones.
For tree tables, there is no meaningful fallback solution for smartphones.

Guidelines

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a table.

Simple worklist without tabs
Simple worklist without tabs

Worklist with tabs

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs can also contain tables with different configurations (for example, with different columns or actions).

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red for the Error tab).

Worklist with tab categories
Worklist with tab categories

Worklist with KPI

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI within the KPI container next to the page title as an object status.

Worklist with KPI
Worklist with KPI

Header Title

Variant Management

Variant management is optional. If used, apply it to the whole page. Use the variants to save and restore all settings, including selected tabs, all tables, all charts, and all personalization settings.

If variant management is not needed, just show a title that describes the current view instead.

Header Toolbar (Global Actions)

Use this for non-finalizing global actions such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

In addition, offer any other global, non-finalizing actions that are needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Page Content

Tab Bar

The tab bar is part of the page content container, which means that the tab bar is not “sticky” and will scroll away when the user scrolls down the page.

Use the text-only version of the icon tab bar. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count). Only use icons if you need to display semantic colors on the icon tab bar.

The tab bar works as a filter on the content below.

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. For filter, sort, and group, show a view settings dialog with only the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no items or only unsuitable items are selected. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Table

If there are no items to display, use the “no data text” of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied: No filters set. To start, enter your search and filter settings and run the search.
  • The filter was executed, but no items were found: No items found. Try adjusting your search and filter settings.
  • By opening a related app, the filter criteria were transferred automatically, but no items were found: No items found. Check the search and filter settings.

There are three types of navigation at item level in the worklist floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation. In a grid table, analytical table, or tree table, clicking the navigation indicator triggers the navigation. Another option is to use a link as the identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is used for a different target.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually a list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting. In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object, as well as a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Standard Naming Conventions

For all objects, follow the standard conventions for action buttons, the object name, and the title in the shell bar. For more information see Manage Objects – Components and Launchpad Shell Bar – Page Title and Navigation Menu.

SAP Fiori Element Worklist

The SAP Fiori element worklist supports only simple content and multiple views (manifest.json: quickVariantSelection or quickVariantSelectionX). Multiple content is not supported. If you use tabs with multiple views, the counters for the tabs are turned off by default. Turn them on, unless this causes performance problems (manifest.json: showCounts).

Only smart tables are supported. Since charts cannot be displayed, no view switch is needed.

The table toolbar supports:

  • Table title (annotation: UI.HeaderInfo, property: TypeNamePlural)
  • Item count: Turned on by default
  • Variant management for the table layout: Although the layout variant is turned on by default, it should not be used in most cases. If the layout variant is turned off, the table layouts are stored together with the page variant (manifest.json: smartVariantManagement).
  • Several standard and custom actions (see below)

Actions cannot be grouped using a menu button on the table toolbar.

Within the SAP Fiori element worklist, you can use the responsive table, grid table, analytical table, or tree table within the smart table.

The smart table supports:

  • No selection, single selection, or multiple selection (manifest.json: multiSelect). With multiple selection, the SAP Fiori element worklist triggers the action for all selected items. If an error occurs with one or more of the selected items, it can be handled in the following ways (annotation: OperationGroupingType):
    • Partial processing: A message is displayed for the items with issues. All other items are processed. The message displayed is generic and must be replaced.
    • Roll-back: A messageis displayed. All items are reverted. The message displayed is generic and must be replaced.
  • Text control in line items
  • Rating indicator within line items (annotation: UI.DataPoint)
  • Progress indicator within line items (annotation: UI.DataPoint)
  • Indicator for the editing status within the rows (for example Draft or Locked by [user]). Users can filter the table by editing status in the filter bar.
  • Line item navigation to different targets (maintain detail pages in manifest.json):
    • Navigation to a related object pagewithin the app (default). Apps can override this behavior and define their own navigation target. The target can also depend on specific conditions defined by the app (maintain detail pages in manifest.json).
    • Cross navigation to another SAP Fiori app or to another system
  • Link and smart link to show details in a quick view or to navigate. A quick view can be used as part of the smart link or for displaying contact details. For navigation, the target can be any web page, another app, or a related object page within the same app.
  • Line item actions as text or icon buttons (such as Approve and Reject).
  • Any control that the corresponding table allows by using breakout columns.

At present, the smart table does not support:

  • The object number. This is only available if you use a breakout column. Without a breakout, amounts appear as standard text only.

Only the responsive table supports:

  • A column that displays the object identifier, including the object name and ID (annotations: Common.SemanticKey with Common.Text)
  • Images in line items (annotation: UI.IsImageURL)
  • The object status control in line items: Use of a specific status, such as Out of Stock, in connection with one of the semantic colors and/or a status icon (criticality annotations). The object status provides different categories: success, warning, error, and none. To sort a column by object status, the SAP Fiori element worklist sorts this column by these categories. If more than one value is used in a category, take care that these values are sorted in a meaningful way within the category (for example, alphabetically).
  • A progress indicator in line items (annotation: UI.DataPoint)
  • Smart area micro charts, smart bullet micro charts, and smart radial micro charts in line items (annotation: UI.Chart)

Only the grid table, analytical table, and tree table support:

  • App-specific column widths: While the SAP Fiori element worklist calculates the width of each column automatically, this calculation is not always perfect. Apps can override the calculated width per column.

Changing the alignment of table content is only possible with UI adaptation.

Because the SAP Fiori element worklist does not support editing use cases, the message button is not supported on the footer toolbar.
Actions cannot be grouped using a menu button on the footer toolbar.

Actions

The worklist offers four locations for actions: global actions, table actions, line item actions, and finalizing actions.

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the standard Share action.

The Share button opens an action sheet that contains actions like Save as Tile (if the SAP Fiori Launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space in the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

Global actions
Global actions

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no action is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

Toolbar actions
Toolbar actions

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this option only for specific, frequently-used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Line item actions are not usually disabled. Hide actions which cannot be used at all (for example, because the user has no authorization, or because the line item is in the “wrong” state).

Inline actions
Inline actions

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information on finalizing actions, see the guidelines for the footer toolbar.

Finalizing actions
Finalizing actions

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen. Once the user has completed the task, the app should:

  • Return the user to the worklist
  • Remove the processed item from the list, or move it to a “completed” section
  • Confirm the user’s action with a message toast

Once the user has completed the task, the app should:

  • Return the user to the worklist
  • Remove the processed item from the list, or move it to a “completed” section
  • Confirm the user’s action with a message toast

SAP Fiori Elements

To see which features are available in the SAP Fiori Element Worklist, use the table below.

Feature Status Comment
 Header Title
Title only (no variant management) Supported
Variant management – page variant Supported
Variant management – only for filter settings Supported Not recommended
Filter information Supported
Global actions Not Supported
Generic action: Share Supported
Generic action: Show Filters / Hide Filters (with grid table, analytical table, tree table only) Supported
Content Area
General Layout
Simple content Supported One table only
Mutiple views – single toolbar (segmented buttons / select) Supported
Multiple views – one toolbar each (tabs) Supported
Multiple content Not Supported
Tabs
Item counts on tabs Supported
Table Toolbar
Title Supported
Item count Supported
Sort/filter/group via view settings dialog Not Supported Do not show filter settings on the table toolbar
Sort/filter/group via P13n dialog Supported Do not show filter settings on the table toolbar
View switch Not Supported
Alternative visualization: chart view Not Supported
Alternative visualization: table and chart view Not Supported
Other alternative visualizations Not Supported
Layout variant Supported Not recommended
App-specific actions with partial processing

(In case of errors, display a message for the items with issues. Process all other items.)

 Supported Change the generic message texts
App-specific actions with roll-back

(In case of errors, display a message. All items are reverted.)

 Supported Change the generic message texts
Enable/disable actions, depending on selection Supported
Grouping of actions (menu button) Not Supported
Overflow handling for toolbar Supported
Generic action: Edit Not Supported
Table
Table type: responsive table Supported
Table type: grid table Supported
Table type: analytical table Supported
Table type: tree table Supported
Table type: list Not Supported
Table type: tree Not Supported
Selection: Table items are not selectable Supported
Selection: single selection Supported
Selection: multi-selection Supported
App-specific column widths (grid table, analytical table, tree table only) Not Supported
Content: text Supported
Content: rating indicator Supported
Content: progress indicator Supported
Content: editing status Supported
Content: actions (text or icon buttons) Supported
Content: object identifier (responsive table only) Supported
Content: images (responsive table only) Supported
Content: object status (responsive table only) Supported
Content: smart area/bullet/radial micro chart (responsive table only) Supported
Any other content the underlying table allows Supported Via break-out only
Aligning content within columns Not Supported
Generic “no data” text Supported
Custom “no data” text Not Supported
Navigation: Line item navigation via navigation indicator (within app, cross-app, any target) Supported
Navigation: Line item navigation via link with/without quick view (within app, cross-app, any target) Supported
Footer Toolbar
Messaging button and message popover Not Supported
Finalizing actions Supported
Grouping of actions (menu button) Not Supported
 Actions
Global Actions
Generic action: Show Filters / Hide Filters Supported
Generic action: Share (icon button) Supported
App-specific actions Not Supported
Grouping of actions (menu button) Not Supported
Table / Chart Actions
Enabling / disabling actions, depending on the current selection Supported
Grouping of actions (menu button) Not Supported
Generic action: Add (via object page) Supported Draft handling is supported
Generic action: Add (via dialog) Supported Via break-out only
Generic action: Add (via new row) Not Supported
Generic action: Delete Supported
Generic action: Sort (via view settings dialog) Not Supported
Generic action: Sort (via P13n dialog) Not Supported
Generic action: Filter (via view settings dialog) Not Supported Do not use filter settings on the table
Generic action: Filter (via P13n dialog) Not Supported Do not use filter settings on the table
Generic action: Group (via view settings dialog) Not Supported
Generic action: Group (via P13n dialog) Not Supported
Generic action: Column Settings (via table personalization dialog) Not Supported
Generic action: Column Settings (via P13n dialog) Not Supported
Generic action: view settings, combining sort, filter, group, and column settings (via P13n dialog) Supported Not recommended. If used, turn-off filter settings.
Generic action: Export to Spreadsheet Supported
Generic action: Maximize Supported
App-specific actions as text button Supported
App-specific actions as icon-only button Not Supported
App-specific actions with partial processing Supported
App-specific actions with roll-back Supported
App-specific action in emphasized style Supported Use this only for one single action
App-specific action in positive/negative style Supported
App-specific action: trigger immediately Supported
App-specific action: needs user confirmation Supported
App-specific action: needs additional user input Supported
App-specific action: triggers navigation (within app, cross-app) Supported
App-specific action: triggers any other behavior Supported Via break-out only
Line Item Actions
App-specific actions as text button Supported
App-specific actions as icon-only button Supported
Generic action: Delete (icon-only button) Not Supported
Finalizing Actions
App-specific actions Supported
Grouping of actions (menu button) Not Supported

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Worklist Floorplan

A worklist displays a collection of items that a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan is on processing the items. This differs from the list report floorplan, which focuses on filtering content to create a list.

Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Your app uses the full screen layout. The full screen worklist is preferable if the work items are complex objects. For simple scenarios, use the split-screen layout instead.

Do not use the worklist floorplan if:

  • You want to create only a lightweight worklist. Instead, use the split-screen layout for simple scenarios.
  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (charts or tables). In this case, use the list report floorplan instead.

Layout

The launchpad shell bar is always available at the top of SAP Fiori apps. The app title (app header) matches the title of the tile on the SAP Fiori launchpad (for example, Approve Purchase Orders).

The worklist contains a list of work items. You can also use the icon tab bar to split the list into different categories. In addition, the worklist can use filters and variants, as described for the list report floorplan. Bear in mind, however, that if users can filter the list, they may also overlook important work items.

To ensure that the application runs on all devices, we recommend using the responsive table. The responsive table also offers a wide range of options for optimizing the layout, scalability, and how the user takes action.

Basic structure
Basic structure

Responsiveness and Adaptiveness

Worklist floorplan - Size S
Worklist floorplan - Size S
Worklist floorplan - Size M
Worklist floorplan - Size M
Worklist floorplan - Size L
Worklist floorplan - Size L

Worklist Floorplan with the Dynamic Page Layout

Variant Management and Global Actions

The header title of the dynamic page provides a variant management option and a toolbar for global actions. If the content is collapsed, the header title displays the selected tab.

Dynamic Page Header

The dynamic page supports snapping behavior for the header content, including the tab bar:

  • If the header is used with a responsive table (sap.m.table), the header content collapses automatically when the user scrolls down the page.
  • If the header is used with a grid table, analytical table, or tree table (sap.ui tables), users can collapse the header manually.

Footer Toolbar

In edit mode or for finalizing actions there is a footer toolbar. This element appears on the bottom of the page content and contains finalizing actions.

Types

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a list.

Simple worklist without tabs
Simple worklist without tabs

Category Worklist

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs can also contain tables with different configurations (for example, with different columns or actions).

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red on the Error tab).

Worklist with tab categories
Worklist with tab categories

KPI Worklist

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI in the subheader.

Worklist with KPI
Worklist with KPI

Actions

Worklist with table toolbar for actions
Worklist with table toolbar for actions

The header title contains the global actions. These actions can apply to individual or multiple items selected by the user. Placing actions in the toolbar allows users to process several items at a time. However, more clicks are required to process single work items.

Worklist with actions at line item level
Worklist with actions at line item level

You can also offer actions at line item level. This reduces the interaction required to a single click per item. Consider offering actions at line item level for the most frequently used actions, and if the list provides enough information to make the a decision.

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen.

Worklist with navigation to item details
Worklist with navigation to item details
Work item details
Work item details

Once the user has completed the task, the app should:

  • Return the user to the worklist
  • Remove the processed item from the list, or move it to a “completed” section
  • Confirm the user’s action with a message toast

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object Page (Floorplan + SAP Fiori Element)

The object page floorplan allows the user to display, create, or edit an object. This is now the recommended floorplan for representing both simple and complex objects in SAP Fiori. It has replaced the flat object view floorplan and is set to replace the object view floorplan. The object page floorplan comes with a flexible header, a choice of anchor or tab navigation, and a flexible, responsive layout. These features make it adaptable for a wide range of use cases.

You can implement the object page floorplan in two ways:

  • Use the pre-built SAP Fiori element (formerly known as a smart template). This implementation uses OData annotations, and allows you to speed up development if the supported feature set matches your requirements. For an overview of the supported features, see the SAP Fiori Element section.
  • Implement the floorplan yourself using the respective SAPUI5 controls.
Object page floorplan
Object page floorplan

Usage

Use the object page floorplan if:

  • Users need to see, edit, or create an item with all its details.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

  • Users want to edit several items at the same time. Use the list report floorplan instead.
  • Users need to find relevant items without knowing the exact item details. Use the list report floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner). Use the initial page floorplan instead.
  • Users need to be guided through a series of steps when a new object is created. Use the wizard floorplan instead.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected. Use the wizard floorplan instead.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL).

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The layout for size XL (large display) contains four columns.

The default layout for size L (desktop) contains three columns. You can also use an optional two-column layout.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Structure

The object page is a full screen floorplan with a display mode, a create mode, and an edit mode.

In all modes, the object page contains:

  • A snapping header
  • A navigation bar
  • A content area

The following sections explain these components in more detail.

Schematic visualization of object page
Schematic visualization of object page

Snapping Header

The snapping header is the uppermost element of the object page floorplan. It contains key information about the business object and provides the user with the necessary context. The header also contains global actions for the object.

Toolbars

The object page supports two toolbars:

  • Header toolbar: Use this toolbar for global actions such as Edit, Delete, Copy and Share.
  • Floating toolbar: Use this toolbar for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

This applies to all object page modes (display, edit, and create).

Responsive overflow toolbar
Responsive overflow toolbar

Navigation

There are three ways to navigate within the object page:

  • Anchor bar (by default)
  • No navigation (flat scrollable page)
  • Tabs

Usage

  • To offer a flat page for a simple object, remove the navigation.
  • For more complex objects, use the anchor or tab navigation.
Object page – Anchor navigation
Object page – Anchor navigation

Anchor Bar and Overflow

The anchor bar is the default navigation control for the object page. It consist of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint

Anchor Bar and Overflow

Use title case for the anchor bar texts. To do this, you need to change the default capitalization (block caps) by changing the the property upperCaseAnchorBar to “false”.

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow overview button on the right of the navigation bar ( ) opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow overview button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the document.

Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow overview button
  8. Overflow overview dropdown
  9. Section (hover) in overflow overview
  10. Section in overflow overview
  11. Subsection in overflow overview

Behavior and Interaction

  • Clicking an anchor link scrolls the page to the selected section.
  • Clicking a section anchor that contains more than one subsection opens a subsection menu.
  • Clicking a subsection scrolls the page to the selected subsection. The keyboard left and right arrows allow the user to move between the anchor links.
  • Hovering over the fade area to the left or right of the anchor bar causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
  • Clicking the overflow scroll button (right arrow) scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
  • Clicking the overflow overview button ( ) displays a hierarchical dropdown list with all the sections and subsections of the document. Clicking an item in the overflow list scrolls to the respective section or subsection.
Object page – Anchor behavior and interaction
Object page – Anchor behavior and interaction

Hiding the Navigation

An object page can be used in a similar way to a flat object view. This is achieved by hiding the navigation bar from the object page, leaving a flat scrollable object. We recommend using this flat view for simple content that doesn’t require anchor navigation.

Tab Navigation

As an alternative to anchor navigation, you can also opt for tab navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. Tab navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional and the default state is “false”. If the state is set to “true”, a dropdown arrow is shown next to the tab. Clicking on the tab displays a dropdown menu with the subsection anchors for that tab.

Object page – Tab navigation
Object page – Tab navigation

Breadcrumbs

If the object page uses a hierarchical parent-child drilldown, you can offer a breadcrumb for navigation. The breadcrumb is part of the snapping header.

Content Area

The object page content consists of sections and subsections arranged in a column layout. For large documents, you can enable a lazy loading mechanism (property: enableLazyLoading) to mitigate the loading time.

Sections

Sections are containers for subsections. They provide the basic structure for navigation, and are directly reflected in the navigation bar. Sections can have a title, subsections, and actions. However, they cannot contain controls.

Use title case for the section title (property titleUppercase = “false”). The title can have an item counter, which is displayed in parentheses. If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Global actions are always placed at subsection level. Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for global actions at the subsection level.

Subsections

Subsections are the containers for actual content. Always place individual controls inside the subsections. Subsection content is arranged according to the column layout approach for the respective screen size. A subsection can include containers for different controls (mixed content).

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can also display everything by selecting the Show All button at the bottom right of the subsection.

Each subsection can have a toolbar, which is placed at subsection header level on the right. The toolbar contains actions that affect the content of the subsection.

Subsections within the same section are separated by a gray horizontal line. Subsections can have an item counter, which is displayed in parentheses next to the subsection header.

You can include various types of related content in one subsection. The layout blocks for the object page give you the flexibility to combine different content types.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times, and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.
Object page – Blocks
Object page – Blocks

Contacts

The contacts on the object page are technically a list, but they can be represented visually as a card.

The cards can contain:

  • An image (optional)
  • A title (mandatory)
  • A subtitle (optional)
  • A text snippet consisting of two lines maximum (optional)

A single card covers the column’s entire horizontal space. To avoid alignment problems, all cards are the same height. The card with the most content defines the overall height for all cards. The image can be rectangular or round. It shows in the top left corner of the card. The content of the card never truncates. If there is not enough space to display the information, it wraps onto the next line.

Content type – Contacts
Content type – Contacts

Tables

In an object page, tables with up to 20 expected items can be displayed right away without lazy loading.

If a table is expected to have more than 20 items, use one of the following 3 options for long tables:

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial amount of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, this option should be used only for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. Here it is important to place the table within a tab as the only or at least the last element and to enable the scroll to load behavior.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, the table itself should be restricted to a reasonable amount of items. We recommend only showing a preview of the data in the table, which should not contain more than 20 items. Ideally, you should have about 10 items. This can be either be achieved by prefiltering and/or by sorting the table, and if necessary, by restricting it to a fixed amount of items (such as top 10). To provide the user with a way to work with the entire table, a navigation to a separate list report containing the full table must be offered.  This navigation should be located below the table in the form of a right-aligned link labelled Show All (x), with x representing the total amount of items in the table.

In the object page, we recommend that you do not use the analytical, grid and tree tables. Instead, use a responsive table and offer navigation to a list report with the table types mentioned above.

For all of the three options mentioned above, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Grouping should be avoided.

Table with navigation to a separate list report
Table with navigation to a separate list report

Child Page Representation

In object pages with drilldown navigation, child pages are represented in three ways:

  • Visual representation in the header: A narrow blue band is displayed in the left margin of the snapping header.
  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Item navigation arrows: Up and down arrows in the application toolbar allow the user to navigate between subitems without going back to the original list.

Behavior and Interaction

Edit

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create). In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area for edit mode to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see manage objects – create, edit, delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

Object page – Global edit with header container and independent header facets
Object page – Global edit with header container and independent header facets

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit on a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Object page – Partial edit with dialog
Object page – Partial edit with dialog

Create and Edit Subobjects

The following options are available for creating or editing subobjects:

  • Navigation to a subobject page
  • Inline create or inline edit in a table
  • Dialog containing the fields of the object

If the subobject has less than 8 fields, use a dialog or the inline create/edit option (no separate page for the subobject). Exceptions can apply if additional content for the subobject is available but not part of the edit process, or if other apps need to offer deep links to the subobject page.

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:
•Who made the changes
•When the last changes were made

The popover closes when the user clicks or taps the Close icon or anywhere outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, use the placeholder text “New ” (for example, “New Purchase Order”). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Guidelines

Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing a clear context.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.
Do
Object page floorplan – Good example of how to arrange actions
Object page floorplan – Good example of how to arrange actions
Don't
Object page floorplan – Bad example of how to arrange actions
Object page floorplan – Bad example of how to arrange actions

Tab Navigation

Use tab navigation if you need a facet approach to your content. This could be due to performance issues in a flat view, or in response to a specific user preference. If you need to use icons, tabs as process steps, or tabs as filters, use the object view floorplan.

Not a Content Dump

Avoid using the object page as a universal container for masses of information. You should use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.

Simplify Content for Your Users

Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request. Furthermore, only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

SAP Fiori Element

Use the table below to see which features are available for the “object page” SAP Fiori element.

Feature Status Comments
Snapping Header
General
Fiori 2.0 merged header Supported
Header always expanded Supported
Header container on/off Supported
Header container on/off in different modes Supported
Header container expand on click Supported
Child page navigation Supported
Subtitle optional Supported
Arrow icon showTitleSelector Not Supported
Breadcrumbs Supported
Favorite behavior Not Supported With indicator next to the title.
Flag behavior Not Supported With indicator next to the title.
Unsaved changes behavior Supported With indicator next to the title.
Lock behavior Supported With indicator next to the title.
Header Facets
Different header facets in different modes Supported
Wrapping behavior for header facets Supported
Image facet square Supported
Image facet round Supported
Image header facet with placeholder Supported
Image header facet in different sizes Supported
Key value facet with unit Supported
Key value header facet with trend Not Supported
Key value facet with same text/numeric size Supported
Microchart header facet Partially supported Currently available for bullet and area charts.
Microchart header facet subtile optional Supported
Microchart header facet footer optional Supported
Microchart header facet with rating indicator Supported
Microchart header facet with progress bar Supported
Form header facet with optional labels Supported
Form header facet with icons as labels Not Supported
Form header facet with links as values Supported
Form header facet value with semantic color Supported
Key value header facet with link as value Supported
Key value header facet with semantic color on value Supported
Plain text header facet Supported
Breakout header facet Not Supported This also includes adding controls to existing header facets.
Toolbar
Header toolbar select, combo box, multi-combo box Not Supported
Header toolbar semantic buttons Supported
Header toolbar highlight buttons Supported
Header toolbar segmented buttons Not Supported
Toolbar overflow Supported
Toolbar overflow prioritization Supported
Icons as buttons Supported
Action sheet in buttons Supported
Prioritization of custom actions in toolbar Supported
Show Edit Header button (partial edit) Not Supported
Navigation
Navigation hidden if object has only one subsection Supported
Counts in anchors and section/subsection headers Not Supported
Carousel overflow for horizontal navigation Supported
Mobile navigation behavior (dropdown) Supported
Navigation overflow overview button Supported
Tab navigation Supported
Tab with anchor subnavigation Not Supported
Anchor behavior Supported
Content
General
Partial edit Not Supported
Forms in content Supported For more on the form features, see the forms article.
Actions in forms Partially Supported Currently only via breakout. Actions go into the subsection toolbar.
Timeline in content Not Supported
Carousel in content Not Supported
Contact cards in content Partially Supported
Mixed content Supported
Block controls Not Supported
Lazy loading Work in Progress
Side panel Not Supported
Scroll to specific section on loading Not Supported
Layout
Content layout in size S (1 column) Supported
Content layout in size M (2 columns) Supported
Content layout in size L (3 columns) Supported
Content layout in size L (2 columns) – optional layout Not Supported
Content layout in size XL (4 columns) Supported
Sections and Subsections
Toolbar in subsections Not Supported
Toolbar in sections Not Supported
Toolbar in sections containing only one subsection Not Supported
Subsection toolbar with custom actions Not Supported
Subsection toolbar with buttons Not Supported
Subsection toolbar with highlighted buttons Not Supported
Subsection toolbar with semantic buttons Not Supported
Subsection toolbar with segmented buttons Not Supported
Subsection toolbar with select combo box or multi-combo box Not Supported
Subsection toolbar with buttons with actions sheets Not Supported
Use of priorities in sections/subsections Not Supported
Tables
Responsive list in content Not Supported
Responsive table in content Supported For specific table features, see the guidelines for tables.
Grid table in content Supported For specific table features, see the guidelines for tables.
Display responsive table instead of grid table on mobile devices Supported For specific table features, see the guidelines for tables.
Analytical table in content Supported For specific table features, see the guidelines for tables.
Display responsive table instead of analytical table on mobile devices  Supported For specific table features, see the guidelines for tables.
Tree table in content Not Supported

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


Block Layout

Information

This layout has been designed specifically for the tool landscape for SAP HANA Cloud Platform. It is not intended for use in regular SAP Fiori applications. 

Intro

The block layout is used to display content in a section-based manner. It features horizontal and vertical subdivisions and full-width banners seen frequently in contemporary Web design. Background colors are attached directly to these areas within the layout. As well, special full-width sections of the block layout enable horizontal scrolling through a set of areas.

General page structure of a tool using the block layout
General page structure of a tool using the block layout
Block layout standalone
Block layout standalone

Usage

Example use cases include landing pages and catalog-like pages. In landing pages, the block layout may serve as a banner-like presentation of illustrative icons with associated text. By placing pictorial and textual elements side by side in different areas, a content relationship is established. In catalog-like layouts, the block layout serves as a flexible container for diverging content, such as headings, explanatory texts, code snippets, remarks, and examples.

It is also possible to have clickable blocks with their own hover and pressed states.

There are four types of block layout: layout only (default), light, and accent background colors, as well as a variant for dashboard pages.

Schematic block layout
Schematic block layout
Schematic block layout with a section scrolling horizontally
Schematic block layout with a section scrolling horizontally

Use the block layout if:

  • You want to display section-based content. Place elements next to each other to indicate a content relationship.
  • You want to display KPIs in the dashboard-variant. Do not use other variants for KPIs.

Do not use the block layout if:

  • You want to display properties or features of one content item. Use the object page floorplan instead. Links within a block must lead to areas outside of the block. As well, enable controls to update only their own containers and not other containers.

Layout

The block layout is divided into horizontal sections, which take on the full width of the available screen real estate. Their screen height is determined by their inner content, which prevents vertical scrolling. If needed, the width of sections can also be set to the following predefined ratios (for the sizes XL, L and M):

  • 1 block: 100%
  • 2 blocks: 75% and 25% / 25% and 75%
  • 2 blocks: 50% and 50%
  • 3 blocks: 2 × 25% and 50% / 50% and 2 × 25% / 25% and 50% and 25%
  • 3 blocks: 3 × 33%
  • 4 blocks: 4 × 25%

Horizontal scrolling sections always have a width of 100%.

Responsiveness

The block layout offers responsive behavior. There are three breakpoints, which results in four supported sizes: XL, L, M, and S. As with the responsive grid (another generic layout control), these breakpoints apply both to the page and block layout. However, the page layout’s breakpoints react to screen width, whereas the breakpoints of the block layout react to the width of the control itself.

Ratios of areas in different contexts

Blocks per section XL, L M S
1 100%  100% 100%
2 75% and 25%
25% and 75%		 75% and 25%
or
25% and 75%		 100% each*
100% each*
2 50% and 50%  50% and 50% 100% each*
3 2 × 25% and 50%
50% and 2 × 25%
25% and 50% and 25%		 2 x 50% and 100% over two rows
or
100% and 2 x 50% over two rows		 100% each*
100% each*
100% each*
3 3 × 33%  3 x 33% 100% each*
4 4 × 25%  2 x 50% over two rows 100% each*

*Blocks wrap and are displayed underneath each other

Responsive behavior of sections and areas
Responsive behavior of sections and areas
Responsive behavior of sections and areas
Responsive behavior of sections and areas
Responsive behavior of a section with horizontal scrolling
Responsive behavior of a section with horizontal scrolling

The width of the horizontal scrolling area in different device contexts

XL, L M S
22.5% or 40% depending on the number of areas
3 to 5 areas: 40%
6 to 10 areas: 22.5%		 40% 90%

Types

There are four types of block layouts:

  1. Default: This layout does not use any background colors.
  2. Light: Areas use predefined colors found in the SAP Fiori 2.0 visual design language. These colors follow a specific order specified in the control. If there are more than four areas, the background colors start over from the initial color.
  3. Accent: Each row contains a range of colors derived from one accent color, and these colors are used alternately. If required by the control, you can display multiple gray blocks: the different shades of gray will then be displayed alternately, beginning with the initial color.
  4. Dashboard: This layout type uses spacing around the blocks. It is mainly used for applications that display charts in the blocks.

Colors

Cell Colors

Colors can be set for each individual cell. There are 10 pre-defined color sets, each with 4 different shades. To change the background of a particular cell, set the block layout’s background color set (main color) (property: backgroundColorSet) and background color shade (shade) (property: backgroundColorSet) accordingly.

The available colors are shown below.

Available Colors

Color set 1, with shades A to D
Color set 1, with shades A to D
Color set 3, with shades A to D
Color set 3, with shades A to D
Color set 5, with shades A to D
Color set 5, with shades A to D
Color set 7, with shades A to D
Color set 7, with shades A to D
Color set 9, with shades A to D
Color set 9, with shades A to D
Color set 2, with shades A to D
Color set 2, with shades A to D
Color set 4, with shades A to D
Color set 4, with shades A to D
Color set 6, with shades A to D
Color set 6, with shades A to D
Color set 8, with shades A to D
Color set 8, with shades A to D
Color set 10, with shades A to D
Color set 10, with shades A to D

Row Color Sets

For rows in the “Light” and the “Accent” variant of the block layout, you may choose between different row color sets (property:rowColorSet). These sets enable different starting colors for the row coloring, preventing color coalescence in the responsive behavior of the block layout.

Images

Images may be placed as background images within one block. The predefined paddings do not apply to blocks with images; images are displayed in the entire block.
If needed, the title control may be placed above the images.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Overview – Layouts, Floorplans, and Frameworks

SAP Fiori has a simple user interface hierarchy, designed to make the user interaction easy and intuitive. In general, the SAP Fiori launchpad is the main entry point. All the apps available to a user are presented as tiles in the app finder, while the home page shows a personalized view of tiles the user has selected. The shell bar offers an enterprise search and other services, which are available across all apps.

Most app designs are based on one of two basic page layouts:

The layout for a full screen page contains only one floorplan. The flexible column layout can also show two or even three floorplans next to each other. The term “floorplan” represents different layout types for whole pages. The floorplan defines the structure of the controls used, and how to handle different use cases.

Layouts and floorplans can be built with SAP Fiori elements, or built from scratch (freestyle apps).

Overview of layouts and floorplans
Overview of layouts and floorplans

Overview of Layouts

Layout Use Case SAP Fiori Elements
Dynamic Page Layout The dynamic page is a layout control designed to support various floorplans and use cases. The design of the dynamic page header helps users to focus on the actual page content, but still ensures that important header information and actions are readily available.  Available
Flexible Column Layout The flexible column layout is a layout control that displays multiple floorplans on a single page. This allows faster and more fluid navigation between multiple floorplans than the usual page-by-page navigation. The flexible column layout offers different layouts with up to three columns. Users can expand the column they want to focus on, switch between different layouts, and view the right-hand column in full screen mode.  Available

Note: The full screen layout and split screen layout were deprecated with version 1.48.

Overview of Floorplans

Floorplan Use Case SAP Fiori Elements
Analytical List Page The analytical list page offers dynamic data visualization and business intelligence capabilities that enable users to analyze data step by step from different perspectives. Users can drill down to investigate a root cause, and act on transactional content.  Available
List Report The list report floorplan enables users to view and work with a large set of items. It offers powerful features for finding and acting on relevant items.  Available
Worklist A worklist displays a collection of items that a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it.
Overview Page The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.  Available
Object Page The object page floorplan allows the user to display, create, or edit an object. This is now the recommended floorplan for representing both simple and complex objects in SAP Fiori. The object page offers also a snapping header feature, but the underlying technology differs from the dynamic page.  Available
Initial Page The initial page floorplan allows the user to navigate to a single object to view or edit it. The interaction point on the screen is a single input field that relies on assisted input to direct the user to the object in as few steps as possible (using features such as value help and live search).
Object View The object view is a floorplan for displaying objects in SAP Fiori. From guideline version 1.42, the object view floorplan is only allowed in combination with the icon tab bar. As soon as the icon tab bar is available for the object page, this floorplan will be deprecated.
Wizard The wizard floorplan allows users to complete a long or unfamiliar task by dividing it into sections and guiding the user through it.

Additional Layout Options

Layout Use Case
Multi Instance The multi-instance layout allows users to open multiple documents in a tabular view. After selecting items from a list, the user opens them in a tab container.
Dynamic Side Content Dynamic side content is a layout control that displays additional content to help the user better understand the data being displayed on the screen. The display of the side content adapts flexibly to different screen sizes.
Additional layout options
Additional layout options

Overview of Frameworks

Framework Use Case
Analysis Path  Analysis Path Framework (APF) is a framework for creating interactive, chart-oriented analytical drilldown apps by configuration.
SAP Smart Business SAP Smart Business drilldown is an analytical app. It enables the user to view and analyze the data for one key performance indicator (KPI).

Overview Page (SAP Fiori Element)

Overview page
Overview page

View, filter, and take immediate action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page. The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Easy filtering

  • Micro actions let users react on the spot

Usage

Use the overview page if:

  • You want to provide an entry-level view of content related to a specific domain or role.
  • Users needs to filter and react to information from at least two different applications to complete their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page.
  • You plan to have at least three cards. These cards should not all be of the same type.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page.
  • You only want to show information about one object. In this case, use the object page.
  • You only want to show information from one application, or have less than three cards. In this case, use the object page.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

Different entry points in SAP Fiori
Different entry points in SAP Fiori

As you can see in the picture above, the overall content scope (shown in gray) becomes more focused with each interaction step. The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

Only provide an overview app for a role if it makes sense to do so. An overview page brings together information from different sources that support a specific task focus or information need. If a role or user has several such main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, and allow him or her to manage the performance reviews of the team. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that he or she is responsible for in the role of quality manager.

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps.

The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window. In the screen flow, always position the overview app between the SAP Fiori launchpad home page and the SAP Fiori app. Never start overview apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Responsiveness

The overview page floorplan is fully responsive. The card layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes.

Overview page – Size L/XL
Overview page – Size L/XL
Overview page – Size M
Overview page – Size M
Overview page – Size S
Overview page – Size S

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards. The card layout determines the size and position of the cards.

Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

Dynamic Page in the Overview Page

The overview page can consume four different versions of the dynamic page layout. All the variants have two things in common:

  • The floating footer toolbar is not included.
  • There are no global actions in the header title.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar. In addition, the variant management control lets users share user-defined variants (Save Variant feature).

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards
Floating footer toolbar – – – –

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. The initial default uses the snapped mode, because content is already available on the cards, and users can start right away. When the user scrolls or clicks, the header content expands as defined.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Snapped mode for size XL/L/M
Dynamic page variant 1 – Snapped mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Snapped mode for size S
Dynamic page variant 1 – Snapped mode for size S

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text, which serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/snapped mode for size XL/L/M
Dynamic page variant 2 – Expanded/snapped mode for size XL/L/M
Dynamic page variant 2 – Expanded/snapped mode for size S
Dynamic page variant 2 – Expanded/snapped mode for size S

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size S
Dynamic page variant 3 – Size S

Variant 4 – Text in the Header Title and Smart Filter Bar 

In this variant, the header title contains a text, and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Snapped mode for size XL/L/M
Dynamic page variant 4 – Snapped mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Snapped mode for size S
Dynamic page variant 4 – Snapped mode for size S

Overview Page Layout

The overview page layout describes the position and size of cards in the content area below the dynamic page header (header title and header content).

Only place cards on the overview page. Never add tiles.

Card Layout

The card layout contains responsive (collapsible) columns of cards. The card width is fixed, and the height is determined by the card type and the embedded control.

There is no limit on the number of cards included. To view all the cards, the user just scrolls down.

Fixed card layout
Fixed card layout

The card layout uses padding on both sides. The cards are displayed inside collapsible columns, making the page fully responsive. When the user resizes the browser or uses a smaller screen, the columns containing the cards collapse. In this way, the layout can accommodate typical laptop screens, larger desktop monitors, and mobile devices:

  • Phone: 1 column
  • Tablet (portrait): 2 columns
  • Laptop / tablet (landscape): 3 columns
  • Large desktop: 4 columns
  • Extended monitor: 5 columns (maximum)

The width of the cards is tied to the column width. Breakpoints for the different screen resolutions determine whether the column width is 20 or 25 rem. The cards inside the columns adapt their width automatically. By contrast, the height of the cards is flexible, and depends on the content and type of card.

Rearranging Cards

Users can reposition cards on the overview page by dragging them to a different location. As the user drags a card, it swaps place with any cards in its path. Releasing the mouse or lifting the finger from the touch surface completes the move. To avoid gaps, cards always snap to the next free space in the row, or to the start of the next row.

The cards are arranged as a “Z” flow: cards are ordered from left to right, starting with the first card on the top left of the page. For example, if a 5-column layout is reduced to 4-column layout, the fifth card drops to the next row, assuming the leftmost position underneath the first card.

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the Me Area under Manage Cards. A popover appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Overview page – Manage cards
Overview page – Manage cards
Overview page – Manage cards dialog
Overview page – Manage cards dialog

Cards

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. Technically, a card is a smart component that uses UI annotations to render its content. Cards differ in the content they display: They can show a chart, a list, a table, informative text, or a combination of two elements. However, cards never have editable fields.

Cards can focus on a single object or topic, or on a group of objects.

You can set a specific refresh interval for the card content. All cards are refreshed at once, so the shorter the refresh interval, the more disruptive it is for users.

Card Components

Every card comprises three components: a header area, a content area, and a footer area. The header and content areas are mandatory. The footer area is only used for actions in the quick view card.

Make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

Overview page – card components
Overview page – card components

Card Header

The card header area is mandatory, and serves three purposes:

  • It indicates what the card is about.
  • It functions as a navigation area for opening the parent app, whereby the whole header area is clickable. We recommend offering this navigation on all cards (exception: link list card). 
  • A counter shows how many items are on the card in relation to the total number of relevant items.

The height of the header area is variable; it expands vertically to accommodate the text. The header area can contain two text fields: a mandatory title, and an optional subtitle. The primary purpose of the header area is to identify the content source, summarize the focus of the card (title), show any relevant parameters (subtitle), and offer navigation to the content source (parent app).

Title

The title is mandatory and represents the card’s “point of view”. In one or two words, it explains why this card exists and why a user might want to use it. It is a natural language reflection of the annotated view. Titles that exceed three lines are truncated with the ellipsis (…).

Subtitle

The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The use of the subtitle can differ, depending on the card type. Subtitles that exceed one line are truncated with the ellipsis (…).

Card header with counter
Card header with counter

Counter 
The counter in the header area indicates how many items are showing on the card in relation to the total number of relevant items:

Format: [Items on Card] of [Total Items]
Example: 5 of 40 

The counter is right-aligned and is never truncated (the title wraps instead). The width of the counter is flexible, depending on the amount of data. [Items on Card] can show a maximum three digits, and [Total Items] a maximum of four digits. For larger numbers, a scaling factor is shown. If there is an issue loading a card, or no items are found for the filter criteria, no counter is shown.

Card header with all counted items
Card header with all counted items
Card header with scaled counter
Card header with scaled counter
Card header without the counter
Card header without the counter

Card Content

The content area is mandatory and is reserved for application content. Content is currently displayed on cards by embedding SAPUI5 controls that specify the properties and data format. For example, an embedded standard list control provides formatting, such as row height, font sizes, and the number of text blocks.

Card Footer

On quick view cards that display information on a single object or data point, you can use the footer area to offer related actions. In this case, the overflow toolbar control is used. The height of the footer bar is fixed.

Card footer area with actions
Card footer area with actions

Formatting Dates, Times, Amounts, and Currencies

Apply the following formats:

  • Dates: The default is the relative date format (for example, Today). However, you can also use the medium date format (such as Aug 7, 2015).
  • Times: Times are not visible per default, but if you need to show a time, use the short format (for example, 11:28 AM).
  • Integers/Float/Currencies: Use the short format (for example, 1K for 1000).

Navigation and Interaction

The navigation and interaction depends on the technical card type:

This section looks at the different technical card types, how card views can be combined, and how to incorporate actions.

Single-Object Cards

Cards that feature content with a single focal point, detail, or entity are called single-object cards. An example is a quick view card with information about a particular product. Analytical cards are also single-object cards. The header area of this card type always navigates to this specific focal point, detail, or entity. The content area can also have interaction areas (for example, a section in a chart, or a telephone number for a contact). However, only quick view cards can have actions in the footer area.

Interaction for a single-object card
Interaction for a single-object card

Object Group Cards

Cards that feature a subset of items grouped by a common criterion are called object group cards. A typical example would be a list of purchase orders grouped by delivery date, amount, or supplier. The cards do not have actions, but each row or list item is selectable, thus providing direct navigation to the object details within the parent application. The header area of this card type always navigates to all items in the list or table. Object group cards include all types of list cards, bar chart list cards, and table cards.

Interaction for an object group card
Interaction for an object group card

Link List Cards

Link list cards allow you to display a collection of links or images that can reference both internal and external targets.

  • Links can navigate to a target or open a popover with additional information.
  • Clicking an image opens an image carousel.
Interaction for a link list card
Interaction for a link list card

Stack Cards

A stack card is a special card type for showing a collection of single-object cards. Stack cards have 3 components with different navigation areas:

  • The top-level stack card opens the collection and contains two clickable areas: the left area navigates to the parent app, and the right area opens the object stream.
  • The object stream shows individual cards that represent objects from the parent application. The object stream heading links to the parent application, while individual cards can contain links and actions relating to the respective object. A Close button returns the user to the stack card.
  • The last card in the object stream is the placeholder card. The entire card is navigable and leads the user directly to the parent application.
Interaction for a stack card
Interaction for a stack card
Interaction for a placeholder card
Interaction for a placeholder card

View Switch

You can use a view switch to offer several different content areas on one card, which can help to reduce the number of cards on the overview page. The user chooses the view using a select control. You can only combine views that have a common denominator. The options offered by the select control merely offer different perspectives. For example, a card “Purchasing Spend” (title in the header area) could offer two views “By Material Group” and “By Supplier” (options in the select control). The view switch is located between the header and content areas.

You can use the view switch for the following cards:

View switch
View switch

Actions on Cards

Only quick view cards within an object stream can have actions in the footer area. The overflow toolbar manages how the actions are displayed. All actions are right-aligned. Any actions that don’t fit into the available space move into the overflow action sheet, represented by the ellipsis ( ). A maximum of six actions are allowed in the footer area. Only offer actions the user really needs in the specific context.

Footer area with additional actions in the overflow
Footer area with additional actions in the overflow

There are two possible types of action: navigation and function import. Any combination of navigation and function import actions is allowed. Error or confirmation messages are displayed directly on the overview page. Always overwrite the predefined default text for errors in a message box: Formulate your message in plain language (without code), describe the issue precisely, and suggest a constructive solution.

Type: Navigation

Navigation is “intent-based” and takes the user to a different SAP Fiori app that specializes in executing an action. Navigation actions are always multi-click (meaning they can be repeated over and over). The destination screen opens in the same browser window, and any error or task confirmation messages are handled by the supporting application, not the overview page.

Type: Function Import

Function imports are custom OData service operations for actions. These actions are handled by the overview page, rather than by another SAP Fiori app. The interaction depends on whether or not the action requires user input:

  • If the action requires additional user input, the input parameters are handled directly on the overview screen without further navigation. A dialog appears on top of the card, allowing the user to enter data or make a selection. An example of additional input might be the rejection reason for a “Reject” action.
  • If the action has no input parameters, the action request is sent immediately. Once the action has been completed, the card disappears from the object stream.

Action on Phone

If an action on a card requires an input dialog box, use a full screen dialog on smartphones.

Card Types

The overview page supports the following standard card types:

Analytical Card

Analytical cards are used for data visualization. They are single-object cards that consist of two areas: a header area that displays the aggregated value of a key measure (KPI), and a chart area that displays a representation of data in graphical format. Analytical cards do not contain a footer area.

The KPI header is mandatory for analytical cards used on the overview page. The KPI header includes the title (mandatory), the KPI with the respective unit (mandatory), and a subtitle (optional). The subtitle can show the filter criteria used for the chart, and can contain up to two lines of text. The KPI itself uses the semantic colors red (negative), green (positive), or gray (neutral). You can also display a percentage indicator (optional) or triangle indicator showing an upward or downward trend (optional).

For more information, see analytical card.

The following (VizFrame) charts are available:

List Card

List cards are a type of object group card, and display a set of items in a vertical list. List cards use the sap.m.List container in the content area.

 

List Card Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set. The counter indicates how many items are showing on the card in relation to the total number of relevant items: [Items on Card] of [Total Items], as in 5 of 40.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application. Only aggregate list items in exceptional cases.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

List Item Types

Two different list item types are available:

  • The standard list item always shows 3 pieces of information and inherits the properties of the SAPUI5 control sap.m.StandardListItem.
  • The extended list item can show up to 6 pieces of information and inherits the properties of the SAPUI5 control sap.m.ObjectListItem.

You can only use one type of list item on any given card.

 

Size of a List Card

List cards resize according to the content available. The height can vary, depending on the number of text fields. Show no more than five standard list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

In addition, you can display the data on the right-hand side in semantic colors.

List card with standard list item
List card with standard list item
List card with extended list item
List card with extended list item

Bar Chart List Card

Bar chart list cards are a type of object group card, and display a set of items in a vertical list. Unlike list cards, bar chart list cards are embedded in another component: the comparison micro chart. This allows you to display negative values and use semantic colors.

 

Bar Chart List Card Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set. The counter indicates how many items are showing on the card in relation to the total number of relevant items: [Items on Card] of [Total Items], as in 5 of 35.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application. Only aggregate list items in exceptional cases.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

Bar Chart List Item Types

Three different list item types are available:

  • The standard list item always shows 3 pieces of information.
  • The condensed list item can show up to 4 pieces of information.
  • The extended list item can show up to 6 pieces of information.

You can only use one type of list item on any given card.

 

Size of a Bar Chart List Card

Bar chart list cards resize according to the content available. The height can vary, depending on the number of text fields. Show no more than five standard/condensed list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

Bar chart list card with standard list item
Bar chart list card with standard list item
Bar chart list card with condensed list item
Bar chart list card with condensed list item
Bar chart list card with extended list item
Bar chart list card with extended list item

Link List Card

Link list cards allow you to display a collection of links or images that can reference both internal and external targets. Links and images are handled as two separate variants:

 

Variant Type: List

The list variant shows a collection of links that can navigate to a target or open a popover with additional information. You can also show an optional subtitle below the link with a description or additional information. The link text and subtitle are each limited to one line.

You can display an icon or image before each link. For example, you might want to include app icons for set of links to recently-used apps, or images for a list of recent contacts. Use icons and images consistently:

  • If you opt to use icons, show an icon before every link.
  • If you include images, use a placeholder for images that are not available.
Link list card – Variant type
Link list card – Variant type "list"
Link list card – Variant type
Link list card – Variant type "list" with icons
Link list card – Variant type
Link list card – Variant type "list" with images

Variant Type: Image

The image variant uses the sap.m.Carousel control to display one or more images. If the carousel contains only one image, the Previous and Next icons and the paging indicator are not visible. The link and an optional subtitle are displayed above the carousel. The link text and subtitle are each limited to one line.

Link list card – Variant type
Link list card – Variant type "image"

Table Card

Table cards are a type of object group card, and display a set of items in a table format. Table cards use the responsive SAPUI5 control sap.m.Table.

 

Table Card Navigation

Clicking the header area of a table card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set. The counter indicates how many items are showing on the card in relation to the total number of relevant items: [Items on Card] of [Total Items], as in 3 of 10.

Clicking a list item (row) on the card opens the detail view for that specific object in the same parent application.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

Size of a Table Card

Table cards resize according to the content available. The height can vary depending on the number of table cells. Tables are limited to a maximum of 3 columns and 3 rows, with a maximum of 3 lines of text per row. To see the full result set, the user needs to navigate to the parent app. All three columns can show either a data field or a data point. Data points can use semantic colors.

Table card
Table card

Stack Card

A stack card is a special collection of single-object quick view cards, based on a topic or action. Unlike the other card types, the top-level stack cards don’t show any application content. Instead, they act as an entry point to an object stream containing multiple cards.

Stack cards have the following components:

  • The title is the top element and is always required. It is used as the heading for the detail view, and comprises 1-2 lines of text.
  • The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The purpose of the subtitle is explain the content of the stack in one line, so its usage depends on the context.
  • The stack content count indicates the number of cards in the stack (object stream). The object stream can contain up to 20 cards. Below the number of cards in the stack, you see the total number of items returned for the annotated view (for example, “20 of 42”).

Overview Page - Stack Card

The top-level stack card contains two clickable navigation areas:

  • The left area and View All link navigate to the parent application, where the user can see all the objects returned for the annotated view (42 in the example above). The placeholder card and heading inside the object stream have the same navigation target.
  • The right area opens the object stream, which contains a scrollable collection of cards presented in an overlay format. The user can browse individual cards, with the option to view, inspect, or take action.

Quick View Card

Quick view cards are single-object cards. They display the basic details for one object, such as the name, address, and phone numbers for a contact. This card type is only available within the object stream; you can’t place quick view cards on the overview page itself. The quick view card inherits the SAPUI5 element sap.m.QuickView.

The header area contains a static text, such as Purchase Order, and an optional dynamic text, such as 1005-3345. In this way, each card header can show different content. Clicking on the header area of the card opens the detailed view of the object in the corresponding parent app. If the content area of a card cannot display all the information, a scrollbar appears on the right. Only the footer area of the quick view card can currently provide actions.

Quick view card for a contact
Quick view card for a contact
Quick view card for a product
Quick view card for a product
Quick view card for a purchase order
Quick view card for a purchase order

Object Stream

Overview page – Object stream
Overview page – Object stream

Clicking the right-hand area of the stack card opens the object stream. The object stream appears on top of the overview page as a modeless overlay, and serves as a layer for showing quick view cards with actions. The overlay has heading on the top left, and a Close button on the right. The heading is the same as the stack card title, and links to the full result set in the parent application (same target as the left-side navigation on the stack card and the navigation from the placeholder card). Clicking outside the overlay area also closes the object stream.

The object stream can have up to 20 cards, which all get their content from the same parent application. By default, the cards are ordered chronologically, with the most recent items first. However, app developers can define the best object stream sorting option for their own needs and custom content. If the number of cards exceeds the available space in the overlay window, an arrow icon appears on the right for scrolling. Mobile device users can swipe to see more cards. If the object stream is empty, the stack link is not active and the overlay cannot be opened. The stack count number displays 0. If only one item is returned, the object stream contains just a single card.

The header area of the quick view cards in the object stream navigates to the detail view for that specific object in the parent application. The footer area of the quick view cards can also offer actions.

 

Object Stream – Scroll Arrows

Scroll arrows only appear on desktop devices. If all the cards in the object stream fit on the screen, the arrows are not visible. If the number of cards exceeds the available space, an arrow icon appears on the right when the user mouses over the object stream overlay. Mousing over the arrow button area scrolls the cards across the screen from right to left. As soon as the first card on the left moves out of the visible overlay area, a second arrow appears on the left for moving in the other direction. Once the last card is in full view, the arrow on the right disappears.

Object Stream – Placeholder Card

If the number of items returned for the annotated view exceeds the maximum 20 cards allowed in the object stream, a placeholder card is added automatically at the end of the stream (as card 21). The entire placeholder card is navigable, and takes the user to the full result set in the parent application.

The text on the placeholder card is composed as follows:

See all [total] [items] in the“[app name]” app.

Where:

  • The values for [total] and [app name] are supplied by the system.
  • The term for [items] must be rephrased by the app team to reflect the type of item or business object.

Examples:

  • See all 42 items awaiting approval in the “Approve Leave Requests” app.
  • See all 42 purchase orders awaiting approval in the “Approve Purchase Orders” app.
Overview page – Placeholder card
Overview page – Placeholder card

Object Stream – Tablet Version

On tablet devices, the modeless overlay expands horizontally. It also expands vertically to accommodate the card height and allow space for the title and Close button. The user can swipe through cards and perform micro actions. Swiping a card in view moves the entire object stream. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

 

Object Stream – Phone Version

On smartphones, the overview page layout collapses to a single column in both portrait and landscape modes. Tapping on the right-hand navigation area of a stack card opens the object stream on top of the overview page in a new full screen window.

The object stream expands horizontally and vertically to accommodate the card height, and to allow space for the title and Close button. The user can swipe through the cards and perform micro actions. Swiping a card moves the entire object stream. Since the cards are too large to fit on the screen in landscape mode, users can also scroll vertically to see the full card content. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

  • Overview page – Object stream interaction size M (landscape)
  • Overview page – Object stream interaction size M (portrait)
  • Overview page – Object stream interaction size S (lportrait)
  • Overview page – Object stream interaction size S (landscape)

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

Introduction to SAP Fiori Elements

SAP Fiori elements (formerly known as smart templates) provide a framework for the most common application patterns.

The application team selects the relevant floorplan and adds semantic and structural data using metadata annotations. The framework then generates the application screen.

SAP Fiori elements ensure design consistency and compliance with the latest design guidelines, while reducing the amount of frontend code needed to build SAP Fiori apps.

Information
SAP Fiori elements are part of the SAPUI5 delivery.
SAP Fiori elements – The production line for UIs
SAP Fiori elements – The production line for UIs

Supported Floorplans and Layouts

The following floorplans are available as SAP Fiori elements:

The SAP Fiori elements framework supports the dynamic page layout for all available floorplans. In addition, the flexible column layout is supported for all available floorplans except the overview page, which is not allowed within the flexible column layout.

SAP Fiori elements use the global edit flow, which includes draft handling, or the local edit flow without draft handling. SAP Fiori elements also offer message handling.

Overview page
Overview page
List report
List report
Worklist
Worklist
Analytical list page
Analytical list page
Object page
Object page

Usage

You can use the SAP Fiori elements framework if the floorplan and layout you need for your app design are supported. The overview page floorplan, analytical list page floorplan, dynamic page layout, and flexible column layout are all fully supported. If you want to use the object page or list report floorplans, check the respective guideline articles to see which features are supported for SAP Fiori elements.

If you want to use floorplans that are not supported by the SAP Fiori elements framework, or if you require several features that are not supported by the respective floorplan in SAP Fiori elements, you should go with a freestyle app instead.

One of the big benefits of SAP Fiori elements is the reduction in development effort. This is especially important for features like draft handling or the flexible column layout. If you need these features in your app, you should go with SAP Fiori elements.

For an overview of all available floorplans and layouts, see Overview – Layouts, Floorplans, and Frameworks.

Responsiveness

The responsiveness of SAP Fiori elements depends on the responsiveness of the floorplans and controls used in your app.

The SAP Fiori elements framework lets you influence the responsiveness of certain controls. For example, you can adapt the overflow behavior of actions and fields in the overflow toolbar, or change the pop-in behavior of columns in a responsive table.

Developer Hint
You can use the priority annotation to influence the responsive behavior of certain controls. This annotation supports the values “high”, “medium”, and “low”.

Adjustments

The behavior and interaction generally follows the guidelines for the respective floorplan or concept. If the guideline offers choices, the SAP Fiori elements framework offers the most generic option or, where possible, provides different options to choose from.

For example, the default table for list reports is the responsive table (or, for aggregated services, the analytical table). Other table types are offered as well, but have to be actively enabled by the application developer.

Deviations from the guidelines are sometimes necessary due to technical limitations, which are listed in the respective guideline artices. These limitations are usually short term and will be solved in future releases.

Developer Hint
You can adjust certain features by implementing breakouts, by adapting the manifest.json of your app, or through annotations or UI adaptation.

Mandatory Adjustments

Some UI texts provided by the SAP Fiori element contain generic placeholders. Always replace the default placeholders with an application-specific text. For more information about placeholder texts in SAP Fiori elements, see Replacing Standard UI Texts.

Examples of generic and adjusted texts:

Default Text Adjusted Example
List Report Create Object Create Sales Order
Object Page New Object New Sales Order
Overview Page Could not perform action Unable to approve the request

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Overview Page – Custom Card

Custom cards allow you to define the appearance of a card on an overview page, and the type of content that appears in the card content area. They offer additional flexibility when you require features that are not offered by the standard cards for overview pages.

Usage

Use a custom card if:

  • Your use case cannot be satisfied in any way by the standard cards provided for the overview page. Always consider the requirements below before using a custom card.

Do not use the custom card if:

  • You can satisfy your use case to a certain extent with the existing standard cards. Even if there are technical or visual limitations, stick with the standard cards if they are still workable for your scenario.
  • You are not using the overview page floorplan.
Information
Keep in mind:

  • A card is not a substitute for an application.
  • A card focuses on the most important task-related data. It lets the user view, filter, and react to information quickly.
  • The content must be defined for a specific context. Do not display irrelevant or unclear content.

Standard Requirements

Custom cards must meet the standard SAP Fiori requirements, especially:

  • Responsiveness: Ensure that the cards can run on different devices (touch, mouse and keyboard), using breakpoints supported by SAPUI5.
  • Cozy/compact: Provide different control dimensions as described by the visual design. If your existing design already covers both use cases (mouse and touch input), you do not have to provide two different designs. For more information on cozy and compact form factors, see content density.
  • Theming: Custom designs must allow theming and use the LESS parameters provided by the official Belize theme. Implementation of the customized design must be tested in all themes (high-contrast white, high-contrast black, and Belize Deep).
  • Accessibility: Support keyboard navigation and screen readers (as stipulated by accessibility requirements).
  • Browsers: Support all types of browser.
  • Performance: Ensure the performance of the implementation is satisfactory.
Information
Be aware that implementing a custom card costs time and effort for development.

Components

Custom cards have two components:

  • A mandatory header area
  • A mandatory content area
Custom card – card components
Custom card – card components

Card Header

The title and subtitle of custom cards follow the guidelines for standard titles and subtitles.

From the header area, users can navigate to the parent app. Since the entire header area is clickable, only one navigation target is allowed. We highly recommend offering this navigation option to give users access to the full-blown app with the complete set of results and actions. If a card displays a subset of grouped items, use a text label to show how many of the relevant items are showing on the card. Also refer to the guidelines for the overview page card header.

If a card features content with a single focal point (detail/entity), the header area navigation must always lead to this specific focal point. If a card features a subset of items grouped by a common criterion, the header area navigation must always lead to all items.

Custom card – header area
Custom card – header area

Card Content

The content area is reserved for application content and shows an entry-level view of the content. The use case determines what should be shown in the content area of a custom card. The content must adhere to the standard content guidelines.

Make sure that the content is responsive.

Provide a stable context for the content area and sustain it when the user navigates away from the overview page into another app. Transfer any sort or filter criteria to the application. In other words, show the same context, but with additional information.

Custom card – content area
Custom card – content area

Card Size

Please follow the guidelines for the fixed card layout. Make sure that the content is responsive.

Guidelines

Custom cards inherit the drag and drop behavior from the standard cards. Only place custom cards on the overview page itself (not in the object stream).

Custom cards must:

  • Provide information that is relevant for the user’s specific domain or role
  • Offer an entry-level view of application content
  • Represent a single topic, task, or context
  • Provide a stable context and sustain it after navigating from the overview page to another application
  • Be integrated in the Manage Cards dialog (show/hide cards)
  • React on filtering (when a smart filter bar is used)
  • Follow the guidelines for formatting dates, times, amounts, currencies, as well as for truncation (ellipsis). These guidelines are the same as for standard cards.
  • Contain consistent texts and formatting, aligned with the other cards on the overview page. Check the UI text guidelines for the overview page for details.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

No links.

Introduction to SAP Fiori Elements

SAP Fiori elements (formerly known as smart templates) provide a framework for generating UIs at runtime based on metadata annotations and predefined templates for the most used application patterns. The goals are to ensure design consistency, keep apps up to date with evolving design guidelines, and reduce the amount of frontend code for building SAP Fiori apps.

SAP Fiori elements use annotations that add semantics and structures to the data provided by the user.

SAP Fiori elements are part of the SAPUI5 delivery.

Currently Available

The following floorplans are currently available with SAP Fiori elements:

All floorplans support the dynamic page layout for full screen layouts. In addition, the new flexible column layout is available for the list report and object page.

Where applicable, SAP Fiori elements use the global edit flow, which includes draft handling, or the local edit flow without draft handling. SAP Fiori elements also offer message handling.

SAP Fiori elements – The production line for UIs
SAP Fiori elements – The production line for UIs

Responsiveness

The responsiveness of SAP Fiori elements depends on the responsiveness of the controls used.

SAP Fiori elements generally use priority annotation on fields and actions to control responsiveness. This annotation supports the values high, medium, and low. Annotating actions with a priority level helps to control the overflow behavior of the toolbar. In the responsive table, the priorities also define the pop-in behavior of columns.

Adjustments

The behavior and interaction generally follows the guidelines for the respective floorplan or concept. If the guideline offers choices, SAP Fiori elements implement the most generic option or, where possible, provide different options to choose from. The application can adjust the application via annotation, Web IDE, or UI adaptation.

Deviations from the guidelines are sometimes necessary due to current technical limitations, which are listed on the respective pages. These limitations are usually short term and will be solved in future releases.

The templates offer breakout scenarios at page level, where it’s possible to add, remove, or replace whole pages, and at section/control level.

Mandatory Adjustments

Some UI texts provided by the SAP Fiori element contain generic placeholders. Always replace the default placeholders with an application-specific text. For more information about placeholder texts in SAP Fiori elements, see Replacing Standard UI Texts.

Examples of generic and adjusted texts:

Default Text Adjusted Example
List Report Create Object Create Sales Order
Object Page New Object New Sales Order
Overview Page Could not perform action Unable to approve the request

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • No links.

Overview Page – Custom Card

Custom cards allow you to define the appearance of a card on an overview page, and the type of content that appears in the card content area. They offer additional flexibility when you require features that are not offered by the standard cards for overview pages.

Usage

Use a custom card if:

  • Your use case cannot be satisfied in any way by the standard cards provided for the overview page. Always consider the requirements below before using a custom card.

Do not use the custom card if:

  • You can satisfy your use case to a certain extent with the existing standard cards. Even if there technical or visual limitations, stick with the standard cards if they are still workable for your scenario.
  • You are not using the overview page floorplan.
Information
Keep in mind:

  • A card is not a substitute for an application.
  • A card focuses on the most important task-related data. It lets the user view, filter, and react to information quickly.
  • The content must be defined for a specific context. Do not display irrelevant or unclear content.

Standard Requirements

Custom cards must meet the standard SAP Fiori requirements, especially:

  • Responsiveness: Ensure that the cards can run on different devices (touch, mouse and keyboard), using breakpoints supported by SAPUI5.
  • Cozy/compact: Provide different control dimensions as described by the visual design. If your existing design already covers both use cases (mouse and touch input), you do not have to provide two different designs. For more information on cozy and compact form factors, see content density.
  • Theming: Custom designs must allow theming and use the LESS parameters provided by the official Belize theme. Implementation of the customized design must be tested in all themes (high-contrast white, high-contrast black, and Belize Deep).
  • Accessibility: Support keyboard navigation and screen readers (as stipulated by accessibility requirements).
  • Browsers: Support all types of browser.
  • Performance: Ensure the performance of the implementation is satisfactory.
Information
Be aware that implementing a custom card costs time and effort for development.

Components

Custom cards have three components:

  • A mandatory header area
  • A mandatory content area
  • A footer area (only mandatory for cards that show a subset of grouped items)
Custom card – card components
Custom card – card components

Card Header

The title and subtitle of custom cards follow the guidelines for standard titles and subtitles.

From the header area, users can navigate to the parent app. Since the entire header area is clickable, only one navigation target is allowed. We highly recommend offering this navigation option to give users access to the full-blown app with the complete set of results and actions.

If a card features content with a single focal point (detail/entity), the header area navigation must always lead to this specific focal point. If a card features a subset of items grouped by a common criterion, the header area navigation must always lead to all items.

Custom card – header area
Custom card – header area

Card Content

The content area is reserved for application content and shows an entry-level view of the content. The use case determines what should be shown in the content area of a custom card. The content must adhere to the standard content guidelines.

Make sure that the content is responsive.

Provide a stable context for the content area and sustain it when the user navigates away from the overview page into another app. Transfer any sort or filter criteria to the application. In other words, show the same context, but with additional information.

Custom card – content area
Custom card – content area

Card Footer

The footer area is used for cards that display a subset of grouped items. Use a text label to show how many of the relevant items are showing on the card for a subset of grouped items. For additional guidelines, see the guidelines for the overview page card footer.

Card Size

Please follow the guidelines for the fixed card layout. Make sure that the content is responsive.

Guidelines

Custom cards inherit the drag and drop behavior from the standard cards. Only place custom cards on the overview page itself (not in the object stream).

Custom cards must:

  • Provide information that is relevant for the user’s specific domain or role
  • Offer an entry-level view of application content
  • Represent a single topic, task, or context
  • Provide a stable context and sustain it after navigating from the overview page to another application
  • Be integrated in the Manage Cards dialog (show/hide cards)
  • React on filtering (when a smart filter bar is used)
  • Follow the guidelines for formatting dates, times, amounts, currencies, as well as for truncation (ellipsis). These guidelines are the same as for standard cards.
  • Contain consistent texts and formatting, aligned with the other cards on the overview page. Check the UI text guidelines for the overview page for details.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

No links.

Analytical List Page (SAP Fiori Element)

The analytical list page offers a unique way to analyze data step by step from different perspectives, to investigate a root cause through drilldown, and to take action on transactional content. All this can be done seamlessly within one page.

The purpose of the analytical list page (ALP) is to identify interesting areas within data sets or significant single instances through the use of data visualization and business intelligence.

Visualizations help users to recognize facts and situations, and reduce the number of interaction steps needed to gain insights or to identify significant single instances. Chart visualization increases the joy of use, and enables users to see relevant data more quickly.

The ALP provides full transparency of business object data and access to business actions. Business end users have access to analytical views and functions without being forced to switch between systems. The ALP displays KPIs (KPI tag), a visual filter where filter values are enriched by measures and visualizations, and a combined table/chart view with drill-in capabilities (hybrid view). Users can interact with the chart in order to analyze and understand object sets.

Analytical list page – Size XL
Analytical list page – Size XL

Snap visual filter bar to top

It is possible to snap the filter to the top to save space.

  • Analyitcal List Page - Snap To Top 1
  • Analyitcal List Page - Snap To Top 2

Elements and Controls

Implementation

Overview Page (SAP Fiori Element)

Overview page
Overview page

View, filter, and take immediate action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page. The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Easy filtering

  • Micro actions let users react on the spot

Usage

Use the overview page if:

  • The user has a specific role and needs to filter and react to information stemming from a range of applications.
  • The user needs to gather information from different sources that support a specific task focus or information need.
  • You want to give users a place to focus on their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page for the tasks of a specific domain or role.
  • You want to organize and display a set of (filterable) data to provide an entry-level view of content related to a specific domain or role.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page instead.
  • You want to show information about one object only. In this case, use the object page instead.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

Different entry points in SAP Fiori
Different entry points in SAP Fiori

As you can see in the picture above, the overall content scope (shown in gray) becomes more focused with each interaction step. The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Page
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
One SAP Fiori launchpad per user Multiple overview pages per user possible
Access to all the user’s favourite applications Selected applications are presented as cards
Uses tiles Uses cards
No actions Micro actions

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

Only provide an overview app for a role if it makes sense to do so. An overview page brings together information from different sources that support a specific task focus or information need. If a role or user has several such main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, and allow him or her to manage the performance reviews of the team. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that he or she is responsible for in the role of quality manager.

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps.

The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window. In the screen flow, always position the overview app between the SAP Fiori launchpad home page and the SAP Fiori app. Never start overview apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Responsiveness

The overview page floorplan is fully responsive. The card layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes.

Overview page – Size L/XL
Overview page – Size L/XL
Overview page – Size M
Overview page – Size M
Overview page – Size S
Overview page – Size S

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards. The card layout determines the size and position of the cards.

Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

Dynamic Page in the Overview Page

The overview page can consume four different versions of the dynamic page layout. All the variants have two things in common:

  • The floating footer toolbar is not included.
  • There are no global actions in the header title.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar.

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards
Floating footer toolbar – – – –

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Snapped mode for size XL/L/M
Dynamic page variant 1 – Snapped mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Snapped mode for size S
Dynamic page variant 1 – Snapped mode for size S

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text, which serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/snapped mode for size XL/L/M
Dynamic page variant 2 – Expanded/snapped mode for size XL/L/M
Dynamic page variant 2 – Expanded/snapped mode for size S
Dynamic page variant 2 – Expanded/snapped mode for size S

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size S
Dynamic page variant 3 – Size S

Variant 4 – Text in the Header Title and Smart Filter Bar 

In this variant, the header title contains a text, and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Snapped mode for size XL/L/M
Dynamic page variant 4 – Snapped mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Snapped mode for size S
Dynamic page variant 4 – Snapped mode for size S

Overview Page Layout

The overview page layout describes the position and size of cards in the content area below the dynamic page header (header title and header content).

Only place cards on the overview page. Never add tiles.

Card Layout

The card layout contains responsive (collapsible) columns of cards. The card width is fixed, and the height is determined by the card type and the embedded control.

There is no limit on the number of cards included. To view all the cards, the user just scrolls down.

Fixed card layout
Fixed card layout

The card layout uses padding on both sides. The cards are displayed inside collapsible columns, making the page fully responsive. When the user resizes the browser or uses a smaller screen, the columns containing the cards collapse. In this way, the layout can accommodate typical laptop screens, larger desktop monitors, and mobile devices:

  • Phone: 1 column
  • Tablet (portrait): 2 columns
  • Laptop / tablet (landscape): 3 columns
  • Large desktop: 4 columns
  • Extended monitor: 5 columns (maximum)

The width of the cards is tied to the column width. Breakpoints for the different screen resolutions determine whether the column width is 20 or 25 rem. The cards inside the columns adapt their width automatically. By contrast, the height of the cards is flexible, and depends on the content and type of card.

Rearranging Cards

Users can reposition cards on the overview page by dragging them to a different location. As the user drags a card, it swaps place with any cards in its path. Releasing the mouse or lifting the finger from the touch surface completes the move. To avoid gaps, cards always snap to the next free space in the row, or to the start of the next row.

The cards are arranged as a “Z” flow: cards are ordered from left to right, starting with the first card on the top left of the page. For example, if a 5-column layout is reduced to 4-column layout, the fifth card drops to the next row, assuming the leftmost position underneath the first card.

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the Me Area under Manage Cards. A popover appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Overview page – Manage cards
Overview page – Manage cards
Overview page – Manage cards dialog
Overview page – Manage cards dialog

Cards

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. Technically, a card is a smart component that uses UI annotations to render its content. Cards differ in the content they display: They can show a chart, a list, a table, informative text, or a combination of two elements. However, cards never have editable fields.

Cards can vary in size, depending on the selected layout. They can focus on a single object or topic, or on a group of objects.

Card Components

Every card comprises three components: a header area, a content area, and a footer area. The header and content areas are mandatory. The footer area is optional (for example, it is not needed on stack cards or analytical cards).

Make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

Overview page – card components
Overview page – card components

Card Header

The card header area is mandatory, and serves two purposes:

  • It indicates what the card is about.
  • It functions as a navigation area for opening the parent app, whereby the whole header area is clickable. We recommend offering this navigation on all cards (exception: link list card). 

The height of the header area is variable; it expands vertically to accommodate the text. The header area can contain two text fields: a mandatory title, and an optional subtitle. The primary purpose of the header area is to identify the content source, summarize the focus of the card (title), show any relevant parameters (subtitle), and offer navigation to the content source (parent app).

Title

The title is mandatory and represents the card’s “point of view”. In one or two words, it explains why this card exists and why a user might want to use it. It is a natural language reflection of the annotated view. Titles that exceed two lines are truncated with the ellipsis (…).

Subtitle

The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The use of the subtitle can differ, depending on the card type. Subtitles that exceed one line are truncated with the ellipsis (…).

Overview page – header area
Overview page – header area

Card Content

The content area is mandatory and is reserved for application content. Content is currently displayed on cards by embedding SAPUI5 controls that specify the properties and data format. For example, an embedded standard list control provides formatting, such as row height, font sizes, and the number of text blocks.

Card Footer

The footer is optional and is not needed for some types of card (such as stack cards or analytical cards). The footer area serves two purposes;

  • On quick view cards that display information on a single object or data point, you can use the footer area to offer related actions. In this case, the overflow toolbar control is used.
  • On cards that display a group of links (such as list or table cards), the footer area is used for information only. Use a text label to show how many of the relevant items are showing on the card (for example, Showing 3 of 10). If no items are returned, display the standard text No items found.

The height of the footer bar is fixed.

Card footer area with actions
Card footer area with actions
Card footer area with a positive summary text label
Card footer area with a positive summary text label
Card footer area with with a negative summary text label
Card footer area with with a negative summary text label

Formatting Dates, Times, Amounts, and Currencies

Apply the following formats:

  • Dates: The default is the relative date format (for example, Today). However, you can also use the medium date format (such as Aug 7, 2015).
  • Times: Times are not visible per default, but if you need to show a time, use the short format (for example, 11:28 AM).
  • Integers/Float/Currencies: Use the short format (for example, 1K for 1000).

Navigation and Interaction

The navigation and interaction depends on the technical card type:

This section looks at the different technical card types, how card views can be combined, and how to incorporate actions.

Single-Object Cards

Cards that feature content with a single focal point, detail, or entity are called single-object cards. An example is a quick view card with information about a particular product. Analytical cards are also single-object cards. The header area of this card type always navigates to this specific focal point, detail, or entity. The content area can also have interaction areas (for example, a section in a chart, or a telephone number for a contact). However, only quick view cards can have actions in the footer area.

Interaction for a single-object card
Interaction for a single-object card

Object Group Cards

Cards that feature a subset of items grouped by a common criterion are called object group cards. A typical example would be a list of purchase orders grouped by delivery date, amount, or supplier. The cards do not have actions, but each row or list item is selectable, thus providing direct navigation to the object details within the parent application. The header area of this card type always navigates to all items in the list or table. Object group cards include all types of list cards, bar chart list cards, and table cards.

Interaction for an object group card
Interaction for an object group card

Link List Cards

Link list cards allow you to display a collection of links or images that can reference both internal and external targets.

  • Links can navigate to a target or open a popover with additional information.
  • Clicking an image opens an image carousel.
Interaction for a link list card
Interaction for a link list card

Stack Cards

A stack card is a special card type for showing a collection of single-object cards. Stack cards have 3 components with different navigation areas:

  • The top-level stack card opens the collection and contains two clickable areas: the left area navigates to the parent app, and the right area opens the object stream.
  • The object stream shows individual cards that represent objects from the parent application. The object stream heading links to the parent application, while individual cards can contain links and actions relating to the respective object. A Close button returns the user to the stack card.
  • The last card in the object stream is the placeholder card. The entire card is navigable and leads the user directly to the parent application.
Interaction for a stack card
Interaction for a stack card
Interaction for a placeholder card
Interaction for a placeholder card

View Switch

You can use a view switch to offer two different content areas on one card, which can help to reduce the number of cards on the overview page. The user chooses the view using a select control. You can only combine views that have a common denominator. The options offered by the select control merely offer different perspectives. For example, a card “Purchasing Spend” (title in the header area) could offer two views “By Material Group” and “By Supplier” (options in the select control). The view switch is located between the header and content areas.

You can use the view switch for the following cards:

View switch
View switch

Actions on Cards

Only quick view cards within an object stream can have actions in the footer area. The overflow toolbar manages how the actions are displayed. All actions are right-aligned. Any actions that don’t fit into the available space move into the overflow action sheet, represented by the ellipsis ( ). A maximum of six actions are allowed in the footer area. Only offer actions the user really needs in the specific context.

Footer area with additional actions in the overflow
Footer area with additional actions in the overflow

There are two possible types of action: navigation and function import. Any combination of navigation and function import actions is allowed. Error or confirmation messages are displayed directly on the overview page.

Type: Navigation

Navigation is “intent-based” and takes the user to a different SAP Fiori app that specializes in executing an action. Navigation actions are always multi-click (meaning they can be repeated over and over). The destination screen opens in the same browser window, and any error or task confirmation messages are handled by the supporting application, not the overview page.

Type: Function Import

Function imports are custom OData service operations for actions. These actions are handled by the overview page, rather than by another SAP Fiori app. The interaction depends on whether or not the action requires user input:

  • If the action requires additional user input, the input parameters are handled directly on the overview screen without further navigation. A dialog appears on top of the card, allowing the user to enter data or make a selection. An example of additional input might be the rejection reason for a “Reject” action.
  • If the action has no input parameters, the action request is sent immediately. Once the action has been completed, the card disappears from the object stream.

Action on Phone

If an action on a card requires an input dialog box, use a full screen dialog on smartphones.

Card Types

The overview page supports the following standard card types:

Analytical Card

Analytical cards are used for data visualization. They are single-object cards that consist of two areas: a header area that displays the aggregated value of a key measure (KPI), and a chart area that displays a representation of data in graphical format. Analytical cards do not contain a footer area.

The KPI header is mandatory for analytical cards used on the overview page. The KPI header includes the title (mandatory), the KPI with the respective unit (mandatory), and a subtitle (optional). The subtitle can show the filter criteria used for the chart, and can contain up to two lines of text. The KPI itself uses the semantic colors red (negative), green (positive), or gray (neutral). You can also display a percentage indicator (optional) or triangle indicator showing an upward or downward trend (optional).

For more information, see analytical card.

The following (VizFrame) charts are available:

List Card

List cards are a type of object group card, and display a set of items in a vertical list. List cards use the sap.m.List container in the content area.

 

List Card Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application. Only aggregate list items in exceptional cases.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

List Item Types

Two different list item types are available:

  • The standard list item always shows 3 pieces of information and inherits the properties of the SAPUI5 control sap.m.StandardListItem.
  • The extended list item can show up to 6 pieces of information and inherits the properties of the SAPUI5 control sap.m.ObjectListItem.

You can only use one type of list item on any given card.

 

Size of a List Card

List cards resize according to the content available. The height can vary, depending on the number of text fields. Show no more than five standard list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

In addition, you can display the data on the right-hand side in semantic colors.

 

List Card Footer

In the footer area, indicate how many items are showing on the card in relation to the total number of relevant items. Use the summary text: Showing [Items on Card] of [Total Items], as in Showing 5 of 13.

List card with standard list item
List card with standard list item
List card with extended list item
List card with extended list item

Bar Chart List Card

Bar chart list cards are a type of object group card, and display a set of items in a vertical list. Unlike list cards, bar chart list cards are embedded in another component: the comparison micro chart. This allows you to display negative values and use semantic colors.

 

Bar Chart List Card Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application. Only aggregate list items in exceptional cases.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

Bar Chart List Item Types

Three different list item types are available:

  • The standard list item always shows 3 pieces of information.
  • The condensed list item can show up to 4 pieces of information.
  • The extended list item can show up to 6 pieces of information.

You can only use one type of list item on any given card.

 

Size of a Bar Chart List Card

Bar chart list cards resize according to the content available. The height can vary, depending on the number of text fields. Show no more than five standard/condensed list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

 

Bar Chart List Card Footer

In the footer area, indicate how many items are showing on the card in relation to the total number of relevant items. Use the summary text: Showing [Items on Card] of [Total Items], as in Showing 5 of 13.

Bar chart list card with standard list item
Bar chart list card with standard list item
Bar chart list card with condensed list item
Bar chart list card with condensed list item
Bar chart list card with extended list item
Bar chart list card with extended list item

Link List Card

Link list cards allow you to display a collection of links or images that can reference both internal and external targets. Links and images are handled as two separate variants:

 

Variant Type: List

The list variant shows a collection of links that can navigate to a target or open a popover with additional information. You can also show an optional subtitle below the link with a description or additional information. The link text and subtitle are each limited to one line.

You can display an icon or image before each link. For example, you might want to include app icons for set of links to recently-used apps, or images for a list of recent contacts. Use icons and images consistently:

  • If you opt to use icons, show an icon before every link.
  • If you include images, use a placeholder for images that are not available.
Link list card – Variant type
Link list card – Variant type "list"
Link list card – Variant type
Link list card – Variant type "list" with icons
Link list card – Variant type
Link list card – Variant type "list" with images

Variant Type: Image

The image variant uses the sap.m.Carousel control to display one or more images. If the carousel contains only one image, the Previous and Next icons and the paging indicator are not visible. The link and an optional subtitle are displayed above the carousel. The link text and subtitle are each limited to one line.

Link list card – Variant type
Link list card – Variant type "image"

Table Card

Table cards are a type of object group card, and display a set of items in a table format. Table cards use the responsive SAPUI5 control sap.m.Table.

 

Table Card Navigation

Clicking the header area of a table card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set.

Clicking a list item (row) on the card opens the detail view for that specific object in the same parent application.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

Size of a Table Card

Table cards resize according to the content available. The height can vary depending on the number of table cells. Tables are limited to a maximum of 3 columns and 3 rows, with a maximum of 3 lines of text per row. To see the full result set, the user needs to navigate to the parent app. All three columns can show either a data field or a data point. Data points can use semantic colors.

 

Table Card Footer

In the footer area, indicate how many items are showing on the card in relation to the total number of relevant items. Use the summary text: Showing [Items on Card] of [Total Items], as in Showing 5 of 13.

Table card
Table card

Stack Card

A stack card is a special collection of single-object quick view cards, based on a topic or action. Unlike the other card types, the top-level stack cards don’t show any application content. Instead, they act as an entry point to an object stream containing multiple cards.

Stack cards have the following components:

  • The title is the top element and is always required. It is used as the heading for the detail view, and comprises 1-2 lines of text.
  • The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The purpose of the subtitle is explain the content of the stack in one line, so its usage depends on the context.
  • The stack content count indicates the number of cards in the stack (object stream). The object stream can contain up to 20 cards. Below the number of cards in the stack, you see the total number of items returned for the annotated view (for example, “20 of 42”).

Overview Page - Stack Card

The top-level stack card contains two clickable navigation areas:

  • The left area and View All link navigate to the parent application, where the user can see all the objects returned for the annotated view (42 in the example above). The placeholder card and heading inside the object stream have the same navigation target.
  • The right area opens the object stream, which contains a scrollable collection of cards presented in an overlay format. The user can browse individual cards, with the option to view, inspect, or take action.

Quick View Card

Quick view cards are single-object cards. They display the basic details for one object, such as the name, address, and phone numbers for a contact. This card type is only available within the object stream; you can’t place quick view cards on the overview page itself. The quick view card inherits the SAPUI5 element sap.m.QuickView.

The header area contains a static text, such as Purchase Order, and an optional dynamic text, such as 1005-3345. In this way, each card header can show different content. Clicking on the header area of the card opens the detailed view of the object in the corresponding parent app. If the content area of a card cannot display all the information, a scrollbar appears on the right. Only the footer area of the quick view card can currently provide actions.

Quick view card for a contact
Quick view card for a contact
Quick view card for a product
Quick view card for a product
Quick view card for a purchase order
Quick view card for a purchase order

Object Stream

Overview page – Object stream
Overview page – Object stream

Clicking the right-hand area of the stack card opens the object stream. The object stream appears on top of the overview page as a modeless overlay, and serves as a layer for showing quick view cards with actions. The overlay has heading on the top left, and a Close button on the right. The heading is the same as the stack card title, and links to the full result set in the parent application (same target as the left-side navigation on the stack card and the navigation from the placeholder card). Clicking outside the overlay area also closes the object stream.

The object stream can have up to 20 cards, which all get their content from the same parent application. By default, the cards are ordered chronologically, with the most recent items first. However, app developers can define the best object stream sorting option for their own needs and custom content. If the number of cards exceeds the available space in the overlay window, an arrow icon appears on the right for scrolling. Mobile device users can swipe to see more cards. If the object stream is empty, the stack link is not active and the overlay cannot be opened. The stack count number displays 0. If only one item is returned, the object stream contains just a single card.

The header area of the quick view cards in the object stream navigates to the detail view for that specific object in the parent application. The footer area of the quick view cards can also offer actions.

 

Object Stream – Scroll Arrows

Scroll arrows only appear on desktop devices. If all the cards in the object stream fit on the screen, the arrows are not visible. If the number of cards exceeds the available space, an arrow icon appears on the right when the user mouses over the object stream overlay. Mousing over the arrow button area scrolls the cards across the screen from right to left. As soon as the first card on the left moves out of the visible overlay area, a second arrow appears on the left for moving in the other direction. Once the last card is in full view, the arrow on the right disappears.

Object Stream – Placeholder Card

If the number of items returned for the annotated view exceeds the maximum 20 cards allowed in the object stream, a placeholder card is added automatically at the end of the stream (as card 21). The entire placeholder card is navigable, and takes the user to the full result set in the parent application.

Overview page – Placeholder card
Overview page – Placeholder card

Object Stream – Tablet Version

On tablet devices, the modeless overlay expands horizontally. It also expands vertically to accommodate the card height and allow space for the title and Close button. The user can swipe through cards and perform micro actions. Swiping a card in view moves the entire object stream. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

 

Object Stream – Phone Version

On smartphones, the overview page layout collapses to a single column in both portrait and landscape modes. Tapping on the right-hand navigation area of a stack card opens the object stream on top of the overview page in a new full screen window.

The object stream expands horizontally and vertically to accommodate the card height, and to allow space for the title and Close button. The user can swipe through the cards and perform micro actions. Swiping a card moves the entire object stream. Since the cards are too large to fit on the screen in landscape mode, users can also scroll vertically to see the full card content. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

  • Overview page – Object stream interaction size M (landscape)
  • Overview page – Object stream interaction size M (portrait)
  • Overview page – Object stream interaction size S (lportrait)
  • Overview page – Object stream interaction size S (landscape)

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

Wizard Floorplan

The wizard floorplan allows users to complete a long or unfamiliar task by dividing it into sections and guiding the user through it. The wizard consists of the walkthrough screen, where the form sections are revealed in sequence after each one is completed, and the summary page, where the form is displayed in read-only mode for assessment and final submission. You can use the wizard both in full-screen and split-screen layouts.

Wizard - Steps
Wizard - Steps

Usage

When to Use the Wizard Floorplan

The wizard aims to help users by dividing large or complex tasks into segments. Use the wizard if the user has to accomplish a long task (such as filling out a long questionnaire) or a task that is unfamiliar to the user. The flow should consist of a minimum of 3 and a maximum of 8 steps.

The wizard can be used for both create and edit scenarios. If your application contains both, consider using the same means for both scenarios – either the wizard, or another create/edit screen (edit flow or object page).

When Not to Use the Wizard Floorplan

If you have a task with only 2 steps or a format that the user is familiar with (for example, it is part of their daily routine), do not use the wizard as it only adds unnecessary clicks to the process. If your process needs more than 8 steps, the wizard will not support those steps as the process is too long and can be confusing for the user. In this case, you should consider restructuring the task.

Consider if the classic edit screens (edit flow or object page) are more suitable for your use case.

Structure

The wizard has two main screens: the walkthrough screen, where users complete a segmented task, and the summary screen, where they can check the data they are about to submit. Wizard content is not restricted to forms; other content such as a value help dialog can also be used.

Walkthrough Screen

The walkthrough screen is the wizard’s main screen. After triggering the wizard, the user is taken to the walkthrough screen, which shows only the first section of the form. Once the user has filled out all the necessary fields, a Step XY button appears, which allows the user to move to the next step. When the user has completed the last section of the wizard, the button label changes to Review and the user is taken to the summary screen.

The wizard footer is used to display the Cancel button, which exits the wizard. If the user has modified any fields, a data loss message also prompts the user. You can also use a Save as Draft function in the footer if the form is long and the user may have to save it before finishing it.

Walkthrough screen in full screen layout
Walkthrough screen in full screen layout

The title in the header toolbar above the wizard remains unchanged during all the wizard steps. Align this title left, and make it clear to users where they are and what they are doing (for example, Create Sales Order or Edit Sales Order 4815162342). Especially in edit scenarios, it is vital to give users a unique identifier for the object they are changing.

Header toolbar with title
Header toolbar with title

The progress bar/anchor navigation below the header highlights the completed steps and the current step. It also allows the user to navigate between steps by clicking on any of the circles.

The progress bar exhibits a grouping behavior if there are multiple steps and the screen width is reduced. This behavior is the same on smartphone, tablet, and desktop screens.

Wizard header and anchor navigation
Wizard header and anchor navigation
Wizard tooltip – Grouped steps
Wizard tooltip – Grouped steps

In certain use cases, the steps in the wizard depend on the choices the user makes along the way. The user’s entries for one step determine the follow-on steps (“branching”). In these cases, a dotted line shows that more steps will follow.

Wizard branching
Wizard branching

Since the wizard is a lightweight way to create or edit objects, applications can use a quick confirmation popup instead of the heavier data loss message, when the user selects Cancel.

If the wizard is used to create an object, the text on the popup should read ‘Discard this ?’ (see image below).If the wizard is used to edit an object, please use the text ‘”Discard changes?” In both cases, the action on the popup should be Discard.

Structure – Quick confirmation
Structure – Quick confirmation

Summary Screen

On the summary screen, users can check all their entries before the object is actually created or changed. The summary screen has no progress bar or anchor navigation, and shows the form sections for all the steps in read-only mode.

To allow the user to go back and edit entries, provide an Edit button either in the footer toolbar or in each form section:

  • If you place the Edit button is placed in the footer toolbar, the user is taken back to the first section of the wizard.
  • If you offer Edit buttons for each section of the form, the user jumps to that particular step.

Alternatively, users can click or tap the Back button to go to the previous step. From there, they can scroll or tap through the sections.

The main action on the summary page should be the final action after completing the wizard, such as Create or Save.

Wizard summary page example
Wizard summary page example

Layout

Wizard structure in full screen layout
Wizard structure in full screen layout
Wizard structure in split-screen layout
Wizard structure in split-screen layout

Types

There are two types of wizard – “standard” and “branching” – which differ in terms of the functions they offer.

Use the standard type if:

  • The total number of steps is known in advance.
  • The number of steps does not change during usage.
  • There is linear progression from one step to the next.

Use the branching type if:

  • The total number of steps is not known.
  • The number of steps may change during usage.
  • There is non-linear progression. In other words, the user’s choice during one step determines which step comes next.

Styles

In addition to the functional types, there are also different visual styles.

Numbers and Icons

By default, both versions use a number inside a circle to represent each step. You can also use icons instead of numbers to help users identify the steps. If you plan to use icons, be sure to assign icons to all the steps (not just to some). The icons you choose should be unique and not look too similar. This will ensure that users do not get individual steps confused with one another.

Steps represented by numbers
Steps represented by numbers
Steps represented by icons
Steps represented by icons

Labels

To help users identify the individual steps even more easily, app developers can assign labels. As with icons, labels must be applied to all or none of the steps.

If there is enough horizontal space, all labels are shown.

All labels are visible
All labels are visible

As the width is reduced, the steps outside the currently selected one do not show labels.

Labels - reduced width
Labels - reduced width

Finally, the unselected and outermost steps are stacked on top of each other to further accommodate the reduced space.

Stacked labels
Stacked labels

Users can still easily access steps inside a stack. A single click opens a list of steps inside this stack.

Labels - stacked popover
Labels - stacked popover

Explanatory Texts

Ideally, the headlines and field labels for each step should provide enough information for users to complete their tasks. However, if additional explanations are needed, applications can put a simple text underneath a step’s headline – either via the sap.m.Text or the sap.m.FormattedText control.

Responsiveness

The wizard supports all common screen sizes and is available in cozy and compact modes, as well as high-contrast black (HCB).

Wizard – Size S
Wizard – Size S
Wizard – Size M
Wizard – Size M
Wizard – Size L
Wizard – Size L

Behavior and Interaction

Navigation and Error Handling

Navigation

Users can trigger the wizard app from another application, the launchpad, or a notification. The wizard always starts at the initial walkthrough page and ends after the user has clicked the main action (such as Submit) on the summary screen. The Step XY button is only used on the walkthrough page, and its purpose is to load the next section of the form.On the summary page, the user can use either the Edit button in the footer or the “back” arrow to return to the wizard and edit any of the fields.Modifying dependent steps: If there are steps that depend on each other (for example, a selection in step 2 triggers an optional step) and the user modifies the parent step, the dependent step is changed or deleted. This first triggers a warning message (when the input control loses focus) that data will be lost.

Error Handling

Error handling is done via message popovers. When the user clicks the Step XY button, the form sections and fields should be validated. When the user clicks the Submit button on the summary page, the entire form is validated. If there are any errors, the user stays on the walkthrough page, the message popover is displayed, and clicking any of the error items scrolls the page to the relevant field, which is also highlighted in red.

Section validation differs from validation of the entire form. In the first case, correct data entry in the form fields is validated. In the second case, the entire form is checked for backend system errors (such as duplicated data entry).

Dynamic Page

Header

Even though the wizard floorplan consumes the dynamic page, the wizard’s header does not allow snapping. Due to the nature of the wizard floorplan, the wizard brings its own step-based header that is already very space-saving.

Footer Toolbar

Contrary to the header, the footer toolbar of the wizard floorplan conforms to the standard layout and uses the sap.m.bar control.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • Wizard (SAPUI5 API reference)
  • Wizard (SAPUI5 samples)
  • Form (SAPUI5 API reference)
  • Form (SAPUI5 samples)

List Report (Floorplan + SAP Fiori Element)

List report
List report

With a list report, users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an object page.

The list report floorplan can be implemented in two ways:

  • Using the corresponding SAPUI5 controls in a dynamic page layout. This gives you much greater flexibility, but at the expense of more development time.
  • Using the SAP Fiori element for the list report. This generates the floorplan from OData annotations, which brings down development time. However, the SAP Fiori element list report is restricted to the most common features. Details on the SAP Fiori element for the list report are included at the end of each section.

Usage

Use the list report floorplan if:

  • Users need to find and act on relevant items by searching, filtering, sorting, and grouping across a large set of items.
  • Users need to display the whole dataset with different visualizations, such as a table or chart (for example, for reporting).
  • Drilldown is not required, or only rarely used. It is only available via navigation, not in-place.
  • Users work on different kinds of items.

Do not use the list report floorplan if:

  • Users need to see or edit one item with all its details. Use the object page floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (for example, if a barcode scanner is used to identify the item). Use the initial page floorplan instead.
  • Users need to work through a comparably small set of items, one by one. Use the work list floorplan instead.

Structure

The list report is a full screen floorplan based on the dynamic page. In addition to the SAP Fiori launchpad shell bar, the dynamic page contains the following areas:

  • The header title: Use this to display a title or the variant for the whole page, filter information (if the header is collapsed), and a header toolbar with global actions such as Share.
  • The header content: Use this to display the filter bar or the smart filter bar.
  • The content area: Use this to display:
    • An icon tab bar (optional)
    • One table/chart toolbar (per tab)
    • One or multiple tables and/or charts. You can use any kind of table. If you use a charts, they can be displayed exclusively (without a table), as an additional view for an existing table (switchable), or in addition to an existing table, where the chart and table are shown at the same time.
  • The footer toolbar: If needed, use a footer toolbar to display the messaging button and finalizing actions.

SAP Fiori Element List Report

The SAP Fiori element list report does not support:

Schematic visualization of a list report
Schematic visualization of a list report

Responsiveness and Adaptiveness

In general, the list report floorplan is responsive. However, there are exceptions if the following controls are used:

For more details, see the respective guideline articles.

SAP Fiori Element List Report

The SAP Fiori element list report automatically replaces grid tables and analytical tables with responsive tables on smartphones.
For tree tables, there is no meaningful fallback solution for smartphones.

List report - Size S
List report - Size S
List report - Size M
List report - Size M
List report - Size L
List report - Size L

Guidelines

Header Title

Variant Management

Variant management is optional. If used, apply it to the whole page. Use the variants to save and restore all settings for filters, selected tabs, all tables, and all charts.

Users can choose a default variant, which is selected every time the app is started.

Allow users to choose whether a variant should be executed automatically as soon as it has been selected. Not executing a variant automatically allows the user to add or remove filters before executing. Provide this option only if the filter bar is in manual update mode. For live updates, this option is not required.
If variant management is not needed, show a title that describes the current view instead.

Variant management
Variant management

Filter Information

Display the filter information only if the header content is collapsed. Use the following format: Filtered By (x):, followed by a comma-separated list of the filters currently applied. “x” stands for the number of applied filters.

Show up to 5 filters. If more filters have been applied, show an ellipsis (“…”) at the end of the string.

If no filters have been applied, show Filtered By: None.

Filter information
Filter information

Header Toolbar

Use this for non-finalizing global actions such as Share. Share opens an action sheet, which features Save as Tile (if the SAP Fiori launchpad is available), Send Email, and Share in SAP Jam (if SAP Jam is available). Show the Share button only if it makes sense for your application.

If the content area contains a grid table, an analytical table, a tree table, or any other content with its own scrollbar, display a Show Filters / Hide Filters button for expanding and collapsing the header content.

In addition, offer any other global, non-finalizing actions needed. Hide actions that cannot be used at all (for example, because of access rights). To save space on the header toolbar, group similar actions using a menu button.
For more information on global actions, see the guidelines for the header toolbar.

Header toolbar
Header toolbar

SAP Fiori Element List Report

The SAP Fiori element list report does not support a header title without variant management.

In the header toolbar, only Share is supported. There is no possibility to add app-specific actions.

By default, the variant management control saves the filter settings only. Change this setting to also save the table layout settings (manifest.json: smartVariantManagement).

Be aware that the SAP Fiori element list report supports only a single table in the content area, and no charts.

Header Content

The header content collapses when scrolling down the page (with responsive table, list, or tree only), and expands again when scrolling back up. To avoid this automatic expand/collapse behavior, users can also pin the header content so that it always stays open. Persist the pin setting.
Users can also expand and collapse the header content by clicking the background of the title bar.

If you are using a grid table, analytical table, tree table, or any other content with its own scrollbar, allow users to explicitly collapse and expand the header content manually with a Show Filters / Hide Filters button on the header title. Persist the expanded or collapsed state of the header content.

Header Content - Expand/Collapse Behavior

  • List Report (Floorplan + SAP Fiori Element) Header Expanded - 1.46

Filter Bar

The filter bar can contain a search field (optional). If you use the search field, the content shows only items that match both the search and filter criteria.

Filters are applied to all content, including all tables and all charts. To improve performance, consider providing mandatory filter fields and/or default settings for filters.

The filter bar offers two different update modes:

  • The live update mode (recommended) triggers filtering immediately whenever a filter setting is changed. If the search field is used, the search is triggered together with all filter settings with every letter typed.
  • The manual update mode displays a Go button, which triggers the filtering. If the search field is used, the search is executed together with all filters as soon as the Go button is pressed.
    Make sure that all tables and charts in the content area are in a busy state until the new data is available. Also ensure that the content is grayed out as soon as the filter settings do not correspond to the content shown (any table, property: showOverlay). This is usually the case if the content is not yet updated and the Go button needs to be triggered.

Use the manual update mode only if you run into performance problems while loading the table data.

Regardless of the update mode, make sure that the filter bar and the visible content match: The filter bar must always describe the items that are shown in the content area.

Filter bar
Filter bar

SAP Fiori Element List Report

Neither the expand/collapse state of the header content nor the pin settings are persisted.

In manual update mode, the content is grayed out whenever the user changes a filter after pressing Go, even if the change is reverted.
Within the smart filter bar, app-specific filters are also possible. Apart from the combo box, select, input field (with or without value help), date picker, and search field, you can also deploy other controls by using break-out options, such as the rating indicator (SmartFilterBar, annotation: UI.SelectionFields).

Content Area

General Layout

There are three basic list report layouts: simple content, multiple views, and multiple content. These are described in more detail below.

Simple Content

In most cases, the content consists of just a table toolbar and a table. If needed, provide an option to switch between the table and a corresponding chart view.

Multiple Views

For more complex scenarios, provide multiple views of the same content. A view consists of one or more of the following:

  • Displaying different columns of the same table
  • Displaying the same table in different pre-filtered states. These states are usually based on a status column, for example, items that are Open, In Process, or Closed. Make sure that the corresponding filter is not offered on the filter bar.
  • Differentiating between the items displayed in the content in some other fundamental way.

To switch between the different views, replace the table title with a content switch. The content switch can be:

If you have both a table title and a content switch, display the table title first, then the content switch. Place both on the left side of the table toolbar. Since the content switch is placed on the table toolbar, the same actions are shown for all views.

If you are using the content switch together with charts, ensure that the chart also reacts to the content switch. This can be done by:

  • Filtering the data that influences the display of the chart
  • Changing the measures and/or dimensions (for example, View by Country, View by Customer, …)
Table toolbar with a segmented button for up to three different views
Table toolbar with a segmented button for up to three different views
Table toolbar with a select control for more than three views
Table toolbar with a select control for more than three views

Multiple Content

To support even more complex use cases, a list report floorplan can also contain multiple tables that display different kinds of objects. The filter bar settings are applied to all of these tables in parallel. For example, a customer overview list report might display different tables for invoices, deliveries, and overdue payments. All of these tables can be filtered for a specific customer and a specific date.

Display each table inside a tab container of an icon tab bar. This also allows you to offer different actions on the table toolbar for each table.

List report floorplan with multiple tables placed in multiple tabs
List report floorplan with multiple tables placed in multiple tabs

Icon Tab Bar

Use the text-only version of the icon tab bar. Use the same name for the tab label and the table title. Display the number of items shown in the respective table on each tab (sap.m.IconTabFilter, property: count).

Icon tab bar
Icon tab bar

Table Toolbar

Display at least a table title (ideally with an item count) and icon-only buttons for sorting, grouping, and column settings. Do not offer additional filter settings on the table toolbar. For sort and group, show a view settings dialog with just the corresponding features enabled. For column settings, show the table personalization dialog. If you need more extensive functionality (for example, grouping or sorting on several levels, tables with more than 20 columns), use the P13n-Dialog with just the corresponding feature enabled.

If alternative visualizations are provided (such as charts), offer an additional view switch on the table toolbar. Triggering the switch replaces the current visualization with another one. If a table and chart need to be shown in parallel, offer a switch for the combined view.

In rare cases, you can offer an additional layout variant on the table toolbar. The layout variant stores view settings like the column order and the sort and group settings. If you use a layout variant, do not store the table settings in the filter variant. Offer this additional layout variant only if there is a strong use case for switching filter and layout variants independently. If there is no strong use case, or you are unsure, do not use a layout variant at all.

In addition, offer any other actions needed. Disable selection-dependent actions (such as Delete) if no or only non-fitting items are selected. Always enable selection-independent actions (such as Add). To save space on the table toolbar, group similar actions using a menu button. For example:

  • Release and Release with Conditions
  • Add Contact and Replace Contact
  • Edit Account and Edit Title

For more information on table/chart actions, see the guidelines for the table toolbar, the chart toolbar, and for managing objects.

Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Typical toolbar in the list report floorplan containing the table title with item count as well as buttons for sorting, grouping, and column settings
Toolbar with a switch between table and chart visualizations
Toolbar with a switch between table and chart visualizations
Toolbar with a table title and layout variant
Toolbar with a table title and layout variant
Toolbar with additional actions
Toolbar with additional actions
Do
Table without the filter icon
Table without the filter icon
Don't
Table with a filter option
Table with a filter option

Table

If there are not items to display, use the “no data text” of the corresponding table. Explain why the table is empty, and what the user needs to do to display items.

Examples:

  • After starting the app, no filters are applied:
    No filters set. To start, enter your search and filter settings and run the search.
  • The filter was executed, but no items were found:
    No items found. Try adjusting your search and filter settings.
  • By opening a related app, the filter criteria were transferred automatically, but no items were found:
    No items found. Check the search and filter settings.

Navigation

There are three types of navigation at item level in the list report floorplan:

  • Line item navigation: If applicable, allow navigation to a detail view (usually an object page) at line item level. Show a navigation indicator (chevron icon) for each line item that provides a detail view. In a list, tree, or responsive table, clicking the line item triggers the navigation.
    In a grid, analytical, or tree table, clicking the navigation indicator triggers the navigation.
    Another option is to use a link as identifier for the line item. This link triggers the navigation. Use this only if the navigation indicator is used for a different target.
  • Drilldown navigation: If a line item contains aggregated data, allow navigation to a view that contains details for the aggregated amount. This is usually another list report. In this case, use a link to display the aggregated amount. If the table contains many columns with links, use the link options to provide different levels of highlighting.
    In charts, offer the drilldown navigation link in the popover for the chart element. In this case, also navigate to the corresponding list report to show the details.
  • Cross navigation: If a line item contains cross-references to other entities, such as people or business objects, use a link to display the corresponding data point in the table. Triggering the link opens a quick view. Typically, the quick view displays basic details of the referenced object and a navigation link to another page (usually an object page) or another app that shows the object details.

Footer Toolbar

Use the footer toolbar to display the messaging button and finalizing actions. Only use the footer toolbar if finalizing actions for the whole page and/or the message popover are available.

Always show the footer toolbar in edit mode.

Hide actions that cannot be used at all (for example, if the user doesn’t have authorization). To save space on the footer toolbar, group similar actions using a menu button.

For more information on finalizing actions, see the guidelines for the footer toolbar.

Footer bar
Footer bar

SAP Fiori Element List Report

The SAP Fiori element list report supports only simple content. The icon tab bar and content switch are not supported. Only smart tables are supported. Since charts cannot be displayed, no view switch is needed.

The table toolbar supports:

  • Table title (annotation: UI.HeaderInfo, property: TypeNamePlural)
  • Item count: Turned on by default.
  • Variant management for the table layout: Although it is turned on by default, it should not be used in most cases. If the layout variant is turned off, the table layouts are stored together with the page variant (manifest.json: smartVariantManagement).
  • Several standard and custom actions (see below)

Actions cannot be grouped using a menu button on the table toolbar.

Within the SAP Fiori element list report, you can use the responsive table, grid table, analytical table, or tree table within the smart table.

The smart table supports:

  • No selection, single selection, or multiple selection (manifest.json: multiSelect). With multiple selection, the SAP Fiori element list report triggers the action for all selected items. If an error occurs with one or more of the selected items, it can be handled in the following ways (annotation: OperationGroupingType):
    • Partial processing: A message is displayed for the items with issues. All other items are processed.
    • Roll-back: A message is displayed. All items are reverted.
  • Text control in line items
  • Rating indicator within line items (annotation: UI.DataPoint)
  • Indicator for the editing status within the rows (for example Draft or Locked by [user]). Users can filter the table by editing status in the filter bar.
  • Line item navigation to different targets (maintain detail pages in manifest.json):
    • Navigation to a related object page within the app (default). Apps can override this behavior and define their own navigation target. The target can also depend on specific conditions defined by the app (maintain detail pages in manifest.json).
    • Cross navigation to another SAP Fiori app or to another system
  • Link and smart link to show details in a quick view or to navigate. A quick view can be used as part of the smart link or for displaying contact details. For navigation, the target can be any web page, another app, or a related object page within the same app.
  • Line item actions as text or icon buttons (such as Approve and Reject).
  • Any control that the corresponding table allows by using breakout columns.

At present, the smart table does not support:

  • The object number control. This is only available if you use a breakout column. Without a breakout, amounts appear as standard text only.

Only the responsive table supports:

The tree table does not support:

  • Standard line item navigation. In contrast to the all other tables, line item navigation works by selecting one item and using a Show Details button on the table toolbar.
It is not possible to change the alignment of table content.

Because the SAP Fiori element list report does not support editing use cases, the message button is not supported on the footer toolbar.
Actions cannot be grouped using a menu button on the footer toolbar.

Actions

Places for actions in the list report: header toolbar, table toolbar, line item, or footer toolbar
Places for actions in the list report: header toolbar, table toolbar, line item, or footer toolbar

The list report offers four locations for actions: global actions, table actions, line item actions, and finalizing actions.

1. Global Actions

Place actions that affect the entire page in the header toolbar in the header title (1). These include the following standard actions:

Hide actions that cannot be used at all (for example, because the user has no authorization). To save space on the header toolbar, group similar actions using a menu button.

Do not place actions that finalize the current process (“finalizing actions”) on the header toolbar of the header title, even if they affect the entire page.

For more information on global actions, see the guidelines for the header toolbar.

2. Table/Chart Actions

Place actions that affect the content of a table or chart in the table toolbar (2).

If an action applies only for selected items, disable it if no items are selected, or if the selected items don’t qualify for the action. For example:

  • Disable Remove if no item is selected.
  • Always keep Add enabled.
    Exception: The user needs to specify where in the table the item should be added. In this case, disable Add if no items are selected, or more than one item is selected.
  • Always keep Edit enabled if it switches the whole table to edit mode. If Edit applies only to one item or to a selection of items, disable it if no action is selected.
  • Disable object-specific actions if no item is selected.
  • Disable actions that change the status of one or multiple items if no item is selected.

Hide actions that cannot be used at all (for example, because the user has no authorization). If you are using an icon tab bar, please be aware that each tab contains its own table toolbar.

For more information on table and chart actions, see the guidelines for the table toolbar, chart toolbar, and for managing objects.

Information
When you use the list, tree, or responsive table, actions on the table toolbar move up out of the visible screen area when the user scrolls down, and are not accessible.

SAP Fiori Element List Report

The table toolbar provides the following built-in actions:

  • Add: An icon button that triggers an object page for creating an item. If this function is not needed, or if you want users to add or create items differently (for example, in a dialog), turn it off.
    Draft handling is supported (recommended). (annotation: Creatable)
  • Delete: A text button to delete selected items. Delete is enabled as soon as deletable items are selected. If this function is not needed, turn it off. (annotation: Deletable)
  • View Settings (sort, group, column settings): In contrast to the guidelines above, only one button is shown for sort, group, and columns settings. The icon button always opens the p13n-dialog with all features enabled. The less complex view settings dialog cannot be used.
    The SAP Fiori element list report also allows users to add filter settings within the p13n-dialog. This feature is only available if an explicit layout variant is being used for the table, which should not usually be the case. Do not use this feature.
  • In addition, you can add app-specific actions, such as Copy or Approve. These actions are displayed as text buttons. App-specific actions can be enabled or disabled, depending items selected in the table.

There are 3 types of app-specific action:

  • The system simply triggers the action.
  • The action requires user confirmation. Use this for critical actions that have severe consequences. A message box appears, and the user needs to confirm the action. The message displayed is generic and cannot be replaced (annotation: IsActionCritical).
  • The action needs additional user input, such as an approval comment. The system opens a dialog with one or more user input elements in which the user enters the required data. The system can pre-fill data if applicable (function import with parameters).

App-specific actions can also trigger navigation to another app or to a related object page within the same app. The navigation can depend on zero selected items, or on one selected item.

Actions cannot be grouped using a menu button.

Actions in the smart table toolbar
Actions in the smart table toolbar

3. Line Item Actions

In rare cases, actions that affect a single item can be placed directly inside the line item. Use this only for specific, frequently used tasks (3). If the same action can also be applied to several items at once, feel free to also place it on the table toolbar. Nevertheless, if you do so, reconsider whether you really need to offer the action at line item level. Examples of line item actions include:

  • Start/Stop (a batch job)
  • Approve (an item)
  • Assign (an item)

Line item actions are not usually disabled. Hide actions which cannot be used at all (for example, because the user has no authorization, or because the line item is in the “wrong” state).

4. Finalizing Actions

Place actions that trigger the end of a process and affect the entire page in the footer toolbar (4).

Examples:

  • Save
  • Cancel
  • Submit

Please be aware: Even if you are using the icon tab bar, there is only one footer toolbar for all tabs.

Hide actions that cannot be used at all (for example, because the user has no authorization).

For more information finalizing actions, see the guidelines for the footer toolbar.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object Page (Floorplan + SAP Fiori Element)

The object page floorplan allows the user to display, create, or edit an object. This is now the recommended floorplan for representing both simple and complex objects in SAP Fiori. It has replaced the flat object view floorplan and is set to replace the object view floorplan. The object page floorplan comes with a flexible header, a choice of anchor or tab navigation, and a flexible, responsive layout. These features make it adaptable for a wide range of use cases.

You can implement the object page floorplan in two ways:

  • Use the pre-built SAP Fiori element (formerly known as a smart template). This implementation uses OData annotations, and allows you to speed up development if the supported feature set matches your requirements. For an overview of the supported features, see the SAP Fiori Element section.
  • Implement the floorplan yourself using the respective SAPUI5 controls.
Object page floorplan
Object page floorplan

Usage

Use the object page floorplan if:

  • Users need to see, edit, or create an item with all its details.
  • Users need to get an overview of an object and interact with different parts of the object.

Do not use the object page floorplan if:

  • Users want to edit several items at the same time. Use the list report floorplan instead.
  • Users need to find relevant items without knowing the exact item details. Use the list report floorplan instead.
  • Users need to find one specific item, where the item or an identifying data point is known to the user (such as a barcode identified by a barcode scanner). Use the initial page floorplan instead.
  • Users need to be guided through a series of steps when a new object is created. Use the wizard floorplan instead.
  • The creation process for a new object is not linear, but can have different paths, depending on the information selected. Use the wizard floorplan instead.

Responsiveness

The object page floorplan is responsive and supports all SAP FIori screen sizes: small (S), medium (M), large (L), and extra large (XL).

Object page – Size S
Object page – Size S
Object page – Size M
Object page – Size M
Object page – Size L
Object page – Size L

The layout for size XL (large display) contains four columns.

The default layout for size L (desktop) contains three columns. You can also use an optional two-column layout.

Object page layout – Size L
Object page layout – Size L

The layout for size M (tablet) contains two columns.

Object page layout – Size M
Object page layout – Size M

The layout for size S (smartphone) contains one column.

Object page layout – Size S
Object page layout – Size S

Structure

The object page is a full screen floorplan with a display mode, a create mode, and an edit mode.

In all modes, the object page contains:

  • A snapping header
  • A navigation bar
  • A content area

The following sections explain these components in more detail.

Schematic visualization of object page
Schematic visualization of object page

Snapping Header

The snapping header is the uppermost element of the object page floorplan. It contains key information about the business object and provides the user with the necessary context. The header also contains global actions for the object.

Toolbars

The object page supports two toolbars:

  • Header toolbar: Use this toolbar for global actions such as Edit, Delete, Copy and Share.
  • Floating toolbar: Use this toolbar for closing and finalizing actions, such as Save, Post, Accept, Reject, and Activate.

This applies to all object page modes (display, edit, and create).

Responsive overflow toolbar
Responsive overflow toolbar

Navigation

There are three ways to navigate within the object page:

  • Anchor bar (by default)
  • No navigation (flat scrollable page)
  • Tabs

Usage

  • To offer a flat page for a simple object, remove the navigation.
  • For more complex objects, use the anchor or tab navigation.
Object page – Anchor navigation
Object page – Anchor navigation

Anchor Bar and Overflow

The anchor bar is the default navigation control for the object page. It consist of a series of anchor links, which are arranged horizontally at the top of the page. The anchors represent sections or subsections of the page. Clicking on these links directs the user to specific sections of the page. The anchor links remain visible when the user scrolls down the page.

Developer Hint
Use title case for the anchor bar texts. To do this, you need to change the default capitalization (block caps) by changing the the property upperCaseAnchorBar to “false”.

Overflow

If there are more anchors than the screen can accommodate, the remaining anchors move into an overflow menu. The overflow overview button on the right of the navigation bar ( ) opens a hierarchical dropdown list of all sections and subsections. When the user scrolls down the page, the anchor links scroll horizontally to ensure that the active anchor is always visible.

You might also see a small right arrow on the anchor bar. This arrow allows you to scroll horizontally to reveal any hidden content, and only appears when you hover over the overflow menu. In the meantime, this arrow has been replaced by the overflow overview button, but is still supported technically for legacy reasons.

Responsiveness

On small screens, the anchor bar becomes a dropdown list. The text field of the dropdown list shows the section currently selected. Clicking the dropdown menu opens a hierarchical list with all the sections and subsections of the document.

Object page – Anchor bar
Object page – Anchor bar
  1. Active anchor
  2. Inactive anchor
  3. Subsection dropdown
  4. Subsection
  5. Subsection dropdown indicator
  6. Overflow carousel button
  7. Overflow overview button
  8. Overflow overview dropdown
  9. Section (hover) in overflow overview
  10. Section in overflow overview
  11. Subsection in overflow overview

Behavior and Interaction

  • Clicking an anchor link scrolls the page to the selected section.
  • Clicking a section anchor that contains more than one subsection opens a subsection menu.
  • Clicking a subsection scrolls the page to the selected subsection. The keyboard left and right arrows allow the user to move between the anchor links.
  • Hovering over the fade area to the left or right of the anchor bar causes an overflow arrow button to appear (compact mode only). The overflow arrow button is always visible in cozy mode.
  • Clicking the overflow scroll button (right arrow) scrolls the anchors horizontally to bring anchors that are hidden in the overflow into view.
  • Clicking the overflow overview button ( ) displays a hierarchical dropdown list with all the sections and subsections of the document. Clicking an item in the overflow list scrolls to the respective section or subsection.
Object page – Anchor behavior and interaction
Object page – Anchor behavior and interaction

Hiding the Navigation

An object page can be used in a similar way to a flat object view. This is achieved by hiding the navigation bar from the object page, leaving a flat scrollable object. We recommend using this flat view for simple content that doesn’t require anchor navigation.

Tab Navigation

As an alternative to anchor navigation, you can also opt for tab navigation. The tab bar works in a similar way to the icon tab bar, but is not the same control. Tab navigation for the object page is a variant of the anchor bar, and is handled by the object page layout control.

If you set the tab bar property (useIconTabBar = “true”), the navigation bar displays tabs instead of anchors. The object page only supports text-only tabs; icon tabs and icon/text tabs are not available. The object page sections and subsections are reflected in the tab navigation: sections of the object page become the tabs, and subsections become the internal content of the tab. The tabs can have an item counter, which is displayed in parentheses next to the title of the tab.

On small screens, the tab bar uses the same horizontal carousel overflow pattern as the icon tab bar. This differs from the dropdown approach used for the anchor bar.

Tab Bar Subnavigation

To make it easier to reach specific content on a long tab page, tabs can have subnavigation. Subnavigation is optional and the default state is “false”. If the state is set to “true”, a dropdown arrow is shown next to the tab. Clicking on the tab displays a dropdown menu with the subsection anchors for that tab.

Object page – Tab navigation
Object page – Tab navigation

Breadcrumbs

If the object page uses a hierarchical parent-child drilldown, you can offer a breadcrumb for navigation. The breadcrumb is part of the snapping header.

Content Area

The object page content consists of sections and subsections arranged in a column layout. For large documents, you can enable a lazy loading mechanism (property: enableLazyLoading) to mitigate the loading time.

Sections

Sections are containers for subsections. They provide the basic structure for navigation, and are directly reflected in the navigation bar. Sections can have a title, subsections, and actions. However, they cannot contain controls.

Use title case for the section title (property titleUppercase = “false”). The title can have an item counter, which is displayed in parentheses. If a section contains only one subsection, the title of the subsection is used as the name of the section. In this case, there is no subsection submenu in the anchor bar.

Global actions are always placed at subsection level. Sections can only contain subsections, not content. Because of this, the object page only provides toolbars for global actions at the subsection level.

Subsections

Subsections are the containers for actual content. Always place individual controls inside the subsections. Subsection content is arranged according to the column layout approach for the respective screen size. A subsection can include containers for different controls (mixed content).

Subsections have a progressive disclosure mechanism to show and hide content. App developers can specify which content is shown initially, but the user can also display everything by selecting the Show All button at the bottom right of the subsection.

Each subsection can have a toolbar, which is placed at subsection header level on the right. The toolbar contains actions that affect the content of the subsection.

Subsections within the same section are separated by a gray horizontal line. Subsections can have an item counter, which is displayed in parentheses next to the subsection header.

You can include various types of related content in one subsection. The layout blocks for the object page give you the flexibility to combine different content types.

Responsiveness

The content blocks in a subsection display in a row. The width of the row depends on the column layout for the respective screen size. If there is not enough space to display a content block, it wraps to the line below.

Object page – Content responsiveness
Object page – Content responsiveness

Forms

Forms follow the standard layout of the object page:

  • Large: 3 columns
  • Medium: 2 columns
  • Small: 1 column

Forms are located within subsections. They follow the column design of the object page, whereby each form group is arranged into a column. The title of the form is given by the subsection header. Only use the form title if you are using several forms within the same subsection.

Use top-aligned labels for form fields. Top-aligned labels are known to reduce completion times, and are the best approach for forms requiring localization or long labels. Using top-aligned labels also avoids issues with the spacing between the label and form field, which can occur with left- and right-aligned labels.

Blocks

Layout blocks allow content to be aligned within the columns as follows:

  • Layout 1: Occupies the maximum available horizontal space of one column.
  • Layout 2: Occupies the horizontal space of only two columns. If there is only one column available, it occupies one column.
  • Layout 3: Occupies the horizontal space of three columns. If there is only one column available, it occupies one column. If there are only two columns available, it occupies two columns.
Object page – Blocks
Object page – Blocks

Contacts

The contacts on the object page are technically a list, but they can be represented visually as a card.

The cards can contain:

  • An image (optional)
  • A title (mandatory)
  • A subtitle (optional)
  • A text snippet consisting of two lines maximum (optional)

A single card covers the column’s entire horizontal space. To avoid alignment problems, all cards are the same height. The card with the most content defines the overall height for all cards. The image can be rectangular or round. It shows in the top left corner of the card. The content of the card never truncates. If there is not enough space to display the information, it wraps onto the next line.

Content type – Contacts
Content type – Contacts

Tables

In an object page, tables with up to 20 expected items can be displayed right away without lazy loading.

If a table is expected to have more than 20 items, use one of the following 3 options for long tables:

1. Lazy Loading Behavior (“More” button)

If you expect up to 100 items, use the More button of the responsive table. The initial amount of items shown depends on the height of the rows. We recommend initially showing 5 to 10 items, but not more than 20. If there is more than one table in the object page, this option should be used only for tables with up to 50 expected items.

2. Tab Navigation

If you expect to have more than 50 to 100 items, but less than 400, using the object page with tab navigation instead of anchor navigation also solves the problems associated with long tables. Here it is important to place the table within a tab as the only or at least the last element and to enable the scroll to load behavior.

3. Navigation to List Report

For tables with more than 400 items, or when the tab approach is unsuitable, the table itself should be restricted to a reasonable amount of items. We recommend only showing a preview of the data in the table, which should not contain more than 20 items. Ideally, you should have about 10 items. This can be either be achieved by prefiltering and/or by sorting the table, and if necessary, by restricting it to a fixed amount of items (such as top 10). To provide the user with a way to work with the entire table, a navigation to a separate list report containing the full table must be offered.  This navigation should be located below the table in the form of a right-aligned link labelled Show All (x), with x representing the total amount of items in the table.

In the object page, we recommend that you do not use the analytical, grid and tree tables. Instead, use a responsive table and offer navigation to a list report with the table types mentioned above.

For all of the three options mentioned above, we recommend providing a search, and if feasible, sort and filtering for the table in the object page. Grouping should be avoided.

Table with navigation to a separate list report
Table with navigation to a separate list report

Child Page Representation

In object pages with drilldown navigation, child pages are represented in three ways:

  • Visual representation in the header: A narrow blue band is displayed in the left margin of the snapping header.
  • Breadcrumbs: A breadcrumb is displayed above the object title. Limit the breadcrumb to the drilldown levels within the object page.
  • Item navigation arrows: Up and down arrows in the application toolbar allow the user to navigate between subitems without going back to the original list.

Behavior and Interaction

Edit

The basic layout of the object page in terms of header, navigation, and content remains the same in all modes (display, edit, create). In edit mode, the object page can contain a mixture of editable and read-only content.

If the user needs to edit elements in the header, a header section is added in the content area for edit mode to enable editing.

Use the same content layout for both display and edit mode. Content should not change location when the user switches between display and edit modes.

For global and local editing guidelines, see manage objects – create, edit, delete.

Editing the Header

The object page header can be edited in two ways:

  • Global edit
  • Partial edit

Global Edit

The header can be edited when the entire object page is in edit mode.

Because the header snaps on scroll, there are no editable forms in the header itself. Instead, a temporary header section is added before the other sections of the page. The title bar information and all editable fields from the header container move from the header to the new editable header section. Any non-editable content displays as read-only. You can leave out header content that doesn’t make sense in edit mode (for example, aggregated values that are calculated from several sources, KPIs, or micro charts).

If only a few fields in the header are editable, and they match an existing section, they are moved to that section. In this case, no editable header section appears.

Object page – Global edit with header container and independent header facets
Object page – Global edit with header container and independent header facets

The header container in edit mode may contain independent facets that are not included in the header content in display mode. They provide information to assist editing.

If the entire object page is in edit mode, but there is no editable information in the header, no editable header section is added.

Any changes made to the header are not reflected until the user saves them.

Partial Edit

The user can edit the header content separately by pressing the Edit Header button.

If there are only a few elements to edit, the partial edit triggers a dialog.

If there are too many elements to fit on a dialog, the partial edit triggers a subpage. The subpage contains all editable information from the header. However, it differs from the “Header” section in global edit mode in that it has no action buttons in the toolbar, no navigation, and no breadcrumbs.

Object page – Partial edit with dialog
Object page – Partial edit with dialog

Unsaved Changes

If draft handling has been implemented, documents are automatically saved as draft versions in the background. An editing icon to the right of the object title indicates that a draft version exists. In other words, either the current user or another user has made changes, but not yet actively saved the document (“unsaved changes”). Do not show the editing icon for unsaved changes if draft handling is not supported.

Selecting the editing icon invokes a popover with more information about the unsaved changes. This normally states:
•Who made the changes
•When the last changes were made

The popover closes when the user clicks or taps the Close icon or anywhere outside the popover.

Unsaved changes popover
Unsaved changes popover

Create

Create mode is similar to edit mode, except that the user creates a new object and defines a title for it. Until the new object title is known, use the placeholder text “New ” (for example, “New Purchase Order”). Replace the placeholder text with the actual name or ID of the new object as soon as this has been entered or generated.

Consider using the wizard floorplan instead of the object page floorpan if:

  • You need to guide the user through a series of steps when a new object is created.
  • You need a progressive disclosure approach for the creation process.
  • The creation process is not linear, but can have different paths, depending on the information selected.
  • The user is not familiar with the creation task.

Guidelines

Header

Use the header to set the context. Ensure that it is clearly structured and contains only essential information. Too much information impedes the main purpose of providing a clear context.

Actions

Arrange the actions in the header toolbar with care, and consider what matters most to the user:

  • Highlight actions that are common or most important.
  • Differentiate between secondary and generic actions.
  • Use either a text button or an icon for an action, but not both.
  • Place the most important actions on the left (actions go into the overflow from right to left).
  • Establish a coherent visual approach.
Do
Object page floorplan – Good example of how to arrange actions
Object page floorplan – Good example of how to arrange actions
Don't
Object page floorplan – Bad example of how to arrange actions
Object page floorplan – Bad example of how to arrange actions

Tab Navigation

Use tab navigation if you need a facet approach to your content. This could be due to performance issues in a flat view, or in response to a specific user preference. If you need to use icons, tabs as process steps, or tabs as filters, use the object view floorplan.

Not a Content Dump

Avoid using the object page as a universal container for masses of information. You should use the object page in accordance with the SAP Fiori principles: role-based, coherent, simple, and adaptive.

Simplify Content for Your Users

Give your users quick and easy access to the information they need to complete their task(s). Use a progressive disclosure strategy to keep your interface clean. You can always provide additional information on request. Furthermore, only present your users with information that makes sense for their industry, role, activity, and task.

Dynamic Side Content

You can offer dynamic side content alongside the object page under the following conditions:

  • Use the side panel only for contextual content. Do not place finalizing or global actions in the side panel. This is because opening the side panel occupies the whole right side of the screen. There is no way to show it only below the header and anchor bar.
  • Do not place object information in the side panel. This information should always be in the content area of the object page.

SAP Fiori Element

Use the table below to see which features are available for the “object page” SAP Fiori element.

Feature Status Comments
Snapping Header
General
Fiori 2.0 merged header Supported
Header always expanded Supported
Header container on/off Supported
Header container on/off in different modes Supported
Header container expand on click Supported
Child page navigation Supported
Subtitle optional Supported
Arrow icon showTitleSelector Not Supported
Breadcrumbs Supported
Favorite behavior Not Supported With indicator next to the title.
Flag behavior Not Supported With indicator next to the title.
Unsaved changes behavior Supported With indicator next to the title.
Lock behavior Supported With indicator next to the title.
Header Facets
Different header facets in different modes Supported
Wrapping behavior for header facets Supported
Image facet square Supported
Image facet round Supported
Image header facet with placeholder Supported
Image header facet in different sizes Supported
Key value facet with unit Supported
Key value header facet with trend Not Supported
Key value facet with same text/numeric size Supported
Microchart header facet Partially supported Currently available for bullet and area charts.
Microchart header facet subtile optional Supported
Microchart header facet footer optional Supported
Microchart header facet with rating indicator Supported
Microchart header facet with progress bar Supported
Form header facet with optional labels Supported
Form header facet with icons as labels Not Supported
Form header facet with links as values Supported
Form header facet value with semantic color Supported
Key value header facet with link as value Supported
Key value header facet with semantic color on value Supported
Plain text header facet Supported
Breakout header facet Not Supported This also includes adding controls to existing header facets.
Toolbar
Header toolbar select, combo box, multi-combo box Not Supported
Header toolbar semantic buttons Supported
Header toolbar highlight buttons Supported
Header toolbar segmented buttons Not Supported
Toolbar overflow Supported
Toolbar overflow prioritization Supported
Icons as buttons Supported
Action sheet in buttons Supported
Prioritization of custom actions in toolbar Supported
Show Edit Header button (partial edit) Not Supported
Navigation
Navigation hidden if object has only one subsection Supported
Counts in anchors and section/subsection headers Not Supported
Carousel overflow for horizontal navigation Supported
Mobile navigation behavior (dropdown) Supported
Navigation overflow overview button Supported
Tab navigation Supported
Tab with anchor subnavigation Not Supported
Anchor behavior Supported
Content
General
Partial edit Not Supported
Forms in content Supported For more on the form features, see the forms article.
Actions in forms Partially Supported Currently only via breakout. Actions go into the subsection toolbar.
Timeline in content Not Supported
Carousel in content Not Supported
Contact cards in content Partially Supported
Mixed content Supported
Block controls Not Supported
Lazy loading Work in Progress
Side panel Not Supported
Scroll to specific section on loading Not Supported
Layout
Content layout in size S (1 column) Supported
Content layout in size M (2 columns) Supported
Content layout in size L (3 columns) Supported
Content layout in size L (2 columns) – optional layout Not Supported
Content layout in size XL (4 columns) Supported
Sections and Subsections
Toolbar in subsections Not Supported
Toolbar in sections Not Supported
Toolbar in sections containing only one subsection Not Supported
Subsection toolbar with custom actions Not Supported
Subsection toolbar with buttons Not Supported
Subsection toolbar with highlighted buttons Not Supported
Subsection toolbar with semantic buttons Not Supported
Subsection toolbar with segmented buttons Not Supported
Subsection toolbar with select combo box or multi-combo box Not Supported
Subsection toolbar with buttons with actions sheets Not Supported
Use of priorities in sections/subsections Not Supported
Tables
Responsive list in content Not Supported
Responsive table in content Supported For specific table features, see the guidelines for tables.
Grid table in content Supported For specific table features, see the guidelines for tables.
Display responsive table instead of grid table on mobile devices Supported For specific table features, see the guidelines for tables.
Analytical table in content Supported For specific table features, see the guidelines for tables.
Display responsive table instead of analytical table on mobile devices  Supported For specific table features, see the guidelines for tables.
Tree table in content Not Supported

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation


Overview – Layouts, Floorplans, and Frameworks

SAP Fiori has a simple user interface hierarchy, designed to support users in the best possible way. In general, the SAP Fiori launchpad is the entry point for the user. All the apps available to a user are presented as tiles in the app finder, while the home page shows a personalized view of tiles the user has selected. The shell bar offers an enterprise search and other services, which are available across all apps.

Most app designs are based on one of the two basic page layouts that we call split-screen layout and full screen layout. These basic page layouts can be used with a range of different floorplans.

Floorplan is an umbrella term for the overall SAP Fiori UX concept for floorplans. It covers the different layout types, the structure of the controls used, and how to handle different use cases. Floorplans can be built with SAP Fiori elements, or built from scratch (freestyle apps).

An application contains normally several pages. Every page shows a single floorplan, For example, the user starts by filtering a list in the list report floorplan and from there drills into a detail page showing the object page floorplan.

To get a better idea of the different floorplans, read on below.

Overview of Page Layouts

Dynamic Page Layout

Dynamic page layout
Dynamic page layout

The dynamic page is a new layout control and it is designed in a way to support various floorplans and use cases. The layout is full responsive and will be the successor of the full screen layout with additional functionality to have a coherent and consistent snapping header concept that can be adapted throughout all floorplans.

For more information, see dynamic page layout.

Full Screen Layout

Full screen layout
Full screen layout

The full screen layout uses the full width of the screen to display the app content. This layout provides maximum flexibility while maintaining the look and feel of SAP Fiori. The full screen layout is ideal for displaying wide tables with four or more columns, and for showing various types of information on one page. However, it is difficult to ensure that the layout is responsive due to the immense differences between a widescreen desktop and a mobile phone.

The new layout for displaying pages in full screen is the dynamic page layout. The dynamic page layout offers more flexibility and integrates features like the snapping header. It is the successor of the full screen layout. Please, check if you could use the dynamic page layout instead. From wave 1.44 (1702) on the full screen layout will be deprecated.

For more information, see full screen layout.

Flexible Column Layout

Flexible column layout
Flexible column layout

The flexible column layout is a responsive layout control that displays multiple floorplans on a single page. This allows a faster and more fluid navigation between multiple floorplans compared to the usual page-by-page navigation. It offers different layouts with up to three columns (panels). Depending on which panel the user is focused on, it can get prioritized (wider). The user can also switch between different layouts and view the last panel in full screen. The flexible column layout is the successor of the split-screen layout.

For more information, see flexible column layout.

Split-Screen Layout

The split-screen layout is one of the most widely used and stable layouts in SAP Fiori. Use this layout if the user needs to switch easily between different work items. The master list on the left shows key information for each item, while the content area on the right shows the details and available actions. This layout lets the user work down the list without additional navigation. On a phone (or when the screen becomes too narrow), the master list and the details are split into two separate pages and the user navigates between the two.

For more information, see split-screen layout.

Dynamic Side Content

Dynamic side content layout
Dynamic side content layout

The dynamic side content layout is a control that allows additional content – such as a timeline, chat, and additional information – to be displayed in a way that flexibly adapts to different screen sizes. The behavior of the control on smaller screen sizes can be configured by app development following the guidelines.

For more information, see dynamic side content.

Overview of Floorplans

Object Page Floorplan

Object page floorplan
Object page floorplan

The object page floorplan is the new way to represent objects in SAP Fiori. The object page replaced the flat object view floorplan and the object view floorplan. New features in the object page, such as flexible headers, an alternative anchor, tab navigation, and a flexible responsive layout, enable you to adapt it for a wide range of use cases.

For more information, see object page floorplan.

Initial Page Floorplan

Initial page floorplan
Initial page floorplan

Use the initial page floorplan if the user has to navigate directly to one object to view or edit it. The interaction point on the screen is a single input field that relies on assisted input to direct the user to the object in as few steps as possible (for example, value help and search as you type). If you need to display more than one object, use the list report floorplan instead.

For more information, see initial page floorplan.

List Report Floorplan

List report floorplan
List report floorplan

The list report floorplan allows the user to work with large lists of items and take action. This floorplan combines powerful filtering capabilities for large amounts of data with diverse and useful ways to display the resulting item list. This floorplan can only be used in the full screen layout.

For more information, see list report floorplan.

Worklist Floorplan

Worklist floorplan
Worklist floorplan

The worklist floorplan displays a collection of items to be processed by the user. Working through the item list usually involves reviewing details of the list items and taking action. In general, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan lies on processing the items. This differs from the list report floorplan, which focuses on filtering content to create a list.

For more information, see worklist floorplan.

Wizard Floorplan

Wizard floorplan
Wizard floorplan

The wizard floorplan guides users through long and/or unfamiliar tasks by dividing the task into sections and guiding the users through the different sections. The wizard comprises a walk-through screen, where the form sections are sequentially revealed as they are completed, and a summary page, where the form is displayed in read-only mode for assessment and final submission. This floorplan can be used in both full screen and split screen layouts.

For more information, see wizard floorplan.

Create Page Floorplan

Create page floorplan
Create page floorplan

The create page floorplan is the simplest way to create new objects. It can either be used as a standalone in a full screen app, or as part of a split-screen layout. The floorplan is a regular form with multiple sections containing forms and tables. Users create the content in place, or by branching off into separate create screens (for example, to add items to a table).

The flow of the form should follow the logic for creating the respective object. For validation, forms use in-place messages that appear directly by the fields.

For more information, see create page floorplan.

Object View Floorplan

Object view floorplan
Object view floorplan

The object view floorplan was the original floorplan used to display simple objects in SAP Fiori. It has since been replaced by the more comprehensive object page floorplan.

From guideline version 1.42, the object view floorplan is only allowed in combination with the icon tab bar.

For more information, see object view floorplan.

Overview of SAP Fiori Elements

SAP Fiori elements provide a framework for generating UIs at runtime based on metadata annotations and predefined templates for the most used application patterns. For more information, see the introduction to SAP Fiori elements.

List Report

List report - SAP Fiori element
List report - SAP Fiori element

The SAP Fiori element list report is an instance of the general list report floorplan implemented as a reusable template. Therefore, the guidelines for the list report generally apply. The list report floorplan allows the user to work with large lists of items and take action.

For more information, see list report floorplan.

Object Page

Object page – SAP Fiori element
Object page – SAP Fiori element

The object page floorplan is used to view, edit, and create objects. The object page can also be implemented as a SAP Fiori element. For details about the general floorplan and the SAP Fiori element, see the object page guidelines.

Overview Page

Overview page - SAP Fiori element
Overview page - SAP Fiori element

Based on a specific domain or role, the overview page (OVP) is a new data-driven SAP Fiori app that provides all the information a user needs to view, filter, and react to data in a one-stop-shop page. The OVP employs cards (containers of content) based on smart template technology as a UI framework for organizing large amounts of information on an equal plane within the page.

For more information, see overview page (SAP Fiori element).

Overview of Frameworks

Analysis Path Framework

Analysis Path Framework (APF) is a framework for creating interactive, chart-oriented analytical drilldown apps by configuration. APF-based apps enable the user to view and analyze the data of several key performance indicators (KPIs) from different data sources. Users can interactively explore data step by step from different perspectives to analyze and investigate root causes.

For more information, see Analysis Path Framework.

SAP Smart Business Framework

SAP Smart Business drilldown is an analytical app. It enables the user to view and analyze the data of one key performance indicator (KPI).

For more information, see SAP Smart Business Framework.

Worklist Floorplan

Work list with actions at line item level

A worklist displays a collection of items that are to be processed by the user. Working through the item list usually involves reviewing details of the list items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan lies on processing the items. This differs from the list report floorplan, which focuses on filtering content to create a list.

Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Your app uses the full screen layout. The full screen worklist is preferable if the work items are complex objects. For simple scenarios, use the split-screen layout instead.

Do not use the worklist floorplan if:

  • You want to create only a lightweight worklist. Instead, use the split-screen layout for simple scenarios.
  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (graphics or tables). In this case, use the list report floorplan instead.

Layout

The launchpad shell bar is always available at the top of SAP Fiori apps. The app title (app header) reflects the title of the launch tile, such as Manage Products.

The worklist contains a list of work items. You can also use the icon tab bar to split the list into different categories. In addition, the worklist can use filters and variants, as described for the list report floorplan. Bear in mind, however, that if users can filter the list, they may also overlook important work items.

To ensure that the application runs on all devices, we recommend using the responsive table. The responsive table also offers a wide range of options for optimizing the layout, scalability, and how the user takes action.

Basic structure
Basic structure

Responsiveness and Adaptiveness

Worklist floorplan - Size S
Worklist floorplan - Size S
Worklist floorplan - Size M
Worklist floorplan - Size M
Worklist floorplan - Size L
Worklist floorplan - Size L

Worklist Floorplan with the Dynamic Page Layout

Variant Management & Global Actions

The header title of the dynamic page provides a variant management and the global actions. The header title displays the selected tab if the header content is collapsed.

Dynamic Page Header

The header content of the page gets a snapping behavior. This includes the tab bar. The header content collapses after scrolling the page if used with the sap.m.table (responsive table), or can be collapsed manually if used with the sap.ui.tables (grid tabel, analytical table (ALV), tree table).

Footer Toolbar

In edit mode or for finalizing actions there is a footer toolbar. This element appears on the bottom of the page content and contains finalizing actions.

Types

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a list.

Simple worklist without tabs
Simple worklist without tabs

Category Worklist

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs can also contain tables with different configurations (for example, with different columns or actions).

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red on the Error tab below).

Worklist with tab categories
Worklist with tab categories

KPI Worklist

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI in the subheader.

Worklist with KPI
Worklist with KPI

Actions

Worklist with table toolbar for actions
Worklist with table toolbar for actions

The header title contains the global actions. These actions can apply to individual or multiple items selected by the user. Placing actions in the toolbar allows users to process several items at a time. However, more clicks are required to process individual work items.

Worklist with actions at line item level
Worklist with actions at line item level

You can also offer actions at line item level. This reduces the interaction required to a single click per item. Consider offering actions at line item level for most frequently used actions, and if the list provides enough information to make the a decision.

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen.

Worklist with navigation to item details
Worklist with navigation to item details
Work item details
Work item details

Once the user has completed the task, the app should:

  • Return the user to the worklist.
  • Remove the processed item from the list, or move it to a “completed” section.
  • Confirm the user’s action with a message toast.

Visual Design

The worklist has no visual design of its own, but app design and development teams should ensure that the margins and padding are similar to those of the normal page layout. For example, the controls should have the same margins inside the side content container.

Basic layout of the worklist on a smartphone (Size S)
Basic layout of the worklist on a smartphone (Size S)
Basic layout of the worklist on a tablet (size M)
Basic layout of the worklist on a tablet (size M)
Basic layout of the worklist on a desktop device (Size L)
Basic layout of the worklist on a desktop device (Size L)

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object Page – Snapping Header

The snapping header is the uppermost element of the object page layout. It summarizes selected data and actions in a visually prioritized position to let the user quickly grasp the most relevant information.

This snapping header control is only available for the object page floorplan.

Information
The dynamic page also has a “snapping header” feature (called dynamic page header) and looks quite similar. However, this is part of the dynamic page control, and is technically not the same as the snapping header for the object page.

Usage

Use the snapping header if:

  • You are using the SAP Fiori element for the object page floorplan.
  • You are creating an object page manually based on the object page floorplan.

Do not use the snapping header if:

  • You are using any other floorplan.

Responsiveness

The snapping header is designed to provide maximum flexibility. It adapts automatically to small, medium, and large screen sizes.

The header title and subtitle never truncate. If necessary, the text wraps to the next line.

The toolbar follows the standard toolbar overflow guidelines by adding the available buttons to the overflow menu from right to left.

Object Header Content Priority

Each facet in the header content area has a priority assigned to it. Content prioritization aims to support responsive behavior. Priorities allow less important content to be omitted from rendering, depending on the screen space available. The user can always access omitted content on request.

Three priority types are available: high, medium, and low. According to the screen size, the facets are distributed as follows:

  • Size L/XL: The facets with high, medium, and low priority are displayed.
  • Size M: The facets with high and medium priority are displayed.
  • Size S: Only the facets with high priority are shown.
Snapping header – Responsiveness – Size L/XL
Snapping header – Responsiveness – Size L/XL
Snapping header – Responsiveness – Size M
Snapping header – Responsiveness – Size M
Snapping header – Responsiveness – Size S
Snapping header – Responsiveness – Size S
Snapping header content priority for sizes S, M, and L
Snapping header content priority for sizes S, M, and L

Components

The snapping header comprises two main control elements:

  • Mandatory: Title bar (sap.uxap.ObjectPageHeader)
  • Optional: Header content (sap.uxap.ObjectPageHeaderContent)

There are different states for the snapping header. You can find further information within Behavior and Interaction.

Title Bar

The title bar comprises the following elements:

  • Header title (mandatory): The title is always visible.
  • Header subtitle (optional)
  • Title bar image (optional): The image has a shape parameter (square or with a round mask) and a placeholder parameter. The placeholder is displayed if no specific image is available.
  • Toolbar: The toolbar contains the global actions for the floorplan. The actions should be represented only with buttons, text, or an icon. They can be transparent, regular, highlighted, or semantic. All buttons go from right to left into the overflow. Buttons should be arranged according to the current use case and always in a consistent visual order (see guidelines for examples). If there are no global actions, the toolbar is not shown. Note that the object page uses the sap.m.Toolbar control instead of sap.m.OverflowToolbar.
  • Child page visualization: Each object page can have drilldown navigation. The child object page can only be reached through the parent object page. A narrow vertical stripe at the left side of the snapping header helps to differentiate the child object page from the parent object page.

The title bar can also contain the following optional indicators:

  • Favorite (property: markFavorite)
  • Flagged (property: markFlagged)
  • Locked (propertly: markLocked)
  • Selector (property: showTitleSelector)
  • Unsaved Changes (property: markChanges)

The title bar control also supports breadcrumb navigation. For more information scroll to section Line Item Navigation.

Snapping header – Structure
Snapping header – Structure

Header Content

The header content is optional and located below the title bar.

You can use the header content (sap.uxap.ObjectPageHeaderContent) to display app-specific contextual information. You build the content using smaller content containers, called facets. Each facet contains a distinct information set, as described below. If there aren’t any facets, the header content is always hidden.

The facets are arranged in line with a left float. Each facet adapts its size to the content and makes optimal use of the space without truncating the texts. If the facets do not all fit on one line, those on the right wrap to the line below.

If the snapping header collapses, the header content is hidden. If the header content is empty, you can also hide it.

Header container – Floating content
Header container – Floating content

Header Facets

There are several types of header facets, depending on the data that they display. The facets need to be handmade for stand-alone object pages.

Form Facet (Dataset)

The form facet can be used to display datasets in the snapping header. It consists of a headline and up to five label-text pairs.

  • The headline is optional
  • Contains at least one but maximum five label-text pairs
  • The labels can be invisible, but need to have a text for accessibility reasons
  • The labels can be icons, but need to have a text for accessibility reasons
  • Each text of a label-text pair can have a press event

Examples for the usage of form facets are document information such as creator and creation time, an address or contact information, and general information.

Developer Hint
For non-SAP Fiori element object pages only:

For each label value pair in the form header facet, a sap.m.Label and a sap.m.Field should be used and nested within an sap.m.HBox.

Header Facet - Form facets
Header Facet - Form facets

Plain Text Facet

The plain text facet can be used to display a continuous text in the snapping header. It consists of a headline and a continuous text.

  • The width of the facet does not depend on its content, but can be set. The default width of the facet is 300px.
  • The headline is optional.
  • If the headline is broader than the facet width, the headline will wrap.
  • Press events are only available inline in the continuous text. These can be links that navigate to another page or open a quick view. There can be more than one link in the continuous text with different actions.
Developer Hint
For non-SAP Fiori element object pages only:

To set the width of the plain text facet, nest the text within an sap.m.HBox and set the property:width of the sap.m.HBox.

Header facet - Plain text facet with default width
Header facet - Plain text facet with default width
Header Facet - Plain text facet with custom width
Header Facet - Plain text facet with custom width

Image Facet

The image facet can hold exactly one image. The snapping header can only hold one or no image facet.

  • The image can be either square or circular.
  • The image can also hold an icon.
  • The image can also hold initials consisting of two letters.
  • The image can have a press event. The default press event is the enlargement of the image.

When the header collapses, the image facet will move to the right of the title and become smaller.

Recommended usage of the different properties:

  • Images of people, especially portraits, should be round. If there’s no image available for a person, initials (first letters from first and last name) should be used instead.
  • All other images should be square. If there is no image available for an object, an appropriate icon should be shown instead.

In all cases it should be clear how the images will be managed and uploaded. This can either be via the edit mode of the object page or, especially when there are a lot of images, via an external tool.

Header facet – Image facet specification
Header facet – Image facet specification

Key Value Facet

The key value facet holds a label in a smaller font size and a text or number in a bigger font size. It can be used to highlight important data or KPIs of the object.

If the key value facet is used with a text such as a status, it can also have an icon on the right side next to the text. This icon has to belong to the text and should only visually support but not expand it.

Developer Hint
For non-SAP Fiori element object pages only:

Larger value texts are currently only available in SAP Fiori elements. For non-SAP Fiori element apps, the value texts have the same size as the label, as custom CSS should not be used.

Header Facet – Key value facets with KPIs and a status
Header Facet – Key value facets with KPIs and a status

Micro Chart Facet

The micro chart facet consists of a headline, a subtitle, a micro chart and a footer.

The headline and the micro chart are mandatory while the subtitle and the footer are optional. To display the unit used in the micro chart, the footer should be used.

The following micro charts can be used in the micro chart facet:

  • Bullet Chart
  • Column Chart
  • Trend Chart
  • Comparison Chart
  • Delta Chart
  • Harvey Ball Chart
  • Radial Chart

The micro chart facet can have a click or tap event on the chart itself. This could for example lead to a page with a bigger chart or open a quickview.

For more information see micro charts.

Header facet – Micro Chart Facets
Header facet – Micro Chart Facets

Progress Indicator Facet

The progress indicator facet consists of a mandatory headline and a progress indicator (sap.m.progressIndicator). Further it can have two optional supplementary texts: a subtitle and a footer.

Header Facet - Progress indicator facet
Header Facet - Progress indicator facet

 Rating Indicator Facet

The rating indicator facet consists of a headline, a rating indicator, and one or two supplementary texts, which are dependent on the use case as described below.

The rating indicator can be modified as described in the rating indicator article.

We recommend the following properties for the rating indicator used in the header facets:

  • We recommend using 5 symbols as the default.
  • We recommend using the Favorite icon as symbols.
  • We recommend using the option to also display half-stars to represent decimal values.

 

The rating indicator facet can be used for two different use cases, which are described below.

  1. Aggregated rating:

    When displaying an aggregated rating, which could be for example the average of several user reviews for a product, the facet can have a mandatory header, an optional subtitle, the rating indicator itself, and a footer.

    The subtitle should display the amount of data that the aggregation is based on. For example, in the case of an average rating, the subtitle would display the number of ratings.

    The footer should display the exact value of the aggregation in the format “2.2 out of 5”, where “2.2” indicates the exact value of the aggregation and “5” indicates the maximum value of the rating.

  2. Single value rating:

When displaying the rating as a single value, the facet can have a mandatory header, an optional subtitle and the rating indicator itself. Here the subtitle can be used as supplementary text and a footer should not be used.

Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with aggregated rating
Header facet - Rating indicator facet with singe value rating
Header facet - Rating indicator facet with singe value rating

Behavior and Interaction

The snapping header has different types of behavior that can be combined:

  • Snapping
  • Title bar only
  • Header content always shown
  • Child page visualization
  • Line item navigation
  • Edit

By default, the snapping is enabled and title bar and header content are shown (expanded).

Snapping

The snapping header is always expanded for all display sizes when the user opens the object page.

When the user scrolls down the page, the header content snaps closed (collapses), leaving only the title bar. This allows the user to see more of the object page content.

You can specify which information is shown in the title bar in the expanded and collapsed states. In the example shown here, the snapping header has been configured to show only the image in the title bar when the header content area is collapsed.

Snapping header – Expanded
Snapping header – Expanded
Snapping header – Collapsed
Snapping header – Collapsed

Title Bar Only

If there is no need for the header content, the title bar-only mode can be used. This means that there is no header content shown at all, but only the title bar. This also means that there is no snapping behavior as the title bar is always shown.

Header Content Always Shown

The snapping header can stay expanded while the user scrolls down the page if the property alwaysShowContentHeader is set to true for the object page layout (sap.uxap.ObjectPageLayout). This behavior is available only for desktops.

Child Page Visualization

Each object page can have drilldown navigation. The child object page can only be reached through the parent object page. A narrow vertical stripe at the left side of the snapping header helps to differentiate the child object page from the parent object page. To navigate between the child object pages of one parent object page, arrows are displayed within the header bar of the page. To easily navigate back to the object page, breadcrumbs are used. To enable the child page visualization use property:isChildPage of sap.uxap.ObjectPageLayout.

Snapping header - Child page visualization
Snapping header - Child page visualization

Line Item Navigation

The snapping header for the object page can contain a breadcrumb that shows the navigation path for the current item. This feature was developed specifically for line item navigation within the object page.

The breadcrumb is located above the title in the title bar. The interaction is typical of a breadcrumb navigation pattern: all links in the breadcrumb chain point to a URL and are triggered by a press event.

If there is not enough space to show the full breadcrumb, it defaults to a dropdown control. In this case, the breadcrumb shows only the immediate parent of the current item. The   symbol indicates that further information is available in a dropdown list.

The dropdown list reveals all the links in the breadcrumb chain. The user reads the breadcrumb from bottom to top: the root object is at the bottom of the list, the immediate parent is at the top, and the current item is selected.

Snapping Header - Breadcrumbs
Snapping Header - Breadcrumbs

Edit

There are two different ways to edit the header information:

  • Global edit
  • Partial edit

Please note: the grand majority of object pages do not have editable header content. Therefore, the object header should not be editable by default.

Global Edit

A button in the header toolbar triggers the edit mode. For more information on global edit, see object page.

The visible facets can differ in create, edit, and display mode. If there aren’t any facets in one mode, the header content is not displayed. Choose which information supports the user best in his or her current task.

The mental model behind this possibility assumes that there are a number of header facets assigned to one given application. You can define which facets are shown in which mode.

Once the edit mode is activated, the header content is moved to a section in the content area of the object page. This section is assigned the anchor label Header. This is the first section in the document. All other sections are displayed in the order in which they had been displayed in display mode. If they’re editable, the object page title, subtitle, and image appear in the header content section. They also remain visible in the header title bar. If these are changed, they will update only as a preview.

If the image is changed in edit mode, the image in the header title bar should update only as a preview. The user will have to save the document to actually enable the changes.

Exemplary scenarios when switching from display to edit mode:

  • When all of the header elements are editable
    All of the header elements are displayed as editable forms in the Header section. The header content hides as no facets are displayed.
  • When independent header facets are present in edit mode

    All of the header elements are displayed as editable forms in the Header section. A new facet that is related to the data the user is editing is displayed in the object page header content area. This header facet is not present in display mode.
  • When only some of the header elements are editable
    All of the header elements are displayed in the Header section, but the content that is not editable is displayed as read-only to keep the layout consistent.

Partial Edit

Partial edit is used when the object page consists of large datasets and the user wants to be able to edit only the object header. Edit mode is triggered by a button that is located on the bottom right of the snapping header.

When there are only a few elements to be edited, the Edit Header button opens a dialog. When there are more editable elements, the button triggers a subpage. This subpage contains all editable data from the header without the toolbar, the navigation, and the breadcrumbs.

Style

The snapping header is available with both flavours of the Belize theme:

  • Belize (light flavor)
  • Belize Deep (dark flavor)
Snapping header – Belize
Snapping header – Belize
Snapping header – Belize Deep
Snapping header – Belize Deep

Guidelines

Breadcrumbs
Use breadcrumb navigation only on the object page, and only where there is a hierarchical drilldown within the object (line item navigation). For other types of navigation, see the SAP Fiori navigation patterns.

Header Toolbar
Do not use input fields, selects, checkboxes, search fields, or similar controls in the header toolbar. Use buttons only.

Header Content Area
Place only meaningful information in the header content containers. The content should help the user in the object context, or provide useful reference information.

Keep the header as clean and uncluttered as possible to allow users to take in the content at a glance. If there is too much information in the header, consider placing an overview section in the content area of the object page floorplan.

Themes

Until theme parameters are available for the snapping header, we recommend using the light flavor. This will avoid any contrast issues that might arise with the dark theme in the current implementation.

Images
When images are used in the object page header, you should consider the following needs:

  • How will the user manage the images?
  • How will the system block people without permission for image editing?
  • How will these images be reflected in other floorplans if they are part of the object?
  • If there are a large number of items, how would a company be able to manage images without having to navigate from page to page?
  • Will the company be able to manage the images?
Developer Hint
How to achieve a small header:

  • The header container is always optional. If there is no important data to be displayed, you can omit it. In this case, only the header title bar will be shown.
  • Omit the image if it is not necessary. It is generally the tallest element in a header container.
  • Use a light theme to reduce the emphasis in the header if there is not much information on it.
  • You can always place the information from the header into a general information section.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Split-Screen Layout

The split-screen layout is optimized for displaying and processing a list of items. On the left, users can quickly scan and navigate through the list. On the right, they see the details of the selected item, and can trigger related actions or edit the data.

Split-screen layout
Split-screen layout

Usage

Use the split-screen layout if:

  • Your users need to review and process different items quickly with minimal navigation.

Do not use the split-screen layout if:

  • You need to offer complex filters for the list of items.
  • Users need to see different attributes for each item in the list, and compare these values across items.
  • You want to display a single object. Do not use the master list to display different facets of the same object.

Structure

Split-screen layout – Structure
Split-screen layout – Structure

Like all layouts, the split-screen layout is embedded in the shell bar of the SAP Fiori launchpad. From the header, users have access to the launchpad services, including the home page, search, settings, and help. Apps are embedded in the shell and have little influence over its features.

The split-screen layout is divided into two separate areas:

  • Master list area: The master list displays the items available to the user. The master list title shows the item type in the plural form and the number of items, such as Products (115). The user can navigate between the items, perform a basic search, and organize the list using sort, filter, and grouping functions. Currently, only the master list is allowed in this area. For more details, see the master list pattern.
  • Details area: This content area displays the details for single or multiple items that are selected in the master list. The title of the details area normally shows the item type in the singular form, such as Product. Exceptions are selecting or editing multiple items in the master list. From here, the user can drill down to subpages (line items). The title of the subpage shows, for example, (2 of 5). The details area can contain one of the following floorplans:

Both areas have separate app headers and footer bars with navigation and actions.

Split-screen layout – Two independent scrolling areas
Split-screen layout – Two independent scrolling areas

The split-screen layout has two independent scrolling areas: the master list area and the details area. To implement the split-screen layout, you can use the sap.m.SplitApp control.

Navigation

Typical navigation within the details area
Typical navigation within the details area

The split-screen layout has two independent navigation containers. Drilldown capabilities and back navigation are supported in both the master list and the details area. For details on navigating in the master list, see the master list pattern.

In the details area, the user can drill down to the details of the main object within the app. Do not offer navigation to other apps from either of the split screen areas.

For example, the main item in the details area might be a shopping cart. A shopping cart contains multiple products. Within the details area, the user can navigate from the list of products in the shopping cart to the details for a single product. To navigate back to the shopping cart, the user clicks or taps the back arrow that appears at the top of the details area. In addition, apps should offer iterators (up/down arrows in the app header) to help users navigate more easily between products.

Drilldown and back navigation in the details area
Drilldown and back navigation in the details area

Responsiveness

Split-screen layout on a phone
Split-screen layout on a phone
Split-screen layout on a tablet
Split-screen layout on a tablet
Split-screen layout on a desktop device
Split-screen layout on a desktop device

On narrow screens for phones (or tablet devices in portrait mode), the master list and the details are split into two separate pages. The user navigates between the list and details, and can see all the available information for each.

The split-screen layout comes with built-in logic to respond to different device types, which reduces the development effort. This is an advantage over the full screen layout, which needs to be adapted manually by the app development team.

Split-screen layout with letterboxing on a desktop device
Split-screen layout with letterboxing on a desktop device

To further reduce the difference in width, you can make use of letterboxing to limit the maximum width of the app.

Examples

Reference App Manage Products

Reference app ''Manage Products'' – Product master list
Reference app ''Manage Products'' – Product master list
Reference app ''Manage Products'' – Product details
Reference app ''Manage Products'' – Product details
Reference app ''Manage Products'' on a tablet
Reference app ''Manage Products'' on a tablet
Reference app ''Manage Products'' on a desktop device
Reference app ''Manage Products'' on a desktop device

The reference app highlights how the user can navigate between the master list and the product details. The user selects a product in the master list and navigates to the product details. By selecting the back navigation, the user returns to the master list.

On a tablet, the master list and details can already be shown side by side. The user selects an item in the master list and it is displayed in the details.

However, when the tablet is turned into portrait mode, similar behavior occurs as on the smartphone. This time, the list can be called up from a menu in the top left-hand corner of the screen and it overlays the details area. The list disappears when the user makes a selection.

Split-screen layout on a tablet in portrait mode – The master list can be called by a menu button in the top left-hand corner
Split-screen layout on a tablet in portrait mode – The master list can be called by a menu button in the top left-hand corner

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Analytical List Page (SAP Fiori Element)

The analytical list page (ALP) is a new SAP Fiori element (formerly known as smart templates), and is also one of the main elements of SAP Fiori embedded analytics. You can use the analytical list page to create a landing page for performing detailed analytics in SAP Fiori apps quickly and easily. Applications may use this version of the ALP to create designs, to explore the capabilities of the ALP, to prepare queries, and configure and test KPIs.

Analytical list page – Size XL
Analytical list page – Size XL

Snap visual filter bar/compact filter to top

It is possible to snap the filter to the top to save space.

Elements and Controls

Implementation

Introduction to SAP Fiori Elements

SAP Fiori elements (formerly known as smart templates) provide a framework for generating UIs at runtime based on metadata annotations and predefined templates for the most used application patterns. The goals are to ensure design consistency, keep apps up to date with evolving design guidelines, and reduce the amount of frontend code for building SAP Fiori apps.

SAP Fiori elements use annotations that add semantics and structures to the data provided by the user.

SAP Fiori elements are part of the SAPUI5 delivery.

Currently Available

The following floorplans are currently available with SAP Fiori elements (in full screen):

Where applicable, smart templates also provide draft handling, non-draft, and global edit flow functionalities, as well as message handling.

Smart templates – The production line for UIs
Smart templates – The production line for UIs

Responsiveness

The responsiveness of the SAP Fiori element depends on the responsiveness of the controls used.

SAP Fiori elements generally use priority annotation on fields and actions to control responsiveness. This annotation supports the values high, medium, and low. Annotating actions with a priority level helps to control the overflow behavior of the toolbar. In the responsive table, the priorities also define the pop-in behavior of columns.

Behavior and Interaction

The behavior and interaction generally follows the guidelines for the respective floorplan or concept. If the guideline offers choices, SAP Fiori elements implement the most generic option or, where possible, provide different options to choose from. Deviations from the guidelines are sometimes necessary due to current technical limitations, which are listed on the respective pages. These limitations are usually short term and will be solved in future releases.

SAP Fiori elements contain a certain amount of default text, which can be overridden by the app development team if necessary. One such example is standard message texts.

The templates offer breakout scenarios at page level, where it’s possible to add, remove, or replace whole pages, and at section level on the object page. See the object page article for more details.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • No links.

Overview Page (SAP Fiori Element)

Overview Page
Overview Page

View, filter, and take immediate action

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, and view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page. The overview page is based on SAP Fiori elements technology, and uses annotated views of app data, meaning that the app content can be tailored to the domain or role. Different types of card allow you to visualize information in an attractive and efficient way.

  • Entry-level view of content on cards

  • One specific context and task area for one role

  • Content from different sources shows side by side – no need to switch screens

  • Information can be visualized on cards in different ways (texts, charts, lists, tables)

  • Easy filtering

  • Micro actions let users react on the spot

Usage

Use the overview page if:

  • The user has a specific role and needs to filter and react to information stemming from a range of applications.
  • The user needs to gather information from different sources that support a specific task focus or information need.
  • You want to give users a place to focus on their role-specific tasks.
  • You want to offer different information formats (such as charts, lists, and tables) on a single page for the tasks of a specific domain or role.
  • You want to organize and display a set of (filterable) data to provide an entry-level view of content related to a specific domain or role.

Do not use the overview page if:

  • A high-level or birds-eye view of application content is sufficient.
  • You just want the user to launch an application. In this case, use the SAP Fiori launchpad home page instead.
  • You want to show information about one object only. In this case, use the object page instead.

The Difference Between the SAP Fiori Launchpad Home Page, Overview Page, and Object Page

Different entry points in SAP Fiori
Different entry points in SAP Fiori

As you can see in the picture above, the overall content scope (shown in gray) becomes more focused with each interaction step. The launchpad home page contains all of a user’s favorite apps and offers access to them via tiles. This covers all the roles that a user might have, such as employee, manager, production worker, or quality manager.

An overview page focuses on the key tasks for a specific role, and contains only the most frequently-used apps for that role. The overview page uses cards, which display more (preview) information than tiles because of their size, properties, and interaction areas. One card type also allows users to perform simple actions. Cards represent an entry-level view of application content.

Launchpad Home Page vs. Overview Page

Launchpad Home Page Overview Pagge
Framework (given) SAP Fiori application (optional)
“Birds-eye” view “Street-level” view
Single point of entry Specific business context for a role
No actions Micro actions
One SAP Fiori launchpad per user Multiple overview pages per user possible

The overview page is always role-based. The user sees a heterogeneous set of information related to a specific business context and the tasks associated with a specific role. This is not the case with the object page, which contains homogenous, object-based information.

Overview Page vs. Object Page

Overview Page Object Page
Role-based Object-based
“Street-level” view “Details” view
Heterogeneous information Homogeneous information

Role-Specific Overview Pages

Only provide an overview app for a role if it makes sense to do so. An overview page brings together information from different sources that support a specific task focus or information need. If a role or user has several such main tasks that each require a specific set of information, the role or user might also have multiple overview apps. For example, one overview app could be used to reflect the user’s role as manager, and allow him or her to manage the performance reviews of the team. Another overview app could be used to track quality issues and other relevant information pertaining to the machines that he or she is responsible for in the role of quality manager.

Dedicated Floorplan

While other floorplans like the list report and object page can be combined in a single app, there is a 1:1 relationship between the overview page floorplan and the corresponding overview app. The overview page floorplan is never combined with other floorplans. Because of this, the terms “overview page floorplan” and “overview (page) app” are often used synonymously.

Interaction Flow

As for any other SAP Fiori app, users open overview page apps by selecting a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link in a browser. From the overview page the user decides which issues need attention, and navigates via cards to the relevant SAP Fiori apps.

The overview page supports navigation to both SAP Fiori and non-SAP Fiori apps. For SAP Fiori apps, it uses intent-based navigation. Non-SAP Fiori apps open in a new the browser window. In the screen flow, always position the overview app between the SAP Fiori launchpad home page and the SAP Fiori app. Never start overview apps from another SAP Fiori app.

The picture below illustrates the complete interaction flow:
SAP Fiori launchpad home page ➝ SAP Fiori overview app ➝ SAP Fiori app or non-SAP Fiori app

Overview page – Interaction flow
Overview page – Interaction flow

Responsiveness

The overview page floorplan is fully responsive. The card layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes.

Overview page – Size L/XL
Overview page – Size L/XL
Overview page – Size M
Overview page – Size M
Overview page – Size S
Overview page – Size S

Structure

The basic structure and appearance of the overview page is governed by the dynamic page layout. This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards. The card layout determines the size and position of the cards.

Overview page – Basic structure
Overview page – Basic structure

Dynamic Page

Dynamic Page in the Overview Page

The overview page can consume four different versions of the dynamic page layout. All the variants have two things in common:

  • The floating footer toolbar is not included.
  • There are no global actions in the header title.

The smart filter bar in the header content uses the live update mode: the results are updated immediately whenever the user changes a filter field. As a result, there is no Go button for the filter bar.

Dynamic Page Variants for the Overview Page

Variant 1 Variant 2 Variant 3 Variant 4
Dynamic page header Yes – – Yes
Header title Variant Management Text – Text
Header content Smart Filter Bar – – Smart Filter Bar
Page content Cards Cards Cards Cards
Floating footer toolbar – – – –

Variant 1 – Variant Management and Smart Filter Bar (default)

In this variant, the header title contains variant management, and the header content includes the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size XL/L/M
Dynamic page variant 1 – Snapped mode for size XL/L/M
Dynamic page variant 1 – Snapped mode for size XL/L/M
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Expanded mode for size S
Dynamic page variant 1 – Snapped mode for size S
Dynamic page variant 1 – Snapped mode for size S

Variant 2 – Text in the Header Title

In the second variant, the header title contains a text, which serves the same purpose as the former page subtitle. The header content is empty (auto hidden), and therefore doesn’t snap. The content area displays the overview page cards.

Dynamic page variant 2 – Expanded/snapped mode for size XL/L/M
Dynamic page variant 2 – Expanded/snapped mode for size XL/L/M
Dynamic page variant 2 – Expanded/snapped mode for size S
Dynamic page variant 2 – Expanded/snapped mode for size S

Variant 3 – No Header

This variant doesn’t snap because both the header title and header content are empty (auto hidden). In this case, the overview page cards (page content) display directly below the shell bar.

Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size XL/L/M
Dynamic page variant 3 – Size S
Dynamic page variant 3 – Size S

Variant 4 – Text in the Header Title and Smart Filter Bar 

In this variant, the header title contains a text, and the header content area contains the smart filter bar. When the user scrolls or clicks, the header content snaps as defined.

Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size XL/L/M
Dynamic page variant 4 – Snapped mode for size XL/L/M
Dynamic page variant 4 – Snapped mode for size XL/L/M
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Expanded mode for size S
Dynamic page variant 4 – Snapped mode for size S
Dynamic page variant 4 – Snapped mode for size S

Overview Page Layout

The overview page layout describes the position and size of cards in the content area below the dynamic page header (header title and header content).

Only place cards on the overview page. Never add tiles.

Card Layout

The card layout contains responsive (collapsible) columns of cards. The card width is fixed, and the height is determined by the card type and the embedded control.

There is no limit on the number of cards included. To view all the cards, the user just scrolls down.

Fixed card layout
Fixed card layout

The card layout uses padding on both sides. The cards are displayed inside collapsible columns, making the page fully responsive. When the user resizes the browser or uses a smaller screen, the columns containing the cards collapse. In this way, the layout can accommodate typical laptop screens, larger desktop monitors, and mobile devices:

  • Phone: 1 column
  • Tablet (portrait): 2 columns
  • Laptop / tablet (landscape): 3 columns
  • Large desktop: 4 columns
  • Extended monitor: 5 columns (maximum)

The width of the cards is tied to the column width. Breakpoints for the different screen resolutions determine whether the column width is 20 or 25 rem. The cards inside the columns adapt their width automatically. By contrast, the height of the cards is flexible, and depends on the content and type of card.

Rearranging Cards

Users can reposition cards on the overview page by dragging them to a different location. As the user drags a card, it swaps place with any cards in its path. Releasing the mouse or lifting the finger from the touch surface completes the move. To avoid gaps, cards always snap to the next free space in the row, or to the start of the next row.

The cards are arranged as a “Z” flow: cards are ordered from left to right, starting with the first card on the top left of the page. For example, if a 5-column layout is reduced to 4-column layout, the fifth card drops to the next row, assuming the leftmost position underneath the first card.

Personalized Selection of Cards

Users can also hide cards. The corresponding setting is in the Me Area under Manage Cards. A popover appears on the overview page, and lists the different card names. Users can opt to show or hide the cards using a switch control. Restore reinstates the default setup. The personalized setup stays until the user next changes it.

Overview page – Manage cards
Overview page – Manage cards
Overview page – Manage cards dialog
Overview page – Manage cards dialog

Cards

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. Technically, a card is a smart component that uses UI annotations to render its content. Cards differ in the content they display: They can show a chart, a list, a table, informative text, or a combination of two elements. However, cards never have editable fields.

Cards can vary in size, depending on the selected layout. They can focus on a single object or topic, or on a group of objects.

Card Components

Every card comprises three components: a header area, a content area, and a footer area. The header and content areas are mandatory. The footer area is optional (for example, it is not needed on stack cards or analytical cards).

Make sure that you define and format the texts on all the cards consistently. Check the UI text guidelines for the overview page for details.

Overview page – card components
Overview page – card components

Card Header

The card header area is mandatory, and serves two purposes:

  • It indicates what the card is about.
  • It functions as a navigation area for opening the parent app, whereby the whole header area is clickable. We recommend offering this navigation on all cards (exception: link list card). 

The height of the header area is variable; it expands vertically to accommodate the text. The header area can contain two text fields: a mandatory title, and an optional subtitle. The primary purpose of the header area is to identify the content source, summarize the focus of the card (title), show any relevant parameters (subtitle), and offer navigation to the content source (parent app).

Title

The title is mandatory and represents the card’s “point of view”. In one or two words, it explains why this card exists and why a user might want to use it. It is a natural language reflection of the annotated view. Titles that exceed two lines are truncated with the ellipsis (…).

Subtitle

The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The use of the subtitle can differ, depending on the card type. Subtitles that exceed one line are truncated with the ellipsis (…).

Overview page – header area
Overview page – header area

Card Content

The content area is mandatory and is reserved for application content. Content is currently displayed on cards by embedding SAPUI5 controls that specify the properties and data format. For example, an embedded standard list control provides formatting, such as row height, font sizes, and the number of text blocks.

Card Footer

The footer is optional and is not needed for some types of card (such as stack cards or analytical cards). The footer area serves two purposes;

  • On quick view cards that display information on a single object or data point, you can use the footer area to offer related actions. In this case, the overflow toolbar control is used.
  • On cards that display a group of links (such as list or table cards), the footer area is used for information only. Use a text label to show how many of the relevant items are showing on the card (for example, Showing 3 of 10). If no items are returned, display the standard text No items found.

The height of the footer bar is fixed.

Card footer area with actions
Card footer area with actions
Card footer area with a positive summary text label
Card footer area with a positive summary text label
Card footer area with with a negative summary text label
Card footer area with with a negative summary text label

Formatting Dates, Times, Amounts, and Currencies

Apply the following formats:

  • Dates: The default is the relative date format (for example, Today). However, you can also use the medium date format (such as Aug 7, 2015).
  • Times: Times are not visible per default, but if you need to show a time, use the short format (for example, 11:28 AM).
  • Integers/Float/Currencies: Use the short format (for example, 1K for 1000).

Navigation and Interaction

The navigation and interaction depends on the technical card type:

  • Single-object cards
  • Object group cards
  • Special cards

This section looks at the different technical card types, how card views can be combined, and how to incorporate actions.

Single-Object Cards

Cards that feature content with a single focal point, detail, or entity are called single-object cards. An example is a quick view card with information about a particular product. Analytical cards are also single-object cards. The header area of this card type always navigates to this specific focal point, detail, or entity. The content area can also have interaction areas (for example, a section in a chart, or a telephone number for a contact). However, only quick view cards can have actions in the footer area.

Interaction for a single-object card
Interaction for a single-object card

Object Group Cards

Cards that feature a subset of items grouped by a common criterion are called object group cards. A typical example would be a list of purchase orders grouped by delivery date, amount, or supplier. The cards do not have actions, but each row or list item is selectable, thus providing direct navigation to the object details within the parent application. The header area of this card type always navigates to all items in the list or table. Object group cards include all types of list cards, bar chart list cards, and table cards.

Interaction for an object group card
Interaction for an object group card

Link List Cards

Link list cards allow you to display a collection of links or images that can reference both internal and external targets.

  • Links can navigate to a target or open a popover with additional information.
  • Clicking an image opens an image carousel.
Interaction for a link list card
Interaction for a link list card

Stack Cards

A stack card is a special card type for showing a collection of single-object cards. Stack cards have 3 components with different navigation areas:

  • The top-level stack card opens the collection and contains two clickable areas: the left area navigates to the parent app, and the right area opens the object stream.
  • The object stream shows individual cards that represent objects from the parent application. The object stream heading links to the parent application, while individual cards can contain links and actions relating to the respective object. A Close button returns the user to the stack card.
  • The last card in the object stream is the placeholder card. The entire card is navigable and leads the user directly to the parent application.
Interaction for a stack card
Interaction for a stack card
Interaction for a placeholder card
Interaction for a placeholder card

View Switch

You can use a view switch to offer two different content areas on one card, which can help to reduce the number of cards on the overview page. The user chooses the view using a select control. You can only combine views that have a common denominator. The options offered by the select control merely offer different perspectives. For example, a card “Purchasing Spend” (title in the header area) could offer two views “By Material Group” and “By Supplier” (options in the select control). The view switch is located between the header and content areas.

You can use the view switch for the following cards:

View switch
View switch

Actions on Cards

Only quick view cards within an object stream can have actions in the footer area. The overflow toolbar manages how the actions are displayed. All actions are right-aligned. Any actions that don’t fit into the available space move into the overflow action sheet, represented by the ellipsis ( ). A maximum of six actions are allowed in the footer area. Only offer actions the user really needs in the specific context.

Footer area with additional actions in the overflow
Footer area with additional actions in the overflow

There are two possible types of action: navigation and function import. Any combination of navigation and function import actions is allowed. Error or confirmation messages are displayed directly on the overview page.

Type: Navigation

Navigation is “intent-based” and takes the user to a different SAP Fiori app that specializes in executing an action. Navigation actions are always multi-click (meaning they can be repeated over and over). The destination screen opens in the same browser window, and any error or task confirmation messages are handled by the supporting application, not the overview page.

Type: Function Import

Function imports are custom OData service operations for actions. These actions are handled by the overview page, rather than by another SAP Fiori app. The interaction depends on whether or not the action requires user input:

  • If the action requires additional user input, the input parameters are handled directly on the overview screen without further navigation. A dialog appears on top of the card, allowing the user to enter data or make a selection. An example of additional input might be the rejection reason for a “Reject” action.
  • If the action has no input parameters, the action request is sent immediately. Once the action has been completed, the card disappears from the object stream.

Action on Phone

If an action on a card requires an input dialog box, use a full screen dialog on smartphones.

Card Types

Quick View Card

Quick view cards are single-object cards. They display the basic details for one object, such as the name, address, and phone numbers for a contact. This card type is only available within the object stream; you can’t place quick view cards on the overview page itself. The quick view card inherits the SAPUI5 element sap.m.QuickView.

The header area contains a static text, such as Purchase Order, and an optional dynamic text, such as 1005-3345. In this way, each card header can show different content. Clicking on the header area of the card opens the detailed view of the object in the corresponding parent app. If the content area of a card cannot display all the information, a scrollbar appears on the right. Only the footer area of the quick view card can currently provide actions.

Quick view card for a contact
Quick view card for a contact
Quick view card for a product
Quick view card for a product
Quick view card for a purchase order
Quick view card for a purchase order

Analytical Card

Analytical cards are used for data visualization. They are single-object cards that consist of two areas: a header area that displays the aggregated value of a key measure (KPI), and a chart area that displays a representation of data in graphical format. Analytical cards do not contain a footer area.

The KPI header is mandatory for analytical cards used on the overview page. The KPI header includes the title (mandatory), the KPI with the respective unit (mandatory), and a subtitle (optional). The subtitle can show the filter criteria used for the chart, and can contain up to two lines of text. The KPI itself uses the semantic colors red (negative), green (positive), or gray (neutral). You can also display a percentage indicator (optional) or triangle indicator showing an upward or downward trend (optional).

For more information, see analytical card.

The following (VizFrame) charts are available:

  • Line chart
  • Bubble chart
  • Column chart
  • Stacked column chart
  • Vertical bullet chart
  • Donut chart
  • Scatter plot
  • Combined chart
  • Scatter plot

List Card

List cards are a type of object group card, and display a set of items in a vertical list. List cards use the sap.m.List container in the content area.

 

List Card Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

List Item Types

Two different list item types are available:

  • The standard list item always shows 3 pieces of information and inherits the properties of the SAPUI5 control sap.m.StandardListItem.
  • The extended list item can show up to 6 pieces of information and inherits the properties of the SAPUI5 control sap.m.ObjectListItem.

You can only use one type of list item on any given card.

 

Size of a List Card

List cards resize according to the content available. The height can vary, depending on the number of text fields. Show no more than five standard list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

In addition, you can display the data on the right-hand side in semantic colors.

 

List Card Footer

In the footer area, indicate how many items are showing on the card in relation to the total number of relevant items. Use the summary text: Showing [Items on Card] of [Total Items], as in Showing 5 of 13.

List card with standard list item
List card with standard list item
List card with extended list item
List card with extended list item

Bar Chart List Card

Bar chart list cards are a type of object group card, and display a set of items in a vertical list. Unlike list cards, bar chart list cards are embedded in another component: the comparison micro chart. This allows you to display negative values and use semantic colors.

 

Bar Chart List Card Navigation

Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set.

Clicking a list item (row) on the card opens the detail view for that specific item in the same parent application.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

Bar Chart List Item Types

Three different list item types are available:

  • The standard list item always shows 3 pieces of information.
  • The condensed list item can show up to 4 pieces of information.
  • The extended list item can show up to 6 pieces of information.

You can only use one type of list item on any given card.

 

Size of a Bar Chart List Card

Bar chart list cards resize according to the content available. The height can vary, depending on the number of text fields. Show no more than five standard/condensed list items and no more than three extended list items on one card. To see the full result set, the user needs to navigate to the parent app.

 

Bar Chart List Card Footer

In the footer area, indicate how many items are showing on the card in relation to the total number of relevant items. Use the summary text: Showing [Items on Card] of [Total Items], as in Showing 5 of 13.

Bar chart list card with standard list item
Bar chart list card with standard list item
Bar chart list card with condensed list item
Bar chart list card with condensed list item
Bar chart list card with extended list item
Bar chart list card with extended list item

Table Card

Table cards are a type of object group card, and display a set of items in a table format. Table cards use the responsive SAPUI5 control sap.m.Table.

 

Table Card Navigation

Clicking the header area of a table card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the objects returned for the result set.

Clicking a list item (row) on the card opens the detail view for that specific object in the same parent application.

Because the header area and line items are based on the same result set, they must always link to the same target application.

 

Size of a Table Card

Table cards resize according to the content available. The height can vary depending on the number of table cells. Tables are limited to a maximum of 3 columns and 3 rows, with a maximum of 3 lines of text per row. To see the full result set, the user needs to navigate to the parent app. All three columns can show either a data field or a data point. Data points can use semantic colors.

 

Table Card Footer

In the footer area, indicate how many items are showing on the card in relation to the total number of relevant items. Use the summary text: Showing [Items on Card] of [Total Items], as in Showing 5 of 13.

Table card
Table card

Link List Card

Link list cards allow you to display a collection of links or images that can reference both internal and external targets. Links and images are handled as two separate variants:

 

Variant Type: List

The list variant shows a collection of links that can navigate to a target or open a popover with additional information. You can also show an optional subtitle below the link with a description or additional information. The link text and subtitle are each limited to one line.

You can display an icon or image before each link. For example, you might want to include app icons for set of links to recently-used apps, or images for a list of recent contacts. Use icons and images consistently:

  • If you opt to use icons, show an icon before every link.
  • If you include images, use a placeholder for images that are not available.
Link list card – Variant type
Link list card – Variant type "list"
Link list card – Variant type
Link list card – Variant type "list" with icons
Link list card – Variant type
Link list card – Variant type "list" with images

Variant Type: Image

The image variant uses the sap.m.Carousel control to display one or more images. If the carousel contains only one image, the Previous and Next icons and the paging indicator are not visible. The link and an optional subtitle are displayed above the carousel. The link text and subtitle are each limited to one line.

Link list card – Variant type
Link list card – Variant type "image"

Stack Card

A stack card is a special collection of single-object quick view cards, based on a topic or action. Unlike the other card types, the top-level stack cards don’t show any application content. Instead, they act as an entry point to an object stream containing multiple cards.

Stack cards have the following components:

  • The title is the top element and is always required. It is used as the heading for the detail view, and comprises 1-2 lines of text.
  • The subtitle is optional. You can use it to qualify the title, offer an explanation, or show a status. The purpose of the subtitle is explain the content of the stack in one line, so its usage depends on the context.
  • The stack content count indicates the number of cards in the stack (object stream). The object stream can contain up to 20 cards. Below the number of cards in the stack, you see the total number of items returned for the annotated view (for example, “20 of 42”).

Overview Page - Stack Card

The top-level stack card contains two clickable navigation areas:

  • The left area and View All link navigate to the parent application, where the user can see all the objects returned for the annotated view (42 in the example above). The placeholder card and heading inside the object stream have the same navigation target.
  • The right area opens the object stream, which contains a scrollable collection of cards presented in an overlay format. The user can browse individual cards, with the option to view, inspect, or take action.

Object Stream

Overview page – Object stream
Overview page – Object stream

Clicking the right-hand area of the stack card opens the object stream. The object stream appears on top of the overview page as a modeless overlay, and serves as a layer for showing quick view cards with actions. The overlay has heading on the top left, and a Close button on the right. The heading is the same as the stack card title, and links to the full result set in the parent application (same target as the left-side navigation on the stack card and the navigation from the placeholder card). Clicking outside the overlay area also closes the object stream.

The object stream can have up to 20 cards, which all get their content from the same parent application. By default, the cards are ordered chronologically, with the most recent items first. However, app developers can define the best object stream sorting option for their own needs and custom content. If the number of cards exceeds the available space in the overlay window, an arrow icon appears on the right for scrolling. Mobile device users can swipe to see more cards. If the object stream is empty, the stack link is not active and the overlay cannot be opened. The stack count number displays 0. If only one item is returned, the object stream contains just a single card.

The header area of the quick view cards in the object stream navigates to the detail view for that specific object in the parent application. The footer area of the quick view cards can also offer actions.

 

Object Stream – Scroll Arrows

Scroll arrows only appear on desktop devices. If all the cards in the object stream fit on the screen, the arrows are not visible. If the number of cards exceeds the available space, an arrow icon appears on the right when the user mouses over the object stream overlay. Mousing over the arrow button area scrolls the cards across the screen from right to left. As soon as the first card on the left moves out of the visible overlay area, a second arrow appears on the left for moving in the other direction. Once the last card is in full view, the arrow on the right disappears.

Object Stream – Placeholder Card

If the number of items returned for the annotated view exceeds the maximum 20 cards allowed in the object stream, a placeholder card is added automatically at the end of the stream (as card 21). The entire placeholder card is navigable, and takes the user to the full result set in the parent application.

Overview page – Placeholder card
Overview page – Placeholder card

Object Stream – Tablet Version

On tablet devices, the modeless overlay expands horizontally. It also expands vertically to accommodate the card height and allow space for the title and Close button. The user can swipe through cards and perform micro actions. Swiping a card in view moves the entire object stream. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

 

Object Stream – Phone Version

On smartphones, the overview page layout collapses to a single column in both portrait and landscape modes. Tapping on the right-hand navigation area of a stack card opens the object stream on top of the overview page in a new full screen window.

The object stream expands horizontally and vertically to accommodate the card height, and to allow space for the title and Close button. The user can swipe through the cards and perform micro actions. Swiping a card moves the entire object stream. Since the cards are too large to fit on the screen in landscape mode, users can also scroll vertically to see the full card content. Tapping the Close button closes the stack card and returns the user to the main overview page. There are no scroll arrows on touch devices.

  • Overview page – Object stream interaction size M (landscape)
  • Overview page – Object stream interaction size M (portrait)
  • Overview page – Object stream interaction size S (lportrait)
  • Overview page – Object stream interaction size S (landscape)

Resources

Want to dive deeper? Follow the links below to find out more about the SAP Fiori Overview Page.

Elements and Controls

Implementation

Wizard Floorplan

The wizard floorplan allows users to complete a long or unfamiliar task by dividing it into sections and guiding the user through it. The wizard consists of the walkthrough screen, where the form sections are revealed in sequence after each one is completed, and the summary page, where the form is displayed in read-only mode for assessment and final submission. You can use the wizard both in full-screen and split-screen layouts.

Wizard - Steps
Wizard - Steps

Usage

When to Use the Wizard Floorplan

The wizard aims to help users by dividing large or complex tasks into segments. Use the wizard if the user has to accomplish a long task (such as filling out a long questionnaire) or a task that is unfamiliar to the user. The flow should consist of a minimum of 3 and a maximum of 8 steps.

The wizard can be used for both create and edit scenarios. If your application contains both, consider using the same means for both scenarios – either the wizard, or another create/edit screen (edit flow or object page).

When Not to Use the Wizard Floorplan

If you have a task with only 2 steps or a format that the user is familiar with (for example, it is part of their daily routine), do not use the wizard as it only adds unnecessary clicks to the process. If your process needs more than 8 steps, the wizard will not support those steps as the process is too long and can be confusing for the user. In this case, you should consider restructuring the task.

Consider if the classic edit screens (edit flow or object page) are more suitable for your use case.

Structure

The wizard has two main screens: the walkthrough screen, where users complete a segmented task, and the summary screen, where they can check the data they are about to submit. Wizard content is not restricted to forms; other content such as a value help dialog can also be used.

Walkthrough Screen

The walkthrough screen is the wizard’s main screen. After triggering the wizard, the user is taken to the walkthrough screen, which shows only the first section of the form. Once the user has filled out all the necessary fields, a Step XY button appears, which allows the user to move to the next step. When the user has completed the last section of the wizard, the button label changes to Review and the user is taken to the summary screen.

The wizard footer is used to display the Cancel button, which exits the wizard. If the user has modified any fields, a data loss message also prompts the user. You can also use a Save as Draft function in the footer if the form is long and the user may have to save it before finishing it.

Walkthrough screen in full screen layout
Walkthrough screen in full screen layout

The progress bar/anchor navigation highlights the completed steps and the current step. It also allows the user to navigate between steps by clicking on any of the circles.

The progress bar exhibits a grouping behavior if there are multiple steps and the screen width is reduced. This behavior is the same on smartphone, tablet, and desktop screens.

Wizard header and anchor navigation
Wizard header and anchor navigation
Wizard tooltip – Grouped steps
Wizard tooltip – Grouped steps

Depending on user preference, you can also have an unknown number of steps after a particular step (“branching”). In this case, a dotted line shows that more steps will follow.

Wizard branching
Wizard branching

Since the wizard is a lightweight way to create or edit objects, applications can use a quick confirmation popup instead of the heavier data loss message, when the user selects Cancel.

If the wizard is used to create an object, the text on the popup should read ‘Discard this ?’ (see image below).If the wizard is used to edit an object, please use the text ‘”Discard changes?” In both cases, the action on the popup should be Discard.

Structure – Quick confirmation
Structure – Quick confirmation

Summary Screen

The summary screen has no progress bar/anchor navigation. It shows the completed steps in read-only mode, which can then be proofread before being submitted.The summary screen consists of the form sections displayed in read-only mode. To allow the user to go back and edit entries, an Edit button needs to be provided either in the footer or on each form section.If the Edit button is placed in the footer, the user is taken back to the first section of the wizard, while the buttons on each section allow the user to jump to that particular step. Alternatively, users can click the back button to go to the last step. From here, they can scroll or tap through the sections.The main action on the summary page should reflect the action taken by the user when completing the wizard, such as Submit or Save.

Wizard summary page example
Wizard summary page example

Layout

Wizard structure in full screen layout
Wizard structure in full screen layout
Wizard structure in split-screen layout
Wizard structure in split-screen layout

Types

There are two types of wizard – “standard” and “branching” – which differ in terms of the functions they offer.

Use the standard type if:

  • The total number of steps is known in advance.
  • The number of steps does not change during usage.
  • There is linear progression from one step to the next.

Use the branching type if:

  • The total number of steps is not known.
  • The number of steps may change during usage.
  • There is non-linear progression. In other words, the user’s choice during one step determines which step comes next.

Styles

In addition to the functional types, there are also different visual styles.

Numbers and Icons

By default, both versions use a number inside a circle to represent each step. You can also use icons instead of numbers to help users identify the steps. If you plan to use icons, be sure to assign icons to all the steps (not just to some). The icons you choose should be unique and not look too similar. This will ensure that users do not get individual steps confused with one another.

Steps represented by numbers
Steps represented by numbers
Steps represented by icons
Steps represented by icons

Labels

To help users identify the individual steps even more easily, app developers can assign labels. As with icons, labels must be applied to all or none of the steps.

If there is enough horizontal space, all labels are shown.

All labels are visible
All labels are visible

As the width is reduced, the steps outside the currently selected one do not show labels.

Labels - reduced width
Labels - reduced width

Finally, the unselected and outermost steps are stacked on top of each other to further accommodate the reduced space.

Stacked labels
Stacked labels

Users can still easily access steps inside a stack. A single click opens a list of steps inside this stack.

Labels - stacked popover
Labels - stacked popover

Explanatory Texts

Ideally, the headlines and field labels for each step should provide enough information for users to complete their tasks. However, if additional explanations are needed, applications can put a simple text underneath a step’s headline – either via the sap.m.Text or the sap.m.FormattedText control.

Responsiveness

The wizard supports all common screen sizes and is available in cozy and compact modes, as well as high-contrast black (HCB).

Wizard – Size S
Wizard – Size S
Wizard – Size M
Wizard – Size M
Wizard – Size L
Wizard – Size L

Behavior and Interaction

Navigation and Error Handling

Navigation

Users can trigger the wizard app from another application, the launchpad, or a notification. The wizard always starts at the initial walkthrough page and ends after the user has clicked the main action (such as Submit) on the summary screen. The Step XY button is only used on the walkthrough page, and its purpose is to load the next section of the form.On the summary page, the user can use either the Edit button in the footer or the “back” arrow to return to the wizard and edit any of the fields.Modifying dependent steps: If there are steps that depend on each other (for example, a selection in step 2 triggers an optional step) and the user modifies the parent step, the dependent step is changed or deleted. This first triggers a warning message (when the input control loses focus) that data will be lost.

Error Handling

Error handling is done via message popovers. When the user clicks the Step XY button, the form sections and fields should be validated. When the user clicks the Submit button on the summary page, the entire form is validated. If there are any errors, the user stays on the walkthrough page, the message popover is displayed, and clicking any of the error items scrolls the page to the relevant field, which is also highlighted in red.

Section validation differs from validation of the entire form. In the first case, correct data entry in the form fields is validated. In the second case, the entire form is checked for backend system errors (such as duplicated data entry).

Dynamic Page

Header

Even though the wizard floorplan consumes the dynamic page, the wizard’s header does not allow snapping. Due to the nature of the wizard floorplan, the wizard brings its own step-based header that is already very space-saving.

Footer Toolbar

Contrary to the header, the footer toolbar of the wizard floorplan conforms to the standard layout and uses the sap.m.bar control.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

  • Wizard (SAPUI5 API reference)
  • Wizard (SAPUI5 samples)
  • Form (SAPUI5 API reference)
  • Form (SAPUI5 samples)

Worklist Floorplan

A worklist displays a collection of items that are to be processed by the user. Working through the item list usually involves reviewing details of the list items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan lies on processing the items. This differs from the list report floorplan, which focuses on filtering content to create a list.

Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Your app uses the full screen layout. The full screen worklist is preferable if the work items are complex objects. For simple scenarios, use the split-screen layout instead.

Do not use the worklist floorplan if:

  • You want to create only a lightweight worklist. Instead, use the split-screen layout for simple scenarios.
  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (graphics or tables). In this case, use the list report floorplan instead.

Layout

The launchpad shell bar is always available at the top of SAP Fiori apps. The app title (app header) reflects the title of the launch tile, such as Manage Products.

The worklist contains a list of work items. You can also use the icon tab bar to split the list into different categories. In addition, the worklist can use filters and variants, as described for the list report floorplan. Bear in mind, however, that if users can filter the list, they may also overlook important work items.

To ensure that the application runs on all devices, we recommend using the responsive table. The responsive table also offers a wide range of options for optimizing the layout, scalability, and how the user takes action.

Basic structure
Basic structure

Responsiveness and Adaptiveness

Worklist floorplan on a smartphone
Worklist floorplan on a smartphone
Worklist floorplan on tablet
Worklist floorplan on tablet
Worklist floorplan on a desktop device
Worklist floorplan on a desktop device

Types

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a list.

Simple worklist without tabs
Simple worklist without tabs

Category Worklist

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs can also contain tables with different configurations (for example, with different columns or actions).

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red on the Error tab below).

Worklist with tab categories
Worklist with tab categories

KPI Worklist

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI in the subheader.

Worklist with tabs for specific categories
Worklist with tabs for specific categories

Actions

Worklist with a global toolbar for actions
Worklist with a global toolbar for actions

The header title contains the global actions. These actions can apply to individual or multiple items selected by the user. Placing actions in the toolbar allows users to process several items at a time. However, more clicks are required to process individual work items.

Work list with actions at line item level
Work list with actions at line item level

You can also offer actions at line item level. This reduces the interaction required to a single click per item. Consider offering actions at line item level for most frequently used actions, and if the list provides enough information to make the a decision.

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen.

Worklist with navigation to item details
Worklist with navigation to item details
Work item details
Work item details

Once the user has completed the task, the app should:

  • Return the user to the worklist.
  • Remove the processed item from the list, or move it to a “completed” section.
  • Confirm the user’s action with a message toast.

Visual Design

The worklist has no visual design of its own, but app design and development teams should ensure that the margins and padding are similar to those of the normal page layout. For example, the controls should have the same margins inside the side content container.

Basic layout of the worklist on a smartphone
Basic layout of the worklist on a smartphone
Basic layout of the worklist on a tablet
Basic layout of the worklist on a tablet
Basic layout of the worklist on a desktop device
Basic layout of the worklist on a desktop device

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Worklist Floorplan

Work list with actions at line item level

A worklist displays a collection of items that are to be processed by the user. Working through the item list usually involves reviewing details of the list items and taking action. In most cases, the user has to either complete a work item or delegate it.

The focus of the worklist floorplan lies on processing the items. This differs from the list report floorplan, which focuses on filtering content to create a list.

Worklist – Full screen
Worklist – Full screen

Usage

Use the worklist floorplan if:

  • The user has numerous potential work items and needs to decide which ones to process first.
  • You want to give the user a direct entry point for taking action on work items.
  • Your app uses the full screen layout. The full screen worklist is preferable if the work items are complex objects. For simple scenarios, use the split-screen layout instead.

Do not use the worklist floorplan if:

  • You want to create only a lightweight worklist. Instead, use the split-screen layout for simple scenarios.
  • The items you are showing are not work items.
  • You want to show large item lists, or combine different data visualizations (graphics or tables). In this case, use the list report floorplan instead.

Layout

The launchpad shell bar is always available at the top of SAP Fiori apps. The app title (app header) reflects the title of the launch tile, such as Manage Products.

The worklist contains a list of work items. You can also use the icon tab bar to split the list into different categories. In addition, the worklist can use filters and variants, as described for the list report floorplan. Bear in mind, however, that if users can filter the list, they may also overlook important work items.

To ensure that the application runs on all devices, we recommend using the responsive table. The responsive table also offers a wide range of options for optimizing the layout, scalability, and how the user takes action.

Basic structure
Basic structure

Responsiveness and Adaptiveness

Worklist floorplan - Size S
Worklist floorplan - Size S
Worklist floorplan - Size M
Worklist floorplan - Size M
Worklist floorplan - Size L
Worklist floorplan - Size L

Worklist Floorplan with the Dynamic Page Layout

Variant Management & Global Actions

The header title of the dynamic page provides a variant management and the global actions. The header title displays the selected tab if the header content is collapsed.

Dynamic Page Header

The header content of the page gets a snapping behavior. This includes the tab bar. The header content collapses after scrolling the page if used with the sap.m.table (responsive table), or can be collapsed manually if used with the sap.ui.tables (grid tabel, analytical table (ALV), tree table).

Footer Toolbar

In edit mode or for finalizing actions there is a footer toolbar. This element appears on the bottom of the page content and contains finalizing actions.

Types

Simple Worklist

The worklist floorplan allows the user to work through a list of items. Ideally, the system provides the user with a complete list of work items in the correct order. You should also ensure that no important work items are lost, and keep distracting functions to a minimum.

The most basic version of the worklist is therefore a plain page with a list.

Simple worklist without tabs
Simple worklist without tabs

Category Worklist

The icon tab bar enables users to call up work items in specific categories. This can help users identify critical items more easily. Different tabs can also contain tables with different configurations (for example, with different columns or actions).

You can offer visual orientation by applying semantic colors to the icons for the different categories (for example, red on the Error tab below).

Worklist with tab categories
Worklist with tab categories

KPI Worklist

The key performance indicator (KPI) worklist allows the user to track a KPI while processing the worklist. You can display the KPI in the subheader.

Worklist with KPI
Worklist with KPI

Actions

Worklist with table toolbar for actions
Worklist with table toolbar for actions

The header title contains the global actions. These actions can apply to individual or multiple items selected by the user. Placing actions in the toolbar allows users to process several items at a time. However, more clicks are required to process individual work items.

Worklist with actions at line item level
Worklist with actions at line item level

You can also offer actions at line item level. This reduces the interaction required to a single click per item. Consider offering actions at line item level for most frequently used actions, and if the list provides enough information to make the a decision.

Often, users will need more information before they can take action. In this case, offer navigation to the work item details, and offer all the relevant actions in the detail screen.

Worklist with navigation to item details
Worklist with navigation to item details
Work item details
Work item details

Once the user has completed the task, the app should:

  • Return the user to the worklist.
  • Remove the processed item from the list, or move it to a “completed” section.
  • Confirm the user’s action with a message toast.

Visual Design

The worklist has no visual design of its own, but app design and development teams should ensure that the margins and padding are similar to those of the normal page layout. For example, the controls should have the same margins inside the side content container.

Basic layout of the worklist on a smartphone (Size S)
Basic layout of the worklist on a smartphone (Size S)
Basic layout of the worklist on a tablet (size M)
Basic layout of the worklist on a tablet (size M)
Basic layout of the worklist on a desktop device (Size L)
Basic layout of the worklist on a desktop device (Size L)

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation

Object View Floorplan

Information
The new floorplan for displaying objects in SAP Fiori is the object page. The object page floorplan offers a richer feature set (such as anchors and tab navigation) and is the successor of the object view floorplan. Where possible, we recommend using the object page floorplan.

From version 1.42, the object view floorplan is only allowed in combination with the icon tab bar. As soon as the icon tab bar is available for the object page, this floorplan will be deprecated.

The object view is a floorplan for displaying objects in SAP Fiori. It can either be embedded in a master-detail app (as in typical approval apps) or shown as a full-screen page. This floorplan offers optimal support for multiple devices.

The object view is suitable for both simple objects and more complex, multi-faceted objects. You can use a tab container to present the information in different categories.

For editing, the layout switches to a flat object view. In other words, all the sections that were presented as tabs appear together on one long page. Switching to this flat layout prevents user input and validation errors from being scattered across multiple tabs.

Object view on a desktop device
Object view on a desktop device

Usage

Use the object view floorplan if:

  • You have objects with up to 5-7 facets.
  • You want to display complex objects with minimal navigation.
  • You want to combine a long table with other object facets, but keep the table visible. In this case, the other aspects are shown as tabs and the table appears below the tab area.
  • You are building a typical approval app.

Do not use the object view floorplan if:

  • You want to keep the same layout when the app switches between create/edit and display modes. In this case, use the flat object view.

Structure

The object view floorplan comprises the following elements, from top to bottom:

  1. Launchpad shell bar: Always available at the top of SAP Fiori apps.
  2. Application header: Reflects the title of the launch tile, such as Manage Products.
  3. Object header
  4. Tabs (optional): If your content falls into different categories, or you want to display different tables, you can embed the content in an icon tab bar.
  5. Content area: The main part of the screen for displaying your data. You can use lists, tables, tree tables, or charts.
  6. Footer toolbar
Structure of object view floorplan
Structure of object view floorplan

Responsiveness

Object view on a smartphone
Object view on a smartphone
Object view on a tablet
Object view on a tablet
Object view on a desktop
Object view on a desktop

You can use the object view floorplan in both a full screen layout and a split-screen layout.

Object view in a split-screen layout (reference app: Manage Products )
Object view in a split-screen layout (reference app: Manage Products )

Tabs

The key element of the object view is the icon tab bar. Each of the tabs shows a certain facet of the object. There are two primary facet types:

  • Form-based facets display attributes of the object in a form layout (for example, object details or contact details).
  • Tabular facets show a list of similar attributes or relationships in a list or table structure (such as attachments, contacts, or products).

Defining Tabs

You can define tabs as expandable, allowing users to show or hide the tab content as needed.

You can also define the default tab that is selected when the user opens the application. This might not always be the first tab on the left. However, you should ensure that the tab state is consistent for object views of the same type. This gives the user a coherent user experience when navigating between object views.

The user can switch between the object facets by just switching tabs. You can display additional information below the tabs.

Object view with text-only tabs
Object view with text-only tabs

In the object view, you can use the following tab types:

  • Icon tabs: Use icons if you only need the standard tabs, such as information, attachments, and notes.
  • Text only: Use text if you need tabs for other (non-standard) object facets.
  • Process tabs: You can also use the tab bar to depict a process. In this case, each tab stands for one step.

Guidelines for choosing a tab type:

  • As a simple rule of thumb, if you have to think about which icon fits best, use the text-only type instead.
  • Do not mix the text-only and icon tab types.
  • Do not use separators between the tabs.

Flows and Variants

Create

The create action creates a new object. The corresponding button can either be a plus ( ) button or a button with a meaningful text (such as Add Product). When the user creates a new object, the display changes to a flat object view in edit mode. Switching to this flat layout prevents user input and validation errors from being scattered across multiple tabs.

In the flat object view, users can fill out the details and save the object. After saving, the new object is shown using the standard object view. If the user navigates away from the object without saving the entries made so far, the app warns the user with a data loss dialog.

Edit

We recommend using the flat object view in edit mode (as for the “create” scenario above). When the user clicks or taps the Edit button, the floorplan switches from the display mode with tabs to the edit mode with the flat object view. The Edit button is replaced by the Save and Cancel buttons. Switching to this flat layout prevents user input and validation errors from being scattered across multiple tabs.

Save or Cancel takes the user back to the display mode of the object view with tabs. Cancel discards any changes made, while Save keeps the changes. If the user navigates to another object or navigates away from the edit page without saving, the app warns the user with a data loss dialog.

If the object view does not have any tabs, the page keeps its layout and structure in edit mode. For more information, see manage simple objects.

Exception: If the object view includes tabs, but only a few tabs have editable fields, you can also use in-place editing and keep the structure of the tabs. In this case, the edit button is positioned next to the editable content (see manage parts of an object for details).

Object view – Edit flow behavior
Object view – Edit flow behavior
Display mode - Object view
Display mode - Object view
Edit mode – Object view switches to a flat object view
Edit mode – Object view switches to a flat object view

In addition to the full page edit mode, the flat object view also supports a partial edit flow, where only certain sections switch to edit mode.

The footer toolbar in the object view floorplan is global. Actions in the footer toolbar must not change when the user switches tabs. If you need to include actions that relate to a specific tab (facet), include them in the tab content. For example, if the tab contains a table, offer actions in a table toolbar.

Object view with partial edit in display mode
Object view with partial edit in display mode
Object view with editable section
Object view with editable section
Attachment tab in an object view – Modeless editing
Attachment tab in an object view – Modeless editing

While the edit mode involves switching to a flat object view, some elements support “modeless” editing. These elements can be changed in both display and edit modes.

For example, adding a new attachment is a one-click action that is guided by a dialog. This action can be triggered without switching to edit mode. Any errors that might occur can be handled during this creation process.

If you do not want to switch to a global edit mode, you can encapsulate your action in a dialog. Example use cases include:

  • Editing certain attributes of an element (use a dialog)
  • Adding line items to a tabular facet (use the plus ( ) button and a dialog or create page)
  • Removing a line item (use a one-click action in the table)

Guidelines

  • Do not switch the actions in the footer toolbar when the user switches tabs. The footer toolbar is global and constant. If you have tab-specific actions, place them in the tab content area.
  • You can hide empty tabs, but only if there is no way of adding content to the tab. For example, you still need to show an empty Attachments tab to enable users to upload attachments.
  • Try to persist the selection state of tabs during a session so that the user finds a similar view while navigating between instances.

Visual Design

The object view floorplan has no visual design of its own, but application design and development should ensure that the margins and paddings are similar to the normal page layout. For example, the controls should have the same margins inside the side content container.

Basic layout of the object view on a smartphone
Basic layout of the object view on a smartphone
Basic layout of the object view on a tablet
Basic layout of the object view on a tablet
Basic layout of the object view on a desktop
Basic layout of the object view on a desktop
Basic layout of the object view on a desktop – Split screen
Basic layout of the object view on a desktop – Split screen

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation