This blog is a follow up on my previous blog, where I introduced the project scope, approach, etc. I think this blog makes more sense after reading the previous one.

As mentioned, the most exciting aspect of this project was the responsive design for “all newer browsers” on desktop, tablet and smartphone. This resulted in a css with several thousands of line of code and we even had a review session with a css expert, who suggested tricks like replacing gradient borders with before selector.

Some more design lessons learned

  • It is hard to create a site which makes use of the screen property in an optimal way on all screen formats. It required a lot of interaction among designers, users and developers. Testing is a big challenge. We used browserstack which allows for virtual testing on many devices and operating systems. For the most used devices, think of IPhone, iPad, Samsung Galaxy, etc, we used physical devices for testing. Browsertack did a 99% job, but for these top devices we aimed to know with 100% certainty what works and what not.
  • The designer came up with a dropdown hover menu for desktop and a separate touch-based menu for phones. Since tablets don’t support hover, we used the touch-based menu for tablets too.
  • In order to handle all the different formats, we used a combination of two approaches for the css. We detect the device (e.g. sap.ui.Device.system.desktop) and also the screen width ($(window).width()). We have to know if the user has e.g. a large tablet (big widths, but touch) or a small monitor (small width, but hover), etc. to offer the optimal design.

Some more technical lessons learned

  • The Application Cache Buster introduced a significant improvement to the performance. We turned it on for production, but left the development system without it.
  • Still, the initial load of the SAPUI5 libraries takes some time. I understand SAP is working on this area. We just adopted a simple technique described by Konstantin Anikeev: we added a spinning wheel and load the SAPUI5 libraries as described in the blog. From a user point of view, this was a huge improvement.
  • We integrated Google Analytics as described by Craig Gutjahr in his blog. We raise our own events and I must say the business loves to see the usage in the real time dashboard. It was also very useful for the go-live, because we could monitor how the usage was taking up.
  • We created a deployment script. It does some adjustments to the code, which are necessary before transporting to production. One example is to minify the code. We use yuicompressor.

As always, I am curious if you recognize these points or your experience is different.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Jason Moors

    Hi Tamas,

    Thanks for sharing your experience, I’m interested in your comment regarding the Application cache buster and how it improved performance.

    My understanding was that the cache buster provided a mechanism to create a new url and avoid the browser caching out of date versions of files until the cache expired.

    I would expect the browser to cache the files for a certain duration without the cache buster, therefore wondered if you know how it actually improves the perormance?

    Many thanks,


    1. Tamas Szirtes

      Hi Jason,

      Your understanding is correct, I should have put it more clearly. The browser cache was giving us a lot of problems, we had to delete it all the time. I must say especially in IE. (IE11 even tried to cache the OData requests, so we had to set no caching in the HTTP response.) This Application Cache Buster tackles this issue, the right items are cached, so users can enjoy the performance benefits of correct caching.




Leave a Reply