Wireframes first

Here’s a pattern I’ve observed. Many website design clients, especially those who have never been responsible for a website project before, expect to a process that goes roughly like this:

1) Talk about requirements

2) Do a complete graphic design

3) Fully implement the design in the site

4) Then move on to building out the functional elements of the site and the content.

Unfortunately, modern web development processes don’t usually work that way.

The process usually needs to go more like this:

1) Identify requirements

2) Do sitemaps and wireframe mockups to get the functional elements and information architecture right

3) Implement the technical bits

4) Do a design to make it pretty

Lots of missed expectations can easily ensue. Educating clients to the point where they can understand a wireframe can be a big — and costly — challenge.

Plone 4: uses 29% less memory than Plone 3

Continuing on the theme of quick-and-dirty benchmarking of the forthcoming Plone 4 release, I decided to revisit an experiment I did about a year ago in which I looked at the memory usage on startup of Plone 3 vs. Plone 4.  In December 2008, I found that Plone trunk used 36% less memory on startup than Plone 3.1.7.

But back then, Plone 4 was still a long way off, so I wondered if things had changed lately.

So I fired up my 2Ghz MacBook with 2GB RAM, I started up Plone 3.3.4 and Plone 4’s current trunk, and Activity Monitor reported memory usage as follows:

That’s a 29% decrease in RAM usage for Plone 4, from 142.5MB to 102.5MB.

Sweet!  Plone is not only a lot faster than Plone 3, it’s also much more RAM-efficient.  Truth is, though, it’s not really Plone’s fault.  One of the big changes in Plone 4 is that it now uses Python 2.6 instead of Python 2.4.  Python 2.6 is quite a bit more memory efficient, and that’s where Plone’s gains are coming from.

So, thanks, Python team!

Update: See comments below from Hanno.  Turns out Python 2.6 is better at garbage collection, so Plone’s memory usage will increase less as it runs, but Python 2.6 actually causes Plone to use slightly more RAM at startup than it would under Python 2.4 (which Plone 4 does not support!).  But, thanks to all of the amazing work that the Plone 4 team has done to make Plone leaner and meaner than ever, Plone 4 more than compensates for Python’s slightly increased drag.  Whee!

Bonus: If you’re wondering why I clocked lower overall RAM usage when I tested this last year (97MB for Plone 3, and 62MB for Plone 4), you can blame Snow Leopard for that.  Running 64-bit Python makes it use more memory than 32-bit, and Snow Leopard, new since last year, is now (mostly) 64-bit.  You can avoid this by running your production sites on a 32-bit Python.  I’m just too lazy to do it right now.

Extra special bonus: One of the many benefits of Plone 4’s new “blob storage” infrastructure for handling files and images is that it is way, way more RAM efficient.  We don’t have hard benchmarks on this yet, but in one very large, heavily used intranet site with 16.5 GB of most documents and media files, the team at Jarn was able to cut RAM usage from 10GB to 3GB with substantial increases in performance.  We expect that most sites with large archives of binary files will see similar resource usage improvements as they migrate to Plone 4.

Plone 4: three times faster than Drupal, Joomla and WordPress

Plone 4 is about to leave its alpha testing phase and enter beta testing prior to a final release. Update: Plone 4 has made a final release; I’ve updated the graph.

One of the many things the Plone team has worked really hard on in this release cycle is improving Plone’s performance.   Plone core developer Hanno Schlichting has blogged about this a number of times, and deserves a tremendous amount of individual credit for digging deep into Plone’s innards to find and fix inefficiencies.

When I read Hanno’s most recent performance post, in which he shows Plone 4.0 alpha 3 serving up 22 pages/second without caching on his personal laptop, I  started to wonder how this compares with some of the other common CMS platforms out there.  I was pretty sure none of them could deliver more than 10 pages/second with zero caching or performance tuning.  So I did a bit of quick-and-dirty speed benchmarking.

I’ll start with results, then explain my methods.  As I suspected, Plone 4 is faster out of the box than some of the most common PHP platforms.  Lots faster.

That’s right:  Out of the box, Plone 4.0 served up 15.1 pages/second, that’s over three times faster than Drupal 7 alpha 1’s 4.1 pages/sec, Joomla! 1.5.15’s 3.6 pages/sec or WordPress 2.9.1’s 4.5 pages/sec.  Plone 3.3.6 our currently shipping release, turned in a snappy 9.4 pages/sec, over twice as fast as its PHP competitors.  Whee!

Testing methodology

Here’s how I tested.  Hardware was my 2GHz MacBook with 2GB RAM.  I installed Plone 4.0 using buildout, and used MAMP 1.7.2 to run the PHP products.  I did a default install of each product, no add-on modules, I used whatever default content and initial configuration each product provided.  (Joomla! gives you the option whether or not to install sample content, which I accepted.)  No caching was installed or configured for any system.   I measured performance of the homepage as an anonymous user with trusty ol’ ab -n 10, ran it a few times to get the systems warmed up, then noted the value where the runs stabilized.

Lies, damn lies and statistics

So, what does all this mean?  Well, honestly, not much.  (Although Hanno clearly has a faster laptop than I do!) This is obviously a crude benchmark.  I didn’t load up each CMS with realistic sample content.  I tested two pre-release products (Plone 4.0 alpha 3 and Drupal 7 alpha 1) against three production releases (Plone 3.3, Joomla! and WordPress).   All of these CMSes can easily pump out hundreds of pages per second with a little bit of tuning, reverse proxy and/or database caching (although many real-world users don’t bother with performance optimization!).  So, this benchmark is definitely not an accurate measure of the real-world performance of a site.  (Matt Hamilton recently explored this a bit.)

But I think that Hanno and the rest of the Plone team can be very, very proud of Plone’s raw speed.  And as Hanno points out, there are even bigger gains just around the corner; he’s targeting 50  pages/second (without caching), as his goal for Plone 5.

Automated shame and software maintenance

Andreas Jung recently wrote “zopyx.trashfinder,” a quick-and-dirty script for assessing whether folks releasing software via the Python community’s “PyPI” repository are providing minimal metadata and actually making releases.  (Andreas has been on the warpath against sloppy release management, it seems, perhaps having been recently frustrated.)

Andreas has assessed the zope.*, plone.*, and collective.* namespaces so far.  He found 2 of 167 zope.* products with metadata problems, 2 of 117 plone.* products with problems, and 15 of 325 collective.* products with problems.

I decided to run an assessment against the Products.* namespace, which also contains lots of Plone add-on products.  The news is pretty good… out of 250 products checked, only 4 had problems.

CRAP: Products.Clouseau==0.8.4dev - description < 40 chars
CRAP: Products.Clouseau==0.8.4dev - summary < 10 chars
CRAP: Products.Clouseau==0.8.4dev - no author and no maintainer email given
CRAP: Products.Clouseau==0.8.4dev - no author and no maintainer name given
CRAP: Products.listen==0.7.1 - description < 40 chars
CRAP: Products.listen==0.7.1 - no author and no maintainer email given
CRAP: Products.listen==0.7.1 - no author and no maintainer name given
CRAP: Products.LoginLockout==0.2 - no release files, no valid download_url
CRAP: Products.PloneInvite==1.1-alpha - no release files, no valid download_url

While I think Andreas is being a bit (characteristically) tough in his conclusion that “PyPI is the public data toilet of the Python community,” given the low rate of problems, I really love the idea of regular, automated sanity checking like this, or as Alex Limi and I have called it, “automated shame.”  I hope Andreas adds the product maintainer or author’s name to the listing in a future release. 😉

I’d love to see someone regularly interrogate all of the packages in Plone.org’s PyPI server with this query, and regularly publish the results to the Plone product-developers list.

Update: David Glick also referred me to Matthew Wilkes’ “mr.parker” which checks to make sure that PyPI packages have more than one authorized admins, in order to avoid the “hit-by-a-bus” factor.  Good stuff.

Even more sprint wisdom

Joel Burton, Chris Calloway, Chris Ewing and Chris Rossi (with some remote assistance from Alex Clark and Matthew Wilkes) just wrapped up an insanely productive sprint focused on improving ZopeSkel, the code generator for Plone integrators and developers.   At the end of their in-depth write-up, they share some golden “lessons learned” about effective small-group sprinting.

The No-Fun ZopeSkel BBQ Sprint accomplished 23 major tasks in four days primarily by four sprinters.

We are very excited by the productivity and usefulness of the sprint and feel there are some lessons to impart:

  • Smaller sprints are by far more productive.
  • Ruthlessly focused sprints are more productive. Having super-clear goals and not wavering from them is key.
  • Excluding topics which don’t exactly fit goals is not a bad idea.
  • Design discussion and documentation ahead of the sprint make for a more productive sprint.
  • Inviting capable sprinters with strong motivations and undivided attention is abolutely necessary.
  • Bounties are not all they are cracked up to be. They take a lot of work. There may be easier ways to raise travel expenses.
  • A work environment geared towards serious concentration with no interruptions or distractions is extremenly helpful.
  • Starting as early as feasible each day and working for about ten hours is most productive.
  • A lunch break which involves walking to a location away from the work environment refreshes the afternoon’s work.
  • IRC, Twitter, UStream and other open communication channels are distractions while sprinting. Help yourselves before helping others outside the sprint while it is sprint-time. There will be time to help others after the sprint and a sprint which doesn’t produce helps nobody.
  • Sprint now, report out later. Blogging is another distraction while sprinting. Help the sprint first.
  • Photographing whiteboards is a nice security blanket which doesn’t take much time.
  • Have the network set up the day before. Don’t go wireless. Have a high speed switch on a fat pipe.
  • Have a couple of nice dinners in the middle of the sprint. Make lunch fun. Eat BBQ every day. Have BBQ on your pizza. People who have fun together work together better.
  • Get plenty of sleep. Don’t stay out all night.
  • Get the nicest possible accommodations. Private accommodations entirely taken over by the sprinters are best.
  • Do not fit three people in the front seat of a pick-up truck.

There’s a lot of clean-up work left over from this sprint. We could have used an extra day. It would have been wrong to cut short the work being completed on the final day in order to make a second ZopeSkel release in four days. Plus, some clean-up work depends on the outcome of discussions regarding the previously mentioned splitting proposal. Suffice to say, there will be at least a couple of people merging branches into trunk at the Plone Conference 2009 Sprint.

Previous posts about sprinting:

Sprint Wisdom

More Sprint Wisdom

Sabbatical!

I’m pleased to announce that I’ll be taking a sabbatical from ONE/Northwest, beginning around July 20th and lasting through early November!

After 13 years at ONE/Northwest, I’m feeling a little fatigued. Worse,  I feel like I’ve become disconnected from the wellspring of inspiration that makes social change work possible.  I need to simultaneously unplug and reconnect.

I plan to use this time to relax, recharge, do some hiking, take some photos, read a bunch, talk with lots of folks and refill the idea-tank that has sustained my journey in the environmental and open-source movements over the past decade.   Of course, I don’t expect to find much of that inspiration in my navel, so I hope to be buying many of you coffee, beer and/or ice cream in the next few months, or at the very least to hit you up on Skype.[1]

I’m profoundly grateful to ONE/Northwest for getting a sabbatical policy in place and allowing me to beta test it.[2]  Time to recharge is an incredible gift, and it’s an amazing feeling to be part of such a supportive team and to know that the work will be in such great hands while I’m gone.

A few logistical notes:

  • My ONE/Northwest email will continue to work, although I will be checking it much less frequently.  Please feel free to email me (jonstahl at gmail.com) if you need to reach me.  I’m eager to hear about what is exciting and inspiring you to change the world.
  • Dave Averill is ONE/Northwest’s main point of intake for new work, so if you’re not sure who to talk to at ONE/Northwest about something, he’s a great starting point.  (davida at onenw.org)
  • Plone community friends: I’ll continue to serve in my role as Plone Foundation board president, and I look forward to seeing you at Plone Conference 2009 in Budapest this October!

Be seeing you!

[1] If that plan sounds a little vague, you’re right!  My plan is to have no plan for at least a few weeks.  I know many of you have taken sabbaticals: if there’s something I absolutely must do (or avoid doing), I’d love to hear about it!

[2] I hope we follow in the footsteps of Sightline Institute and make sabbaticals mandatory.  That’s hardcore sustainability!

Progress Towards A New Commenting System for Plone

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.

Auto-optimizing images in Plone

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.

Theming without tears

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.

Plone 4 and Plone 5: Plans and Progress

Geir Bækholt of Jarn just delivered a keynote talk at the European Plone Symposium 2009 in which he outlined the roadmap for the next two major releases of Plone.  You can skim through the slides here, but it’s worthwhile to click through to the full version so you can click on the “Notes” tab and read Geir’s notes to accompany the slides.

Squall: Perfect Plone blogging with Scrawl + Quills

I just did a little experiment today (prompted by a clever idea from Erik Rose) to see if I could achieve Plone blogging nirvana by mashing together QuillsEnabled and Scrawl.  Not only did it work, it made me cackle with such evil genius glee that I needed to write it up.

OK, so you’re probably thinking: Scrawl and QuillsEnabled are both blogging products for Plone — how could you possibly combine them without creating a rupture in the very fabric of spacetime itself?  And yet…

QuillsEnabled is content-type agnostic.  It just provides some very nice portlets (archive, tag cloud, etc), some smart syndication, and a sweet little blog-style view on a folder.  Just create a folder, hit “enable blog” in Actions  (which applies a marker interface to your folder) and start blogging.

Scrawl is in many ways just the opposite.  It provides a Blog Entry content type (a straight-up copy of a News Item), some default settings on the Blog Entry (comments enabled, and a blog-style view for the Blog Entry).

Either of them alone provides a pretty nice blogging experience in Plone.  But each is missing something.  QuillsEnabled can’t let you have comments automatically enabled on only your blog posts, because it’s just using standard Plone content types, and comments get enabled per-type or per-item, but not per-location.  On the other hand, Scrawl doesn’t have nice blog-style portlets, and setting up a blog in Scrawl involves a bunch more pointing-and-clicking than with QuillsEnabled.

Erik suggested that I could install both Scrawl and QuillsEnabled, then tell QuillsEnabled to use Scrawl’s “Blog Entry” objects as its “blog” type (which is a configurable option in QuillsEnabled).  So I did, and it worked beautifully!  I now have a blog based on Scrawl’s Blog Entry objects, which have a nice blog view and default to having comments enabled, wrapped up in QuillsEnabled’s lovely master blog view and portlets.

If you want to give it a try, here’s how:

  1. Add Products.QuillsEnabled, Products.basesyndication (required by Quills) and Products.Scrawl to your buildout.
  2. Install QuillsEnabled, fatsyndication and Scrawl in your Plone site.
  3. Add a folder; use the actions menu to mark it as a blog.
  4. Click the “configure blog” link in the Weblog Admin portlet on the right side of your screen.  Change the “default type” from Document to Blog Entry.
  5. Add Blog Entries to your blog and publish them.

Voila!  You’re now publishing beautiful Scrawl blog entries in a Quills blog.

Squall!

Warning: I have no idea if this is a good idea or a horrible one.  I certainly wouldn’t advise you to try it in production unless you know how to extract yourself from a sticky situation.

Why NASA Chose Plone, and What They Learned

Katie Cunningham, a technical lead at NASA, has written up a great three-part case study on her experiences managing a massive (and massively successful) project to relaunch the NASA Science website with Plone.

Part I: Why Plone?

Part II: Design and Development

Part III: Lessons Learned

Lots of great lessons in there about what it takes to manage a successful big-league government website project with a world-class open-source CMS like Plone.

And, while we’re on the topic of Plone for government agencies Ken Wasetis’ talk about Why Plone Works Well for Large Government Agencies is well worth watching.

I’m a published author

As of this week, and much to my surprise, I’m officially a published author!

Along with a dozen other talented Plone community members, I contributed three chapters to Practical Plone 3: A Beginner’s Guide to Building Powerful Websites.  A modest contribution the annals of technical nonfiction, to be sure, but I’m still tickled pink at the prospect of going into a bookstore and possibly spotting my name on the shelf.

I’m also really excited to have a beginner-friendly book on Plone 3 in the market.  I’m hoping that Practical Plone will ease folks’ climb up the learning curve to Plone mastery.  Enjoy!

TinyMCE for Plone: A quick review

I’m very excited about Products.TinyMCE, the new add-on product for Plone by Rob Gietema of Four Digits that integrates TinyMCE, the popular open-source graphical HTML, into Plone.

Background: Since Plone 2.1, released in 2006, Plone has shipped with an excellent graphical HTML editor called Kupu.  Kupu was a mature, capable product long before TinyMCE was a glimmer in its developers’ eyes, and Plone’s “batteries included” approach to bundling a high quality, cross-platform graphical editor is still a solid differentiating factor.

Of course, this being open-source, some people prefer alternative graphical editors.   There’s long been a decent integration of the unfortunately-named FCKEditor.  And the crew at OpenPlans have wrangled Xinha into Plone as well.  But, in my opinion, there’s never been a competitor to Kupu that equalled its features and improved on its usability.  Until now.

Here’s what I particularly like about Products.TinyMCE:

  • It gets the “Link” drawer right.  Kupu has two separate drawers, one for internal (inside your site) links, and one for external links.  That’s confusing and awkward for users.  TinyMCE combines these into a single drawer, and raises Kupu by adding point-and-click support for mailto: and https: links and control over whether links open a new window.  The overall design of the drawer is a lot cleaner and it feels a lot more responsive.
  • Similarly, Product.TinyMCE’s “Image” drawer is also a nice improvement.  Its features are basically equivalent to Kupu’s, although its support for image captioning is a bit cleaner.
  • Product.TinyMCE’s support for creating and editing HTML tables is pretty solid.  This was always a weak area for Kupu, and a very difficult task for any graphical HTML editor.
  • Products.TinyMCE handles Flash embedding in a clean and user-friendly way.  Flash embedding is possible in current versions of Kupu, but often feels a bit awkward and unreliable.
  • TinyMCE is a lot easier to extend with custom code than Kupu.  At least that what David Glick tells me.  😉

Nothing is perfect, though.  Here are a few areas where Products.TinyMCE is not quite up to Kupu’s high standard.  Some I know are already on Rob’s list, so I’m hoping to see them in the next release soon. 🙂

UPDATE: TinyMCE 1.1RC is out, and addresses most of my suggestions below, except for Plone 2.x support. Try it, it rocks.

  • Search support in the Image and Link drawers.  Kupu lets you search your site content in the insert Image and Link drawers.  That’s an incredibly powerful and useful feature, and it’s not there in Products.TinyMCE.  I know it’s high on Rob’s to-do list, so I’m sure this oversight will be remedied soon.
  • Kupu has a nice feature where you can link directly to an anchor tag in a page your Plone site.  Products.TinyMCE can link to an anchor within the current page, but not to an anchor on another page.  This is not a feature I use often, but it can be handy.
  • Kupu has a nice feature for automatically assigning anchor tags to heading styles, and managing them.  Products.TinyMCE doesn’t seem to have equivalent functionality.   Again, this is not a very frequently used feature, IMHO.
  • Kupu works with both Plone 2.x and Plone 3; Products.TinyMCE only works with Plone 3.  That’s probably not a deal-breaker, but worth noting if you’re thinking about a switch.
  • There’s a “save” button to save your draft without leaving edit mode; it works, but there’s no visual feedback to the user.

We’re about to start testing Products.TinyMCE with some of our users, to see if, like us, they think it’s more pleasant and powerful than Kupu.  If that pans out, we’ll likely start rolling it out across our Plone 3 projects.

And, one more thing…

One thing that would really help deployment of Products.TinyMCE on exisitng sites would be a script that could be triggered by a site administrator that would walk through all users and change their preferred editor to TinyMCE (or change it back to Kupu).  This could allow site admins to roll out a new editor without having to ask every user to manually change their preferences.   That would be a really great convenience that could really boost adoption.

ImageEditor 1.0 for Plone is out

Nathan Van Gheem has put out a 1.0 release candidate of ImageEditor, his fantastic image editing add-on product for Plone.  ImageEditor implements a slick, easy-to-use image editor inside of Plone.  ImageEditor lets Plone users quickly and easily resize, crop, sharpen and compress images they’ve uploaded without Photoshop.

A short screencast is worth a thousand words of description, so here you go: ImageEditor in 2 minutes.

Thanks, Nathan, for all the work you’ve put into making ImageEditor rock!  I can’t wait to start using it with all of our sites.

Brainstorm: Improving user management in Plone

The internals of Plone’s user & groups system got massively upgraded in Plone 2.5 with the inclusion of PAS (Plugabble Auth System).  Behind the scenes, we now have an impressively powerful, extremely flexible system for managing the entire authentication system.  It’s a great foundation. But while the foundation is sound, the more external-facing parts of the system could use some freshening up.

Here are what I see as the main problems facing site administrators and integrators:

  • Poor usability of user/group administration screens for site managers.  Think of how much we streamlined the “Sharing” tab from Plone 2.5 to Plone 3.  We need a similar effort here
  • It’s too hard to customize  member profiles — it requires changing lots of scattered forms & scripts.  Membrane and Remember offer a path to using Archtypes objects as member/group sources, which is a good idea.  But we can (I think) do even better soon.
  • User registration and user administration both use the same join_form.  That is somewhat inflexible.
  • Password confirmation/reminder messages have some rough usability edges.
  • Deleting users can orphan content they’ve created without an owner — need a way to reassign a user’s content objects when deleting the user.

Users & Groups in Plone 4: My vision

I think the key elements of Plone 4’s users & groups story could be:

  1. Dexterity-powered membership objects (“Membrane NG” if you will)  and reimplemented user management UI so it is powered by these Dexterity objects (“Remember NG”)  This should be Plone’s OOTB story.  This will give us easy user/group profile configurability.  Users are just content objects.
  2. Big usability cleanup to user management UI.
  3. Use PFG (or its Plone 4 successor) to create public user registration/profile forms

Other ideas

  • Include LDAP support out of the box (included but disabled) — review its usability so it is as easy as possible to configure.
  • We probably need a better story for attachig to a SQL source for user/group data.  (Problem with SqlPASPlugin is that it stores all newly created users in SQL, there’s no choice to store some users locally.)   Such a system probably needs to be made to use SQLAlchemy at its heart.
  • Password strength requirements w/ interactive feedback.
  • Through-the-web customization of registration confirmation and password reminder emails.
  • We need a really good tool for importing memberlists via CSV

Ok, that’s my first brain dump.  What’s on your mind?  How should Plone’s users & groups system be improved?  And more importantly, who can step forward as a champion for this important but often-neglected component?  This is a big opportunity to take ownership of a critical piece of Plone’s future.

A Few Thoughts About Idealware’s “A Good Email Discussion List Tools”

The good folks at Idealware have added another nice article to their “A Few Good Tools…” series, this one titled “A Few Good Email List Discussion Tools.”

While the article provides a pretty good overview of the space, it leaves out a few supporting details that I think are worth noting:

  • Idealware’s article mentions that many CMS platforms have some email discussion list support, including Democracy In Action, Convio, Kintera, Drupal and Joomla, but neglects to mention that Plone also has such features, through its add-on product Listen.
  • Idealware’s article mentions the great folks at Electric Embers, DGroups and OnlineGroups as nonprofit-oriented discussion list providers, but neglects to also mention the team at The Open Planning Project, whose OpenPlans service offers a very powerful, user-friendly web-and-email discussion list experience.
  • Idealware’s article gives rather short shrift to several powerful open-source email discussion list solutions that enable more sophisticated groups to take control of their own discussion list hosting. Sympa and Mailman are probably the two leaders.  Idealware dismisses Mailman in passing, saying it and (unnamed) similar tools “aren’t as easy to use as many others, and don’t include features like archives or online groups. They can also make it difficult to view or export a file of the list of subscribers.”While it’s true that Mailman and Sympa don’t have the polished usability of some commercial discussion tools, they do include web-based archives and offer simple subscriber views and one-click export of the subscriber list.  Some hosting providers may disable archiving, but that’s not the software’s fault.

    The host-it-yourself path is not for everyone, since it does require some technical expertise to configure and maintain, but that’s also true of many of the solutions Idealware does mention.

Overall, good article, worth a read.   I hope Idealware will consider incorporating some of these additional details to round it out a bit more.

Running Plone trunk under Python 2.6 on Mac OS X

Note: this is absolutely, positively not recommended for production.

I had heard that it was possible to install and run Plone trunk under Python 2.6, and that it would use substantially less memory (mostly thanks to Python 2.6 improvements).  It took a bunch of fiddling and some help from David Glick, but here’s how I did it on my Mac OS X 10.5 laptop:

Install macports
Make sure /opt/local/bin is in your path.
echo 'export PATH=/opt/local/bin:$PATH' >> ~/.bash_profile
Restart terminal
(NB you may have to sudo port commands)
$ port install python26
$ port install py26-pil
if it fails, try again, second shot worked for me.  ah, ports. ;-)
NB that you must either have an empty /usr/local or temporarily rename it to /usr/local-off while installing the port.   don't forget to name it back when you're done.  (see https://trac.macports.org/ticket/15077)
svn co https://svn.plone.org/svn/plone/buildouts/plone-coredev/trunk plone-trunk
cd plone-trunk
python2.6 bootstrap.py
python2.6 bin/buildout
bin/addzope2user user password
(to add an admin user)
bin/instance
Visit http://localhost:8080/manage_main and away you go!

To my delight, I found that it uses 62MB of RAM on startup; Plone 3.1.7/Python 2.4 uses 97MB on this machine.  That’s a pretty nice reduction.  I really hope we are able to deploy Plone 3.x under Python 2.6 soon, too!