[Framework-Team] What is Plone 3.3?

Martin Aspeli optilude at gmx.net
Sat Oct 11 15:47:51 UTC 2008


Over the past three days of conference chatter, we've been talking a lot 
about how we're proud of Plone 3.x being "boring". It's stable. 
Upgrading is safe. Improvements are incremental. You and your users 
don't need to re-learn lots of things when moving from one 3.x version 
to another.

Now, several PLIPs are being proposed for 3.3 that I feel would break 
this mantra. They are not accepted yet, obviously, but I think it's 
important to be explicit about our intentions.

*If* we agree that we want to retain stability and predictability across 
the 3.x series, then we have to accept that:

  - We can't remove, change or move major pieces of the UI.
  - We can't break add-on products and (sane) customisations.

This means that we sometimes have to delay perfecting things until at 
least a new major release.

There are books in print (and about to go to print) about Plone 3. There 
is documentation on plone.org that we can't (and shouldn't) "just 
change". People have received training and  spent time learning how to 
use Plone. If the UI changes, they have to be re-trained. "Just moving a 
link" may not seem like much, but I guarantee you that it will cause a 
lot of pain and frustration.

Right now, the things that concern me are:

  - Adding a new way to add content (the "add sibling" proposal)
  - Moving the contextual "manage portlets" link somewhere else
  - Removing the "display" menu and putting the behaviour on the fieldset

(the last one is doubly bad, because it would require any add-on product 
that used this menu to be updated in a possibly backwards-incompatible 
way, to add a field to replicate this, and we'd need a unique solution 
for non-AT content).

Note that I actually agree with all these changes: The display menu 
causes confusion; the manage portlets link is ugly; adding a sibling 
object is too cumbersome. However, we should solve these problems 
properly in the context of Plone 4, not make tactical changes in 3.x 
that cause confusion and break documentation.

Luckily, there's a "workaround". :) All of these changes could be 
provided with easy-to-install add-on products. These could be tested on 
real users and used by those who want different behaviour.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

More information about the Framework-Team mailing list