Commenting is the building block of most “social” features on the web.  Plone has had commenting since its very early releases, and got a lot of things right the first time.  However, the web has become more sophisticated since 2004, and our “mostly good enough” commenting framework is now showing its age.  It’s time for a rewrite, and that rewrite is under way!  Here’s a short progress update, and an invitation to help out.

Thanks to Google Summer of Code 2009, Timo Stollenwerk is leading the work on plone.app.discussion, a modern, lightweight, easy-to-extend commenting system for Plone.   Martin Aspeli is serving as the project mentor, and is playing a large role in designing the architecture, project management and quality assurance — all with a goal of ensuring that we have code of sufficient quality to land in Plone 4 later this year.  I’m playing the role of the “customer,” helping to articulate and prioritize requirements and testing the results.

Check it out!

Our roadmap and progress log is public at http://www.pivotaltracker.com/projects/15135.  As you can see, we’re using an Agile development process on this, thanks to Martin.   Basic commenting functionality is now working, and we’ve got iterations planned out for the rest of the summer (and beyond!).  You can give our development version a try at http://gsoc.timostollenwerk.net/.  More experienced users can get their hands on the code with our development buildout.

I’ve been brainstorming a bit about how Plone do an even better job of helping non-technical website editors manage and optimize their images for the web, and I’ve come up with what I think is a pretty clever idea.  I have neither the time nor the skill to implement it, and so I thought I’d float it out there to see if

A) it holds water;

B) if I can’t interest someone in implementing it

The problem: big-ass images

Lots of people who edit Plone websites don’t really understand how to properly optimize images for the web via resizing and compression.   Plone is not entirely unhelpful here; if you upload an image, we automatically create several different resized versions for you to use in your pages.  However, Plone doesn’t currently do anything to help you make sure that original image you’re uploading is appropriately sized and compressed.

When you couple user inexperience with the massive image sizes that today’s digital cameras produce (6/8/10/12 megapixels!), the result is often a situation where users are uploading massive digital camera photos to their Plone sites, then using the PIL resizes in page.  While this works, it quickly produces a bloated ZODB.    In addition, the automatic PIL resizes don’t apply much compression, so the resized images aren’t very well optimized either.  This slows down site performance and causes lots of unnecessary server load.

There are a number of add-on products that can help in various ways, among them:

• Plone.app.blob and Filesystem storage, which push large binary objects such as images to the filesystem, reducing ZODB bloat.
• ImageEditor, the amazing Photoshop-like image editing program that runs inside of Plone.  It can do resizing and compression, but only one image at a time.  It’s a great solution for end-users, though.

These are great, but I think we can do better.

Some possible clever solutions

Here’s how I think we can do better.

First, some changes to Plone’s default behavior:

• Make the amount of compression that PIL applies to its resizes settable in the Plone control panel.  Right now it is hardcoded into ATContentTypes, and it’s hard to customize without rolling your own content types.
• Automatically resize all “original” uploaded images to 1024px.  Make it user-configurable, and disable-able for those rare occasions when you need to upload really high-resolution originals.

More daringly, I think that someone could write a clever add-on product for site administrators that would do the following:

1. Walk the site catalog, looking for all objects that are Image-ish and in JPEG format.
2. Look at the pixel dimensions and the filesize of each image.
3. Find images where the “bytes per pixel” (filesize/*(height*width)) is higher than a certain “reasonable” value.  (0.5 bytes per pixel seems about right to me, based on the idea that a 150X150 pixel JPEG image shouldn’t weigh much more than 10kb.  (Obviously, these settings should be user-editable.)
4. Present the user with a list of “suspiciously large” images, along with their pixel dimensions, filesize, bytes per pixel and a preview.
5. For the JPEG images, offer to apply additional compression to some or all of the selected images.  (Make value user-settable, maybe offer an opportunity to test it against 2-3 images, and estimate the savings you’d realize.)
6. For images that have larger pixel dimensions than anyone would want to display in a web browser, offer to resize the original image down to a user-specified size (1024 pixels seems like a reasonable default to me).
7. Apply compression via PIL, presumably in a background process so that Zope doesn’t bog down.  Rebuild Plone’s auto-resized images afterwards from this new original.  Purge caches as necessary.

So, whaddya think?  Is this sane?  Would you get value from these things?  Are there other low-hanging fruit I’ve overlooked?  Interested in helping roll the first two ideas into PLIPs for Plone 4?  Or building out the bulk image optimizer?  Or helping raise some money to sponsor such a project?  I’d love to hear from you.

The Plone community is hard at work on some game-changing innovations that will redefine your notion of what is possible with a content management system.  One of the coolest elements of this is Deliverance, a new system for “theming” (applying a custom visual design) to a Plone site.

Deliverance introduces the paradigm-shifting notion of “rules based theming” in which the theme consists of a simple set of rules expressed in XML which are capable of mapping chunks of a source page (raw Plone) into sections of a fully-styled HTML/CSS page.

It’s easier to see than describe: Nate Aune put together a fantastic set of slides about Deliverance for Plone Symposium East 2009, I can’t recommend them highly enough.

Even cooler bonus: Deliverance will let us build a new generation of “point and click” theming tools like Banjo, which Nate and Eric Steele whipped up during the post-Symposium sprint.  It’s a proof of concept, not ready for primetime yet, but it’s a pretty compelling glimpse into the future of theming.

This isn’t quite “mainstream best practice” for Plone yet, but it will be in the not-too-distant future.  I for one can’t wait!

One more thing:  Because Deliverance runs outside of Plone, you can use it to theme almost any web application!  I wonder if we’ll see Drupal and Joomla adopting Deliverance someday?

H/T to Elizabeth Zimmerman.