zope

**

I know, I need to work on the 10-second explanation. This blog post is some kind of start.

One reason why I think it's often hard to spit out a quick explanation of what a CMS is to people who've never heard of one is that the 'what it is' description isn't really so interesting to non-tech people. I know I may like to think otherwise, but it's true. The 'what it is' sounds something like "a web-based platform for workflowing, securing, organizing and presenting database-driven content though a website." Try rolling that out at your next happy hour and see what kind of response you get.

Most people don't think much about what makes websites run, or at least I think most people still think of smaller websites more or less as if they actually were made up of pages. Meaning, there's a front page that might have 'stuff' on it, there's an 'About me' page, a gallery page, a blog maybe, and so on. If you set up your site using software like iWeb or something similar, then this is exactly how your site is constructed, one 'page' at a time.

(This is what I call the 'electronic brochure' website model. You've got a front and a few panels that 'fold out,' as it were. If you're running a business, that might mean that your business site has your office hours, company description and location... and that's about it. Clean and simple. Not very complicated, but not fussy either.)

It's likely you have noticed that the big sites aren't built this way, but maybe you don't know how or why. To be sure, a giant retailer like Amazon or a huge government organization like NASA is not creating 'pages' one at a time by hand. That would be an awful job even if it weren't completely impractical to try to create each piece of information for a large or complicated site one page at a time.

In fact, large sites like NASA.gov don't 'think' in terms of pages at all. They actually think in terms of a large database of information. The database holds all the 'content,' usually as small pieces of information and almost never as whole HTML pages. The database might hold documents, images, files, text, raw data, even feeds that get assembled into HTML pages dynamically. The 'pages' are actually created on the fly, as they are needed, automatically at the time they are requested.

This might sound weird if it's the first time you've ever thought about it, and it may change the way you look at websites.

Think of an Amazon webpage for a book. It's got a picture, the book's title, et cetera, some customer reviews, some recommendations & reviews, tags, oh, and Amazon's navigation. Now this particular page you're looking at only *potentially* existed until you called it. Furthermore, the different parts of the page probably came from very different parts of the database. That is, all the bits were there, somewhere, in the database, but *you* actually caused the page to be assembled out of database info and turned into HTML that your browser could read when you passed the URL to the Amazon server. Something at Amazon knew what to assemble and how to present it as HTML, and also knew what ads to show you and knew what related items to display, and so on. (You see where I'm heading with this.)

Now, the database's job is to hold and fetch all the 'content.' But the database itself doesn't hold any web pages. Creating and serving up the web pages is the CMS's job. A CMS takes raw information and shapes it into web pages. Sounds boring, but it's a very, very powerful thing to do. After all, if you generalize just a little bit, talking to a database and serving up small pieces of information in a human-friendly way is pretty much what most of your desktop applications do. What's Outlook, but a database of mail messages served up in a window? Or, what's iTunes, but a database of audio files with a player interface?

If a CMS does what, say, iTunes does, but with web pages instead of music, then what's to stop you from turning your website into, I dunno, a full-blown web application that can do all kinds of things?

It sounds pretty IT-industrial, and it can be. If you're a small biz person, you're probably already doing the staffing math. And, maybe you think it just isn't necessary for your site.

To that first point, a CMS site doesn't cost an arm and a leg. In fact, many excellent CMSs are open source (read: no cost to buy). And, if properly configured, you won't need to staff an IT guy either. At this point, some folks may disagree, but I'm holding firm on this. A small business with a good hosting service and the right setup shouldn't need any intense technical knowledge to run its CMS. If you go with an open source CMS, your up-front costs come from having somebody configure things for you, and that's it.

OK, you say, but can a free, open source CMS do all the things that NASA's site does? Hah. Trick question. NASA's site is run on an open source CMS.

1. Don't write xml, export it‽

I think I saw four people in breakout sessions tweak their content settings TTW and then pop over to site_setup and export the profile to make pretty, well formed .zcml files. OK, ok, I get the point. It's very fast, accurate, and way less a pain in the ass than writing your own.

2. Everything I make gon be folderish from now on‽

I've sort of half been paying attention to the new content type story (a la occasionally checking the Dexterity changelog) for upcoming Plone releases, but it was a bit of an eye opener to watch limi's Plone 5 demo and see Plone's moving to a single, folderish content type. Out-effin-standing. Everything folderish make incredible sense, and I've been tweaking my dev content types accordingly.

3. Use more ZopeSkel‽

Again, small encouragements. jjmojojjmojo's demo capped a couple days thinking that I ought to get more conversant with what ZopeSkel can do. Somehow I had been missing the

addcontent atschema

4. People want awards‽

I've been working on a Plone Community Awards idea, mostly in a vacuum. I knew a couple people from the Board were interested, but I was suprised so many people not only turned up for the BoF, but had also actually read my very, very long draft. Unfortunately, the BoF didn't get very far before they shooed us all off to dinner. Putting faces and names together was very helpful, and we've now got something to go to the Board hopefully this week. When the dust settles, I'll do a separate post or five about the awards.

5. A couple cheers for the little guy‽

At a conference of about a hundred on campus at Penn State, you expect that a bunch of people would be attached to institutions or medium-ish companies, and that was about right. There was the WebLion/Penn State contingent, which seemed to be a hell of a lot of people, and there was the 6FtUp blackshirt army, too.

But, there were also a whole bunch of 'small shop' people there, independent developers or small biz owners, or single Plone people inside larger companies. It reinforces, actually, what I've been thinking for a while, namely that there's been a bunch of commotion lately about positioning Plone as an enterprise level CMS/platform, but there doesn't seem to be so much attention on the fact that many of us work in the small business sphere, and that Plone can be an excellent small biz solution. And, that small shop Plonistas have particular needs and challenges.

Interestingly, the Evangelism BoF did appear pretty heavily weighted with small shop attendance.

Based on the location and the expertise of the WebLion folks, it seemed right that there were lots of sessions devoted to what seemed to me institutional issues, though based on the attendance, there should have been at least one session about Plone from the freelancer/small shop perspective.