There’s no denying the increase of mobile device use is not only in our social lives but also, globally, across our professional life. Just a quick click through Mary Meeker’s latest slide deck will give a fantastic perspective and some real insight into the state of internet trends – particularly in relation to smartphones and tablets. Continue reading
I recently had a reason to build a demo form in Composer to demonstrate the capabilities of Dynamic Data in SmartForm Factory. This article will give you an idea of how Dynamic Data works and what steps you need to take to get it working in your form. This article assumes an intermediate level of Composer and Manager experience. Continue reading
As many of you who read my blogs know, I often try to find a musical accompaniment. I’m sure some of you occasionally roll your eyeballs, but I have fun.
This blog was my easiest one yet. Enjoy “On the Road Again“, by Willie Nelson while you’re reading this blog.
Mobile Devices have gone beyond the consumer and are now seen by many organisations as an essential business tool and possibly a competitive advantage. According to VDC Research, the global market for Enterprise Mobility solutions will be $23bn by 2015.
Beyond communication and collaboration, there are two primary functions mobile devices can deliver to the Enterprise:
- Collection of data
- Access to corporate data and systems
The Avoka SmartForm Field Worker is a mobile app that addresses the Data Collection requirement and runs on a wide variety of mobile devices. It allows you to take your SmartForms “on the road” with you, as well as allowing integration to corporate systems. The Field Worker provides a number of key benefits:
- At your fingertips. Your forms are always at your fingertips, immediately available through the simple user interface. No navigating through a web site or bookmarks to find the forms.
- Offline. You can do your work when you are offline, because they are synched down to the device. Drafts and submission are also stored within the app, and synched back to the server when you go back online.
- Cost, and Time to Market. Building an app for data collection is hard and expensive. You need developers to build it, test it, and ensure it works on multiple devices and versions. Then you need to deploy it through multiple AppStores, going through approval processes. Then repeat this process for each update. With the Avoka Field Worker, you design your forms in Composer as usual, deploy to SmartForm Manager, and the form will then immediately be available to regular web users via the web site, as well as automatically by synched to all Field Worker apps.
- Mobile Extra Features. The Field Worker enables several extra features specifically for mobile devices, such as Camera and GPS integration.
The Field Worker app is great for a many different types of users, such as:
- Agents of Finance or Insurance companies, who visit their clients at their homes or business locations and complete forms on their behalf.
- Auditors or inspectors, who fill out forms on site.
- Health workers collecting patient-related information within a hospital or at patients’ homes.
- Anyone who needs to fill out the same form on a regular basis, such as a worker who needs to complete a timesheet or job card every day or week or at the completion of every job.
Under the Hood
The Field Worker is an App aimed at tablet devices, and is currently targetting iPad, Android and Microsoft tablet devices. Its main user interface is shown above:
Based on your login information , all of the forms that have been allocated to your organization and group within SmartForm Manager will be synchronized down to the Field Worker. These are exactly the same set of forms that you would have access to if you navigated to the SmartForm Manager Portal in your regular web browser, except these versions of the forms are those optimized for tablet look and feel, and touch-style interactions. Once all the forms have been synchronized, you may disconnect from the internet, hit the road, and those forms will always be accessible to you. You will then be able to do any of the following:
- Open up a form, and start entering datacollect a rich data set including Text, Structured Data, Photos and GPS coordinates (based on the capabilities of the device). You can open the same form multiple times, and each will be saved separately.
- You can save a partially completed form locally, and resume completing at a later time. This means that you do not have to complete every form immediately, but you can save it in a partially completed state, and come back to it when ready. When you save a form locally, all regular mandatory field requirements are temporarily ignored.
- You can submit the form, even if you’re offline. When offline, the form data will be held in a queue, and automatically synchronized later when you’re back online.
- You can maintain your profile information which is used to pre-populate forms you initiate, saving on keystrokes and time.
Any new forms, or new versions of existing forms will by synchronized down to the Field Worker app whenever you connect. The Field Worker also synchronizes a number of additional information from SmartForm Manager:
- SmartForm Manager profile data. Field Worker will use this profile information to pre-fill any forms that are configured to use profile data.
- Draft forms are synchronized with the server when you go online, which allows you to switch to a different device and still be able to complete your work.
- Any tasks (forms plus data) that are assigned to you in SmartForm Manager will be synchronized to Field Worker, and appear in your ToDo list. A task may be assigned to you, for example, if you have not completed a form correctly and it needs an amendment, or perhaps a brand new form that includes the details of where and when you need to perform the task associated with this form.
- Attachments. Additional files of various types are also synchronized to SmartForm Manager (see below).
When you’re back online, all the data from forms you have completed will by synchronized to SmartForm Manager, and then delivered to back-end systems using the SmartForm Integration Agent. (This is the same way that regular web-based form submissions are delivered.)
The diagram above shows the overall architecture of Field Worker, SmartForm Manager, and SmartForm Integration Agent in a multi-organization cloud environment. Other configurations are available.
The SmartForm Field Worker app enables a number of additional mobile-specific features. These include:
- Camera and Gallery integration. For field workers, it’s often useful to be able to capture a picture. This could be the damage to a vehicle being assessed for an insurance claim, or a patient’s injury, or a person’s portrait picture. The camera can also be used to take pictures of supporting documents, such as driver’s license, payslips, or passports. Pictures can be captured in two ways – either via a specific picture field on a form, or as a generic attachment to the form. Audio and video can also be captured if necessary. Pictures are submitted as part of the form submission, but are synchronized separately, to ensure optimal use of available bandwidth.
- GPS location data. Many tablet devices support GPS, and it is useful to be able to capture this information and associate it with a form. This can be used to prove that the person was actually at the correct location at the right time – the location data is generally non-editable, and can only be collected by using the device’s location service.
- Signatures. Avoka supports the use of a Scribble Signature field, that allows signatures created with a finger or stylus to be collected right on the screen.
Access to the Field Worker app is governed by a username and password login. The first time you start the Field Worker, it will communicate with its “home” SmartForm Manager instance. (You can configure the Field Worker app to point to Avoka’s cloud server, or to your own organizational instance of SmartForm Manager.) You will be prompted to log in, using your regular username and password, which will be authenticated by the server. These credentials will identify you, and determine which organization and group you belong to. This is the same login that you use on your corporate network. When offline, access is controlled using a local hash of the password – the password itself is never stored on the device.
All the synchronized data is stored securely on the local device. Once the form has been successfully submitted to the server, local copies of the data are purged.
All data stored within the Field Worker is encryped using 128 bit encryption. In addition, all communication between Field Worker and SmartForm Manager is conducted securely over HTTPS.
Cost, Time to Market, and Agility
Building a custom data collection app is difficult and costly.
- You need to use highly paid developers, generally with specific expertise in different tablet operating systems, development environments, and programming languages.
- You need to develop and test the app on multiple devices, with multiple screen sizes and resolutions.
- You need to go through approval processes to have your app published on multiple AppStores.
- And then you need to repeat the entire process each time you need to make a change or develop a new data collection app.
Some indication of the costs you can expect can be found in this article: http://www.propelics.com/ipad-app-development-cost-a-breakdown/
Alternately, you can use SmartForm Field Worker and create your own SmartForms.
- SmartForm Field Worker is already built, and will be available soon in the App Stores.
- Avoka has already done all the work of developing and testing this app on multiple devices.
- You can create sophisticated data collection SmartForms extremely easily using Avoka SmartForm Composer, without requiring developers to help you build them.
- Your SmartForms are automatically branded and styled correctly, and customized for touch interaction and tablet screen sizes.
- You can then simply deploy your SmartForms to SmartForm Manager, and the forms will magically appear in the Field Worker app for all your users to fill in.
SmartForm Field Worker is quick, easy, and cost-effective.
Please take a look at this excellent demo by Jeff, one of my Avoka colleagues: SmartForm Field Worker Demo. This demo takes you through the key elements of the Field Worker on an iPad.
If your organization is…
- Looking to embrace the benefits of mobile devices for improved customer service or greater productivity
- Collecting data (text or rich) in the field
- Employing staff or contractors to work in occasionally connected environments
- Not mandating or supplying a particular mobile device, but rather adopting a Bring Your Own Device (BYOD) strategy that could see Apple, Android, Windows etc. devices used for field mobility
…then the Avoka Mobile Field Worker will be a powerful and cost effective solution for you.
Many Adobe customers have invested in Adobe LiveCycle as a way of creating, publishing and managing business forms. These customers use Adobe LiveCycle Designer to create sophisticated PDF electronic forms using the XDP (also known as XFA) specification, and deploy and manage these electronic forms using Adobe LiveCycle server products.
However, the world is rapidly going mobile, and traditional PDF/XDP forms do not run on most mobile devices.
This blog outlines some of the options available to existing LiveCycle customers to take their forms mobile.
Some Options for Taking your Forms Mobile
There are several different ways you could use for getting your forms mobile:
Wait for a new version of Mobile Reader
Build it yourself in HTML5
You could build your business forms yourself in HTML5.
There are a few problems with this approach:
- You’d be building everything twice – once in PDF, and again in HTML5.
- HTML5 is a whole new and complex set of skills. It takes a significant amount of learning and investment to create even moderately sophisticated HTML forms and typically needs to be done by programmers. You may need to hire staff with different skills, or retrain your existing staff.
- You may need to build several variants of a form in HTML, for different screen sizes – one size does not fit all. You may also need both touch and mouse-oriented variants.
- Building touch-oriented HTML pages is a new skill to learn. Not only do we need to learn traditional HTML, you also need to learn touch-specific features.
- You need to test your forms across a large number of different browsers and devices.
Select a Proven Solution that is Available Now – Avoka SmartForm Factory
Avoka has been working on mobile capabilities in our SmartForm Factory product for almost two years, and we have a robust and mature implementation that enables a single design to be generated as either a interactive PDF Form, a static PDF Receipt, or a HTML/HTML5 form. Importantly, SmartForm Factory can fully leverage your existing LiveCycle Infrastructure!
Some of the features we have built into SmartForm Factory that enable mobile devices include:
- SmartForm Factory is built on the experience of hundreds of developer-years building both PDF/XFA and HTML forms.
- SmartForm Composer is a technology-neutral form design environment. You design your forms, including look-and-feel, layout, business rules, and more, in Composer. Composer generates “best of breed” renditions of this form, including both Interactive and Print PDF, Desktop HTML, Tablet HTML/HTML5, and SmartPhone HTML/HTML5.
- Our form management platform, SmartForm Manager, “sniffs” the user’s browser, and automatically serves up the appropriate rendition of the form.
- Tablet and smartphone variants are optimized for touch interactions.
- Composer supports platform-specific widgets (eg Google maps field in HTML), as well as cross-platform widgets that work in both PDF and HTML.
- Wizard-style forms (in both PDF and HTML).
- We have an automated testing facility that tests Composer-generated forms across a wide variety of browsers. We do the hard work of cross-browser compatibility so that you don’t have to.
- SmartForm Factory works seamlessly with Adobe LiveCycle.
- Our forms also work off-line, by pushing them to the Mobile FieldWorker app.
- You can build mobile forms in SmartForm Factory today!
Other features that are not specifically aimed at Mobile support, but may be of interest to you, are:
- Extensive use of Style-sheets, so that you can build forms more quickly and with better consistency. Also allows a single form branded differently for different customers.
- Extensive capabilities for re-use, including re-usable blocks (with form-level overrides possible), and impact analysis.
- Ability to create the same form in multiple languages, including automated translation capabilities.
- Dynamic Data lookups to interact in real-time with back-end systems.
- Support for save-as-draft, attachments, receipts, and more.
- Integration with Payment Gateways.
- Integration with existing web sites and content management systems.
- Customizable delivery options.
- Battle-tested Quality of Service features to ensure highly scalable levels of service.
Coming in Q4 2012: Adobe’s XFA->HTML5 generation option
Adobe’s Dave Welch has indicated that a future version of LiveCycle will include support for mobile forms. From this LinkedIn thread:
David Welch: We are working on a way to enable XFA forms to work on mobile deices as part of our next release. I expect that we’ll start doing demos and prerelease activities in the next couple of months and you’ll definately want to be in on that. We’ll announce on our blog when we’re ready to show it off.
There are definitely some advantages of Adobe’s approach, the major one being that you will be able to publish your existing XFA forms as HTML. However, we tend to agree with Duane Nickull, who said, “IMO – XFA/XDP forms are not optimal for a lot of mobile browsing”. The major disadvantage of this XFA->HTML is that you will be limited to the types of forms that you can currently build in LiveCycle Designer, and will not be able to use HTML-specific features, or make the best possible use of more limited screen real-estate.
We will be watching Adobe’s approach with great interest, and will definitely be incorporating whatever they deliver into SmartForm Factory – this will be a good quick solution to taking existing forms mobile. However, we believe that to give your mobile customers the best possible user experience, use SmartForm Factory approach, where you can design for optimal HTML experiences, and still get great looking PDF’s (great for receipts) from the same form design.
In this case a Google Maps widget can be used within a HTML form providing “drag & drop” address selection or preview.
If you want to transition to the mobile world, while still making the most of your existing LiveCycle investment and skills, you should be taking a very close look at Avoka SmartForm Factory.
We recently received a specification from a customer of a wizard-form they wanted to build. You know the type, where you have next and previous buttons on the bottom of the page, and you go through the various pages one at a time. Here’s an example of this type of form on an iPad:
There are two quite different ways to implement this type of form in HTML, with different trade-offs. I would like to contrast these two approaches, and explain the reasons why we chose one approach over the other for SmartForm Composer wizard forms.
Should I stay or should I go? – The Clash
The two options
Option 1 – the traditional or Web1.0 approach
In the traditional or Web1.0 approach, each page of the wizard form is implemented as a separate page in some sort of server-side html authoring environment, such as Java or .NET servlet. Each page is separate, and each time you press the Next or Previous buttons, the browser does a full round trip to the server, returning the full HTML for the next or previous page.
Option 2 – the modern or Web2.0 approach
The more modern or Web2.0 approach is to embed all the wizard sub-pages within a single containing html document. The sub-pages are all loaded at once when the wizard is first loaded. Each page will be loaded into its own <div> element, and while all page exist within the browser at the same time, only one page is displayed at a time. When you click the Next or Previous button, all that happens is that the page you’re on is hidden, and the page you’re going to is made visible.
This is the Web2.0 approach, where the form becomes more of a Rich Internet Application (RIA), and communicates back to the server only when necessary using AJAX. For an explanation of Web2.0, RIA and AJAX, please refer to
This is also the approach takenPDF by most of the popular frameworks for building mobile applications, such as JQTouch and JQueryMobile, as discussed in the article below.
There are a bunch of other capabilities that can and are built into Web 2.0 applications, including:
- Client-side validation and calculation rules are built-in, rather than requiring a full round-trip to the server. This results in in a much more responsive application.
- The application may “call home” using JSON or REST if it needs any additional data, such as to validate an address or populate a drop-down list. (But it’s only the data being transferred, not the entire web page, so it’s fast.) I will be blogging more about this soon.
The Advantages of the Web2.0 approach
We believe strongly that the Web2.0 approach is better for a whole lot of reasons. These include:
Because all the sub-pages are loaded up front, and all we’re really doing is hiding and showing them, navigation between sub-pages is almost instantaneous. The form feels really snappy, and you can flick through the wizard very quickly, at the speed of a native application. This is what users have come to expect, and they tend to get cranky when there is a long delay between pages. Performance is particularly an issue over slower un-wired networks. There is a slight up-front hit when the form first loads, but this is generally completely compensated for by the snappiness of the form once it has loaded.
You can build much more interactive and functional applications (as opposed to simple web pages) using Web 2.0. Customers are increasingly getting used to and demanding functionality like that found in other Web 2.0 applications such as Google Mail, Google Docs, and Trello.
Because all the wizard pages are already loaded, we can do some cool things. One common example is that we can use CSS transitions when navigating between pages. So instead of just getting the next page to replace the previous one, we can have it rotate in, or glide in, or some other type of cool animation. This isn’t JUST cool – on mobile and tablet devices, users expect and demand a slick transition between pages in their user interface. We can even incorporate finger-gestures to flick between pages of the wizard.
With the Web2.0 approach, once you have your form loaded on your tablet, you can walk into an elevator or drive through a tunnel, hit the Next or Preview button, and everything still works. Do the same thing with the Web1.0 approach, and you’ll get a “Page not found” error, and you’ve effectively lost everything you’ve done so far.
In the Web1.0 approach, if you’re on page 3, and it has a calculation that depends on a question you answered on page 1, you have a bit of a problem – that page no longer exists, and neither does the value of the field. In the Web2.0 approach, all pages are always loaded in the browser, so you can always refer to any value on any page.
Because much of the business logic is being performed within the user’s browser, and there are less round trips, there is less traffic back to the server, and less for the server to do. This allows you to scale better.
State Management and Programming model
(Skip this section if you’re not a programmer, but believe me that the Web1.0 approach is more complex to code and test.)
In the Web1.0 approach, the programming model is much more complicated. Because each wizard sub-page is largely a self-contained web page, and because the basic HTML model is stateless, you need to store the current state of each form, for each person who is currently filling out a form, somewhere. Each time a user submits the form, you need to combine their submission with information you’ve already stored about where they are up to in the form, and what other data they have filled in. All this information needs to be stored somewhere, kept up to date, and discarded if the user decides not to proceed with their submission. (Privacy laws generally dictate that you cannot store data that the user hasn’t agreed to submit.)
This isn’t rocket science, and it can be built, but it is complicated, and adds to the difficulty and therefore the cost of building and testing the forms.
In the Web2.0 approach, the entire form and its state is all completely self-contained within a single consistent “application”. You can develop all your application logic within a single environment, using a single programming paradigm. The only time you need to communicate with the server is for server side validations or lookups, and on final submission.
Similarity with PDF Forms
For many organizations, they want their users to be able to use either PDF or HTML to fill in forms. PDF forms are completely self-contained, and run the entire form and all its pages client-side. The Web2.0 HTML approach uses exactly the same technique. This means that you have a single model that works for both PDF and HTML forms, and a single server-side implementation will work for both PDF and HTML.
It also means that for each wizard-style form that you fill in, you can create a paged-style PDF form that becomes the document-of-record for the data you have entered. If you use Composer to build your forms, then you are building just one form, and generating two different “flavours” of form.
Organizational constraints and change management
If you use the Web1.0 approach, then each time you want to make a change to any of your forms, you need to re-deploy your entire web application. This involves the full Software Development Lifecycle (SDLC) process, and in particular, requires a full re-test. This can be very time-consuming. It can also be quite dangerous, because a change to the core application in order to change one form may accidentally affect other forms.
If you use the Web2.0 approach, then you are simply deploying an updated, completely self-contained form, into an existing web application. The new form does need to be re-tested, but you do not need to re-deploy or retest the entire web application, or any of the other forms, because only one form has changed.
Some objections to the Web 2.0 method
Complete navigational flexibility
- This potentially creates a highly confusing experience for the end-user. Users assume a fairly linear flow through a wizard, and tend to get very confused if the user interface “wanders off” in seemingly random directions.
- It does not allow you to show a navigation menu for the entire form, because you don’t know what the pages are going to be till you get to them.
- Instead of a single form, you can “chain” together multiple forms. For example, the first form might be an overview form, and then you get multiple additional forms to fill in based on this first form. Each form is self-contained, but can re-use data that was supplied in previous forms.
- You can hide and show different sub-pages (or sections within a sub-page) based on questions that the user answers earlier in the wizard
- You can call back to the server in order to populate a particular page with contextual data. For example, the exact terms and conditions that a user needs to agree to may differ based on their state.
Server-side validation and lookups
It can be argued that the Web1.0 model allows the server to provide “input” at each sub-page transition. This could be to validate data, or to populate the next page with data based on the answers to previous pages.
This can be relatively easily implemented in the Web2.0 approach both within pages, and at page transition boundaries, or even at the individual field level, using a simple form-to-server communication protocol. (I will be blogging more about this later.)
But isn’t Web 2.0 difficult???
Yes, Web2.0 can be insanely difficult. Web 2.0 applications are difficult because:
- You have to deal with a whole lot of new technologies, including rich client frameworks, event driven architecture, and asynchronous messaging.
- There are numerous cross-browser issues you need to deal with.
- You will need to retrain and up-skill your developers.
- Web 2.0 applications are difficult to maintain, because tooling is still relatively primitive.
- Testing and debugging are difficult, again because tooling is still quite primitive, and also because every browser is different.
Ta-daaa… SmartForm Factory to the rescue
The Web2.0 approach to wizard-style forms provides significant advantages, and almost no disadvantages, compared to the Web1.0 approach. Avoka SmartForm Factory makes it simple to build fully-functional Web 2.0 applications without the massive learning curve.
Today’s post is inspired by this posting on the LiveCycle Google Group:
Tarek wanted to be able to submit an electronic form (eform) to a server without performing all the checks for mandatory fields. This is actually a very common requirement, and is most useful when you want to allow your users to save the eform as a draft copy back onto the server. Obviously, if you’re saving as draft, you want to allow the user to save the eform without all mandatory fields completed. (Note that you still do want all validation rules for non-blank data to be fired – otherwise you will get a whole lot of errors being displayed when you re-open the draft form.)
Tarek has outlined his very clever code to achieve this. However, it’s quite complex, and requires code to be explicitly placed on every mandatory field in order to make it work. I haven’t tested it myself, but according to his own testing, it seems to work. Take a look at the link above to review his code.
This is the sort of thing we’ve been building into our electronic forms for years, and so we’ve added it as a standard feature in Composer. All you need to do is check one checkbox on the Submit button’s properties. Done. No fuss, no complicated code, nothing else to do.
But wait, there’s more…
You may also notice the “Clear hidden data on submit” checkbox, which is checked by default. This is another feature we provide by default.
At Avoka, we have several hundreds person-years of collective form building experience. We’ve taken that experience, encapsulated it, and built it directly into Composer. Many if not all of the more sophisticated features that you need in your eforms are already there, and all you need to do is use them. You can build PDF/XFA forms, or HTML5 forms for Desktop or Tablet from the same form design. Please contact us for more information or a trial.