It worth noting that I did this Saturday. Things have changed since. If you’re interested, popularly relevant information about development is at the WordPress Blog. More abbreviated notes, and up-to-the-day changes are tracked here.

Because some of my impressions make little sense without visuals, I’ve included a gallery of the most notable changes that have so far been made in the progress toward 2.7. (Sidenote: first time I’ve used the gallery in WordPress.)

And now my impressions, as originally noted:

I don’t really like how the new version smashes out the horizontal space. Though I doubt the change is nearly as big as it currently seems to me, it’s undeniable that the compose area fits fewer words per line than did previous (2.6-) versions.

The left side navigation has its pluses and minuses. I like that you can get to any page at all from it, but it’s also there even when you aren’t wanting to go to any page.

I think the term Utilities in the sidebar is misguided. “Manage” seemed to make more sense, and still does.

The built-in browse and install feature for plugins is pretty unquestionably cool.

The built-in upgrade to WordPress itself seemed to have failed on my one and only attempt. (It has since worked for me, the failure may have been a fluke.)

I think the ability to drag anything on the write page the sidebar is good, but it’s not as much customizability as I’d like. Will I ever be able to put a custom field on a post, without having to name that field every time? And be able to put that field right under the title field if I so choose? Until then any changes or not to the Write page will seem rather superficial to me.

There appears to have been few or no changes made to the Themes area thus far.

The dashboard has changed, but right now the utility of the “Inbox” and Quick Post sections, both sitting above the news boxes of 2.5+, are open questions.

Clearly there’s no small amount of work left before 2.7 “ships” in November (by current plans). That said, I’m amazed by all the great features slated for inclusion, and I feel so lucky to blog on such a constantly-improving platform.

The Problem: Incompatible Rules

During my work on Kaleidoscope, that’s the theme this site is running, I decided that a random post link in the footer would be nice. A quick search yeilded Matt’s Random Redirect Plugin, which was more than up to the job. Without a need to reinvent the wheel, I just borrowed the core functionality of Matt’s plugin function and dropped it into my theme’s functions.php file.

And on my personal test server, it worked well. And when I put it on the Ikiru Demo Blog, there too it worked fine. But I found problems on Ikiru Design. More frustratingly, those problems would sometimes seem to suddenly disappear. (It was only later that I realized that it was whether or not I’d logged in that was the cause of that disparity.)

As you may suspect from what I’ve said so far, Ikiru Design has the WP Super Cache plugin running (though it has rarely needed it). Looking desperately to figure out why my redirect link in the footer worked on the demo blog but not on the main one, I decided to look through their directories.

Solution One: Changing .htaccess

Mercifully, I noticed that the .htaccess files were drastically different sizes. And I remembered that SuperCache depends on your making changes to that file. And indeed, comparing the two showed these lines added to Ikiru’s .htaccess file:

# BEGIN WPSuperCache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
</IfModule>

# END WPSuperCache

I now understand what this does, but at first I didn’t. It looked like a mash of random characters. But I know enough about programming conventions to guess that an “!” means not. And I also know enough about this modern world to know to Google things I don’t understand. “RewriteRule” seemed a reasonable phrase to start with.

I’ll spare you the full narrative of the search, but I’ll explain what I learned. RewriteCond provides the conditions that determine whether or not a RewriteRule is used by the server. Essentially, if a user trying to access a given file on the server gets through all the conditions in the RewriteCond stack, they’ll be made to follow the RewriteRule.

In this case, that means that if their query string — that’s the ?s or ?p=187 or ?random that tells the server what dynamic features are wanted — doesn’t start with ?s, and if the user doesn’t have a cookie specifying that they’ve either logged in or commented, and if the proper static file has been generated, send them that static file. (You see essentially the same rules there twice, the top one is for if you’re using compression, the other for if you’re not.) This is exactly how Super Cache is advertised to work.

But it means that the server will ignore the query string ?random that Matt’s Random Redirect function relies on. So the user will get, as I was, the cached version of the index page. And they’ll get it before Matt’s plugin has had a chance to well, redirect them.

Having figured that this was what was probably happening, I felt reasonably hopeful that I could finally fix this week-old problem. After all, the random link was working when I was logged in — thus not making me follow the RewriteRule — but it was failing when I wasn’t.

So I added was this line to the RewriteCond stacks:

RewriteCond %{QUERY_STRING} !.*random*

This adds an exclusion, which says that if the url looks something like “http://www.ikirudesign.com/?random”, exclude the user from the RewriteRule. Uploading the modified file and opening the link from every conceivable page I could find showed that it was finally working.

Solution Two: Changing the Function

But this can’t be packaged into a theme. Fortunately, a usable but imperfect solution can be. The basic problem is that redirects break with WP Super Cache. The solution is to do this same thing without a redirect.

Essentially, all this take is simplifying Matt’s Random Redirect Plugin even further. The result was this function:

function sc_safe_random() {
	global $wpdb;
	$query = "SELECT ID FROM $wpdb->posts WHERE post_type = 'post' AND post_password = '' AND post_status = 'publish' ORDER BY RAND() LIMIT 1";
	$random_id = $wpdb->get_var( $query );
	return get_permalink($random_id);
}

This is essentially the first three lines of Matt’s function — which picks a random post from among those eligible on your blog — and adds a line that just tells it to pass the permalink for that post to the place where the function is called. Then you simply call the function for your random link, like:

<a href="<?php echo sc_safe_random() ?>">a random post</a>

This solution works, but it’s got a problem. If I were to click the redirect version into five new tabs from a single page, I’d receive five tabs each with a different random post in it. If I do the same with this version, I get the same post each time.

The likelihood of someone doing this is obviously questionable, but it’s a feature that I’d rather not lose. For that reason, I’m planning on making sure that I allow a user who doesn’t have WP Super Cache enabled, or who have implemented Solution One, to use the redirect version. Those who have Super Cache enabled, or who don’t mind the limitations of this second solution, would be able to continue to use it.

1. The theme now has an options page. Controllable are the accent color — at Ikiru Design that’s set to “orange” — which is used one the description in the header and the links in the footer, the display of default gravatars, the display of The Mini Quilt (see #2), and switching to Southern Hemisphere colors.
2. The Mini Quilt. The Mini Quilt is a smaller version of the Quilt that appears on Kaleidoscope archives pages. To fit, it sacrifices displaying the Post Titles — though you’ll see them on hover — in favor of offering many more posts than a basic Recent Posts widget would. (And if you want to display both, or have even more control of your sidebar, the quilt will also appear as a potential sidebar widget.)
3. The random post link in the footer is now compatible with WP Super Cache. Because the popular plugin changes a blog’s redirect rules, the old method — which required a redirect — would break when you ran the plugin. The new method, which gets rid of the need for a redirect, will help keep your server load down, and will let readers use the link whether you’re caching or note. (Also, I’m working on a post explaining two different workarounds for the problem.)
4. Fixed a number of visual “bugs”. Two different problems caused the layout of certain pages to break in 0.7.6, with the help of Babs, those are fixed. A number of little problems have been tackled.
5. Finally, and this may have been unnoticed by everyone but me, in previous version of Kaleidoscope (and every theme I’ve made for that matter) the search bar has been outside of the area in the sidebar that is replaced by widget. That is because I didn’t like the styling of the widget. But now I’ve overridden the styling of the widget, and am satisfied with it. Essentially, you finally have the freedom to put the search box where ever you want it in the sidebar.

These are some of things I’d been planning to do on Kaleidoscope and I’m glad to have finally gotten them out. I’m sure there are still problems lurking under the surface, and I’m sure a quick-eyed user will find them quicker than I. If you’re such a user, please drop me a line.

Oh, the download link! And here’s a link to Kaleidoscope’s listing in the WordPress Themes Directory.

I honestly don’t remember when I started working on it, but I wouldn’t be surprised to find out it began in January. That isn’t to say that development of this theme has been terribly difficult — though there were certainly parts I’ve struggled with — but also that I’ve simply been short on time I’ve been able to devote to the project.

It wasn’t until Friday, after what felt like a too-long wait, that I finally saw the then-current version, 0.7.6 in the newly opened WordPress Theme Directory. This release, as signified by it’s less than 1.0 status, is less than I intend to do with the theme. But I’m hoping that finally making the project public will force me to spend more time to add the last features that I’ve been waiting so long to build.

Enough about how my development process works however, let’s cover the highlights of the theme itself. The primary feature, the one for which it is named, is the algorithm that translates dates into colors. This is done with a few PHP functions which take advantage of cosine curves to generate colors that are generally suited to the time of year. Essentially, the three colors of the red-green-blue system commonly used in HTML, all peak at different times. The blue is at it’s height around January first, green peaks around April 1, and red peaks around September 1. All of these are estimates, as I’ve fudged a bit with the peaks and valleys of these curves to give me colors closer to what I want.

Taking advantage of this date-to-color algorithm, I’ve made my favorite feature, the quilt. The quilt is, as you may guess, a collection of differently colored squares to create a blanket to keep you warm… err, display your posts. Rather than use the month-divided list-style archives I’ve built for my themes in the past, I’ve made a single collection of all posts, with colors serving to give you a rough idea of the date. You can easily tell posts from January from those from August, and you can also tell posts from 2008 are different from those from 2005. Of course, this feature is also made even easier to understand by the fact that the post are themselves shown chronologically in the quilt. The real result of the quilt, however, is that you get a beautiful rendering of your archives.

There are many more little features in this theme. I’ve added a rather novel system to hide the default gravatars when a user hasn’t set them. Trackback are seperated from comments so they don’t break the flow of conversation. The whole archives page is prettier than any I’ve made. Heck, the theme itself is just prettier than any I’ve made. And page titles have a novel organization I’m rather fond of.

Mostly though, I’m glad to have finally put this out into the world. It’s still not done, but I simply can’t continue to sit on it. I’ll keep you updated about changes I make to it in the future, and I hope to write a few tutorials explaining the most interesting features of Kaleidoscope to anyone interesting in using them in a different context.

You can, of course, see a demo of the theme at the Ikiru Demo Blog. Be sure to look at the archives page. (Or you can just look around here, as it is the theme Ikiru Design is currently using.) There is also a demo, lacking an archives page, at the WordPress Theme Directory. And you can download the theme from there. You can find even more rambling about it at the theme’s page. And if you have anything to tell me about it — be it bug reports, complaints, or compliments — feel free to contact me.

As anyone who’s spent much time surfing the internet can probably tell you, a mailto: link is the kind that usually launches a user’s email client and has some information — at minimum an address, but subjects aren’t uncommon — already filled in.

It sounds benign enough, but I don’t like it. There are three essential problems with using mailto: links on today’s internet. The first is a problems for the publisher, the second is a problem for users like me, and the third is a problem for all users. Add those all up, and I’m rather certain that mailto: links should be used as little as possible.

The most obvious and well known problem is the one posed to the publisher. That is: for nearly as long as there have been spammers on the internet, they’ve built bots those go around and scrape information from mailto: links. With this information, they do what any sensible spammer will, send you offers to enlarge your penis, get rich quick, win the lottery, and — if you’re really lucky — sign up for totally disgusting forms of pornography.

No one wants this stuff, and so schemes have been imagined to combat the problem. Some are rather low-tech, like creating a broken mailto: link like “mailto:me[at]me[dot]com.” This can work, if the sender recognizes that you’ve broken the link and they need to fix it. A myriad of other, more complex, options exist and yet none of them offer much compelling reason for not abandoning the format altogether.

But honestly, I don’t really care about the problems a publisher has when they use mailto: links, I have a problem with the inconveniences they cause me.

The first of which, and admittedly a not completely common one, is that I use Gmail as my primary email client. As such, when I (inadvertently) click a mailto: link the computer launches the default email client which I’ve never used nor configured. This means that I get a useless program launch that lets me compose an unsendable email.

There are work around for this, of course. One of the more elegant is offered for the forthcoming — but already widely used — Firefox 3. Gina Trapani explains how a few mildly technical steps can make the browser launch Gmail for mailto: link. But this isn’t something that the average user of a web-based email client is likely to know about or do, so it hardly solves this problem for those who want to use the mailto: link.

The last gripe was already touched on, but has broader implications than I earlier suggested. I can think of few things worse than navigating around a site and inadvertently launching another program — whether or not I regularly use that program.

This is usually a result of poor design, but not always. To my mind, the greatest sin is when a site puts a mailto: link in main navigation controls. This wasn’t too abnormal a decade ago, but mercifully convention now say that such a link should never launch an external program without warning. Some have yet to get that memo about conventions, however.

Though I personally dislike curmudgeonly exhortation from anyone, including myself, sometimes it just feels necessary. Mailto: links are a poor invention when they work perfectly, and a hideous invention when they don’t work properly.

Personally I’m a fan of contact forms — like the one I use. There are a lot of plugins that make it easy to build one for WordPress, the most noted of which is cforms II. If that’s too much, you can also simply create a separate page that says Contact, and offers an email address there. Or you could simply make explicitly clear that your email address is behind a mailto: link. I’d certainly prefer seeing the inelegant “Contact Me (mailto:)” to the deceptive “Contact Me.”

Of course as just a random internet crumudgeon, there’s little reason for you to follow my advice. I accept that. But don’t tell me I didn’t warn you when you receive an angry email from a crumudgeon like me.

Good

• A New Look — Though I wouldn’t say that all aesthetic changes made to WordPress redound to the good, I’m satisfied. The new colors are nice, the dashboard’s been improved, and everything feels better.
• Much Better Tag Integration — This is a direct descendant of the above point. Now a list of entries shows the tags. Now we get tag suggestions. And the ability to edit tags as a group. All of these are big improvements over the piecemeal support for tags that felt tagged on to 2.3.
• Better Media Integration — Though I’ve heard — and share — some discontent with the new Flash uploader, it’s nice that it was rethought. The ability to easily upload many pictures, and to easily create galleries are nice changes.
• Crucial or Trivial Bonus: Plays nice with Safari/WebKit — Anyone who tried using Safari with WordPress before will understand what a nice change this is. Anyone who hasn’t tried will think this is a silly point.

Bad

• The Bugs — This may be based solely on the fact that I use custom fields, but I’ve been having terrible trouble with both scheduling posts and the unnecessary creation of extraneous drafts. These sins can be forgiven, but I am getting rather impatient waiting for a fix.
• The New Look — A lot of changes to the Write page are for the better, but the dearth of white space on the right side confounds me. Catergories were there previously, and I think there was a number of good reasons for that. Tags, I think, should go there as well. But neither’s there. As I sidenote: I’m not really a fan of this Lucidia Grande business in the editor either.
• Change is Hard  — This is more a personal problem, but a lot of people (myself included) have been and slow to accept 2.5. This innate resistance to change is both irrational, and a waste of time.

I’m certainly not going back, and am even less likely to change blogging platforms, so all of this is essentially trivial. But now you know.

Perhaps I’m the only one who has noticed. Perhaps others have noticed but decided to remain silent. Perhaps others who noticed weren’t silent, but spoke while I wasn’t paying attention. (To be fair, a few noticed and spoke up.)

Whatever the case may be, I have an announcement: “Zoom” is replacing “Increase Text Size” in most browsers. And though I confess to initial ambivalence, I’m increasingly certain this is a good thing.

If you’re not sure what I’m talking about, click on View and look for “Increase Text Size.” Can’t find it: congratulations you’re using IE7, Opera 9.5, or Firefox 3. (Safari still seems tied to text size.) If you can find it (or a similar), you’re looking at old technology.

Now, this will all be largely irrelevant to those who don’t spend hours tinkering with CSS, but this does has some important implications for us that do. Many web designers — I count myself among them — have gotten into the habit of sizing as many things as they can with ems.

Sizing with ems allows people who need bigger text to get it, without breaking your design. If your browser still has “Increase text size,” you can play with it on this page. You’ll notice that everything scales. (Well, almost everything. The divider won’t, more on that choice can be found here.) With the design I’m using, this is a relatively unimpressive feat, but it does demonstrate the point.

There are problem with designing with ems, primarily that images — barring some fancy footwork — won’t change like other elements. This is why zoom is much more useful than “Increase text size:” it scales images as wells. Further, this means that designers using ems are becoming, essentially, outdated. Using pxs or even pts will now (well really, when “Zoom” browsers completely replace “Increase Text Size” browsers) have the exact same efficacy as styling with ems.

And now, if your cared, you definitely know. And if you didn’t, you still know. Congratulations on learning something.

The problem is essentially this: page views are what determines advertising rates on the internet. The more page views a website has, the more they can charge advertisers. Thus they have a perverse incentive to stretch even the smallest article over many pages.

I loathe this practice, and as a consequence I’ve thought about it quite a lot, and so I’m here to offer the internet some salient advice on the topic.

• Paginate responsibly. I offer for you consideration, a list of the top 25 band logos of all time. As the rather famous Jason Kottke prefaced his link to the site, only offering one image per page is absurd. Surely it’ll give you a massive number of page views for those who are willing to click all the way through, but you also risk a massive number of people quiting after three clicks.
• Make a single page view available. This strike me as a reader as absolutely required, but I’m appalled by the hordes of respectable sites that refrain from doing so.
• If I must, I’ll use “Print View.” This is a double loss for most publisher, who (thankfully) refrain from putting an ads on their printable page. Unfortunately, these views are also ugly and unoptimized for screen reading (that is, if they were optimized for reading at all).
• I’ll leave if it’s too hard. If you offer a single page view, you’re only half way there. You also need to make it easy to find. Putting it at the top of the page is probably best, putting it at the bottom of the page makes sense. Whatever you do, don’t hide it or I’m apt to give up on reading your content entirely.

Practical Examples

If someone understands how to paginate on the web, it’s the New York Times. Not only do they offer a single-page view, and not only is there a good amount of line-spacing, but they’ve made the button easy to find. Right at the top of every single paginated article (and right to the right of this text) they have a convenient “Single Page” link for me to click before I even start reading.

Another, but different, style is offered by The Weekly Standard. The conservative weekly’s website could perhaps use a face lift, but their pagination policy’s sensible. Though the don’t offer a simple single page view, they never extend an article past page two. The effect of this is that though a reader must “turn” the page, even for long articles you don’t have to “turn the page” 24 times.

Also of note is an online “magazine” I love, Slate. Because I’ve confessed to being a fan, I can and will now browbeat them a bit. You should know that the average Slate article is one or two pages long. Now consider this: after the first page, right by the pagination links they offer a “single page view” that snaps to after the end of page one. This policy is more sensible than the one in use at The New Yorker (where the “single page” link in the same position takes you to the top of the single page view), but it’s flawed. After all, for a two page article — again, Slate’s average length — this has essentially the same effect as click onto page two. If articles were routinely three or more pages long, this would make sense. But as an avid reader I feel confident in saying that this is rarely the case.

Surely it’s hard to get it right, this choice between pageviews and reader satisfaction. Most websites do an admirable job. But that doesn’t mean I won’t still be a little bitter that they aren’t putting my desires first.

I — and many other people who sometimes opine on blog design issues — think its rather useful to have images on posts. They’re a quick introduction to your topic, a way to jazz up your text, and a great way stand out at least a little bit.

And if you’re like me, you’re not exactly a prolific photographer with thousands of images that you can use for all kinds of topic you might write about. Also, you probably don’t want to go about buying photos to use. In such a case you have two choices, one legal and one not. (I’m actually ignoring the existence of free stock photos, because I’ve never found them terribly useful.)

The illegal — or at least problematic — way is to take them from other website. One thing I used to do, was hotlink directly to Yahoo!’s images. And I’ve also used Google Image Search, without regard for who owned the image or what have you. If it looks roughly like I wanted I’d upload it to my own server and use it.

And so now, assuming we’re not pirates, we have a problem in need of a solution. And there is a very easy solution: Creative Commons images. As you very well may know, Creative Commons is a license in which the creator give away some — but crucially not all — rights to what they’ve produced.

The easiest and best ways to find Creative Commons licensed images is with a Flickr Advanced Search. Down on the bottom of that page, you’ll find an option for Creative Commons licensed images. For myself, I always choose “Find content to use commercially” simply because I want the least stringent and problematic license. What you find there doesn’t exactly leave you home free. Almost all — perhaps all, I don’t know — CC images require a citation. Some also require other things, but this is the most important requirement from a design perspective.

Designing Images with Citations

DWQ

We’ve established the need for citations on images you might use on your blog. And there are indeed a number of ways to cite. Many conscientious people lacking some know-how simply add a “The image on this post is from Mr. Flickr” at the end their posts. But for myself, I wanted something at least a bit more elegant than that.

For inspiration, I’d always liked the way that The Economist’s website displays the citations on its images (see random example), and decided to mirror it. There were mild changes I made beyond that — for my own aesthetic preferences, but that was the layout — and CSS code — to which I referred while devising this solution — which you may notice in the out-of-place-photos of Optimus Prime and Canadian geese, each lazily stolen from Frozen Toothpaste entries (here and here).

I have two basic ways, both of which work essentially like this in WordPress’s “code” editor for a given post:

<p class="rightcite">
<span><a href="http://www.dummyurl.com/">Dummy Photographer</a></span>
<img src="http://www.myadress.com/images/dummy.jpg" />
</p>

As you may be able to tell from this rather simple (X)HTML, this simple creates a paragraph while will carry the styling from the CSS class “rightcite” — more on what that means later. The next line is the photographers name, with a link to the URL that they want used for citation. For our purposes, it doesn’t really matter what’s on that line so long as it’s wrapped with the “span” tag, again used for styling. The third line is simply the image, preferably hosted on your servers, though there’s no reason it must be.

A note: The use of the paragraph (“p”) division rather than the more traditional “div” simply because WordPress seems to choke on anything but the paragraph division. If you’re using a different content management system, feel free to see if it can handle the use of a “div” rather than a “p.”

Now, we must style this stuff so that it looks good on our site:

p.rightcite {
display: block;
float: right;
margin: .1em 0 .1em .5em;
background: #f1f1f1;
padding: .2em;
border: 1px solid black;
}
p.rightcite span {
display: block;
text-align: right;
font-size: .8em;
color: #555;
margin: -.5em 0 -.4em 0;
}

As you may be able to tell, the first set of styles is for every part of the “rightcite” paragraph. The crucial things to note are the “display” and “float” properties. The rest just makes it look the way I want, but those two make the paragraph float to the right.

The second set of styles is for our citation, again the most important part here is the “display” attribute, which prevents the citation from floating all over the map. The rest is again mostly for aesthetic concerns.

Now, you may be interested to see a similar thing for a centered image, which is just a bit more complicated.

p.centercite {
display: block;
text-align: center;
margin: .8em auto;
width: 468px;
}

The crucial thing here is the width declaration, which is needed to keep our “span” text from floating away. Obviously, by declaring a width for this paragraph you’ll have to keep your images to that width for proper functioning. You can change that width in an implementation on your own blog, but I wouldn’t recommend changing it once you’ve decided what width you’ll use.

There are some other notable ways to do a similar thing as all this with different methods. The most interesting and prominent in my mind is Derek Punsalan’s, which uses custom fields. I’ll leave the explanation of that technique to him.

If there’s one problem in this ever-growing blogosphere, it’s that sites are so easy to create that no one worries too much when they die. So they continue to sit out here with the living, quickly becoming useless piles of bones that get in the way of the rest of us.

This is a problem in itself, but it’s one with which we can cope. We can cope so long as these bones aren’t intentionally made to look more alive than they are. So long as bones show themselves to clearly be bones, we living members are pretty able to avoid those we don’t really want to look at.

But a problem arises when you hide that your website is a skeleton. When you decide that you’ll get rid of post times or — and this is far, far worse — dates. Then when I come upon your site a quick glance around doesn’t tell me if I’m dealing with a skeleton or a living, breathing, changing blog

And if there’s one thing I less like than a dead blog, it’s a blog that doesn’t quickly fess to its deadness. Some otherwise great blogs and themes have this problem. I really like a lot about Brian Gardener’s Revolution theme, but I hate that no version puts publication times or dates on all the articles shown on the front page. Perhaps this was intentional or a simple oversight, but I don’t like it.

This is the internet age when lifespan of content is measured is hours, or — if we’re to be very generous — days. In such an atmosphere not telling me when your content was published is like admitting that you’re not a part of these exciting and rapidly changing times.

In some situations you could get away without times. Yahoo!, for example, doesn’t offer them on it’s homepage. And the Washington Post and LA Times are both lax about the times their stories were written. But they’ve got a great deal of built-in trust as well-known sources of information, and arguably important ones. A visitor can easily guess that, at most, the content is a day old.

But visitors to MyRandomSite don’t know who you are or what you do. They don’t know that they can trust that you’re not a pile of bones. So you need to tell them. Not much is needed; seeing “March 5, 2008” on a post is enough in most situations. That way I can tell that if nothing else, your site’s not a pile of bones. Maybe you’ve not updated in a few days or hours, but I know when you were last seen breathing. In a place where content’s cheap and credibility costs a great deal, that little bit matters a lot.

So please, bloggers, webmasters, web designer, and spectators, put a time stamp on your content. On your front page. Tell me that you’re not expired and I’m more likely to stick around and give what you’re doing some consideration. Thank you.