Inspiration

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:

A Wizard-style form

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.

Musical accompaniment

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.

Web1.0 Technique

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.

Web2.0 Technique

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

http://en.wikipedia.org/wiki/Web_2.0

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.
http://www.packtpub.com/article/build-iphone-android-ipad-applications-jqtouch-jquery

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:

Performance/Responsiveness

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.

Functionality

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.

Coolness

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.

Occasionally disconnected

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.

Cross-page references

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.

Scalability

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.

Another issue is that half of your form logic runs client-side (in JavaScript) and half of it runs server-side (in Java or C# or some server-side language). This adds to the complexity of form development, as well as the level of skills required by the form developer. There are just more “moving parts”.

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.
• JavaScript is a difficult language to use to build larger-scale applications.
• 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

Bottom Line

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.