Hi,

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.

Cheers,
Martin

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


_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to