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.
