Back in 2009, I ran a project to convert a bunch of paper forms into InfoPath for online forms. After a few months we gave up on InfoPath:
- We still had to have paper forms for legally required forms in case someone didn’t have a computer, etc. so then we needed a regular printable PDF. InfoPath native forms had issues with printing.
- The InfoPath-PDF integration was not very good and not usable for my production.
- The data on the other end went into bizarre formats and thus needed a job to convert it to the format we needed (and take action).
In the end this solution was deployed, and shockingly is still online and in production in 15 years later:
- A graphic designer (often an intern) took the original paper forms or fillable PDFs and made basic HTML forms with them.
- jQuery used for user friendly form validation.
- These forms were integrated with an SSO to allow e-signing.
- “Print” and “Submit” buttons on the form invoked a Perl script which (1) transformed the HTML form to having the content filled in, (2) ran headless Firefox and print-to-PDF to archive the form for legal purposes, (3) stored the form values in the native database, and (4) fired off a stored procedure based on the form name.
In effect, the same things InfoPath was supposed to do, but it didn’t need a dedicated administrator or complex integrations.
Oh my goodness, what a blast from the past! Didn't you have to define forms using XML and XSLT? If I recall right, you had to host it either in SharePoint or InfoPath forms server.
Don't get me wrong, it was an amazing tool for its day, but had some steep and proprietary onramps that limited adoption. I'm personally not at all surprised that it faded from general consciousness.
You (usually) built forms using the graphical form editor, and they could be packaged as an executable desktop application that emailed you results back. If you wanted them to be in a browser they had to be on SharePoint, of course, because it's the usual Microsoft lock-in thing.
It was surprisingly good at letting non-computer-people build data gathering applications though.
Did InfoPath have any other workflow/automation/integration things available besides BizTalk (which is the one thing I saw InfoPath with)? Because if not, then it's no surprise that it didn't catch on.
I remember it inserting rows straight into an Access or arbitrary-SQL database, and the integrations running from there. It was a data collection tool.
- We still had to have paper forms for legally required forms in case someone didn’t have a computer, etc. so then we needed a regular printable PDF. InfoPath native forms had issues with printing.
- The InfoPath-PDF integration was not very good and not usable for my production.
- The data on the other end went into bizarre formats and thus needed a job to convert it to the format we needed (and take action).
In the end this solution was deployed, and shockingly is still online and in production in 15 years later:
- A graphic designer (often an intern) took the original paper forms or fillable PDFs and made basic HTML forms with them.
- jQuery used for user friendly form validation.
- These forms were integrated with an SSO to allow e-signing.
- “Print” and “Submit” buttons on the form invoked a Perl script which (1) transformed the HTML form to having the content filled in, (2) ran headless Firefox and print-to-PDF to archive the form for legal purposes, (3) stored the form values in the native database, and (4) fired off a stored procedure based on the form name.
In effect, the same things InfoPath was supposed to do, but it didn’t need a dedicated administrator or complex integrations.