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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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