The combination of SAP Interactive Forms by Adobe and Forms Lifecycle Manager provides the option of building e-forms using PDF, HTML or a combination of both. In this update I explain the differences between these two approaches.
PDF e-forms
The benefits of a PDF form approach are well-documented. Compared to SAPGUI or SAP Enterprise Portal the user-interface is very desirable. The design tool, ‘Adobe LiveCycle Designer’ provides a wealth of design functionality, such as built-in accessibility tools and the ability to easily bind form fields to multiple data sources.
A PDF form can be used to collect attachments, it can be used off-line, and/or collect multiple digital signatures.
If customers are using PDF forms for output, or they use SAP Interactive Forms by Adobe for existing forms processes, then they will have familiarity with Adobe LiveCycle Designer, and so they are likely to want a single forms technology. Using a pure-PDF approach is likely to be a better fit.
HTML e-forms
The benefit of HTML forms is process mobility. HTML forms can be used on mobile devices such as Smart phones and tablet devices. There is a huge opportunity for extending SAP processes to the iPad without building custom apps or rolling out Sybase Unwired Platform.
The same HTML form can be used on the iPad as on a desktop or laptop. Whereas PDF forms are rendered to give them the stand-alone capability that delivers off-line processing, HTML forms exist transiently, in the moment. Whilst this means HTML forms are often simpler in terms of capability it also means that run-time performance is excellent.
For a pure HTML-form approach, no SAP Interactive Forms by Adobe licence is required. However, a SAP user licence of some sort will be required since form users will be accessing SAP data.
How HTML5 fits in
HTML5 delivers a number of new form elements that will make HTML forms more powerful and easier to develop. However, those new elements are not supported by most web browsers in common use. Internet Explorer 10 will support those elements, and so a move to pure HTML5 forms may be practical in 2013.
Other HTML5 elements are widely supported by browsers already, and so HTML5 can be used already within e-form templates.
Comparison Chart
Development Effort
HTML form templates generally require more development effort than PDF form templates. This is because there are fewer standard html objects for forms. (For example, there is no object for a date field.)
Of course, once a customer has built a library of reusable objects then the development process can be very quick. However, in a multiple-device scenario, the HTML form template may need to be re-developed for multiple devices: It is likely that a Smart phone version of the form template will be different to a large-screen form template in order to optimize the use of the device screen, although some of this can be overcome by using style sheets. Over time, any development overhead may diminish to be quite small and compensated by the process mobility benefits.
From a standing start, HTML forms are more difficult to develop than PDF forms – but you might already have the required skills in-house.
Benefits of a mixed approach
We see scenarios where a flattened version of the form needs to be sent back to the applicant, or saved on a document server. We see scenarios where the form is filled outside the firewall by a non-SAP user, or a ‘fill and print’ version of the form needs to be made available. For these scenarios we use PDF forms.
We also see scenarios for simple approval / rejection, where opening a PDF form is cumbersome, or forms that are always used on-line and which businesses want to make available on the maximum number of devices. We see citizen-facing forms, and scenarios where we cannot control the version of Adobe Reader in use. For these scenarios we use HTML forms.
So it is easy to envisage scenarios where a single form process involves a PDF form for part of the process and an HTML form for another part of the process.
Where PDF is the preferred option, but process mobility is also a requirement, we can deliver either a PDF form or an HTML form based on the requesting device. In this way, existing PDF-based processes can be extended to mobile devices through the addition of an HTML template.
So having both form technologies available provides many more options to deliver simple forms-based business processes.
E-forms Everywhere
SAP e-forms, involving the strategic combination of Forms Lifecycle Manager and SAP Interactive Forms by Adobe, provides an end-to-end solution to develop, deploy and manage e-forms. Those forms simplify the end-user interaction with SAP business processes in on-line, off-line and mobile scenarios.
- SAP Managed Tags:
