Categories
Weblogging

You know

..you’ve been writing about weblogging technology too much, when you start to compare it to a washing machine. However, it’s a good subject for the Labor Day holiday because no one is going to read what you write during the weekend, anyway.

Speaking of disconnected, I received an email at my gmail account asking to me to verify my membership request in The Queensland chapter of the Australian Society for Limnology (ASL) mailing group. That was exciting–I learned a new word. Limnology: The scientific study of the life and phenomena of fresh water, especially lakes and ponds.

There’s also an entire page on limnology at Wikipedia. But then, Wikipedia isn’t authoritative, so I can’t believe any of it.

Still, since I was in the area, I looked up ‘washing machine’ and found the following:

Connectivity

Some modern washing machines include USB or Wifi ports to connect to a domotic network or to the Internet.

So maybe my association between weblogging and the washing machine wasn’t too far off, after all.

Blog your laundry today.

Categories
Technology Weblogging

When is a weblogging tool like a washing machine

In comments to my post,WeblogTweaks: Tool Independence Jacques Distler wrote:

There are things that one can do in WordPress that one cannot (easily) do in MovableType. And there are things one can do in MT that one cannot (easily) do in WP.

The day that our tools become interchangeable is the day that one can truly say that innovation has died.

If the developers of weblogging software (and, in the case of MT and WP, the legion of plugin authors that surround them) are not producing cool new features that no one else has, then they are not doing their jobs.

It is deeply wrongheaded to hope for (let alone celebrate) the homogenization of this technology.

Leaving aside Jacques’ equating of tool independence with homogenization, I want to focus for a moment on his underlying assumption about the importance of innovation to most webloggers.

Two or three years ago, innovation was the heart and soul of weblog tool development primarily because most of the functionality to support weblog writing in early times was fairly primitive. In addition, a significant proportion of the people who weblogged then were just as interested in the nature of the medium, as they were in publishing their thoughts online. New innovations almost invariably broke new ground, and generated excitement that caused ripples felt throughout most of weblogging environment. This excitement, in turn, fed the innovation. as those who developed the gadgets and whatnots received plentiful feedback, encouraging them to yet more feats of development magic. It was bewildering and exciting and like flemings to the sea, we flocked from tool to tool based almost solely on innovation.

But then the innovations became to develop costs, such as over-aggresive aggregators that queried RSS feeds by the minute; or spammers blitzing our comments. Seeing our names at the top of a Google search begin to lose it’s novelty, and we stopped paying much attention to articles that talked about weblogging. The demographics of weblogging has changed and today’s average weblogger is less interested in wizbang technology or the coolness of what we’re doing then in having a tool that upgrades without breaking; allows us to reliably write to the weblog and to do so easily and quickly with a mimimum of problems; have the resulting page look good; and not have to wake up every morning and spend time cleaning out spam.

This change in priorities regarding our tools is reflected in recent discussions. A few years back, most discussions about web technology were on this new gadget, and that new functionality–it was all very positive and exciting and even the most technology shy webloggers would be moved to participate from time to time. For the last year and a half, though, most of the buzz about weblogging technology has focused on comment spam and elimination thereof. The ragged echo of voices you hear are tired, and frazzled, and sound more like beseiged castle dwellers holding back a foe, than brave adventurers into new territory.

As for excitement – the last major excitement related to weblogging technology was when Six Apart introduced it’s licensing scheme with 3.0, and Dave Winer closed down weblogs.com. Neither of these events had anything to do with ‘innovation’.

Webloggers are just not as interested in shiny and new as they were at one time. Shiny and new attracts attention most of us aren’t sure we want.

Now, I’m not saying this to discourage innovation, and couldn’t even if I wanted to–the nature of the human beast is such as to always see what is done, and how it can be made better. But most of the innovation in weblogging lately has been directed more at the geeks than based on any real and expressed need of weblogging tool users. This is well and good, too, as most advances in technology are based on putting new and geeky technology out on the market and then showing the people how this is something they wanted all along and just didn’t know it.

But at some point, there must be a connect between the technology and the users, or the innovation is bound to fail. History is littered with the desiccated remains of brilliant ideas that no one wanted.

But I digress. Returning to Jacques equating weblogging tool independence with tool homogenization, and from there, to the death of weblogging innovation. It’s funny, but his statement is an echo of something that I wrote once, a long time ago, about web standards. and Mozilla.

Challenge your assumption that all Internet services are provided by a Web server and consumed by a browser. Challenge your assumption that chaos within a development environment is a bad thing. And challenge your assumption that standards must take precedent over innovation.

Somewhere along the way…standards became less of a means for providing stability and more a means of containment. In some cases, standards have become a weapon used to bludgeon organizations for practicing the very thing that started the growth of Web applications in the first place: innovation.

This old article I wrote for O’Reilly was inspired by the the WSP’s criticism of the Mozilla team’s focus on creating an infrastucture rather than just providing a standards-compliant browser. Stop wasting time, they said. Give us standards compliance and then you can go play.

Thanks to the Mozilla group’s resistence to the outcries of the time, we now have Filezilla for FTP, and Thunderbird for email, not to mention Firefox and all it’s wonderful, marvelous extensibility to which I have become addicted. That time spent on geeky stuff back then has born fruit now and we’re all giddy with the possibilities.

This would seem to support Jacques statement of the importance of innovation not being suppressed, but but not how tool independence leads to homogenization, which in turn suppresses innovation.

Because of it’s focus on infrastructure, Mozilla did lose users, people who switched to other more standards compliant browsers; however, this didn’t stop it from continuing to innovate. And Mozilla eventually did develop that standards-compliant browser the WSP wanted. Now, many of those people who switched earlier are returning to Mozilla, or more specifically Firefox, leading other browser vendors to look more closely at their own products.

If anything, innovation is more closely associated with vendor independence than dependence. After all, you don’t have to work as hard with a captive audience (beer vendors at ballgames have long understood this association).

Making it difficult for webloggers to change tools does not encourage innovation. If anything, more of Six Apart’s recent innovative work–such as dynamic PHP-based pages–came from people switching or threatening to switch, to other tools, than from happy customers politely putting in enhancement or bug fix requests.

No, all that tool dependence does is make people frustrated because they feel trapped into using one tool. Eventually, even if the tool they’re using does improve, they won’t see it, or even acknowledge it because that feeling of being ‘captive’ to the tool becomes a mighty powerful filter that influences their preception of the tool from that point on. Microsoft’s experiences with Windows is a good example of this.

But can tool independence limit innovation, as Jacques implies? No more so than with any other use of technology. Take the washing machine industry for example.

A washing machine’s basic functionality is very simple: provide a waterproof tub; fill it with water; agitate the contents of the tub a bit; empty the water and spin the tub to get some of the excess water from the clothes. All washing machines share this same functionality.

Now, Washing Machine A, in order to capture more of the market share, develops a new machine that allows different temperatures. This generates a lot of interest because we all know that red socks washed at hot temperatures dye other things in the wash, pink. However, the creators of Washing Machine A, in their enthusiasm, rushed their product to market, and it breaks down a lot. Some customers, frustrated by sopping up water on the floor, or holding up shredded nighties, move to Washing Machine B, which has less temperature options, but is more reliable. New customers, hearing that A, though nifty, breaks down a lot also decide to buy B. Other people, though, who have a lot of red socks and really need these many different temperature options, and who sleep in the buff anyway, stay with A.

Still, Vendor A loses customers. Alarmed by this, A improves the reliability of their product. It finds and closes the tiny black hole that is eating up one of the red socks with each load; they slow down the agitation of the spin cycle so that the clothes aren’t beaten until their threads begin to disintegrate.

Some of Machine A’s old customers that switched to B move back to A because of the increased reliability. New customers, hearing that the old problems have been fixed, buy A this time instead of B. While this is happening, though, Washing Machine vendor B, inspired by A’s customer’s interest in access to different water temperatures, and alarmed in turn about the loss of its own customers, adds an improved temperature control, but separates the temperature control by wash and by rinse – pretty exciting stuff.

Some of A’s loyal customers that stayed through the reliability issues, see ’shiny’ and ‘new’ with Machine B, version 2.0, and make the switch. So Vendor A adds a new innovation–a device that adds softener at the right time so you don’t have to do it yourself. Machine B counters by providing a glass front so that customers can stare at the clothes as they go through the cycles, mesmerized by the action.

About this time, vendor C, who has been focusing on televisions, sees there’s a lot of money to be made in dousing clothes with water and shaking them up a bit. So they enter the market, adding yet more incentive for innovation. Seriously alarmed now, Washing Machine vendor A, in a fit of inspiration, and encouraged by government tax rebates, introduces a new model that is very energy efficient, hoping to take advantage of ‘green’ interests. Unfortunately, the new model costs signifantly more than other models that are less energy efficient, but providing the same functionality, and A takes a real hit in the marketplace.

Vendor B also wants to have those government rebates, but when they introduce their energy efficient machine, they also load it with a bunch of new options so that people can see something new for their increased costs, above and beyond the energy savings.

Yet through all of this crazy innovation, and marketing strategies, the basic functionality of the machines is the same: water, movement, rinse, repeat. It is because of this shared common functionality that customers can switch between products, choosing the features they want, or the reliability they need, while being assured that this basic, needed functionality is provided.

Returning to weblogging tool technology: it is a shared functionality and a minimum data model between products that leads to many of the innovations we have come to take for granted. It is this that allows us to have syndication feeds that can be consumed by all aggregators regardless of tool manufacturer and innovation. It is this that allows one weblog to ping another, or to ping notification aggregators such as weblogs.com. It is this that allows desktop editors or email clients, or even cellphones to post to different weblogging products. And it is this sameness that can be exploited to make it easier for webloggers to switch to a different product.

Being able to switch relatively easily led to customer demands that led to competition among the washing machine vendors, and it can do the same with weblogging technology. It is customer demands that lead to support of multiple syndication feeds rather than just one; it is customer interest in, and demand for, comments that led to them being incorporated into most weblogging tools, including the recent addition of comments to Blogger; and it is customer demands that are now driving much of the work on comment spam prevention.

If enough tools support an innovation it becomes commonplace and hence a de facto standard; eventually it forces enhancements to the underlying commonly shared behavior and data between tools. This then ups the minimal level of necessary functionality for all products, and the innovative cycle begins again.

Rather than homogenize weblogging, by enabling webloggers to move relatively easily between weblogging tools, and encouraging them to so move when they’re unhappy with their existing products, we’re giving them a say in the the direction that technology takes–that intersection between innovation and use I mentioned earlier. This, in turn, leads to better products, leading to happier webloggers, who are encouraged to write more about things that interest them–such as washing machines, and what happens to all those socks that disappear.

Categories
Technology Weblogging

Tool independence: The export format

The first challenge to moving a weblog is getting a snapshot of your weblog data in a format that can be imported into the new tool. To create an export that works with most tools, at least for moment, you’ll want to export your existing weblog’s data using the Movable Type import/export format.

WordPress doesn’t have a MT export built into the tool (more on this later); as I mentioned in a previous post, I used Scott Hanson’s new WordPress to MT export script to export my posts, categories, comments, and other data. Once I copied his file, I edited the parameters given in the script, providing the same username, password, and database name I added to the wp-config.php file. I also edited the file to use the default line break within Movable Type, __default__ , rather than ‘markdown’, which is the text format tool currently set as default in the import tool. These items are easily found in the script using a text editing tool.

When I load the export script page into a browser, the exported data prints out to the page, in a technique made popular by Movable Type. Once the export is finished (a message displays at the end of the page), I used the browser’s File/Save As functionality to save the page to a local file called bb.export.

(Another approach is to use the Unix wget utility on the command line as follows: wget http://somedom.com/import.php. This saves the exported data as ‘import.php’ and you can the use the data as needed. )

After the file was created, I FTP’d it to a newly created sub-directory, import within the MT cgi-bin directory. All that was needed at that point was to open up my MT installation, select import/export, and pick the import option–choosing to use myself as default author. the default post status of ‘publish’, and since all the entries had categories, I didn’t need the default category. I also have titles for all entries, so didn’t need to fill in the start and end title HTML fields, either. Clicking the link to do the import should load the data, and the data migration of the tool porting is finished.

(See the Movable Type documentation for more information about importing data into a MT weblog.)

A regular WordPress supporter, Carthik also has a version of a WP-to-MT export tool that uses WordPress global variables for the database variables. You can access it here. Carthik had his export tool finished before Scott started working on his, but had withheld publication because he’s now working on what he and Matt Mullenweg, the lead WP developer, are calling a “lossless XML export”–a import/export format that is going to be included with WordPress 1.3, and licensed as GPL for others to use if they wish.

One reason that the WordPress folks are creating this new format is that there has been problems with the existing MT format in the past. I have exported and imported data several times using this format and haven’t had issues recently, but others have had problems, specifically with fairly fragile points of breakage in the scripts such as dependence on a dashed line to separate entries. When I first used the import format to move from Blogger to MT, the import kept stopping as it would run into a sequence of dashed characters and the import functionality thought, “Well, that’s it – she’s done.” Once I edited for this problem, another would surface, making my move from Blogger to MT the most painful tool move I’ve done.

However, there is no denying that the MT export/import format is the most widely supported format in most weblogs. To have tool independence, in this case you need to depend on a specific tool import/export format…at least until enough vendors can support a replacement.

Technical issues of clean transformations aside, a challenge with a new universal format is the underlying data model each tool shares. For instance, a ‘post’, that has 0 or more ‘comments’ and at least one ‘category’ is more or less a standard model of data across all weblogging tools. However, beyond this simple core model, each tool does differ widely.

For instance, Movable Type supports keywords but not key/value pairs. Keywords are just a listing of terms associated as values to the weblog, while key/value pairs have both a term and an associated value. WordPress supports key/value pairs, and I use these in the ‘about this entry’ box in the top-left of the page. When I moved the data to the Movable Type test site, I lost this key/value pairing. Even if a new export format included these key/value pairs, there would be no place to receive it in the target weblogging tool–in this case Movable Type. The most we could do is strip the key portion of the pair and just take the value, and this would defeat the usefulness.

Now, if we use something like RSS or Atom to act as the transport medium, it might seem as if these would then ensure a common data model because most tools support one or more of these these feed syntaxes. The assumption is that if the tool supports the feed, they have to support the data that provides the feed, and therefore a minimum data model is guaranteeed. Right?

Well, not necessarily….

If a syndication feed supports complex or hierarchical categories but these are optional, and one weblog tools supports them, but another doesn’t, using the syndication feed to export the data from one tool to the other will result in loss of data; using XML won’t improve this situation, or prevent the loss of data.

That’s where the MT import/export format comes in handy at this time. The power behind it isn’t in it’s syntax, which is problematical–but in the underlying data model. The MT format has, by virture of it’s wide usage, defined a minimal shared model that most tools support. An XML-based version of this model could then provide a more robust import/export format. This is a win/win for all tools, and one that we as customers should encourage.

However, until a good majority of tools support the use of this XML format, whether it’s based on RSS or Atom or even something entirely new – the de facto standard for most tools now is the existing MT regular text-based format. This is what I will be using for the rest of these writings.

Categories
Technology Weblogging

Weblog tweaks: tool independence

Recovered from the Wayback Machine.

Once upon a time, a weblogger was defined by the tool they used as much as the type of material they published and the style of writing they favored. We were, and many still are, a fiercely loyal bunch when it comes to the software that help us publish our thoughts to the world.

But things happen.

We barely brushed the afterbirth from comments before the spammers hit; people became successful writing the software, or got tired of writing the software, and that changed the dynamics between tool giver and tool taker; open source tools came, and went, and then returned, either with a whisper or a shout. Over time, the packs that moved en masse from one tool to another begin to splinter here and there, and the tenuous bonds of loyalty between tool maker and tool user began to fade. Now, to most people, weblogging software is just that…software. And moving between tools is less a declaration of independence than a simple convenience.

When changing tools, instead of:

I am moving from Movable Type to WordPress now!

Hear me! I am moving now! Watch!

Are you watching?

Here I go!

It becomes:

Oh, I forgot to mention last week, I moved to WordPress.

There will always be core groups of people loyal to one type of software or another; more power to them because they also provide the core support for the product and we all need a little help from time to time. But for most of us, all we want is to write in peace and not have to clean our buffers of 1001 spam messages every morning.

Of course, no one wants to spend their time, moving their weblogs from tool to tool. However, If you truly want to focus on your writing (or your photos, or your garden stories and recipes) then you have to be willing to move your weblog to a new tool rather than stay with one that makes you unhappy. A tool that pisses you off is going to claim a whole lot more of your attention than the day or so to move it.

It’s also not good for the tool makers or vendors to have people continuing to use their tool because they, the webloggers, feel ‘trapped’ into using it. These people will express their unhappiness: probably frequently, and most likely noisely. There’s enough customers for all the tool providers, and none of them needs an unhappy customer. Moving to a different tool could be a far, far better thing for your customer to do, then they have ever done before. I know that my previous weblog tool providers have certainly felt that way about me.

However, rumor has it that porting your weblog between tools is a major undertaking similar to, as I wrote someone recently, dying and being re-born. Painfully. And it’s true that moving your weblog between tools is not the easiest thing in the world–but it doesn’t have to be overly difficult either.

I have moved several people through a variety of tools and environments. I have written a couple of hundred tutorials and tips for the various weblogging tools I’ve used, including how to move your weblog from Tool A to Tool B. But I’ve never tried to separate out the commonalities between the tools when I’ve created these writings–what it is about each tool that is very similar. That’s what I hope to do in this set of essays I call my WeblogTweaks – the last of my writing on weblogging technology.

First up: Moving from WordPress to Movable Type.

I created a brand new MT installation this morning, and I’ve finished the port of the entries using Scott Hanson’s WP to MT export script. In addition, since I’m moving from a PHP-based tool, I’m preserving the dynamic nature in the new environment, and have incorporated the new MT PHP configuration into this weblog; the pages you see are being served dynamically. I’ve also preserved the URLs from WordPress to MT–no redirect or fancy foolin’ will be needed to maintain the permalinks.

Now, I’m working on the sidebar. In my current weblog, much of this is fed by WordPress specific plugins. Whatever functionality can be handled by tags will be replaced by tags, but there are some functions unique to my specific setup. Rather than drop them, I hope to convert them into MT style plugins using the new PHP-based plug-in API.

(And the transparent calendar looks rather nifty on the faintly patterned background. Hmmm…)

But that’s for tomorrow, as is the detailed writeup on the work I did today. I’m beat and I want to write something non-techy before bed.

Caveat: I’m not recommending people move from tool A to tool B just because they can; nor am I recommending any one tool over another. Each tool has good points and bad, and both are relative to the person using the tool and their specific needs. And here’s a hint: all weblogging software is buggy. It is the nature of software–there is no magic fairy that sprinkles pixie dust on weblogging software that makes the bad stuff go away. If there was, Microsoft would have hired him or her a long time ago.

Categories
Weblogging

Bad mans find good woman

I’ve been hit severals time recently with comment spams. In fact the frequency of attack has really picked up as WordPress has become more popular.

I don’t use any form of blacklist, but controlling the spam is still pretty trivial. There’s one throttle in place that doesn’t allow more than so many posts in a short period of time–over ten posts in a minute, and over fifty a day; anything beyond these limits is automatically moderated. I can easily increase the number of comments per minute or day if I suddenly gain political blogger status.

(The ten posts in a minute throttle is new, so please send me email if you have problems.)

I also have code in place to automatically put my comments into moderation at 20 days. Due to the increased frequency of attack, I’ve changed this to put any comments older than five days into moderation. Since most activity falls within this five day period, this shouldn’t be too restrictive.

With these protections in place, I still get the comments. But no build is happening, so it’s just a straight database access and an email. And since I can’t get more than ten of these beasties at a time, the mail is no burden. Once a day, I then go into WordPress, go to the comment power-editing page, search on whatever is common on all the spams, and then mass delete the bunch.

If there’s one drawback to this, when my throttle is in place, your comments may end up in my moderation queue. But unless you’re selling me online gambling, I’ll let you through.

This spam throttling is one of my favorite WP modifications. If I had to pick any five modifications I’ve done to WordPress that has more than paid for the time to maintain these between version upgrades, I would pick the following:

  1. My comment spam throttling. Without having to resort to IP or other blacklisting, I have it controlled and managed with a minimum of effort. I am looking at putting this into a plug-in for WP 1.3
  2. My fullpage preview. There’s nothing like previewing your post within the environment it will be viewed at when published. The only way this can be a plug-in is to use DHTML to modify the page objects on load. Since I’m not fond of using DHTML for anything to do with navigation, I prefer to customize the page.
  3. My comment editing. As I posted comments in the last few days in other weblogs, I really regretted I couldn’t edit the comments after the fact. My damn typos. Because of this, I’ve come to have a deep appreciation for my own comment editing feature. I think all sites that offer comments, should provide comment editing. Best thing of all, this can be a drop-in modification. I need to package it accordingly for 1.3.
  4. My moderated comments customization. Being able to turn moderation on an off selectively rather than globally is a wonder. Again, this can be a plug-in, but would require DHTML to modify the document and this doesn’t ring my bell. So it stays a customization.
  5. My other customizations are tied for usefulness, but I like my comment/trackback split, and my talkback feature (both plug-ins, which I need to link at the WP support wiki). I also like my Insert post status that allows me to publish an entry, without it being part of the overall site navigation. This is particularly useful for About pages and other content that you want static. I also like my static page implementation, though I think the one that comes with WordPress now might be better (have to check it out and see).I also like my new “about this entry” with notes annotation that I just added. It adds an element of fun.

Why do technologists like weblogging? Because the tools are a tweaker’s paradise.