NASA Science Case Study - Part I - Why Plone?

Back in 2008, Pydanny and I presented at the Plone Conference in DC on NASA Science, the Science Mission Directorates' outreach site. In case you didn't know, we did it in Plone, and everyone seemed to want to know why and how. We decided to tell the world with a presentation, and not long after, were asked to write up a case study.

Dear god, Jon Stahl is one patient man. Finally, here it is.

Part I - Why Plone?

But first, some history!

The last time the SMD website had been updated, structure-wise, was back in 1999. While it had won awards for its design and content in the day, it was long overdue for a major overhaul.

The original site was 90% HTML with the occasional Perl script thrown in. There was no database backing it, save for a few 'mini-apps' that didn't talk to each other. Over time, the original look of the site gave way to dozens of mini-sites, each of which had a completely new look. Data had to be updated deep within the HTML, and god save the poor soul who had to do so without the original tool. I had to do it a few times, and the HTML those things churn out are NOT pretty.

The content needed some serious updating, and so did the look. The little black kid on the front page? He was from a stock photo, and by 2006, he was everywhere. Stock photos are evil. The overall style had aged poorly. The sub-sites confused users. And the search? Well, when you use Google rather than your own native search, you know you have a problem.

Selling a CMS

The first thing we had to sell was using a CMS for the site, rather than just doing another HTML monstrosity. Developers, of course, love CMS's, but the only way we could sell it was to show the customer what they would gain... and respect what they would lose.

What they gained:

• Sharing content: content could be shared between sites, pages, even applications
• Reuse of content: content could be used in more than one place, and even used to create more focused mini-sites if needed
• More complex interactions with data and display, like images that update automatically, or cool reports of data
• Easier to change the layout and look if we were using centralized templates and CSS

But what did they lose?

• Instant updates. As long as they had the same designer, they designer could run an update through their software and upload the site all over again. Even without it, it was just munging through bad HTML. Painful for us, but a short wait for them. Now, some updates could be done instantly, but others would have to wait for a release.
• Fast development. They saw a comp one day, a site the next! The magic of export! Now, they would have to sit through our development cycle
• Small team! Before they had a designer, maybe a content editor part time, and that was it! Now, they had a team of developers and a designer or two
  

We were fairly open about what they would lose, but they could see that what they gained far outpaced what they were losing. Whenever they had doubts, we pointed them back to the mess the old site had become, and how painful it was to update it, and impossible to redo.

So, we now had the okay to use a CMS. But which one? We had many sections to our contract's shop: .Net, ColdFusion, Java, and there was the Nasa.gov CMS...

Notice what was missing?

No official Python shop.

We had people who loved Python, and had used it on several projects, but we weren't grouped together. We wanted Plone from the start , but how did we make the case for it with no group to hand it off to? First, slay the other monsters.

HTML: Yes, there were still those that wanted to do the site in pure HTML and upload it.

Pros:

• Fast
• Small shop
• No dev cycle
  

Cons:

• No search! We'd have to make and tweak our own.
• No dynamic grouping or associating of data. No tags, no reports, no 'other things of interests' that wouldn't have to be done by hand

Cold Fusion: We had some eager ColdFusion developers. Why not use them?

Pros:

• They're already in house! No need for hiring!
• They wanted to do a CMS from scratch. That's always easier than learning something, right?

Cons:

• Writing a CMS from scratch is deceptively hard. It takes teams of people from all over the world to make ones that aren't too hard to learn, and actually adheres to a few standards out there
• The leading ColdFusion CMS at the time was Farcry, and it wasn't 508 compliant. Being 508 compliant (accessible to those with disabilities) is a must for any government site, so out it went
• Crufty URLs unless you do some serious Apache configuration
• What SMD had started to want was more modern than the current batch of CF apps had to offer

.Net: What about .Net? We had a .Net shop, after all. Why not use them?

Pros:

• Staff already on hand
• Sharepoint, a .Net CMS, already existed, and there was already some support for it at NASA for other sites

Cons:

• Our .Net shop was small, and already burdened with work
• Sharepoint is reportedly as complex as Plone when it comes to its innards, if not more so
• The designers I knew who worked with Sharepoint hated trying to customize its interface
• The final nail: the .Net developers were concerned about the scalability of Sharepoint

eTouch: NASA.gov uses a CMS. Why not use theirs?

Well, that one is actually a bit stickier. Though NASA.gov deployed first, the SMD site actually started development first. By the time NASA.gov and eTouch came about, we were almost through with development, and dealing with design changes.

Also, in the government, one must always be concerned with what pool of money work comes from. Though we all look like one big happy, people get very, very testy if you start taking from their honeypot.

Plone!

We settled on Plone as our driving technology. Why?

• We had a local resource in the form of the DC ZPUG. There, we could find people interested to work with us, pick brains, and get to hear a little about the trends of our chosen platform
• One of the older CMS's, it was extremely stable
• Active. Even though it was one of the older CMS's, it was definitely still being worked on
• We found it easy to use. One install, and we could already get it doing all sorts of things.
• It came to us 508 compliant, which saved us a LOT of time
• And a host of other reasons, which boiled down to the developers really, really wanting to do something big in Python, and in a shiney new CMS

The customers bought in, and we were on to actually making the site...

(Part II and Part III)