Chapter 2. Trying Out Webform

In this chapter, we will cover:

  • Creating a Webform node
  • Adding textfield components to our Webform
  • Cloning components
  • Adding e-mail components
  • Adding textarea components
  • Adding fieldset components
  • Adding select components
  • Configuring a reply e-mail
  • Testing our Webform

Introduction

A tool that offers such a broad spectrum of functionality can appear very complex. While there are several layers to the functionality that Webform presents to us, it becomes quite a simple tool to use after just a little bit of practice.

In this chapter, we are very rapidly going to create a form which will handle the registration of speakers who will deliver presentations at our fictitious conference. In later chapters this first form will be extended to demonstrate additional features of the Webform module.

It is just as well to take a moment now to consider the preparatory work that goes into a well structured form, particularly when there are many input fields required. Clearly one would not lose too much sleep over a form that needs only five fields, as there is not much that can go wrong in terms of layout and cohesiveness. However, when we get to something a little more bulky, with over fifty required inputs for example, then we should plan our way forward with some care.

Perhaps the two most important criteria to consider in general form structure are sequence and grouping. It would be surprising to us if a conference registration form were to first ask whether we would like breakfast included in our hotel rates before asking whether we actually require accommodation at all. Similarly, we would be somewhat taken aback if we needed to fill in our first name on page one and our surname on page four!

In the general case, it makes sense to start the form design process at as high a level as possible. Of course, it also helps to have knowledge of all of the business rules to do with speaker registrations while we're busy. All too often a carefully planned form has to be almost completely reorganized and reworked because the designer lacked some critical item of information or misunderstood the purpose of an element of data.

In our scenario, where we're designing a form for the registration of speakers, we need to find out from the conference organizers exactly what information they require to ensure that the speakers have an enjoyable conference experience. It is necessary, also, to ensure that information deemed to be required is, in fact, pertinent to the situation. For example, while it is true that speakers are people and most people have feet, the speaker's shoe size is not an important piece of information to have unless the organizers are handing out shoes to the speakers.

Every aspect of our form needs to be evaluated from two entirely different points of view: that of the end user who will fill out the form and that of the administrative users who will make use of the data gathered by the form. There should be no information requested of registering speakers that is not required by the organizers to aid in their planning and execution of a successful conference.

Any information that we do request should be laid out in a clear and logical fashion to avoid any frustration or confusion on the part of persons registering via our form.

The high-level design of the speaker registration form we are about to put together is as follows:

  • Speaker information
  • Presentation information
  • Additional activities
  • Accommodation requirements
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset