ReadWriteWeb

I don't want to wade into an RSS syntax debate, but I came across a practical example of why to duplicate the Guid and Link elements in your RSS 2.0 file. Rogers Cadenhead recommends that they be duplicated. It is one of two differences between Rogers' new proposed RSS feed for Movable Type users and Brad Choate's version (which I had used). The other difference is that Brad uses excerpted entries for the Description tag, whereas Rogers advocates the full entry. I agree with Rogers there, so that was the one alteration I made to Brad's version when I implemented it. But the Guid / Link thing, I didn't think it was a big deal to not have the Link element under each Item...so long as you had a Guid. What's a Guid? The RSS 2.0 Spec defines it as:

"guid stands for globally unique identifier. It's a string that uniquely identifies the item. When present, an aggregator may choose to use this string to determine if an item is new."

Anyway in the comments to my last post, Adrian McEwen pointed out that the Aggregator he uses does not display my permalinks:

"...at the moment people clicking through from your RSS feed (like I've just done) don't actually get taken to the individual post, they get the main http://www.readwriteweb.com/ (at least that's what happens with nntp//rss)"

I went and checked out nntp//rss and it turns out it's a new form of RSS Aggregator I'd not come across before:

"Bridging the worlds of NNTP clients and RSS feeds, nntp//rss is an application that will enable you to use your existing favorite NNTP newsreader to read your information channels."

The demo uses version 0.4 of nntp//rss, which appears to pick up Guid OK. They didn't have my RSS feed in the demo, but I checked the Scripting News feed and it was fine. However Adrian is using version 0.3, which didn't display permalinks for either me or Dave Winer. So maybe it was just a bug in nntp//rss v 0.3. However it does go to show there's no harm in duplicating Guid and Link! So I've gone and made that change to my RSS feed.

More tinkering. Last night I made the header and footer fixed width, evened up the right-hand column's width in relation to the left column, added more white space to the main content area, and made various other changes to the CSS. I'm much happier with the layout now - it looks more balanced and not so cluttered. But I'd be interested in hearing some feedback, especially if things look funny in your web browser of choice.

Pop Quiz

I don't have enough readers to do quizzes, but if you are here reading this - would you mind giving me a YES or a NO to this question:

Should I append comments to the end of each post, rather than my current practice of keeping comments separate in a pop-up box?

There's really no excuse for me not to append comments onto the end of each post, as Movable Type has ways of keeping out those dastardly spammers. It'd be keeping with my Two-Way Web principles to allow it, because it encourages reader/writer conversations. On the other hand I don't get very many comments, compared to some other bloggers who interact with their readers a lot, so maybe the status quo pop-up box is sufficient. Hmmm, what do you think? (perhaps an ironical question, given my previous statement!)

Yesterday I explained why I moved my blog from Radio Userland and today I'm going to explain how I did it. I'll also talk a bit about my new CSS layout.

The Move

I have to give a big shout-out to Bill Kearney, whose Radio Exporter tool made it relatively easy to export all my content from Radio to MT. There were a couple of gotchas for me though - one was I had to convert the date format Radio uses (DD-MM-YYYY) to the format MT wanted (MM-DD-YYYY). The second additional thing I had to do was get rid of all the line breaks I had in my content - I used MS Word (of all things) to do that. There was some other faffing about, but eventually I got all the content imported into MT.

The next task was to maintain the same URL structure in my new MT blog, so that permalinks to past articles wouldn't break. Again Bill Kearney had solved this - it was a matter of adjusting the date-based archive template in MT to use the same date format as Radio.

My comments system proved to be the biggest challenge (apart from the CSS that is, which I'll get to in a minute). I debated with myself whether to use MT's in-built comments system, or whether to stick with Phil Pearson's excellent Python Community Server. I decided it would be easiest to keep going with PYCS, rather than try and migrate all the comments across. Plus I like the pop-up box method of comments, rather than sticking comments on the same page as my posts. Although having said that, I do admit that having comments on the same page as the post encourages community-centred conversations. But for now I'm very happy with PYCS. A big shout-out here to Phil Pearson, who has been helping me migrate my comments.

NB: some of the old comments haven't yet made it across, so if you're wondering why a comment you made on my blog in the past is no longer present - it's not because I deleted it, unfortunately it's stuck in transit. It'll be back soon.

So that was basically how I moved my content across to MT. There were a few other gotchas along the way, but that's par for the course whenever you move weblogs - and every person's gotchas will be different, so there's little point in me describing them here.

The CSS Re-design

Now before I start talking about the CSS, I have to say that I don't think my new design is - visually speaking - anything to write home about. I'm no Zeldman or Asterisk or Simplebits. Those guys are artistes, whereas I'm not worthy to shine their shoes (in a web design sense). But even though I have the esthetic sensibilities of a bull in a paint supplies shop, nevertheless I wanted to design my very own style for my MT weblog. My goal was to design a fairly unique, CSS-positioned, table-less layout that had semantically meaningful <div> tags dripping from its very pores.

Last time I did a CSS design, I borrowed one from the fab CSS Zen Garden (with the designer's permission of course). But this time I specifically wanted to create my own CSS design from the ground up. So firstly I studied lots of existing designs, to see how others did it, and I consulted various books such as Eric Meyer on CSS (thanks to Code is Mandatory for lending me that, plus the Zeldman book). I noticed that most of the good designs out there are centred and fixed width, but eventually I decided on a left-aligned fixed width design - to be slightly different, but also I think the main menu is best positioned on the left of a page rather than horizontally below the header (where most trendy websites place it). I also opted for 3 columns, as I wanted to highlight my Quicklinks in a place that was separate from the main navigation. The right-hand column is where most bloggers put their quicklinks, and in this case I opted to go with the common wisdom (Jakob Nielsen would be proud of me).

The CSS design I created uses 'float: left' and 'float: right' to position the left and right columns, and the main content area fits in between. All 3 columns are placed within a container div. The effect of the two vertical grey lines that separate each column is attained via a vertically tiled background image - see Dan Cederholm's excellent article on Faux Columns. There is one little gotcha here that I didn't discover until the morning after I published my new CSS - in the HTML file, the code for the left and right columns must be placed before the code for the centre column. This means the left and right columns will render before the centre column, which will prevent jerky scrolling in Mozilla and overlaying divs in all browsers.

There are a few other things I need to tidy up in my CSS - e.g. there is an annoying bug in IE's rendering of pages that include an <em> tag. So if you notice the right grey line missing on a page which has italics, that's the reason. This and a few other minor things still need patching up. I also suspect I haven't covered all bases for backwards compatibility (IE 5 browsers and the like). Sigh, the joys of CSS design. I will try and fix these things up over the next few weeks.

One more thing, I will try and jazz up the design some more - e.g. with a graphical header and some more stuff in the right column...maybe music-logging (a la Lucas and Seb)?? Hmmm, have to think about that. Any suggestions?

Summary

Well that about brings to a close my latest project - moving to MT and designing a new CSS layout. I can now get back into writing and other explorations. I have an interesting RSS article coming up, regarding E-Government. Stay tuned :-)

My transition to Movable Type is mostly complete now, at least in terms of migrating content from Radio Userland and getting my new CSS design to a position of relative stability. In this post I'll explain my motives for switching to Movable Type. In my next post I'll provide some details of the process I went through to switch and how I designed the CSS.

First of all, let me say that I have nothing against Radio Userland as a product. I've been using it for over 2 years, it introduced me to the world of blogging and RSS, and it's served me well. But now it's time for a change and here are my main reasons:

The desktop model of publishing no longer suits me.
Radio Userland is a kind of web server for your PC. It's an application that resides on your PC and to publish from it, you "upstream" html pages from your PC to your web server. Movable Type on the other hand is an application that is installed on the web server and accessed via your web browser. There are benefits to both models, but the main benefit to the MT one is that you are not tied to one computer. You can publish from MT using any computer that's connected to the Internet. Which is what I want nowadays.

I want dynamic webpages.
Movable Type has strong support for PHP, which is a server-side scripting language. This is something I want to learn more about. I'm very familiar with ASP (Microsoft's server-side scripting language) and I used to run an ASP-based website in the late 90's. PHP is basically the open source counterpart of ASP, so I'd like to play around with it.

Movable Type has a very strong Developer community - e.g. lots of plug-ins.
This is something I feel that Radio Userland has lost a lot of ground in over the past year. When I first started using Radio, there was a vibrant community of developers who created new add-ons and plug-ins. But those developers have drifted away from Radio, while at the same time MT's developer community has flourished. I think this has a lot to do with Radio Userland not having had any major upgrade in functionality in the last 2 years. Radio Userland version 8.0.8 was released in May 2002 and there hasn't been another version since that date. And what's most frustrating is that Radio users have been promised new features for quite some time, but nothing has eventuated. In July 2003 then-CEO John Robb promised that "lots of great things coming for Radio will be out in the next 3-4 months" and that many of them would be "truly revolutionary".

Well I'm sick of waiting. I don't mean that to sound mean-spirited, because I'm very fond of the Radio Userland product and community. Many of the people I've met over the last year and put on my blogroll are Radio users. I just feel that we've been let down by the product not moving forward and not keeping pace with the likes of Movable Type and Wordpress.

But back to Movable Type - it has a strong developer community and a guy like me relies and thrives on plug-ins and add-ons. I'm not a programmer by trade, but I do like to tinker and mess around under the hood of software products. I've had a great deal of fun mucking around in the radio.root file, for example. I'm looking forward to doing the same with MT, but with PHP and plug-ins. btw that's also why I like XML technologies such as XSLT and XPath - they allow me to experiment and be an "information-remix junkie" (Rogers Cadenhead's term).

MT is free
As in free beer. Radio costs US$40 per year, so even if it did come up with a major new upgrade in 2004 I'd have to shell out about $75 dollars for it (NZ currency). While I have nothing against paying for software, I'm afraid $75 per year isn't trivial for me. Radio should perhaps consider a model where you pay US$40 for purchasing the product, then say US$10 every year for the privilege of downloading upgrades.

Movable Type is a lot easier to design CSS layouts with
Designing with Web Standards and CSS is important for me, not so much to show my wares as a designer (I'm "graphically-challenged", I guess you could put it!). CSS is mainly important to me because of its semantic qualities. I've written about this before, so I won't repeat myself here. But I will say that Movable Type is much easier to design in CSS with. When I did my first CSS layout in Radio, I had to change some macros and fiddle around in the root file to get it working.

Movable Type has in-built search functionality
I haven't turned this on yet, because I haven't got around to styling it. But it's coming soon...

I wanted a stronger connection between my main weblog and my linkblog.
I've been running my linkblog in Movable Type for the past 7 months. I think now's the time for me to integrate it more strongly with my main weblog. Not just in terms of what tool I use to publish it, but in the next few weeks you'll see the designs of those two blogs move closer together.

I've joked in the past about the 'Read/Write Web Media Empire', but I do have some real-life plans to have a "network" of blogs. So far I have a main writing weblog (Read/Write Web) and a blog to store links (Web of Ideas). Next up: multimedia blogging!

Summary

Those are the main reasons why I moved to Movable Type. But it's also got a lot to do with the kind of person I am - curious, an intellectual explorer, someone who likes to challenge himself with Web technologies. Those are all fancy ways of saying: time for a change. I still like Radio Userland and would recommend it to my friends. But the Movable Type era has begun at Read/Write Web!

Pardon my dust, I'm in the process of moving my weblog from Radio Userland to Movable Type. Also, as you can see, I've done a re-design. There are still a few CSS issues to iron out, so things may be a bit funky for the next few days. But I decided to publish my new weblog now anyway, because...well, I'm an impatient character and I want to get back to my writing.

I'll explain more about why I decided to move to Movable Type in my next post. Right now, I need some sleep!

ps comments for old posts haven't been hooked up yet.

pps did you get the movie reference in the title :-) The River Phoenix movie... I'm sure the joke has been done before.

I've just arrived back from a business trip in Melbourne, Australia. I'm creating a strategy for and managing the implementation of a new Intranet site. While I was over in Melbourne, I saw some examples of strategic thinking in action - by the local taxi drivers. Everybody is strategic in some form. But taxi drivers perhaps have more of a requirement to devise cunning strategies for success than most, because their industry is extremely competitive.

Strategies are all about having a plan to optimize performance and the following two examples illustrate this quite well. The first example (not in chronological order) occured on the ride to the airport to go back to my home in Wellington, New Zealand. The driver I had knew the route to the airport like the back of his hand, and he'd worked out a strategy to get from the city to the airport in the quickest time possible in peak traffic. He reckoned he'd shaved 5 minutes off the time most people would take to get to the airport. His strategy was all to do with moving into different lanes on the motorway at what he figured were the optimum times.

There are 4 lanes in total on most of the motorway between Melbourne City and the international airport. The driver started off by cruising in the extreme left lane. The right-hand lanes were busier (and hence slightly slower) at that point, but people knew that the left lanes would get busy later when new traffic entered the motorway from the left. And soon we did indeed come to a point where an off-road merged with the left lane of the motorway. But instead of moving into one of the right lanes straight away to avoid the merge, my driver continued on in the left lane. He went as far as he could in the left lane, before the traffic began to slow down due to the merge. His intention was always to move across to the right-hand lanes. But the trick, he said, was to leave the lane changes as late as possible - so he could push in ahead of those people who had moved from the left to right lanes before the slowdown in the left lanes started. So at the point where the left lanes had slowed down, but not quite so much as to make it impossible to shift into the right lanes, the driver made his move. He pushed his way across two lanes so he was now in the middle-right lane. It wasn't an easy manoeuvre, as the two middle lanes were by that stage very busy and those people fortunate enough to already be in the right lanes were reluctant to let other people in (as it would slow them down).

The driver advised that he'd learned to tell which cars would let him push in and which would block his move. So he'd picked up the skill of being able to accurately judge which cars are 'the weak links' (my words, not his) and which ones he won't take on. I should've quizzed him more on this, as it occured to me later that it would be good to know whether he makes his judgement call based on the model of the car or the type of person driving it - or a mixture of both?

So we were now in the middle-right lane. "Look at how many cars we passed", the driver said, gesturing in the rear-view mirror at the cars behind us that had stuck to the right lanes throughout or had made their move into the right lanes too early.

After cruising in the right lanes for a while, the driver pointed out that coming up ahead was a bend - which would slow down the right lanes. I craned my neck to look ahead of me, but the bend was nowhere to be seen. The driver though had driven the city-to-airport route hundreds of times before - he had foreknowledge. So before the bend came into view, he pushed back into the left lanes. And sure enough, when the bend arrived the cars in the right lanes slowed down relative to those in the left lanes.

After the bend had been navigated, our car drifted back into the right lanes where it was faster once more. Then, at a time that the driver had pre-calculated was optimum, he pushed back into the extreme left lane for the airport turn-off.

I may have left out one or two other lane changes in this story, as my memory has been affected by jetlag. But the moral is that the driver knew the system (of driving from the city to the airport in peak-hour traffic) so well, he'd been able to devise a strategy to optimize the journey - optimal performance in this case measured by having the quickest possible travel-time.

I'll give you another example of taxi driver strategy that made an impression on me, albeit in a less favourable light. When I checked out of my hotel in Melbourne city, I had to go back to the office for a bit. The office was only one block away from the hotel, but my luggage was too heavy to walk it. So I took a taxi.

Now obviously a person standing outside of a hotel with luggage is an attractive prospect for a taxi driver, as odds-on that person will be travelling to the airport. Ka-ching! So it didn't take long for a taxi to pull over. 

The expectant face of the driver leaned over, waiting to hear the magic words: "To the airport please." I poked my head into the car and informed him I was only going a couple of streets. The driver looked at me disbelievingly for a second, then his face assumed a mixture of crestfallen and disgusted. It would only be a $5 fare for him. At first I thought the guy wasn't going to let me in the car. But he relented, after my slightly terse "Is that alright?".

As soon as I got in the taxi, the driver asked me if it'd be OK if he picked up another passenger on the way.

"Another passenger?" I said querulously, "You want to pick up someone else while I'm in the car?"

The driver could tell I wasn't keen on that idea, so he quickly changed tack. "No, no - I meant when we arrive. Can I pick up another passenger at the same time I drop you off? That's all I meant." His voice was apologetic, but at the same time dripping with contempt.

"It's hard to get people going to the airport", the driver continued, "It's the luck of the draw who you get" - his surly expression indicating his bad luck at picking me up. He ended up getting his revenge by dropping me off 50 metres before my office, claiming that the traffic would prevent him finding a place to stop elsewhere.

This taxi driver's strategy was obviously to avoid $5 fares and always try to pick up airport fares. I'm only guessing, but I think the taxi system he works in is optimized when a driver picks up passengers going to and from the airport. I realise this is common in most cities, but there will also be reasons specific to Melbourne why inner city passengers don't cut it - e.g. perhaps taxi drivers there waste too much time sitting at intersections waiting for trams to go past. I don't know the reasons, but the optimum strategy does seem to be to get as many airport passengers as possible in a day's work.

So there you have it - some strategies that taxi drivers use to try and achieve optimal performance. It's damn hard work being a taxi driver, due to the competition they face from other taxis and the complex environment they work in (peak traffic flows, trying to decide where the best places are to pick up passengers, etc). I admire their strategic thinking abilities. A desk-bound webman like me could learn a lot from them.

My article for Digital Web Magazine, The Evolution of Corporate Websites, has now been published. It's a high-level look at web design trends over the past 10 years. Here's the introductory paragraph:

Hard to believe, but corporate Web sites have been around for over 10 years now. It’s fascinating to see how they have evolved over the years, from the early days of magazine-style brochureware to the most recent trends of two-way Web interfaces.
Continue reading at Digital Web Magazine...