Tudor's overview of InfoPath browser-based forms

This is my first blog on InfoPath 12 so please allow me to introduce myself. I’ve started in Microsoft as a developer on FoxPro. If anyone still remembers the database container and the client connectivity, those are features I contributed to many years ago. Later on I moved to program management and worked on the` data access stack in the early days of odbc, oledb, and ado. I’ve always been passionate with data processing so, about five years ago, I’ve been super excited to participate in jump-starting an incubation project for authoring generic XML. That project grew into InfoPath 2003, then SP1, and now the brand new InfoPath v2 in Office 12.

After we shipped InfoPath 2003, we’ve surveyed InfoPath users and asked them for the most important feature round-outs they’d like to see in the product. In SP1 we’ve addressed 9 out of the top 10 requests. However we couldn’t address request #1 which was filling out InfoPath forms in the browser. This feature is now available in InfoPath 12! I think the best use of my first post on InfoPath 12 is to give you an insight into browser forms and share some of my thoughts on this feature.

One goal for InfoPath 12 has been to let users design a form once for both the rich client and the browser. Informally we call this feature “design once”. This way the same form template basically addresses scenarios that require the richness of the InfoPath client and scenarios for browser form filling, with zero client footprint. Choosing between rich and reach forms used to be a dividing requirement for form developers. Now InfoPath provides what I think is a very elegant solution for it. In InfoPath 12 users building forms only need to check the “Web browser enabled” checkbox to create a “design once” form. (Yes, I will talk in a follow up post about the “Template Part” option :-)).

Our functionality goal for browser forms has been to provide a level of validation for the data entered via the browser than matches that of the data entered in the InfoPath rich client. In other words, for “design once” forms, the xml schema validation, rules, conditional formatting, and business logic apply the same way for both rich and browser forms. InfoPath makes sure that the quality of the data submitted by a form is the same, regardless of the client that has been used to fill it out.

The layout is very similar between the rich and the browser version of a form. As you may know, the InfoPath client uses html for the form layout, which makes it very similar to the same form rendered in the browser. I’ve included below a Loan Application form rendered in InfoPath and in IE. Notice the same in-doc UI for repeating items, the same controls, and the same table layout, which makes the forms virtually identical. One difference is the spellchecking in the InfoPath client, which represents an improvement over the browser form.

Here is the same Loan Application form rendered in Internet Explorer:

The value of zero footprint forms is not complete if they are not available virtually on any machine and on any platform. InfoPath 12 delivers ubiquity of form filling. Users are able to fill out forms in current versions of IE, Firefox, Safari, and Netscape. The form functionality and validation remains the same across all browsers. We’ve worked hard to provide true ubiquity of form filling in order to allow all users to participate in business-to-citizen scenarios such as banking, insurance, healthcare as well as in many government-to-citizen scenarios. I’ve included another version of the Loan form below, this time rendered in Firefox:

In addition to the browsers mentioned above, we are also providing InfoPath forms for mobile devices. The set of controls available for mobile browsers is more limited. However we expect to run most forms that are appropriate to being filled out on mobile devices. Here is the same Loan form as above rendered on a PDA and on a smart phone:

I feel I’ve added a lot of screenshots for a first blog on InfoPath. To my defense, I’ve tried to make a visual statement on the ubiquity of browser forms and on their high layout fidelity in different browsers. I hope you found them valuable.

Finally, I wanted to mention a very important point. The first reaction of some customers when we show them the browser forms is to question the necessity of using the rich client: “If our users can access forms in the browser, with zero footprint, why would they ever need to run rich forms in InfoPath?” This question makes me think of my personal experience with Outlook Web Access. For me it provides a great experience for a browser mail client but I would never use it if I could work in Outlook. The rich functionality and offline caching are features I would never give up. I think InfoPath has a similar value proposition. It provides a smooth, self-contained form filling experience, with no server roundtrips. It gives you the ability to work on your forms offline. It also integrates with Outlook allowing you to route forms in email and store them in form-enabled folders, which become your local version of SharePoint form libraries. In addition, there are a few features, such as ActiveX controls and form rights management that work only in the InfoPath client.

This is my short dive into InfoPath 12 browser-based forms. I know I’ve mentioned a number of features without giving any details but I wanted to keep my posting scoped. I will follow up shortly with more product information. Please send me your comments and help me focus my upcoming posts on areas of most interest to you. Thanks and stay tuned!

Tudor Toma

Group Program Manager