Plone Roadmap

May 2012

Plone Roadmap Team
<plone-roadmap@lists.plone.org>


Table of Contents

Plone Roadmap

May 2012

Plone Roadmap Team
<plone-roadmap@lists.plone.org>

Table of Contents

Introduction

About the numbering

Context

Plone’s purpose

Roadmap audiences

Plone’s competitors

Ideal size

Key industries

Plone’s differentiators

Guiding principles

The release process

Plone Roadmap - Overview Summary

The Near Term (6-12 months)

The Medium Term (12-24 months)

Longer Term (24+ months)

Near-term Roadmap

R1. Improved collections

R2. Adopt HTML5

R3. Support Diazo theming out of the box

R4. Improved content type development experience (through the web and filesystem)

R5. Improved calendaring and event management

R6. Make it easier for integrators to use jQuery UI widgets

Medium-term Roadmap

R8. Flexible page layouts (“Deco Lite”)

R9. Chameleon page template engine

R10. WSGI deployment

R13. Standardise on browser views for all templates

R14. Standardize on plone.app.registry for storing settings

R15. Move away from the catalog for navigation

Long-term Roadmap

R16. Unified rendering model based on tiles (“Blocks”)

R17. Page-centric content type model (“Deco”)

R18. Make the ZMI optional

R19. Simplified publisher and access control

Commonly feature requests

Introduction

The purpose of this document is to provide a “working draft” roadmap for Plone. This is more about synthesising current community views and activities than dictating a path forward, although in some cases the Roadmap Team may conduct surveys or other forms of analysis to suggest areas of focus that the community may choose to take up.

The main body of this document comprises descriptions of near, medium and long term items on the roadmap. The near term items will necessarily be more firm than the medium and long term ones, though over time – and as this document evolves – items may move between the time horizons. Towards the end of the document, we will outline broader feature requests and opportunities that may eventually make it onto the roadmap.

It is important to remember that the Roadmap Team is a facilitator, not a dictator, of community investment in Plone. As such, the whole Plone community is encouraged to join in the conversation around the roadmap, and challenge it where appropriate. The best way to do so, is to email the Roadmap Team at plone-roadmap@lists.plone.org, although discussion about Plone’s development – present and future – is best conducted on the Plone Developers mailing list (plone-developers@lists.sourceforge.net).

About the numbering

Each item on the roadmap is given a number, preceded by the letter R, as a unique identifier. Numbers are assigned in the order items are added, and do not signify priority or sequence. Numbers will never be reused, even as the roadmap evolves.


Context

Before we can outline the roadmap, it is important to put it in context.

Plone’s purpose

Plone is a general-purpose Web Content Management System, often used to create and manage public websites, intranets and extranets. Its advanced security model and strong workflow system makes it particularly well suited for sites where multiple content authors collaborate to maintain a website.

Plone also provides a rich development interface, allowing it to be used to build “content-centric” web applications, often where those applications are closely integrated into a broader, content-managed website.

Roadmap audiences

We expect the Plone roadmap to be of interest to the following groups of people, who want to know where Plone is headed as a product as they make decisions about whether to buy or use Plone for their projects:

Plone’s competitors

Plone is used for many purposes, and so can be seen to have many different types of competitors. Some of the main ones include:

Ideal size

Plone is used in projects large and small. It is difficult to put figures on the ideal size of a Plone project, but some key metrics may include:

Take together, this may mean that on the scale of Web CMS projects, Plone is often used for “medium-to-large” projects.

However it is very important to consider that Plone is also used for much smaller projects, either in smaller organisations, or by tinkerers and hobbyists. In fact, this is often a route through which future contributors and users gain their first experiences with Plone. It follows that Plone must remain (or become) easy to install, evaluate and get started with, for content authors, designers, themers and developers.

Key industries

Plone is a general-purpose CMS, not an industry-specific solution. That said, certain industries are represented more strongly than others in the community. Plone appears popular in:

This is, however, a great over-simplification. At http://plone.org/support/network, you will find sites and case studies for a range of industries.

Plone’s differentiators

The aspects of Plone that differentiate it from other WCM solutions vary between projects and users, but some frequently stated differentiators include:

Guiding principles

In developing the Plone roadmap, we have adopted a number of guiding principles:

The release process

Plone releases are driven by the community, and are time-bounded, not feature-bounded. In brief:


Plone Roadmap - Overview Summary

Anyone who has travelled realizes that a roadmap is different than a flight plan. A flight plan puts forth with great specificity exactly the path and timing of the steps involved in getting from one place to another.  A roadmap is a set of options, different places you can go, different ways you can get there.  A roadmap offers opportunities to change your path, pick up something new along the way, take short cuts when time is short, or pause to take stock when it is important to include as many inputs and options as necessary to be sure the final destination you have planned is where your passengers really want you to be going.

In the end, trips are about passengers - or, in the case of Plone, users.  Passengers help plan where they want to go, they provide input, directions and, periodically, ask "Are we there yet?"  Without passengers or goals, a roadmap is a mythical, meaningless thing - so the main goal we have in producing this roadmap is to let our users, developers, integrators, and those looking for a CMS know where it is Plone is going, as well as how we hope to get there.  

The Near Term (6-12 months)

In the short run, the path of Plone is well-known.  We have some specific must-have incremental improvements that our users and developers have told us need to be provided for Plone to remain standards-compliant, keep our strong points compelling and address common pain points.

In the area of standards, Plone will adopt HTML5, CSS3, and provide simple access to jQuery UI widgets. (This will be released in Plone 4.X.)

Plone's collections and content types are powerful, but each needs an improved user experience.  An improved interface for collections and developing content types - either through the web or on the filesystem - is being released in the next few months, most likely in Plone 4.3.

Theming Plone has long been an issue which made it more difficult for new users and integrators to approach that it should have been.  Plone will soon be supporting Diazo theming out of the box - providing a simple road to theming Plone for those who know CSS, but not about Plone-specific theming. This transition has been underway for some time, and there are already dozens of Diazo based themes available. (This will be released as part of the standard installation in Plone 4.3.)

Finally, we're improving Plone's calendaring and event management system to support better views and recurrence.  These are abilities expected in any modern CMS, and ones Plone will soon provide out of the box. This will be probably be released in Plone 4.3 or 4.4.

The Medium Term (12-24 months)

Beyond fixing issues of standards, UI weaknesses and pain points, the medium term roadmap identifies more ambitious changes which change how Plone works and how users interact with it.

We'll be separating the user interface for Plone from the content with an innovation called CMSUI - which will simplify theming and greatly speed up non-editor views of pages. We'll also add a system for creating complex page layouts using "tiles" called "Deco Lite." The combination of these two will make it easier to create precisely the pages you want, while at the same time removing the CSS and Javascript which slow down Plone for those using content rather than editing.

Under the hood, a new engine for rendering page templates much more quickly, known as Chameleon, will replace the current implementation of Zope Page Templates.  This system is solid and well-tested in production.  We're also adding support for WSGI for deployment and integration, which allows the use of many other web servers.

Another pain for Plone integrators and developers has been the use of many places and methods for storing information and presentation.  We'll be providing a standard method for handling forms (z3c.form), how pages are viewed, where Plone settings are stored (plone.app.registry), as well as separating information used in content search from information used to create navigation structures.  In each case, Plone becomes simpler to develop for and use, and confusion around "where is this?" is eliminated.

Longer Term (24+ months)

Longer term goals are necessarily less-specific, but represent fundamental changes in the basic paradigms of how Plone functions with the chance for gaining major advantages.

The next major goal is to fundamentally replace the way Plone stores and presents information by providing one way of rendering content ("Blocks") and reducing the number of content types in Plone from dozens to just two - pages and files with a model called "Deco."  This is a huge change for Plone, but the payoff is potentially huge, as is the reduction of complexity and ramp up in learning to develop.

The ZMI, a window into Zope 2, has long been a point of unnecessary complexity in managing Plone.  Another long term goal is to eliminate the ZMI, replacing it with a better set of control panels that allow Plone management in a more manageable way.

Another part of Plone which is powerful, yet unnecessarily complex as a result of a decade of organic growth and additions, is how we handle access control and publishing permissions. We are working to provide a simpler, easier-to build-on system for managing the sharing aspects of Plone with a more reasonable set of defaults.

Near-term Roadmap

The near term reflects the main PLIPs already underway and expected to land in the next release or two. For a full list of PLIPs, see https://dev.plone.org/report/24.

Goal

Incremental improvements to the Plone 4.x line

Status

PLIP reviews and implementation in progress

R1. Improved collections

Rationale

The Collection type (ATTopic) is powerful, but cumbersome. A better user experience would make Collections more useful.

Description

See PLIP http://dev.plone.org/ticket/10902 

Status

Merged for 4.2

R2. Adopt HTML5

Rationale

HTML5 provides more descriptive markup and is the latest HTML standard, in keeping with Plone’s tradition of being on the cutting edge of web standards

Description

See http://dev.plone.org/ticket/11300 

Status

Merged for 4.2

R3. Support Diazo theming out of the box

Rationale

The Diazo theming engine makes theming easier and more designer-friendly. By shipping with plone.app.theming, we can make it easier for integrators to develop Diazo themes.

Description

See http://dev.plone.org/ticket/11880 

Status

Merged for 4.2; more work continues to improve the through-the-web experience. See http://dev.plone.org/ticket/12227. 

R4. Improved content type development experience (through the web and filesystem)

Rationale

By allowing non-programmers to develop simple schema-based types, and making it easier for developers to get started modelling their specific requirements as content types, the Dexterity framework promises to make Plone more approachable.

Description

See http://dev.plone.org/ticket/11773 

Status

Approved for 4.3 - in active, production use as a separate installation

R5. Improved calendaring and event management

Rationale

Support recurrence and better calendaring views for Plone’s Event types

Description

See http://dev.plone.org/ticket/10886 

Status

Proposed for 4.3

R6. Make it easier for integrators to use jQuery UI widgets

Rationale

Plone uses jQuery, but currently avoids jQuery UI, mainly because its Theme Roller framework is considered too heavyweight for Plone’s needs. However, many integrators (and some core contributors) want to use jQuery UI widgets. Without a standard integration approach, there is great potential for conflicting integrations.

Description

See http://dev.plone.org/ticket/12350

Status

Proposed for 4.3

Medium-term Roadmap 

The medium term reflects changes that will require one or more major Plone versions to be refined, and which are more ambitious in nature.

R7. Separate CMS user interface from content (“CMSUI”)

Rationale

Make it easier to theme and customise the public face of a Plone site without having to worry about the markup, CSS and JavaScript that make up Plone’s editing UI.

Description

Separate the editing UI into its own iframe, with separate resources, using overlays and other techniques to provide a contextual but technically segregated editing experience.

Status

The plone.app.cmsui and plone.app.toolbar packages are under development

R8. Flexible page layouts (“Deco Lite”)

Rationale

Complex page layouts are currently difficult to achieve using out of the box solutions, and third-party packages such as Collage are not very user friendly.

Description

The Deco editor allows for advanced page layouts using the concept of tiles. The full Deco proposal also envisages other changes to Plone’s content type model (see below), but by separating out the page layout component into a standalone package, we can support flexible page layouts without the other, more invasive other Deco changes.

Status

Work has started on a slimmed-down plone.app.deco and plone.app.layoutpage.

R9. Chameleon page template engine

Rationale

The Chameleon implementation of Zope Page Templates is faster and more powerful than zope.pagetemplate.

Description

Chameleon is a faster, drop-in replacement for Zope Page Templates. It has been in production use for a long time and offers significant performance benefits.

Status

Ploud.com, a cloud-based Plone hosting product, now runs Plone 4 with Chameleon exclusively and is reporting success.  However, the Framework Team has decided to hold off on shipping Chameleon as part of the Plone core until Plone 5, mainly due to potential compatibilty issues with existing addons.  (We encourage addon product authors to test Chameleon compatibility and fix any issues.)

R10. WSGI deployment

Rationale

Most Python web frameworks now support WSGI as a deployment and integration mechanism. This will allow use of other web servers, such as Paste, CherryPy and mod_wsgi in Apache.

Description

Zope 2.13 supports a WSGI version of its publisher, which should be a drop-in replacement.

Status

Needs documentation and extensive testing.

R11. Standardise on jQuery for all AJAX operations

Rationale

Supporting both KSS and jQuery adds unnecessary complexity and page weight. jQuery currently has the mindshare.

Description

Turn KSS into an optional add-on and don’t ship with it Plone out of the box.

Possibly provide jQuery-based tools to support server-side KSS commands.

Status

Some work has been done by various contributors, but needs a champion and a PLIP.

R12. Standardise on z3c.form for all generated forms

Rationale

Forms in Plone currently use a mixture of CMFFormController, zope.formlib and z3c.form. The latter is most modern and forms the basis for Dexterity and tiles.

Description

Rewrite existing forms in Plone core using CMFFormController and zope.formlib to use z3c.form and deprecate the other libraries.

Status

Some work has been done by various contributors, but needs a champion and a PLIP.

R13. Standardise on browser views for all templates

Rationale

Using both CMF skin layers and browser views for templates is confusing and requires integrators to learn multiple technologies.

Description

Rewrite templates currently using CMF skin layers to use browser views. Promote z3c.jbot as the primary template customization technology.

Improve plone.app.customerize to provide a better through the web customization story and improve cohesion with z3c.jbot.

Status

Needs a champion and a PLIP.

R14. Standardize on plone.app.registry for storing settings

Rationale

Settings in Plone are stored in a multitude of places, such as portal_properties, various tools and the Plone site root. Plone.app.registry provides a robust and scalable settings storage that is easier to interact with in code and through the web.

Description

Change uses of other settings storages to use plone.app.registry instead.

Status

New code generally uses plone.app.registry, but this needs a champion and a PLIP.

R15. Move away from the catalog for navigation

Rationale

The catalog is currently used both for content searching, and for building navigation structures such as the navigation tree and folder listings. This means it has become bloated with indexes to serve both purposes.

Description

Add __parent__ pointers for all content to make parent traversal work without acquisition.

Optimize ZODB storage for content items to make it cheaper to load a few dozen objects on each request, reducing the need for catalog queries.

Make basic batched folder listings and navigation tree constructs use object traversal instead of catalog queries.

Status

Needs a champion and a PLIP.

Long-term Roadmap

The long term roadmap incorporates items that require more radical changes to the way Plone works, and so may require several major releases to land.

R16. Unified rendering model based on tiles (“Blocks”)

Rationale

Views, viewlets and portlets provide slightly different ways to render HTML, and often assume knowledge of Python or ZCML. Tiles provide a simpler rendering model, and with the Blocks layout engine, it becomes possible to compose dynamic and static content naturally and easily using HTML5 constructs.

Description

Change the main_template paradigm to use plone.app.blocks rendering, which relies on HTML markup conventions and HTML5 data attributes to specify how pages are composed.

Deprecate and remove portlets in favour of tiles.

Use viewlets in a much more limited capacity, or perhaps not at all, out of the box.

Status

The components are largely finished (plone.app.blocks, plone.tiles), but more work is required to understand what changes should be made to existing templates.

R17. Page-centric content type model (“Deco”)

Rationale

With tiles and the Deco editing experience, it becomes possible to rationalize the number of content types down to two: Page and File.

Description

Pages become containers that can be based on predefined template layouts administered through the web. Folder listings (Collections, Folders), calendaring support (Events), lead images (News Items) and other aspects of content simply boil down to the application of tiles, either ad-hoc or through predefined template layouts.

Status

The design is in place, but this requires more advanced and user friendly tiles, and more in-depth consideration of migration issues.

R18. Make the ZMI optional

Rationale

The ZMI, provided by Zope 2, is clunky, difficult to maintain and susceptible to cross-site request forging attacks.

Description

Through better control panels, Plone could make the ZMI unnecessary, and a large amount of code could be removed from the standard Plone distribution.

Status

Not started.

R19. Simplified publisher and access control

Rationale

ZPublisher and AccessControl are incredibly complex, supporting a decade’s worth of corner cases and semi-deprecated functionality. A simpler model would be easier to maintain, debug and build upon.

Description

Provide a better publisher and security module that support only the main use cases (e.g. __getitem__ traversal only, no attribute traversal), and provide on better defaults (e.g. default deny security, remove the involvement of docstrings in determining whether a method is publishable).

Some changes to Plone and add-ons would be expected.

Status

Not started.


Commonly feature requests

The table below captures some of the more common feature requests, which should influence the roadmap. See also http://plone.uservoice.com.

Feature

Comments

Better content import/export

Transmogrifier is expected to be the technology to support this, and is used successfully by many projects. It is still a framework and not a product, though.

Better accessibility

Probably fairly low hanging fruit, but requires investment of time and research.

Better Microsoft Office integration

Various technologies exist to support this, but we do not have a clear vision yet for how to make this into a polished solution for end users.

Static content export/mirroring

Various projects have had success with ore.contentmirror, but this still requires a fair amount of custom integration.

Better mobile device support

Mainly about CSS (and testing/maintaining that CSS), but we should also consider whether we need certain mobile-optimised pages, e.g. search, basic content browsing.

Better support for cloud deployments

Ploud.com is paving the way here, but we should also provide ready-made images for common cloud platforms, e.g. Amazon EC2. We should also consider platforms such as Heroku.  Supporting WSGI will help here.

Support multi-location content (symbolic links)

This is quite difficult to do properly (and support 100% of edge cases) without rethinking the content repository model. It may be possible to find a solution that works for 80% of use cases and degrades gracefully.

In-Plone product search and install

This presents various technical challenges, but would make the discovery and evaluation of add-on products much more approachable. Editing and running a buildout is a major stumbling block at the moment.

Multi-site / sub-site support

The Lineage product provides this to an extent, but there is no out-of-the-box solution, and content reuse is still a stumbling block.

Better batch operations

Working with content in batch usually requires scripting. Look to e.g. Flickr for examples of UIs.