Comparing InfoPath and SharePoint Designer Forms

By Jeremy Sublett

Let's compare two different form technologies for SharePoint, InfoPath forms (using Forms Services) and forms created with SharePoint Designer.  Despite different steps, both of these solutions achieve the same thing: browser-based form technology.

Microsoft Office InfoPath and SharePoint Form Services have been touted as the solution for data collection in SharePoint. InfoPath enables power users to develop very powerful input forms and when used with the enterprise version of SharePoint, these forms can be rendered in the browser. There are other options for forms, however. You can create custom web parts, user controls, and application pages that collect information.

Another alternative that is relatively easy is to use SharePoint Designer to create forms using the Data View web part. In this article, we’ll take a look at the pros and cons of InfoPath and SharePoint Designer Forms in the context of SharePoint Server 2007.

Before we get too far, let’s briefly discuss what these two tools can do. InfoPath is strictly a forms creation and editing tool. Although it was built with SharePoint in mind, it has the capability to serve as a frontend to applications and can stand alone. With little or no coding, you can use it to build forms that can access many data sources in both a read and write capacity.

SharePoint Designer, on the other hand, is a website-editing tool. It can assist the web developer with many tasks. When used in combination with SharePoint, this tool lets you create web-based forms that provide a frontend to SharePoint lists. Let's look closer at these two tools.

InfoPath 2007

InfoPath is a stand-alone product within the Microsoft Office suite of tools. It has been around since Office 2003 and has always provided power users with the ability to develop forms with multiple input elements: text boxes, radio boxes, drop-downs as well as repeating groups/sections of controls. Once you create an InfoPath form, you can publish it to a variety of locations for people to fill out.

Although there are other options, SharePoint is a common destination for these forms. Regardless of whether an InfoPath form is published to SharePoint, filling out a form will usually result in an XML file. In SharePoint, this file is what’s stored in a document library. When clicking on an existing XML file produced by InfoPath, users will be presented the form, with the form’s original data.

Until SharePoint 2007 versions came out, all users of InfoPath forms were required to have InfoPath installed, which required a license. Now, users can fill out and edit these same forms through a web browser. This functionality is made possible through a product referred to as Forms Services or Forms Server, depending on the environment.

Forms Services comes with Server Microsoft Office SharePoint (MOSS) 2007 Enterprise. Forms Server what you would use with MOSS Standard or Windows SharePoint Services (WSS) 3.0. Forms Server is purchased as a separate add-on to the environment and is essentially the same product as Forms Services.

Creating an InfoPath form and publishing it to SharePoint is a relatively simple task. Once a browser-enabled form has been designed, you can use the Publish command within InfoPath to push the form to a SharePoint document library. In SharePoint, as long as the Enterprise Site and Site Collection features are enabled, you can simply go to the document library and use the form.

If InfoPath is installed on the client, the client application will automatically run. If not, the form will render in the browser. This default behavior can be changed by editing the list settings. The following are the steps in more detail.

In Part 2, I discuss SharePoint Designer and compare its features with those of InfoPath.

Jeremy Sublett is a software architect and senior partner with Composable Systems, LLC, specializing in SharePoint-based business solutions and is a Microsoft SharePoint MVP.

For more information on InfoPath, see "Speeding InfoPath 2010 Custom Form Deployment to External Lists" by Ethan Wilansky and Tomek Stojecki.