I work at a research organization and we publish a lot of large-ish documents, usually organized in sections. What I want to know is how best to present these multi-section documents on our website.

Presently, what I do is load the entire document as a single page, with each section as its own div. Then I show and hide divs as needed via a table of contents and "next" and "prev" buttons.

The advantages to this are mainly: 1) that you can move between sections very quickly, 2) it produces consistent analytics (when a page is loaded, I know a report is being read).

The disadvantages, however, are real:

  • Readers can't take advantage of browser back/forward buttons to move between sections.
  • It's complicated to create direct links to individual sections (I can do it with javascript but it's not easy for other people to grab and share).
  • For long reports, you have to wait for the full report to load before you can move around (and that can include hordes of images and charts).

Do other people have thoughts on better ways to organize this? Here's an example of the current system: http://massbudget.org/825

  • 1
    Best practice is to use AJAX! Commented Jun 7, 2012 at 18:32
  • 1
    That would solve the long load time problem, but won't I have the same issue with history (back/forward) and direct links?
    – ecpepper
    Commented Jun 7, 2012 at 18:41
  • 1
    You shall use a history plugin for that. Commented Jun 7, 2012 at 18:49
  • ajaxhistory.com is one example assuming you are not using a library like jquery or prototype. For these libraries history plugins exist separately e.g., github.com/balupton/jquery-history Commented Jun 7, 2012 at 19:00
  • I guess it's time to learn to use AJAX, then.
    – ecpepper
    Commented Jun 7, 2012 at 19:13

5 Answers 5


Best practice is to do AJAX based development. For browser history you can then use a plugin like ajaxhistory if you are developing over plain javascript.

If you are using a library such as jquery or prototype, then you can use a plugin provided for those. e.g., jquery-history-plugin


Only load the abstract of a report on the page, if a user wants to read more provide a download of a PDF that contains the full report and has sections. An abstract should have everything you need from an SEO perspective.

  • PDF? Seriously? Come on, people are going to be reading this on computer screens; PDF is for print media. HTML can be massaged into all sorts of shapes and presentations by user agents, that's what it was designed to do. PDF has a fixed page size, and it never fits the screen well enough to read comfortably, plus you have to navigate around the page breaks trying to avoid too much jumping.
    – tdammers
    Commented Jun 7, 2012 at 21:56
  • @tdammers I've never found PDFs to be as cumbersome as you describe.
    – Ryathal
    Commented Jun 8, 2012 at 12:26
  • PDF isn't bad at all; it's the de facto standard for distributing print documents, and it works reasonably well on practically all platforms. It's just not a very good format for screen reading. Formats that allow dynamic reflowing, or are based on a vertically continuous media model, are much better suited - and it just so happens that HTML satisfies both.
    – tdammers
    Commented Jun 8, 2012 at 13:10

Your setup doesn't sound that bad at all. To improve the user experience you can integrate the "page changes" into the browser's history. This will allow the back and forward buttons to work as expected.

Also, you can change the URL in the browser's address bar whenever a "page change" occurs. You don't need to reload the page in order to do this. (I imagine this is also part of browsers' history API.) Then people can easily grab a link to the "page" they are reading and share it. When one of those links is requested, you wont need much (if any) JavaScript to "navigate" to it. You can just deliver the page as it needs to be.

For an example of these features, take a look at any GitHub code repository and browse the code.


I have gone through the link http://massbudget.org/825 and according to my observation.. 1) Size of Intended data is very huge and it's taking a long time in loading the complete content of the page. 2) Navigation approach is not bad but can be more Readable and continent. 3) No need to deal with the content of the history.

Recommendations. 1) Don't load the complete document on onload event best practice will be either to use pagination or to use Ajax to dynamically change the content of div or page...

2) To enhance the readability you can provide Anchor tags that will provide the hyperlinks to browse incontinently between the content of the document. example: Approach used by most common Wikipedia (content section).

3) In current scenario as a user if an going through a div or page with heavy content the i have to scroll a lot so i will rec-amend that a particular div must be scrollable not the complete page suppose only a div of about 900X700 dimension will be scrollable the i will be having complete control over Navigation Bar, Content Bar(as suggested in 2nd point), Header and Footer as well.



Front-End Templating may be a useful solution for you. There are many frameworks to choose from and they have risen in popularity in recent years. Two examples are underscore.js and handlebars.js. Also, Mustache.

These may be useful as a corresponding implementation of AJAX.

If you find yourself duplicating your layout over and over... templating is a nice workflow and maintenance optimization.

Also, you would have to check the support for history, anchoring, and lazy-loading - but it is quite likely that a good templating engine would solve your three defined disadvantages.

link to example comparison.

All the best, Nash

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.