4 ms·

> Being able to automate forms can absolutely revolutionize some businesses I once worked for an insurance brokerage whose in-house CRM had started years befor

> Being able to automate forms can absolutely revolutionize some businesses I once worked for an insurance brokerage whose in-house CRM had started years before as an effort to automate paper-based forms. The company's business model was based on having their sales advisers fill out insurance policy application forms on their customers' behalf and originally this had been done using pen-and paper, which was obviously time-consuming and laborious. At some point, someone in the IT department had had the idea of scanning the application forms to image files and writing a simple PHP application to insert those images onto web pages with HTML <input> tags superimposed over the form fields, thus allowing advisers to fill in the forms using keyboard entry. They quickly realised that once forms are filled in digitally, (a) you can store the form data into the database and retrieve it later for further editing, (b) some of the data can be filled in automatically from the customer's records and (c) when generating quotes across multiple insurance providers, the common parts of each insurer's form can be filled in from data previously entered elsewhere. While the idea of superimposing HTML input fields over a scanned paper form isn't one I've encountered before or since, that company was turning over $3M per month by the time I joined, so there is clearly mileage in the idea. Incidentally, it turns out that basing your entry forms around scanned paper forms completely kills dead any of the interminable bikeshedding that takes place around UX design with complicated, multi-section forms.

phonon 7y ago
https://www.codeproject.com/Articles/466362/Blend-PDF-with-HTML5 https://www.codeproject.com/Articles/466362/Blend-PDF-with-H...
cr0sh 7y ago
> While the idea of superimposing HTML input fields over a scanned paper form isn't one I've encountered before or since, that company was turning over $3M per month by the time I joined, so there is clearly mileage in the idea. You can also do this with PDF files, if you have Acrobat (or at least, it was possible - last time I played with it was several years ago - 2009-ish). You've probably seen "editable" PDF files - where there are fields you can type stuff into - much like a paper document that you'd put in a typewriter to "fill out". Well, it's actually possible (in Acrobat) to set up a "form submit" (virtually identical - IIRC, it was an actual HTTPS POST message) that you could point to a web endpoint. Add a button to the bottom of the page to submit the form, and it could also capture and handle errors (like if the service to receive the POST is offline, or has an error, etc). I forget was Adobe called it - but it worked rather well. I worked for a web app company who was contracted by a doctor's group to redo their website, and part of that was automating the forms. They wanted some way that a patient could download and use their standard PDF forms, to both enter and upload the information, or print it and fill it out manually and return it, if they were more comfortable with that. They didn't want an standard web form, or anything like you mentioned - because they might change the PDF for manual copies. Instead, we supplied them a template and taught them how to use it (and not to change particular parts - the parts handling submitting/errors and such) - so they could continue to use it. The backend was a PHP/MySQL system, everything was HTTPS, and IIRC we encrypted the data on the backend. I'm not certain that it was completely HIPAA compliant, but it was certainly as compliant as "form filled out with pen and filed in folder). So yeah - there's clearly a market for this kind of thing...
- rad_gruchalski 7y ago
  > I forget was Adobe called it - but it worked rather well. Livecycle Designer?
bob1029 7y ago
HTML is an amazing approach for fully-generated forms. But, for filling pre-existing forms, the mapping from HTML down to fixed layout on an existing document can cause lots of headache when it comes to getting really precise positioning of elements within dense forms. We built an internal tool that effectively converts any business form into a PNG @ 300DPI, and then defines a fixed element layout on top. This allows for pixel-perfect positioning of elements you'd like to fill on top of literally anything you can get into a PNG. Each definition is effectively just a JSON model specifying where everything lives, and then it is fed into some C# System.Drawing routines to fill the template image with expected data. The output is then converted back into whatever format is most ideal for downstream delivery (i.e. merge PNGs back into pages in a combined PDF). The downside of this approach is that rasterization of PDFs or other upstream forms items effectively strips them of any textual data that you could mine out of the document. So, there are certain use cases where this would be a bad approach. For most businesses, I don't think this is usually a concern, especially if you already have the data you used to fill the document in a good structure somewhere for alternate delivery approaches.

phonon 7y ago

https://www.codeproject.com/Articles/466362/Blend-PDF-with-HTML5 https://www.codeproject.com/Articles/466362/Blend-PDF-with-H...

cr0sh 7y ago

> While the idea of superimposing HTML input fields over a scanned paper form isn't one I've encountered before or since, that company was turning over $3M per month by the time I joined, so there is clearly mileage in the idea. You can also do this with PDF files, if you have Acrobat (or at least, it was possible - last time I played with it was several years ago - 2009-ish). You've probably seen "editable" PDF files - where there are fields you can type stuff into - much like a paper document that you'd put in a typewriter to "fill out". Well, it's actually possible (in Acrobat) to set up a "form submit" (virtually identical - IIRC, it was an actual HTTPS POST message) that you could point to a web endpoint. Add a button to the bottom of the page to submit the form, and it could also capture and handle errors (like if the service to receive the POST is offline, or has an error, etc). I forget was Adobe called it - but it worked rather well. I worked for a web app company who was contracted by a doctor's group to redo their website, and part of that was automating the forms. They wanted some way that a patient could download and use their standard PDF forms, to both enter and upload the information, or print it and fill it out manually and return it, if they were more comfortable with that. They didn't want an standard web form, or anything like you mentioned - because they might change the PDF for manual copies. Instead, we supplied them a template and taught them how to use it (and not to change particular parts - the parts handling submitting/errors and such) - so they could continue to use it. The backend was a PHP/MySQL system, everything was HTTPS, and IIRC we encrypted the data on the backend. I'm not certain that it was completely HIPAA compliant, but it was certainly as compliant as "form filled out with pen and filed in folder). So yeah - there's clearly a market for this kind of thing...

rad_gruchalski 7y ago
> I forget was Adobe called it - but it worked rather well. Livecycle Designer?

bob1029 7y ago

HTML is an amazing approach for fully-generated forms. But, for filling pre-existing forms, the mapping from HTML down to fixed layout on an existing document can cause lots of headache when it comes to getting really precise positioning of elements within dense forms. We built an internal tool that effectively converts any business form into a PNG @ 300DPI, and then defines a fixed element layout on top. This allows for pixel-perfect positioning of elements you'd like to fill on top of literally anything you can get into a PNG. Each definition is effectively just a JSON model specifying where everything lives, and then it is fed into some C# System.Drawing routines to fill the template image with expected data. The output is then converted back into whatever format is most ideal for downstream delivery (i.e. merge PNGs back into pages in a combined PDF). The downside of this approach is that rasterization of PDFs or other upstream forms items effectively strips them of any textual data that you could mine out of the document. So, there are certain use cases where this would be a bad approach. For most businesses, I don't think this is usually a concern, especially if you already have the data you used to fill the document in a good structure somewhere for alternate delivery approaches.