Re: [Framework-Team] What is Plone 3.3?
> 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. > Hi, Just this year, my company trained more than 1,000 people to use Plone 3. These people are representative of more than 40 different companies that are currently occupying more than 100 different Plone sites. Proposing that a client pay again to have his or her employees trained anew would have an extremely negative effect on the Plone image and would make it seem untrustworthy. I believe that radical changes, that require the client to invest in new training, should be reserved for newer large scale versions like Plone 4.0 My 2 cents ;) -- Fábio Rizzo Matos ThreePointsWeb [EMAIL PROTECTED] http://www.threepointsweb.com +55 61 3202-6480 Python, Zope e Plone com quem entende do assunto! ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] What is Plone 3.3?
On 11. Okt 2008, at 17:47, Martin Aspeli wrote: - 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 +1 None of the above should go into the Plone 3 series, IMNSHO. We have made many of our integrators cry over the years, and I believe this has to stop. Plone is a player now and people are betting their companies on our technology. Predictable upgrade-paths and feature-sets are essential if Plone wants to be perceived as a "professional" CMS stack. I would certainly expect to be able to upgrade an application from version 3.0 to version 3.3 without having to rewrite it, or half of its dependencies. 2-cents-etc-ly, Stefan -- Anything that, in happening, causes itself to happen again, happens again. --Douglas Adams ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] What is Plone 3.3?
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
[Framework-Team] What is Plone 3.3?
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