SAP Fiori is the design language that brings great user experiences to enterprise applications. In addition to the great resources we already provide to support the adoption of our design system, we are announcing an exciting new step in our goal to bring the award-winning SAP Fiori user experience (UX) to as many applications as we can.

What you may already know about SAP Fiori

Those of you familiar with SAP Fiori, know that it can be implemented in various UI technologies. We provide the Fiori design language out-of-the box with the SAPUI5 framework, as well as with SAP Fiori for iOS and SAP Fiori for Android to build native mobile apps. If you’ve done any designing or developing for Fiori, you probably also know SAP Fiori elements, a helpful framework for the most common application patterns that ensures design consistency and compliance with the latest design guidelines. Developers in particular benefit from Fiori Elements because it reduces the amount of frontend code needed to build SAP Fiori apps.

All of these guidelines, tools, templates, stencils and code snippets are open source for anyone interested in building Fiori apps. And we will continue to offer these resources in the future.

3 reasons why SAP Fiori UX is decoupled from the code base

First, UI technology changes very frequently. Supporting only one UI technology does not give us the flexibility to take advantage of the latest and greatest technology on the market. Second, because of the breadth of our portfolio, it is impossible for us to converge on only one technology stack, UI technology or UI framework. Re-platforming for the sake of UX consistency alone does not bring our customers value. And finally, we want to give our community of internal and external designers and developers the freedom to choose the right technology for their projects. 

What’s new?

The next big step in our offering will be SAP Fiori fundamentals. This is a light-weight presentation layer that can be used with your UI framework of choice (e.g. Angular, React, Vue, etc.).

Keep in mind, SAP Fiori fundamentals is not a new UI technology, nor is it replacing UI5. And, we are not abandoning or slowing down our investments in UI5. SAP Fiori fundamentals is a library of stylesheets and HTML tags that developers can use and extend to build Fiori apps in their preferred UI framework. It is open sourced to enable our various product teams, our customers and our partners to quickly extend the library and evolve SAP Fiori in any web-based technology.

For designers and developers

In addition, we plan to redesign the Fiori Guidelines to support our two main personas: the designer and the developer.  The designer path will contain the guidelines, stencils, tools, and plugins needed to easily create experiences using the Fiori design language. We will also provide Sketch plug-ins so that they can produce Fiori designs with predefined Fiori components. The developer section will contain the guidelines, libraries, and sample code they need to develop apps or applications with Fiori UX, in the technology of their choice. These investments will help SAP deliver a consistent Fiori user experience for our own products AND will enable our partners and customers to adopt Fiori UX for their own applications. 

Try it out today

Please explore SAP Fiori fundamentals and let us know what you think by leaving a comment here below or sending us an email at userexperiencecommunity@sap.com.

Not logged in
  • Juan M   2 days ago

    SAP Fiori fundamentals HTML/CSS seem a bit verbose. Why shall you use

    • Juan M   1 day ago

      Thanks Sebastian. I was saying that the html seems a bit verbose. For example an alert has these classes fd-alert fd-alert–warning fd-alert–dismissible

      Then

    • Juan M   1 day ago

      Thanks Sebastian. I’ll try again 🙂

      I was saying that the HTML seems a bit verbose. For example, in the utility clases a name is fd-has-font-weight-bold, why not use something sorter as fd-text-bold.

      I did not see headers within the components, instead, in utils (https://sap.github.io/fundamental/guides/design-system-utilities.html) we have a p with different sizes (which by the way is not a semantically correct nor accessible).

      Then, it seems that the naming conventions are hard to remember… or inconsistent? For example, in an alert I found fd-alert fd-alert--warning fd-alert--dismissible, in a button fd-alert__close and for icons sap-icon--arrow-right sap-icon--s. That is sometimes we have – as separator, others — and others __. The prefix is fd for all except for icons…

    • Christos Koutsiaris   13 hours ago

      Hi Juan, thanks for your comment. Certainly, there is room for improvement in naming. I will discuss it with the team and plan the next steps. In the meantime, since SAP Fiori fundamentals is an open source project it would be great if you can have a look in the code and create a new issue in github. https://github.com/SAP/fundamental

      Regards

    • Zack Frazier   7 hours ago

      Juan,

      Thanks for the comments. Let me address your feedback.

      We follow a BEM model for naming, which admittedly can be a bit verbose. This approach helps us keep CSS specificity low and maintain a good separation between presentation and layout, where elements tend to be more about layout and modifiers more about the style.

      For example, `alert` is a block, i.e., component. The base component can be modified — `–modifier` — like turning an `alert` yellow as in `fd-alert–warning`. While we try to mimimize presentation classes, sometimes we can’t avoid them like where we must have `fd-alert–dismissible` to properly layout the content and the button inside of the `alert`. You mention the `fd-alert__close`. This is an element, i.e., a child of the block, used only for the button.

      Any icon set could be used with our components so we opted to differentiate the namespace for the SAP icons since we don’t manage the icon set and have no ability to add or modify icons.

      We are open to simplifying the utility classes names but we wanted to follow a logical naming system using actual CSS properties with a recognizable prefix. We use `is-` for states like `is-selected` and `has-` for helpers. The intention is that helper classes should be used sparingly but sometimes you need brute force. Also, we only recently got specs for text headers and will implement those very soon. See https://github.com/SAP/fundamental/issues/745.

      Lastly, there are some discrepancies for sure that we are working through, We will continue to optimize the vocabulary we use, e.g, “warning” vs. “alert”, to match the Fiori standards. As we do that work, we will deprecate some classes over time.

      I hope that helps. With any design system, every choice has many trade-offs. I look forward to gathering more feedback. Please don’t hesitate to contact us.

      Zack