Form Design Overview

To create forms that integrate with your existing systems and databases and meet end-user requirements (and before you actually sit down in front of the computer and start designing forms with InfoPath), you need to design your form and have some idea of what the finished product will look like. The form design process has the following six basic phases, each of which is described in turn in the sections that follow:

1. Defining the concept

2. Determining the processing model

3. Sourcing the data

4. Creating the design

5. Developing and testing the design

6. Deploying and operating the form

Defining the Concept

Because InfoPath is a relatively new software application, many developers and users are unsure of how it will be used within their own organization. That’s why the first step in the form design process is critical—if you can define the concept of what information the form will collect and then can extend that to how the information will be used, users will have a better understanding of how InfoPath fits into your organization and developers will have a concept to work toward when creating their own forms.

How do you define the concept for a form? How is InfoPath used? How can it be used? A good starting point for these types of discussions is with the sample forms that ship with InfoPath. The sample forms can be viewed by selecting File | Fill Out a Form and then clicking the More Forms option in the Fill Out a Form view in the Task Pane. This opens a list of installed and sample forms, as shown in Figure 4-1.

Figure 4-1: Sample forms installed with InfoPath

The sample forms are provided within InfoPath to give you some idea of the types of applications that InfoPath can be used for and to give you a starting point for your own development. Before you continue with the design process, take time to look through these samples. Perhaps a sample will give you an idea of where you could apply a similar concept or perhaps you will find forms you can use with your own systems or databases.

Once you have a good understanding of the capabilities within InfoPath, you can then tackle your first form. It may be a form you need to create for your own use or a form requested by another user.

To ensure that you understand other users’ form requests, spend some time interviewing them to find out what information they would like to gather using the form. A good way to get them thinking about what their form could look like is to bring along printed copies of the sample or existing forms currently in use. This could be forms that were previously completed in hard copy, electronic forms, or forms in existing systems or applications that are used to enter or gather information.

When you are interviewing users for their requirements, there is no group of questions set in stone that you should ask every time, but the following list should help you to gather the information you need to complete your form design:

• Who will use this form?

• What is the purpose of the form? (To gather information, consolidate, and so forth.)

• Will this form replace an existing form or process? If so, what does that form or process currently look like?

• What information would you like to see in the form?

• What is the title of the form?

• What type of form should be generated? (A simple field-based form, repeating rows or columns, a multipage form, and so on.)

After you have interviewed the users and understand what they would like to see in a form, the easiest way to develop and communicate this concept is to create a prototype, or mock-up, of the form that you wish to create. You can use a word processor, a spreadsheet, or the low-tech option of pen and paper, but you should try to make the prototype of your form as complete as possible. This will help you later when you are trying to determine whether the form that you wish to create is feasible.

Determining the Processing Model

After you have met with the users who will actually be using the form and understand what information they want to capture and how they want to use the information entered, the next step is to select a processing model for how the form will be processed. There are a number of different ways you can deploy InfoPath forms depending on your own needs. The following is a list of some of the most popular methods of processing InfoPath forms:

• XML file Using this method, you can create forms that can be saved to an XML file and used with a variety of systems and databases.

• Consolidated XML file Using this method, users would consolidate the data from multiple InfoPath forms into a single XML file.

• Database integration You can also create forms that submit the information entered directly into a database, eliminating the need to save and process an XML file.

• Web Service Using this method, you could create a web service that could be used to capture information entered into a form or return data to a form.

Keep in mind that this section only lists a few of the ways that InfoPath can be used—there is also broad scope for creating workflow applications and integrating InfoPath with SharePoint, BizTalk Server, and other applications or systems.

Did You Know?—The “silo” approach

Out of the four popular processing methods listed, the two for working with XML files and consolidated XML files are the easiest and don't require any additional work on the database, nor any need to develop a web service to collect and aggregate information. Users can use this information in other systems or export it to Excel for their own analysis. This “silo” approach to InfoPath could mean that you have a number of disparate forms in use around the organization, so if you do have the support to create and maintain an Access or SQL Server database, it is probably a good idea to have your InfoPath forms submit the data directly into the database.

If you do have developers within your organization who are experienced working with Web Services or if you want to push information directly into other database systems or applications (for example, Oracle, DB2, and so on), the web service method might be the best.

Tip

For more information on working with SharePoint, check out Chapter 11.

Sourcing the Data

After you have decided how your InfoPath form will be processed, it is time to look at where the data for your form resides. You don’t necessarily need to have an existing XML file or data source to create an InfoPath form (as you will see in this chapter), but if you are planning to create a form that pushes information directly into a database, you probably want to have a look at the database schema to determine which tables will be used in your form and how the data will be submitted to the database. Some developers prefer to have InfoPath write data to a specific set of tables that are separate from their core systems and then run an import process to update the correct database tables, whereas other developers may allow InfoPath forms to directly update core tables. At this point, you need to sit down with your database or systems administrator and talk about where the data from this form will reside and how it will be handled once it has been submitted to the database.

Also, if you want to push data into another database format besides Access or SQL Server, you need to work out who will create the web service that will accept your data and find out what input they are expecting from you.

Note

Microsoft has provided a number of Visual Studio .NET samples for InfoPath that will help developers who are familiar with web services to get started designing applications to interface to InfoPath forms. You can find these technical resources at www.microsoft.com/infopath.

Creating the Design

After you create a prototype and determine your data source, the next step is to design the form. You must be asking yourself at this point whether this is where you get to use InfoPath. The answer is “No.” The best form design is one that is completed first on paper and then re-created using InfoPath. During the design phase, you want to revisit your prototype form and, given what you now know about the database, indicate which of the fields on your form are going to come from the database, which are going to need to be validated, and what criteria are to be used in those validations.

You should also have a good idea about how the data is organized and be able to determine what grouping and sorting is required, as well as which records to select to get the results you need.

Developing and Testing the Design

With the design completed on paper, it is time to open InfoPath and get down to business. After you have laid the groundwork, the actual form design process should be quick and simple, after you learn the skills in the upcoming chapters. After the initial form development is complete, you should test your form on a number of different computers or operating systems. Note any performance issues and revisit your form design to see if you can make any performance enhancements.

If you have created a form that validates user input, try entering bad dates, the same date, incorrect text, and so on to view the error messages that will appear. You need to be prepared to handle any situation that a user may encounter.

Deploying and Operating the Form

As the final step in the form design process, consider how your form is going to be used. Will users access the form locally? How does the data captured in the form translate when you export to Microsoft Excel or HTML? Try to export the form yourself. You may need to revisit your form design based on the results of your exporting attempts.

Will users be able to modify the form? Have you locked the form design for changes? Again, you may need to modify the form design based on these answers.

Finally, when the form is in production, you need to monitor the operation of the form to ensure that it performs as expected and that the form is still relevant. Many organizations think that creating a form stops when the form is handed to its user. To the contrary, the form design process should be ongoing throughout the life cycle of the form and should continually analyze ways to enhance the information captured and to add additional value to the data.

An easy way to learn how to develop a form prototype is to jump right in and tackle an existing form request. If you are creating the form on behalf of someone else, there may be a little extra work spent interviewing the user and making sure the form prototype meets their needs, but it is definitely time well spent. If you ensure that the user is happy with the form’s design before you begin, there will be no surprises when you deliver the final product.