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