SAP Fiori 2.0: The Object Page – Part 1: Its History

[Kai_Richter]

Representing business objects in a consumable yet sufficiently powerful way is a challenge on its own. Since joining SAP in 2006, I have witnessed a number of different approaches on how to provide a floorplan that can provide an easy overview of the most important aspects of the business object at the same time show all relevant information and support edit and create use cases as well.

In this article, I would like to review the most important approaches to the object floorplan so far, and I would like to explain based on that how we arrived to the current design of the object page in SAP Fiori 2.0.

The History of the Object Page Floorplan at SAP

Before the ENJOY SAP initiative in 1999, page types that were used to display objects varied a lot. There was no definition of a floorplan that could be matched to today’s object page and displaying the various aspects of an object required the user to navigate between many different windows and dialogs. As part of the ENJOY initiative, and with the support of the design company, Frog, SAP established the first guidelines for R/3 floorplans (they weren’t called floorplans though).

SAP Enjoy (1999)

The SAP Enjoy single-screen transaction.

During the ENJOY SAP initiative, single-screen transactions were introduced. This design pattern included many options that allowed the user to navigate even complex objects without leaving the screen – overcoming the issue of open dialogs in previous versions of the SAP GUI. An overview panel on the left (2) allowed the user to navigate between many different objects, while on the right, the object is displayed in a structured way displaying object header information on the top (4) and related contents and items (5) below. It was characteristic at that time to use tabs excessively to accommodate as much information as information on one small screen without scrolling (here in the header section [4] on the top as well as in the item details section [6] at the bottom).

The biggest problem of this design is the deep hierarchy of dependent states created by master-detail relationships from the overview (2) to the details section and further between item list (5) and item details (6); one change in selection will cause the entire screen to change. Furthermore, hiding so much information in different tabs prevents the user from acquiring a holistic view of the object information, and there’s a high risk that related data points are scattered over multiple tabs, forcing the user to switch back and forth (not to mention error handling in edit mode). As a consequence, one of the most common tasks of tools like SAP Screen Personas is it to collect fields from multiple tabs.

Pro: Compared to the previous designs, the new floorplan provided the user with all information on one screen avoiding the need to open multiple dialogs.

Con: The variety of navigation options with master-detail-detail relationships created complexity and held the risk of unpredictable screen changes. Tab strips separate the object information and prevent a holistic view.

You can find the SAP R/3 Style Guide on our SAP User Experience Community website.

 

UI Standards (2002-2007)

The object instance floorplan (OIF) in the UI standards 2.0.

During the transition from native to web technologies, the standardization of SAP user interfaces continued. In the years between 2002 and 2007, a comprehensive design system based on patterns and floorplans was continuously refined and implemented.

• 2002 – CRM People-centric UI: Details


• 2005 – SAP Business ByDesign: Object instance floorplan (OIF), quick activity floorplan (QAF)


• 2005 – Guidelines for Professional Applications in ERP: OIF, QAF


• 2007 – User Interface Guidelines for SAP Business Suite 1.1: OIF, QAF

During this transition period, the basic structure of floorplans to display business objects remained largely unchanged: an object header was used to display the most important attributes of the object and a tab strip was used to structure the content.

The image above shows the object instance floorplan (OIF) from the 2007 business suite guidelines. Compared to the SAP Enjoy screens, the object header (B - identification region) has been streamlined and the visual hierarchy is more apparent. The double toolbar (D and G) was a specific feature of that version to improve the reachability of the toolbar. The tab strip (E) here was even hierarchical so that subtabs were possible within each tab. This resulted in deep navigation structures and high degree of segmentation of the content.

In addition to the powerful OIF, another object floorplan was introduced with the ByDesign guidelines in 2005. The quick activity floorplan (QAF) didn’t feature tabs. It was used to display only those fields that were needed for a specific task. From the QAF, the user could open an OIF for the full object functionality.

Pro: A clear page structure with a simplified page header and strict information hierarchy. A scalable approach that supported complex objects (OIF) as well as a task-based view of an object (QAF).

Con: The issue with the information scattered over multiple tabs hasn’t been resolved. Especially in edit scenarios, error handling is a huge issue.

The UI Styleguide for SAP Business ByDesign from 2012 can be found on our SAP User Experience Community website.

 

UI Guidelines 2.0 (2010)

An overview page in the Business Suite Guidelines 2.0 that was designed following the CRM WebClient UI.

In 2007, CRM replaced their people-centric UI with the new WebClient UI and abandoned the tab strip. The new overview page (OVP) laid out all object aspects on one long continuous page. This was a consequent step towards the native web experience as we know it today that puts scrolling over screen changes and modes.

The OVP featured a simple header with a global header toolbar. The contents were organized in so-called assignment blocks that were placed underneath of each other and that could be arranged by the user. The first assignment block was reserved for general header attributes. For many objects, this allowed the user to get a good overview of all aspects of an object on one page without navigation.

Based on the success of the WebClient, SAP decided in 2010 to harmonize the experience for the Business Suite. The new guidelines 2.0 for WebDynpro ABAP extended the WebClient guidelines taking into account additional requirements from the business and the tabs sneaked back in.

In some cases, the long scrolling layout in the WebClient UI led to extremely long pages where users lost orientation. The absence of intra-page navigation made it hard to find sections and the scrolling distance separated related contents as much as the navigation between tabs. Therefore, the option to stack assignment block into tabs was introduced again. Now, it was up to the application, and later the user, to decide whether tabs or long scrolling pages or a combination of both were preferred. This offered the most flexible solution so far.

Pro: The long-scrolling page layout allows the user to scan the entire object and no information is hidden.

Con: For complex objects, the page becomes too long. The combination of tabs and long-scrolling can produce issues as the user might miss information in a stacked view assuming everything is visible.

The overview page floorplan originated from the Design Guidleines for CRM WebClient UI and were evolved as part of the SAP User Interface Guidelines 2.0 for SAP Business Suite that both can be found on our SAP User Experience Community website.

 

UX3 (2011)

The thing inspector in UX3

The UX3 design that was released with Sales on Demand in 2011 was an attempt to create a modern user environment for cloud solutions. Abandoning the work center concept that used to be the structuring element in the business suite so far, UX3 took a solution-based approach that centered around domains of work, such as sales. The concept of business objects was substituted with the notion of user-centric things and the thing inspector was defined as the floorplan to display all aspects of such a thing.

The header area of the thing inspector was much more prominent than in previous object floorplans, covering the left part of the page featuring the representation of the thing as a business card in the upper left corner. The object contents again were distributed over multiple tabs where the first tab should be used as a summary of the most important contents. Interestingly, in UX3, all things were opened in a dedicated thing layer on the UI, which allowed the user to browse through things without losing the underlying screen context.

The innovative and beautiful layout turned out in practice to have a number of shortcomings: the fixed area of the header area on smaller screens takes away valuable screen real estate, squeezing the content area. At the same time, the header area is still rather narrow so that texts often get truncated. On smaller screens, the containers for the header and content area require separate and ugly scrollbars. And, for mobile devices, the design is not really suitable.

Pro: The object header area provides enough space for rich information and visualizations, and the overview tab can be used to create an appealing summary of the object.

Con: The object header reserves a fixed screen space that is missing on small screens for the content area. At the same time, longer texts get truncated.

 

SAP Fiori 1.0 (2013)

The object view in Fiori 1.0

In 2013, the first wave of SAP Fiori was designed and developed. Initially, the focus was on simple use cases with very limited content and with a mobile first design approach.

The object view was the primary floorplan to display objects, and it consisted of an object header area on top, containing a fixed structure: title and attributes on the left and a key figure and status on the right. The content area could be structured with one tab strip (with the icon tabs as shown above) or with multiple sections underneath each other, which we called the flat object view. For editing, the tabbed object view had to be transformed into a flat page to avoid issues with error handling within the tabs. The toolbar on the bottom was always global.

This simple design worked very well for simple and task-oriented contents (similar to the QAF above). However, for larger objects, the object view soon reached its limits with either too many tabs or an elongated page without internal navigation.

In general, the lack of flexibility in the object header was a problem for rich header contents, and the two-column layout fell apart on wide screens. Having only one global footer toolbar for a page was also not sufficient to place all required actions; it works well for finalizing actions such as Save or Commit, but not for other global actions that people expect to find in the header area.

Pro: The clear structure of the page and the inbuilt responsiveness provide a good basis for simple objects, and the possibility to choose between a flat and a tabbed layout offers enough flexibility for the designers to pick the best option.

Con: The header area limited presenting rich content that didn’t fit to the predefined structure, and, on large displays, the two-content columns fell apart. The object view in both modes was not scalable enough to accommodate large business objects.

The SAP Fiori Design Guidelines are available on our SAP User Experience Community website. The object view can be found in all versions up to 1.40.

 

SAP Fiori 2.0 (2016)

The object page in SAP Fiori 2.0

With the new object page in SAP Fiori 2.0, our goal to provide a solution that takes the learnings from previous object floorplans into account.

• The object page defines a highly-structured and consistent floorplan similar to the UI Standard based on the dynamic page layout that is used as the common foundation for all SAP Fiori 2.0 floorplans.


• The object page offers a rich and expressive header area similar to the thing inspector in UX3 but it does so without constantly blocking a large screen area and as on the object page the header collapses on scroll. Also, the content structure of the object page header content area is flexible and designed to avoid text truncation overcoming the limitations of the object view in SAP Fiori 1.0.


• The object page by default features a long-scrolling one-page layout similar to the overview page in the guidelines 2.0 in order to provide the user a complete overview of the content of the object without switching tabs. In addition, the anchor bar provides a page-internal navigation to ensure orientation on large object pages. Alternatively, the object page can be implemented using a tabbed content structure if the content consists of multiple long tables.


• The object page features a page toolbar on the top to accommodate global actions. In addition, a footer toolbar can be activated for editing tasks to accommodate finalizing actions, such as Save or Cancel, or workflow actions. Both toolbars are fixed in position and will never scroll away to overcome the issue that was addressed in different ways by the object instance floorplan in the era of the UI standards.

The object page is an extremely flexible and powerful floorplan that provides ways to feature the content of an object in many different ways. Depending on the use case, the object page can be designed to be very operational and action-focused, as well as more strategic serving as kind of an object dashboard.

Basic Object Page

The basic object page structure consists of the following parts:


The header title contains the object name, a subtitle, and, where required, a breadcrumb to describe the hierarchical relationship to other objects. On the right, the page toolbar for global object actions is located. The header title is always visible on the page and doesn’t scroll away, which always provides access to the most important information and actions.

• Examples for the object page header title can be found in the SAPUI5 Explored app.


• We also offer design guidelines for the object page header and the snapping header.

The header content area can contain everything in general. However, we recommend only placing the most important header information and information that needs to be highlighted to the user. The most common elements recommended for the header content area are images, forms, key figures, or micro charts. The object header content collapses when the user scrolls down.

• Examples for the object page header content can be found in the SAPUI5 Explored app.


• We also offer design guidelines for the object page header and the snapping header.

The anchor bar is the intra-page navigation element that allows the user to directly access every section of the page content by scrolling to the section header position. Alternatively, a page can also make use of the tab strip to display the different sections, but due to the issue of content segregation, this option should only be used if there are few but large content blocks that are rather independent.

• Examples for the anchor bar can be found in the SAPUI5 Explored app.

The object page content area is split into content sections and optionally subsections that serve as anchors for the anchor bar navigation. In general, also here, the possibilities are rather unlimited. However, we provide some guidance on how to best design such a page. No matter if you place forms, tables, charts, or any other type of information, you should make sure that the sections don’t get too long. In case the content is too long, you should consider restricting the information on the page to an aggregation or selection and use a detail page navigation to display the entire content on a separate page.

Of course, being a SAP Fiori floorplan, the object page is responsive. All parts of the object page like the header, toolbar, anchor bar, as well as the contents adjust to the available screen real estate. The concept of priorities allows you to define content elements that are only visible on certain sizes.



 

Example of the object page header adjusting to the screen size with the help of priorities.

• Examples for the object page can be found in the SAPUI5 Explored app.


• The object page can also be experienced as part of the SAP Fiori Reference Apps.


• We also offer design guidelines for the object page.

The object page is available as a stand-alone page layout as well as a meta-data-driven SAP Fiori Element to simplify and accelerate your own SAP Fiori adoption.

Take Aways

Designing suitable pages to display business objects with all variance in complexity and with all the different functional requirements has always been a challenge.

The different generations of design standards described in this article show how SAP has been addressing this challenge in a systematic way, evolving from a very dense and complex user interface to an increasingly structured and usable design that features rich and expressive content:

• 1999: As a first step, multiple dialogs to display objects were consolidated into tabs on a single page and a navigation structure was established with SAP Enjoy .


• 2002-2007: The evolution of the SAP Enjoy single-screen design into the object instance floorplan took place, and the design settled on a fixed header area and a content area split into many tabs.


• 2007-2010: To overcome the issue of content scattered over multiple tabs, making it difficult to find and integrate the content into a coherent picture, flat layouts were introduced and explored with the overview page.


• 2011-2013: New means to provide richer visualizations in the header as well as in the content area were explored in the thing inspector, and, later, with the first SAP Fiori object floorplan, the object view.

The object page that is based on the dynamic page layout (introduced with SAP Fiori 2.0) is the next evolution step in this development. While the dynamic page layout ensures a consistent page structure across all page types, the object page is optimized to display an object on one long-scrolling page. We have reflected on past experiences to ensure that this new layout displays content in a rich and appealing manner. The flexibility of the concept allows designers to optimize the page to specific use cases without breaking the overall integrity of the system. Following the tradition of SAP Fiori, even this complex floorplan now acts responsive so that you can display the objects on any device.

This article provided a historic overview of the genesis and purpose of the object page. In the next articles of this series, I will give you more details on the design and usage of this central floorplan.