Section 5.6. The UI layer

5.6. The UI layer

One of ESA's primary goals is to make standard software more powerful at every level. Using enterprise services and process orchestration, a given set of service providers, leveraged by composite applications, will be able to meet more requirements than traditional forms of enterprise applications. More processes will be automated. More people will be involved as users, not just as experts. More value will result.

Implied in this expansion of value, however, is another expansion, an expansion of do-it-yourself capability. SAP is creating ESA so that standard enterprise software can solve many more business problems. Delivering enterprise applications using enterprise services provides access to the building blocks that allow more processes to be automated. To automate a new process, existing services must be orchestrated and new UIs must be created to serve the needs of each role in the process. But who will do this orchestration and who will create these UIs? SAP, of course, will provide standard business applications built on enterprise services. Third parties will use enterprise services to add their own applications, building on SAP's suite of services. And IT departments will be able to automate new processes much more quickly and easily using enterprise services and model-driven development tools.

This change will involve an interesting transformation of the UI layer. More than 100,000 different UI screens came with SAP R/3. SAP has studied these UIs and discovered patterns that will allow the same functionality to be delivered in fewer than 10,000 screens. But under ESA, many new processes will be automated, which will result in a significant number of role-based UIs. Supply Chain Management (SCM) will be needed for every role in every process. The typical user will interact with many more UIs than is currently typically the case.

SAP will not construct these UIs, however; customers will, using the techniques described in this section.

For the UI layer under ESA, this means the following:

• Productivity in creating UIs must increase to avoid a development bottleneck.

• The new UIs must be easier to maintain to avoid a large maintenance burden.

• UIs must be created according to familiar structures and patterns to reduce the need for training for new populations of users.

• Users must find a way to manage their interaction with a larger number of UIs representing the larger number of roles they may play in automated processes.

In order to succeed, ESA's UI layer must meet all of these challenges.

As the following set of questions and answers will explain, ESA's approach to building UIs uses a combination of techniques based on modeling, standard UI building blocks, the use of patterns to increase development productivity, an expansion of the potential pool of developers, and a reduction in the burden of training and maintenance.

5.6.1. How will the UI layer change in ESA?

The biggest change in the UI layer under ESA is a wholesale introduction of modeling as a development method. SAP NetWeaver Visual Composer will be the primary modeling tool and UI patterns will be used to amplify productivity. The details of these two changes will be explained shortly, but their effect on how UIs will be structured is shown thematically in Figure 5-13.

Figure 5-13. UI transformation under ESA

The message of Figure 5-13 is that as automation increases, the domain of the expert user becomes smaller as more users are able to meet their own needs. The interaction center box can be seen as a proxy for the way patterns standardize the operation of UIs so that the same common structures can be used repeatedly to solve new problems. Self-service means that users who are now asking others to do work for them through communication with call centers or with experts of some sort will do the work for themselves.

Replacing traditional sorts of coding with model-driven development offers several advantages:

• More than ever before, the UI will be decoupled from the underlying application functionality. Many UIs for different purposes may be powered by the same set of enterprise services.

• Modeling will make UIs more platform independent than ever before. The abstractions combined using visual tools will be captured in a visual composition language that can be rendered into any number of forms.

• Developer productivity will increase while maintenance and training costs will decrease because patterns for standard forms of UIs will streamline the process. Patterns give developers a running start and users a familiar structure.

• Based on modeling, pattern-based UI building blocks, and UIs automatically created from enterprise service interfaces, UIs may be generated on the fly in response to exceptions containing just the right information to allow a user to resolve a problem. While this may be a way off, it is not implausible and it shows the power of modeling and patterns.

These claims are dramatic, but in order to understand them better and to add to their credibility, it is important that we explain how this will happen.

5.6.2. How will modeling be used to create the UI layer?

SAP NetWeaver Visual Composer, shown in Figure 5-14, is a primary modeling tool for creating UIs under ESA. SAP NetWeaver Visual Composer is used to build all sorts of different applications, including UIs for the SAP NetWeaver Portal, analytical applications, and other, more complicated composite applications. Our goal is not to document the detailed workings of SAP NetWeaver Visual Composer, but rather to explain at a high level how it works and why it will achieve the goals of ESA.

The first thing to understand is that SAP NetWeaver Visual Composer will be used in ESA in two ways. Freestyle modeling is what most people think of when they think of modeling. In freestyle modeling, some sort of tool is used to create relationships with modeling primitives. In the case of SAP NetWeaver Visual Composer, the tool is a visual editing environment that runs on the browser, and the modeling primitives are UI elements and enterprise services. The relationships among the elements are captured in a visual composition language. When it comes time to run the UI, the visual composition language is rendered into some executable form. In the case of SAP UIs, iViews that run in the SAP NetWeaver Portal are frequently in the executable form, but not always. For example, for some applications the visual composition language was rendered into Adobe's Flex environment for building UIs.

Figure 5-14. Visual Composer

Freestyle modeling starts to meet several of the challenges facing the UI layer. Development using visual methods is generally simpler, which improves productivity and expands the pool of developers from engineers to business analysts. The visual composition language separates the definition of an application from the implementation. The visual composition language can be rendered into many different forms for execution. Basing the application on enterprise services provides a clear separation from the service providers.

But freestyle modeling is not enough to meet all of the challenges. UI building blocks and patterns must be used to amplify the power of freestyle modeling and further reduce the training and maintenance burden, as the next question and answer will show.

5.6.3. What are patterns and UI building blocks?

UI building blocks and patterns complete the journey to a UI layer that meets the needs of ESA. What are they anyway, and how do they work?

As mentioned in Chapter 4, patterns have had a profound influence on software development for many years. For the purposes of UIs, a pattern is a relationship between certain components that is found to be repeated over and over again in various UIs. Patterns are useful because they can become the starting point for development. While developers use single UI elements such as buttons, text fields, and tables and then combine them in freestyle development, a single pattern may contain tens or hundreds of UI elements already connected to solve some common purpose.

For example, the tab pattern is one of the most commonly used patterns; it's used in Microsoft Windows for settings in the Control Panel such as Display Properties. At the top of the window is a set of tabs that represent different sections of an application or web site. When one of the tabs is clicked, the display changes to indicate that the tab is now active. When a UI developer realizes that a pattern may be useful, he may select a pattern and configure it for a particular use. Configuration of the tab pattern may mean determining the number of tabs and the name of each tab.

SAP's approach to UIs has three levels of patterns:

UI pattern elements

These patterns have the smallest scope and are made up of basic UI elements, such as buttons, tables, trees, and such. They are configurable and reusable and include such elements as forms, lists, and object searches.

UI pattern components

These patterns are larger in scope than UI pattern elements, and they do more work. Usually they focus on one user task, such as searching for and identifying an object, inspecting and maintaining attributes, or editing data with guidance. UI pattern components usually combine many different UI pattern elements.

Floor plans

Floor plans are the highest level of patterns. They combine pattern elements and/or components into larger structures that are reused. Three common floor plans will be described later.

Another term, UI building blocks, refers to any one of these levels of patterns that has become part of a common approach to building UIs. For example, one of the most important UI building blocks is called the Universal Work List (UWL), which collects in one place all the tasks assigned to one user or one role.

Patterns then finish the job that modeling started. Patterns not only make developers more productive, they also allow UIs to be constructed out of common elements. Using a core set of common elements reduces the maintenance burden and means that many more UIs can be standardized, which should reduce training time.

Patterns can be implemented in many different ways. They can be collections of UI elements that are assembled using the visual composition language, or they can be implemented in technology such as Web Dynpro.

5.6.4. How will UI building blocks and patterns change the nature of applications?

SAP has created a set of UI building blocks that provide a general structure for organizing the work of a user who must interact with various UIs playing different roles with varying levels of frequency.

These building blocks address the challenges of helping users manage their work when faced with a much larger set of UIs, some of which they do not use that often. The two most important UI building blocks are the control center and the work center, shown in Figure 5-15.

Figure 5-15. Control centers and work centers

These UI building blocks work together as follows. The control center is a combination of an inbox and a homepage for all of the work that is assigned to a user. The control center provides access to working content such as alerts, notifications, work items, news, reports, and information. At the heart of the control center is a UWL UI building block, which is a list of all of the alerts and workflow items assigned to the user. From the control center, a user can also see all of the documents, analytical displays, reports, and tasks that are relevant to her work.

It is assumed that each user is assigned a number of roles. For each role, a work center is created that helps organize all of the work that is required for that role. The work center may include information from one or more of the enterprise solutions that help carry out various tasks required by that role. Work centers that are visited often may include many elements from the enterprise solutions to allow frequently performed tasks to be done quickly. Work centers that are used less frequently may provide access to guided procedures that walk a user through the steps of performing a particular process.

Much of the work done by common enterprise applications can be captured using the control center and work center UI building blocks. It is important to remember that the control center and work center are just the first step in a journey SAP is undertaking in an effort to standardize as much of the UI as possible. Such standardization is perhaps the most important strategy to managing the expansion of UIs as more and more business processes are automated.

5.6.5. How will the UI be implemented under ESA?

One misconception related to the transformation of the UI that will take place under ESA is that all existing UIs will have to be rewritten. Fortunately for SAP and for customers, this is not the case. All of the existing SAP UIs created in the SAP NetWeaver Portal or in other manners can participate in the new world of patterns and UI building blocks.

The SAP NetWeaver Portal will remain the center of the SAP UI. Portal iViews will be the container in which all of the UI building blocks, floor plans, and patterns will reside. In turn, iViews from existing SAP solutions will be used as building blocks themselves and will be included in work centers and control centers as needed. Web Dynpro is being used to implement some of the most common and frequently used patterns in a highly optimized manner. And in special cases, such as analytical applications, the visual composition language allows other forms of UIs, such as Adobe Flex, to be used as a platform for UIs.