18 March 2004

MT Wishlist

With MovableType 3.0 on the horizon, and with prompting from Kottke’s new integrated design, I’ve been doing some thinking about what weblog software doesn’t do. Here’s a short list of some features I’d like to see in the next generation of personal publishing software. Most of these can be done with clever hacks, but the fact that the hacks exist shows that there’s a need that isn’t being met.

Customized Fields

Separating posts in different categories is often not enough for many people. Suppose I write lots of movie reviews on my page. Putting them all in a “Film” category would useful, but I might also want to group them as “Drama,” “Comedy,” “Action,” etc. While MovableType currently allows posts to be assigned to multiple categories, what I really want in the above scenario is the ability to assign subcategories. The most logical way to do this is to create a weblog just for movie reviews. There are two major roadblocks that prevent this from being an easy solution. The first is a lack of customizable fields, and the second is that there’s no way to stitch multiple weblogs together on the same page.

A basic weblog uses just a few fields, such as entry title, entry body, and category. More complicated setups might have extended entries and keywords. Every different weblog has its own unique configuration, and weblog software should adapt accordingly. A book review post might need fields for author, publisher, ISBN, summary, review, and rating. A movie review post might include actors, IMDB links, etc. A linklog might contain fields for link destination, commentary, and attributed site. A blogrol could contain a person’s name, site name, site URL, one-line bio, XFN data, and FOAF link. The config screen for each of my weblogs should let me define and name fields specific to that weblog, and create a template tag for that field, like <$MTCustomFieldISBN$> or <$MTCustomFieldvialink$>.

Pages Containing Multiple Weblogs

While it makes sense to put different types of posts into different weblogs, there’s no easy way to have all of those posts appear interspersed together in chronological order on my main page. Currently, MovableType assumes that the weblog is the basic building block of a page. TypePad allows extra stuff like TypeLists and photo albums to hang out on a page’s sidebar (and really, TypeLists are just stripped-down weblogs without archives, comment systems, or XML feeds), but doesn’t let you integrate this information in with full-fledged posts. Suppose I wanted to keep a moblog but wanted its photos to show up inline with my text posts. What I see is a move away from weblog-centered pages to pages whose content can include posts from any local source. Archives could be similarly organized and both integrated and segregated, so that users could view everything posted in a April 2003, or just photos from that month, or just posts in the “Romance” category whether they’re books or movies.

RSS and Atom fields should be available for all posts within a single weblog and for all posts on the entire page.

Built-In Text Education and Validation

Daring Fireball’s SmartyPants is great. It and Amputator should be built into MovableType and be turned on by default. Encoding ampersands would solve validation problems for most pages. Furthermore, though templates can be easily coded to output valid HTML, a page is only valid if the content of its posts are valid as well. There should be an option to “validate and publish” that will return markup errors before posting an entry if any are found. [Note: a per a strand from Daring Fireball, a post cannot actually be valid on invalid, just well-formed or not. Still MT could check so make sure start tags have end tags and such.]

Cruft-Free URLs

MovableType should automatically generate cruft-free URLs.

Spam Protection

All email address should be automatically hidden from spambots using an approach similar to (or licensed from) The Hiveware Enkoder.

Link Stripping

Comment spam is a problem. Instead of blacklisting IP addresses, we should blacklist link destinations. Links to known porn sites in comments should either be banned or stripped down to plain text.