Over on my personal blog, Will Parks just asked:

I’ve also seen quite a few of your sites on del.icio.us, you do excellent work modifying the layout of Plone. This is my first time at this blog, did you ever write an entry about the customization process you use?

In fact, I haven't.  But I'm really proud of many of the sites my talented colleagues here at ONE/Northwest have launched since we picked up the Plone habit in early 2004.  (You can find many of them listed at Del.icio.us, and you should tag other Plone sites with the "plone-sites" tag, too.  But I digress.)  And there's quite a lot I could say about how we do what we do with Plone, in the hopes that it will be useful to others who are using Plone to build websites that are "cheap, fast and good."

Graphic design

Out of the box, Plone is about the cleanest and most usable CMS out there, thanks to the considerable talents and tender love of Mr. Alexander Limi!  And that's what a CMS should be, clean and usable. But it's a little... plain.

Making Plone look good starts with pure-and-simple graphic design.  (Surprise!)  We actually spend some focused graphic design time on every site we do.  We've got a talented graphic designer, Laurie Kellogg, on staff here, as well as a handful of friends that we call on for bigger jobs.  Some of our clients even bring their own graphic designers to the table.  We're fine with that. Thanks to Plone's excellent separation of content and design code, it's generally pretty easy for us to integrate a visual design into Plone quickly.

Sites we've done have spent from a few hundred dollars to $3000-4000 on graphic design work.  A low-end example is Herons Forever; a high-end example is Snow Leopard Trust, which was designed by our friends at Light Sky Designs.

The bottom line is that making Plone look good starts with some creative talent.

Integrating Graphic Design Into Plone

Integrating the graphic design into Plone is pretty straightforward.  We used to just do it by customizing templates through the ZMI; about a year ago we discovered the joys of filesystem-based skin development, and we haven't looked back.  Today, our basic graphic design integration bag of tricks consists of:

• DIYPloneStyle, which we use as a basis for creating filesystem skin products.
  
• Subversion, which we use to manage our skin products -- makes have multiple people working on stuff reasonably easy.  And it lets us roll back our mistakes. (We make lots.)
  
• A few "stupid python/ZPT tricks" for doing stuff like random banner images or per-section logos.  These just get dropped into page templates.
  

Deeper Magic: Customizing Plone Functionality

Plone out-of-the-box is pretty close to the way our clients want their sites to work, but we've discovered a bunch of tweaks we make to pretty much every site we do.  This includes things like:

• Disabling new member signups (most of our sites aren't public 'community' sites)
• Hiding the login & join links
• Adding an email signup portlet (virtually all of our clients have email newsletters)
• Creating "images" and "files" folders to give users convenient, standard places to put, um, images and files.
• Making Plone use US-style date formatting (e.g. May 13, 2005).
  
• Changing the colophon to read "Powered by Plone | Site by ONE/Northwest"
• And more minor stuff like this...
  

We've wrapped all of these little tweaks up into a product we call "ONENWTemplate" and it gets installed into most of our new sites as soon as we start creating them.  We keep it under version control and are constantly tweaking it in small ways.

"Pigeonhole" -- Extra Special Kung-Fu Power

For our more complex sites, that have lots of content and serve multiple audiences, we have developed a generic product called "Pigeonhole" that is basically some custom and customizable metadata fields that can be applied to content objects.  Things like "audience" and "program area."  These are then used, often in combination with Keywords to help link together related content from across the site, and to build portlets of related content.  Pigeonhole also includes a couple of generic content types we use for many sites, such as a Quotes portlet and a simple Poll/Quiz portlet.

"Kickstart" -- Ultra-Rapid Site Wireframe Build-Out

The final main ingredient in our recipie for a tasty Plone site is a little tool we call "Kickstart."  Technically, it's part of the "ONENWTemplate" product I mentioned above. But it's cool enough (IMHO) to deserve a separate mention. 

As you may have discovered, creating twenty or more folders and all of the portal_action entries for a typical mid-sized site through-the-Plone is just slow enough to be maddening, and doing it via Python is too complicated for most of our project managers (myself included).  So we created Kickstart to bridge the gap. It's designed to make building out a site from an initial sitemap really, really fast.  

Basically, it's just a little textarea box that appears in portal_migrations, which accepts text input that we create in a simple Excel worksheet.   Each row is a folder or page, and can be designated to appear in the main nav, the utility nav or in our Pigeonhole-powered audience nav.  Things can be given parent folders (or root) and it can optionally generate an index page for a folder. 

This lets our project managers rip out site maps in Excel, often working collaboratively with the client, and then cut-and-paste the sitemap into the ZMI to build out the site in a flash.  Then the client can get started putting content into their "clickable prototype" while we work on design integration and any custom programming.

Conclusions

So, there you have it. Our Plone development scheme in a nutshell.  Graphic design, design integration, Pigeonhole-enhanced metadata and Kickstart-powered wireframing.

What I'd like to know is: what kinds of tricks do you use?  Some of you readers are lots more clever than we are. I bet there are lots more 'smart practices' for building simple Plone sites.