CMb 2009–10
What intranet content should be in PDF format?
Categorised under: articles, intranets
The typical corporate intranet will consist of a mix of HTML-based web pages and a variety of PDF-based content available for download. PDFs can be derived from word processing documents, a document management system and/or similar software. It’s not uncommon for an intranet to house thousands of PDFs alongside its standard web pages.
So what’s the difference between PDF and HTML, and when should each format be used?
PDFs versus HTML
The ‘Portable Document Format’ (PDF) was primarily designed to present documents in an easily readable, easily printed and common digital document format that will display as its creator intended (no matter which computer it’s opened with). This hasn’t changed and PDFs remain fantastic for displaying detailed and in-depth information that’s difficult to digest on screen, as manuals and policies, for example.
Alternatively, as an easily interpreted, scaled, read and copied from format, HTML web pages are the standard for web browser-based content. HTML loads quickly, is searchable, can be updated quickly and easily and adapts to a computer’s screen size and resolution.
These different characteristics mark the overall difference between the two formats: HTML is designed to be read on screen, while PDFS are really designed to be printed out.
Evaluating PDF use
The pros of PDFs include:
- traditionally suitable format for documents and forms
- easily printed
- easily downloaded and stored
- easily shared (via email, or stored on a network drive)
And the cons:
- requires a PDF reader to read
- requires a PDF creator to produce
- time-consuming to update
- can be unwieldy to open and navigate in a browser if incorrectly produced
- can be slow to find what you’re looking for within a PDF
- poor copy and paste results to other formats (email, word documents etc)
Use a PDF when:
- uploading a policy, manual, report, document or similar that’s finalised before digital distribution
- the information contained within the PDF will not be changing regularly
- a document is designed to be distributed before being printed on an individual basis (e.g. an internal newsletter)
Use an HTML page when:
- information on a page will change regularly
- the information contains hyperlinks to other online content
- the content is unlikely to need printing
Also don’t forget that most modern content management systems offer ‘print page’ functionality, just in case a user needs to see the page in hard copy. This is a far more fluid and practical system than creating PDFs solely for the purpose of printing web-based information.
PDFs for forms
One of the most popular uses for PDFs in organisations is for forms. Yet, a modern intranet should be moving away from using PDFs for this purpose, and instead using fully-developed online forms (because intranets should be places for doing things, not just finding and downloading material to be printed).
In one organisation recently, with 14,000 employees, transferring just the ‘Room/Venue booking’ form from a PDF to an actual online form saved over 40,000 emails a year in support and administration — just for one process.
Progressively transferring all PDF forms to online forms is a sound improvement, and many organisations have made the transition successfully.
Alex Manchester is a senior member of the consulting team. He has a specific focus on intranets, internal communications and social media. He has worked with a range of public and private organisations in these areas. 
9 Comments:
Essentially, your list authorizes the use of PDF for any document that isn’t going to be changed, which would include essentially every blog post in the world. This is hardly a well-considered option.
The WCAG Samurai list of acceptable PDF file types is the correct one.
Hi Joe,
That is a good list, with some good points and several similar to the above ( (I note that you created the WCAG Samurai list). Your point about blog posts is a little strange as they’re rarely (if ever?) made into PDFs – they’re designed and created to be read on screen.
This article is less about “authorizing” and more about offering reference points when publishing content [to the intranet].
Alex,
Can I respectfully disagree? Here’s my take on the ‘cons’ –
‘Requires a PDF reader to read’ – every company I’ve worked for in the last 8 years has had Adobe Reader loaded as standard on all company PCs. So what’s the problem?
‘Requires a PDF creator to produce’ – Again so what? PDF programmes are relatively cheap and limiting them to certain personnel means that everything will get a look over before publishing which is no bad thing
‘Time-consuming to update’ – It isn’t. In fact its usually far quicker than HTML. I’ve received a request to update a large document where the content owner has sent me a Word document and I’ve checked it, turned it into PDF and uploaded it in less than 15 minutes. Try that with HTML when you have pagination and graphics issues.
‘Can be unwieldy to open and navigate in a browser if incorrectly produced’ – then produce it correctly
‘Can be slow to find what you’re looking for within a PDF’ – Not if internal navigation is done properly plus Adobe allows you to search within a PDF anyway
‘Poor copy and paste results to other formats (email, word documents etc)’- Never noticed this but however the work flow is Word into PDF and not the other way around
Just my 2c worth. I’ve posted on PDFs here
http://patrickcwalsh.wordpress.com/2008/11/29/simplify-your-intranet-by-using-pdfs-but-dont-make-documents-searchable/
Patrick
Hi Patrick,
Appreciate your points and the opportunity to put some more shape around this article.
I reiterate that I think PDFs are still fantastic for certain uses. Static, standalone policies, graphic-heavy reports, documents etc. remain PDF worthy. For sure. PDFs still have their place. And as your article describes well, if they – along with the rest of your content – are organised and managed correctly, then they are very useful for lots of things. I’m not disputing that.
What I am saying is the type of content and its format should really be considered beforehand. Using PDFs as a default is not right, and neither is using HTML all the time.
Drawing from our experience, I’m also coming at this from the perspective that intranet managers should be aiming, wherever possible, to simplify processes and speed up access to information on the intranet.
That means being able to locate a page or a summary page, and read he information immediately – without downloading anything or opening up a separate PDF reader or similar application.
This perspective is also borne out of countless tales of user frustration with their corporate intranet and the glut of information on it (much of which is out of date and dead – and in PDF format); where computer software is a hideously slow and unreliable desktop virtualization environment that crashes or freezes intermittently if you try to open more than a browser and email app at one time.
Users also hate the experience of downloading half a dozen PDFs before finding the correct one – especially if they’re looking for a one paragraph PDF that really should be just an HTML page.
I agree with the underlying point in your counter arguments: that PDFs should just be produced correctly, that the right software be in place, that content be managed and owned so well that all updating a document requires is the original author send you it and you correct and republish.
But that’s a very smooth, well-oiled intranet, IT infrastructure and publishing system.
Instead, you often have original authors that have left or moved and the original Word document is nowhere to be found. You have a situation where content is already duplicated in several different places… It’s not always straightforward
Even then, when all said and done, you’re still asking users to download, check and read information in a format that’s not primarily intended for displaying on screen.
Hi Alex,
Interesting post and comment thread.
Overuse of PDFs is certainly an issue with our intranet – unnecessary clicking, unnecessary delay as another application launches, and unnecessary mental gymnastics as staff have to shift from IE-mode to Acrobat-mode. (And don’t try to tell me that embedding the Acrobat toolbar in IE removes that.) And these are in addition to the ‘cons’ you’ve raised.
Our future is to use HTML (via a simple publishing mechanism) as the default and PDFs will be the exception. But there’s a mountain of habit to conquer before we realise that dream.
Thanks for the article.
Andrew.
No one seems to have commented on the most obvious reason to have HTML as the default over and above pdf’s – accessibilty. apart from being a legal requirement in most countries, it actually makes your page more usable.
Let’s move away from the lazy option of pdf and make more effort to get things right.
[...] Lees het artikel hier: What intranet content should be in PDF format? [...]
Good post. Detailed & understandable.
and I recommand a PDF converter name Tweak PDF -Focus on PDF converter solutions
So when everyone agree that, yes, a PDF should be linked to on this occasion – do you stick to the usability rule of setting new content page to open in the existing window, or should it open in a new window?
7 Trackbacks
[...] Read the whole article [...]
[...] What intranet content should be in PDF format? [...]
[...] Lees het artikel hier: What intranet content should be in PDF format? [...]
[...] – Quando usare i PDF e quando i form in una intranet. Un bell’articolo che spiega come impostare un uso sostenibile dei (tanti) PDF che affollano le nostre intranet. [...]
[...] Alex Manchester from Step Two (Intranet Design) provides clear guidance on when to use PDFs. [...]
[...] What Intranet Content Should be in PDF Format? – Alex Manchester New! Up to Page Index [...]
[...] Manchester, from Step Two Designs has a very useful article on when to publish Intranet content in PDF format rather than HTML. I [...]