Dave Winer's kind mention on Scripting News was the impetus to set down my thoughts about something I've come to call the Lightweight Content Management System.

From my days at The Examiner I took away the notion that simple production systems, based on free or inexpensive tools, were a better match for the needs of modern media companies than the traditional big, 'complete' production systems.

Big systems have the advantage that they (in theory, anyway) do everything you need: print page layout, image archiving, re-purposing into other forms, e.g. HTML (or HTML to print if the Web is your native medium). That makes them attractive to pressure-filled production environments like Web sites, daily newspapers and magazines, where screw-ups are frequent and occasionally costly (read 'libel suit').

It seems reasonable to managers and bean-counters that good software could make their people more productive, especially if they can be used to program out behaviors that waste time or are otherwise inefficient.

Big systems: complete but costly and slow to change

Good theory, but the practical problem is that the cost - in time and money - to make the software and configure it for a particular application, is frequently (maybe always) greater than the benefit realized from elimination of inefficiencies. You may be able to get the paper out with 2 fewer people, but you have to hire 3 programmers to maintain the system.

A bigger issue may be the cost of dropping the system. Media companies have to be incredibly responsive to markets to be successful in the 21st Century. They have to create new products, and drop old ones, quickly. The people who are trained in proprietary 'big' systems are difficult to repurpose. It's costly to either lay them off or retrain them to do other work.

And big systems suffer from an inevitable response problem. To be financially successful, they have to have lots of customers. But the demands of lots of customers for features and support slows down the response time. A finite number of engineers can only get a certain amount of work done, so the cutomer's usual response is "we'll put that in the next rev". The customer has the duel problem of getting their own organization to move and getting their vendor's organization to move.

Lightweight systems: fast, inexpensive but maybe not complete

Lightweight do-it-yourself systems have problems too, but I still think they're a better deal. The biggest drawback is the 'dot-the-i' problem - it's frequently true that you can find free or inexpensive solutions for most of the 'big' problems like archiving and finding things, but nothing to handle small, niggling but important details.

At the Examiner, for example, we had a production server, a script that created a folder for each day, and sub-folders for each section (which were day-specific) and an AppleTalk network (this was '89 when we started). We added scripts that automatically archived and made an index of all the photos and graphics a few days after the content had appeared. Scripts also handled wire photo flow, and automatically created HTML versions of all the day's stories for www.examiner.com.

A niggling missing widget: our inexpensive search tool, AppleSearch (Sherlock's forerunner) couldn't read the captions on photos. There was a tool - ImageAXS - which offered caption search, but meant that we had to move our entire archive, and make arrangements daily to update it inside of AXS. AXS wasn't a bad product, but it had been architected initially for the needs of museums, not newspapers.

AXS eventually went out of business, after a promising start, at least partly because it was so difficult to provide the feature level required by markets as diverse as newspapers and museums (and medical imaging etc. etc.), which would have left The Examiner in a worse position.

As it was, 2 years after I left, the Examiner IT department called up to say the archive server was full, needed more disk space, but they couldn't find the physical box even though they could see it on the network. An archive so simple that it consisted of a file system and a script served a daily newspaperfo almost 4 years, shortcomings notwithstanding.

Lightweight CMS: a recipe

Here is one recipe for an easy content management system, c. 2002:

- Radio (or an editing app with a scripting environment)
- Sherlock search engine (or Google or Inktomi)
- Mac OS X server (or any general purpose NOS - NT, Linux etc.)
- Network (Ethernet, 802.11b)
- Simple architecture
- Simple rules

The key to 'simple' is that the rules and architecture are clear to the intended users. The Examiner's rules were simple: nothing got in the paper if it wasn't placed in its final form in the correct section folder under the right day. The examiner's architecture, a folder for each day, and a subfolder for each section, made perfect sense to daily newspaper workers.

Right now I'm editing my radio weblog using OmniWeb - a Mac OS X Web browser - and Radio. OmniWeb, unlike IE, uses the Mac OS X dictionary system resource so that the browser text-editing windows do spell checking and otherwise behave like a word processor. Radio takes care of generating HTML, plugging it into a page template and uploading it to the Web server.

My only tools are the operating system and 2 inexpensive applications - Radio and OmniWeb. With some scripts, a sensible folder structure, some re-configuring of Radio this system could easily be extended to allow multiple users. Add an email server and some scripts, and you'd have a system that could support editors and authors wherever they hapenned to be, as long as they could get Net access.

www.gulker.com, my Web site, has been authored in Frontier, Radio's predecessor, for 7 years. I can change the whole look and feel of the entire site just by changing the template, and as many users as I want can edit content in a simple browser interface. I often write long pieces in MS Word, to get the word-processing tools, then cust and paste into the user interface. www.gulker.com has thousands of pages and hundreds of graphics, and we get along just fine with mostly off-the-shelf parts (Mac OS, WebStar server, Frontier, a browser and Word) with a relatively small investment in some custom scripts for work flow.

Keep it simple

So, that's the pitch. Keep it simple and inexpensive: use infrastructure products like your NOS and off-the-shelf apps. If nothing else it's easy to drop and go with something else if you're convinced you have to. On the other hand, it's easy to add processes quickly to accomodate new needs, new products or new people - and I'm banking that being fast and flexible is going to be of paramount importance in the future.

Updated 4/16/04; 1:55:28 PM

Features & Categories:
Columns (soon)
Dotcom Garden
Picture Weblog
Theory & Strategy
Weblogging


gulker.com Cam

Interesting blogs et al.:

AlwaysOn Network
Natalie d'Arbeloff
Azeem Azhar
Ken Bereskin
Blogging Ecosysytem
Blogging Network
BlogStreet
Boing Boing
Tim Bray
Matt Croydon
DaveNet
Rael Dornfest
Esther Dyson
Dave Farber's IP
Dave Fitch
David Galbraith
John Getze
William Gibson
Dan Gillmor
James Gleick
Bernie Goldbach
Meg Hourihan
Joi Ito
Xeni Jardin (home, Boing Boing)
Jeff Jarvis
Linux Journal
Mitch Kapor
Kuro5hin
Gunnar Langemark
Joshua Levy
Scott Loftesness
Macintouch
Ross Mayfield
Hans Moravec
Rafe Needleman
Nonsense Verse
OS Opinion
Tim Porter
Recommended Reading
Reverse Cowgirl
Glenn Reynolds
Roger Ridey
Phil Ringnalda
John Robb
Scott Rosenberg
Anita Rowland
Brent Simmons
Robert Scoble
Doc Searls
Jessica Shea
Gavin Sheridan
Shifted Librarian
Stefan Smalla
Bruce Sterling
Scripting News
Slashdot
Dan Shafer
John Tringham
Jon Udell
Moicho Umeda
Philipp Weltentummler
Kevin Werbach
Amy Wohl

---