Skip to Content

This article is part of a series of articles that explain the design rationale behind some of the changes that come with the next evolution of SAP Fiori.

In this article, you will learn about the dynamic page, a new layout that will be used as the basis for most of the standard pages in SAP Fiori. Using the dynamic page will not only bring about some usability improvements, but it will also give a coherent look to the different pages. Due to the increased flexibility of the layout, the dynamic page also allows the application to make better use of the screen real estate on different form factors.

The dynamic page is now available as a first version with the object page layout. The generic layout is currently under development and will be available soon.

From Object View to Dynamic Page

Object-View-Object-view-floorplan-on-a-desktop.png

Object view floorplan featuring the object header and the icon tab bar.

One of the first standard page types in SAP Fiori was the object view. This page was designed to display information about a single object or task, such as a product or work item. The most significant parts of that page were the object header, the content area (often containing a tab container with icon tabs), and the footer toolbar.

The object header was designed to provide a simple overview of the most important object information, with the title and some attributes on the left, and an optional key figure and status information on the right. This was also a very consistent repetition of the left-side list view in a master-detail application.

The object header defines a very clear information hierarchy on the page and ensures sufficient white space to create an elegant and simple appearance. This concept works well for certain content and device configurations that we defined in the initial portfolio. On limited screen real estate, the object header provides a robust responsive behavior for contents of different lengths.

However, this layout also exposes some weaknesses. Large screens sometimes produce white spaces in the center. Furthermore, the guidance to keep a certain padding between the lines to ensure safe touch targets sometimes results in extra vertical space being consumed with every additional attribute pushing the content down. Finally, though the rigid structure of the object header ensures consistency and clarity, it also prevents other content, such as information visualization or multiple KPIs, from being shown. We therefore designed a responsive version of the object header that addresses some of these limitations, though some of the structural issues nevertheless persist due to compatibility constraints.

The content area of the object view has two basic structures:

  • Tabs
  • The flat layout displays all content in vertically-aligned blocks, with all the information visible on one page.

Each of the two structures has advantages as well as disadvantages. While the tab layout allows you to display large information sets on limited screens with little scrolling, it also affects the coherence of the page by chopping up the information into smaller pieces. In this very traditional approach, the user can only see one content block at a time. Also, since the footer toolbar is global and that the toolbar shouldn’t change when switching tabs, our experience shows that many designers struggle with which actions should be placed in the footer toolbar.

The flat layout, on the other hand, gives a good overview of all the aspects related to an object at one glance. However, this only works for smaller objects since – as the page doesn’t offer navigation – the user would otherwise need to scroll through the entire page to find the information that he or she was looking for.

In general, the recommendation is to use the tab layout for contents with varying length (especially long tables), while the flat layout should be used for limited content and for editing (meaning that also tabbed objects should be switched to a flat layout when editing).

Finally, we have the footer toolbar, which initially used to be the only place for actions, particularly for simple use cases. This approach followed the common mobile patterns of that time, where actions were placed primarily at the bottom of the screen.

The usability of the footer toolbar is particularly affected by the device type and display size. While the footer toolbar works well on mobile devices, users sometimes experience issues locating it on larger displays and on regular computers. In some usability tests we conducted, the dark tool bar was not always found by the users, particularly on first usage.

To summarize, the object view was one of the first page types that we established for SAP Fiori, and it successfully helped to create a consistent and simple appearance. However, it does come with some limitations. The flexibility of the header content, the empty spaces in the layout, and the question of where to place actions, are some examples of where there is room for improvement.

With the dynamic page, we’ve developed a design that addresses these issues while keeping the advantages of a consistent page layout.

The Structure of the Dynamic Page

Bildschirmfoto 2016-07-07 um 23.03.09.png

The structure of the dynamic page: The header title area  contains global actions, and the header content disappears when the user scrolls down the page.

The dynamic page has three areas:

  • Header title: This area clearly identifies the content of the page and remains visible at all times. To the right of that area, a toolbar can be found that contains the global actions. A more detailed explanation of the action concept will follow later on in this series.
  • Header content: This area contains secondary header information such as attributes, key facts and figures, charts, and more. As the header content area is very flexible and has no limitations on layout or content types, this area can be used in many ways. When scrolling down the page, the header content area disappears and a short summary appears next to the title. The user can also expand and collapse the header area by clicking on the title.
  • Page content: This area can be used freely. However, there are predefined page types such as the object page, which support a specific content model.

Compared to the object view, this layout offers a number of advantages that will give us more flexibility and scalability for future design iterations. With this structure, we first of all provide a stable title that doesn’t scroll away (as was the case for the object view), and that complements the merged header area of the launchpad quite well (see previous article).

Furthermore, we provide a stable place for global actions such as Share, Edit, and so on, without taking away additional screen space (as was the case with the footertoolbar). As the header content area is more flexible and can be collapsed, we’re able provide rich header information without necessarily pushing down the page content.

In the next section, I’ll go into these aspects in more detail.

Header Title

ObjectPage_LIGHT_Normal.png

Object page with a bread crumb on the title, status icons, and a summary. On the right side, an Edit action and a Share icon are shown.

The header title provides the necessary information for the user to immediately identify the content of the page. It is consistently positioned at the very top of the page and is always visible. When the header content area is collapsed, a summary of the header content can be displayed next to the title (for example, “Filtered by company code”). The global actions appears on the very right of the title area. The user can click on the title to expand or collapse the header content area independently of the scrolling position (either by pushing in the header content or by overlaying the page contents).

If a page is closely related to another page (for example, if the object on that page is part of another object), an additional breadcrumb can be displayed on top of the title to allow navigation up the hierarchy.

When using the header title, you have to carefully manage the contents in order to avoid truncation. The overflow behavior is defined to avoid unwanted behavior, but it’s still necessary to minimize the number of actions, the content summary, and also to control the title length carefully. With the additional possibilities that offer more flexibility, it is even more important that the contents be well-managed and kept simple during the design process.

Header Content

ObjectPage_LIGHT_Normal.png

Object page with a bread crumb on the title, status icons, and a summary. On the right side, an Edit action and a Share icon are shown.

The header content is designed to display the necessary information required to understand of the most important aspects of the object or contents on the screen. In general, this can include:

  • Images
  • Forms
  • Links
  • Key figures
  • Micro charts

The most flexible way to set this up is to organize the header contents into small entities or facets, and align them in a flow layout. We don’t recommended displaying editable controls such as input fields in the header content, as the header should really be reserved for displaying information only. However, the contents of the header content can be interactive and influence the contents of the page below.

ListReport_LIGHT_Normal Kopie.png

List page with a filter bar. The filter title, variant management, and Analyze action are located in the header title area. The filter fields are located in the header content area.

In order to accommodate the filter bar into the dynamic page layout, we split the filter bar into two components: the title with the variant management that go into the header title, and the filter controls that are displayed in the header content area.

In the dynamic page layout, the visibility of the filter bar can be adjusted by scrolling up and down the page, by selecting the title, or through an additional action that hides or shows the filter bar. For desktop tables that don’t use page scrolling, but which have a scrollbar within the table, clicking the title or the Hide/Show actions is the only option to change the visibility of the toolbar.

Such pages would contain controls like:

  • Filter bar
  • Facet filter
  • Visual filter (labs preview)
  • Icon tab bar
  • Timeline

Bildschirmfoto 2016-07-07 um 23.11.57.png

Analytical list page (lab preview) with a visual filter in the header content area.

In the analytical list page (lab preview), a visual filter can be placed in the header content area to filter the contents of the page below. The same applies for the filter bar or other charts. Another example would be placing a timeline control in the header content that can be used to switch between versions of the page below.

The overflow behavior of a header content area can differ depending on the type of contents displayed there. Facets would wrap, while a control like the visual filter (lab preview) would require a paging overflow.

When the header content is collapsed – either by clicking the title or by scrolling the page – a very condensed summary of the header content appears in the header title. The summary includes the following information:

  • Icon (placed in front of the title)
  • Most important attribute
  • Status
  • Filter criteria
  • KPI

It will be important for applications to define a meaningful string to summarize the header content.

Page Content

There are currently a number of predefined floorplans that have been adapted to the dynamic page layout, such as the overview page, list page, initial page, work list, and object page.

All of them make use of the snapping header concept to allow for rich header content that can be hidden when required. In the page content area, there are different concepts for the different floorplans:

  • The overview page features cards which, depending on their type, can display different contents and be arranged by the user.
  • The page content of the list page usually consists of a table, chart, or combination of both. The same applies for the worklist, which is usually headed by a tab strip.
  • In the object page, the content is organized into sections. Each section can be accessed using an anchor bar on top of the page, which doesn’t scroll away. Each section can contain forms, tables, charts or other controls aligned to a grid of up to four columns, depending on the screen size.

Actions and Toolbars

The dynamic page layout features a more powerful concept to offer actions to the user. In general, we intend to bring actions closer to the element that they affect.

Therefore, we have introduced toolbars in tables and forms for their actions. Following the same logic, we introduced a toolbar in the header title for actions that belong to the page to indicate that these actions are global.

Global actions on page level could be:

  • Share
  • Edit
  • Request Access
  • Change Status

All these actions affect the whole page and are not meant to finalize a certain state. Instead those actions belong to the object displayed on that page.

Initialpage_LIGHT_Normal_Content.png

Initial page floorplan with a footer toolbar with the determining actions Save and Cancel.

In addition to the actions on the page title, we offer an improved footer toolbar for determining actions, meaning actions that finalize a transient state of the page and which  should therefore be at the end of the page.

Determining actions include:

  • Save
  • Cancel
  • Approve
  • Reject
  • Postpone

All those actions should be triggered as a result of reviewing the object or to determine the state of the object. Save or Cancel, for instance, end the state of being editable. Approve and Reject determine the pending state of a work item. As finalizing or determining actions, these action should be placed at the end of the screen to follow both the reading flow and flow of action.

In order to make the footer toolbar easier to find, we’ve introduced a padding around the toolbar to set it apart from the window frame. We therefore called it the floating toolbar. In addition to the padding, we introduced an animation when the toolbar appears so that the user’s attention is immediately drawn to it.

Take Aways

The new dynamic page layout is the basis for new floorplans in SAP Fiori going forward, as it offers a number of powerful advantages over other page layouts:

  • A fixed header title area gives a clear indication of the page content and provides access to page’s global actions any time.
  • The flexible header content minimizes when scrolling to provide the possibility to display rich header information, as well as powerful filtering controls without permanently blocking screen real estate.
  • The new floating footer toolbar overcomes some of the usability issues of the older version of the footer toolbar, providing direct and intuitive access to determining actions.

Standardizing most of the SAP Fiori floorplans on this dynamic page layout will not only improve this usability of the individual pages, but it will also lead to more consistency and coherence across the different pages, also when used side-by-side.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Dorian Salmon

    Kai:

    Great post – this new design will definitely help generate some really nice Fiori / UI5 apps.

    When can we expect to see the template in the Web IDE?

    Will this new design template be usable with some of the earlier versions of UI5? Several of our current customers tend not to do frequent updates to the UI5 libraries once they have done the initial implementation.

    Thanks,

    Dorian.

    (0) 
    1. Kai Richter Post author

      Hi,

      This article is intended to be a design preview to provide a wider context to our customers and partners. Right now, the dynamic page is still under development and available only internally for technical and user evaluation. We plan to release the new page type soon but I am not entitled to make any commitments with regards to timelines.

      Today, you can already experience the behavior in the object page that is available since UI5 1.26. The dynamic page is a generalization of this behavior on other page types. The object page templates are already available in WebIDE as far as I know.

      As soon as the dynamic page page is available for productive use it will also become available in the tooling.

      Best regards

      Kai

      (0) 
    1. Kai Richter Post author

      Hi,

      sorry for the delayed answer (holiday season… :-).

      There are several references for an implementation of the dynamic page:

      If you want to know, which applications are using the dynamic page? This is hard to answer to be honest because it also depends on the version of the app we are talking about. You can expect that many application will make use of the Fiori Elements and those applications will automatically be based on the dynamic page layout. Unfortunately, I am not able to tell you which of the existing applications.

      Best regards
      Kai

      (0) 

Leave a Reply