Skip to Content

Integration and consistency a core strength of SAP

One of the biggest strengths of SAP’s Business Suite and other software developed on top of SAP technology, by SAP themselves or independent software vendors (ISVs), is the seamless integration of applications. This means not only integration at the technical level, but also a consistent user experience across applications.

Consistent user experience and the benefits

A consistent user experience means that all the user interfaces the user sees follow the same intuitive rule set. Working with one application, the user gets an intuitive grasp of interaction patterns, icon meanings, and screen design patterns. Dipping into neighbouring applications (for example, an HR user follows the payroll money into the FI application, or a CRM user maintains Business Partner master data), the user is supposed to find all applications to behave alike. We all know how to create a new object in an SAP transaction, and how to cancel that transaction without saving, how to navigate the details screens of a business object, and how to locate an object in the locator area of the screen. That’s called a consistent user experience.

The benefits of a consistent user experiences are: fewer handling errors, improved data quality, more efficient handling, more business transactions processed per salary dollar, reduced training costs, happy and motivated users.

Achieved with the help of standards and guidelines

In spite of the huge number of developers working on SAP applications, SAP has managed quite well to establish that consistent user experience in the SAPGui-based applications. There are of course slight differences between the most recent applications and those created 25 years ago, but most old UIs were renovated and polished up in recent years, levelling those differences.

This has worked so well because there were always UI standards the developers could refer to. If you were a developer at SAP, you had to follow the currently valid UI standards because otherwise your software wouldn’t be allowed to ship. If you were an ISV, breaking UI standards meant that SAP would withhold their solution management seal, which might also result in the application not shipping. If you were a customer paying consultants and developers for in-house development, making those UI design guidelines binding would be the smart thing to do. Outside SAP, you had to put up with versions of SAP’s UI style guide that were officially outdated, but okay to work with. You could (and still can) find them at http://www.sapdesignguild.org/.

Enter Web Dynpro

Now when my company decided to start a really large new NetWeaver-based application development project, for which my esteemed colleague Tobias Trapp and I have the privilege to develop the architecture and technical design, we decided to develop the majority of the user interfaces with Web Dynpro (both ABAP and Java) in accordance with SAP’s UI strategy.

One of my first actions in preparations for the project was to search http://www.sapdesignguild.org/ for the most recent Web Dynpro UI style guide. Imagine my disbelief and shock when I found plenty of interesting articles about UI design, but nothing about Web Dynpro that was even remotely comparable to the SAPGui-related style guides. I came back the next day to search some more because I thought I must have missed it, but after a while I resigned.

Then I wrote an email to the good people of the SAP Design Guild and asked them where I could find the UI style guide, which I was sure must be accessible somewhere. After all, for how many years has Web Dynpro been around? At least since release 6.40 or NetWeaver 2004. They were nice enough to forward my email to someone else at SAP, and shortly thereafter I received an email from an SAP employee (a vice president, which I read as “middle management”) who regretted that currently there was no publicly available style guide, but that they were trying hard to release one by Autumn 2009. (This was in April.)

Now please don’t misunderstand me: Nothing would be farther from my intentions than back-stabbing these friendly and helpful people by complaining about their responses. Quite probably, they’re working as hard as possible with the team size and priorities assigned to them by senior management.

So, dear senior management at SAP, please consider this:

SAP has been using Web Dynpro for years. Customers and partners have been pressed to adopt it, which is all good and well. But when using it to develop new applications, what we don’t want is

  • to spend a lot of money on performing a task that has been performed exactly alike a dozen times before (writing a new style guide)
  • to develop your own idiosyncratic and possibly quite odd style guide which will cause your applications to deviate from the future standard of SAP’s Web-Dynpro-based business applications.

Standardization at the core of the SAP UI design model

Let’s go back for a moment and consider some of the key benefits of Web Dynpro. If you want a free-form desktop or web application, you’re not going to use Web Dynpro. If you want to use the full freedom of expression of HTML, use BSPs or JSPs or any other HTML-based development framework for your application. On the other hand, if you want a standardized look and feel that does not allow the developer to choose their favourite font and size, colour, and button shape, but achieves UI standardization and harmonization across applications by means of a reduced set of design elements and layouts, SAPGui and Web Dynpro are the right choice. You have less freedom in designing the UI, but developing it is also very simple, consumes much less time and requires no HTML or AJAX skills.

This explains why it is very important that SAP reveal their Web Dynpro design guidelines so that everyone outside is able to develop applications that provide a consistent user experience with the main body of SAP’s own application. SAP should have done so years ago. UI style guides for Web Dynpro should have been a core product feature of Web Dynpro and should thus have been available right from the start.

Costly and annoying consequences

For our project, this means that we might have to change the Web Dynpro UIs after the style guide has been released in autumn. We’re lucky that it is going to be completed shipped after the release of the style guide because this mean that we will have a chance to adapt our UIs to the standards. Hopefully these changes will only be superficial. However, in order to anticipate as much as possible and keep the changes as superficial, we will have to write our own preliminary UI style guide, which costs time and money we would rather use for other things.

I really don’t understand why it takes SAP well three years to release a style guide, given the importance of a standard look and feel in the SAP world. I think it shows that the priorities were set wrongly, and that the needs of customers and partners were not properly recognized in the process.

My last plea: After the long wait, the first ever released Web Dynpro UI style guide better be good. I hope it will be as down-to-earth and immediately applicable as the publicly available UI style guide for ABAP Dynpro in SAPGui, which his marked obsolete, but consistent with current SAPGui applications – but that is a different story.

To report this post you need to login first.

7 Comments

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

  1. Susan Keohan
    Thorsten,
    Although my experience with WD4A is practically nil, I hope to change that, and with the help of the forthcoming style guide. 
    Thanks for taking the time to write such a well thought blog!
    Keep us posted,
    Sue
    (0) 
  2. Stefan Riedel-Seifert
    SAP is not able to provide a stable standalone theme editor. Why a style guide?

    WebDynpro in my opinion is stillborn. Too much academic complexity on the server side. No flexibility on the clientside. No performance so far. May be better with the lightspeed renderer, but too late.

    (0) 
    1. Thorsten Franz
      Post author
      Hi Stefan,
      SAP is very well able to put a style guide. This is not a matter of incompetence, it just seems that sometimes they think they’re the only software vendor on earth and must be nagged a bit to understand that other software vendors in the SAP ecosystems need certain kind of information and support.
      As far as your criticism of Web Dynpro is concerned, I don’t see too much academic complexity in the design time (not sure if you mean the run time, though, because you say “on the server side”?). I find developing Web Dynpro UIs quite straightforward. As far as performance and flexibility is concerned, it seems that SAP have understood the weaknesses of the current versions because the NetWeaver Business Client 3.0, which will go into ramp-up in December.
      Cheers,
      Thorsten
      (0) 
  3. Sergio Ferrari
    Hi Thorsten,
    I appreciated your blog and I would like to share with you the point that instead of publishing a “guide” SAP took the control via the FLOORPLAN MANAGER (FPM) FOR WEB DYNPRO ABAP http://help.sap.com/saphelp_nw70ehp1/helpdata/en/9f/95467bbefc4a808fffeba4c5177258/frameset.htm

      Implementing WDA based on FPM the style of the resulting application is compliant by default.
      Title, Toolbar, messagearea and so on are placed in the window by the FPM framework.

      For sure a smaller style guide could be useful also in FPM ….

    Sergio

    (0) 
    1. Thorsten Franz
      Post author
      Hi Sergio,
      You’re right, the FPM for ABAP reduces the need for a style guide for Web Dynpro ABAP applications. Thanks for pointing that out. Sadly, it seems that nothing comparable is planned for Web Dynpro Java and Visual Composer, although I think it would be of great use at least for Web Dynpro Java.
      Best regards,
      Thorsten
      (0) 

Leave a Reply