InfoPath 2003 Decision Tree: Comparing InfoPath Forms to Other Microsoft Solutions

Article
05/23/2014

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

Summary: Learn which product or technology to use for creating client information solutions. This article clarifies the role that Microsoft Office InfoPath 2003 plays in relation to Windows Forms, Web Forms, and Microsoft Office Word 2003 and Microsoft Office Excel 2003 smart documents. (14 printed pages)

Peter Kelly, 3Sharp, LLC

September 2003

Applies to: Microsoft Office InfoPath 2003, Microsoft Office Word 2003, Microsoft Office Excel 2003

Contents

Decision Tree Overview
Microsoft Solutions Landscape
Windows Forms
Web Forms
Smart Documents in Word 2003 and Excel 2003
InfoPath
Choosing the Right Option
Expense Reports
Status Reports
Conclusion
Additional Resources

Decision Tree Overview

Microsoft provides a few different ways to create office productivity solutions. All of these technologies share a common goal: making it simpler and faster to create rich forms and documents and to gather and analyze the data stored in them and around the organization. Because different business tasks have different requirements and emphases, Microsoft has developed a few different technologies that provide a range of abilities to meet these needs.

The article offers a decision tree for both IT professionals and information workers to understand when to use each of Microsoft's technologies for creating client information solutions. The specific focus of this article is to clarify the role that Microsoft Office InfoPath 2003 plays in relation to the other technologies.

Knowing the capabilities of each technology — and when to use them — is an important part of effective solutions development. Therefore, the article begins with an overview of four Microsoft solutions technologies (Web Forms, Microsoft Windows Forms, smart documents, and InfoPath forms), identifying the unique strengths and deployment considerations of each, and paying particular attention to the capabilities of InfoPath. After describing the solutions landscape, the article goes on to provide a number of individual examples in which one or another solution approach makes the most sense. Taken together, these examples are intended to deliver a best practices guide for how and when to use InfoPath solutions.

Microsoft Solutions Landscape

Data gathering and analysis are key parts of modern business operations. Business intelligence, customer relationship management, and enterprise application integration all demand continual feeds of data from various applications and processes. Microsoft, particularly with the Microsoft Office System, provides powerful enterprise-level tools for building client solutions that link to back-end data sources and processes, using traditional means, XML, and Web services. There are four main options available for developers using Microsoft technologies:

Microsoft Windows Forms combine the flexibility of the Web Forms development process with the ability to use native Windows services on the Windows desktop. The result is an executable solution that can be deployed on client desktops and that provides a native Windows experience to end users.
Web Forms allow solution developers to reach a broad audience. Web Forms code can be implemented using ASP.NET, Microsoft ActiveX controls, and various scripting languages. The resulting solutions are accessible to clients from Microsoft Internet Explorer and other modern Web browsers, often without requiring any configuration or installation on the client itself.
Microsoft Office Word 2003 and Microsoft Office Excel 2003 both support mapping of XML schemas. Furthermore, documents in both Word 2003 and Excel 2003 can be smart documents. To create a smart document, developers add context to an XML document so that actions or help can be provided to information workers depending on where they are working within a document. Organizations can deploy and update smart document solutions from a single server location. For information workers, smart documents are a great solution because they are already very familiar with the Word and Excel environments. This reduces training costs and improves user acceptance.
InfoPath is the ideal application for rich data capture and validation and provides extensive support for XML. The InfoPath toolset includes an XML forms editor and an XML forms designer in the familiar Office user interface and a Solution Developers Kit. InfoPath-developed solutions can be used online or offline, and, through built in support for Web services, they can be tied to any back-end system that supports industry-standard XML.

Note that these technologies often work together. For example, a developer can combine smart document and InfoPath solutions to solve different aspects of the same business problem. Outside the firewall, the developer may decide to build a Web form that uses the same Web services and back-end systems.

Table 1. Comparison of four technologies for client information solutions

	InfoPath	Smart Document (Word or Excel	Web Forms	Windows Forms
Custom Code / Deployment	Little script	DLL	ActiveX, Script	Compiled Code/Executable
Solution Flexibility (for users)	High	Medium	High	Very High
Security	High Security with Trusted Deployment (URN) Can use Web security with Sandboxed Deployment (URL)		Same as any Web page/application	Developer determines security requirements and architecture
Ease of Deployment	High	Medium	Very High	Medium (client application deployed to desktop)
Client Component	InfoPath and custom form template	Word 2003/Excel 2003 and custom DLL	Web browser	Custom client component
Key Benefits	Easy to deploy Strong data validation Native support for customer defined XML data	Familiar user environment and full feature-set of Word/Excel Reuse XML data Easy to deploy	Easy to deploy One size fits all	Build any application Have access to the client operating system functions

Windows Forms

Windows Forms is a framework that provides a clean, modern API that combines the power of the Windows API with a rich set of services drawn from the .NET Framework. Building applications with Windows Forms gives users the familiar Windows interface while preserving existing investments in Windows API-related tools and techniques. However, developers who use the .NET Framework often find that it is much richer than the Windows API, and when you write applications using Windows Forms, you have the full power of the framework at your disposal. More often than not, applications written using Windows Forms require less code than applications that use the Windows API or MFC.

Another benefit of Windows Forms is that you use the same API, regardless of which programming language you choose. All applications that use Windows Forms are written to one API — that of the .NET Framework class library.

Windows Forms still require developers to build the application from the ground up, so they are not the ideal option for all needs. However, they run in trusted mode and give developers the richest access to other Windows services, and they make it easier for the developer to read and write native XML data by using the Windows XML parsing components. They also provide access to Windows security services (including cryptographic and authentication services), making them a natural path for applications that require additional security.

Web Forms

Web Forms are an ASP.NET technology designed to help developers build dynamic, interactive Web pages. They provide a programming interface similar to the APIs in forms-based development tools that are used in building highly responsive office productivity applications.

Developers create Web Forms as combinations of HTML, code, and prepackaged server components (controls) that execute on a Web server running Microsoft Internet Information Services. Developers design Web Forms to render their own user interfaces by generating the appropriate markup language (generally HTML) to return to browsers. This rendering can take into account the client's language and Web browser version, providing an interface that is tailored to the client's capabilities.

Web Forms bridge the gap between traditional application models and Web programming models by making use of the same form-based programming paradigm that is already familiar to Windows-based developers. Using Microsoft Visual Studio .NET, Web applications can be created by dropping controls onto forms, then double-clicking those controls and writing event handlers. The code for the event handlers can be written in Microsoft Visual Basic, Microsoft Visual C#, or any other language that is supported by a .NET compiler.

One of the key benefits of Web Forms is that, because the bulk of the work is done on the server, virtually any Web browser can run a Web Forms application. Prepackaged server controls are a huge advantage, too, because they reduce complex UI elements to simple HTML-like tags, and promote smart server components that adapt their output to the target browser. Because Web Forms applications run on the Web server, their security is linked to the security of the Web server — it is important to ensure that the Web server is properly secured to protect the integrity of the application.

Web Forms are a good choice when there is a heterogeneous user base. For example, many heavy manufacturing companies have UNIX workstations for computer-aided design; Web Forms-based applications can be used transparently from Windows, Macintosh, UNIX, and Linux machines, making them a natural choice for heterogeneous environments. Web Forms also make sense when it is known that the application will be used by a diverse set of users (including users whose desktops you do not control). In such cases, it is unreasonable to expect all clients to have a certain application or component installed.

Smart Documents in Word 2003 and Excel 2003

A Word 2003 or Excel 2003-based smart document solution combines an underlying XML structure with custom code to enable special actions within the document. Actions are based on where the cursor is placed within the document and can range from context sensitive help information, data retrieval, formatting actions, and others.

When an information worker opens a smart document, the document exposes a set of actions in the Document Actions task pane. The actions available depend on the section of the document being edited; developers can build actions that display help text, ask for user input (using standard Microsoft Windows controls like check boxes and text fields), or retrieve data from other applications or back-end servers. Once the user enters the data necessary for a task, the smart document can perform actions like looking up data, formatting it according to the document's template, and placing it in the document — all automatically.

End users gain productivity because their common tasks are "understood" by the document, making it easier and faster to build documents for specific jobs. Because smart documents are built using the industry-standard XML and any of a range of programming languages, they are easy for developers to build and test — which in turn makes it easier to develop solutions for all groups of information workers in an organization. This makes it possible for information workers to work faster and more efficiently, enabling faster time-to-market and better communications throughout the enterprise. This improvement comes with no additional user training, since smart documents leverage the Office 2003 interface to expose their functions. In addition, since Word and Excel are rich clients, they can work offline and allow users to save their work and resume later as needed.

Smart documents require some coding, but not as much as Windows Forms or Web Forms. Integration with back-end systems is relatively easy to accomplish through Web services. To create a smart document solution, the developer first attaches an XML schema (any customer-defined XML schema) to a Word document or Excel workbook and annotates the portions of the document that will have smart document actions or help content associated with them with XML. Then the developer creates actions based on XML elements within the document and compiles the solution as a DLL (and any supporting files). To deploy the solution, the developer digitally signs the DLL, creates a Solution Manifest file (which is also signed), and the administrator places the solution's files in the locations referred to in the solution manifest.

To use the smart document, information workers simply open the Word document or Excel workbook that is designed to be a smart document and start interacting with it. The manifest will prompt the information worker to download the solution's components (XSLT, DLL, managed code assembly, and so on). Smart documents have a good security model as well:

Smart documents can be controlled by security policies.
Solution manifests must come from trusted sites. The solution manifests themselves must be code signed or otherwise trusted.
Code that runs as part of a smart document solution is subject to the users' Office security settings.
Users are prompted whether to initiate a smart document solution install.

Since smart document solutions can be loaded from a server, they can also be updated from the server, which simplifies the process of updating a solution.

InfoPath

InfoPath provides information workers with a set of tools that enable the creation of dynamic forms to gather and share information across a wide range of formal and informal business processes. Unlike traditional forms packages, InfoPath provides a high degree of information-gathering flexibility, enabling people to obtain the information they need in a timely fashion and to make well-informed decisions. Information workers enjoy seamless integration between InfoPath and the other Office System 2003 programs.

In addition to a rich design environment for the forms themselves, InfoPath provides excellent integration with existing enterprise systems, including non-Microsoft databases and middle-tier systems. This means that developers and IT professionals can work together to build powerful business process solutions that leverage the existing environment. This integration is possible chiefly because InfoPath supports any customer-defined XML schema (its native file format is XML) and because InfoPath has built-in support for Web services.

Thus, a customer with an SAP system, a Microsoft SQL Server-based inventory system, and a schema already in place for dealing with internal and partner transactions, can build an InfoPath solution that provides all the richness of the InfoPath client environment and, through Web services, the ability to retrieve and write back to multiple back-end systems, participate in workflow, and so on.

In such a "smart client" solution, data entered by users can be dynamically validated to ensure that it is correct and complete before it is passed on to the next tier. All of this means that any information gathered with InfoPath can be reused and repurposed by anyone or any process in the organization, which greatly increases the productivity and power of that information.

When comparing InfoPath forms to Web forms, a few considerations apply. First, unlike a browser, InfoPath is a rich client with all the functionality that a rich client can offer, including rich text editing, spell checking, and AutoCorrect. Second, InfoPath provides a natural interface for working with repeated groups of data and optional fields, even when working with existing customer schemas. Web Forms require manual coding to deal with XML schemas. Third, InfoPath forms tend to be easier to build than Web applications. Fourth, InfoPath provides a document-like model that gives you the ability to work offline, completely disconnected. You can save your work to your computer and resume working at your convenience. Finally, InfoPath provides the ability to validate business logic on the client, online and offline. In general, the more complex the data and schema, the more ideally suited is InfoPath.

InfoPath lets you work offline on a form because it caches the form template after the first use. It also has built in support for updating the form template to let the form developer roll out new features and bug fixes without any user interaction. Because of the automatic deployment, InfoPath has a strict security model on these templates (this is a sandboxed deployment). If a developer needs full access to a client machine with a form, InfoPath gives the developer the option to create trusted templates, which need to be installed on client machines (this is a trusted deployment and is similar to the deployment of a smart document or a Windows Form solution).

For team-based data gathering and collaboration scenarios, InfoPath and Microsoft Windows SharePoint® Services provide great integration. With built-in support for form libraries, information workers can use InfoPath to easily create and publish forms to the forms library, where they are available for all to use.

Form Deployment

InfoPath solutions do require the client to have a copy of the InfoPath application. For deployment of forms, InfoPath provides two options: Sandboxed (URL) and Trusted (URN).

Sandboxed solutions are not registered locally. They are installed by URL (download can be silent and upgrades can be automatic) and are stored in a local cache. Sandboxed solutions run under the same security model as Web pages in Internet Explorer and have access to the current form only (they don't have access to any resources of the local computer). Organization should use sandboxed solutions as the default choice any time the scenario can be accomplished in a sandboxed security mode.

If the solution needs access to local resources such as writing to local files, or if it needs to run trusted code (such as Microsoft Visual C++ components), a trusted solutions is necessary. Trusted solutions require a client install (using MSI or some other setup technology) and explicit upgrades.

Example: Sales Call Report

Sales call reports and other internal data gathering forms can really take advantage of InfoPath and its ability to provide a flexible yet structured form environment. In the example shown in Figure 1, a number of user interface features have been provided to make the data gathering process as easy and as rich as possible. Not shown in the figure, but just as important for salespeople, is the ability to work with the form offline. The form developer can create the form to provide full functionality online and offline.

Figure 1. Sales call report solution in InfoPath

This InfoPath form contains a context-sensitive drop-down menu for a customer field group, enabling the information work to add another customer field group, remove this customer field group, insert an item row in the table of purchase items in this field group, or insert an optional actions field group within the field group.

This form has some custom, code-enabled conditional formatting, but InfoPath also allows designers to apply conditional formatting out of the box. For example, a form designer can configure a field to appear in specific ways when specific conditions are met.

The optional actions section would then have its own elements, which could include actions that would route this form to an order fulfillment center. The Click here link provides another way to insert the actions field group. Another feature of this form is the conditional formatting within the order field. Notice that the number "100" appears green; conditional formatting defines that a value of 100 or greater should appear green, indicating an acceptable order quantity. The second entry has been given a value of "99" and appears red to indicate that it is not within the proper range.

Choosing the Right Option

With such a broad range of powerful options, picking the right one for your scenario may seem confusing. Different business processes have different requirements, tasks and document types; these differences provide a way to explore the most appropriate development approach to each scenario.

Determining which technology to use for a given task or document type is not exact science. For good reasons, there is a fair amount of overlap among Windows Forms, Web Forms, smart documents, and InfoPath forms. For example, a developer could design a Windows Form-based expense report solution. However, a Web Form solution, or better, an InfoPath-based expense report solution, is easier to develop and deploy in most environments.

There are general criteria that can guide the decision (as illustrated in Figure 2). Specific considerations are the kind of document or task, how the data in the document will be used, and the logical and physical location of those who will use the solution. Note that the decision tree depicted is by no means a strict set of rules. Clearly, "soft" factors, such as user preference, can be a strong influence alongside the basic parameters described in the decision tree. For example, in the Office Client Choice Test branch, InfoPath is shown as the appropriate solution in situations where analysis and reporting are less important than structured, dynamic, and hierarchical layout of data. In a situation well suited to an InfoPath solution, however, an organization may still choose Excel or Access with good success. The point here is simply to assert some general guidelines.

Figure 2. When to use InfoPath forms as compared to other options

Expense Reports

As with most office productivity tasks, developers could build a solution for expense reports using Windows Forms, Web Forms, InfoPath forms, or smart documents. Windows Forms are clearly overkill for what is needed in an expense report. Web Forms may make sense — for example, a Web form may better help to protect credit card information. However, a key drawback of Web Forms here is the inability to use them in offline mode.

An InfoPath expense report form would be very easy to design (with little coding). InfoPath comes with a sample expense report form, which contains a few key elements that marry it well to the needs of an expense report. An Itemized Expenses field contains repeatable sections, so that an information worker only needs as many lines as his entries. There is also an optional Notes field below that is hidden until the information worker clicks on it. In addition, InfoPath forms can be created and completed while offline, making it possible for information workers to complete their expense reports while traveling and upload them when they return to the office.

Status Reports

Status reports combine a structured document layout with free-form data entry. Weekly status reports, for example, will contain consistent topics that need to be addressed (Goals, Tasks Accomplished, Goals for Next Week, Blocking Issues, and so on). Within this structure, an information worker will also provide free-form text to support the status of projects.

For status reports that consist of mostly structured information with some space for free-text editing, InfoPath is the clear choice. For status reports that contain little structured information and a majority of free edit areas, Word 2003 may make more sense, with smart document logic providing any needed structure and associated actions as well as contextual help for all sections, including free-form sections.

A status report created in InfoPath could contain some required fields (for example, tasks completed), some optional fields (for example, additional comments or recommendations to management), and so on. It could also have routing logic that automatically sends the report to the information worker's manager, based on user detection and business rules.

Finally, the manager could use the built-in merge functionality in InfoPath to aggregate information from multiple status reports into a single form. She could do this within InfoPath alone or within Windows SharePoint Services.

Requests For Proposals and Other Document Generation Tasks

While many repetitive tasks can be automated, creating Requests For Proposals (RFPs) and other such documents is still a very manual process that requires creative input from information workers. RFPs are usually quite large, complex, documents whose purpose is to be presented. Thus, the rich formatting capabilities of Word 2003 make it an obvious choice. With smart documents, much of the document generation, data gathering, and data manipulation can be handled by the document itself.

For example, an RFP for a call center contract might contain the following elements:

**Pricing **With details on overall service costs, plus costs per individual service type.
Organizational Capabilities With details on daily call volume, seasonality, call wait time, and so on.
**Facilities **With details on number, locations.
Systems With details on hardware/software type, IT support, disaster recovery, and so on.
**Reporting **With details on capabilities, report samples, costs for reports, and so on.
Quality and Monitoring With details on quality assurance programs, monitoring programs, number of monitors, and so on.
**Appendix **Organizational chart, annual report, client list, promotional materials, and so on.

Without a smart document solution, putting together this information will require a lot of manual (and error-prone) cutting and pasting, looking up information in databases, and so on. Since our sample call center responds to many RFPs, all of which contain these common elements, they have developed a smart document solution that eases much of the information gathering and sorting. For example, an information worker who is filling out the pricing section might have a smart document action that queries the company's back-end systems to retrieve precise, up-to-date metrics, format them as a chart or graph, and insert them properly in the document.

Beyond the smart document functionality, there are a few common-sense reasons to use Word in this situation. The length of the document, the desire to track changes in a collaborative environment, and the need for high fidelity printing all make Word the most compelling environment for such solutions.

Information Processing

Some common examples of information processing documents are questionnaires, receptionist forms, and telephone trees (such as those used by call center support staff). Traditionally, the structure for such documents is rigid and the permissible range of values for the form's fields is very narrow so they are often presented as forms. InfoPath is the ideal choice for these documents, which are at their best when they respond and change based on the information being entered and integrate well with back-end systems. For example, an InfoPath-based questionnaire could:

Provide data validation to ensure that the answer provided is meaningful
Determine, based on a Yes answer to a question, that an additional explanation section is now required, then automatically add it to the document
Provide repeating sections on the fly to accommodate additional input
Provide the ability to enter rich text and check spelling
Provide flexible formatting and printing options for cases where paper forms are used (for example for service orders or repair tickets)
Be developed very quickly and modified very easily

The XML data captured in InfoPath forms can be submitted, from within InfoPath, to a Web service for further processing. InfoPath can work with Microsoft BizTalk Server, and it can interact with IIS (through ASP.NET), Microsoft SQL Server 2000, or any third party back-end system that can use Web services. InfoPath can be configured (without coding) to use the ADO (ActiveX Data Objects) interface to talk directly to SQL or Microsoft Access.

Data Analysis

Information workers have long turned to Excel for data analysis tasks. Excel 2003 is even more suited to documents in which data analysis, interpretation, and presentation are all important. Excel 2003 smart documents, like Word 2003 smart documents, base available actions upon XML elements within the document.

For example, an investment-banking firm could create an Excel 2003 smart document to assist in analyzing the financial health of a company. The smart document might provide context specific help instructions to the analyst based on which cell was selected. The document might also retrieve company information from a number of sources (publicly reported price and SEC information, other economic information, and so on). All of this information could then be programmatically sorted, processed, and compared with internal data or run through a proprietary analysis technique. The analyst spends less time looking for information, is less likely to commit errors (downloading data on the wrong company), and is able to produce a consistent, refined presentation of data, based on the smart document template.

Sales Documents

Salespeople often need to create customer-tailored sales documents, which are, in effect, miniature proposals. For example, a salesperson at a pharmaceutical company, whose job it is to visit doctors and distribute product samples, would need to create a document for each doctor she visits. The document would include product datasheets, the doctor's specific address, license, and specialty information, a letter of introduction, a form cataloguing the number of samples distributed, and so on.

Since the necessary end product in this scenario is the document itself, either printed or electronic, a Word 2003 smart document solution makes the most sense. In the solution, the salesperson interacts with the document, providing the doctor's name and specialty. The smart document retrieves the doctor's current address and license information and places it in the document based on the mapping of XML elements. The smart document continues to allow rich flexibility in creating the sales document, while the data gathering and formatting actions dramatically simplify the overall task.

Clinical Documents

Documents that need to conform to a specific structure, either by law or by convention, are great candidates for InfoPath. For example, the HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. These clinical documents need to conform to some key requirements:

Persistence A clinical document continues to exist in an unaltered state, for a period defined by local and regulatory requirements.

Stewardship A clinical document is maintained by a person or organization entrusted with its care.

Potential for authentication A clinical document is an assemblage of information that is intended to be legally authenticated.

Wholeness Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.

Human readability A clinical document is human readable.

A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content.

In addition to meeting all these requirements, an InfoPath form can be designed to conform to an existing customer-defined XML schema, if necessary. A doctor's office could use the form to gather information about a patient: for example, that he has been diagnosed with high blood pressure and hypertension, and a medication has been prescribed. The InfoPath form is compliant to the CDA standard and contains coded entries for the diagnosis (hypertension) and the prescription (Hyzaar) as well as the doctor's and patient's name and identifiers. The same information is then used to generate an order (in another structured document format) that is then send to the pharmacy in order to fill the prescription for the patient.

Conclusion

InfoPath dramatically simplifies the process of developing rich, integrated forms. While Windows Forms, Web Forms, and smart documents are clearly appropriate solutions in certain scenarios, developers can turn to InfoPath to help solve difficult problems for which these other approaches are not ideal. Table 2 summarizes the document and task types described in this article. It also gives a quick view on where and why Windows Forms, Web Forms, smart documents, and InfoPath forms make sense.

Table 2. Summary of document/task types and appropriate solutions

	Recommended Solution	Key Factors in Solution Choice
Expense Report	InfoPath form	Focus on data and data structure, as opposed to the document containing the data Process oriented
Status Report	InfoPath form	Focus on data and data structure Process oriented Flexibility of InfoPath (rich text, optional sections, and so on.)
RFP	Word smart document	Focus on the document as the end product Length of the document and need for high-fidelity printing Rich authoring/editing and collaborative capabilities of Word 2003 Powerful custom capabilities of smart document actions based on XML elements within document
Information Processing Tasks	InfoPath forms	Very process oriented Flexibility of forms (repeatable sections, optional sections, data validation, rich text) Powerful form logic (for example – decision tree, pain chain) Integration with back-end systems through built-in support for Web services
Data Analysis Tasks	Excel smart documents	Powerful analysis capabilities Powerful XML support Support for Web services for data gathering and submission
Sales Documents	Word smart document	Focus on the document as the end product Length of the document and need for high-fidelity printing Rich authoring/editing and collaborative capabilities of Word 2003 Powerful custom capabilities of smart document actions based on XML elements within document
Sales Call Reports	InfoPath form	Very process oriented Flexibility of forms (repeatable sections, optional sections, data validation, rich text) Integration with back-end systems through built-in support for Web services
Clinical Documents	InfoPath form	Focus on structured data Ability to exchange data with partner/supplier Ability to conform to structure and work with customer-defined XML schema Flexibility of InfoPath forms

This article provides a framework in which to think about when to use the different Microsoft technologies for creating client information solutions. In general, whenever information needs to be gathered and manipulated, developers may want to consider InfoPath first.

Additional Resources

For more information, see the following: