Ruminations on Posts vs. Pages

By Deane Barker on September 20, 2005

Blogging systems have always confused “posts” and “pages.” We’ve talked about this before: what is the difference between a time-sensitive “post” and an “eternal” page? At what point does a “post” get re-visited and revised enough that it should become a page?

We wrote about this at length almost two years ago:

What’s the difference between a blog post and an “article” or a “story”? By those terms, I mean content that isn’t as ephemeral as posts that hit the site every 15 minutes.

Blogs are, by definition, transient — they’re time-based, and items get essentially dropped into a stampede that tramples down the front page. What if you want something to rise above the stampede?

I also talked about this obliquely in a post about the Wikipedia coverage of Hurricane Ivan last year:

With Wikipedia, you’re not seeing a series of posted items. You’re seeing a single body of information, continually updated and groomed. Thus, the basic information stays right where it’s easy to see. Wikis are more “speak to me like I know nothing” information, rather than “tell me the very latest nuance” information.

The ideal is really a combination of both — keep the basic (wiki-ish) information right there, and have a sidebar of the latest (blog-ish) information as it comes in.

The difference between a post and page is reflected on this site — how do we differentiate this post from, say, our Terms of Service? Really, what are the differences between the TOS and “regular” blog posts:

  1. The TOS shouldn’t appear in any category listing
  2. It should have slightly different formatting (no “recent posts in this category,” no Adsense)
  3. It should have a different URL pattern.

That’s really about it.

Our solution was to have a separate blog in Movable Type for “Static Pages.” That blog uses the MTKeyValue plugin to explicitly specify a filename under which we want to write the TOS. It also has some different templates. Pretty simple.

Movable Type 3.2, however, includes a much more subtle method to getting decent static pages: entry basename control. MT always had the ability to morph the title of an entry into a URL, but now they let you set it:

With Movable Type 3.2, we really unleash the power of the basename field by allowing you to set it right in the entry interface. So now, you can title your entry “Play that not-so-funky music” and set your basename to “midi_ring_tones_on_your_cell_phone” to let link-hoverers and search engines know what they’re going to find on that page.

This means you could make an entry and set the basement to “terms_of_service,” and you’ve created your very own URL namespace for a static page. (You probably still need them in their own blog, however, since you don’t want to see them in any archives.)

WordPress has probably come the closest to nailing it by explicitly creating a sub-system for “pages.” From the WordPress Codex:

Pages, on the other hand, are most often used to present information about yourself or your site that is somehow timeless — information that is always applicable. For example, you might write a Post describing what you did or thought on a particular morning (“Breakfast was good”), but on a Page you might write something whose context is less time dependent (“This site is about breakfast”).

Pages in WordPress can be hierarchical. You could have a page for “Authors” then a subpage for “Deane,” “Joe,” etc. This feature is only in WP 1.5 and above.

Radio Userland has “posts” and “stories” (pages):

If you think of Stories — conceptually — as permanent or semi-permanent weblog Posts, you will be on the right track. Most folks compose weblog posts on-the-fly as they are inclined to share something of immediate interest. Stories tend to be written at leisure to capture extended thoughts on a given subject.

There’s a risk here, I think, of transcending the blogging format itself. If you’re using a WordPress blog for nothing but pages, do you even have a blog? Do you need to use WordPress or something else? A wiki perhaps? For that matter, do we need to declare jurisdiction:

  1. Posts are the domain of blogs
  2. Pages are the domain of wikis

If you sit down with a client who says that he needs a blog and you find out that he wants to store a bunch of static stuff that won’t change, would you be better off putting him in a edit-controlled wiki? (Or a CMS, for that matter.)

No hard-and-fast answers here, just questions.

Can we do a quick survey on other blogging platforms? How do they differentiate between posts and pages?

Gadgetopia
What This Links To
What Links Here

Comments

  1. I think that there are definitely three different types of systems involved and each has a specific function. Using definitions from Wikipedia, we have:

    • Blog: A weblog (now more commonly known as a blog) is a web-based publication consisting primarily of periodic articles (normally in reverse chronological order).
    • Wiki: A wiki is a web application that allows users to add content, as on an Internet forum, but also allows anyone to edit the content.
    • CMS: In computing, a content management system (CMS) is a system used to organize and facilitate collaborative creation of documents and other content.

    I think that a CMS is the only one of the three that can stand entirely on its own without the need for aspects of the others. I say that because if you have a blog or wiki, inevitably you are going to need those static pages that aren’t in the flow of the journal or editable by others.

    TextPattern seems to do a pretty good job of traversing the lines between CMS and blog:

    A free, flexible, elegant, easy-to-use content management system for all kinds of websites, even weblogs.
  2. It seems to me that a blog and a wiki are both CMS’s, only with a limited subset of the features you get in a “full” CMS.

    Put another way, I can use eZ Publish to create a blog by setting the home page to show the X most recent entries. Or I could use it to create a Wiki by allowing anonymous users to edit the article and get access to past versions.

    To get back to Deane’s original question, I think what makes something a blog, or a post, is more in the content and the way it’s handled than in the underlying system.

    It’s a little like the dividing line between what makes something a magazine vs a book or a pamphlet. The insert in the Sunday paper calls itself a magazine, but O’Reilly’s Make has a bookish format but calls itself a magazine. On the online side, A List Apart publishes in ‘issues’ and writes long articles, but reads and feels somewhat blog-ish.

    I guess that, in short, a blog is a blog because people think it’s a blog, and the same goes for a wiki. You can probably identify some parameters that make people think that, but in the end, what the site ‘is’ is sort of a collaboration between the authors and the readers.

  3. It’s also in how the administration system handles things. For instance, making a huge directory of static pages in Movable Type would be odd to administer because everything is date-centric in the admin side — it’s geared towards posts, not pages.

    On the other hand, WordPress’s page system is hierarchical, which makes more sense from a “page” perspective and gels it in your head better.

    I always thought that MT could make huge strides in this area by just letting you order entries alphabetically in the admin interface.

  4. I use ExpressionEngine quite a bit, and it muddies the waters even further in that posts dont even have to be date-related. EE has a blogging background, so many of the object names reflect that (sites still consist of blogs and posts, etc), but the only way to really grasp it is to think in database terms. An EE weblog is really a table with a completely flexible field and category structure. A post in the weblog is the same as a record in the table.

    One post may be a part number in a product catalog. Or one event on a timeline. Or one entire “about us” page. Or just the copyright date in the site footer. It’s all just a matter of how you chunk out the content, put it in blogs then build the templates to pull from the blogs and present the content.

    This approach leads to much more granular content than page-based content in a traditional CMS. Rather than bulding a timeline page, creating a 30 row table and making each row one event on the timeline, I create a timeline weblog and create one blog post for each event. The template creates the table and pulls in the posts as events.

    There’s a couple of advantages in this:

    • I can re-use those posts in different ways, such as randomized sidebars in other areas of the site. Or date-match the event date and do a dynamic “this day in history” feature.
    • The content owner doesn’t need to know tables, or bother with editing one large table when he wants to add or delete one item on the timeline.
  5. Someone on the inside at Six Apart contacted me and said they have something up their sleeve on this subject, for the next release or the one after. Stay tuned.

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.