Four years later, PDF is not dead

Alan Pringle / Analysis11 Comments

gravestone with statue coming out of grave

This post is part of Scriptorium’s 20th anniversary celebration.

In 2013, I wrote that PDF is not dead. Four years later, it’s still too early to write the obituary.

Do PDF files work well on phones and tablets? Nope, but PDF files still have their uses (and even a fan base), so we can’t just stop providing them:

You can’t force your customers to happily rely on new output formats when you’ve supplied just PDF content for the past umpteen releases. This is particularly true if contracts or industry regulations specify how you provide content. If you have a legal requirement to offer PDF, print, or some other format, it doesn’t matter that your HTML pages are searchable or that the EPUB version works well on a tablet. The HTML and EPUB don’t fulfill your obligations.

gravestone with statue coming out of grave

Flickr: Adam

The distribution format really isn’t the point, is it? Business requirements and customer needs should dictate how companies distribute content. The PDF is an easy target because it’s been around a long time and doesn’t have the pizzazz of other formats.

Maybe we will have the same conversation about web pages in 20 years!

PS: There are many great comments in the original post. I have always appreciated the intelligent (and hilarious) commentary on our blog over the years.

About the Author

Alan Pringle

Twitter

Content strategy consulting. Publishing (electronic and print). Eating (preferably pastries and chocolate). COO at Scriptorium.

11 Comments on “Four years later, PDF is not dead”

  1. I believe you’re right: PDF will never die completely. Especially now that it’s an open standard.

    Now Flash, on the other hand: if Adobe hadn’t nailed it to the perch it’d be pushing up daisies.

  2. As I posted in response to the original post, one use case for PDFs is when regulations or compliance are important factors. But on the whole, organizations continue to use PDFs and live with the associated pain points (because we do not have an option).

    – PDFs are not interactive, and hence not persuasive enough. Particularly for sales and strategic channels, these lack CTA opportunities. And readers continue to read the content in a linear model (book model, and not web model).

    – Different assets listed in a PDF document are disjoint which means that a reference to an external video, to a white paper or case study, to an event, or to any external reference, remains outside the PDF. So, the combined power of all assets that can *convert* (marketing or sales) or *decide* (assurance, support content) are a disconnected experience… and that tells on conversions or on NPS (Net Promoter Score).

    – Content impact is short-lived. Many a business opportunities are lost or compromised because of the PDF-powered broken content experience. Sales or partnership talks continue to be in *no decision* mode. This study by CSO Insights (https://www.csoinsights.com/wp-content/uploads/sites/5/2016/08/2016-Sales-Performance-Optimization-Study-Key-Trends-Analysis.pdf) says that around 60% of the sales teams’ time is spent on NOT talking to the customers. And so a blow to sales teams’ ROI.

    And did I say that we do not have an option? It is 2017, and we have Relayto. See https://relayto.com/relayto/2016-milestones and write to me if PDF is a should-be-archived-pain for you. 🙂

  3. Since I’ve just railed against PDF on Twitter, I’ll add my thoughts here. PDFs for techcomm should die quickly.

    The only statistic that you get from PDFs is the number of downloads. Once the user has the file, you have no idea if they ever actually open it, You have no idea what they’re looking for, and if they actually found an answer. In a metric-driven world, management wants more than that.

    For users, search doesn’t return context, it only returns the keyword (if it’s even used).

    Plus, it’s so dang hard to get quality PDF output from DITA unless you’re an XSLT guru. Or you use InDesign, which opens up a whole workflow issue. It’s probably a lot easier to create a print stylesheet in CSS so your users can print as they need, and your team gets the benefit of usage statistics.

    Of course, the biggest problem is people not wanting to change. I don’t know how to fix that.

    1. “Of course, the biggest problem is people not wanting to change. I don’t know how to fix that.”

      Many of our clients have customers who request PDF output, so they still provide it to keep those customers happy. Also, some government agencies require PDF output for regulatory purposes. Hard to argue with regulations.

  4. If you have structured content that can be published in multiple formats and you can offer those multiple formats to users who may prefer one format over another, why not offer them? We received many customer requests for PDF when we supplied only webhelp content, so we now just provide both on our website. For us it is just one more build.

    1. We have clients who take a similar approach to yours, Nancy. For one client, the PDF is not the primary deliverable, but those customers who want a PDF can easily download it (and an EPUB version, too).

  5. @Ed Marsh, I can get beautiful PDFs out of Word with Acrobat Professional; been doing it for years.

    “For users, search doesn’t return context, it only returns the keyword (if it’s even used).”

    Search terms not used in the content isn’t a flaw of the output format… it’s sometimes a flaw in the content development, sometimes a case of the user not knowing what something is called so they try search terms that come to mind.

    I prefer to build a structured document in Word or Framemaker from which I can build a beautiful PDF (with automatically generated bookmarks from the document structure) and then link the source document to a HAT to create other formats… basically single-sourcing the low-end way (without having to spend enormous amounts of time and money on a DITA/XML solution).

  6. There’s nothing you can do if you’re in a regulated environment that requires PDFs, but for others, it’s up to you to find out the best format for your users.

    How do you respond to your users’ needs if the only information you have is that they downloaded your PDF?

    If you have content that is measurable, i.e. in HTML on a server, then you can get data from it – who’s using your content, what’s the best and least performing content, what are users searching for – and is it the same keywords you’re using?

    @Mike Starr – I use the data collected from our usage stats as well as support tickets to ensure our keywords are the ones our users use – not vice-versa.

    Creating PDFs is also a lot of additional overhead if you publish updates frequently, particularly in the non-Frame structured world. The last time I used Frame it required DTDs and a lot of extra files that created extra work. I hope it’s improved since then.

  7. It’s true. I’m pushing my team to get with the 1990s and think about HTML as the primary format–and organize and write for people reading that way. But I just got a new car, and while I like looking things up online when I get home, I usually need to figure stuff out when I’m in the car, and searching online will be somewhere along the spectrum from slow-and-small to no-bars-of-signal. Just let me download the darned PDF already, would you?

Leave a Reply

Your email address will not be published. Required fields are marked *