Hi, I'm david (b) hayes.

There’s a well-worn maxim very relevant to the life and death of this site: “only a poor craftsman blames his tools.”

The tool we’re talking about here is 2004 Compaq Presario X1000 laptop that has been my primary computer since that year. It runs Window XP, has 1.6 screaming gigahertz, and can barely stay usable if you try to do two things at once. (Don’t even ask about playing Flash videos smoothly.)

I’m too focused on other monetary goals to purchase a new computer until I really need one. But with regards to programming-type activities, I’ve been letting my computer’s deliberateness serve as my excuse to do nothing about getting better at them. This is due primarily to a fundamental misunderstanding of how real work gets done real workers.

Surely, I’m not completely wrong in the thinking that a faster computer running the Mac OS I’ve been lusting over pretty much as long as I’ve had this computer would increase my ability to do these things. Surely Coda’s a nicer piece of software than one can easily find for web design on Windows (especially when you’re unwilling to spend money because you intend to stop using it… sometime). But that’s not really the reason I’ve not gotten better at this internet creating thing.

To extend the opening idea, a craftsman very dedicated to carving wood will do it with rocks if that’s all he has. A man who insists that he can only make something interesting with $4000 of equipment has no real interest in making things with wood. We may be able to say he’s interested in the idea of making things with wood, but no one should be considered serious about a project he isn’t working on regularly. This is the hard truth that I’m still working on learning fully.

My first article on the merits of Tumblr and WordPress was written for the rather specific things that I desired in a link-blogging engine. (The linkblog I made is called Link Banana, if you’re interested.) I think what I wrote does cover that well, but in the intervening years that post experienced some unexpectedly strong Google mojo and still sees a respectable volume of traffic from people looking for a basic comparison of the two platforms. That piece wasn’t very good for that purpose, and the battle has changed a fair amount in the intervening years, so to better help people wondering how to start a blog I’ve redone the comparison with a more universal mindset.

To Begin

Tumblr is an engine built for “tumbling” or “tumble blogging” or various other derivatives in that direction. In short, it’s built for you to collect things (photos, videos, quotations, links…) from the internet & sundry and present it to the world in a unified & pretty looking site. While it is absolutely possible to use Tumblr to write 24 paragraph essays in the context of a broad and fully-featured site, it’s not it’s primary goal.

WordPress is the premier blogging platform in the style of old. It’s got great features for the person who’s looking to mostly publish longish essays. It’s recently been extended so that you can effectively use it like Tumblr, but it’s not the core mission and as a newish feature hardly has the robustness of the rest of WordPress.

It should also be noted that WordPress can mean two different things. WordPress.com is a free and easy way to publish a blog. WordPress.org is a free and rather easy way to start and publish a blog on your own webserver and your own web address. Essentially, you have to pay for hosting to use WordPress.org with all it’s customizability. Most people who are interested in a comparison are likely new to this whole blogging thing, and so interested in WordPress.com. As such, that will be the primary comparison here.

I’d also like to take the opportunity to note that while these two are the best free blogging tools to my eyes, they’re not the only ones. Google’s Blogger, long languishing, is finally getting some updates to make the back-end feel less like it’s from last decade. Posterous, which I’ve never fully grasped, has many satisfied users. LiveJournal still exists, though it hasn’t been the cool kids spot in a decade. But if neither of these tools I describe strike your fancy, don’t give up. Look around.

Social Features

We’ve already established that both WordPress.com and Tumblr have the ability to handle your writings, quotations, pictures, etc. Given that both are adequate at the task, most of the big differentiators are external to that calculation. (Though we will talk more about it later.)

One of the features of Tumblr that I completely neglected in the last blogging battle is its most compelling. The ability to follow people and get the latest from everywhere on your dashboard. The neophyte’s explanation of this is “your Facebook newsfeed for Tumblr”. The old pro’s explanation is that this is a “highly social RSS reader that encourages responses.” In either case, the ability to like things, “reblog” — quote their post and then add a response — and reply directly means that you get a way to not only make a blog, but follow and interact with your friends and people you admire. This is, to use a third technology analogy you may not get, a more complete and compelling version of Twitter. And like Twitter, its usefulness is largely determined by the number of people you’re interested in that are on Tumblr.

WordPress.com has a feature somewhat similar to this — they call it “My Subscriptions” and it’s implementation is about as dry as it sounds. While it’s a serviceable RSS feed reader — way to stay current on what a group of people is saying in one single location — and it does offer “reblog” and “like” buttons, both it’s design and function are left in the dust by Tumblr. The whole thing feels like a feature bolted onto the core WordPress experience, rather than integral as it is on Tumblr.

Advantage: Tumblr

See What I’m Talking About

Writing

There are a number of ways to write and a number of reasons to. That’s to say that I’ve set this up as virtually unwinnable. If you’re interested in writing a personal journal or long discursive essays, and you intend to do that in situ (that is: in your blogging software, rather than in MS Word, text files, etc) WordPress almost certainly offers the better and more complete experience. It’s got a full screen writing mode (of which a far better version is imminent), a spell checker, easy formatting, and strong style controls.

If you’re mostly looking to respond to things your friends and heroes said or drew or photographed, Tumblr is simply unbeatable. The ease with which you can grab the content you’re looking to respond to, dash off your few paragraphs and have that live on the web is crazy when you compare it to WordPress. Coupled with the Tumblr dashboard’s aggregating features, WordPress looks even more like a dinosaur. But the compose screen on Tumblr is comparatively modest, offering only the bare essentials of what you may possibly want if you aim to publish on the web.

Advantage: WordPress for longer discursive writing, Tumblr for quick dashes and reactions

Reliability

That I didn’t mention this last time is a testament to both my relative inexperience with the platforms and the relative stability of both at the time. Around the time that I wrote the last match-up, Twitter was renowned for being constantly down, unable to cope with the load of it’s users.

Today, if any single site on the internet deserves that description it’s Tumblr. How long these problems will persist is unknowable, but in the last few months it seems that the “wild tumbeasts” — Tumblr’s answer to Twitter’s “Fail Whale” — are winning. It’s certainly not constant downtime, or even predictable, but it’s frequent enough that casual use meets with slowness and frustration. Surely some combination of increased server power and decreased user demand will eventually remedy this problem, but the bad taste and memories do the platform no favors.  Up-to-date information about Tumblr’s uptime is easy to accessed on Chad Scira’s Tumblr Uptime page. (The page’s existence is itself a sign of how bad the problem has been.)

WordPress.com certainly isn’t perfect (for example) nor has it had 100% up-time in the last year, but compared to Tumblr it seems rock solid. A less anecdotal, but still imperfect, study demonstrating this point can also be found at the Royal Pingdom blog.

Advantage: WordPress

Money

If you blanched at the suggestion of money, let me assure you, both WordPress.com and Tumblr are essentially free. Free to write on, free to publish on, free to be read on. But that’s not  all there is to it.

One of the best things about Tumblr is that it doesn’t yet have to make money, flooded as it is with venture capital dollars. One of the scariest things about Tumblr is that they don’t yet have to make money, flush today with venture capital sure they can eventually “monetize” the service. What I’m saying is: Tumblr currently lets you run whatever theme you want, on whatever domain you want, using as much space as you want, without ever having a single ad on your site and all for free. While this is clearly great today, some day its venture capitalists will want to see revenue from all the popularity, and Tumblr will have to find a way to make money. Something will inevitably be lost in that transition.

Automattic, the company that runs WordPress.com, is plenty profitable. And a large part of that is charging for almost all of the features mentioned in the last paragraph. Using CSS to style your WordPress.com blog the way you want is $15/year. Ensuring no ads are ever displayed on your site — WordPress.com interjects them randomly, usually to people coming from search engines — is $30/year. Five gigabytes of extra space is $20/year. These fees are hardly exorbitant, but they aren’t zero, which is what Tumblr is offering today.

Advantage: Tumblr, but the victory may be temporary

Random Bits

Tumblr supports tagging, but not all themes do. WordPress.com supports both tags and categories, though their categories work most like Tumblr tags, showing only results from your blog. (This is a place where one may prefer WordPress.org, as both work for just your blog with self-hosted WordPress installs.)

WordPress has comments by default. Tumblr doesn’t. Disqus is probably the most popular way to add them to Tumblr.

Tumblr creates pretty archives pages, but they’re slow to load and I’ve never found them all that useful. WordPress.com only offers access to archives in the sidebar by date or category, which I believe is even more useless.

In Conclusion

My judgements have ended up in about the place they were last time. For sheer comprehensiveness and ease of use, Tumblr still wins. It’s a beautiful tool that can be used in myriad ways and while reliability is currently a real concern, that is likely to wane.

WordPress.com is a better overall platform if you’re looking to do blogging the way it’s been done for nearly a decade. It’s more robust, has more features, and is very stable. It’s got the best post-writing interface of anything on the market.

And so, the TL;DR (Too Long; Didn’t Read, for non-internet people) version of this review is this: if you know and like people using Tumblr, it’s polish and community are unchallenged by WordPress. If you’re just looking for a way to write things on the internet, WordPress.com is still the best thing available.

It has been more than two years — that thing they say about years going faster as you get older is true — since I published a post here. Quite nearly as long since I did anything at all on this site. I can’t say that I’ve really missed it. While I do sometimes enjoy making things using internet languages, I’ve never had a degree of mastery that makes that making a constantly-fun thing to do.

Lately I’ve been itching to be better are this whole web design and development thing, but that doesn’t mean I miss the 20 minute hunts to realize I forgot a semicolon. (This may not be a problem you face frequently, greater master of the coding arts, but its one this distractable newbie has faced many times.) But whether I was missing this aspect of the web or am just hoping to be better at it, the best way to remedy either of these states is to do it more.

And so I’m hoping to do here what I did on my essay-based blog about a year ago: set myself hard and clear deadlines and hold to them. Since I resolved to publish once a month over there, I’ve not missed. Much of the stuff was hard to make myself do, competing as it was for my non-infinite free time against massively enjoyable and very easy things. Compared to the other things I do with my free time, writing’s hard work. So is coding. Even CSS is hard compared with all the easily accessible and fun alternatives my privileged life presents me.

But I mean it. It is now resolved that on the first of the month I will require myself to publish a post at this blog. Some of those will doubtless reflect 35 hours of dinking around in text editors and FTP clients. Others will probably be just an interesting thing that I thought of that seemed relevant to these topics. But in either case they will at least represent some small effort to be better at this “web thing”, and so I’ll get better, even if only at a crawl.

This site is no longer dead.

Weeks have a way of getting away from me. Last weekend I was thinking I’d get a post up about my first WordPress plugin, a stand-alone implementation of the Kaleidoscope Mini Quilt, by Tuesday. Suddenly I look down and realize that it’s Sunday and I’ve not written such a post and not updated the plugin’s page beyond a goofy first draft.

If you’re familiar with Kaleidoscope, you know it’s most unique feature is the algorithm that takes the date a post was published and determines a color that, based on some vague ideas of what colors fit what time of year, seems appropriate.

My original implementation of that was a large quilt-looking series of patchs that you can find on my archives page. And while I do like that — and the fact that it gives post names as well as colors — it requires someone to create and click to an archives page to see the best use of the algorithm.

The Mini Quilt was a way that I could have the quilt-looking array of posts, but offer it on every page of any WordPress blog, regardless of the existence of an archives page.

Well, I like the Mini Quilt, and I got a few requests from people who liked it too, so I built a plugin to allow anyone to add it to any widgetized WordPress theme. If also features simple but useful controls that allow you to quickly change patch size, and the number of patches in it to fit any size and show any number of posts.

To use it, you just need to search for the Mini Quilt plugin from inside your WordPress dashboard and install it (still from your dashboad — you’re using WordPress 2.7+, right?). Once it’s installed, activate the plugin and add the widget to your sidebar. It couldn’t be much simpler.

If you’re looking for more information before you take the above steps, you can try the plugin’s page here at Ikiru Design, or at the WordPress plugin repository.

Are, in rough order of nobleness:

1. Because no one else has made anything like this before and I’m sure it’ll be awesome.
2. Because no one has ever combined these feature sets and the combination will be legen — dramatic pause — dary.
3. Because this platform needs this type of software.
4. Because my version will be way better than all the others.
5. Because building it will teach me something.
6. Because I can do it too.

I wrote this back at the end of May 2008 and didn’t publish it. When I thought about posting something similar a few days ago, I was surprised to find this nearly complete set of thoughts. I’ve decided to post this version, and will probably add some further thoughts on the topic soon.

For better or worse, Cascading Style Sheets are meant to cascade. That means if you style an <h1></h1>, all thing elements enclosed in <h1> tags well inherent that h1 style. This is both incredibly useful and incredibly troublesome.

It nice that if you really do want all your <h1>s to look the same. The cascade assures that they do regardless of the <div> they’re under or the classes you’ve given them. It’s a problem because when you absent-mindedly use an <h1> tag without remembering that you’ve styled the attribute, you can get some wonky looking stuff.

There are two basic means to deal with this reality: containment and a laissez-faire “let it cascade” approach. The first has the advantage of meaning that you never accidentally have things cascade, but the disadvantage that your stylesheet may well end up incredibly verbose. The latter has the advantage that when used correctly it can give you surprisingly brief stylesheets, but while composing that sheet you may well fall victim to the aforementioned surprise cascade.

Before we get too far into the analysis of the problem, some basic understanding. A containment strategy will wrap everything in every ancestor class all the way down to the exact element you’re styling. This assures that you never have a single style cascading in an expected way, and will generally yield something like this:

#container #content .post .entry p {
margin: 1em 0;
font-size: 1.2em;
font-face: "Times New Roman", Times, serif;
}

Conversely, a cascaded style you only define what you’re styling in a loose and primarily pragmatic manner. The above might come out simply as:

.entry p {
font size: 1.2em;
}

This obviously assumes that face and margins were defined elsewhere. And though it’s not always going to be true, it’s a realistic possibility with a full-fledged cascade.

From a simple length perspective, there’s reason to assume that the latter method is better. But you never know when you’ll realize that you’ve already styled <p> to include font-size: 5em; or some such nonsense. In this case — and this is a unique problem for those sizing thing in ems — you’ll get a font size of 6ems, or around 60 pixels, certainly not what you wanted.

I’ve got a gut-level aversion to verbosity where it’s not necessary. But I don’t like being surprised by unexpected cascading bits either.

There is, I think, a way to split the difference. A managed cascade can allow for a reasonable number of “presets” while still leaving sufficient room to avoid the accidental cascade. Though I still think that browsers welcome movement away from crude text resizing and toward zoom will eventually render the use of ems for sizing completely obsolete, that day isn’t here yet. (And if it were, not all the issues in the containment versus cascade battle would be resolved.)

So for now, I think it’s best to contain as much styling as you feel is reasonable, while allowing some things to cascade. It’s an unconscious working assumption I’m sure more than a few designers already use, but it’s a conscious one I’m certain I’ll be helped by.

I’ve been thoroughly neglectful about updating this blog over the last few month.

And though I earlier said I didn’t want to post about every release, I feel people might actually want to know that I have released a new version of Kaleidoscope at the WordPress.org Theme Directory.

It supports both threaded comments and pagination. I actually forgot about the existence of “sticky posts” until after I uploaded it, so I have no idea what, if anything,  needs to be done to support those.

It’s not the polished version I’ve been hoping to make, but it functions well for most purposes. And it offers support for the most anticipated features of WordPress 2.7, so I’ve no doubt that despite its shortcomings it’s worth releasing.

Just a note for those looking for threaded comments: you need to enable them (In Settings>Discussion) before you’ll see them. They’re turned off by default for the sake of backwards compatibility.

UPDATE (19 Jan 09) — In a heretofore unprecedented move, I actually dropped an even newer version yesterday, and it’s available. Major highlights: basic sticky post support, and lots of styles for obscure situations that no blog but the example at the theme directory is very likely to try.

Over the weekend, I decided to finally install a copy of the WordPress trunk — that’s the currently-being-worked-on version for those not familiar with the term. For need of something to write on that new installation, I noted my first impressions of it. It seems relevant to share as the WordPress team is now soliciting advice about its menu structures.

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.

I think the quip, which I most often see attributed to Thomas Fuller, that “All things are difficult before they are easy” is so clearly borne out by debugging that the truth of it cannot be doubted. You can easily spend minutes, hours, even days bashing your head against a metaphorical wall only to notice that a misplaced colon — which you of course, didn’t realize was misplaced — was the cause of reams of unnecessary pain.

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.

I have mixed feelings about posting whenever a single theme is updated, but this is a pretty big one. And it’s also worth noting that the WordPress Themes Directory got it up less than 24 hours after I uploaded it. Given the large lead time that was needed for 0.7.6, I was pleasantly surprised to see that. So anyway, the most important changes are, in a particular order:

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.