Home > Samples > Update > September 2005
InfoPath 12 Headed for the Web    
   

[bio]

The following is the full text of an article published by Directions on Microsoft, an independent research firm focused exclusively on Microsoft strategy & technology. Each month we make one or more key articles available to non-subscribers.

InfoPath's capabilities will expand from designing desktop forms and entering data to creation of Web forms that end users fill out in a browser. The InfoPath design tools will also be available from within the Visual Studio development environment. The planned improvements will expand the reach of InfoPath, increase its ability to compete with Adobe's PDF format, and make InfoPath more attractive for professional developers. However, licensing details, yet to be released, could affect costs and adoption rates. Moreover, InfoPath still faces internal competition from many existing and planned forms technologies from Microsoft.

Smart Forms for Office Users

Introduced with Office 2003, InfoPath is an application for forms design and XML data entry that uses a familiar Office-like interface and allows offline data entry, which is not possible with Web-based forms. InfoPath forms can contain custom code to validate data and submit completed forms to back-end applications, such as customer relationship management (CRM) systems or enterprise resource planning (ERP) systems. However, InfoPath forms designers do not have to write code for many tasks, including validating data formats, automatically expanding forms to include new line items, and submitting completed forms to Web services.

InfoPath has been used for forms-based applications inside organizations, particularly for mobile workers or others who aren't online full time and who are familiar with Office. However, adoption has been hampered by the product's "thick-client" architecture: Every user must have InfoPath installed, even users who only enter data and never design forms. This has made InfoPath more expensive for IT organizations, which must license and deploy the product for every user. It also excludes InfoPath from markets where there is little or no control over the client platform, such as e-government initiatives that deliver services to citizens using digital forms sent over the Web. These markets, in turn, have enabled Adobe's competing Portable Document Format (PDF) to gain an early foothold for forms processing.

In addition, InfoPath initially did not support Microsoft's primary programming languages, VB.NET and C#, and is not integrated into the Visual Studio developer environment for coding, testing, and debugging. As a result, professional developers who use Visual Studio and these languages were often better off with Microsoft's Windows Forms or ASP.NET Web Forms platforms.

New Architecture for Browser Data Entry

InfoPath 12 will introduce a new thin-client option that enables users to enter data in a browser without requiring InfoPath on their computers. (See the illustration "New InfoPath Application Architecture".) Developers using this option deploy forms to a Web server, which then delivers the forms to users and collects completed forms for processing.

In the browser, InfoPath forms will still support some distinctive features, including locally saving a copy of a partially completed form (to support offline data entry) and conditional formatting (which adds or removes sections of the form based on user input). However, not all InfoPath features will be supported in browser forms. Consequently, InfoPath 12 will continue to support a thick-client architecture in which the full product is used to fill out forms that are too complex to be rendered in a browser.

The thin-client architecture will be supported by an InfoPath 12 forms server component, based on the existing Windows SharePoint Services forms library component. The new forms server will provide a Web-based user interface for retrieving and submitting forms. It will also provide APIs for server-side forms distribution and processing code, enabling developers to centralize code for these functions on servers rather than having to distribute this code to every client.

The new thin-client option will make InfoPath significantly more useful. Customers will now be able to design InfoPath forms for users who lack InfoPath. This will make InfoPath a candidate for designing "customer-facing" applications that serve clients outside of an organization's control.

New Forms Design and Development Options

With InfoPath 12, developers will be able to design, code, test, and debug forms from within the Visual Studio development environment. In addition, InfoPath 12 will have a managed object model, a more extensive set of managed APIs for custom code that validates forms input and processes forms. The Visual Studio designer and improved managed APIs will make InfoPath more attractive to professional developers accustomed to working in Visual Studio with the VB.NET and C# languages. They will be able to combine InfoPath forms-design tools with the superior debugging and more automated build process of Visual Studio, and the superior organizational features of those programming languages. The stand-alone InfoPath 12 product will remain; Microsoft believes the stand-alone InfoPath 12 will continue to serve forms design by part-time developers and sophisticated business users, who would be put off by Visual Studio.

Both inside and outside Visual Studio, the InfoPath 12 forms designer will include new design options to support the new thin-client architecture. Of particular note: It will enable a designer to create a single form that works both for browser users and for users of the full InfoPath product. These "design-once" forms are ASP.NET Web pages, which the designer deploys to an InfoPath 12 forms server. Once deployed, the Web page automatically detects the type of client (browser or InfoPath) and delivers the appropriate type of form (HTML or InfoPath XML) to that client.

With InfoPath 12, organizations will also be able to create libraries of forms controls and forms sections that include code to exchange data with specific back-end applications. For example, a company could create a library of customer information fields (e.g., customer last name) and sections, with all the code needed to retrieve and update the corresponding information in the company's CRM system. Libraries of such "data-bound" forms blocks could make InfoPath forms design more feasible for part-time developers and business users, because code for retrieving and submitting data can be the most complex part of a form.

Embedding in Office 12, Other Improvements

InfoPath 12 forms can be embedded in documents and messages created with the next version of Office (code-named Office 12 and expected in late 2006). This feature will require the end users of the forms to have InfoPath 12, but it could prove a useful way to collect data from Office 12 users, particularly when some of the data must be copied and pasted from an Office 12 document or message. This feature could eventually replace the three distinct, complex, and minimally maintained embedded-forms technologies of Word, Excel, and Outlook. ISVs will also be able to embed the InfoPath engine in their own applications, using planned InfoPath 12 ActiveX and Windows Forms controls.

Other notable improvements in InfoPath 12 include the following:

  • Utilities to convert existing Word and Excel forms into InfoPath forms
  • Rights management support in InfoPath, which could be useful for protecting forms that capture sensitive information, such as human resources data
  • Outlook 12 features for InfoPath 12 forms, such as a specialized "forms folder" type and a tabular view for previewing collections of completed forms.

Future Considerations: Licensing, Convergence

While InfoPath 12 will be a significant improvement, there are some important considerations for developers and other potential customers. First, the version's packaging and licensing have not been set. Some InfoPath 12 features (such as forms server capabilities) might require purchase of additional licenses, and some of these licenses might not be covered by current Enterprise Agreements. For example, the InfoPath forms server might be a separate product requiring separate Client Access Licenses (CALs) from the InfoPath client product. InfoPath 12 adoption will be difficult to predict until these potential costs have been determined.

Furthermore, InfoPath 12 is not Microsoft's last word in forms technology. Due around the same time is the Windows Presentation Framework (WPF), a new graphics and user interface system for Windows Vista and Windows XP SP2 that includes a built-in forms platform. Like InfoPath, the WPF forms platform uses an XML format (called XAML) to represent forms, but XAML forms can also include other Windows user interface elements, such as menu bars and toolbars. XAML will also support "high-fidelity" digital forms that closely match their printed counterparts; in fact, XAML is a superset of Microsoft's planned page description language, the XML Paper Specification (XPS, formerly code-named Metro). High-fidelity forms are a popular feature of Adobe's PDF forms technology, because they simplify compliance with regulations that mandate particular forms, and they can simplify user training and reduce other transition costs from paper forms.

The WPF is one of a large number of competing Microsoft forms platforms that will be available by the end of 2006. (See the chart "Forms Platforms".) At some point these many forms platforms might begin to converge. One possible scenario runs as follows:

  • Microsoft settles on two forms technologies, HTML for thin clients and XAML for thick clients, and a forms server that supports both technologies
  • Office applications such as Word, Excel, and Outlook adopt XAML for forms data entry as well as other user interface customizations, including Smart Tags and other customizations supported by the Information Bridge Framework today
  • InfoPath evolves into a design environment for form templates that deliver either HTML or XAML to users, and also can function as an embedded forms-design environment in Visual Studio
  • Microsoft supports migration of existing InfoPath forms and Information Bridge Framework metadata to XAML and HTML.

Convergence on XAML and HTML would imply reduced Microsoft support for the current InfoPath forms technology, although the company would likely provide conversion utilities and other support for migration. In any event, convergence could not occur until 2008 or 2009, the earliest likely ship date for a version of Office that supports XAML. Microsoft has not revealed any plans for convergence of its forms platforms, so developers starting long-term projects today will have to place their bets as best they can.

Resources

Office 12 and InfoPath 12 information will be posted at www.microsoft.com/office/preview.

The Microsoft InfoPath Web site is www.microsoft.com/infopath.

For an overview of Microsoft's developer platforms, including its forms technologies, see the Dec. 2004 Directions on Microsoft "Developer Platform Roadmap."

Microsoft's recommendations for choosing a forms platform appear at msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_ip2003_ta/html/odc_ipinfopathdecisiontree.asp.