This is the first part in a series of blogs meant to give some more background information on the most important aspects of SAP Fiori 2.0, the user experience for S/4HANA. In this post, I will explain the different ways you can organize and manage applications in the SAP Fiori launchpad.
The launchpad is the environment in which all SAP Fiori applications run. Much of the glue and integration functionality (such as navigation, search, and notifications) that create a coherent experience across the apps is located in the launchpad.
One of the most important functions of the launchpad is to provide access to all the applications that a user needs.
Navigation vs. Discovery
There are two fundamental use cases for a user to access applications:
- Navigation: the user knows that there is an app that he wants to use and he needs an easy way to navigate to it.
- Discovery: the user has to complete a task and he assumes that there is a suitable app for this, but doesn’t know which one and therefore needs an easy way to discover the appropriate app.
Of course, in an enterprise environment there are generally clear rules about which users/roles are allowed to use which applications. An administrator will typically assign the user specific roles with the assumption that the user’s tasks have already been well defined. This was the principle on which current navigation concepts were based. Navigation consisted of a curated catalog or repository of apps from which the user could select.
However, as we learn more about our users and about how they are using the system, we want to be able to provide more tailored recommendations. There is also a certain level of fuzziness in the practice of role-assignment that we want to avoid. Often, administrators tend to define roles either too widely or too narrowly, risking either too liberal of an authorization, or forcing the user to request access to individual apps manually. What often ends up being the case is that users need to overcome certain hurdles to access the required functionality, and ultimately decreases effectiveness.
With SAP Fiori 2.0, we have developed a more granular concept to support easy navigation as well as discovery.
The primary place where a user will look for applications is the home page. This is the heart of the launchpad and the starting place for the user. The home page is similar to the corresponding concepts on mobile platforms or common operating systems. It’s a place where the user can create shortcuts to the apps he or she uses most frequently.
This also means that the home page should be considered a place where the user – and not the system administrator or boss – is king. Much of the functionality that allows administrators to make apps or groups of apps permanently visible and fixed to a certain position on the home page, though useful, ultimately reduces the users’ freedom and should be handled with extreme care. After all, who wants to own a home where other people decide on what furniture to buy and where to place it?
By combining launching and dashboard functionalities, the home page offers more flexibility than a regular desktop or device home without increasing the level of complexity for the user:
- Launch tiles are used to represent the individual apps (or variants of these, using the apps Save as Tile function), similar to the app icons you might find on a desktop. In addition to their pure launching function, tiles also offer enough space to display information from the corresponding apps, such as a counter, KPI, or even data visualization. As the user can define what tiles should be visible on the home page, he or she can use this functionality to create an individualized dashboard.
- The link area allows for an alternative visualization of apps on the home page as simple textual links. This possibility is extremely useful if a user needs direct access to a group of apps that don’t necessarily offer content worth visualizing on launch tiles.
- Tile groups allow the user to better structure the home page according to his or her needs. Related apps can be grouped together. The groups also serve as anchors for the navigation bar on top of the page, allowing the user to scroll directly to a specific group. Within each group, either launch tiles or textual links can be used. This allows the user to control content density and the kind of information displayed on the home page.
- The edit mode offers additional functionality to control the visibility and placement of apps and groups on the home page. To add new applications to the home page, the user can access the catalog. The catalog, which was introduced with the initial version of SAP Fiori, contains all the apps that are available to the user. For SAP Fiori 2.0, this catalog will be replaced with a more powerful “app store”-like component, which will be described later on in this article.
Initially, the navigation concept in SAP Fiori was inspired by mobile operating systems in the sense that apps were launched from a central home page. To access another application from within an open application, the user would need to return to the home page. This navigation concept, the so-called hub-and-spoke model, is simple and intuitive, but it doesn’t scale to a large suite of business applications.
Traditionally, this issue would have been solved with navigation menus that either reside on top or on the left of the screen, revealing the fixed navigation structure of the environment. Unfortunately, such an approach not only takes up valuable screen real estate, which is not an option for mobile use, but it also creates unnecessary complexity. Assuming that the home page holds access to all the apps that the user needs to accomplish his or her tasks, and assuming also that these apps sequentially guide the user through each task, having a comprehensive navigation menu would likely end up being more distracting than helpful.
We therefore decided to take a different approach to navigation for SAP Fiori 2.0. In addition to keeping the original hub-and-spoke navigation, we also introduced an additional navigation menu. While not yet fully implemented (2 and 3 are still lab preview), the navigation menu potentially offers three different navigation approaches:
- Hierarchy navigation: For every app, each screen forms part of a screen flow, which was defined during the initial design phase. No matter which screen the user chooses to access, the hierarchical navigation of the launchpad will offer the user the option to navigate to the parent screen of the corresponding app. For example, if a user receives an email notification for a work item, he or she can access this work item by clicking the link in the email. If the user now wanted to access the related worklist, this would not be possible using a historical back navigation. Instead, the worklist would need to be derived from the application structure and exposed in the hierarchy navigation.
- Related apps: Many apps form part of a bundle of apps that support similar tasks or different aspects of a domain. Such apps can be offered as a recommendation to the user depending on the current context and based on different heuristics. An example would be the My Opportunities app for field sales representatives (in CRM). This app forms a natural bundle with other CRM apps such as My Contacts, which could easily be accessed through a list of related apps.
- All apps: If none of the above proposals are sufficient, the user can also access the full navigation menu. This menu provides the user with structured access to all apps in the catalog. Compared to the traditional approaches of using a fix masthead or top level navigation, this menu is only temporarily visible on the screen and can also be used on a mobile phone.
While not technically part of the navigation menu, the launchpad will also offer an additional way for the user to navigate through SAP Fiori through a frequently used apps option in the so-called Me Area (more on this area in the next blog). This is an especially useful feature for users who only use a small number of apps on a frequent basis. In addition to this, the SAP Fiori launchpad will also provide separate access to both an app history and a used objects history.
If a user needs to find a certain functionality or application, but is not sure whether this is available or how it’s called exactly, the user will benefit from an intuitive way to browse and explore the available apps. For this purpose, we are planning to introduce the App Finder, an “app store”-like interface that will list all the apps that a user might potentially use. Apps in the App Finder will be sorted in the following way:
- Frontend server catalog: All apps that an administrator has added to the catalog in the frontend server. These are the apps that would typically appear in the user’s catalog of the SAP Fiori launchpad.
- User menu (SAP Logon): All apps that have been assigned to a user in a specific system. These are the apps that a user would find in the user menu in SAP Logon when logged on to a specific system.
- SAP menu (SAP Logon): All apps in a system, no matter if they were assigned to the user, or if the user has access to it. These are the apps that a user would find in the SAP menu in SAP Logon when logged in to a specific system.
As this is under development, this should be considered a lab preview with no commitment to the final product scope.
Let’s take a look at the case of the frontend server catalog apps. As the image illustrates, the idea of the App Finder is to feature applications either based on administrated rules or on matching algorithms, as is common in store interfaces.
Other common functionalities such as application descriptions, screenshots, and community content should accompany these apps so that the user can get a better idea of whether an app might be useful. From the App Finder, the user will be able to directly open an app or add it to the home page as part of his or her favorites. If the user doesn’t have access rights for a specific app, he or she should be able to directly request the rights through a GRC process.
While Top Apps features specific apps along certain recommendation criteria, the For You and All Apps perspectives offer a hierarchically structured view of different system-specific catalogs. Here the user can search or browse the entire catalog for suitable apps.
Even though the App Finder is not really a store in the sense that users can purchase and download apps, it is nevertheless a well-established paradigm that every user knows how to handle. Users will, however, be able to launch the apps, add them to the home page, and rate them.
With SAP Fiori 2.0, we have significantly enhanced the way apps are managed, making it even more suitable for a large suite of enterprise applications. With the distinction between navigation and discovery, we can now offer much more targeted support for the individual use cases. We are introducing new functionality to manage the user’s favorite apps, to navigate between apps, and to discover new apps without sacrificing the design principles of adaptiveness and simplicity. Furthermore, we are laying the foundation for contextual navigations and recommendations of applications, an area that will heavily evolve within the upcoming years.
At SAPPHIRE 2016, we showed a preview of SAP Fiori 2.0 in our development systems and the feedback was extremely positive. Parts of the abovementioned functionality will be included in the next releases of S/4HANA.