in ask the readers

Bottom line, all weblog apps suck in some way

I spent most of the weekend elbow-deep in weblog archives and templates, trying to update my site to MT 4.01 and WP 2.3.2 (the former required the latter to export/import). After several hours, I started looking at Expression Engine and Tumblr and even considered Blogger to run this site. After getting fed up with shortcomings, I thought I’d describe my dream weblog engine instead.

For anyone that designs and builds a blog app or CMS, consider the following as typical use cases and design technology around these experiences. As a user, it feels like blog app design is instead about picking technology first and asking users to design their usage around that.

Admin Backend

When you’re working on a blog post or setting up a blog, the backend of the application should be as close to the database as possible. A blog backend is almost by definition very low-traffic (especially with a single author) and there should be no impediments between having a thought and pushing a publish button. Most every app I’ve used is too slow in this regard, so even if you have to use another technology or application design from your blog publishing core functions, keep the backend as fast as possible.

Here’s a design goal: writing a sentence, pressing publish, and seeing it live on the site should take a handful of seconds. Writers should never have to stare at a spinning graphic for a minute as they wait for the publishing engine.


Here’s how most designers interact with templates: They work on a layout for a day or two (in photoshop and/or plain HTML/CSS), implement in whatever blog code the system requires, then they tweak it 100s of times over a few hours until it is done. Then it stays the same for anywhere from three to twelve months until a new theme/design inspiration comes along.

I personally like tweaking templates in a text editor, directly interacting with files on the server (as opposed to within a web app window, having to regenerate to see changes). I also prefer not to see the guts and/or technology of the blog CMS. Abstract it with output tags that don’t require knowledge of programming languages. Keep application logic out of the layout whenever possible, and allow minor tweaks in simplified tools (clicking options in a widget editor) instead of requiring template changes.

Simplicity is golden. The fewer templates, the better. Blogger wins in this regard by allowing an entire site to be laid out with a single template file and some CSS. MT4 is kind of a nightmare in this regard with seemingly dozens of templates, sub-templates, and sub-sub-templates that can be tweaked.

My ideal template engine would be as simple as possible and allow me one general template to control layout, maybe a few specific templates for specialized output (an entry with comments is different than a list of archived posts), and allow for fast tweaks until the design is done. When a template is “done” convert it into some stable package the CMS can use and that I can share with others easily as an archive.


There really should be a standard of some sort that blog CMS companies can agree on for export and import. Users of blog engines shouldn’t be hostages to their applications. Data exit and entry is problematic in everything I’ve used and it’s a shame. Blogging is supposed to be fun and I prefer to be agnostic about what tools I’m using, so it’d be nice if I could change blog engines every three months without too much friction. I won’t even go into how every engine has its own URL scheme — it’d be nice if I could keep my permalinks forever, even as I change blogging apps.


Every blog engine seems to suffer not only from poor documentation, but also extensions, template designs, and tutorials are almost always spread out across multiple sites (often out-of-date). If I download a blog CMS from Site A, plugins for it are on Site B, but they link to Site C where you can download things (but documentation for the plugin is back on Site B). Every blog engine seems to also have internal battles between “here are the free tools for your blog” and “here are our professional services for your blog” that leaves me wondering where to find more info or extensions after I download. Then there are random people that just setup galleries of plugins and templates that often rival or surpass the blog engine company’s version of the same. It’d be nice if there was a way to find those as well.

My ideal blog engine company would hire some seasoned blogger and technical writer to be a documentation czar, keeping docs up to date when new versions are launched, produce screencasts for introductory users, and provide complete documentation at a stable URL that applies to every version of the product. If an outside site does a better job of collecting and offering templates, a documentation leader should recognize that and link to them in highly visible places. There doesn’t seem to be anyone internal at these companies fighting for the users to make sure they can keep being informed about how to best use the product.

Server Load

I’ll admit I like simple, live code editing of my template files (as described above) when I’m tweaking a design, and I love fast admin screens that let me post instantly, but once a post is up, it’s just text on a web server and should exist as a flat file. I’ve clicked through way too many digg links and popular links only to end up at database connection errors or too many user errors on servers that can’t handle the load. I know building a perfect cache is hard to do, but failure of your site at the most visible and important time for you should never happen.

Anyone got any other ideas of how to build the perfect blog application?


  1. I’ve been evaluating “modern” CMS packages in the past few weeks, and find my thoughts echo a lot of what you have to say.
    Another weak spot I’ve noticed is URL/URI design. Most packages offer some kind of “clean” URL options, but they seem glommed on, with a focus on search engine gaming/optimization rather than encouraging/enabling smart URL schemes. For example, the default Joomla “sample data” install has a few URLs that look like this
    Certainly keyword friendly, but hardly smart information architecture.
    Tangent Re: slow admin applications. Have you tried the various XML-RPC Desktop weblog clients out there? Once you have your site configured, it as simple as “writing a sentence, pressing publish, and seeing it live on the site in handful of seconds”.

  2. Hey, I really think that wordpress is the ultimate compromise between the ease of blogger and the depth of MT.
    I find that anything I want to do in WP has been done before and is packaged in a plugin (some much better than others).
    The community is rich and you can blog from anywhere using email and RSS importing plugins.
    Tumble blogging is also something worth looking at if you are really into small and fast and simple.
    I love my tumblr,
    It imports a specific tag I can give to RSS posts in googles reader and, with the bookmarklet, becomes a great re-blogging tool.
    Give WP another chance!

  3. I lost nearly a month of my life trying to figure out how to use UserLand’s presumably built-in tools to export my Manila site into a format usable, ultimately, by WordPress. It wasn’t until I gave up trying to RTFM trying to do what UserLand’s tools claimed it would do, and ended up begging Jason Levine to have pity on me and generously apply his home-grown script to translate the site to MovableType (as a go between) that I made any progress. That was, what, 2004?
    There are still weirdly formed things in my blog that, had I infinite time and energy, I’d go back and fix. I think I’m in the minority for the thoroughness of my migration. Most of the people I know who had Manila-based sites ended up either abandoning them, or plunking them in a kind of backwater, and not fully migrating them forward.
    I wholeheartedly agree that there should be a kind of back-end Esperanto.

  4. As a member of the Habari Project, I hear you loud and clear. We’re trying very hard to learn the lessons from other blogging applications and to avoid them wherever possible as we build our next-generation blogging platform.
    Thanks for taking the time to document your frustrations. It’s opinions like these that help us stay focused on what we need to do. Do please feel free to join us, and to help us stay on track!

  5. I think the only thing that we need here, is an official standard how blog/cms content should be stored in a database (or content in general).
    WP, TP and MT should sit down and make a standard.
    As for the template design: I think it is fine how it is. Maybe HTML 5 will help there a bit, but designing templates will never be 1,2,3,done.

  6. I agree with Matt’s comments. As someone who migrated from MT to WP, and is curious about MT4, here are few other thoughts.
    1. The markup language to be used in blog posts, whether it’s Markdown or Textile or whatever, has always struck me as not quite ready for prime time. More specifically, the implementation of these: I’ve always wound up hand coding HTML for anything beyond the basic, and the way the markup interpreters deal with mixed-in HTML has been problematic.
    2. Custom fields. I know WP has this, and I believe MT4 has it, but support for custom fields needs to penetrate to the publishing API, and ideally would be more extensive, allowing for, say, simple calculated fields etc.
    3. I much prefer the “atomic” template tag approach MT uses for the most part, but it breaks down for some things—the complexity of the comment-entry area cries out for the “molecular” approach in WP—and being able to mingle code and template tags, while perhaps sloppy, is powerful. And it bugs me that feeds are not templatized in WP.
    4. Update mechanism. We need a way to discover and install core engine, plug-in, and theme updates within the admin interface. There are probably a raft of reasons why this is a bad idea, but still.

  7. other things that suck about the major self-hosted blog CMS’s:
    — media handling (running a photoblog is like poking yourself with a stick repeatedly in the eye)
    — memory footprint (ever gotten a lot of comment traffic to your blog? good luck!)
    — upgrade-path (do you use any plugins? do you want to upgrade to the current version of your CMS? most likely you are shit out of luck.)
    — integration with other services (it’d be great if there was some universal content syndication specification for moving content between various providers. oh wait, didn’t someone invent that in like 1998?)
    but templating hassles and the molasses-slow process to actually put up a post– those are definitely the two worst things about the present systems.
    what i’d love to see: Tumblr’s ease of use combined with WordPress huge community of developers combined with MT’s sophisticated approach to publishing. my guess is it’s never going to happen.

  8. I’ve been using Tumblr because it’s really quick and easy. That said, ExpressionEngine will address many of your goals. It takes a little ramp-up, but is ultra-flexible and easy to publish with.

  9. “UserLand addressed migration from Manila via XML export almost seven years ago. UserLand also lead the way with the MetaWeblog API. And the latest candidate, RSS? Yes, UserLand again, starting about ten years ago.”
    UserLand was ahead on the concepts but way behind on their implementation. I’ve moved blogs into and out of Manila and Radio UserLand. The data’s incomplete and there are a bunch of character encoding issues that must be resolved individually. Movable Type and WordPress are much, much better at this process.

  10. Garret Vreeland has also been moving his blog back and forth between MT, WP and Expression Engine and ultimately decided on the latter. His write up is worth reading for the pros and cons of each system.

  11. Design. Design. Design.
    You can have all of the best features in the world but their totally useless unless the design makes those features usable as well as functional.
    This is something I’ve been noticing for years as software evolves. You’ll have a great new version with “tons” of features, yet at the same time the usability of the app goes down the tubes. All of the talk lately around the bloatware that is Microsoft Word is a good example of this, as people are dumping it for simpler apps. From another viewpoint, look at what an excellent design makeover did for Firefox.
    Therefore, I really don’t care how many features you’re blogging app has, the question is “are those features easy to use and more importantly easy to setup?” For simple get up and go, I still find Radio Userland has a great balance of functionality and usability even today (and I even wish some of it’s features were in current blogging software). Right now I utilize Squarespace as my primary platform, again due to it’s balance between functionality and simplicity. Tumblr is without a doubt an excellent example of a very usable app but I wish it would add a bit more functionality to balance it out.
    One of the most important features is data portability and as you pointed out, it’s not just about moving the data but maintaining a seamless experience with that data especially as we move towards creating a distributed filing system with it (i.e. images on Flickr, videos on YouTube, etc). Therefore, maintaining your links is critical for this to occur. That’s why I’d like to see the ability for all services to offer alternative virtual mapping via your own domain.
    So I could map my subdomain of to my Flickr account and choose my own URL structure as an alternative over Flickr’s proprietary URL. Sure their proprietary URL is fine if you’re using their service internally (i.e. chatting in the social network) but for maintaining data connectivity on your own site, we need to have some way to maintain these persistent URL links to your data.

  12. The problem with deciding on import/export data schemes up front is that you there’s little room for extension or flexibility in a way that retains interop across tools – tools that may not yet even have been invented.
    For the Web environment you need a Web data language – that’s what the Resource Description Framework is, it’s designed to support interop across the distributed environment. Check out SIOC for a blog-related vocabulary.

  13. This is interesting. I decided just under 2 weeks ago that I was annoyed with WP so I’ve started building my own. I shall watch the comments here with interest :)

  14. Very good post Matt, I use Joomla and I would have to think of the nightmare if I ever had to move CMS. Joomla does seem to be slower than the other tools out there such as WordPress but does have the massive community which is why there are so many cool modules and components you can install.

  15. I’ve got to throw a plug for Textpattern in here. – get it – plugins – themes – in depth documentation wiki and tag library with descriptions and code examples
    Best of all, you don’t need to be a php master to use it. Just HTML and CSS with a sprinkling of txp: tags.

  16. What’s really needed:
    – Drag and drop template design and modification
    – Visual theme editing with drag and drop functionality
    – Automatic install and updating
    – Universal plugin architecture

  17. I’ve hacked up my copy of MT 2.66 so much that I can’t easily upgrade anymore… not that I really need to.
    I’ve been tempted to strip it down even more and release it as an MT-lite sort of thing, assuming the Open Source-ness of MT applies to older versions as well.
    I wonder if anyone would use such a thing.

  18. I agree. Trying MT401 was a disaster for me.
    I thought it would be better to launch new stuff on 4, but it was so hard, I think I’ll just put it on 316.
    Applogic in the templates to save me from editing (-???!) 4 main types, or my own included php/mt modules instead? Massive Balkanization of all backend functions and views.
    Thinking seriously of moving everything to WP in future.
    I wish there were a User-Configurable backend interface (for MT) analog to XP’s new/classic mode for start menu, control panel, etc. Ie: 316-style vs. 401-style

  19. The only way I found which is close to what is said above.
    * No database.
    * XHTML (or whatever file formats neeeded),
    * scripts (bash, python, XSLT) to make them XHTML, create index, feeds, extract categories, etc.
    * another script for rsync under ssh with the server.
    it results in: No dependencies. Close from the content. Plain control of everything. Flexibility in moving platform in a few minutes. A full copy of the site on my laptop. A local server on my laptop to check the drafts and navigate the site.

  20. Karl, the functionality of that almost sounds like Radio Userland. For example, if you had a copy of Radio Userland on your laptop, you’d just need a net connection to post to your site. Moving your site is easy as well since it’s all static.
    Only thing it can’t do is comments though (that is if you wanted them). You’d need some sort of online service or script to do that.

  21. Have been playing with Symphony recently, which although at first looks bare, is incredibly powerful. PHP/MySQL, but the eventual output is an XML document for each page (generated by creating your own Data Sources). These are then transformed using XSL into clean HTML markup.
    Although the default install is blog-esque, you can define your own database schema (in the Sections area) which sets the fields/datatypes for your content.

  22. I suppose that Soapblox (.net) is really a community/group blogging software. But it is close to the database. We never get database errors. All the “templates” work the same.
    But it really is set up for community use what with ratings, and nested comment replies and registration etc.

  23. i’m glad to know that if mister haughey, seasoned blogger and all round smart person is having a tough time of it, i shouldn’t feel so bad. i tried upgrading MT from 2.6 to 4.
    and gave up.
    here’s why:
    before downloading mt4, i did my research on upgrading. in “10 reasons mt4 will rock your blog“learning moveable type says:
    ” Arvind Satyanarayan:
    @Anthony: It will be extremely easy to upgrade your MT 2.64 blog to 4.0, you don’t really need to do any importing as such just upload the new files to your web server making sure they overwrite your old files. MT4 will then automatically upgrade your database for you :) If you intend to use this on a public-facing blog, I recommend you wait until v4.0 is official released (i.e. after the beta test) as there are still some bugs in the system. ”
    Arvind is an author contributor to the learning movable type site, and makes plugins – so you’d think he’d know.
    so i go and do the download off the frontpage of movabletype, follow the quickstart instructions enclosed to the letter, and no go. turns out that checking out the documentation on the website gives different instructions:
    “Upgrading from Movable Type 2.6x and earlier
    Users upgrading from Movable Type 2.6 and earlier wishing to upgrade to Movable Type 4.0 are requested to first upgrade to Movable Type 3.35 and then upgrade to Movable Type 4.0.
    We are making this recommendation based soley on the fact that Six Apart did not extensively test the upgrade process from MT 2.6 directly to 4.0. While technically it should work, and there are no known issues with upgrading in this fashion, we can only offer upgrade support to users upgrading from 3.x.”
    so, as a user of movable type upgrading to 4, it’s up to me to read 3 differing versions of how i should upgrade, and determine which one is right. insane. because i missed the online mt4 documentation, i did the upgrade wrongly, found myself stuck, and the online help forums aren’t answered promptly, if at all. there’s close to 3000 results for the search “powered by movable type 2.63” so you’d hope that the organisation would want to assist those folk and other 2.x versions in upgrading.

  24. I spent an enormous amount of time when I went full time as a web developer to find the best and most configurable platform over a five year period.
    After well over 30 different systems being installed, some repeatedly, and tested extensively, there was one (five years ago) that allowed infinite customizations, because of everything being in templates, not in the core files, and would publish as a page anything in them.
    I did not want a module for menu changes, one example of many. The above are all similar, and overall inconfigurable.
    Movable Type was an exception.
    Then Expression Engine came out over two years ago, resulting from pmachine, which was one of few I hadn’t tried.
    Expression Engine developed into a major player that was, and is, the most easily configured cms on the market. Custom fields, podcasting, member management, fantastic friendly paid support on the forums, fantastic complete and organized docs, image handling including galleries, on and on.
    And like MT, will publish anything put in a template.
    It has to be tried to be believed.
    Movable Type I firmly believe will continue to improve. Each has it’s place, but MT has to be made simpler and stop increasing the server load.
    Proper custom fields have to be built in with database access to the data..
    Simplicity is the key, and MT has been going in the opposite direction, and disbelieving and challenging anyone who disagrees.
    I firmly believe the present MT4 will do Six Apart more harm than good because of being too complex, causing too much server load, poor documentation, and once again breaking plugins and addons from previous releases. Add on the amount of conditionals, and modules inside of modules, it becomes a nightmare for the average user to do anything with.
    I have some hope for MT, but am working 99% with Expression Engine for clients sites now. The reason being, I make a living doing this, and have to have both the most configurable, the most trustable, and most stable CMS available.
    That is EE.

  25. MT4 is kind of a nightmare in this regard with seemingly dozens of templates, sub-templates, and sub-sub-templates that can be tweaked.
    Or flattened. Not that it’s right out front and center, but if the default templates are confusing(I hate them but luckily have no need for them), removing all the includes goes a long way toward making them comprehensible.
    There are valid reasons for the template structure, but I personally think addressing those reasons was taken too far in this iteration of the default templates. But this isn’t the place for that discussion. Anyone interested can join the relevant MT-related mailing lists.

  26. Also, re-reading some of the comments here backs me up. A lot of recommendations based on, purely, technical reasoning.
    Web applications are called so because they aren’t products – there is a reason for this!

  27. Good points raised about the templating systems. There are obvious benefits to taking structured approach with multiple layered templates but if such an approach is taken, a viewing methodology needs to be taken so as to enable easy modification of these multiple templates at once.
    For example, wasn’t it Microsoft Word that had a “master document” feature that allowed you to embed multiple documents in one document and thus edit each independently but in a unified view? If so, it would be nice to see something like this in CMS platforms that have many templates and sub templates. In effect, if I was looking at a specific template, I should be able to click a button and see all the sub templates associated with it in a unified view and edit them individually from this unified view (so as to create the illusion of editing a single web page).

  28. I have done the big move a few months ago from MT 4.01 which was crashing my servers to WordPress and have not looked back.
    I am really happy with the plugins and control they give me in WordPress and after having a bit of a learning curve with the templates with the different markup language I feel comfortable now getting the editing I need done.
    One quick tip that I like is that I keep the same theme on all of my blogs so that I can upgrade all at the same time.

Comments are closed.