When is a form not a form?

[chris_scott]

When is a form not a form?  When it’s an app.

Or perhaps we should say 'When is an app not an app?  When it's a form.'

The current proliferation of apps; the race to build as many reselling apps as possible, is bringing new user interface options to SAP customers, and arguably the app is moving into the ground previously held by the e-form.

The introduction of increasingly more powerful smartphones and tablet devices has of course driven this widespread interest in apps.  Plus SAP’s acquisition of SyBase and the introduction of their app store are giving customers clear guidance that the new era of user interface will be via apps.

In many customers’ minds the edges between apps and forms have become blurred, and there is confusion about when to use an app and when to use an e-form.

So is this the start of the end for the e-form?  I say no: E-forms are cheaper to build, more flexible and easier to maintain.  In fact, tablets provide a new lease of life for the humble e-form.

In order to clarify the boundaries between e-forms and apps and provide guidance about when to use an e-form and when to use an app, first you need define the terminology:  what is an e-form and what is an app?

Apps

‘Apps’ has become a generic term for any executable application on any device.  Even if we focus on SAP-relevant use cases, there are a lot of different technical models.

Wired vs. Un-wired

Wired apps rely on a direct connection with SAP. They may reside on the client device or they can be served up on demand (for example in cloud-based solutions).

Un-wired apps can work without a permanent connection to SAP, so they need a local database on the client machine.  This is where SAP’s Sybase Unwired Platform (SUP) provides the infrastructure to handle the synchronising communications to multiple different devices.

PC vs. Tablet

Since HTML5 instead of Flash is the universal standard for mobile devices, then tablet-based apps need to be created in HTML5 or in the standard that is supported by the device’s operating system.

For PCs, Flash is used widely for apps that are served on request. For client-based apps then Adobe AIR is the equivalent technology.

E-forms

E-forms are ‘single shot’ interfaces used for data collection.  They are typically much less complex than apps, so cheaper to develop and maintain.  They have traditionally been used on PCs (PDF-based forms) and websites (HTML-based forms), but not on smartphones as the screen size has prohibited great form interfaces.  However, with tablets, the e-form can have an important role.

Wired vs. Un-wired

Wired forms are ‘On-line forms’ which are typically rendered at the point of request, served up to the requester, and so can be pre-populated based on real-time data and based on who has requested the form.

Un-wired forms are ‘Off-line forms’ which are typically sent as e-mail attachments and filled in without any connection to an SAP system, then submitted back by e-mail.  These work well for scenarios where the form user is external.

PC vs. Tablet

Tablets support HTML forms rather than PDF forms, and so this lends itself much more to ‘on-line’ rather than ‘off-line’ scenarios.

It is the use of e-forms on tablets in particular that needs to be differentiated from mobile apps, and to this end I propose new terminology:

• Portable forms.  On-line html forms that can be used on any device.
• Mobile forms. Form solutions for ‘un-wired’ mobile devices.

Portable forms

Portable forms are HTML e-forms, served by user request.  That request can come from a tablet such as an iPad – or indeed any device with an internet browser.  Since the forms are on-line, there is no need for any synchronisation so there is no need for the SUP. 

These forms can be used for all kinds of business processes; note that the user will always authenticate to SAP in order to launch the form.

Holiday Request: It’s a portable form, not an app

Mobile forms

Mobile forms are HTML e-forms that are launched from an app based on the mobile device.  These forms will work in an entirely disconnected state, which means that:

i) They will be larger, as they will not rely on server-side resources like logos, style sheets and scripts, and

ii) They will rely on a local database, and so require SUP in order to synchronise the data to and from the SAP system.

The use cases for mobile forms are more limited to form-heavy jobs, such as police, social care and perhaps field service.

Comparing apps and e-forms

Typical e-form functionality	Typical app functionality
Single-shot update.  Each form, once rendered can be used once.	Can perform a variety of updates.
Is pre-populated for a specific task.	No limit to number of SAP updates.
Relies on server database.	Relies on local database.
Requires user authentication.	Stores user details, so no need to log in each time.
Completely intuitive: no training required.	More complex. May require training.
Flexible, is liable to change – for example new fields added.	Inflexible but configurable.
Likely to build in-house – e-forms have high level of business fit.	Expensive to build in-house. App model is to purchase, may mean no development but reduced fit.
Form routing is normal for approvals or collecting data from multiple parties.	No data routing from the App as standard.
E-form may be used mid-way through a business process managed in SAP	App is the start of the process.

How to select the correct approach

Your business requirement may require e-forms, or apps or a mixture of both.  Remember that one size does not fit all.

Here are some questions to help you decide whether an e-forms solution or an app solution is the best way for you:

Does your requirement need to:-

• Update SAP or access data in real time?

Consider a wired scenario, e-form or app

• Work completely without connection to SAP?

Consider an unwired scenario, e-form or app

• Perform many different functions/updates

More likely to require an app rather than an e-form

• Store data locally on the client device?

More likely to require an app rather than an e-form

• Collect data for a single shot update?

More likely to require an e-form rather than an app

• Be routed for approval steps before final SAP update?

More likely to require an e-form rather than an app

• Be triggered by a SAP process or workflow?

More likely to require an e-form rather than an app

• Be the start of a SAP process or the middle or both?

More likely to require an e-form rather than an app

• Work in offline and online mode?

More likely to be a PDF form

• Work on PCs, tablets or both?

More likely to be an HTML form if non-PC devices are used

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.