The overview page (OVP) is a new data-driven SAP Fiori app that provides all the information a user needs in a single page, based on the user’s specific domain or role. It allows the user to focus on the most important tasks, enabling faster decision-making as well as immediate action.

The overview page employs cards (containers of content), which are based on smart template technology, and which act as a UI framework for organizing large amounts of information on an equal plane within the page. The overview page is created by a developer based on annotated views of app data (meaning that app content can be tailored to the domain or role). Information can be visualized in an attractive and efficient way using different types of cards.

In short, the overview page is a simple, one-stop, data-driven SAP Fiori app that gives a role all essential information. It allows the user to view, filter, and react to information quickly.

Use the overview page if:

• The user has a specific role and needs to filter and react to information stemming from a range of applications.
• The user needs to gather information from different sources that support a specific task focus or information need.
• You want to offer different information formats (such as charts, lists, and tables) on a single page for a specific domain or role.
• You want to organize and display a set of (filterable) data to provide an entry-level view of content related to a specific domain or role.

Do not use the overview page if:

• A high-level or birds-eye view of application content is sufficient.
• You want give access to all available SAP Fiori apps for all groups or domains.
• You want to add or delete applications. Instead, consider using the SAP Fiori launchpad home page.

The overview page in SAP Fiori functions like a typical SAP Fiori app. This means that you can start it by clicking a tile on the SAP Fiori launchpad home page, or by bookmarking the direct link to the overview page in your browser to access it directly as you would any other app. The figure below illustrates the complete interaction flow.

The entire SAP Fiori overview page floorplan is fully responsive and uses letterboxing. The flexible “easy scan” layout can accommodate typical laptop screens as well as larger desktop monitors, and features responsive (collapsible) “columns” of cards that can scale all the way down to tablet or phone screen sizes. The columns are of equal width and contain the cards in the following layout sizes:

• Small: one column
• Medium: two columns
• Large: three columns
• Extended: four to five columns for large desktop screen resolutions (maximum five columns)

The width of the cards changes depending on the screen size being used: either 20 or 25 rem is displayed. This process starts automatically and saves the responsiveness and readability of the cards to each device. This flexible width behavior applies to all card types.

The overview page consists of the following components:

• Overview page header
• Smart filter bar
• Content area with cards

These are described in more detail below.

Components

Overview Page Header

The overview page uses the object page header for a page header. The header is the uppermost element in the floorplan. Its purpose is to provide the user with context and relevant information about the page it represents. The information allowed in the object page header of an overview page is limited to a title, subtitle (optional), and an icon button used to open the smart filter bar.

Smart Filter Bar

The smart filter bar  is used “as is”, meaning that for the overview page, all existing functions and behaviors of the current UI5 control are available, including variant management. The smart filter bar filters all the content on the page and in the data base. A notable exception is that the smart filter bar is not visible when the page is first loaded; the user must select the filter icon from the object header to cause the smart filter bar to appear on the page. On a desktop, once the smart filter bar has been invoked, it is always displayed in extended mode. On mobile devices, once it has been invoked, the smart filter bar is always displayed as collapsed.

Content Area of the Overview Page

The content area contains responsive (collapsible) columns of cards. The content area of the overview page features what is referred to as the “easy scan” layout. Note that you cannot place tiles in the content area on the overview page. Like an operating system’s home screen, the home screen only offers access to apps, but no further functionality for keeping the home page clean and usable. The overview page contains cards but no tiles. Cards have more than one interaction area and might even offer actions, thus making them much richer than tiles. Apps can be launched from an overview page through the header area of a card that is related to the specific app.

Cards

Cards, which are entirely new for the overview page, are containers of application content. A card is a smart component that uses UI annotation to render its content, and is bound to a single data source. Cards differ in the content they display. They can show a chart, a list of items, a table, informative text, or a combination of two elements. For example, an analytical card may show a KPI header and a chart.

Cards used for the “easy scan” layout always have a uniform horizontal width, but may vary in their vertical dimension based on the card type.

The vertical size (height) is determined by the card type and the embedded control.

Card Components

Every card comprises three components: a header area, a content area, and a footer area. The header and content areas are mandatory. In some cases, the footer area is not needed (such as for the stack or analytical cards) and is therefore optional.

Content Area of Cards

The content area is mandatory and reserved for application content. Content is currently displayed in a card by embedding a UI5 control that specifies the properties and data format to be displayed. For example, an embedded UI5 standard list control provides formatting (such as row height, font sizes, and number of text blocks).

Footer Area

The footer area has a fixed height. It is also optional as, in some cases, a footer area is not needed (such as for stack or analytical cards). It serves two purposes:

1. For cards that display information about a single object or data point, the footer area is used to display actions associated to the content of the card. This only applies to the quick view card. For more information, see the section on Behavior and Interaction in this article.
2. For cards that display links to a group of multiple objects (such as list or table cards), the footer is informational and contains no actions. It provides a summary text label which describes how many items are shown on the card in respect to all items returned for the particular annotated view. For example: Showing 3 of 10. If there aren’t any items, the following text should be displayed: No items found.

Card Types

Single-Object Cards

Cards that feature content with a single focal point, detail, or entity are called single-object cards. An example is a business card with information about a particular contact. The quick view card and the analytical card are single-object cards.

Object Group Cards

Cards that feature a subset of items grouped together by relation to a common topic are called object group cards. A typical example would be a list of sales orders grouped by amount, status, or most recent status. They do not have actions, but are designed in such a way that each row or list item is selectable, thus providing direct navigation to the detailed object within the parent application. Object group cards include all types of list cards and table cards.

Analytical cards are used for data visualization. They are single-object cards that consist of two areas: a header area that displays the aggregated value of a key measure (KPI), and a chart area that displays a representation of data in graphical format.

The KPI header includes the title and a subtitle. The headline is replaced by the KPI with the respective unit, which can be shown using semantic colors. An optional percentage indicator and a triangle indicator (showing an upward or a downward trend) can also be displayed. The optional subtitle can show the filter criteria used for the chart, and can contain up to two lines of text.

Currently, the VizFrame line chart, bubble chart, and donut chart without a footer area are available for use on the overview page.

For more information, see analytical card.

List cards are a type of object group card, and display a set of items in a vertical list. The list card uses the sap.m.List container in the content area. Clicking the header area of a list card opens the parent application, which uses the same filter as the annotated card, and shows a list of all the returned ResultSet objects. Clicking on a list item (row) on the card opens the detail view for that specific item in the same parent application.

Two different line item types are available: “condensed list item” and “extended list item”. However, you can only use one type of list item on any given card. The condensed list item shows minimal information – two lines of text and a number – and contains the same properties as the SAPUI5 control sap.m.StandardListItem. The extended list item displays more information – three lines of text and three numbers – and contains the same properties as the SAPUI5 control sap.m.ObjectListItem.

Size

The size of list cards displaying multiple objects adjusts depending on the amount content available. The height can vary depending on the number of text fields. However, there are rules for the fixed number of list items: You should show no more than 5 condensed list items and no more than 3 extended list items in one list card. The user should expect to navigate to the full app to see a list of all possible items or the result set.

The bar chart list card adds a chart component to a list. You can embed a progress indicator in either a condensed or extended list format.

Table cards are a type of object group card, and display a set of items in a table format. Table cards use the responsive SAPUI5 control sap.m.Table. Clicking on the header area of a table card  opens the parent application with the same filter applied as for the annotated card with access to a table of all the returned ResultSet objects. In contrast, clicking on a table row inside the card opens that specific object detail screen within an app. The card limit the width of the table to three columns and no row should display more than three lines of text The first and second column show a data field and the last column a data point. The height of the card reflects its content. If one or more items are returned, show the items in the footer area with a summary text “Showing x of x”.

Size

The size of list cards displaying multiple objects adjusts depending on the amount content available. The height can vary depending on the number of text fields. However, there are rules for the fixed number of list items: You should show no more than 5 condensed list items and no more than 3 extended list items in one list card. The user should expect to navigate to the full app to see a list of all possible items or the result set.

If no items are found, the card should only display the header and footer information. The only selectable area would be the header for navigation to the corresponding app.

If one or more items are returned, show the items in the list/table format with a footer area for summary text. The height of the card depends on the amount of content.

Stack Card

Behavior and Interaction

The layout of the overview page consists a scrollable page of cards for each device, making it easy to scan through quickly.

Actions on Cards

Only quick view cards can have actions in the footer area (inside the object stream). The order of actions assigned and displayed on a card should be determined by the app’s owner. “Primary” and “secondary” actions are possible.

A primary action appears on the left side of the footer area. If more than one action is to be displayed, the additional action moves into the overflow and is described as a secondary action. The three dots (…) represent the overflow action icon. This icon is used as a place to consolidate all other actions except the primary action. Clicking on the overflow invokes the appearance of an action sheet, which is displayed on top of the card’s surface with the list of secondary actions. Clicking on an action starts it and dismisses the action sheet. A maximum of five secondary actions are allowed in the overflow (although we recommend permitting a maximum of three secondary actions here). Including the primary action, you can therefore display up to six actions.

There are two possible types of action: navigation and function import. Any combination of navigation and function import actions should be allowed. The order of actions assigned to a card should be determined by the app’s owner. Any error messaging or confirmation toasts would be displayed directly on the overview page.

Navigate

Navigation is “intent-based” and takes the user to a different SAP Fiori app that specializes in executing an action. Navigation actions are always multiple-click (meaning that they can be repeated over and over). If we take the example of an SAP Fiori detail view that supports operations for the intended action, the intended destination screen would open in the same browser window, and any errors or task confirmation toast messages would be handled by the supporting application, not the overview page. If another application is open, the object stream should remain as is until the user returns to the overview page.

Import Function

The import function is a term to describe how actions are named in OData. It has two purposes:

1. An action requires some input parameters. These would be handled on the overview page screen without further navigation. When an action choice is made (through user selection), the card should change to a dialog, and the input or selection action can be carried out.
2. An action can have no parameters, and in such a case, the action request is sent immediately. Once the action has been completed, the card disappears from the object stream.

Action on Phone

Action behavior on a phone is very similar to that on a desktop or tablet. The main difference is that whenever an action on a card requires an input dialog box, the default option should be to use a full screen version for the phone’s form factor.

Resources