Defining a perfect blogging tool
"Metafilter" Matt Haughey just finished migrating one of his blogs to a new back-end, and the experience has left him with a lot of smart thinking about what the perfect blogging tool should be like:
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.Link
the latest
latest episodes
Then perhaps a large, influential group of bloggers should get together and lobby for a standard to be created and put in place by people that make blog software.
Now who could help with this... *ponders*
Not to mention the fact that most blogger's image and formatting systems are about as advanced as a ten-year-old WordPerfect shell. You have to go into the HTML at every turn to fix things.
What Clumpy says is true, but I don't necessarily think this is a bad thing. I learned more about html fromblogging with blogger than I ever would have otherwise, being a non-techie.
Hurray for open standards! This is a perfect example of why we need the Open Document Format.
I wonder if there isn't some kind of migration plugin or helper that would facilitate moving to another system though. Especially the permalinks, those are pretty easy to fake: use .htaccess to rewrite to a catcher script, use a db lookup to translate to the new page, issue a 301 for good measure and forward to the new page.
This is why I like Twitter. You can post stuff via a web interface, an instant message or SMS. And thus you can post from pretty much anything.
And while microblogging is probably a bit small for any commercial blogging project, it's perfect for the typical personal ego stroke.
@krisjohn but this is about data export. As far as I know, twitter doesn't have an import or export capability. Especially not a generic import utility, since twitter is limited to what? 256 characters? Also, a twitter export would be nothing more than one big timestamped file. A really trivial export format is all that's needed.
Blogs on the other hand have become more complicated with permalinks, tags, comments, comment threads, posts, and the like.
Really though. Isn't this what XML is/was supposed to save us from?
Atom! The Atom syndication format is not only XML, but an Internet RFC exists for it, making it pretty much a "standard". Export to Atom, import from Atom. That handles the content issue, only, though it can also address the URL scheme issue as we should expect the Import tool to deal with that. The various template conversions I'm not so sure about, though I believe it could be done.
Asking to change your engine every couple of months is like asking to change your syntax every couple of months.
The object or verb before the subject putting to do this for instance is one way.
After all, it's just a simple transformation, right? Why should it be so hard?
There is no grand unified best system for representing even the kinds of limited universe of knowledge blog schemas represent. For this reason, unified standards are always orders of magnitude more complex than any single one of the things they try to unify (I give you SGML and DICOM as examples.) Anyone who could deal with such a complex standard would be able to write their own HTML from scratch using a hex editor.
I have two years worth of wordpress I'd like to get over to my blogger without having to learn SQL.
Tom @9: Only the code developers would ever have to deal with the complexity of the proposed blog-neutral standard. You develop a blog-neutral XML schema, and then develop translators that write out the neutral format to blog-native code.
Then you create a client GUI in which the users do their authoring. When you hit Post, the client does the translation and sends the appropriate code to your blog using the parameters you specify. To change blogging software, just change the parameter settings. The developers could even create predefined output parameters, and the user could just select Wordpress or Blogger or whatever from a menu.
You could use the same client to translate existing blog data into the neutral language, and then into the target language.
I'm a technical writer, not a code developer, but I've worked on projects that involve doing this sort of thing with CAD and PLM data (which I'm guessing is a lot more complicated than blogging software), so I know it can be done.
It wouldn't necessarily solve Matt's permalink problem, but one step at a time, eh?
Atom with XHTML and associated extensions will certainly get you a long way with core content description. But there are areas of CMS data that aren't covered with adequate detail. There's also the variation between what different systems actually support.
For open-ended flexibility the obvious choice is RDF - it was designed explicity for Web data after all. I'd expect there are standard vocabularies for 95%+ of what's needed: SIOC, Tag Ontology, FOAF etc, any new terms needed can be invented and aligned later as appropriate.
(An Atom/RDF mapping is in progress - Atom's inherently (Semantic) Web-friendly as it uses lots of URIs).
If this article makes you say "this is why i like working with ", you haven't understood the article ...
"Export to Atom, import from Atom." is a good start, but not a comprehensive solution. Well, yes, import tools ... there's a problem with adding automatic conversion stuff to import/export tools: You're overcoming a sort of impedance mismatch between different systems, and that rarely works perfectly. So with each additional migration, a few small things become a wee bit more unsightly (using some 'neutral intermediate language' would add even more steps and therefore wouldn't exactly help here). And the oldest parts of your archives, which you want to keep around but not actively maintain any longer, slowly degrade. Hence the very sensible suggestion from Matt to store everything in a format that is compatible with multiple tools without such conversions.
When you present this idea to the maker of some major blogware, they'd certainly recognise that it is a good one, but they might still be wary of implementing it. Here's why: coming up with a comprehensive, all-encompassing solution takes time and effort, hence money and resources that could be spent on improving just your software. And once you've rolled it out, nothing stops your competitors from reading your lovingly crafted, detailed documentation of this new open standard and implementing only the import side of it. So now your users have the option of easily becoming their users, but not vice versa. It just seems a bit dangerous to be the first one to move.
I'm sure I'm missing the point, but isn't this just the thing apps like BlogJet solve?
Nope, BlogJet just lets you prepare posts in a way that is meant to be user-friendly (and it probably is, I just haven't tried it), and submit them to your blog. What's desired is a way of migrating from one blogging software (i.e. the server-side stuff!) to another one and have the new site behave exactly like the old one (i.e. all content, including tags and whatnot, is carried over 1:1, and even the URLs are still exactly the same, so no links are broken).
Standards appeal to the logical mind... at first. But in the real world, standardization is so difficult and so fraught with politics and complexity that it is rarely economical.
It's seldom about the end-user anyway.
Ford started with "standardized parts", but over the decades most auto manufacturers found that wasn't the ideal way to maximize profits. Eventually they made cars so complex that very few end-users could repair them.
Standards are most valuable when an industry is just starting up. It's almost an accident that MIDI (which lets musical instruments talk) emerged when it did. People complain about how it hasn't been updated -- but the odds that it could even be created were quite low. Someone had to work very hard selling the idea to get competing manufacturers to agree.
I remember when HTML was a standard. Then Netscape and Microsoft worked hard to "fix" that.
Sorry Matt, but ... it was just a wonderful dream.