Continuing my series on Fiori elements ... you'll find more blogs in the Fiori elements wiki.
Object Pages are a summary screen for a single something – a single Order, single Customer, single Invoice, etc. They are also used as the default way to display a single row of a list report, and can be called from Fiori Search or provided as the target of a hyperlink or button from other apps. Here we take first steps into designing our own Object Page.
When you want a summary screen of a single business object – a single Order, Customer, Invoice, Cost Centre or whatever – that’s the time to reach for an Object Page. Object Pages can be used to both display or edit a single business object. Object Pages are part of the List Report template as they are also used as the default display of a single row of a List Report. In this blog we will focus on the basics – designing a simple read only display with a few sections.
Here’s an example of a Customer Object Page from S/4HANA Cloud 1705.
As explained in the Fiori Design Guidelines, the layout of the Object Page contains:
So when designing an Object Page you need to:
Let’s get to it!
Every Object Page has a header.
The Object Page Header is the first thing your business user will see when they open your object page. You want your user to instantly confirm that they are looking at the correct object instance. So the header should show the most important identifying information.
In the real-life Customer Object Page example taken from SAP S/4HANA Cloud you can see:
After that if you wish you can add other Header sections (called Header Facets) for important information that most people will want to know right away. These sections are laid out horizontally in the Object Page header content area.
In this example, you can see:
There is no minimum number of sections, although of course an Object Page with no content other than the header is of limited value to a business user.
The top section in the content typically contains the main information of this business object. In the example you can see fields of the Customer object itself in the General Information section. By default these fields are listed vertically. If you have a lot of fields you may want to gather these into logical groups. In the example you can see 3 logical groups: Basic Data, Communication Data and Overall Blocks.
Other sections typically contain relationships to other objects.
Remember always business users will experience the Object Page scrolling from the top-down, so aim to place the most important relationships before less important relationships.
You can display all sorts of content and content types in each section.
The simplest content is simple text fields.
You can also use a range of graphical visualizations, tables and other content types.
If you find you are wanting to include a lot of analytical content, you may want to consider using an Analytical List Page instead.
By default, each section is displayed vertically beneath the previous section. The anchor bar at the top enables quick navigation to each vertical section. In the example, when the business user selects “Contacts” in the anchor bar the Object Page scrolls down to the Contacts section below.
When using a device with large screen size you may want to display logical field groups horizontally to make better use of the screen and minimize vertical scrolling. On smaller screen sizes, Fiori responsive design will automatically adjust the screen by wrapping the fields underneath.
In the example you can see how the 3 logical groups of the General Information section are displayed horizontally as subsections of General Information.
Once you have confirmed what you want to show, make sure you give your Object Page design to your OData Architect to design the logical data model that is needed. They will decide:
Once your OData Service design has been modelled, then your architects and developers can use the model to decide how best to extract the information from your database, and expose it for consumption via your OData Service.
For example, if you are following the ABAP Programming Model for Fiori guidelines, your architects and developers will need to:
Now you are ready to start developing your Object Page! Watch out for my upcoming blog on developing the Object Page including which annotations you will need to realize your design.
If you want to find out more about designing the Object Page, you’ll find lots more design information in the Fiori Design Guidelines for the Object Page.
If you want to understand more about why the Object Page is organized this way then read up on the Object Page and its History.
If you are interested in Fiori elements you might also like to look at some of our videos on Youtube such as:
Adding a Field Group to an Object Page with SAP Fiori Elements
If you are going to SAP Teched 2017 and Interested in learning more about Fiori elements you might like to attend these sessions:
And you can find more information on Developing apps with SAP Fiori elements in the SAPUI5 SDK.
Brought to you by S/4HANA RIG
Object Pages are a summary screen for a single something – a single Order, single Customer, single Invoice, etc. They are also used as the default way to display a single row of a list report, and can be called from Fiori Search or provided as the target of a hyperlink or button from other apps. Here we take first steps into designing our own Object Page.
When you want a summary screen of a single business object – a single Order, Customer, Invoice, Cost Centre or whatever – that’s the time to reach for an Object Page. Object Pages can be used to both display or edit a single business object. Object Pages are part of the List Report template as they are also used as the default display of a single row of a List Report. In this blog we will focus on the basics – designing a simple read only display with a few sections.
Here’s an example of a Customer Object Page from S/4HANA Cloud 1705.
As explained in the Fiori Design Guidelines, the layout of the Object Page contains:
- Object Page Header
- Object Page Header content area, for optional additional header content
- Object Page Body content area, which consists of:
- Navigation bar - to navigate the main sections in the Body
- Sections and their content
So when designing an Object Page you need to:
- Decide what you want to show in the Header
- Decide what sections you want in the Body of the Object Page
- Decide what content & what content type you will show in each section
- Decide on the overall layout of the sections within the content
- Make sure your OData model includes all the entity sets and properties that will provide the content to be displayed
Let’s get to it!
Design the Object Page Header
Every Object Page has a header.
The Object Page Header is the first thing your business user will see when they open your object page. You want your user to instantly confirm that they are looking at the correct object instance. So the header should show the most important identifying information.
In the real-life Customer Object Page example taken from SAP S/4HANA Cloud you can see:
- The customer name
- The customer number
- An image – which could be the customer logo
After that if you wish you can add other Header sections (called Header Facets) for important information that most people will want to know right away. These sections are laid out horizontally in the Object Page header content area.
In this example, you can see:
- The location (city) of the customer
Design the Sections of the Object Page Body
There is no minimum number of sections, although of course an Object Page with no content other than the header is of limited value to a business user.
The top section in the content typically contains the main information of this business object. In the example you can see fields of the Customer object itself in the General Information section. By default these fields are listed vertically. If you have a lot of fields you may want to gather these into logical groups. In the example you can see 3 logical groups: Basic Data, Communication Data and Overall Blocks.
Other sections typically contain relationships to other objects.
Remember always business users will experience the Object Page scrolling from the top-down, so aim to place the most important relationships before less important relationships.
Design the content of each Section
You can display all sorts of content and content types in each section.
The simplest content is simple text fields.
You can also use a range of graphical visualizations, tables and other content types.
If you find you are wanting to include a lot of analytical content, you may want to consider using an Analytical List Page instead.
Design the layout of the Object Page Body
By default, each section is displayed vertically beneath the previous section. The anchor bar at the top enables quick navigation to each vertical section. In the example, when the business user selects “Contacts” in the anchor bar the Object Page scrolls down to the Contacts section below.
When using a device with large screen size you may want to display logical field groups horizontally to make better use of the screen and minimize vertical scrolling. On smaller screen sizes, Fiori responsive design will automatically adjust the screen by wrapping the fields underneath.
In the example you can see how the 3 logical groups of the General Information section are displayed horizontally as subsections of General Information.
Design your Data Model
Once you have confirmed what you want to show, make sure you give your Object Page design to your OData Architect to design the logical data model that is needed. They will decide:
- Which entity sets are needed in the OData Service
- The properties (fields) of each entity set
- The associations (relationships) between entity sets
Once your OData Service design has been modelled, then your architects and developers can use the model to decide how best to extract the information from your database, and expose it for consumption via your OData Service.
For example, if you are following the ABAP Programming Model for Fiori guidelines, your architects and developers will need to:
- Identify or design the virtual data model (VDM)
- Physically implement the VDM, by identifying or creating Core Data Services (CDS) views
- Extend the CDS Views with appropriate annotations to speed development of your Object Page
- Publish the CDS Views via OData Services
Now you are ready to start developing your Object Page! Watch out for my upcoming blog on developing the Object Page including which annotations you will need to realize your design.
Taking your Design to the next level
If you want to find out more about designing the Object Page, you’ll find lots more design information in the Fiori Design Guidelines for the Object Page.
If you want to understand more about why the Object Page is organized this way then read up on the Object Page and its History.
If you are interested in Fiori elements you might also like to look at some of our videos on Youtube such as:
Adding a Field Group to an Object Page with SAP Fiori Elements
If you are going to SAP Teched 2017 and Interested in learning more about Fiori elements you might like to attend these sessions:
- DX201 What's New with SAP Fiori Elements
- S4H276 Build a List Report SAP Fiori App: ABAP Programming Model for SAP S/4HANA
- S4H279 Build Transactional SAP Fiori App: ABAP Programming Model for SAP S/4 HANA
- DX264 Overview Page in SAP Fiori Elements
- DX266 SAP Fiori Elements - Analytical List Page
And you can find more information on Developing apps with SAP Fiori elements in the SAPUI5 SDK.
Brought to you by S/4HANA RIG
- SAP Managed Tags:
14 Comments
