Jumper is a little addin which can be used to truncate posts on category pages, and automatically add a link to a dedicated page containing the complete post. I wouldn't doubt that you've used something like it with other platforms.

It supports a couple of niceties including:

• The ability to specify unique jump trigger for individual posts
• Support for defining multiple triggers

Download Jumper

For complete details about the options, look over the settings in the Jumper's config section at the top of the addin.file.

Installation

• Download the addin.
• Expand the zip archive.
• Copy the Jumper addin folder to your site's addins directory.

It's a simple drag and drop install, like the majority of Ode's addins, and there's nothing that you need to configure (assuming you're happy with the defaults).

Configuration

• Review and optionally modify the settings in the config section of the addin file.

Usage

• Add one of the jump triggers specified in Jumper's configuration to one or more of your posts.

More about the addin

Tags

The addin includes support for a single tag, **alt-jump-trigger**.

The format of the full tag is:

> tag : jumper : alt-jump-trigger : tag value

which confirms to the standard tag naming convention:

> tag prefix literal : tag source : tag name : tag value

You can use the tag to define a unique jump trigger for individual posts.

For example, if I wanted to use the string [[JUMP]] as a trigger for a post, and that is not one of the configured triggers, I could add the following tag:

Remember that tags belong between the title and body of a post.

Parameters

The addin recognizes a single parameter: include_jump_separator

When the parameter is included as part of the query string with a request that targets a individual post page, the addin will place a separator at the point where the jump_trigger appears in the post (replacing the trigger).

Without the parameter the jump_trigger will be removed but the separator will not be used.

You should never need to type this parameter manually. It is included by default as part of the link generated by the addin for posts which include a jump_trigger.

This means that when the visitor clicks the link and arrives at the the page displaying the complete post, the separator will appear providing a cue as to where they should pick up reading.

Read through the comments for a complete description, and thorough annotations.

Description
(taken more or less from the description included in the addin itself)

When you first read the description of what Jumper does, you may not think you need it. Having said that, I would encourage everyone to give it some serious consideration.

I'd guess that most people will benefit from installing the addin and using it at least occasionally.

Why? Well, let's start with a description and then come back to this question.

Keep in mind that there are three (3) broad request types:

1. root - 'sample.net/cgi-bin/ode.cgi'
2. category - 'sample.net/cgi-bin/ode.cgi/books/perl/'
3. post - 'sample.net/cgi-bin/ode.cgi/books/perl/learning_perl'

Every request is one of these three basic types.

Jumper does only one thing.

First you insert a token (i.e. a special string) at any point in the body of a post.

The addin takes one of two different actions depending on the type of request.

For root and category requests Jumper truncates the post at the point of the token, replacing everything that follows with a link to a page containing the complete post.

For post type requests (like the link generated by the Jumper addin at the end of the truncated post on root and category requests), the addin displays the full post.

For example

Let's say that I have a post file titled 'some_post' in a category titled 'some_category' at the root of my Ode site.

'.../some_category/some_post.txt'

OK, now let's say that the contents of 'some_post' are as follows:

START OF POST
I'm the first line of some_post, which makes me the title.

I'm the first line of the body.
I'm the 2nd line.
TOKEN
I'm the 3rd line.
I'm the 4th line.
END OF POST

What will the post look like on the page returned in response to a request?

For root and category type requests, for example:

http://sample.net/cgi-bin/ode.cgi/
http://sample.net/cgi-bin/ode.cgi/some_category/

The post will look like:

START OF POST
I'm the first line of some_post, which makes me the title.

I'm the first line of the body.
I'm the 2nd line.
-LINK TO PERMALINK-
END OF POST

But for post type requests, for example:

http://sample.net/cgi-bin/ode.cgi/some_category/some_post

The post will look like:

START OF POST
I'm the first line of some_post, which makes me the title.

I'm the first line of the body.
I'm the 2nd line.
I'm the 3rd line.
I'm the 4th line.
END OF POST

(Note that this is an overly simplified example.)

So, back to the question, 'Why is this useful?'

I can think of two very good reasons for using the Jumper to truncate posts for category and root type requests.

(I'm not suggesting that these are the only two reasons for using the addin.)

1. Analytics
2. Performance

1. Analytics

It's often useful, for any number of reasons (including simple curiosity), to look at who is visiting your site, where they came from, what they find interesting, etc.

Web analytics is the measurement, collection, analysis and reporting of internet data for purposes of understanding and optimizing web usage.

Definition from the Wikipedia entry for Web Analytics at http://en.wikipedia.org/wiki/Web_analytics (2010_0411 2:10 pm EDT)

Weblogs, and dynamic sites more generally, present some challenges related to analytics. (I'll discuss just the one that is relevant here.)

With a typical weblog, every post initially appears at the top of the home page, and possibly category pages and other pages containing multiple posts.

Though each post may have a dedicated permalink page, frequent visitors, or anyone directed to the site to read a popular post soon after it is published, is likely to encounter the post on the home page.

From an analytics perspective, the problem with this is that we don't know what specifically visitors are interested in if the majority of them are reading the content from the homepage. (We just know that they've been to the homepage.)

If I have 20 posts showing up on the home page of my site and 1000 visitors, looking only at the home page, I can't know which of those posts what number of the visitors actually read.

With Jumper in use, only part of each post is visible on the home page.

Visitors must actually navigate to the page at the permalink for a post to read the whole thing, which they will do if they're interested in a particular, and not otherwise.

The request for the permalink page is recorded in the site logs (or noted by a 3rd party analytics service, such as Google Analytics). With this information, it's easy to see exactly what content visitors are reading (and what they're not).

2. Performance

If the first reason seems a little self-serving, at the expense of your visitors, the second is clearly for their benefit.

Ideally, people visiting your site want pages that load quickly and are of reasonable length so that they're easy to navigate.

One mechanism we can use to limit the length of pages is the num_posts setting (specified in Ode's config file). This option controls the number of posts displayed on any one page by default, and in that sense can be used to limit the length of pages.

(Note that the num_posts setting can be overridden on a per request basis with the num_posts parameter.)

A page with 10 posts would seem to be ten times shorter than a page with 100 posts. As a result, we might expect it to load faster and be less difficult to navigate.

But this is only true if every post is the same length.

A page of 10 posts is the same size as one of 100 posts if on average the posts are 10 times longer.

With the jumper addin, we can control the length of our posts as displayed on category pages, and so, combined with the num_posts parameter, we can control the length of these pages. Regardless of the size of individual posts, every page consisting of some x number of posts will be roughly the same size if we use jumper to truncate them at approx the same point.

This translates to consistent load times for pages and improved navigation.

There's another issue to consider, namely media.

The web is a rich media space. We can display images and video, in addition to plain text. We can also have complex behaviors using Javascript. Though this greatly enhances the utility and appeal of the web, it can get pretty complicated and resource intensive.

For example, we might include a single optimized image in a post and add 90 KB to the size of a page. Alternatively, we might embed an entire gallery of images and add tens of MB.

Is 10 MB too much? It depends on the audience (e.g. their bandwidth, patience, and level of interest), the capabilities of the server, and many other factors.

The short answer is no, not necessarily.

But now imagine a photographer with a weblog who regularly posts these sorts of galleries.

If we have 10 posts on a category page, each of which includes a 10MB gallery, then that's 100 MB (in addition to the size of of other elements), and almost certainly too much for a single page.

We want the galleries to load individually, on pages corresponding to the permalink for each post, but we don't want the galleries to display on category pages. We can do this by using the Jumper addin to truncate these posts right before the gallery.

So using this addin has the potential to benefit both you and your visitors, and that's why I suggest that you might want to consider installing it.

Download Jumper