Skip to Content
Author's profile photo Fábio Luiz Esperati Pagoti

Fiori lie detector

Maury tell us why.

Design Principles

The design philosophy of SAP Fiori is based on five core principles. SAP Fiori user experience is role-based, adaptive, simple, coherent, and delightful.


SAP Fiori is designed for your business, your needs, and how you work. It draws from our broad insights on the multifaceted roles of today’s workforce. SAP Fiori provides the right information at the right time and reflects the way you actually work.


Apart from making you work smarter, SAP Fiori also enriches your work experience by allowing you to simply do your job.


Whether you fulfill a sales order, review your latest KPIs, or manage leave requests – SAP Fiori adheres to a consistent interaction and visual design language. Across the enterprise, you enjoy the same intuitive and consistent experience.


With SAP Fiori, you can complete your job intuitively and quickly. SAP Fiori helps you focus on what is important – essential functions are easy to use and you can personalize the experience to focus on your relevant tasks and activities.


SAP Fiori enables you to work how and where you want, regardless of the device you use. And, it provides relevant information that allows for instant insight.


Is FB01 Role based?‘FB01’)/S6OP

Is MIRO delightful?‘MIRO’)/S6OP

Is MM03 coherent with VA03?‘MM03’)/S6OP‘VA03’)/S6OP
Is J1BTAX simple?‘VF01’)/S6OP

Is VF01 adaptative?‘VF01’)/S6OP

Please SAP, call GUI transactions with a blue background which are opened inside a new browser tab within an iFrame anyhow you want … but not Fiori.

Fiori principles were totally forgotten on such move and even if someone might like the result and want it, you are denying yourself.

Please don’t, just don’t

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jason Scott
      Jason Scott

      Couldn't agree more. Not only is it pathetic... but as a sap consultant it's actually embarrassing!

      Author's profile photo Christian Punz
      Christian Punz

      Agree! bad move by SAP.

      Author's profile photo Former Member
      Former Member

      Fabio, first of all, thank you for defending the principles behind Fiori.  As you would suspect, we tried to be thoughtful in defining these as we started to transform the SAP user experience.  The SAP GUI transactions that make up were developed over 25 years and will take more time for an overhaul.  We were left with a situation where certain scenarios were redesigned in Fiori but many others were not leading to a jarring experience between the new and the old.  We initially kept these very separate to maintain the purity of the new Fiori apps.  Our customers requested a more pragmatic approach of what we call Fiori One Look (also refereed to as visual harmonization).  I have spoken about this a lot recently at TechED and other forums.  First and most importantly, this is a bridge and transition to more redesigned Fiori apps.  There will always be specific transactions that can be improved, but the customer and user feedback has been positive thus far especially combined with SAP Screen Persons.  Second, by separating the design of Fiori from the underlying UI technology, it gives SAP more  flexibility in spreading the impact of Fiori.  On one hand, there are limitations of the underlying technology (like SAP GUI) that prevents us from achieving all of the design principles of Fiori.  On the other hand, it allows us to take the Fiori design language and extend it to Apple and iOS to explore new capabilities not supported by html5.  It also provides a strategy to converge SAP LOB Cloud solutions like SAP Success Factors that was implemented in other UI technologies.  Hope this helps.

      Author's profile photo Michael Appleby
      Michael Appleby

      Having the technical information for configuration and implementation in the Fiori App library is very useful.  Being able to implement T-codes on the Fiori Launchpad has been around for a while, but finding that technical information was not always easy for the specific t-codes.  While it was rather surprising to see the additional 6500 apps suddenly show up, I would think this is a better approach than not having a central repository for Fiori apps.

      So I am somewhat ambivalent about this approach as I share some of Fabio's concerns.  But I'm not sure there was a better option available.  The blog really brought focus and a good discussion to the subject.  I am curious as to what others think would have been a better option to support the t-code apps?

      Thanks, Mike (Moderator - SAP Fiori)
      SAP Technology RIG

      Author's profile photo Former Member
      Former Member

      Hello Sam,

      Thanks a lot for your time explaining the reasons for that.

      I believe most complains about this situation are not due the fact that SAP enabled GUI transactions to be used with this look and feel but the way of explaining it.

      Personally, the very first time I have seen a WDA app inside the Fiori Launchpad with belize theme I was really impressed.

      Definitely opening transactions that we are used to in the browser now might create some resistance, which is natural. I really think that such harmonization might be very useful for some companies although I tend to disagree that it will help spreading the impact of Fiori. My personal opinion is that considering the design principles, those transactions are not Fiori, even with belize or personas. Now it’s written in huge letters that it’s fine to create an executable ABAP program because it will run inside Fiori. Why would someone need UI5 or iOS? Are the reasons good enough to convince the ecosystem?

      Nobody can argue with the fact that SAP is doing a great job in terms of new apps developing. On average, SAP has been delivering 1+ app each day for at last 1 year. To that extend, I also believe that this is transition and sooner or later, those apps will become obsolete.

      However, the impression given documenting every transaction in the Fiori Apps Library is that SAP will market it as if it were true that there are 7000+ apps now, which is far from been the truth. It gives the message that the most important aspect of Fiori now with S/4 is the number of apps. Another way of viewing it is that Fiori 2.0 although looks great, also adds a change in what everyone knows and understands about the Fiori concept.

      By the way, there were already WDA aplications registered in the library months ago – as they were 50 out or 1100, nobody really cared if the catalog was being reused for other means. Now, for historical reasons SAP tell us that 6000 out of 7000 apps do not follow its own design principles and guidelines and everyone should be convinced that they do follow as there is a version 2.0 of that principle.

      SAP, why not renaming the website to “Fiori-like” Apps Library? ? We have heard this term so often when Fiori was launched and even nowadays. Definitely it would be a better name making a bad (but real) impression. And that rebranding would be just fine as it would be just another stuff that has its name changed by SAP ?

      Again, thanks a lot for your time to answer this topic which is definitely important. Every person who read us is specially interested and hope for the best of SAP and Fiori. The next weeks are very important for the community to get a feel of how SAP will brand all this.


      Author's profile photo Christopher Solomon
      Christopher Solomon

      “Now it’s written in huge letters that it’s fine to create an executable ABAP program because it will run inside Fiori. ”

      Uh oh!!! 

      You just enabled an army of people to run and go add “Fiori Developer” to their resume! (haha)

      I am actually NOT kidding…THAT will happen now.

      Author's profile photo Former Member
      Former Member

      Haha. That’s ok. It seems to be the strategy in the mid term.

      Actually, they will add (Senior) Fiori Developer.

      Jokes aside… I really believe lots of customer will think like that.

      Author's profile photo Custodio de Oliveira
      Custodio de Oliveira

      I’ve already updated my LinkedIn profile: “Fiori Development: 18 year of experience”

      Author's profile photo Jose Nunes
      Jose Nunes

      LOL, for sure it will happen, Chris.

      Well, speaking of principles is weird, specially when you lay them down and them you crush them.

      Anyway, that`s fine, we're in a constant change anyway.

      Author's profile photo Helmut Tammen
      Helmut Tammen

      Hi Fabio,

      I totally agree with you. In my opinion it's greywashing of the existing ABAP transactions. Why does SAP do that?

      • Did they realize that it takes too long to convert all these old applications to Fiori apps?
      • Do they, like Bill McDermott recently announced in an interview with the german Handelsblatt, invest all they have in AI, so that there is no more money for Fiori?
      • Are they already working on the next step of UX based on React, Elm or whatever and need a means to quickly close their Fiori journey?

      Anyway, this decision does not help Fiori. It helps the old ABAP Dynpro developers. They tell their customers and bosses: "Look, we are developing Fiori apps now. So don't tell us to learn Javascript."

      Although there might be explanations (no reasons) for this step, it was a bad one. Reminds me to the move to Java about 15 years ago. After SAP realized that they couldn't move their ABAP developers to Java they stopped the Java initiative (best example is Web Dynpro for Java).
      It's really a pitty but some of my customers who say: "SAP is no UI company and will never be" seem to be right another time.

      Author's profile photo Michael Devine
      Michael Devine

      As per the SAP UI Roadmap 2015, it was mentioned to : Create New Applications in Fiori, Renew existing Applications ( if possible )in Fiori and Enable existing Applications for Fiori.....

      Author's profile photo Guilherme Lahr
      Guilherme Lahr

      SAP being SAP.
      I would love to see a screenshot of a Dump in belize.

      Author's profile photo Joachim Rees
      Joachim Rees

      No problem, here you go:


      (Not THAT impressive, is it?)

      It's SAP_UI 752, on SAP BC6.5.



      Author's profile photo Former Member
      Former Member

      Agree with you Fabio.  Why does SAP have SAP Design Fiori Guidelines only to "break" them?  It was bad enough when web Dynpro started to appear in the sapfiorilibrary, then we had the watering down of the definition of what Fiori is and now we have the personas/sapgui "apps".  For me Fiori has no clear definition anymore, no guidelines being followed and basically SAP Fiori has been put into the trash along with everything thing else that shares a similar theme?

      I disagree with the comment of SAP has been fast in producing new Fiori apps,  when so many modules still have close to no Fiori apps (PM, MM for example).  It is nice to see the cloud solutions (support etc) get Fiorised and I guess if those developers had been working on ERP/S4 whatever apps instead we would have seen much better fiori coverage.  It also appears that SAP is now hiring Fiori developers with more urgency than before but that is a couple of years too late IMO.

      Author's profile photo Bruno Lucattelli
      Bruno Lucattelli

      For too many years X11 was a mess for both beginners and experienced Linux users. This is not completely resolved by now, but it has improved a lot.

      Why am I talking about X11? Because I believe that we can learn something from it and apply to our reality with SAPgui and Fiori.

      X11 provides a great way for newbies to use Linux. But there's a problem: you can't do ALL in X11, mostly because there's a lot of old, legacy and stable code that runs on the terminal only. And even if you could (as you many times can) use the terminal software as an API or a SVC to support GUI applications that run in X11, it took a lot of work to do.

      That's the scenario with real Fiori Apps. We can only do so much with them. And there's still a LOT that ERP does that's stuck in ABAP Module Pools and Function Groups that are stable solid and trusted by experienced users.

      As users cannot rely on X11 only to use Linux adoption was slower than expected. And, as software developers couldn't convert all terminal code to X11 code, they came up with an idea: to put a X11 terminal (XTerm and others) inside X11. Now, whenever the user needed to perform something inside X11 that didn't have a GUI program for it, they could use the terminal.

      That didn't solve the problem for newbies, but definitely brought "good positive feedback" from the experienced users, which at the time were the vast majority of the community. Developers got the heat out of their backs and went back to normal activities.

      This is what's happening now with Fiori. We are quieting the experienced users by giving them inside Fiori what they already have in SAPgui. In other words, just like hardcore Linux users, they now can benefit from the new features of Fiori (GUI) while bringing the knowledge that they already have and love from SAPgui (Terminal).

      The thing is: a Terminal app isn't a GUI one. And, if the original idea of the X11 project was to create the best UX possible, then this idea of bringing the Terminal to X11 wasn't helping much. But the effects of this decision went far deeper into the following years of X11. It definitely helped Linux bring many experienced Terminal users to X11, but it did little to the newbies. In fact, it slowed down the process of replacing Terminal with GUI, because now every time a user poked a developer, asking for a solution to a NotImplementedGuiFeature (LOL), there's an alternative a developer can suggest, no matter how bad it is.

      As software developers, we know that the features that are implemented first are the ones the user cannot live without. Terminal apps removed that urgency tag from it. Once urgency is removed, it goes straight to the back of the line. SAPgui in FLP performs a similar effect.

      I trully understand why SAP is bringing SAPgui to Fiori Launchpad. It will help adoption rate increase. And this is a good thing for us. But I have to ask: SAP, please do not slow down the development rate for Fiori Apps. Create Sales Order is MUCH better than VA01 for newbies. It's also great to see buyers using Create Purchase Requisition. I want to see the other users as pleased as these, even knowing that there's a Terminal app SAPgui TRX running in FLP that can be used as well.

      Fiori is about the new SAP UX, and just like X11, it will make it more pleasant, easy, simple and fast. SAPgui TRX will always be used by some old school users as they will become some sort of "SAP hackers". But we cannot forget what Fiori is all about.

      Author's profile photo Jeremy Good
      Jeremy Good

      Connecting the blog from Maricel to this active discussion:

      Author's profile photo Former Member
      Former Member

      Hi Fabio, thanks heaps for your blog.  I liked it so much I was inspired to write my own opinion piece here with a link back to your blog.  Since I wrote that piece, I’m now wondering if SAP could improve the transparency by adding some KPI tiles on the home page of the Fiori Apps Library (that is assuming they won’t change the name of that site).  A tile for the number of Fiori transactional apps, Fiori analytics apps, classic transactions, web dynpro, etc.  At least that would make it very transparent, and we don’t lose the inherent ‘feature’ we used to have by navigating to the site to see how many Fiori apps had been created.  With the current state of the site, you need to go through quite a few button clicks to determine where SAP is with Fiori apps – that isn’t a good UX!


      Author's profile photo Robbie Watson
      Robbie Watson

      If you take any individual transaction by itself then I see your point.

      However, it is important to point out, not all transactions in S/4 1610 have been added to the Fiori App Reference Library.


      Well, the Fiori theme for Classical apps looks great and provides a bridge as SAP continue to execute on it Design and User experience vision at an impressive pace. However, It is not the look and feel that is the important part.

      It is (from my point of view) that these transactions have been delivered as part of 100’s of Standard Business roles and include app descriptors that allow seamless, intuitive and efficient navigation between information and tasks in S/4 1610.

      This takes full advantage of innovations delivered through the SAP Fiori Launchpad. For example:-

      • Powerful search capability to quickly get access to real-time information and tasks.
      • Access to information and tasks via Alerts and Notifications pushed to users through events and KPI tiles informing users of a critical situation.
      • Simplified navigation forward and back between information, analytics and tasks and in context, which provides an intuitive experience.

      So, let’s ask again. Does the inclusion of these classical apps support the Fiori Design Principles?

      • Role Based – Designed for an end user, addressing your needs and how you work.
      • Simple – Focuses on the important items providing you with the information you need for the task in hand.
      • Coherent – Provides a fluid, intuitive and single experience enhances by the new Fiori theme for S/4 Classical transactions.
      • Delightful – Making an emotional connection by allowing the end user to perform their tasks more efficiently and more effectively.
      • Adaptive, I may concede this one…. Although at a stretch the new visual theme considerable reduces the amount of white space that previously existed for a desktop user.

      I would have to say, yes!