InfoPath over jQuery?

A recent project had my team asking some really difficult questions on what technology should be applied to a business problem. We had been tasked to create a specialized survey in SharePoint that would need to change based on the items selected for each question. The question would present five or six possible answers, but all other answers might need to be cleared if a specific answer was selected.

For example, the question might read “Who needs to sign-off on this project?” and include “Information Technology, Public Relations, Marketing, Executive Leadership and No Sign-off Required” as possible answers. The person completing the survey could select any combination of the first four options. However; if the person completing the survey selected No Sign-off Required, all of the other answers become irrelevant so they should be cleared.

We looked at several options for presenting this in a graphically friendly way while allowing the data to be stored in SharePoint. We also needed a way to allow a high degree of customization of the survey without the site owner being required to open up Visual Studio or start hacking through a bunch of JavaScript code. Technologies that we explored included:

  1. Adobe Flash
  2. Microsoft Silverlight
  3. SharePoint Web-Part(s)
  4. jQuery / jQuery UI
  5. InfoPath

Flash was discarded pretty quickly due to the lack of available programmers and a client policy that discourages the use of Flash for internal business applications. Silverlight was discarded after some debate since the client is not yet ready to support on-going development of Silverlight Business RIA’s (they have an extensive .Net developer pool, but have not yet moved into Silverlight or WPF). SharePoint Web-Part(s) were eventually discarded due to the necessity of including a solution file for a one-off requirement. The team just couldn’t find any other business needs that justified custom web-parts, especially since this is a SharePoint 2007 implementation that is being migrated at some point before the project could be completed. This left jQuery and InfoPath as the most likely candidates.

InfoPath was initially discarded because the site owner wanted to emulate a Flash survey as closely as possible. We started down the path using jQuery with jQuery UI. Three custom lists were created in SharePoint: one to hold all of the questions, one to hold all of the possible answers to each question and one to hold the results of the survey. A form was dynamically created from the questions and answers stored in the SharePoint lists using SPServices. The person completing the survey would navigate through a wizard presenting each of the questions. When completed, the survey was then submitted back to SharePoint using SPServices and stored in a list where further actions could be taken at a later time.

It took us over two weeks to build the solution and almost 900 lines of  JavaScript had been written and tested. After successfully completing the requirements, we were discouraged because the end result did not meet our performance requirements (we suspected this might be the case as the solution was becoming more complex).  We even changed our web service calls from synchronous to asynchronous to try to solve the problem, but we still hit a performance barrier. So, we had to turn back to the only other technology available — InfoPath.

It took us less than an hour to create the InfoPath form using the questions required for the survey. By placing the questions and answers directly into InfoPath, this reduced our dependence upon maintaining questions and answers in two different lists. The site owner now had a familiar interface for modifying questions and answers in the same location — by simply editing the InfoPath template.

We began creating rules for each of the questions in the survey to perform the exclusive selection operation defined in the business case.  Setting up conditions and actions was much easier and ultimately more maintainable for the site owner if the structure of the question needed to change. Once the form was completed, it was published directly to a form library on the SharePoint site and set to use browser rendering. Key properties from the survey were promoted into columns within SharePoint that could be analyzed by workflow or exposed using views. The entire time from the initial design of the form to deployment in a production environment was about 8 hours.

The point of this case study is to help us consider how to tackle the business challenges we face in SharePoint. We must consider all of the tools available to us and match that with the goals of our client. We must also measure the requirements against the business problem we are attempting to solve. Our client was happy with the appearance of the jQuery solution, but the performance was not what they expected and the ability to change the presentation was not as easy as they desired. Conversely, InfoPath exceeded our expectations to solve the business problem. The rules and validation logic dialogs accelerated the development of the required business logic and the site owner had a much easier way to modify the verbiage of the survey as needed.

We demonstrated in this exercise that meeting the business requirement with out of the box tools requires much less effort and a can provide a more maintainable solution for site owners. As an added bonus, this form can be replicated to other sites quickly by simply changing the publishing location or saving the form library as a list template. Having a reusable solution like this increases the value to the client because it reduces the overhead of recreating the tool if it is ever needed again. Also, by using out of the box capabilities we have reduced the risks involved with migration to SharePoint 2010.


5 thoughts on “InfoPath over jQuery?

  1. This question becomes even more relevant with the advent of Apps in SharePoint 2013 … what to do with an app that is outside the infrastructure of SharePoint and therefore Forms Services? Is jQuery going to fill the gap?

    Great post! and further proof to test the OOB first and then prove it wrong with something else.

  2. Chris,
    Great case study. It would be awesome to see screenshots or even a live demo of this. These kind of customization question come up all the time, but sometimes you have to go down both routes like you did and compare to see which way works best.

  3. Hey, Chris. I would be interested to understand where you saw the performance issues. I don’t say that SPServices and jQuery is always the answer, but I am always interested to understand why it falls down as part of a solution toolkit.


    1. Mark,

      In this scenario it had more to do with the amount of data being gathered, returned and stored. It also fell back on browser issues (the client is still using IE7), so there were some quirks that caused the browser to be unresponsive.

      On the data side, we had a fairly large set of questions. Each question was retrieved and then corresponding answers were mapped back to the question. Ironically, this is the same project where I blogged about using asynchronous calls to improve jQuery performance, but in this scenario, it simply wasn’t enough to overcome the browser limitations.

      On the browser side, there were some odd quirks that we could not overcome with jQuery UI nested inside of SharePoint. We also had iterations where some of the testers for the solution would not have the events hook up properly so the survey would fail to work as designed. After wrestling with this for several days it was obvious that we just didn’t have enough resources internally to continue down the path of jQuery.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s