Here at Network World, we use Drupal for our blogging platform. Drupal -- which runs on any platform that supports Apache (1.3+) or Internet Information Server (IIS5+) and PHP (4.3.3+), and MySQL or PostgreSQL -- is impressive in its scope and the level of community effort that has gone into improving, enhancing and extending its features and facilities.
That said, Drupal is a more than a handful to manage. It is, to say the least, complex, rather cranky and definitely a case of death by options. Network World's resident Drupal expert, Adam Gaffin, has become great at wrangling with Drupal, which is to say that insanity might just be around the next corner for him.
Drupal, along with just about every content management system (CMS) I've ever tried, has one big failing: When you are editing content over the 'Net -- in other words, when you are remote from the CMS -- performance is not good.
Usually the page refreshes and delays in submission, meaning you can experience a lag of anything from 15 seconds to 45 seconds after a key press, which can drive you to drink if you have to go through a cycle as I usually do of edit, preview, edit, preview, edit, preview, edit, preview and finally, submit.
In fact this may be one of the biggest issues in Web application design in general today. There are many cases I've found where using a Web browser as the platform for an online user interface provides little or no advantage over a custom client-side application because functionality and performance are deficient to some degree or often mostly missing.
Sometimes it is just that the application designer hasn't grasped the value of additive or alternative technologies. For example, I recently discussed a Web application in my Network World "Web applications" newsletter that would be, and should have been, vastly improved by the use of Asynchronous JavaScript + XML or even by migrating to flash.
The fact is that a Web interface isn't always the best choice for user interaction: When you are trying to keep a user engaged and focused on utility value, you need to provide a suitable response time and usually a simple, Web-based GUI isn't going to cut it.
Anyway, to avoid having to use Drupal's Web posting interface, I used to post to Gibbsblog using a utility called Zempt, which was pretty good.
Zempt, in common with other blog-posting tools, knows how to communicate with a number of blog APIs. In the case of Drupal, the API is based on XML-RPC. Now, I'd love to be able to point you to the Drupal documentation for this API, but the fact is that the Drupal documentation is a bit of a mess. When it comes to the API, it is fragmented in places and missing in others.
Zempt was my blog-posting tool of choice for quite a while but, alas, development and user interest seem to have waned. Next week we'll look at a couple of newer and more "featureful" alternatives I've tried.
Read an interview with Drupal's founder, Dries Buytaert here.
