There have been lots of articles around outlining how to adopt Fiori Elements and Fiori Technology in general. However, many organisations still struggle to understand what the pros and cons of adopting Fiori Elements are and when to adopt them and when not. Making these important architectural decisions are left mainly to the development team and preference of the team members dictate the decisions. In this article, I have tried to address this issue and outline what considerations need to be made to facilitate the decision process.

Fiori Elements are design concepts devised by SAP with an objective of Rapid Application Development. The underlying philosophy is that the Businesses do not need to invest significant amount in designing new applications and should be able to roll out new applications within shortest possible time. No wonder, Fiori Elements facilitated by front end or back end annotations have gone a long way in achieving this goal.

At the time of authoring this article, Fiori Elements provide four major floorplans to choose from namely – List Report Object Page, Worklist, Analytical List Page and Overview page. Below is a snapshot from SAP Business Application Studio.

Lets take an example of List Report Object Page. If adopted enterprise wide as a model template to display list of information, it will provide a very consistent look and feels for all applications that are listing information ( claims, purchase orders, people or sales order ).

All applications will inherit default functions such as Search, Filters, File Export, Sorting and Listing Information and will function exactly in similar ways.

This reduces user training efforts from an organisational point of view, reduces maintenance efforts and delivers more with less coding.

While you achieve greater consistency by adopting Fiori Elements as design principles, it comes with sacrifices that the design team must consider.

1. It is very hard to accommodate custom user requirements with smart templates. There are extension options for all the floorplans. However, mixing standard screens with custom views lead to dubious objectives and less harmonious screen flow.
2. Many developers feel that Fiori Elements and smart templates set unrealistic expectation to the stakeholders that UI Design is a trivial task and hence appropriate time is not allocated to validate the user experience.
3. Smart templates also take most controls out of developers hand and in many cases developers look for complex workarounds to resolve simple problems.
4. It can become very tedious and hard to troubleshoot issues when things do go wrong.
5. Fiori Elements is also very much annotation driven and UI Annotations in the CDS Layer play a critical part in terms of how the UI will be generated. It creates a very tight coupling with UI to the back-end design. Any changes in the backend has an impact on how the UI will be rendered.
6. The templates in existence have some slight variations (example – List Report vs  Worklist ). However, they pretty much follow similar flows with only a few options to change. So, when presenting a UI Design to the end users, we can show an option A – however, it is hard to come up with an option B that is significantly different from the first option.

Organisational factors may influence the decision process here – if the Fiori applications being developed have a narrow user base ( administrators and power users for example ) and it is important to develop many applications in a smaller period of time, Fiori Elements or smart templates may be the right way to go.

However, if an organisation is looking to roll out applications to a wider range of people (members of public – claims processing for a government organisation for example) or high profile people ( travel applications for Member of Parliaments for example ) – smart templates may not achieve the end goal ( e.g. accommodating variations or impressing users ). SAPUI5 freestyle applications with careful design thinking may be more appropriate in this instance.

Hence, careful considerations should be made in adopting a UI strategy for SAP Projects taking into context variables suggested in this article to achieve the end goal and be successful.