Medscape Lite C M S

This describes how we handled content production and delivery for MedScape, from 1997 through 2001 (well, it was evolving over time, this describes the process as of early 2000).

The site generated a few million pageviews per month, from a cluster of Win N T servers running: Netscape Enterprise Server, NSAPI C code, Cold Fusion, server-side Java, Verity Search Engine. (Prior to this we ran on Macintosh servers from 1994 to 1997 - see Medscape And Frontier.)

We had a fairly manual process for most of our content, the majority of which was medical journal articles (long, highly structured, lots of tables and references, a fair number of images, etc.).

• content came from page-layout files (e.g. Page Maker) (if they had already been published in print) or MsWord (if original content)

• conversion to HTML was a largely manual process (lots of BBEdit search-and-replaces). Worse, there were often 2 versions of an article: the primary multi-document version, and the stripped-down print-friendly version. Post-production edits (e.g. typo fixes) required duplicate steps

  • we talked to a custom document handling shop about automating the process, but their cost estimates were hardly cheaper than our manual process. Working with formal journal articles (long, tables, footnotes, sidebars, etc.) is a big challenge.

• rolling out an article involved (a) copying from a staging-server to a primary production server (where robocopy would run periodically to replicate to the multi-server cluster), and (b) posting the new article URL to a Cold Fusion form which would trigger a server-side app which would read the file to grab its Medscape Meta Tags and populate/update a SQL db.

• we used SSIs (with Netscape Enterprise server) for content pages to allow for some small design changes to be made without forcing re-rendering

• the main navigation pages (you could call them "channels", though that wasn't our term) were managed with manual HTML code to allow maximum editorial control (ordering of stories, keeping multiple columns to similar length, etc.)

• seconday navigation pages were generated on-request by Cold Fusion, pulling from the meta db (generally on the basis of 'articleTopics' and 'family' Medscape Meta Tags, chronologically sorted). No caching, since those pages didn't get a huge amount of traffic

• the meta db was also used to generate weekly email broadcasts (MedPulse) (separate edition for each "channel"). Cold Fusion would write the ASCII files, an editor would review/tweak (change order, drop an article for length, add something he wanted to promote, etc.). Then someone would manually send by sending to controlled listserv.

Obviously we were ripe for a CMS. But we got into larger issues of platform migration, so CMS took a back seat. Plus I wasn't happy about spending huge bucks for stuff that didn't seem to work very well and that would require adding yet another language (e.g. TCL) to our mix (we only had 4 programmers for the entire site, I didn't want to start worrying about adding staff just for managing the CMS). I was also hoping to use XML as our primary article format (on the server side), but was very concerned about the quality of the visual document-oriented XML editors available (at the time).

Medscape is (as of early 2000) close to picking a CMS vendor now, I believe, though I think they will not use it for page delivery, instead using their own EJB-based stuff. I believe The Street.com had a similar approach, using Vignette as their CMS back end but delivering pages via ATG-Dynamo.

(They picked InterWoven, moved to SunSolaris, kept using Netscape/iPlanet web server, built new infrastructure with J2EE on BEA/Web Logic.)

Interwoven are pieces of shit. Any company where you have to pay a team of consultants 200+ an hour each, is putting out a shitty product. In my opinion, CMS solutions are overbuilt and under designed from a usability perspective. There is a large percentage (above 50) of CMS projects which are abandoned because of the failure of the purchaser to effectively use the system. This bespeaks of the design flaws inherent.

There are additional options in implementing a CMS. Instead of purchasing a $400,000+ system, www.phpnuke.org offers a php based content management system for free. The source is given out therefore an intelligent company could download this system, at a really low cost, and utilize a php consultant to modify the source to the taste of the purchasing company. The end product is tuned to the needs and use-plan of the company. Can you see the ROI here? Less money and more use out of the system? Makes you wonder how Stellant and Interwoven stay around. --ScottScazafavo

amen --ChaitanyaReddy