I’ve been doing some major codesmithing on my Wordpress templates in preparation for releasing them into the wild as an official Wordpress Theme! In the process I’ve made the year pages (e.g. /2007/) generate truly beautiful HTML, not that a single damnable person in the world cares (there are new easter eggs for potential carers just in case...). Besides that, I’ve made new design discoveries:

Pagination considered harmful

You know how big websites like to break up their long articles into multiple pages to force you to click many times to read through the whole article, in order to place a larger acreage of adverts in front of you? It’s called pagination, and it’s usually bad.

Newspaper articles, blog posts, and almost any other kind of textual content is, bytewise, very small. A 10,000 word essay is less than 60KB of HTML and can be quickly downloaded, parsed and displayed even on a rusty 2.5G cellphone. There is no technical reason to paginate. Since sane websites invite their users to scroll up and down, there is little design reason to paginate either. As far as I can tell, there are only two reasons to paginate web pages:

1. If you’re building a web-interface to a gigantic database like, say, Google, or Flickr, it’s easy to formulate queries that return hundreds of millions of objects, so some sort of throttling is desirable.
2. If you’re a business, you probably like forcing the user to see more adverts.

Are there any other reasons? I don’t think so. Here are some good reasons not to:

1. Users are annoyed when their reading is interrupted by having to click.
2. You can’t do a full-text search on the whole article.
3. Your PageRank is spread out across all the subpages.

That’s why I’ve removed all pagination from my Wordpress theme. The most egregious example of this is the linkblog, which shows every single post. Perhaps this will flood something one day, but posting at my current rate for the next 30 years would still generate less than 400KB of HTML.

The logical conclusion might be that all content should be stuck on the root page and you should do away with URIs altogether, but aside from that being plain madness, it would only work if all the content had a common theme. Here’s an example of a very long, well-structured document; it wouldn’t make any semantic sense to have the authors’ cat photo database on the same page. The lesson is this: start a different page for a different subject, and use the same page for the same subject.

Photo galleries and permalinks

I experimented briefly with an integrated photo gallery. Gallery2 is the latest, greatest, biggest, heaviest incarnation of good old Gallery 1. It does all kinds of amazing things relating to displaying photo albums on the web, but it fails completely to generate sane URIs. Here’s an example:

http://james.lab6.com/2003-02-11+chs+bits+and+pieces/DSCF0461.JPG.html

Yuck. For a start, there’s a useless .html hanging off the end. Even worse, deleting said html doesn’t serve you the image as a JPEG file. To get that, you must visit:

http://james.lab6.com/d/24-1/DSCF0461.JPG

• The /d/ is part of Gallery’s last-ditch attempt rescue its horrific default URIs (which I’m not even going to mention) using mod_rewrite. Slideshow URIs start with /v/ and the “add comment” form URI starts with /c/.
• The 24 is the item ID, a globally unique integer tied to every individual image which the developers will “try not to change” in the next version. That ain’t reassuring.
• The -1 is another hack to force browsers to reload the image if it’s changed.

The official solution for people who wish to have unchanging URIs is the “Permalink plugin”. That lets you assign an image, or an album, a short globally unique slug which you access at:

http://james.lab6.com/f/mycoolphoto

That’s beyond diabolical. It’s unexplorable (navigating up to http://james.lab6.com/f/ gets you worse than nowhere: a PHP error), it still has useless /f/ cruft in it, and you have to create permalinks manually for every single image you want to have a permanent link. Which is surely all of them.

Worse still, some of these issues have been on Gallery2’s bug tracker since 2005, the gallery-devel mailing list is alarmingly bare, the gallery-core mailing list isn’t public, and the release schedule page has been abandoned. These are not the life signs of a healthy open source project.

On a practical level, integrating Gallery2 into an existing Wordpress blog is done via WPG2, which itself takes a dim view of Gallery2’s mod_rewrite shenanigans. The fact that WPG2 has a Release Compatibility Matrix (incomplete and out of date, of course) tells you all you need to know about the problems inherent in getting two content management systems to play nicely with each other. It’s simply not tenable to synchronise the versions of three different software packages when they’re all so picky. Moreover, third party Wordpress plugins cannot be relied upon when it comes to building core functionality; they have an alarming tendency to become suddenly derelict.

So Gallery2 is not yet ready for the long-term web, which is a real shame as it’s otherwise the clear leader of gallery apps. The only thing that comes close is Flickr, and that’s got its own two special problems: uploading and downloading.

In 2005 I bought a Flickr account and started uploading photos. Tagging was good fun and all, but their uploading tools were rubbish, tailored to users who upload one or two photos at a time. I checked again a week or two ago, and they’re still rubbish. For users who already have thousands of photos in hundreds of albums, it’s a hassle and causes a lot of duplicated effort.

As for downloading, Flickr is quite liberal about embedding images, but does its best to keep your data inside its walled garden. There is now a tool to export all your photos, but I don’t know what it does with tags and comments. I expect they are lost. Thus is the nature of the walled garden exposed: you are in somebody else’s home, and the longer you spend inside, the harder it is to get out.

I stopped using Flickr when it became infeasible to continue bulk uploads, which is to say when the sweet taste of easy content sharing was overpowered by the bitter taste of vendor lock-in.

Social bookmarking and Digg icons

I added a little Digg icon on the blue sidebar for every page. After noticing precisely nothing for 5 days, I have come to agree with this post, in particular the second comment:

You see so many blogs that are all nascar’d up with these things.

There’s another comment by somebody who runs one of the social bookmarking sites:

4. People who are likely to save the current page as a bookmark are not random readers and visitors, but rather the regular users of the service. And guess what? They already have those bookmarklets and extensions handy in their browsers!

Nailed.

Bye-bye icons. I retain my grumpy old endorsement of Web 1.0 and my original design inspiration.