InfoPath

It looks like I'll be starting a new project soon that involves the creation of about 30 InfoPath Forms.

If you're not familiar with InfoPath, it is a new product that is part of the Microsoft Office Family. InfoPath's main purpose in life is to collect data. It provides an interface to allow developers (or non-developers) to easily create data entry forms. The forms are made up of controls (text boxes, check boxes, etc) and can have all kinds of validation built in to them. What gets created is a template file, that is actually an XML document that defines the form and its data structure.

Users can simply double click the template file to open InfoPath and fill out the form, then the data can be saved as XML, or sumbitted to a database or web service.

While doing a presentation on InfoPath recently, I was asked if, as a developer, I would honestly choose InfoPath over simply writing a quick and dirty Windows Form Application in VB.NET or C#.

That's a good question, since most developers are going to stick with what they are comfortable with. However, I have found that for simple data entry forms, I can build the form in InfoPath much quicker than developing an application. It would have to depend on the situation, of course, but I think InfoPath will find its place as part of larger solutions.

For example, the Office Solution Accelerator for Recruiting combines many technologies. It uses SharePoint and WebParts, web services, and InfoPath together to create a solution for tracking candidates through the interviewing process. InfoPath is actually a small part of the solution, but ties the solution together. Developers need to be able to know when to use which technologies to make a solution work.

For more information on InfoPath, see the excellent InfoPath SDK and check out the InfoPath Team Blog