• Home
• Products and Services
• Local Gov
• Support
• Services
• FAQ
• Forms 101
• Checklist
• Designing Forms
• Latest Release
• Professional Services
• Initiatives
• Partners
• Developer Club

Forms 101

Summary

We at Mandoforms believe that for capturing and processing data over the Internet, extranets and intranets our solution is the intelligent replacement for HTML forms. However, many people are not familiar with HTML forms at all, and fewer still are familiar with the ways of processing the data captured by them. So below is an overview of how HTML forms work and what their limitations are.

What are HTML forms?

HTML forms originated shortly after the Web itself, around 1990, when the HTML language was used to write Web pages to enable the transfer of information across the Internet for display within a Web browser. Initially all you could do to send back a response to the Web author, was to send them an email. So an enhancement to the HTML language was provided to allow people to send back a response in a structured way. A Web page that has this extra language feature, and can ask questions, is called an HTML form.

Note that early Web Sites consisted of a few grey pages of text with no images, connection speeds were slow, and browsers slower still. As a result, HTML forms were only expected to capture limited amounts of information, and apart from a small enhancement in the early 1990s, HTML forms have remained the same ever since.

In stark contrast, Mandoforms are designed for today's data capture needs, making HTML forms a thing of the past.

How is data captured and sent back to the server?

Each question on an HTML form is given a name, often called a 'field name'. You can specify a number of different field names to capture the answer, such as a drop down list or a simple text box. The answer itself is normally called the 'value'. So you'll see most texts discussing HTML form questions and their answers as {field, value} pairs or {name, value} pairs.

The answers themselves are captured and stored in the browser until the user clicks the Submit button. The browser then has two different ways of sending the answers back to the Web server. The most typical way is to pretend to ask for another Web page and embed the answers in the request, for example:

http://your_name.com/a_pretend_webpage?field1=value1&field2=value2

where 'fieldN=valueN' represents the names of each of the questions and the associated answers, i.e. the {field, value} pairs.

Mandoforms work in a similar way. Each question also has an associated 'field name', and Mandoforms sends back the results to the Web server using {field, value} pairs when you press a 'Submit' button. More importantly, Mandoforms appear to Web servers exactly like HTML forms do, using exactly the same communication mechanism, and can therefore work across the whole Internet, just like any HTML form, or indeed Web page.

Validating the data

A simple, non-technical way of making it easier for users to enter correct information is to make things clear for the user by displaying just a few questions at a time. This of course means splitting your form into lots of pages, each with just a few questions on. In this way users find it easier to complete forms, and so the data captured will be more accurate, saving on processing costs. See our design section of the Support page for more information on how to put together user-friendly forms that really work.

Often, you'll want to check that users enter valid responses to individual questions. For example if you've asked for a telephone number, post code, or credit card number, it's important that users haven't made a simple mistake or entered invalid characters. The better your validation routines here, the fewer issues you'll have to sort out when you try to process the captured data, especially if you have to put the information into an internal computer system or database. So getting the validation right at the original point of capture will enhance the user experience and reduce end-processing costs.

HTML form validation

There are two main validation options available with HTML forms. The traditional route is:

1. The user submits the data captured on a page to the Web server
2. The page is checked and returned to the user with the errors marked
3. The user then corrects the errors and re- submits the page to the server

This approach suffers in many respects.

Firstly, you need to write a program for the server to do the checking. Secondly, the checking can take some time to perform, especially if you have many pages from different people to check, and you have opted for lots of small pages as discussed above.

This explains why most HTML forms fail; most users get tired of waiting, just to be told that 'Mrs' has to be in upper case and they go elsewhere. Add in 128bit SSL security to protect the submitted data, which will slow down your server a thousand-fold, and you'll be soon be searching for alternatives or compromises such as pages full of questions, and minimum field validation.

A more recent innovation is to use JavaScript, which allows extra, more powerful commands on your Web page and can be used to perform basic validation without having to return to the server. Sounds great, but:

• You'll still have to write and maintain the JavaScript
• For anything other than basic validation routines, you have to do a lot of coding
• You may have to write different routines for different browsers
• You'll still need to write a program for the server that will display the next set of questions and/or perform any complex validation you need
• The Web pages you produce will increase in size as you add more JavaScript, resulting in increased download times.

As a result, few have found Javascript a successful alternative to standard HTML forms.

Mandoforms validation

With Mandoforms, validation is carried out in the user's browser. Navigation, (i.e. which questions are displayed next) is also handled in the browser. So responses are fast and occur as soon as the user begins to type. Therefore you can add the validation you require, without upsetting the user experience, leading to quality data and reduced processing costs.

You can also design your forms with as few or as many questions on each page as makes sense for the user, without worrying about the impact on your Web server. Your server will also be free to service more users, more rapidly than with HTML forms. Finally, validation routines themselves are selected from a list in the Builder Tool, so there's no programming required and maintenance is much easier.

How is form data processed at the Web server?

You may still be thinking that HTML forms aren't so bad after all. Just add a bit of HTML to your Web pages, and you're half way there. Unfortunately, this is just the tip of the iceberg. The next step, i.e. actually doing something with the data you've collected, is the most difficult part.

When the fields and their values arrive back at the Web server, it can't do anything with them. The original solution was to add an interface to the Web server called the CGI (Common Gateway Interface), to allow servers to pass data to application programs on other servers for processing. The application program receives the form data, and passes a Web page back to the Web server to send back to the user's browser. Unfortunately, this is very inefficient, so both Netscape, and much later Microsoft, came up with better solutions for their own Web servers.

Whatever the case you will still need to write the program to process the form data. The original option, and still most prevalent, is to learn a language called Perl. This is a great language in itself, but few can use it properly, and most use Perl programs written by others with some modification. Simpler options include using Microsoft's ASP, or Sun's JSP language. But you will still have to write a program, debug it, test it, change it when the form changes and, of course, you'll need one program for every page of questions, for every form you have. The programs themselves will not be easy to write, as you may have to encapsulate all of the validation routines, handle errors, decide which page to send back depending on the answers sent, then create the page to send back. Finally, you will also need to deal with the data received, send an email, put it in a database etc.

So as you can see, writing the HTML form is the easy bit. The time-consuming and costly part is writing and later maintaining the many server programs you'll need to process the data. The Mandoforms Server can carry out simple data processing tasks with no programming needed, and/or can minimise the number of server programs required by presenting the form as if it were a single HTML page, simplifying the whole problem.

The Mandoforms Server

The Enterprise Server has all of the standard functionality you require built in. So you can perform common tasks such as sending emails, talking to a database, creating spreadsheets, return PDF files, and so on. All without any programming.

In fact, you can configure the Mandoforms Servers to perform much more complex data processing if you wish, and all with just a few clicks on your browser.

What do you need to write HTML forms?

If you know the HTML language, you can use a simple text editor, but you'll probably end up with a few nondescript pages. A better option is to use a proprietary editor, such as Dreamweaver from Macromedia, or Front Page from Microsoft. These will ease the pain of writing HTML, and will hopefully make you much more productive.

You will also need a Web server on which to test, and deploy your pages. Furthermore, you will need to learn at least one new server programming language, write the appropriate server-scripts to process your form's data, and install and support these programs on your Web server.

With Mandoforms, if you understand XML and our use of it, you could also use a simple text editor to write the forms. However, a better option is to use our Builder Tool, which is part of the Developer Kit. This will reduce the overhead of learning to use XML, and make you much more productive.

Of course you will still need a Web server on which to test, and finally deploy your forms, although our Developer Kit includes a simple Web server and Mandoforms Server combined to make it easier to develop forms.

With Mandoforms Server, there is no need to write any programs, just use the browser-based Configuration Tool, to select which actions to perform on the form data received.