InfoPath Review
I was asked recently to check out the potential uses of InfoPath at our company, and was thankful I got the chance to do so last week. I learned about InfoPath by developing a working prototype form containing data populated directly from both SQL and a Web Service, and which passed its data to a web service to add a record in a SQL table.
InfoPath is a cool tool in that it packages up XML data nice and tidy with its own schema, allowing the developer to do practically anything with that data he or she needs to do. I am totally impressed with how InfoPath "thinks XML."
My issue is with the user experience. I thought InfoPath would be a wonderful transitioning experience for my users as we move from web-based apps to rich-client winform apps in the months ahead. I read much about the "rich InfoPath experience" and wanted to see it in action.
But I quickly discovered that InfoPath is NOT a rich user experience. InfoPath forms are web-forms masquerading as rich client forms. They are even more stupid than web forms because you do not have managed code to rely on for flexible validation and user prompting. And if you don't enter all required fields (those are the ones that InfoPath puts the ugly red lines under them), when you click submit the only message users receive is: "the form cannot be submitted because it contains errors." You can change the submit response message, of course, but options are few. As for individual field validation support, there are really good support dialogs to set these up. That is, if you want to check for anything OTHER than a blank field. Nothing I did in the validation support dialogs to prompt the user on tabbing or clicking past a required blank field had any effect.
Forget about simple tasks like selecting a default value in a dropdown list. Neither VBScript nor JScript has a ddlist.FindByValue("1").Selected = true; statement :-). And that's the rub. Anything you might want to do code-wise must be done in VBScript or JScript. Oooo, now that makes for a rich user experience!
I also made the mistake of trying to replicate an application of sorts with the InfoPath prototype form. In doing so I was able to add an Office Toolbar to InfoPath (by manually typing it into the manifest.xsf file under the appropriate "view" schema area), which was actually pretty cool. This toolbar button displayed a secondary form (defined in InfoPath as a "view.") But then I went to my secondary form and added a "Submit" button. D'oh! Only one submit button per InfoPath form! And those fields you added on the secondary form? They're part of a single DOM XML file passed to your web service or URL on submit. Not exactly the behavior you might expect in a normal application consisting of “multiple forms.“
A week is not long enough to evaluate the full potential of InfoPath, certainly, but I think it was enough time for me to conclude that I cannot recommend our company prioritizes using InfoPath over current web and Office-based services. My main arguments against using InfoPath is that it is not a rich UI as claimed and its architecture (from a .NET developer's perspective) is waaay lacking. And while InfoPath is marketed as a tool that any administrative assistant can use to crank out forms and move XML throughout the enterprise, that is not a realistic appraisal of its use at all. An administrative assistant may very well design the form, but a developer will be required to spend precious development time adding the hooks to move the data in and the code to move the data out of Office InfoPath forms, confirming the data types, specifying field names, and so on.
Or maybe I just didn't "get it." Hopefully I'll get some good input from developers who DO get InfoPath.