Explore generating pdfs of form output

[annekainicUSDS]

Explore the lift involved in generating pdfs of the form output. This could be a useful feature for 2 reasons:

1. Some teams may not have a back-end API to automatically accept form submissions. If we can still enable users to fill out the form online, print it out, and send it in, we're at least making the form completion process easier and more reliable (catching validation errors and making sure required fields are present) and incrementally upgrading their system.

2. Some users completing forms may want to print a copy of their submitted information for record-keeping (I've heard this request before from some Vets.gov users). This would enable them to easily save their submission.

Haven't investigated this library, but look into this more: https://github.com/diegomura/react-pdf.

[dmethvin-gov]

As long as we don't need to preserve the format of the original form this seems pretty doable. In fact, I wonder if we really need to go through PDF to get this. The main reason for going PDF would seem to be if we had to stuff the web form data into a predesigned looks-like-paper form. From a quick take it doesn't seem like that library can fill existing forms, it's more for creating one from scratch.

Would it be possible to render all the pages inside the browser using a different stylesheet? Basically, the review page with all the sections expanded. We do have page-break-before/after/inside in CSS so at least a bit of control on things.

[annekainicUSDS]

Yes, agree that this would be pretty simple if we don't need to preserve the format of the original form (maybe this is something we can get more information on from @bernars-usa's investigation into form owners and what formats forms can be submitted to them for manual processing).

[jcmeloni-usds]

I have more to say on this but can anyone confirm or deny that https://github.com/pdffillerjs/pdffiller is still a thing that people use? I used it a couple years ago with success but it doesn't appear to have been maintained. The thought being that given a fillable PDF template, map JSON to fillable fields and generate the PDF to download -- which is what Vets.gov does in some instances (I believe that's still true) through the rails-based shim layer (via pdf-fill gem or somesuch).

[dmethvin-gov]

If vets.gov handles PDFs via server side that makes sense, although that would put it outside the scope of a client-side library like us-forms-system. We could create a PoC on some test server that takes a JSON post plus a form specifier and returns a downloadable filled-out PDF, but actual production usage would depend on the server being used and the back-end language.

[jcmeloni-usds]

Here are my longer comments, based on existing use cases (heads up @ju-liem)...

• For teams without a backend API to accept form submissions, @annekainicUSDS is absolutely correct that having a better front-end experience that only leads users to download a form they've filled out and then send it somewhere is still a value-add because of validation errors that could be caught -- but also because filling out a PDF in a browser on a desktop let alone on mobile is still a sucky experience and getting one step past that is still one important step.

• Teams without a backend API to accept form submissions might also not have ATO/privacy/system of record documents or processes in place at all yet -- those can take a very long time, and providing a means to fill a PDF in which data is not persisted (and in many cases not authenticated) in an electronic way is still useful to the user while also giving the teams time to have their program offices get all that together. In fact, it may be the success of the form to PDF process that kickstarts the streamlining of the process to accommodate full electronic end-to-end work.

• Anne is also right about providing a filled-out copy for personal record-keeping, which is especially true in the unauthenticated interactions, since "personally" would be the only way a user could save their data.

• Dave's comments and an ongoing eye toward what is the responsibilty of a f/e library vs an app vs a backend system are also important -- we don't want to feature creep the library, but we do want to nod toward being useful.

• Also remember that in some magical future world of unicorns, puppies, rainbows, kittens, and the like, this library could form the foundation of an actual service in the govt that could churn out filled PDFs, being one step closer to a fully automated set of systems, and negating the spend for something like an Adobe platform.

I think it's super important to draw clear boundaries around library vs implementation, but I'm not even sure where that line should be in this case. My gut leans this way:

• the library produces a form UI. The default action of the form 'submit' is to produce JSON and then if a flag is true, dumps it to the console.
• the starter app uses the library to produce a form UI, with the default dump JSON still in effect, but adds possible output examples: use fillable PDF template and map JSON to fields and offer for download, transform JSON to XML and SOAP (because you know some govt agency is going to need it), maybe a third that makes sense and is low-lift.

Why? Because while the ideal future is development teams use library and implement it into their flow (e.g. vets.gov and its Rails app and API layer for form data handling), the reality is that a lot of agency first steps are going to be rolling up standalone React apps and having something meaningful happen on form submit is important....and should get them there.

[jcmeloni-usds]

I'm leaving this open, but during your planning for Phase 2, please take my comment into consideration (#226 (comment)) and then when you figure out what you're going to do, close this and open a new ticket.

[dmethvin-gov]

Duplicate of #21, the specifics all depend on specific user needs and we don't know those until there is a specific user.