Logo SharePoint Thoughts   Downloads   About   Up to Bluedog Limited
A follow up to my InfoPath post
Posted on 7/12/2007 1:16 PM by Maurice Prather
I've received a few emails and comments about my last post.  Some folks said that I was perhaps being unfair and wondered if I had in fact ever used InfoPath.  In light of those inquiries, I think it's worth posting a general reply...
 
 
In reviewing my post, I realize that I might have come across a bit stronger than I had intended.  Although I stated "I've yet to work on a project that includes utilizing InfoPath", that does not mean I have never used InfoPath. That's quite the opposite. I should have been more explicit and perhaps said that I've never worked on a project where InfoPath survived the design phase and was part of the final implementation.  I have used InfoPath on many occasions (as a product team member and as a consultant).  I've been called in to fix/understand problems - from really simple mistakes to mysterious form crashes - as well as help design new projects.  I have literally spent days on issues trying to determine why it won't work and how to work around it....

InfoPath works well for most scenarios.  The problem that I find is that once you start wandering outside the normal path, you will encounter a variety of issues.  A lot of folks really want to push the envelope.  This is the crux of the problems outlined by Rob.  It's not to say that you can't build really cool applications with InfoPath.  However, the development pain can be excruciating.

Do I boycott InfoPath?  No.  There is only 1 feature in WSS/MOSS that I will not touch.  I'll post more on that subject later this week. 

Do I prefer to not use InfoPath?  Yes.  Nonetheless, I will do my best to understand the scenario and determine whether or not the technology is required for the project (this obviously implies being involved in the design phase and not simply being called into to add/modify/fix something).  I then examine ways on how to accomplish the same tasks without using InfoPath.  A lot of effort is spent trying to determine if in fact InfoPath is the right solution.  More times than not, the problems which are systematic of InfoPath force a rethink on the desired solution.  Simple design changes will often times lessen the dependency. 

It's all a matter of understanding the technology, the obstacles ahead, and the amount of time to achieve your final goal. 
re: A follow up to my InfoPath post
Hi Maurice,
 
We need two solid sharepoint developers.  Do you have any ideas on where to access these individuals?
 
 
amanda garrett @ 7/16/2007 6:16 AM
re: A follow up to my InfoPath post
Amanda,
 
There are quite a few consulting companies with InfoPath experience who can help you.  ShareSquared and Dimension-SI are two companies that immediately come to mind...  I work for the former (you can find links on my site for more information) and I know the owner of the latter. 
 
-Maurice
 
Maurice Prather @ 7/17/2007 10:41 AM
re: A follow up to my InfoPath post
I actually think that you didn't got far enough in criticism of InfoPath. And I have used it.
 
You hit the nail on the head with "folks really want to push the envelope". We hit that with a customer - the form they wanted to build was fairly complex. Not to the point where it would have been impossible in competing products, or even (God forbid) to code as an ASPX page - but more complex than we've seen InfoPath used for before. Oh, and this was to be used in SharePoint. We ended up with a form that took a minute to render in IE. Interesting, in InfoPath client it took about a second, and in Firefox about 5.
 
I also tried using InfoPath forms in SharePoint Workflow - what a disaster. We had all sorts of problems - repeating fields that returned empty of data, not being able to populate said repeating fields. Setting up an InfoPath form for workflow also seems to involve an arcane process, and Lord help you if you fail to notice that Secondary Data Source -which has to be called ItemMetaData.xml - has incorrect capitalisation.
 
In the end, the workflow forms stuff was so bad we abandoned using workflow entirely. (I know, I suggested just using ASPX forms, but they didn't want to go that route)
Andy Burns @ 7/26/2007 4:49 AM
Tools
As an architect one has to understand where InfoPath’s place is the SharePoint technology umbrella. Remember the InfoPath is targeted to technical business users to author data collection forms.
steven-fowler.com @ 8/16/2007 6:16 PM
re: A follow up to my InfoPath post
Agree 100% with the last comment.  You really have to understand where InfoPath fits in.  I'm an InfoPath convert myself.  When I first was introduced to it, I thought "why the heck would I use Infopath when I know how to create custom web parts using user controls?"
 
The answer is who is maintaining / creating the forms.  If I create a form using .NET user controls / web parts, a business user isn't going to be able to maintain it and make updates.  If my requirements are within the bounds of what InfoPath is capable of it's absolutely the right choice.
 
I've had one client who said InfoPath would save them hundreds of thousands of dollars in increased effeciency just by making the forms electronic and allowing them to maintain it .  They would never have been able to afford a completely custom system.
 
That said, I 100% agree with Rob's post as well.  Some very solid points (as usual, from the guy I learned SharePoint from :) ).  There are a number of things that could be done to make the product better.  That doesn't mean you should completely avoid it though.
Jason Ruthkoski @ 9/23/2009 12:22 PM
RSS feed
Microsoft Certified Master
MVP Logo
Follow me on Twitter!
Keyword Search
 
View by category
 

Disclaimer:
The contents of this site represent thoughts and opinions of the authors , not those of anyone else - such as past, present and future employers.  This a forum of the exchange of ideas centered on SharePoint technologies.  It is not a support channel.  :)

Copyright © 2004-2010 Maurice Prather, Inc. All rights reserved.