28

I work for a company that has hundreds of forms in fillable PDF format on our website. We run into issues constantly because web browsers love to open PDFs in browser instead of opening the files in the native Adobe Reader application.

Users download the form and their browser opens the file in a new tab. They end up filling out the form in the browser and then try to use the JavaScript submit button at the bottom which does nothing because browser block JS activity in PDFs. If they haven't given up by this point, they'll save the file to their desktop but the forms don't save what was filled out in the browser and they become even angrier.

What is standard practice for this sort of thing? Normally, I recommend replacing fillable PDFs with regular web forms but a good number of these forms are longer, there are a ton of them, and most of them are updated quite often making web forms less than ideal.

I've looked at DocuSign-like products which I've never used before but appear on the surface to be better equipped to manage form distribution and collection but I'm unsure if this is best practice (especially considering the paywall on some of the bigger name products) or if there's a solution I haven't thought of.

TheIronCheek
  • 411
  • 4
  • 9

8 Answers8

18

Normally, I recommend replacing fillable PDFs with regular web forms

I think overall, yes, that would be the ideal solution, but you noted some of the the issues with this, which includes how to handle all the existing content already made.

We run into issues constantly because web browsers love to open PDFs in browser instead of opening the files in the native Adobe Reader application.

By allowing the browser to handle the PDF file, you are leaving it to each users individual browser settings (e.g. open PDF in browser, or download). You have no control this way.

What is standard practice for this sort of thing?

You need to take control of the entire viewing experience, by adding a PDF viewer that supports PDF form filling, and load the PDF in your viewer. This way you know exactly what the user is doing, and control the entire user experience, and you can test your corpus of files for testing against this particular viewer since you host it.

John Conde
  • 86,484
  • 28
  • 150
  • 244
Ryan
  • 339
  • 2
  • 6
10

You could try to force downloading of the PDF, so that it opens in the default application for viewing PDF files instead of the browser.

See this question: How do I force files to open in the browser instead of downloading (PDF)?

Paul
  • 209
  • 1
  • 3
5

There is no standard practise. You'll have to re-think your process:

Why do your customers have to fill out PDFs in the first place?

Do you just need structured data from the customer? Who needs the PDF later, a government agency? Do you have to provide the customer with the same PDF? Can your company create web forms instead of PDFs? Can you auto-generate the PDFs yourself? Does the customer need to see the PDF exactly as is when filling it?

At our company, this PDF-filling is part of our core business domain, so we have an in-house solution. If it is not crucial to your business, you could buy this PDF-to-web form bridge from DocuSign, HelloWorks et al.

The quick-and-easy way is to force PDF download and demand that your customers use Adobe Reader.

Edit/PS: As PDFs are two-dimensional landscapes, they can be hard to navigate on mobile devices. Zoomed out, you're able to see everything but can read nothing, or vice versa when zoomed in. You have to consider how many users are on mobile devices. The more mobile devices among your customers, the better a web-optimized solution that features real forms. After filling the form, you could present the user with the automatically generated PDF.

knallfrosch
  • 159
  • 3
2

Even if you force users to download a PDF instead of opening it directly, you have no control over what program they use to open it (for security reasons).

Others have mentioned DocuSign (or similar), which have great tooling for not only signing but access control and 3rd-party verification. For most people, this is a good way to go. However the pricing may be prohibitive for certain businesses / use cases.

I recently built a custom signing tool for a large client, who also needed to accommodate a large number of ever-changing documents and save the completed and signed PDFs. As far as I can tell, it's similar to what DocuSign is doing (though not nearly as sophisticated)

The workflow is as follows:

  1. A manager/customer creates the document with signature fields, and uploads it in the application
  2. The application registers the doc for use, and extracts information about the fields to be completed
  3. The end user is shown a web form generated automatically from the metadata.
    • The form shows a background image of the original document
    • The input fields are positioned over their correct spot in the image so it looks like the user is typing directly on the document
  4. The user fills out the form and physically signs a signature section (on a tablet or with a mouse)
  5. The completed form data and signature image are sent back to the server
  6. The application fills in the original file with the data, and generates a PDF
  7. The final PDF and all the form entries (but not the signature!) are saved to the database, allowing admins to search within all completed forms and remove them if ever needed (e.g. HIPPA / GDPR compliance)

However for most businesses, especially those without developers and IT already on staff, building and maintaining a custom app like this isn't viable or cost effective. Between the development, security, and liability, it's generally cheaper (and a better user experience!) to just go with an existing service.

brichins
  • 121
  • 4
1

I worked on a project many years ago which used downloadable Word documents with form fields and editing protection which disallowed changing anything except the contents of the form fields. If your users will have Word (or maybe LibreOffice – you could do tests to see what the compatibility is like nowadays) then this might be an alternative. I've not seen any browsers which attempt to open Word documents.

Peter Taylor
  • 1,062
  • 7
  • 13
1

Might be a bit late to this one but having experienced this myself I would genuinely just start moving to Web Forms for this. Others have listed out the major reasons above but to be honest, my opinion on situations like these is:

If there are 2 perfectly usable options where one is open-source and the other is proprietary (e.g. HTML Vs PDF) then go with the Open Source version. Cost will be a winner in the long term, and there's little chance of a feature getting locked down by the vendor behind a paywall or price increase.

In theory Adobe could always pull Form Filling from the standard Adobe Reader in an effort to force people to pay for something like Docusign/Echosign. Doubtful but possible, and then you'll end up having to convert them all anyway.

An advantage to going with a web form for this is the extended functionality and data validation you can perform. Also, if you need to use a pdf further down the line for something internal, you can always use a library to generate a PDF from the web form, the other way round is not as easy.

I would begin with monitoring the GET requests for the forms to identify those that get used the most, and begin converting the most used to the least over time.

DAustin
  • 111
  • 1
0

Are you able to modify the files at all?

There are some systems that (ab)use the fact that every pdf reader renders differently to detect what PDF reader you are using.

I know I have seen PDFs created before, which if not opened in adobe reader, only display a page asking the user to download the correct software.

Google's currently failing me, but I assume there's some setting you could flip in acrobat in order to make a PDF that would require the user to download adobe's SW.

Stack Tracer
  • 101
  • 2
0

Users download the form and their browser opens the file in a new tab. They end up filling out the form in the browser and then try to use the JavaScript submit button at the bottom which does nothing because browser block JS activity in PDFs. If they haven't given up by this point, they'll save the file to their desktop but the forms don't save what was filled out in the browser and they become even angrier.

This makes me think that there isn't any sort of indicator that users should download and use Adobe Reader, or an alternative program (E.g.: SumatraPDF).

However, there is a way! How about some changes to make the PDF gracefully degrade?
Instead of the button being always present, use JavaScript to add the button.
Alternativelly, a better option would be to replace the contents of a "box" with the button. The "box" could have a warning to save the file or use the "Print to PDF" option on Windows 10 or the browser itself.

Using an actual example, taken from: http://foersom.com/net/HowTo/data/OoPdfFormExample.pdf

Using Google Chrome, you can print the PDF (and if you pick to "Save as PDF", you can send it): Google Chrome - Save as PDF

You can see that the form is filled with random "junk", but filled. It can't be edited later, but it is filled.

In the case of Firefox, it gives a proper warning: Firefox warning (Roughly translated: This PDF document contains forms. Field filling is not supported. - Open with other viewer).

In short: consider graceful degradation and proper warnings/instructions in the webpage and PDF itself.

Ismael Miguel
  • 101
  • 2