This series of blogs discusses aspects of SAP’s latest iteration of the SAP Fiori design language: SAP Fiori 2.0. In this article, I will discuss the idea of the overview page in the context of the SAP Fiori environment, and how it can be used to bundle information and functionality centered around one task context for a specific user role. This new floorplan has been introduced with SAPUI5 version 1.32 (http://scn.sap.com/docs/DOC-68528).

This article will not touch on the implementation aspects of the overview page, but will purely focus on the design and motivation. It will give ideas on why we took certain design decisions, as well as what are the things we are planning to change.

What is the Overview Page?

When we started with SAP Fiori, our goal was to provide highly focused and simple apps for the most frequently-encountered use cases. Initially, SAP Fiori comprised 25 of such rather simple apps that were mainly independent. Many of them targeted different roles and had hardly any overlap or cross-navigation. Within the first releases of SAP Fiori, this picture changed drastically, and within a year’s time the portfolio grew to several hundred apps that could often be recombined into longer process flows where the user could navigate from app to app carrying over context.

The initial SAP Fiori Launchpage with a very limited set of applications

With a larger number of applications, SAP Fiori now became more capable of covering entire business flows. The interdependency between the apps increased. Users now started to use several apps that addressed different aspects of the same task. We started to see a need to bundle apps and information around specific tasks or areas of responsibility in one place, and at the same time provide richer interaction and information possibilities on that level.

To achieve this, we evaluated two main options:

1. Widgets – Enhance the homepage with richer content elements that allow us to show things such as “top n items”, interactive charts, actionable content, and more, in a way that’s similar to the widgets in the Android home screens.
2. Overview Page – Introduce an additional layer of information or a separate page type that bundles information and functions around a specific task, and which allows the user to navigate away from the home page.

We ran these options through most of our stakeholders as we felt this was an important decision that we needed to take jointly. We also opened the discussion up to collect additional ideas, which we then evaluated. After several workshops, we came to the joint conclusion that the overview page was the most promising approach:

• Using a separate page to focus on a task area would allow us more options to provide rich content and functionality than any transitional layer or integration into other pages.
• A separate page could also be used as alternative entry page by the user. A user could directly bookmark it and navigate to it directly, or package it for mobile or offline usage.
• An overview page could be represented as a tile on the home page and de facto work as a folder binding together multiple apps, therefore reducing the amount of individual apps on the home page itself.
• Using widgets on the home page would provide more possibilities on the home page, but it would also increase visual complexity, personalization, and performance of that page.

As a result of that discussion, we decided to introduce the overview page as a page type that aggregates and collects multiple apps, thereby creating an intermediate step between the home page and the applications.

The overview page can be used to gather all information for a specific task group. This also allows the user to reduce the number of tiles on the home page

Design Choices

What do we want this overview to be? The overview page should serve as a place where detailed or aggregated information from different apps could be displayed in one context. It should act as an intermediate dashboard where the user can get an overview of a certain domain or task set. From here, the user should be able to navigate into the apps to see more details and to take action. Ideally, we would be able to offer quick actions as well so that the user is able to complete tasks without navigating away from the overview page.

These ideas ended up as a list of the following high-level requirements (in addition to the overarching design principles of SAP Fiori, one of which is the requirement for responsiveness and usage across devices):

• Provide one context
• Display individual items
• Display collections of item
• Display aggregates (in different visualizations)
• Navigate to items
• Navigate to apps (or lists)
• Provide small actions
• Allow personalized arrangements

We evaluated several options for page layouts that would allow us to flexibly structure this page, with everything ranging from a card-based newspaper layout, to a freely resizable grid-based layout, and a row-based layout.

Different layout options for the overview page: newspaper, grid, flow-layout

While we clearly saw the need for a layout that supports information components of variable sizes (as this is supported by the grid-based layout), we decided to start with the column-based card layout as this promised most flexibility with the least technical side effects.

The card-based layout would allow us to invest into the design of different individual card types to support different content requirements such as displaying individual items, lists, or aggregates. The dimensions of cards are limited so that we could make sure an overview page would also run on a smartphone without issues. A column-based layout would be easy to manage without running into issues with white spaces.

Cards

The design metaphor of a card is something that became popular with Google Now or Pinterest. The idea is to have independent and focused information modules. As opposed to tiles with one-click interaction as we use them on the home page, cards can have multiple interaction areas and even actions. The form factor of these cards usually fits on the screen of a smartphone or can be smaller. The content of different cards can be diverse as long as there is a common basic structure.

This way, content diversity doesn’t conflict with the user’s ability to discover and scan. The content should nevertheless remain sufficiently simple so that a page full of cards doesn’t get too busy and complex. Cards can be delivered to the user standalone or as part of a page context.

Cards in the SAP Fiori overview page usually have three interaction areas:

1. Header area – Identifies the card and allows the user to navigate to the app information. In the card, it represents a filtered list. Selecting the header navigates the user to the app with this filter still applied.
2. Content area – Contains the information payload, such as attributes, list items, or an analytical visualization such as a chart. Selecting an item in a list will navigate to that item.
3. Footer area – Displays secondary information such as the total size of the data set beyond that which is visible, as well as actions.

Basic structure of a card in the overview page with three main areas: header, content, and footer

Imagining the cards as self-contained information modules that can be arranged on a page seemed to be a perfect metaphor for the overview page. To support the different information requirements identified above, we were able to design dedicated cards that could best represent these different information types.

	Object Card The object card displays information about a single item. This is similar to the quick view contents both in scope as well as in behavior. Usually, this will contain attributes of the object and it will provide access to actions for the corresponding object. Selecting the header opens the app to display the full object context. This card should be used to display information about an object of permanent interest in the given context. As the current concept doesn’t support personalization beyond the selection predefined contents – meaning the user can’t place additional objects here other than those that have been predefined – there are only few examples of where this applies.
	Table Card The table card displays information about multiple objects in a tabular structure. The amount of columns is limited to three in order to reduce the risk of truncation. The limited width of the card further restricts the amount of content that can be displayed. Selecting a line brings the user to the corresponding item. This card can be used to list numeric or status attributes of a limited number of items. Here, you should avoid having long text strings or text strings of varying length. This, of course, is not a replacement of an accounting table, but merely provides a preview of the underlying data. It is crucial to identify the right set of items to be displayed here.
	List Card The list card displays a list of items and some of the key attribute of those items. This can be used for few but longer attributes, or for attributes of varying length. A typical use case are named items such as products with some additional meta data. With the bar chart list card, the list card is enhanced with an additional bar below the content visualizing one numeric value as a bar in one color, or using semantic colors.
	Analytical Card The analytical card displays a key figure and a more detailed visualization of aggregated data points in various charts, including: Donut chart Line chart Bubble chart Column chart Stacked column chart Vertical bullet chart The analytical card should be used to visualize analytical information in a highly condensed manner. Using several analytical cards, the overview page can be used to create a dashboard that navigates to transactional data or to other analytical apps.

Link Card

The link card as list with icons, images and as carousel with images

The link card is a special card type that displays a set of links either as list or in a carousel with images. This can be used to reference items or links to applications in the overview page. This way, the overview page can be used as a navigation hub to various applications in a domain.

Currently, these links are provided as part of the application data services and follow the application lifecycle. However, we are currently evaluating the possibility of offering such links out of the content configuration lifecycle using the same content configuration as the role catalogues.

Stacked Card

Finally, the stacked card is used to visualize a stack of instances. These instance cards unfold into a so-called object stream in an overlay, offering the possibility of quick actions at instance level.

While this idea may have sounded convincing and intuitive at first, user testing revealed that this concept is generally not well understood by the users. The main issues are the uncertainty about the total numbers of items (as a stack only shows a subset of the total items matching the stack criteria, otherwise the object stream would become too crowded), and the advantage of the progressive disclosure (which was seen to have limited value), while the overlay was perceived as disruptive. Testing revealed that a navigation to a list would have been preferred. Therefore, we are currently re-evaluating and redesigning this to make it easier to use and more efficient.

Further card types are in planning and there are constant efforts to improve and optimize the cards with regards to consistency and enhancements of useful features.

Context

The cards are perfect way to offer content in a way that is not only easy to digest, but which is also rich enough to inform the user’s further actions or to even take action directly on the card. However, while the overview page represents content stemming from one domain or a single bundle of related tasks, there might be further dimensions by which a domain might be segmented.

Let’s take the example of a Material Planner who uses an overview page that provides an overview of the different aspects of the material stock. If this user is only interested in a certain material group, he or she should be able to narrow down the scope of the overview page to that material group. Also, the user might only be responsible for certain factories or warehouses and needs to be able to restrict the perspective to this scope.

The overview page for a purchaser. On top of the page, the filter area offers two filter options: Time and Supplier.

Using the filter, the context for the overview page has been set to suppliers that start with “t”. All cards react to this filter by showing just the data that is related to suppliers starting with “t”.

To allow this, we have introduced a filter on top of the overview page by which the user can define the scope of the overview page. Similar to the list page, this filter can contain several filter criteria which can be applied to restrict the contents of the overview page. The user can define variants to easily switch between different filter sets.

By setting this context, all cards should react and reduce the scope of their content to the defined scope. This means that, in the case of the Material Planner, all cards should only show the data for the selected material group for specific factories or warehouses.

Using the established “send to home” feature for variants, the user can easily create a selection of differently scoped overview pages and add this to the home page as tiles.

Though currently not possible, we are also exploring ways to allow the selection on one card to influence the content of other cards. This might be useful if one of the cards is a data visualization such as a chart or map where individual data points can be selected. In this case, we would like to avoid controlling the dependencies by linking individual cards. Instead, we would foresee that this master card controls the context and through selection sets the context to which the other cards then would need to react.

Personalization

The personalization of the overview page resembles the personalization of the home page. Users can rearrange cards using drag and drop. New cards can be selected from a set of available cards, and visible cards can be hidden using a simple personalization dialog. This allows each user to decide which information should be displayed, and how it should be arranged.

Currently, users cannot add contents to the overview page that haven’t been defined at design time. Therefore, it is not possible to drag a tile on an overview page or add it from the catalog as is the case with the home page currently. This is intentional as the overview page is hard-coded as an application and has a different lifecycle than the content of the launchpad. However, we are also exploring other options to see if content from the overview page could also be combined with other content, and if this content could be used in other places.

Using the filters and the variants, the user can define different scopes or contexts for overview pages and save them as variants. These variants can be referenced and referenced as tiles from the home page.

In the current column-based layout, cards cannot be resized. However, as we are working on other layouts such as the grid layout, we are also exploring the possibility of allowing the user to resize different cards.

Designing Overview Pages

Currently, overview pages are implemented as SAP Fiori Elements (aka smart templates) using OData annotations. The user interface is therefore entirely driven through the data that is loaded into the application. This means that the decisions that you have to take designing an overview page are primarily content decisions. You only have to choose the right card type and the right content elements.

What are the things you have to take care of when designing the content of an overview page?

• Make sure that the content is centered around one domain or one set of tasks. Cards on the overview page should belong together and fit within a single context. Overview pages should not be used to collect arbitrary content.
• The tasks that an overview page supports can also be seasonal in nature. For instance, there could be an overview page just supporting the performance management process that takes place in some companies only once a year.
• The user enters an overview page to get an overview of a domain or a set of tasks. The user will be looking to either take action or to get an idea of the required parts of the domain. In most cases, the user will navigate from the overview page into applications where the actual work takes place. Therefore, the overview page is a central hub in the navigation into a domain, and you should make sure to support this use.
• In general, there are different types of use cases that can be supported with the current overview page. Each of these different use cases requires a different mix of analytical data, contents and navigation:
  • Dashboard: The user needs an overview of various key figures and analytical visualizations, and continues on to deeper analytics in dedicated applications (analytical cards).
  • Monitor: The user tracks the status of multiple items and key figures to take action where required (list cards, analytical cards, stacked cards).
  • Work list: The user tracks the contents of one or several lists of actionable items and takes action (list cards, analytical cards).
  • Navigation hub: The user needs the overview page to locate the appropriate apps with which the user can actually work. Cards can be used to structure apps of one domain (link cards). Caution: Being an application, the overview page contents are defined at design time. Currently we do not support cards that can consume configuration or role content).
• Display the correct information on the cards. Are the relevant attributes being shown? Have you chosen an appropriate visualization for the data?
• Think about the way you structure the content. Should dimensions be comparable in different cards on the screen (if used in parallel), or is it a context dimension that should be accessible through the filter (if used exclusively)?
• Users should be able to personalize the content. Think about the information superset. This will allow the user to hide unnecessary information. The user will not be able to add contents that you haven’t foreseen.

The overview page is an extremely flexible and powerful page type. We are continuously working on enhancing it. We’re also aiming to provide additional layout options, such as the grid layout.

While we are doing our best to design cards and contents that support as wide a range of use cases as possible, we realize that we will never be able to cover all of them. Therefore, it might also be a valid option to take the idea of an overview page as a hub or entry point to a domain, but to use different approaches to structure the content.

Example use case: There might be a domain that consists of multiple phases (for example, marketing), where it makes sense to show to the user what apps should be used in what step. This could be supported with a visualization of that process including the corresponding applications and probably the supporting analytics. This is nothing we offer with the off-the-shelf overview page, but it theoretically could be built as a free-style application and used in the same way as an overview page.

It’s important to understand that most design concepts have two levels:

1. The role this concept plays in the overall design environment or in the information architecture of the design system;
2. The concrete design of an artifact that can fill this role (and its implementation).

With SAP Fiori, the home page of the Fiori launchpad is the home of the user and it should be the one home for the user. The application on the other hand represents the concrete task or use case. In between those two resides the place that represents a domain or bundle of tasks, and the overview page is one instance for that.

• Home page –> User
• Overview page –> Domain, task bundle
• Application –> Task

There could be other instantiations of that concept representing a specific domain with very specific requirements. Applications can therefore also provide these overview pages on their own following a different design than the overview page concept presented here.

One example would be the project overview app (https://boma0d717969.hana.ondemand.com/sap/fix/externalViewer/#/detail/Apps(‘F0720’)) that shows an overview list of key figures for all projects that a project manager is responsible for. In this case, there is only one object type in focus, making the card metaphor less useful. This app follows an approach similar to a list page. In the information architecture of this role, such a page nevertheless plays the role of an overview page.

In short: the overview page is not the only floorplan or page type that can play the role of a domain overview for a user.

Take Aways

The overview page offers you a way to design places where the user can get an overview of a domain or of a set of tasks. With that, the overview page fills an important gap in the information architecture of the SAP Fiori design language and can help to guide users to better understand their domains and the available tools within that domain.

• An overview page should provide the user with all the necessary information to understand the state of a domain and what actions are required.
• With the overview page, you can design the structure and the priorities within a domain, thereby offering more guidance to the user than is possible with the home page.
• The content of an overview page is modular using a card metaphor. Cards can show different types of content and expose actions, but with a rather limited level of detail in order to reduce complexity.
• The overview page provides a means to define and differentiate between contexts so that the user can get an overview for a specific context without the need to run multiple independent reports and analyses.
• An overview page can serve as a navigation hub to direct the user into other applications so that these apps don’t have to be shown on the home page directly, thus reducing the number of tiles on the home page.
• While we are offering a growing set of specific design patterns for overview pages today, the role of a domain-specific overview can also be fulfilled by other design patterns where applicable. If a domain has a clear structure that can be visualized and given to the user as guidance, this could also be done by other means (other than the overview page floorplan) when necessary.

The overview page is a highly flexible and modular way to create a coherent picture of a domain and to provide guidance to the user. For many scenarios, the overview page could be considered an integration point for content that is not important enough to be shown on the user’s home page, but which should be accessible in the context of a certain domain. In the language of the traditional SAP design environment, overview pages are closest to the work center concept, but provide much more flexibility and diversity.