Martin Aspeli wrote:
Hi,
Hi Martin,
I hear you loud and clearly ;-)
Actually I even share all of you concerns.
And I was just about to propose the add-on approach
while reading your message. I would agree that if
we are providing such changes in the 3.x series
site admins should be able to decide what they want
(and some things wouldn't even need add-ons like the
moving of the 'manage-portets' link: adding an invisible
site action and giving the link a dedicated CSS class
should make it pretty straight-forward for people who
want that change *if* it is properly documented).
In particular the printed books are a strong argument
from my POV. Just imagine a brand new book coming
out in a few weeks from now and parts of it are already
outdated. That wouldn't fit my understanding of what
we want 3.x to be.
Raphael
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
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
