Updated: December 19, 2016

Navigation

Intro

Navigation in SAP Fiori follows standard navigation paradigms of various web applications. When a user navigates to a new screen, the user’s system default navigation is in place. Depending on individual browser settings and functionality, new screens can also be opened in a new tab or window by using a long tap or right mouse click.

SAP Fiori combines the hub-and-spoke navigation model with an application network model. A central home page (the SAP Fiori launchpad home page) is the center of all navigation paths. The user starts from the launchpad home page and navigates forward into the apps through multiple screens. Multiple apps can form a process. The ubiquitous back navigation function allows the user to go back to the previous screen. The user can always navigate back to the launchpad home page via the home icon.

Hub and spoke and application network navigation model
Hub and spoke and application network navigation model

Navigation Between Apps

The tiles on the home page of the SAP Fiori launchpad represent navigation anchors to the individual apps. By selecting a tile, the user navigates to the corresponding app. It is also possible to integrate legacy UI technology through these tiles. Non-SAP Fiori UI technologies open in a new tab or window (for supported desktop operating systems only).

The home page on the SAP Fiori launchpad features tiles as navigation anchors to the individual apps
The home page on the SAP Fiori launchpad features tiles as navigation anchors to the individual apps

Individual apps can be connected to build up navigation flows. There are different ways to build a connection:

  • Navigation via links (to open other objects or lists)
  • Navigation via line items in a list or table (to display more details about the item in the list/table)
  • Navigation via other UI elements
  • Actions on buttons (to trigger transactional tasks)

By transferring context between apps, one modular app can build on the input of the previous app(s). This way, individual apps can be reused in different contexts. More complex functionality can be combined using individual modules or apps. After each navigation step, the user can always navigate back using the browser’s back button or the back arrow icon in the title bar of the app.

In SAP Fiori, modular apps build up more complex navigation flows
In SAP Fiori, modular apps build up more complex navigation flows

Back and Home

The launchpad shell bar is always located at the top of each app. It displays the home icon (except on the launchpad home page), which triggers navigation to the home page. While the home icon is always shown in the launchpad shell bar, the back arrow icon is always shown in the header of the app.

Launchpad shell bar with home icon and page header with back arrow icon
Launchpad shell bar with home icon and page header with back arrow icon

Split-Screen Layout

On large devices, such as desktops or tablets in landscape mode, the master and detail screens are shown side by side. When the user enters the screen, the first entry of the master table is selected and the corresponding detail is shown in the details area. This selection is already reflected in the URL.

When the user selects another item in the master list, the details of the selected item will be displayed in the details area. This action also results in a new URL, so that the new state of the app can now be bookmarked. However, in order to prevent long history chains from being formed when selecting different items in the master list, an additional entry should not be created in the back chain. Instead, the URL (hash) should be replaced. If the use case requires it, changes in filter settings can result in a new URL, but this should also not create a new history entry.

In apps with a split-screen layout, the user can navigate deeper within the details area. In this case, an additional back button will appear in the details area header.  This button takes the user one step back within the details area. When the user is at the highest detail level, no back button is shown in the details area. Back navigation in the details area does not create a new history entry in the back chain of the browser.

The back button above the master list always brings the user back to the location from which the app was first launched. This can either be the launchpad home page or another app.

Page header showing back navigation and generic header descriptions
Page header showing back navigation and generic header descriptions
Navigation flow in split-screen apps
Navigation flow in split-screen apps

Back Navigation in Split-Screen Layouts on Small Devices

On small devices, such as smartphones or tablets in portrait mode, the navigation behavior of the split-screen layout changes. Either the master list or the detail view are shown in full screen mode. Selecting an entry in the master list triggers navigation to the details page, which results in a new entry in the browser history. In this case, the back button triggers navigation back to the master list.

Switching from display mode to edit mode is not a navigation step. Hence, no new entry is made in the browser history. If the URL is shared, it always leads to the page in display mode.

The behavior in edit scenarios is described on edit page floorplan. More information about deep linking and bookmarking can be found in the draft handling article.

Entries in Browser History

The state of an app is reflected in its URL. This allows the user to bookmark or send a link to the app in this specific state. But when is a new URL created?

In general, there are three cases:

  1. new entry in the browser history should always be created when the user enters a new app. When the user navigates to a different page within the same app, a new entry should be created to allow back navigation to the previous page. In these cases, the previous page can be reached using the back button or the browser’s back arrow icon.
  2. The URL should be replaced in the browser history if only parts of the page are changed. This is important to avoid unnecessarily long back chains when navigating back in the browser history (see exception below). An example of this is when the user selects an item in the master list of a split-screen app on a tablet or desktop. On smartphones, the split screen-layout is divided into two separate pages, and the rule above applies. A new entry should be added to the history. You will also need to replace the URL when the user navigates through a list of items using the up/down arrows, or applies a filter to a list.
  3. The URL stays the same when it’s not necessary to mark a new state of the app. This could be the case after choosing a selection. The URL also stays the same when switching between display and edit modes (see exception below).

Exception

There is an exception when working on a draft version. In this case, the URL stays unchanged and a GUID is added to identify the draft version.

Deep Links

A page of an application that is not its entry page can be bookmarked or shared as a deep link. Ideally, the full UI state of the page is retrieved. Technically, this includes every part that is represented in the URL.

For example, a master-detail app in split-screen app gets a new URL when another detail is selected in the master list and shown in the detail. This state with the new detail can be used as a deep link.

A page that can be switched from display to edit mode can only be deep linked in display mode. This means the deep link will always navigate to the display mode.

Calling a Deep Link

Navigation to a deep link ideally restores every detail of the page. Technically, this includes all parts reflected in the URL. The use case and feasibility determine which changes are reflected in the URL, but the rules mentioned in this section (Deep Links) must be fulfilled. If a deep link leads the user to an object that no longer exists or is inaccessible, an empty page is shown. If a user calls a deep link that has been forwarded by another user, the results displayed may vary due depending on authorization levels.

Deep Linking to Split-Screen Layouts

A deep link to a detail in master-detail scenarios (split-screen layout) shows the detail as well as the master table. There is a BAdI solution for users who cannot see the master list on a deep link, though this is not used for standard delivery.

Guidelines and behavior:

  • If a deep link leads to a master-detail page, the entry in the master list that corresponds to the detail is selected. The master list scrolls in such a way that the selected entry is visible.
  • If a deep link leads to an object that no longer exists or is inaccessible, an empty page is shown in the details area. The master list allows another object to be selected.
  • If the deep link points to a line item of a detail, all the rules for split-screen layouts The back button above the line item detail navigates to the corresponding detail.
  • If the object is not yet loaded in the master list (growing list) and takes too long, show the first page of the master list next to the detail. In this case, there is no selection in the master list.
  • As multiselection mode in the master list is normally not reflected in the URL, a deep link leads to the previously selected object. The same state would be shown when closing the multiselection.
  • Depending on the use case, more information can be put into the URL, such as a search term in the master list. This ensures that this information is also restored when a deep link is called.

For more information about deep linking and bookmarking for drafts, see the draft handling article.

Deep Links

A page of an application that is not its entry page can be bookmarked or shared as a deep link. Ideally, the full UI state of the page is retrieved. Technically, this includes every part that is represented in the URL.

For example, a master-detail app in split screen gets a new URL when another detail is selected in the master list and shown in the detail. This state with the new detail can be used as a deep link.

Apps with draft handling functionality allow deep linking to a page in edit mode. Apps without draft handling allow deep linking only to the display mode of an object. This means that the deep link will always navigate to the display mode. For more information about deep linking and bookmarking for drafts, see the draft handling article.

Calling a Deep Link

Navigation to a deep link ideally restores every detail of the page. Technically, this includes all parts reflected in the URL. The use case and feasibility determine which changes are reflected in the URL, but the rules mentioned in this section must be fulfilled. If a deep link leads the user to an object that no longer exists or is inaccessible, an empty page is shown. If a user calls a deep link that has been forwarded by another user, the results displayed may vary due depending on authorization levels.

Deep Linking to Split-Screen Layouts

A deep link to a detail in master-detail scenarios (split-screen layout) shows the detail as well as the master table. There is a BAdI solution for users who cannot see the master list on a deep link, though this is not used for standard delivery.

Guidelines and behavior:

  • If a deep link leads to a master-detail page, the entry in the master list that corresponds to the detail is selected. The master list scrolls in such a way that the selected entry is visible.
  • If a deep link leads to an object that no longer exists or is inaccessible, an empty page is shown in the details area. The master list allows another object to be selected.
  • If the deep link points to a line item of a detail, all the rules for split-screen layouts apply. The back button above the line item detail navigates to the corresponding detail.
  • If the object is not yet loaded in the master list (growing list) and takes too long, show the first page of the master list next to the detail. In this case, there is no selection in the master list.
  • As multi selection mode in the master list is normally not reflected in the URL, a deep link leads to the previously selected object. The same state would be shown when closing the multiselection.
  • Depending on the use case, more information can be put into the URL, such as a search term in the master list. This ensures that this information is also restored when a deep link is called.

For more information about deep linking and bookmarking for drafts, see the draft handling article.

Quick View

Users can navigate from a quick view to those of the different users/objects. In this case, a back button is placed on the top left of the quick view box to allow the user to navigate back to the first or previous quick view. All other links lead to new pages and close the quick view.

Example of a quick view
Example of a quick view

Native Operating System

How can SAP Fiori apps be embedded into the native operating system?

Any SAP Fiori app should run in a standard HTML5 browser. Like with any other webpage, users can create shortcuts to either the launchpad or the individual app to support a more integrated experience. The user can save a reference to an app on the desktop or home page of the native OS. When this reference is followed, the app can be launched directly, bypassing the SAP Fiori launchpad home page. On smartphones, this hides the browser controls and displays the app in full-screen mode.

Accessing an app directly from the native OS
Accessing an app directly from the native OS

The same applies to the SAP Fiori launchpad itself. The reference to the launchpad can also be stored on the desktop or home page of the native OS.

Accessing the SAP Fiori launchpad from the native OS
Accessing the SAP Fiori launchpad from the native OS

Even better integration into the native OS can be achieved using the SAP Fiori Client. The SAP Fiori Client is a native application runtime for running the SAP Fiori launchpad and applications on Android and iOS devices. It encapsulates the HTML page within a native container, optimizing caching and offering access to native device functionalities such as GPS, sensors, camera, and so on. Find out more about the SAP Fiori Client.