So, Robert Brogue has posted some comments on InfoPath, and Maurice Prather agrees but doesn’t want to sound like he’s going too far.
I actually think that Maurice didn’t go far enough in criticism of InfoPath, at least in a workflow context. And I have used it.
Customers like forms, and inevitably they want complicated ones, with ‘intelligence’ in them - calculated fields, validation that is dependent on multiple fields, fields that appear or vanish like something from Hogwarts - and really, it doesn’t take much of this to head beyond InfoPath’s 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, and to be mainly accessed through Internet Explorer. We ended up with a form that took a minute to render in IE (by my colleague, Bruce). Interesting, in InfoPath client it took about a second, and in Firefox about 5 seconds. I don’t know what was happening, but something was knocking the hell out of IE’s rendering engine. Bruce reckons it was the JavaScript rendering - he might well be right.
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.
Don’t even get me started on the workflow Modification Forms I tried to create.
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).
Not impressive for an application that is supposed to make forms easier. And why (oh God why) did they tie it to workflow so much? For anything more complicated than a trivial workflow, it isn’t adequate.
I guess there, maybe it’s an issue of people trying to push SharePoint workflow beyond it’s envelope - again, unsurprisingly. If you give people a hammer, they’ll try and hit nails with it - it’s no good to then say that it’s only any good for hammering soft cheese…
Comments from my old blog:
Given my own experiences with workflow development on client projects, I don’t think you’ve taken the hammer and nail analogy far enough.
If you give a customer a hammer and nails, they typically then want you to build the space shuttle with them.
