Ever since SAP announced the release of Fiori earlier this year I've been excited by the prospect of a renaissance in SAP's UX/UI future. The apps look gorgeous and the fact that they are positioned around HTML5 technologies (SAPUI5) and multi-channel support (eg. smartphones, tablets, desktops) makes them well positioned for the future.
And I was further impressed to see SAP make bold statements such as this one when I attended SAP TechEd 2013 in Las Vegas (the below from the session 'TEC149 - SAP UX Strategy and UI Roadmap') ...
"All applications & UI technologies to converge to the Fiori concept. The roadmap beyond the initial Suite applications is yet to be defined."
(Source: Slide TEC149 page 62, SAP TechEd 2013 Las Vegas)
Oh, let's not forget the fine print ... "This is the current state of planning and may be changed by SAP at any time".
But ever since I saw the first live demonstration of Fiori apps by an SAP representative, there is one thing that I've been a little uneasy about, and its this ... I noticed it took a fair amount of time (and by that I mean well over 10 seconds) for the app to appear on a mobile device after being launched. And I cast my mind back over a decade to the words of the usability guru Dr Jakob Nielson in his book 'Designing Web Usability' from 1999, where he makes this important observation based on usability studies ...
"Download times rule the Web, and since most users have access speeds on the order of 28.8 kbps, Web pages can be no more than 3 KB if they are to download in one second .... Users do not keep their attention on the page if downloading exceeds 10 seconds, corresponding to 30 KB at modem speed. "
Source: Dr Jakob Nielson, 'Designing Web Usability' 1999
Now of course over a decade on from those observations, we no longer operate in a world of modems or 30KB websites. Yet the world of mobile and slow or brittle networks has brought back similar challenges, and once again we need to be mindful of the need for lean web delivery. Indeed some have taken it a little far with statements such as this (below someone quoting on Twitter what they heard at a conference) ...
"You should never use a JavaScript library that you couldn't store in the RAM of a Commodore 64." (Source: unknown)
On a side note ... if you are my vintage, you may remember that whilst a Commodore 64 had 64K or RAM, the available amount for the user was only 38K. And if you want to be really nostalgic, try out this Commodore 64 emulator that someone wrote in HTML5 and JavaScript http://www.kingsquare.nl/jsc64. But back to my point ...
The current literature on the web describes Fiori as a set of 'lightweight' consumer-friendly applications from SAP. But my anecdotal observations had me asking myself just how lightweight are these apps, from a client payload perspective? So, I have had debates recently about how lean the Fiori apps (and the underlying SAPUI5 libraries) really are. Or more accurately whether they should be leaner to improve the time to load Fiori app resources into the browser, and by extension improve the user experience. Of course, that's easier said than done when you want to build in a wealth of 'enterprise-grade' features ... but that is the challenge for the engineers at SAP to tackle.
I discussed this with nstabell from Neptune Software who I met at TechEd and has deep experience with SAPUI5. He wrote a blog providing his analysis of how a custom SAPUI5 app would outperform an equivalent Web Dynpro ABAP app here ... Performance comparison of ABAP WebDynpro and SAPUI5 with Neptune Application Designer. But what was still missing was an analysis of Fiori apps against the equivalent Web Dynpro ABAP counterparts.
So recently I had the opportunity to implement some SAP Fiori apps for trial purposes, and at the same time measure such things as the performance and download size of the apps. I was also able to compare against the equivalent Web Dynpro ABAP app provided by SAP. Here are my findings...
Firstly I examined the payload to download the out-of-box SAP Fiori leave request app to a browser with an empty cache.
In the above test (which I repeated half a dozen times) I noticed that a whopping 1MB (after 72% compression) of download with 84 separate HTTP requests is received the first time a browser attempts to render the Fiori leave request app. Similar measurements were obtained for others, such as the leave approval app. In the above test the payload takes 14 seconds to retrieve over a high speed LAN. However I also tested the worst case (which mobiles can sometimes exhibit) ... satellite access with 600ms latency. In this worst case scenario, the download took closer to 100 seconds to retrieve.
Next I examined the payload to download the equivalent out-of-box Web Dynpro ABAP leave request app with an empty browser cache.
So the Web Dynpro ABAP leave request app delivered by SAP renders with around 280K of payload over 65 HTTP requests. In the above test the data takes 9 seconds to retrieve.
Effectively the Fiori leave app had a payload of almost four times that of the equivalent Web Dynpro ABAP leave app, with almost 30% more HTTP requests. When the browser cache is full (ie. after first load), performance for both the Fiori app and Web Dynpro app is much better.
What I want to see in Fiori
I am an advocate of HTML5 (see my recent presentation on it) and by extension I believe that SAP's foray into HTML5-based apps with Fiori and SAPUI5 is the appropriate approach, especially when combined with pace layering enablers such as NetWeaver Gateway. However, here's what I would like to see in Fiori ...
Basically, we find that whilst this first release of Fiori apps brings gorgeous design and an appropriate way forward, more attention needs to be paid to the user experience from the perspective of time to load the app. All is well if you operate with fast networks to desktops. But if serving these apps to remote locations or mobile devices, then other measures (eg. wrapping the Fiori apps in PhoneGap or SAP's Kapsel) may be necessary (with the associated complexities and costs, such as potentially implementing SAP Mobile Platform if the use of Kapsel is desired). In fact, that may explain why in recent SAP demonstrations of Fiori on mobiles, I have seen SAP demo with precisely this wrapping implemented - there is no initial delay in rendering the app. Of course, when comparing with SAP's Web Dynpro ABAP we are looking at a much more mature technology. And SAP sought to optimise WDA over time ... such as with the introduction of lightspeed rendering. (and in an ironic twist, andreas.kunz tells me the original codename for SAPUI5 was 'Phoenix', and that name was derived based on what is faster than light speed .... being warp speed, which any Trekkers amongst you know was achieved by the spaceship Phoenix in the movie 'Star Trek: First Contact').
What would I like SAP to do? Well, provide a mechanism in the ICF to only serve what is necessary, and to consolidate resources to minimise HTTP requests and minify resources. For instance, a mechanism to automatically combine and minify JavaScript and CSS files etc. Don't think it is possible? Well Google engineers pulled it off with their open source contribution of Google PageSpeed Module for Apache and Nginx web servers. So I'm sure SAP's engineers would be equally capable. Or the open source community might. In fact in the blog 13 reasons why SAP should open-source SAPUI5 by jan.penninkhof2 there is a similar comment provided by msaads...
In the course of research for this blog I noticed also similar concerns were raised by tobias.hofmann in this blog ... Remember, all I'm offering is the truth – nothing more – week 5
So there we have it. Fiori delivers great looking apps. But from my perspective, if SAP is to be successful in the long run with Fiori, it needs to be lean, fast, and perfectly tuned for the environment it is built for .... to run better, like a Ferrari! Lets hope SAP can take us there ..... fast.
- SAP Managed Tags:
60 Comments
