Techdata
SAP Fiori UI UIs User Interface [shutterstock: 617330408, Rawpixel.com]
[shutterstock: 617330408, Rawpixel.com]
Blog SOH and S/4

Software Development At SAP: Fiori UIs

For developing software, it takes a couple of days to decide on an architecture, a couple of months to implement the backend, and multiple years for the User Interface to mature. Hence a few guiding thoughts on building modern UIs.

Building a proper User Interface (UI) is difficult because it needs to balance opposing requirements. It should be simple and flexible, obvious for new users and powerful for advanced users, fast but comprehensive, visually appealing but efficient, and many more contradicting requirements.

The classic SAPGUI is a good example of a bad UI design. If the backend function had 100 fields, the UI showed 100 input fields. And the same company that had relied on SAPGUI suddenly gets design awards for good UI design? What is going on here? The answer: SAP solved the problem from all three angles.

Fiori as the design pattern

The first part in UI development is a design pattern, guiding the developers how to present the data. The goal is to have a consistent user experience to make end users feel at home and to provide ideas as to what controls might be suited. Fiori breaks the entire task into guidelines for: Launchpad, Shell, Floorplans and Controls.

ad_banner

The Launchpad is the central navigation page where all applications can be found. The list of applications is based on the user’s roles and provides some customization. Adding a new application is therefore an intuitive process.

The Shell is the common frame where users can log out, navigate between applications, or open help screens – essentially all that is shown in the top menu and which should be identical in all applications.

The various screens can usually be categorized as either an entry mask to modify a single record, a table view to edit multiple records at once, an analytical page or other concepts. These are the Fiori layouts and floorplans. This level is about how UI controls are organized. The data to show and the control types would be the next step in building a UI.

Fiori defines additional rules that are often forgotten: Support multiple languages, use icons instead of images as they scale lossless, what color scheme to use, fonts, these kinds of things.

All we create up to here is paper. Guidelines that make sense – if only people would read them.

UI5 controls

The easiest way to build screens is by using the UI5 controls SAP provides, either as SAPUI5 library or as OpenUI5 library (the open source variant). When using these controls, the Fiori design language comes to life automatically. The developer starts with a Shell, adds a Layout and within the layout the individual controls are arranged. Even without having read and memorized the Fiori rules, the components contain them.

Of course, there are still a lot of ways the developer might diverge from the Fiori guidelines but when using the controls, it is the proper time to look up some of the details. Should I use a List, a Select, an Input or a ComboBox? The Fiori documents tell users the pros and cons of each and their use cases.

From a technical point of view, the UI5 library leaves little to desire. Complex things can be done easily, the controls provide enough flexibility, and if customers are still not satisfied, there are enough extension points:

  • Controls can be combined into super-controls, e.g. a search control is a combination of a text input, a search button and a result list.
  • Controls can be further customized.
  • In the worst case, completely new controls can be written.

One downside of UI5 is the learning curve, however. Using UI5 is easy – if you know what you are doing. Building the first application, it takes a while to get used to.

Shifting perspective a bit: As architect, my questions are of a more technical nature, but also must consider external factors, like: Is there a future in the library being used? What is the license fee for using the library myself and when selling a product to customers? Where do I get support? Is the library living and breathing?

Especially on the last few questions, we have been burned multiple times. A promising tool might have been presented at Sapphire, but one year later, it is barely usable, and another year later, SAP might have lost interest altogether. For UI development, this would be a disaster. It is the most expensive part of the development, runs for multiple years, and internet standards (together with browsers) keep progressing.

Here, the OpenUI5 team does an excellent job. When experiencing issues or wanting to share an idea, they respond quickly, are open to enhancements and constant progress in the UI library. Kudos to these people and to SAP for sponsoring the development.

Design Thinking

While the Fiori design pattern tells users how to build UIs and the UI5 library allows for the implementation, the missing part is an idea of what to build. In my experience, products usually break at their interfaces. In the UI development, there are interfaces to the backend, to the end users and the product manager overseeing the development budget. A lot of options to fail.

To get more effective in that area, SAP promotes the Design Thinking approach via internal trainings and customer workshops. Design Thinking is a process aiming to facilitate the different knowledge people have. The end user does know the current business processes but has no clue about the difficulties of software development and the possibilities how modern software can optimize these processes.

The result of using Fiori, UI5 and Design Thinking together is what allowed SAP to become better. We can utilize that.

Other considerations

If all the above sounds too good to be true, trust me, I’m telling the truth: UIs is one of the areas in which SAP did an excellent job. Of course, not everything is perfect and, in some areas, the potential is not fully realized yet. For example, the Hana UI development (with XSC and XSA) and SAP Cloud Platform development are too inefficient, in my opinion. There are better options to achieve the same outcome, which I prefer. But this concerns a different layer. It is more the backend development and development support. There is no dependency on that when cherry picking the good parts.

Another point to keep in mind is that UI5 is most efficient for Input masks, data display, and large applications. It contains powerful prebuilt controls for these types of screens. For other web applications, say a program for drawing pictures, there are probably better options.

But for typical transactional applications, SAP provides all the building blocks. I use OpenUI5 even for non-SAP projects! It is on par with Vue and Angular and excels for database applications.

Source:
rtdi.io

About the author

Werner Daehn, rtdi.io

Werner Daehn, former SAP employee, is an expert on big data and smart data integration. He is also the CEO of rtdi.io.

Add Comment

Click here to post a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Push

Subscribe to our Newsletter


PREMIUM PARTNER NEWSFEED

Titelbild
Titelbild
Our Authors
Anzeige