A business expert - or key user - is faced with many challenges. While SAP's standard apps cover a wide range of use cases, your end users know best how they work and will present you with various requests to adapt the user interfaces to fit their needs even better.
With SAPUI5 flexibility, you as a key user can tailor the user interfaces of SAPUI5 applications, making them more efficient, easier to use, and better accepted by end users. This video shows how key users can adapt the UI of an app for others.
But how do you keep track of all the UI changes? How do you analyze the different states of your changed UIs in case of issues? And how do you as a key user provide support for your end users?
If you create UI changes for multiple applications over a longer period, you will notice that it becomes increasingly difficult to remember all the changes as well as the earlier states of the applications. To stay in charge in such situations, SAPUI5 flexibility supports key users with helpful tools like the version history and the change visualization.
As of today, the version history for SAPUI5 flexibility key user adaptation is only available for SAP Fiori applications running with SAPUI5 1.84 or newer on the SAP Business Technology Platform, Cloud Foundry environment but is planned to be available in SAP S/4HANA Cloud later this year (as always, forward-looking statements are subject to change).
Understand the history of UI versions
As a key user with the corresponding role depending on the used platform (find the relevant documentation), you have the ‘Adapt UI‘ option in your user menu and can adapt standard apps.
Entering UI Adaptation
In case the application has not been adapted yet, ‘Original App’ is shown as the version history title in the top left.
Original App without any UI changes
If you open the dropdown to show the version history, you will see that no other versions exist yet.
Version history with Original App only
As there are currently no UI changes present for this application let us create some, for example adding and moving a new field plus removing a section.
Adding a new field to the UI
Removing a section from the UI
Having changed the UI, the ‘UI Adaptation’ mode has left its ‘Original App’ state and is now in a ‘Draft’ state. Draft changes are only present for key users within ‘UI Adaptation’. End users working with the application will still see the active version of its UI which is highlighted in the version history in green, here the ‘Original App’. This allows you as a key user to create UI adaptations without disrupting end users. As the draft can be changed by other key users, you can collaborate over multiple sessions before deciding to make this UI state available to end users.
Version history with the draft
To finalize a set of self-contained changes and to make the UI changes available for end users the draft must be activated as a version first.
Activating the draft as new version
Providing a title for the new version
The latest version automatically becomes the application’s active version and is added to the top of the version history. Every entry is made up of the title entered during its activation, which can serve as a brief description of its content, along with its creation date and the username of the key user activating it. The title is only visible in ‘UI Adaptation’ - end users do not see it. If the platform supports transporting changes to another system, activated versions can be written onto a transport request.
Version history with the activated version
Having activated the version, the corresponding UI changes are now also applied for all end users. To benefit from the changed UI, end users do not have to be assigned to any specific user role.
UI changes being applied for all end users
Creating additional UI changes and activating them as new versions results in a growing version history. The active version of the application’s user interface is always shown on top of the list while the last entry is reserved for the ‘Original App’. This version history offers key users a chronological list of the various states the UI has undergone.
Version history with multiple versions
The version history can even be used to display the UI state of non-active versions. Simply select the respective version in the list and the app will automatically reload and apply the corresponding changes within the ‘UI Adaptation’ mode.
Selecting an inactive version
Key users can also select the ‘Original App’ entry from the version history to have a look at how the app looks in absence of any key user changes. Each version (including ‘Original App’) can also be reactivated. When a version is reactivated, a new version with a dedicated title will be created to keep the chronological list consistent.
Reactivated version with a new title
Once a version is activated, it cannot be changed anymore. Each version, both active and inactive, can be used as the basis for a new draft. To create changes based on an inactive version, simply select it from the version history before making the desired UI changes. As usual, these changes will be created as a new draft first, but this time based on the selected version instead of the active one. Once the draft is activated, its UI state becomes the new top entry in the version history.
Visualize UI changes
To get even more details of what has been changed on the user interface of an application, the ‘Visualization’ mode can be selected. This mode was introduced to solve common problems key users had with adapted applications. First, it is unclear to what degree an application has changed (and which parts), and second, there is no way to get details about individual changes, e.g. to find out what a text was before it was renamed. In this mode, all UI elements being affected by at least one key user adaptation are marked with a dot, called ‘Change Indicator’. When selecting such an indicator, all details about the corresponding change(s) are displayed in a popup table.
Details about the removed section
Details about the added field
The information contained in the ‘changes‘ table contains different information depending on the change type - ‘rename‘ changes contain the ‘before‘ state of the rename, while ‘move‘ changes show if an element was moved from a different container. To indicate that some controls have been changed more than others, the color of the change indicator will become darker as the number of changes increases to visualize the ‘change density‘ of controls and parts of the application.
Change indicators with a different change density
Additionally, key users can use the dropdown on the right to filter the type of changes to be visualized, e.g. when searching for a change of a particular type.
Visualization dropdown to filter the type of changes
Visualization for a filtered change type
Sometimes changes cannot be visualized for several reasons – either the control to which the change belongs is not visible on the screen (for example when it is part of the List Report and the key user is currently on the Object Page, or the control belongs to a popup), or the change type is not yet supported for visualization. In this case, the dropdown will contain a hint on top to inform you that there are more changes than you can currently see visualized.
Changes not visualized
Try it out!
With version history and visualization, we offer a straightforward way for key users to manage their adaptations and with that to efficiently provide a tailored experience for their business users.