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.

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:

1. Form-based facets display attributes of the object in a form layout (for example, object details or contact details).
2. 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.

In the object view, you can use the following tab types:

1. Icon tabs: Use icons if you only need the standard tabs, such as information, attachments, and notes.
2. Text only: Use text if you need tabs for other (non-standard) object facets.
3. 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.

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

Resources

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

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

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

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.

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

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

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

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

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

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

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

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

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

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 (SAP Fiori element).

Object Page

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

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.

The flat object view floorplan displays all the information for an object on one long, scrollable page. The advantage of this floorplan over the object view floorplan is that the layout stays the same in both display and edit mode.

Usage

Use the flat object view floorplan if:

• You want to switch to edit mode without disrupting the layout of the page.
• You want to show the different sections for an object on one page.

Do not use the flat object view floorplan if:

• The objects contain too much information for one page. Instead, use the object view floorplan, and build tabs to organize and simplify the content.

Structure

The flat object view has the same basic structure as the object view floorplan, with the object header control at the top and a footer toolbar at the bottom. However, unlike the object view floorplan, the flat object view does not have a tab container to switch between different facets of the object. Instead, it has one long flat layout with multiple form or table elements underneath each other. The flat object view builds entirely on existing controls. 

Responsivness and Adaptiveness

You can embed the flat object view floorplan in a full screen layout or split-screen layout. In both cases, it can be used as an alternative to the object view floorplan.

Edit

The flat object view is optimized for switching between the display and edit modes – the structure and layout of the page remain intact. In the object view, the tabs have to be flattened out in edit mode to avoid hidden editing errors and inconsistencies between tabs. In the flat object view, all elements are always visible, so any error messages and inconsistencies can be highlighted directly on the page.

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.

Scrolling

Because the flat object view displays everything on one page, users might need to scroll to reach the end. While scrolling itself is no longer critical – today’s devices all support optimized scroll gestures – usability issues can still occur with large tables and collapsible panels.

Embedding Large Tables

If the view contains a long embedded table, the remaining content may be pushed down too far. Therefore, when embedding a large table, make sure that you limit the number of items that are initially loaded. This ensures that the user can reach the content below the table.

Collapsible Panels

If your object has several sections, you might be tempted to use collapsible panels to reduce the length of the page and minimize scrolling. However, placing several collapsed panels below each other can look broken. It also forces the user to open and close containers, which can shift their position. This behavior has been proven to cause usability issues. Where possible, avoid using collapsible panels in the flat object view.

Guidelines

• Avoid showing long tables in full when a page is first loaded. Instead, use lazy loading to display only the first 5 or 10 table items.
• Avoid using collapsible panels to minimize scrolling.
• Use either the panel or table controls as basic elements of the flat object page and avoid embedding elements in other elements. Placing the elements underneath each other makes the layout very clean and stable.
• Use the object header at the top of the flat object view to give the page structure.
• Choose between the global or local edit flow (the global flow is usually easier to handle).

Visual Design

The flat object view floorplan has no visual design of its own. However, 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.

Resources

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

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, and is set to replace the flat object view floorplan and 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.

Usage

Use the object page floorplan if:

• You need to let users display, create, or edit an object.
• You want to offer a flat page with no navigation for a simple object.
• You want to use tabs or anchor navigation for a more complex object.

Do not use the object page floorplan 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.

In all these cases, consider using 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).

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.

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.

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.

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.

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.

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.

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.

SAP Fiori Element

Use the table below to see which features are available for the “object page” SAP Fiori element.

Resources

The list report floorplan allows the user to work with a large list of items and take action. This floorplan combines powerful functions for filtering large lists with different ways of displaying the resulting item list. You can only use the list report floorplan with the full screen layout.

Usage

Use the list report floorplan if:

• You need to display and filter large lists of items. The filter bar is very powerful and allows the user to handle large data sets with multiple filter mechanisms.
• You want to combine different visualizations for large data sets, such as graphics and tables.

Do not use the list report floorplan if:

• The users work primarily on a specific list of items. In this case, the focus lies on the action, and less on filtering, so you should use the worklist floorplan

Layout

Responsiveness

Currently, the controls used within the list report floorplan do not all adjust responsively across all devices. Depending on the controls you use, you may need to change your implementation for some devices. The level of multi-device support depends on the individual controls used in the floorplan. For details, see the guidelines for the individual controls.

• Filter bar  – supported on all devices.
• Icon tab bar  – supported on all devices.
• Responsive table, list – supported on all devices (use the responsive features).
• Analytical table, grid table  – supported on desktop and tablet devices only. On smartphones, replace it with the responsive table.
• Tree table – supported on desktop and tablet devices only. There is currently no direct alternative for smartphones. Only in some cases, the tree table could be replaced by a category navigation pattern on smart phone.
• Chart – supported on all devices.

List Report Floorplan with the Dynamic Page

Variant Management and Global Actions

The header title of the dynamic page contains the variant management and global actions. The header title displays up to 5 filter criteria if the header content is collapsed.

Snapping Header

The header content of the page has a snapping behavior. This includes the filter 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, a footer toolbar is available. This element appears on the bottom of the page content and contains closing or finalizing actions.

Filter Area

In the filter area, users specify the data that is displayed in the content area by:

• Using different filter criteria to reduce the number of items displayed.
• Selecting predefined filter sets (known as variants) to support different use cases.

These functions are offered by the filter bar, which is mandatory for any list report floorplan.

Please be aware that triggering a filter can take a while if the result set becomes very large. To improve performance in such cases, consider providing manadory filter fields and/ or default settings for filters. Both help to reduce the size of typical filter result sets.

The variant management functions allow users to define and manage predefined filter sets as well as predefined view settings for the lists, tables, trees, and charts. Users can set a default variant, and specify how the variant is executed:

• If Execute on Select is active, the variant is executed as soon as the user selects it (live update).
• If Execute on Select is not active, the user can modify the query, but has to execute the search manually to display the data (delayed update).

Variant management is optional.

The filter bar can be either expanded or collapsed when the list report floorplan is launched. The expanded view reveals the filter functionality and makes it clear that the user can filter directly on the list. However, it looks more complex than the collapsed view. The collapsed view is simple and user-friendly. However, users might not realize that they can change the content using multiple filters.

Users can expand or collapse the filter bar manually. In this case, the app should persist the status that the user has set.

In case the grid or analytical table is used there has to be a show/hide filters button since the page doesn´t scroll.

Content Area

The content area is located on the lower part of the screen and contains the actual data. The data shown is determined by the settings in the filter area.

Content

There are various options for displaying large data sets, each of which has specific features and advantages. For more information, see the documentation for the individual control.

• List (sap.m.List)
• Table (sap.m.Table)
• Grid Table (sap.ui.table.Table)
• Analytical table (sap.ui.table.AnalyticalTable)
• Tree table (sap.ui.table.TreeTable)
• Smart Table (sap.ui.comp.smarttable.SmartTable)
• Charts (sap.viz.ui5.controls.VizFrame)

Toolbar

The different content controls allow you to incorporate toolbars in different ways. The details are covered in the guidelines for the respective toolbars. This section only covers the specifics for the list report floorplan.

In the simplest case, the toolbar contains only basic table functionality, such as the table title (optionally with count), sorting, grouping, and table personalization.

In addition to the basic list, you can provide alternative visualizations, such as a table or a chart. You can also offer these two functions in the toolbar, including combined visualizations, such as a chart together with a table.

Users can store personalized table settings in a layout variant, which is also available on the table toolbar. If so, do not store the table settings in the filter variant.

Use this only in rare cases. In most cases it is sufficient to use the variant management on the filter bar for storing the filter settings and the layout settings of the table.

You can extend the toolbar to offer additional contextual actions. These actions can be selection-dependent (enabled only if an item is selected) or selection-independent (always enabled, even without item selection).

Simple Content (Default)

In most cases, the content is displayed in a single list or table, with a title toolbar at the top. The title toolbar has a specific style (transparent background), and uses one of the content variants described above.

Multiple Views

In many cases, you will want to offer multiple predefined views on the data in the content area. Such views represent certain filter criteria, or some other fundamental differentiation between the items displayed in the content (for example, open items, items in process, and closed items). There are two ways to let users select these views directly:

• For two to three views, use a segmented button .
• For more than three views, or if the number of views can change, use the select control .

For the filter bar also influences the result set shown in the table, avoid repeating filter criteria in the views. If the criterion that determines the view is also a filter criterion, you might run into dependencies that are difficult to resolve. For example, if you have a Status filter in the filter bar, and a view switch with the views Open, In Process, and Closed, both refer to the same property.

If you use a content switch, you no longer need a title. In very rare use cases, both a title and a content switch must be visible. In this case, the title and the content view are left-aligned.

Switching between views can affect how the content is visualized:

• For charts, switching views can affect the visualization. This can be the case if there is a better way to represent the data for a specific view (for example, view by country, view by customer).
• For tables, the different views do not affect how the content is visualized. They only change the content or items displayed (filter on the content). Table columns and sort settings are not affected by switching views.

Multiple Contents

A list report can contain multiple lists or tables in parallel. The same filter criteria are applied across all tables. For example, if the user filters for specific customers and dates, a customer overview report would show only matching invoices, deliveries, and overdue payments.

To facilitate navigation, you can show each table on a separate tab in the icon tab bar.

Guidelines:

• For the list report floorplan, use the text-only version of the icon tab bar.
• By default, populate the count attribute with the number of items shown in the respective table.
• Use the same name for the tab and the table title.
• You can add a toolbar for  table functions. Follow the rules described above for the toolbar.

“No Data” Texts

If the content area is empty, use a placeholder text to tell the user why. To assign a placeholder text, set the “noDataText” attribute.

Typical use cases and placeholder texts:

• The user has started the app, but not applied any filters.
  Text: “No items selected. To start, enter your selection criteria and run the search.”
• The user has executed the filter, but no items were found.
  Text: “No results found. Try adjusting your search and filter settings.”
• The user has opened a related app. The filter criteria are transferred automatically, but no items are found in the related app.
  Text: “No items selected. Check the search and filter settings.”

Dependencies Between Areas

The filter and content areas must be synchronized at all times. In other words, the filters in the filter bar must always describe the items that are shown in the content area.

Updating the Content Area

The filter bar supports two update modes:

• Live update (default): The user changes a filter criterion, and the content is updated immediately. The results table is updated every time the user changes a filter field or the search field. Therefore, a Go button is not necessary and is not shown if the live update mode is used. Also, the search is triggered with every letter that is entered. Starting with the first letter typed in, the table is updated with the results that match all set filters, including the search term.
  The live update mode fits for most use cases and should be used as a default.

• Manual update: The user changes a filter criterion first and then presses the Go button to apply the filter and update the content. In this case, a Go button is mandatory. If a search field is used, it is only triggered by the Go button and not instantly.

The manual update mode is necessary to reduce load on the back-end systems. In live update mode, the app has to query the back end for every filter change.

In the manual update mode, indicate that the content is not yet updated by graying out the content area (showOverlay = true). As soon as the user triggers the update by selecting Go in the filter bar, set the content area to “busy” (busy = true) until the new data has been retrieved. This will switch the control to busy state.

Filter Bar and Table Filter

Since the filters in the filter bar and the filter option in the table can contain confusing or even contradictory entries, you must deactivate the filter option in the table.

Basic Search Field and Table Search

The filter bar determines the content of the report. This filter configuration can also be persisted and shared with other users (variant management).

The search field is optional. If used, it is shown next to the variant management in the fitler bar. Every search is executed against the back end and in combination with the set filters.

The report results are now reduced to only those items that contain the search string and match all set filters.

Actions

Users should also be able to trigger actions on the list report floorplan. Apps can offer four types of action: global actions, table actions, line item actions, and finalizing actions.

1. Global Actions

If the user wants to execute actions that affect the entire page, these actions can be placed in the page header section of the page (1).

The global actions do also contain the Share button. Show it only, if you really need it. In other cases, remove the Share button.

2. Table Actions

To allow users to change the content of a table, you can offer actions in the table toolbar (2). The scope of these actions depends on the items selected (no item selected, a single item selected, multiple items selected). If an action applies to specific items, the user has to first select the item or items, and then the action from the toolbar. Examples of such actions include:

• Adding/removing items
• Editing one or multiple items
• Triggering an object function for one or multiple items
• Changing the status of one or multiple items

Disable actions, which can currently not be used (e.g. for no items are selected).

3. Line Item Actions

In rare cases it can make sense to let the user trigger specific, frequent tasks directly from the item (3). In this case, you can embed a button into a line item. Such actions can be offered alongside corresponding table actions or global actions. Examples of line item actions include:

• Starting/stopping a batch job
• Approving an item
• Assigning an item

4. Finalizing Actions

Finalizing actions execute the end of a process that affect the entire page. These actions can be placed in the footer toolbar section of the page (4).

For example:

• Save
• Cancel
• Submit

Navigation

In most cases, users can navigate to the detail view for each line item in the report. In cases where reports display data aggregates, the user might also want to drill into the details for the aggregated amount.

Line Item Navigation

At line item level, navigation to the item details depends on the control that is being used to display the data. In most cases, users navigate to the details either by selecting the table line (list, responsive table), or by selecting the identifier of the line item (grid table, analytical table, tree table). For more details on the navigation behavior, see the guideline for the respective control.

Drilldown Navigation

If a report displays aggregated amounts, the user might want to drill down into the individual items. In this case, we recommend to display the aggregate values as links. Clicking the link takes the user to another report showing the individual figures. Use the possibilities of the link to provide different levels of highlight in cases where the table contains many columns with links.

In charts, offer the drilldown navigation link in the popover for the chart element.

Cross Navigation

Reports – especially tables – can contain cross-references to other entities, such as people or business objects. Show references to other entities in a popover. Typically, the popover displays basic details of the referenced object and a navigation link to another page or another app that shows the object details.

Visual Design

For your convenience, we have integrated the visual design specifications for the list report floorplan.

Resources

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

The SAP Fiori element list report (formerly referred to as smart template) is an instance of the general list report floorplan implemented as a reusable template. The list report floorplan allows users to work with large lists of items and take action. The guidelines for the list report generally apply. Existing deviations and limitations are listed below.

Usage

If you are not sure whether to use this floorplan, please consult the list report floorplan guidelines. Use this template to efficiently implement standard applications that are based on large lists. The smart filter bar, smart table, and object page sections support breakout scenarios. This means that custom-coded deviations are technically possible, although this is not the case for the object header.

Responsiveness

Layout

Behavior and Interaction

Smart Table – Table Toolbar

Triggering

App-specific actions can be one of the following types:

• The system simply triggers the action.
• The action needs a user confirmation. This is used, for example, for critical actions that have severe consequences. The system opens a dialog in which the user needs to confirm the action. This message is generic and cannot be replaced.
• The action needs additional user input, such as an approval comment. The system opens a dialog with one or more entry elements in which the user enters the required data. The system can prefill data if applicable.

App-specific actions can also trigger a navigation to another app or to a related object page inside the same app. The navigation can depend on zero or one selected item(s).

Smart Table

Within this SAP Fiori element, you can use the responsive table, grid table, or analytical table within the smart table. The tree table is not supported.

The smart table supports:

• None, single, or multiselection.
  • For multiselection, the SAP Fiori Element triggers the action for all selected items. If an error occurs with one or more of the selected items, a message is displayed. All other items are processed.
• Text control in line items.
• Indications of editing states within the rows.
  • For example, Draft or Locked by….The table can be filtered by the editing states by using the filter bar.
• Line item navigation inside the app (to a related object page per default). Apps can override this behavior and define their own navigation target. This target can also be different pending on app-defined conditions.
• Line item cross navigation to another SAP Fiori application or to another system.
• Link and smart link to navigate to any webpage, to another app, or to a related object page inside the same app.
• Line item actions as text or icon buttons (such as Approve or Reject)
• Object status control in line items:
  • Use of a specific status such as Out of Stock in connection with the standard semantic color and/or status icon.
• Any control which the corresponding table allows by using breakout columns.

At present, the smart table does not support:

• The object number. Amounts appear as standard text only.

Only the responsive table supports:

• A column that displays the object identifier, including the object name and ID.
• Pictures in line items.
• A rating indicator and progress bar in line items.
• Line item navigation with a chevron icon to detail screens. For the grid table and analytical table, the toolbar offers a Show Details button instead.
• Smart area micro chart and smart bullet micro chart in line items.

Only the grid table and analytical table support:

• App-specific column widths: While the smart template list report uses an automatic calculation for the width of each column, this calculation is not always perfect. Apps can override the calculated width per column.

Footer Toolbar

Finalizing actions are placed on the footer toolbar. Finalizing actions can be shown or hidden (for example, depending on access rights).

Use the footer toolbar only if you have closing or finalizing actions for the whole page. For the list report, this is only a rare case.

Resources

A collect app is used to browse and collect objects in order to apply a more complex action or a process to them. A typical example of this is the shopping app.

A shopping app enables users to browse through products, collect them in a shopping cart and to order them. In general, it consists of three parts:

• Product list (all products)
• Shopping cart
• Check out step(s)

Responsiveness

The shopping (collect) app works well on any form factor. It inherits the responsive behavior from the full screen layout.

Behavior and Interaction

Product List (All Products)

The master screen contains a responsive table with all products and is usually a full-screen app. The header contains an indicator of how many products are in the shopping cart. This indicator also serves as navigation trigger to the shopping cart. The user can filter the items using the filter bar above the table.

Sort, group, and personalization is positioned in the table toolbar. The Personalize button allows the user to show/ hide or rearrange columns.
Any filters that are set and the personalization of the table can be saved with the variant management in the object header.

Product Detail Page

Add to Cart (Action)

Shopping Cart

Checkout

Page Flow

The shopping (collect) flow shows how a user navigates from a product list through the whole ordering process.

A collect app is used to browse and collect objects in order to apply a more complex action or a process to them. A typical example of this is the shopping app.

A shopping app enables users to browse through products, collect them in a shopping cart and to order them. In general, it consists of three parts:

• Product list (all products)
• Shopping cart
• Check out step(s)

Responsiveness

The shopping (collect) app works well on any form factor. It inherits the responsive behavior from the full screen layout.

Behavior and Interaction

Product List (All Products)

The master screen contains a responsive table with all products and is usually a full-screen app. The header contains an indicator of how many products are in the shopping cart. This indicator also serves as navigation trigger to the shopping cart. The user can filter the items using the filter bar above the table.

Sort, group, and personalization is positioned in the table toolbar. The Personalize button allows the user to show/ hide or rearrange columns.
Any filters that are set and the personalization of the table can be saved with the variant management in the object header.

Product Detail Page

Add to Cart (Action)

Shopping Cart

Checkout

Page Flow

The shopping (collect) flow shows how a user navigates from a product list through the whole ordering process.

The approval app allows the user to quickly scan through a list of work items and take action. This app type has already been used in multiple occasions within SAP Fiori, and therefore is well established and mature.

The approval app is based on the split-screen layout and also can make use of all capabilities of the master list.

Responsiveness

The approval app works well on any form factor. It inherits the responsive behavior from the split-screen layout.

Behavior and Interaction

The approval app is used to display a number of work items in the master list and the work item’s details in the details area. This allows the user to get a quick overview of the work items, directly select them, and take action without navigation.

Ideally, the switch between work items should be fast an seamless. Otherwise, please indicate loading with a busy indicator every time the switch between items takes longer than two seconds.

On startup, the first work item should be selected and displayed in the details area. If there are no items in the list, please show an empty page in the details area.

The approval app consists of the following components:

• Master list that contains object list items (sap.m.ObjectListItem)
• Detail area that contains an object view page

In the approval app, the master list usually uses the object list item. This corresponds to the object header used in the object view page in the details area. The object list item should contain the most important information about the item. It contains the following elements:

• Title – used to display information to identify the object
• Key figure – used to give a good understanding of the value of the item (if required, use formatters to shorten the number)
• Attributes (max. three) –  can be used to display additional information like an ID, content information, etc.
• Status fields (max. two) – can show icons or text to describe the status of the item; consider using semantic colors to highlight critical status

The object header in the details area should repeat the fields that are shown in the master list. This helps to recognize the item, especially if master and detail are split into two different pages when running on a smartphone. It can also show additional information, however, please try to avoid having too much different information between the object header and the object list item.

The rules for the master list and the split-screen layout also apply to the approval app. This includes the possibility to offer the selection modes for mass approval (usually not wanted by customers), Search, Filter, Group, and Sort.

The approval app can also contain other tabs. The four tabs mentioned above are the most common tabs and should be used consistently.

Approve and Reject

The action on the individual work item is offered in the footer bar (sap.m.Toolbar) on the detail area.

In approval apps, it is common to have two primary actions:

• Approve (positive action using button type Accept)
• Reject (negative action using the button type Reject)

These default actions in the approval app make it very easy for the user to map the decision to the right action. Using semantic values allows customers to remap semantics to other colors if established within a company or culture.

It is still allowed to offer other or additional actions if the use case requires it.

In addition to the approve and reject action, the app should also offer access to the sharing actions.

In some cases it is required to ask for a confirmation on either the approve or the reject action.

A rejection needs to be especially confirmed to avoid an erroneous rejection and any follow-up confusion. In addition, the user might want to add a reason to the rejection to explain the decision.

To achieve this in a consistent manner, please use the confirmation dialog (sap.ca.ui.dialog).

Navigating Line Items

The approval app allows the user to quickly scan through a list of work items and take action. This app type has already been used in multiple occasions within SAP Fiori, and therefore is well established and mature.

The approval app is based on the split-screen layout and also can make use of all capabilities of the master list.

Responsiveness

The approval app works well on any form factor. It inherits the responsive behavior from the split-screen layout.

Behavior and Interaction

The approval app is used to display a number of work items in the master list and the work item’s details in the details area. This allows the user to get a quick overview of the work items, directly select them, and take action without navigation.

Ideally, the switch between work items should be fast an seamless. Otherwise, please indicate loading with a busy indicator every time the switch between items takes longer than two seconds.

On startup, the first work item should be selected and displayed in the details area. If there are no items in the list, please show an empty page in the details area.

The approval app consists of the following components:

• Master list containing object list items (sap.m.ObjectListItem).
• Detail area containing an object view page.

In the approval app, the master list usually uses the object list item. This corresponds to the object header used in the object view page in the details area. The object list item should contain the most important information about the item. It contains the following elements:

• Title: Used to display information to identify the object.
• Key figure:  Used to give a good understanding of the value of the item. If required, use formatters to shorten the number.
• Attributes (max. three):  Used to display additional information such as an ID, content information,and more.
• Status fields (max. two): Displays icons or text that describe the status of the item. Consider using semantic colors to highlight critical statuses.

The object header in the details area should repeat the fields that are shown in the master list. This helps to recognize the item, especially if master and detail are split into two different pages when running on a smartphone. It can also show additional information, however, please try to avoid having too much different information between the object header and the object list item.

The rules for the master list and the split-screen layout also apply to the approval app. This includes the possibility to offer the selection modes for mass approval (usually not wanted by customers), Search, Filter, Group, and Sort.

The approval app can also contain other tabs. The four tabs mentioned above are the most common tabs and should be used consistently.

Approve and Reject

The action on the individual work item is offered in the footer bar (sap.m.Toolbar) on the detail area.

In approval apps, it is common to have two primary actions:

• Approve (positive action using button type Accept)
• Reject (negative action using the button type Reject)

These default actions in the approval app make it very easy for the user to map the decision to the right action. Using semantic values allows customers to remap semantics to other colors if established within a company or culture.

It is still allowed to offer other or additional actions if the use case requires it.

In addition to the approve and reject action, the app should also offer access to the sharing actions.

In some cases, it is required to ask for a confirmation on either the approve or the reject action.

A rejection needs to be especially confirmed to avoid an erroneous rejection and any follow-up confusion. In addition, the user might want to add a reason to the rejection to explain the decision.

To achieve this in a consistent manner, please use the confirmation dialog (sap.ca.ui.dialog).

Navigating Line Items

The master-detail app allows the user to quickly scan through a list of items and take action. The main actions are creating and editing list items. This app type has already been used in multiple occasions within SAP Fiori and is well established and mature.

The master-detail app is based on the split-screen layout and also uses the master list.

Responsiveness

The master-detail app works well on any form factor. It inherits the responsive behavior from the split-screen layout.

Behavior and Interaction

Please use the master-detail app to display a number of items in the master list and further information to that item in the details area. This allows the user to quickly get an overview of the items. The user is able to select an existing item in order to edit it or can create a new one without navigating.

The possibility to use the multi-select functionality in order to edit several items at the same time also exists (read more in master list article “select multiple items“).

Note: The edit page floorplan and the create page floorplan offer multiple variants to edit and create an item to support different use cases.

The master-detail app consists of the following components:

• Master list that contains object list items (sap.m.ObjectListItem)
• Detail area that contains an object view floorplan or a flat object view floorplan in edit mode

No items available:

On startup, the first work item should be selected and displayed in the details area. If there are no items in the list, the details area should show an empty page.

If an item is saved as tile and cannot be shown the next time, then the details area should also show an empty page (see picture below).

The full screen layout lets you exploit the full width of the screen. Use this layout for apps that need to display large amounts of data, large visualizations, or wide tables.

Avoid switching between full and split-screen layouts within an app. If your app has some screens that require the full width, and others that do not, try to stick to one layout.

Usage

Use the full screen layout if:

• Your app content requires the full width of the screen (for example, large tables, charts, or other types of visualization).

Do not use the full screen layout if:

• You only need to display a small amount of information. If you cannot avoid using the full screen layout, use letterboxing to mitigate the issue.
• You are not sure how to structure your information on the screen.

Structure

Like all layouts, the full screen layout is embedded in the shell header of the SAP Fiori lauchpad. 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 uppermost app element is the app header, with the back navigation, the app title, and one optional action. The app title reflects the title of the launch tile, such as Manage Products. The exceptions is the create page floorplan. From here, the user can drill down to subpages (line items). The title of the subpage shows, for example, <Sub item> (2 of 5).

The long scrollable page below contains the app content. You can either use one of the predefined floorplans, or create your own layout.

You can also add an app-specific footer toolbar at the bottom of the screen.

The full screen layout has one single scrolling area.

Responsiveness

The full screen layout offers considerable freedom and flexibility. However, you also need to make sure that the app is responsive or adaptive across devices. The content is not adjusted automatically as it is for the split-screen layout. Instead, you need to select the appropriate layout and controls, and make any necessary adjustments yourself.

Letterboxing means limiting the width of the content area to 1280 px. This prevents the app content from becoming too “stretched” on wide screens, and optimizes readability.

Examples

Full Screen example of “List Report”

Resources

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

The full screen layout lets you exploit the full width of the screen. Use this layout for apps that need to display large amounts of data, large visualizations, or wide tables.

Avoid switching between full and split-screen layouts within an app. If your app has some screens that require the full width, and others that do not, try to stick to one layout.

Usage

Use the full screen layout if:

• Your app content requires the full width of the screen (for example, large tables, charts, or other types of visualization).

Do not use the full screen layout if:

• You only need to display a small amount of information. If you cannot avoid using the full screen layout, use letterboxing to mitigate the issue.
• You are not sure how to structure your information on the screen.

Structure

Like all layouts, the full screen layout is embedded in the shell header of the SAP Fiori lauchpad. 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 uppermost app element is the app header, with the back navigation, the app title, and one optional action. The app title reflects the title of the launch tile, such as Manage Products. The exceptions is the create page floorplan. From here, the user can drill down to subpages (line items). The title of the subpage shows, for example, <Sub item> (2 of 5).

The long scrollable page below contains the app content. You can either use one of the predefined floorplans, or create your own layout.

You can also add an app-specific footer toolbar at the bottom of the screen.

The full screen layout has one single scrolling area.

Responsiveness

The full screen layout offers considerable freedom and flexibility. However, you also need to make sure that the app is responsive or adaptive across devices. The content is not adjusted automatically as it is for the split-screen layout. Instead, you need to select the appropriate layout and controls, and make any necessary adjustments yourself.

Letterboxing means limiting the width of the content area to 1280 px. This prevents the app content from becoming too “stretched” on wide screens, and optimizes readability.

Examples

Full Screen example of “List Report”

Resources

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

The full screen layout lets you exploit the full width of the screen. Use this layout for apps that need to display large amounts of data, large visualizations, or wide tables.

Avoid switching between full and split-screen layouts within an app. If your app has some screens that require the full width, and others that do not, try to stick to one layout.

Usage

Use the full screen layout if:

• Your app content requires the full width of the screen (for example, large tables, charts, or other types of visualization).

Do not use the full screen layout if:

• You only need to display a small amount of information. If you cannot avoid using the full screen layout, use letterboxing to mitigate the issue.
• You are not sure how to structure your information on the screen.

Structure

Like all layouts, the full screen layout is embedded in the shell header of the SAP Fiori lauchpad. 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 uppermost app element is the app header, with the back navigation, the app title, and one optional action. The app title reflects the title of the launch tile, such as Manage Products. Exceptions are the create page floorplan and the edit page floorplan. From here, the user can drill down to subpages (line items). The title of the subpage shows, for example, <Sub item> (2 of 5).

The long scrollable page below contains the app content. You can either use one of the predefined floorplans, or create your own layout.

You can also add an app-specific footer toolbar at the bottom of the screen.

The full screen layout has one single scrolling area.

Responsiveness

The full screen layout offers considerable freedom and flexibility. However, you also need to make sure that the app is responsive or adaptive across devices. The content is not adjusted automatically as it is for the split-screen layout. Instead, you need to select the appropriate layout and controls, and make any necessary adjustments yourself.

Letterboxing means limiting the width of the content area to 1280 px. This prevents the app content from becoming too “stretched” on wide screens, and optimizes readability.

Examples

List Report Floorplan

The list report is the most common floorplan for the full screen layout. This floorplan is used to display and filter large data sets, and takes full advantage of the additional screen real estate offered by the full screen layout.

Reference App “Shop”

The  reference app “Shop” shows how you might use a list report floorplan in the full screen layout. This app also demonstrates how you can overcome limits to responsiveness by making device-specific adaptations. On phones, the filter bar is replaced by a simple search field. This offers a better mobile user experience, and compensates for the fact that the current filter bar control does not support mobile devices. This example also shows how the list contents need to adjust to the available screen real estate.

Reference App “Shop”

The product details screen of the reference app “Shop” shows how an app can make use of an object view floorplan in the full screen layout. This example highlights the responsive capabilities of the components used for an object view floorplan.

Resources

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

The full screen layout lets you exploit the full width of the screen. Use this layout for apps that need to display large amounts of data, large visualizations, or wide tables.

Avoid switching between full and split-screen layouts within an app. If your app has some screens that require the full width, and others that do not, try to stick to one layout.

Usage

Use the full screen layout if:

• Your app content requires the full width of the screen (for example, large tables, charts, or other types of visualization).

Do not use the full screen layout if:

• You only need to display a small amount of information. If you cannot avoid using the full screen layout, use letterboxing to mitigate the issue.
• You are not sure how to structure your information on the screen.

Structure

Like all layouts, the full screen layout is embedded in the shell header of the SAP Fiori lauchpad. 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 uppermost app element is the app header, with the back navigation, the app title, and one optional action. The app title reflects the title of the launch tile, such as Manage Products. Exceptions are the create page floorplan and the edit page floorplan. From here, the user can drill down to subpages (line items). The title of the subpage shows, for example, <Sub item> (2 of 5).

The long scrollable page below contains the app content. You can either use one of the predefined floorplans, or create your own layout.

You can also add an app-specific footer toolbar at the bottom of the screen.

The full screen layout has one single scrolling area.

Responsiveness

The full screen layout offers considerable freedom and flexibility. However, you also need to make sure that the app is responsive or adaptive across devices. The content is not adjusted automatically as it is for the split-screen layout. Instead, you need to select the appropriate layout and controls, and make any necessary adjustments yourself.

Letterboxing means limiting the width of the content area to 1280 px. This prevents the app content from becoming too “stretched” on wide screens, and optimizes readability.

Examples

List Report Floorplan

The list report is the most common floorplan for the full screen layout. This floorplan is used to display and filter large data sets, and takes full advantage of the additional screen real estate offered by the full screen layout.

Reference App “Shop”

The product details screen of the reference app “Shop” shows how an app can make use of an object view floorplan in the full screen layout. This example highlights the responsive capabilities of the components used for an object view floorplan.

Resources

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

The full screen layout lets you exploit the full width of the screen. Use this layout for apps that need to display large amounts of data, large visualizations, or wide tables.

Avoid switching between full and split-screen layouts within an app. If your app has some screens that require the full width, and others that do not, try to stick to one layout.

Usage

Use the full screen layout if:

• Your app content requires the full width of the screen (for example, large tables, charts, or other types of visualization).

Do not use the full screen layout if:

• You only need to display a small amount of information. If you cannot avoid using the full screen layout, use letterboxing to mitigate the issue.
• You are not sure how to structure your information on the screen.

Structure

Like all layouts, the full screen layout is embedded in the shell header of the SAP Fiori lauchpad. 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 uppermost app element is the app header, with the back navigation, the app title, and one optional action. The app title reflects the title of the launch tile, such as Manage Products. The exceptions is the create page floorplan. From here, the user can drill down to subpages (line items). The title of the subpage shows, for example, <Sub item> (2 of 5).

The long scrollable page below contains the app content. You can either use one of the predefined floorplans, or create your own layout.

You can also add an app-specific footer toolbar at the bottom of the screen.

The full screen layout has one single scrolling area.

Responsiveness

The full screen layout offers considerable freedom and flexibility. However, you also need to make sure that the app is responsive or adaptive across devices. The content is not adjusted automatically as it is for the split-screen layout. Instead, you need to select the appropriate layout and controls, and make any necessary adjustments yourself.

Letterboxing means limiting the width of the content area to 1280 px. This prevents the app content from becoming too “stretched” on wide screens, and optimizes readability.

Examples

Reference App “Shop”

The product details screen of the reference app “Shop” shows how an app can make use of an object view floorplan in the full screen layout. This example highlights the responsive capabilities of the components used for an object view floorplan.

Resources

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

The list report floorplan allows the user to work with a large list of items and take action. This floorplan combines powerful functions for filtering large lists with different ways of displaying the resulting item list. You can only use the list report floorplan with the full screen layout.

Usage

Use the list report floorplan if:

• You need to display and filter large lists of items. The filter bar is very powerful and allows the user to handle large data sets with multiple filter mechanisms.
• You want to combine different visualizations for large data sets, such as graphics and tables.

Do not use the list report floorplan if:

• The users work primarily on a specific list of items. In this case, the focus lies on the action, and less on filtering, so you should use the worklist floorplan

Layout

Responsiveness

Currently, the controls used within the list report floorplan do not all adjust responsively across all devices. Depending on the controls you use, you may need to change your implementation for some devices. The level of multi-device support depends on the individual controls used in the floorplan. For details, see the guidelines for the individual controls.

• Filter bar  – supported on all devices.
• Icon tab bar  – supported on all devices.
• Responsive table, list – supported on all devices (use the responsive features).
• Analytical table, grid table  – supported on desktop and tablet devices only. On smartphones, replace it with the responsive table.
• Tree table – supported on desktop and tablet devices only. There is currently no direct alternative for smartphones. Only in some cases, the tree table could be replaced by a category navigation pattern on smart phone.
• Chart – supported on all devices.

List Report Floorplan with the Dynamic Page

Variant Management and Global Actions

The header title of the dynamic page contains the variant management and global actions. The header title displays up to 5 filter criteria if the header content is collapsed.

Snapping Header

The header content of the page has a snapping behavior. This includes the filter 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, a footer toolbar is available. This element appears on the bottom of the page content and contains closing or finalizing actions.

Filter Area

In the filter area, users specify the data that is displayed in the content area by:

• Using different filter criteria to reduce the number of items displayed.
• Selecting predefined filter sets (known as variants) to support different use cases.

These functions are offered by the filter bar, which is mandatory for any list report floorplan.

Please be aware that triggering a filter can take a while if the result set becomes very large. To improve performance in such cases, consider providing manadory filter fields and/ or default settings for filters. Both help to reduce the size of typical filter result sets.

The variant management functions allow users to define and manage predefined filter sets as well as predefined view settings for the lists, tables, trees, and charts. Users can set a default variant, and specify how the variant is executed:

• If Execute on Select is active, the variant is executed as soon as the user selects it (live update).
• If Execute on Select is not active, the user can modify the query, but has to execute the search manually to display the data (delayed update).

Variant management is optional.

The filter bar can be either expanded or collapsed when the list report floorplan is launched. The expanded view reveals the filter functionality and makes it clear that the user can filter directly on the list. However, it looks more complex than the collapsed view. The collapsed view is simple and user-friendly. However, users might not realize that they can change the content using multiple filters.

Users can expand or collapse the filter bar manually. In this case, the app should persist the status that the user has set.

Content Area

The content area is located on the lower part of the screen and contains the actual data. The data shown is determined by the settings in the filter area.

Content

There are various options for displaying large data sets, each of which has specific features and advantages. For more information, see the documentation for the individual control.

• List (sap.m.List)
• Table (sap.m.Table)
• Grid Table (sap.ui.table.Table)
• Analytical table (sap.ui.table.AnalyticalTable)
• Tree table (sap.ui.table.TreeTable)
• Smart Table (sap.ui.comp.smarttable.SmartTable)
• Charts (sap.viz.ui5.controls.VizFrame)

Toolbar

The different content controls allow you to incorporate toolbars in different ways. The details are covered in the guidelines for the respective toolbars. This section only covers the specifics for the list report floorplan.

In the simplest case, the toolbar contains only basic table functionality, such as the table title (optionally with count), sorting, grouping, and table personalization.

In addition to the basic list, you can provide alternative visualizations, such as a table or a chart. You can also offer these two functions in the toolbar, including combined visualizations, such as a chart together with a table.

Users can store personalized table settings in a layout variant, which is also available on the table toolbar. If so, do not store the table settings in the filter variant.

Use this only in rare cases. In most cases it is sufficient to use the variant management on the filter bar for storing the filter settings and the layout settings of the table.

You can extend the toolbar to offer additional contextual actions. These actions can be selection-dependent (enabled only if an item is selected) or selection-independent (always enabled, even without item selection).

Simple Content (Default)

In most cases, the content is displayed in a single list or table, with a title toolbar at the top. The title toolbar has a specific style (transparent background), and uses one of the content variants described above.

Multiple Views

In many cases, you will want to offer multiple predefined views on the data in the content area. Such views represent certain filter criteria, or some other fundamental differentiation between the items displayed in the content (for example, open items, items in process, and closed items). There are two ways to let users select these views directly:

• For two to three views, use a segmented button .
• For more than three views, or if the number of views can change, use the select control .

For the filter bar also influences the result set shown in the table, avoid repeating filter criteria in the views. If the criterion that determines the view is also a filter criterion, you might run into dependencies that are difficult to resolve. For example, if you have a Status filter in the filter bar, and a view switch with the views Open, In Process, and Closed, both refer to the same property.

If you use a content switch, you no longer need a title. In very rare use cases, both a title and a content switch must be visible. In this case, the title and the content view are left-aligned.

Switching between views can affect how the content is visualized:

• For charts, switching views can affect the visualization. This can be the case if there is a better way to represent the data for a specific view (for example, view by country, view by customer).
• For tables, the different views do not affect how the content is visualized. They only change the content or items displayed (filter on the content). Table columns and sort settings are not affected by switching views.

Multiple Contents

A list report can contain multiple lists or tables in parallel. The same filter criteria are applied across all tables. For example, if the user filters for specific customers and dates, a customer overview report would show only matching invoices, deliveries, and overdue payments.

To facilitate navigation, you can show each table on a separate tab in the icon tab bar.

Guidelines:

• For the list report floorplan, use the text-only version of the icon tab bar.
• By default, populate the count attribute with the number of items shown in the respective table.
• Use the same name for the tab and the table title.
• You can add a toolbar for  table functions. Follow the rules described above for the toolbar.

“No Data” Texts

If the content area is empty, use a placeholder text to tell the user why. To assign a placeholder text, set the “noDataText” attribute.

Typical use cases and placeholder texts:

• The user has started the app, but not applied any filters.
  Text: “No items selected. To start, enter your selection criteria and run the search.”
• The user has executed the filter, but no items were found.
  Text: “No results found. Try adjusting your search and filter settings.”
• The user has opened a related app. The filter criteria are transferred automatically, but no items are found in the related app.
  Text: “No items selected. Check the search and filter settings.”

Dependencies Between Areas

The filter and content areas must be synchronized at all times. In other words, the filters in the filter bar must always describe the items that are shown in the content area.

Updating the Content Area

The filter bar supports two update modes:

• Live update (default): The user changes a filter criterion, and the content is updated immediately. The results table is updated every time the user changes a filter field or the search field. Therefore, a Go button is not necessary and is not shown if the live update mode is used. Also, the search is triggered with every letter that is entered. Starting with the first letter typed in, the table is updated with the results that match all set filters, including the search term.
  The live update mode fits for most use cases and should be used as a default.

• Manual update: The user changes a filter criterion first and then presses the Go button to apply the filter and update the content. In this case, a Go button is mandatory. If a search field is used, it is only triggered by the Go button and not instantly.

The manual update mode is necessary to reduce load on the back-end systems. In live update mode, the app has to query the back end for every filter change.

In the manual update mode, indicate that the content is not yet updated by graying out the content area (showOverlay = true). As soon as the user triggers the update by selecting Go in the filter bar, set the content area to “busy” (busy = true) until the new data has been retrieved. This will switch the control to busy state.

Filter Bar and Table Filter

Since the filters in the filter bar and the filter option in the table can contain confusing or even contradictory entries, you must deactivate the filter option in the table.

Basic Search Field and Table Search

The filter bar determines the content of the report. This filter configuration can also be persisted and shared with other users (variant management).

The search field is optional. If used, it is shown next to the variant management in the fitler bar. Every search is executed against the back end and in combination with the set filters.

The report results are now reduced to only those items that contain the search string and match all set filters.

Actions

Users should also be able to trigger actions on the list report floorplan. Apps can offer four types of action: global actions, table actions, line item actions, and finalizing actions.

1. Global Actions

If the user wants to execute actions that affect the entire page, these actions can be placed in the page header section of the page (1).

The global actions do also contain the Share button. Show it only, if you really need it. In other cases, remove the Share button.

2. Table Actions

To allow users to change the content of a table, you can offer actions in the table toolbar (2). The scope of these actions depends on the items selected (no item selected, a single item selected, multiple items selected). If an action applies to specific items, the user has to first select the item or items, and then the action from the toolbar. Examples of such actions include:

• Adding/removing items
• Editing one or multiple items
• Triggering an object function for one or multiple items
• Changing the status of one or multiple items

Disable actions, which can currently not be used (e.g. for no items are selected).

3. Line Item Actions

In rare cases it can make sense to let the user trigger specific, frequent tasks directly from the item (3). In this case, you can embed a button into a line item. Such actions can be offered alongside corresponding table actions or global actions. Examples of line item actions include:

• Starting/stopping a batch job
• Approving an item
• Assigning an item

4. Finalizing Actions

Finalizing actions execute the end of a process that affect the entire page. These actions can be placed in the footer toolbar section of the page (4).

For example:

• Save
• Cancel
• Submit

Navigation

In most cases, users can navigate to the detail view for each line item in the report. In cases where reports display data aggregates, the user might also want to drill into the details for the aggregated amount.

Line Item Navigation

At line item level, navigation to the item details depends on the control that is being used to display the data. In most cases, users navigate to the details either by selecting the table line (list, responsive table), or by selecting the identifier of the line item (grid table, analytical table, tree table). For more details on the navigation behavior, see the guideline for the respective control.

Drilldown Navigation

If a report displays aggregated amounts, the user might want to drill down into the individual items. In this case, we recommend to display the aggregate values as links. Clicking the link takes the user to another report showing the individual figures. Use the possibilities of the link to provide different levels of highlight in cases where the table contains many columns with links.

In charts, offer the drilldown navigation link in the popover for the chart element.

Cross Navigation

Reports – especially tables – can contain cross-references to other entities, such as people or business objects. Show references to other entities in a popover. Typically, the popover displays basic details of the referenced object and a navigation link to another page or another app that shows the object details.

Visual Design

For your convenience, we have integrated the visual design specifications for the list report floorplan.

Resources

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

The list report floorplan allows the user to work with a large list of items and take action. This floorplan combines powerful functions for filtering large lists with different ways of displaying the resulting item list. You can only use the list report floorplan with the full screen layout.

Usage

Use the list report floorplan if:

• You need to display and filter large lists of items. The filter bar is very powerful and allows the user to handle large data sets with multiple filter mechanisms.
• You want to combine different visualizations for large data sets, such as graphics and tables.

Do not use the list report floorplan if:

• The users work primarily on a specific list of items. In this case, the focus lies on the action, and less on filtering, so you should use the worklist floorplan

Layout

Responsiveness

Currently, the controls used within the list report floorplan do not all adjust responsively across all devices. Depending on the controls you use, you may need to change your implementation for some devices. The level of multi-device support depends on the individual controls used in the floorplan. For details, see the guidelines for the individual controls.

• Filter bar  – supported on all devices.
• Icon tab bar  – supported on all devices.
• Responsive table, list – supported on all devices (use the responsive features).
• Analytical table, grid table  – supported on desktop and tablet devices only. On smartphones, replace it with the responsive table.
• Tree table – supported on desktop and tablet devices only. There is currently no direct alternative for smartphones. Only in some cases, the tree table could be replaced by a category navigation pattern on smart phone.
• Chart – supported on all devices.

List Report Floorplan with the Dynamic Page

Variant Management & Global Actions

The header title of the dynamic page provides a variant management and the global actions. The header title displays up to five filter criteria if the header content is collapsed.

Snapping Header

The header content of the page gets a snapping behavior. This includes the filter 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 closing or finalizing actions.

Filter Area

In the filter area, users specify the data that is displayed in the content area by:

• Using different filter criteria to reduce the number of items displayed.
• Selecting predefined filter sets (known as variants) to support different use cases.

These functions are offered by the filter bar, which is mandatory for any list report floorplan.

Please be aware that triggering a filter can take a while if the result set becomes very large. To improve performance in such cases, consider providing manadory filter fields and/ or default settings for filters. Both help to reduce the size of typical filter result sets.

The variant management functions allow users to define and manage predefined filter sets as well as predefined view settings for the lists, tables, trees, and charts. Users can set a default variant, and specify how the variant is executed:

• If Execute on Select is active, the variant is executed as soon as the user selects it (live update).
• If Execute on Select is not active, the user can modify the query, but has to execute the search manually to display the data (delayed update).

Variant management is optional.

The filter bar can be either expanded or collapsed when the list report floorplan is launched. The expanded view reveals the filter functionality and makes it clear that the user can filter directly on the list. However, it looks more complex than the collapsed view. The collapsed view is simple and user-friendly. However, users might not realize that they can change the content using multiple filters.

Users can expand or collapse the filter bar manually. In this case, the app should persist the status that the user has set.

Content Area

The content area is located on the lower part of the screen and contains the actual data. The data shown is determined by the settings in the filter area.

Content

There are various options for displaying large data sets, each of which has specific features and advantages. For more information, see the documentation for the individual control.

• List (sap.m.List)
• Table (sap.m.Table)
• Grid Table (sap.ui.table.Table)
• Analytical table (sap.ui.table.AnalyticalTable)
• Tree table (sap.ui.table.TreeTable)
• Smart Table (sap.ui.comp.smarttable.SmartTable)
• Charts (sap.viz.ui5.controls.VizFrame)

Toolbar

The different content controls allow you to incorporate toolbars in different ways. The details are covered in the guidelines for the respective toolbars. This section only covers the specifics for the list report floorplan.

In the simplest case, the toolbar contains only basic table functionality, such as the table title (optionally with count), sorting, grouping, and table personalization.

In addition to the basic list, you can provide alternative visualizations, such as a table or a chart. You can also offer these two functions in the toolbar, including combined visualizations, such as a chart together with a table.

Users can store personalized table settings in a layout variant, which is also available on the table toolbar. If so, do not store the table settings in the filter variant.

Use this only in rare cases. In most cases it is sufficient to use the variant management on the filter bar for storing the filter settings and the layout settings of the table.

You can extend the toolbar to offer additional contextual actions. These actions can be selection-dependent (enabled only if an item is selected) or selection-independent (always enabled, even without item selection).

Simple Content (Default)

In most cases, the content is displayed in a single list or table, with a title toolbar at the top. The title toolbar has a specific style (transparent background), and uses one of the content variants described above.

Multiple Views

In many cases, you will want to offer multiple predefined views on the data in the content area. Such views represent certain filter criteria, or some other fundamental differentiation between the items displayed in the content (for example, open items, items in process, and closed items). There are two ways to let users select these views directly:

• For two to three views, use a segmented button .
• For more than three views, or if the number of views can change, use the select control .

For the filter bar also influences the result set shown in the table, avoid repeating filter criteria in the views. If the criterion that determines the view is also a filter criterion, you might run into dependencies that are difficult to resolve. For example, if you have a Status filter in the filter bar, and a view switch with the views Open, In Process, and Closed, both refer to the same property.

If you use a content switch, you no longer need a title. In very rare use cases, both a title and a content switch must be visible. In this case, the title and the content view are left-aligned.

Switching between views can affect how the content is visualized:

• For charts, switching views can affect the visualization. This can be the case if there is a better way to represent the data for a specific view (for example, view by country, view by customer).
• For tables, the different views do not affect how the content is visualized. They only change the content or items displayed (filter on the content). Table columns and sort settings are not affected by switching views.

Multiple Contents

A list report can contain multiple lists or tables in parallel. The same filter criteria are applied across all tables. For example, if the user filters for specific customers and dates, a customer overview report would show only matching invoices, deliveries, and overdue payments.

To facilitate navigation, you can show each table on a separate tab in the icon tab bar.

Guidelines:

• For the list report floorplan, use the text-only version of the icon tab bar.
• By default, populate the count attribute with the number of items shown in the respective table.
• Use the same name for the tab and the table title.
• You can add a toolbar for  table functions. Follow the rules described above for the toolbar.

“No Data” Texts

If the content area is empty, use a placeholder text to tell the user why. To assign a placeholder text, set the “noDataText” attribute.

Typical use cases and placeholder texts:

• The user has started the app, but not applied any filters.
  Text: “No items selected. To start, enter your selection criteria and run the search.”
• The user has executed the filter, but no items were found.
  Text: “No results found. Try adjusting your search and filter settings.”
• The user has opened a related app. The filter criteria are transferred automatically, but no items are found in the related app.
  Text: “No items selected. Check the search and filter settings.”

Dependencies Between Areas

The filter and content areas must be synchronized at all times. In other words, the filters in the filter bar must always describe the items that are shown in the content area.

Updating the Content Area

The filter bar supports two update modes:

• Live update (default): The user changes a filter criterion, and the content is updated immediately. The results table is updated every time the user changes a filter field or the search field. Therefore, a Go button is not necessary and is not shown if the live update mode is used. Also, the search is triggered with every letter that is entered. Starting with the first letter typed in, the table is updated with the results that match all set filters, including the search term.
  The live update mode fits for most use cases and should be used as a default.

• Manual update: The user changes a filter criterion first and then presses the Go button to apply the filter and update the content. In this case, a Go button is mandatory. If a search field is used, it is only triggered by the Go button and not instantly.

The manual update mode is necessary to reduce load on the back-end systems. In live update mode, the app has to query the back end for every filter change.

In the manual update mode, indicate that the content is not yet updated by graying out the content area (showOverlay = true). As soon as the user triggers the update by selecting Go in the filter bar, set the content area to “busy” (busy = true) until the new data has been retrieved. This will switch the control to busy state.

Filter Bar and Table Filter

Since the filters in the filter bar and the filter option in the table can contain confusing or even contradictory entries, you must deactivate the filter option in the table.

Basic Search Field and Table Search

The filter bar determines the content of the report. This filter configuration can also be persisted and shared with other users (variant management).

The search field is optional. If used, it is shown next to the variant management in the fitler bar. Every search is executed against the back end and in combination with the set filters.

The report results are now reduced to only those items that contain the search string and match all set filters.

Actions

Users should also be able to trigger actions on the list report floorplan. Apps can offer three types of action: table actions, line item actions, and global actions.

1. Table Actions

To allow users to change the content of a table, you can offer actions in the table toolbar (1). The scope of these actions depends on the items selected (no item selected, a single item selected, or multiple items selected). If an action applies to specific items, the user has to first select the item or items, and then the action from the toolbar. Examples of such actions include:

• Adding/removing items
• Editing one or multiple items
• Triggering an object function for one or multiple items
• Changing the status of one or multiple items

Disable actions that cannot be currently used (for example, when no items are selected).

2. Line Item Actions

In rare cases it makes sense to let the user trigger specific frequently-used tasks directly from the item. In this case, you can embed a button into a line item. Such actions can be offered alongside corresponding table actions or global actions. Examples of line item actions include:

• Starting/stopping a batch job
• Approving an item
• Assigning an item

3. Global Actions

If the user wants to execute actions that affect the entire page, these actions can be placed in the footer toolbar section of the page (3).

The global actions do also contain the Share button. Show it only if you really need it. If not, remove the Share button.

Navigation

In most cases, users can navigate to the detail view for each line item in the report. In cases where reports display data aggregates, the user might also want to drill into the details for the aggregated amount.

Line Item Navigation

At line item level, navigation to the item details depends on the control that is being used to display the data. In most cases, users navigate to the details either by selecting the table line (list, responsive table), or by selecting the identifier of the line item (grid table, analytical table, tree table). For more details on the navigation behavior, see the guideline for the respective control.

Drilldown Navigation

If a report displays aggregated amounts, the user might want to drill down into the individual items. In this case, we recommend to display the aggregate values as links. Clicking the link takes the user to another report showing the individual figures. Use the possibilities of the link to provide different levels of highlight in cases where the table contains many columns with links.

In charts, offer the drilldown navigation link in the popover for the chart element.

Cross Navigation

Reports – especially tables – can contain cross-references to other entities, such as people or business objects. Show references to other entities in a popover. Typically, the popover displays basic details of the referenced object and a navigation link to another page or another app that shows the object details.

Visual Design

For your convenience, we have integrated the visual design specifications for the list report floorplan.

Resources

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

The list report floorplan allows the user to work with a large list of items and take action. This floorplan combines powerful functions for filtering large lists with different ways of displaying the resulting item list. You can only use the list report floorplan with the full screen layout.

Usage

Use the list report floorplan if:

• You need to display and filter large lists of items. The filter bar is very powerful and allows the user to handle large data sets with multiple filter mechanisms.
• You want to combine different visualizations for large data sets, such as graphics and tables.

Do not use the list report floorplan if:

• The users work primarily on a specific list of items. In this case, the focus lies on the action, and less on filtering. Use the work list floorplan instead.

Layout

Responsiveness

Currently, the controls used within the list report floorplan do not all adjust responsively across all devices. Depending on the controls you implement, you may need to adapt them for some devices. The level of multi-device support depends on the individual controls used in the floorplan. For details, see the guidelines for the individual controls.

• Filter bar  – supported on all devices.
• Icon tab bar  – supported on all devices.
• Responsive table, list – supported on all devices (use the responsive features).
• Analytical table  – supported on desktop devices only. On tablets and smartphones, replace it with the responsive table.
• Tree table – supported on desktop devices only. There is currently no alternative for tablets and smartphones.
• Chart – supported on all devices.

Filter Area

In the filter area, users specify the data that is displayed in the content area by:

• Using different filter criteria to reduce the number of items displayed.
• Selecting predefined filter sets (known as variants) to support different use cases.

These functions are offered by the filter bar, which is mandatory for any list report floorplan.

The variant management functions allow users to define and manage predefined filter sets. They can set a default variant, and specify how the variant is executed:

• If Execute on Select is active, the variant is executed as soon as the user selects it (live update).
• If Execute on Select is not active, the user can modify the query, but has to execute the search manually to display the data (delayed update).

The list report floorplan can start with the filter bar expanded or collapsed:

• The expanded view reveals the filter functionality and makes it clear that the user can filter on the list. However, it looks more complex than the collapsed view.
• The collapsed view is simple and user-friendly. However, users might not realize that they can change the content using multiple filters.

Users can expand or collapse the filter bar manually. In this case, the app should persist the status the user has set. The persisted state should override the default state set by the app.

Content Area

The content area is located on the lower part of the screen and contains the actual data. The data shown is determined by the settings in the filter area.

Content

There are various options for displaying large data sets, each of which has specific features and advantages. For more information, see the documentation for the individual control.

• List (sap.m.List)
• Table (sap.m.Table)
• Grid Table (sap.ui.table.Table)
• Analytical table (sap.ui.table.AnalyticalTable)
• Tree table (sap.ui.table.TreeTable)
• Smart Table (sap.ui.comp.smarttable.SmartTable)
• Charts (sap.viz.ui5.controls.VizFrame)

Toolbar

The different content controls allow you to incorporate toolbars in different ways. The details are covered in the guidelines for the respective toolbars. This section only covers the specifics for the list report floorplan.

In the simplest case, the toolbar contains only basic table functionality, such as the table title (count), sorting, grouping, and table personalization.

In addition to the basic list, you can provide alternative visualizations, such as a table or a chart. You can also offer these two functions in the toolbar, including combined visualizations, such as a chart together with a table.

Users can store personalized table settings in a layout variant, which is also available on the table toolbar.

You can extend the toolbar to offer additional contextual actions. These actions can be selection-dependent (enabled only if an item is selected) or selection-independent (always enabled, even without item selection).

Simple Content (Default)

In most cases, the content is displayed in a single list or table, with a title toolbar at the top. The title toolbar has a specific style (transparent background), and uses one of the content variants described above.

Multiple Views

In many cases, you will want to offer multiple predefined views on the data in the content area. Such views represent certain filter criteria, or some other fundamental differentiation between the items displayed in the content (for example, open items, items in process, and closed items). There are two ways to let users select these views directly:

• For two to three views, use a segmented button .
• For more than three views, or if the number of views can change, use the select control .

For the filter bar also influences the result set shown in the table, avoid repeating filter criteria in the views. If the criterion that determines the view is also a filter criterion, you might run into dependencies that are difficult to resolve. For example, if you have a Status filter in the filter bar, and a view switch with the views Open, In Process, and Closed, both refer to the same property.

If you use a content switch, you no longer need a title. In very rare use cases, both a title and a content switch must be visible. In this case, the title and the content view are left-aligned.

Switching between views can affect how the content is visualized:

• For tables, the different views do not affect how the content is visualized. They only change the content or items displayed (filter on the content). Table columns and sort settings are not affected by switching views.
• For charts, switching views can affect the visualization. This can be the case if there is a better way to represent the data for a specific view (for example, view by country, view by customer).

Multiple Contents

A list report can contain multiple lists or tables in parallel. The same filter criteria are applied across all tables. For example, if the user filters for specific customers and dates, a customer overview report would show only matching invoices, deliveries, and overdue payments.

To facilitate navigation, you can show each table on a separate tab in the icon tab bar.

Guidelines:

• For the list report floorplan, use the text-only version of the icon tab bar.
• By default, populate the count attribute with the number of items shown in the respective table.
• Use the same name for the tab and the table title.
• You can add a toolbar for  table functions. Follow the rules described above for the toolbar.

“No Data” Texts

If the content area is empty, use a placeholder text to tell the user why. To assign a placeholder text, set the “noDataText” attribute.

Typical use cases and placeholder texts:

• The user has started the app, but not applied any filters.
  Text: “No items selected. To start, enter your selection criteria and run the search.”
• The user has executed the filter, but no items were found.
  Text: “No results found. Try adjusting your search and filter settings.”
• The user has opened a related app. The filter criteria are transferred automatically, but no items are found in the related app.
  Text: “No items selected. Check the search and filter settings.”

Dependencies Between Areas

The filter and content areas must be synchronized at all times. In other words, the filters in the filter bar must always describe the items that are shown in the content area.

Updating the Content Area

The filter bar supports two update modes:

• Live update (default): The user changes a filter criterion, and the content is updated immediately. The results table is updated every time the user changes a filter field or the search field. Therefore, a Go button is not necessary and is not shown if the live update mode is used. Also, the search is triggered with every letter that is entered. Starting with the first letter typed in, the table is updated with the results that match all set filters, including the search term.
  The live update mode fits for most use cases and should be used as a default.

• Manual update: The user changes a filter criterion first and then presses the Go button to apply the filter and update the content. In this case, a Go button is mandatory. If a search field is used, it is only triggered by the Go button and not instantly.

The manual update mode is necessary to reduce load on the back-end systems. In live update mode, the app has to query the back end for every filter change.

In the manual update mode, indicate that the content is not yet updated by graying out the content area (showOverlay = true). As soon as the user triggers the update by selecting Go in the filter bar, set the content area to “busy” (busy = true) until the new data has been retrieved. This will switch the control to busy state.

Filter Bar and Table Filter

Since the filters in the filter bar and the filter option in the table can contain confusing or even contradictory entries, you must deactivate the filter option in the table.

Basic Search Field and Table Search

The filter bar determines the content of the report. This filter configuration can also be persisted and shared with other users (variant management).

Since the search is not included in the filter bar (except within the smart filter bar), you must implement the search functionality in every app. Every search is executed against the back end and in combination with the set filters.

The report results are now reduced to only those items that contain the search string and match all set filters.

If the basic search field is used in the filter bar, you must deactivate the search field in the table.

Actions

Users should also be able to trigger actions on the list report floorplan. Apps can offer three types of action: table actions, line item actions, and global actions.

1. Table Actions

To allow users to change the content of a table, you can offer actions in the table toolbar (1). The scope of these actions depends on the items selected (no item selected, a single item selected, or multiple items selected). If an action applies to specific items, the user has to first select the item or items, and then the action from the toolbar. Examples of such actions include:

• Adding/removing items
• Editing one or multiple items
• Triggering an object function for one or multiple items
• Changing the status of one or multiple items

Disable actions that cannot be currently used (for example, when no items are selected).

2. Line Item Actions

In rare cases it makes sense to let the user trigger specific frequently-used tasks directly from the item. In this case, you can embed a button into a line item. Such actions can be offered alongside corresponding table actions or global actions. Examples of line item actions include:

• Starting/stopping a batch job
• Approving an item
• Assigning an item

3. Global Actions

If the user wants to execute actions that affect the entire page, these actions can be placed in the footer toolbar section of the page (3).

The global actions do also contain the Share button. Show it only if you really need it. If not, remove the Share button.

Navigation

In most cases, users can navigate to the detail view for each line item in the report. In cases where reports display data aggregates, the user might also want to drill into the details for the aggregated amount.

Line Item Navigation

At line item level, navigation to the item details depends on the control that is being used to display the data. In most cases, users navigate to the details either by selecting the table line (list, responsive table), or by selecting the identifier of the line item (grid table, analytical table, tree table). For more details on the navigation behavior, see the guideline for the respective control.

Drilldown Navigation

If a report displays aggregated amounts, the user might want to drill down into the individual items. In this case, we recommend to display the aggregate values as links. Clicking the link takes the user to another report showing the individual figures. Use the possibilities of the link to provide different levels of highlight in cases where the table contains many columns with links.

In charts, offer the drilldown navigation link in the popover for the chart element.

Cross Navigation

Reports – especially tables – can contain cross-references to other entities, such as people or business objects. Show references to other entities in a popover. Typically, the popover displays basic details of the referenced object and a navigation link to another page or another app that shows the object details.

Visual Design

For your convenience, we have integrated the visual design specifications for the list report floorplan.

Resources

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