If InfoPath is so great why isn’t everyone doing it?

Perception is king, too bad it is often misled!  If we take a minute to really examine the large majority of line of business applications that we spend time creating, deploying, and monitoring. Many of these applications are designed around the same core requirements which include providing your customer with the ability to capture, retrieve, edit and submit, data to an API, service or storage repository (i.e. a database or content management system).  Think about the amount time, money and energy creating the most basic of applications, using technologies like .NET, Java, PowerBuilder VB6, etc.

This where I have spent a far amount of time recommending InfoPath to our customers, only to meet the same objections time and time again.  InfoPath is just another technology I have deploy, and support on the client.

So, if InfoPath is so great, then why isn’t everyone using and deploying InfoPath solutions?  The most common customer objection to using InfoPath is the requirement to deploy the InfoPath client.  In order to fill out an offline form you have to install something on the client.  The form requires a container, in other vendor solutions and even your custom solution to provide the common functionality we listed earlier (capture, retrieve, edit, submit).  Let’s take a look at a few alternatives and discuss how InfoPath helps to solve the problem of the ever increasing number of applications your call center and IT teams need to support.  Consider the following customer scenarios:

Customer “I need an offline solution for people to be able to fill out forms, validate user input and submit when they are back online.”

Response: “InfoPath would be a good solution for you to quickly deploy forms that can be submitted to a web service, database repository or SharePoint form library”

Customer “We are not going to use InfoPath it requires us to install a client on all of the workstations”

Response: “Let’s examine the other options”


·         You have to deploy Word/Excel

·         The data is not structured and form support in Word/Excel is very limited this is not the best solution for forms.

Build a "quick" app using a technology we already support (.NET/J2EE/PowerBuilder/VB6/Other):

·         You have to deploy the app to the client

·         You have to build your own shell (again)

·         You have to come up with the format for exchanging data and write all the code to submit the data (again)

Purchase another solution like Macromedia or ADOBE eforms:

·         You have the deploy the client (and make sure the version of the client installed is the one you intend to target

·         You probably already own Office (at least in many corporate scenarios)

·         .NET development are on par with Java development (we can argue but what’s the point)

·         Integrating the data with other Office applications can be a challenge; InfoPath is part of Office so integration from the suite is very prescriptive

- and no everyone does not have the ADOBE reader (or even the same version already deployed).

We will just use the browser:

·         Planning on doing any custom business rules you need to deploy the business rules.

·         Planning on supporting anything besides Internet Explorer?  You have to deploy the client.

·         Scripting is a maintenance nightmare and provides poor support for debugging (especially remote debugging).  How many offline browser applications exist today?  I agree this is a great solution for online forms but offline forms have a number of challenges when hosted inside a browser for editing.

What about Groove?

·         We think Groove is a great solution for offline forms just like we believe InfoPath is a great solution; however there are two challenges today before you determine Groove is the right answer for you:

·         Today Groove uses its own form technology that existed before Microsoft acquired Groove Networks.  This is yet another programming model you will need to support and it is not the strategic direction for the next release of Groove (2007).  The next release of Groove will use the InfoPath form engine.

·         You need to deploy the Groove client

The end point here is you are probably deploying to a Windows client, and in many scenarios there is a good chance you are running some version of Office on the client; especially for applications targeting internal users in the enterprise.  I have not seen many good offline solutions that do not require at least a one time deployment of a client, to provides a rich management, deployment and a great end user experience for the enterprise.  Keep in mind the alternative is to custom develop a solution, which often times lack many enterprise features for management, deployment debugging and security.

Using eForms in offline and online scenarios where I can leverage the capabilities of the client workstation, a tested shell that provides for a great out of the box user experience, XML file formats helps me to deliver value faster to my customers, while lowering the cost for development, deployment and maintenance.

For more information about InfoPath click here.


Additional Resources

FAQ’s for InfoPath

Comments (10)

  1. Mike Hartley says:

    Interesting – only the other day I posted on article on my site (http://www.wildmind.co.uk/index.php?id=28) talking about InfoPath and how I feel it’s underrated and underused.

    I think a big issue for a lot of people is finding info about InfoPath and working out how to use it. Intuitiveness isn’t a strong point and adjusting thinking at times isn’t the easiest of things.

    Looking forward to seeing what the next version holds though 🙂

  2. ShadowChaser says:

    InfoPath is great, but it’s only one part of a solution. There’s no way to view data or organize data – just entering random forms isn’t very usefull by itself.

    I’d love to see InfoPath sold as some sort of licensable/royalty control for Visual Studio. I’d LOVE to redistribute and embed this sucker with my application, but right now it’s impossible.

    InfoPath could be a huge Lotus Notes killer, if only they would add the "View" and front end support to it!

  3. Chris says:

    Many of our clients are using a tool called Infoview (www.infoview.net) to convert InfoPath forms into web forms and therefore kill the need to deploy InfoPath on every desktop.

    Sure…forms need to be created with InfoPath in the first place.

  4. David says:

    >>Perception is king, too bad it is often mislead!<<

    Your English needs a little help, Bub.

  5. John Dowdell says:

    What’s the size of an InfoPath client, and what OS/hardware does it require? Is there a download link? This might be another factor in people’s decisions.

    (I tried searching but got website runaround.)


  6. JD,

    I would say we are comparable to the Adobe solution.  We run on Windows 2000 or Windows XP, and we require 100 MB of disk space.  See http://www.microsoft.com/office/infopath/prodinfo/sysreq.mspx for additional details

    According to the ADOBE site (http://www.adobe.com/products/acrobat/acrrsystemreqs.html#70win) the requirements are pretty much identical with the exception of the size where you require 90 MB, I am thinking the extra 10 MB is not a deal breaker in most deployment scenarios especially in the enterprise setting.



  7. John Dowdell says:

    Hmm. The free Adobe Reader is a 20-megabyte download, and also runs on older Windows systems, as well as Macintosh, Linux, more. For what it’s worth.

  8. I will agree that the consumer space or public domain may be another conversation.  Note many of my comments refer to enteprise customers and line of business applications.  The specs posted at the following link must be something different or a typo: http://www.adobe.com/products/acrobat/acrrsystemreqs.html#70win.  What do these specs refer too?

    Back to the comments about the consumer space or solutions for the public.  How many scenarios do you know if that require or really benefit from offline forms for the public or consumer space?  Keep in mind I am not asking for 1 or 2 examples.  I can think of a few, but that is the point I can only think of a few.  Even the sales force automation scenarios, most of them have a captive audience.  The tax scenario may be the one of the few but outside of that it is a stretch at best.  In most cases a connected browser based solution is a better story when talking about public access to eForms.


  9. John Dowdell says:

    Are you referring to this line?

    "Up to 90MB of available hard-disk space"

    If so, then you might be opening a multi-megabyte document, and so would need local space to store it. This is distinct from the size of the rendering engine.

    "How many scenarios do you know if that require or really benefit from offline forms for the public or consumer space?"

    I don’t know, I haven’t taken the time to enumerate how many I could imagine. For "What are some additional scenarios for self-contained documents beyond tax forms?" then a few include any financial agreement, any contractual agreement, the whole static document scene of course, the great range of archival documents (see ISO 19005-2), building plans and inspection certifications, the collaborative history of a group document, the collection of a range of electronic documents into a single archivable package, the connection of electronic presentations (video, animation) with text documents… but basically, if you fill out a form online, then it’s good to have a digitally-signed and checksum’d local version of it, so that your records don’t only live on Someone Else’s Server. Is this the type of thing you were seeking…?

Skip to main content