A Whole Lotta Nothing

Super Tuesday

I didn't know half the delegates are voted on in less than a week. I mean, I knew a lot of races were happening at once, but half the delegates? That's a quasi-election day right there. This video should help you decide:

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.

Templates

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.

Import/Export

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.

Documentation

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 del.icio.us 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?