[Framework-Team] Feedback on New Collections for Plone 4.2

Jon Stahl jonstahl at gmail.com
Tue Jul 5 21:46:29 UTC 2011


Couple of thoughts and some background questions, thanks for starting this
thread, Alec.

1) Is it feasible to optionally automatically migrate old-style Collections
to New Collections (as I'll refer to them here)?  If not, why not?  This
seems like it would be hugely valuable, and eliminate most if not all of the
pain we are anticipating.

2) Thinking over Groundwire's 150+ launched Plone sites (going all the way
back to 2.0.5), I'm having trouble thinking of more than a handful where we
trained clients on building/modifying their own Collections.  And those few
whom we have are quite sophisticated and I'm sure would have zero difficulty
picking up the new UI.  So I'm not too concerned there.

3) Where I am concerned, though, is with add-on products. I can think of
quite a few widely used add-on products that provide custom views on top of
Collections (or Folders).  I'm thinking of products like:

* Scrawl (and similar blog products)
* PloneTrueGallery (and similar photo gallery products)
* EEAFacetedNavigation
* collective.flowplayer
* The various "fullcalendar" products e.g. solegma.fullcalendar

Would these products all break?  Do we yet know how much work it would be to
update them for New Collections?  If there is work involved to upgrade, can
we work to ensure that product authors have the information and time they
need to upgrade their products before 4.2 launches?

4) A meta-point: as I mentioned on IRC, and especially if no automatic
migration from Old to New Collections is possible, I think it's pretty
important to solicit some wider input/raise awareness about this well before
4.2 goes live.  I'd suggest engaging in some wider discussion on
plone-developers and product-developers.

:jon


On Tue, Jul 5, 2011 at 12:38 PM, Alec Mitchell <alecpm at gmail.com> wrote:
> Hello all,
>
> The framework team on the cusp of approving an exciting new
> Collections implementation for Plone 4.2 and would like to get a
> little feedback on how the migration process should work.  In
> particular, we would like some advice from people who have extensive
> user training and support experience.
>
> The add-on provides a new Collection type which is intended to replace
> the current Collection implementation from ATContentTypes  It does not
> provide a migration path from old Collections to the new ones.  Custom
> templates designed for the ATCT Collection type will probably need to
> be modified to work with the new collection type.  Additionally, the
> user interface for managing collections has been completely overhauled
> (entirely for the better).  For newly installed sites, the ATCT
> Collection type will probably be removed from the Add Menu and only
> the new Collection type will be addable, to avoid user confusion.
> However, there's some concern about what to do when migrating existing
> sites.
>
> There may be many existing sites which depend heavily on use of the
> ATCT Collections.  These sites may have invested time and money in
> training to use ATCT Collections (in part because ATCT Collections are
> amazingly unintuitive).  These sites may have developed custom
> templates for their ATCT Collections.  We want to make sure that the
> migration process is relatively painless and unsurprising for those
> sites.
>
> Do you, as people with extensive support and training experience, feel
> that it would be acceptable to disable adding of AT collections in
> favor of the new more usable collections during migration?  Is it
> likely that a significant number of deployments would be negatively
> impacted by such a switch?  If the old type were disabled, would clear
> documentation describing how to re-enable adding it be a sufficient
> mitigation?  Would it be preferable to keep the old Collection type in
> the add menu, but change the title to one which makes it clear that it
> is no longer recommended (e.g. "Old-Style Collections")?
>
> We would like to balance the need to provide a consistent environment
> for both new users and those migrating from an older version with the
> desire to make the migration both painless and straightforward.  Any
> feedback or suggestions you can provide would be welcome.
>
> Thanks,
> Alec Mitchell
> Plone 4.2 Framework Team
> _______________________________________________
> Framework-Team mailing list
> Framework-Team at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-framework-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20110705/a3c14db6/attachment.html>


More information about the Framework-Team mailing list