Repoze Blog

2008-02-14 00:00:00-05:00

Plone Sitetheming Part 1: Why Not

At the Plone Strategic Planning Summit, I signed up for work on Promote Deliverance as the branding/"corporate ID" mechanism. In the next series of blog posts, I'll try to cover the why, the what, and the how. Before beginning, though, I'd like to be up-front about some of the "why not to go in this direction."

This ticket is about putting a site's common look-and-feel on each page. For the moment, I'll call this step "sitetheming". Should we have a special, simple facility for just this audience (integrators, entry-level Plone customizers) and activity?

However, not all will agree on the basic premise, so I'd like to anticipate some of these concerns up-front. If any of this sounds like you, please speak up during this process. The goal is to make something uniquely useful and simple for the non-core-developer audience. We certainly don't want to do something that you won't like!

(If you simply must read more about site themes, here is a writeup I made long ago on the Zope wiki and here is the introduction to Deliverance. Alternatively, wait until my next few posts.)

Why Not

  1. Plone 2.5 and/or Plone 3.0 is easy enough to theme. Falls into the "ain't broke, don't fix it" category. My sense is that "theming is hard" is a common complaint by the target audience, but perhaps I'm mis-reading the tea leaves.
  2. It's hard, but worth it. Currently, theming/skinning/templating/programming are all part of the same facility. This lets you do just about anything. Creating an isolated, stripped-down "theme engine" thus breaks that proposition.
  3. I'm both the developer and the UI person. If you're mostly a developer who also does the UI, you might not want to learn a new facility, as you're still going to be the person doing the page content generation.
  4. People will invariably stray over the line. We always encourage a clear line between presentation and content. However, the moment you have something straddling the line (e.g. the contents of a calenar portlet), that discipline feels restraining.
  5. I'll never have non-Plone. As part of this proposal, we'd like to encourage moving stuff out the Zope stack, allowing it to be applied across other Python stuff. However, that might not be your itch. Having a corporate ID that could be used with other Plone apps, or potentitally non-Plone apps, might not be a meaningful upside for you.
  6. Plone needs to stop changing. Integrators, and even some core Plone folks, are feeling bumfuzzled by all the machinery changes. They've reached their absorption limit. Thus, it wouldn't matter if there was a problem, nor if this was a good solution. It's a new way to do old stuff, and that's bad on the face of it.

That's some of what I'm hearing so far. Before we get into the details of what's on the table, who should care, and even how we can minimize these points, I want to make sure I'm listening to the integrators and entry folks. Any other concerns about this proposal in particular, or the strategic planning summit in general?

- Paul

posted at: 00:00 | permalink