What is SAP Fiori? Maybe it’s more than you think

I was fortunate enough to be invited to participate in the Bloggers Program at SAP TechEd in Las Vegas last week.

Among lots of interesting topics Fiori was one of the most discussed and debated. In fact a repeat of a 2 hour hands-on session scheduled on the Friday morning was filled to overflowing – quite an achievement when you consider many delegates choose to start their trip home on Thursday evening or Friday morning.

When the term “Fiori” comes up most people think about the 25 apps that were delivered as part of  what is now called “Fiori Wave 1” or of the distinctive look and feel of these Fiori apps themselves. *Fiori Wave 2 will arrive soon to be followed by Wave 3, etc.

But Fiori means more than that. It is a fundamental change to the way SAP are looking at delivering user experiences across much of the SAP product portfolio and it is also more than a few CSS style sheets and some Javascript.

Along with the Fiori look and feel comes something I have heard described as the “Fiori style” or “Fiori approach”.

In a recent discussion with Sam Yen, the global head of design and user experience at SAP, and Adi Kavaler, the SAP Product Manager responsible for Fiori, they referred to the “Fiori Design Principles”. These principles are being applied to all the new Fiori apps that are currently under development – look for announcements soon.

The above slide I lifted from the SAP TechEd handouts comes close to capturing the details of this discussion – or at least most closely relates to my notes.

Not surprisingly the first of these design principles is that the screens should support all device types, screen sizes, form factors, versions and channels. Of course implicit in this is a “mobile first” principle as well. This means “responsive” design where a single code base produces a client experience that adjusts to best support the device characteristics. For example a tabular display should not be wider than the device width so the user does not have to scroll horizontally. So using responsive design techniques less important columns can be suppressed or rendered across multiple lines based upon the available screen width. This is a feature that is delivered as part of the mobile controls delivered in the SAPUI5 library. For a SAPUI5 working example go here and start resizing your browser window to see how the layout adjusts in response to the changing screen width.

Another design principle is to break a business function down into small independent pieces and build a UX for each piece. That is in stark contrast to how SAP have traditionally built Dynpro transaction screens – and Web Dynpro screen as well for that matter.

Take the example of the transactions for working with purchase orders in ERP. Sure there are different transaction codes for create, display and change of a PO – but they are really the same program with different entry points. SAP built a monolithic program for everyone who might need to touch a purchase order – a classic example of code reuse contributing to end user confusion. Because the PO transaction screens allow you to do absolutely anything you ever wanted to do with a PO it is a mass of different navigation areas, toolbars, menus, tab strips, drop downs, tables, etc. It is a screen that no one could navigate without at least some training – probably quite a lot.

The Fiori Design Principles call for a much more focused user experience targeted at a single role and user. This means that each app is designed with much more conservative and practical goals and does not aim to be all things to all people.

SAP advocate a design principle known as 1-1-3 (“one one three”). This means each screen should be designed with a single user (or role) in mind, a single task that this user wants to accomplish, and a maximum of three levels of navigation to perform this task.

Another design principle is that the apps should all have consistent look and feel, navigation principles, etc. So, for example, if we decide that clicking on a header record should navigate directly to the item records then we implement this feature identically everywhere so the users intuitively know how to drill down to item level in every app. This is what is described in the above slide as “coherence”.

And finally the apps should be able to be delivered quickly and easily to provide instant value and the lowest possible barriers to adoption. SAP primarily achieve this by using NetWeaver Gateway to publish lightweight web services at the backend and the SAPUI5 libraries to build the user interfaces that consume these services. Both these technologies are readily available for the vast majority of existing SAP customers. I don’t know how far back the SAP Fiori apps will successfully run on older versions of Business Suite, but the SAPUI5 library and NetWeaver Gateway technology are available to all customers.

I can’t argue with any of these design principles – after all they are pretty close to the same UI design principles I have been advocating and implementing for many years. On top of that I can take the SAPUI5 libraries and construct my own apps using the Fiori look and feel and add them to the Fiori Launchpad.

IMO – all good stuff.