See you on 10-13 June 2014 in Barcelona, for the next Plone sprint: a jump towards the vision of Deco.

Plone Mosaic sprint: improving the contents editor experience in Plone

See you on 10-13 June 2014 in Barcelona, for the next Plone sprint: a jump towards the vision of Deco.

On the second week of June, between 10th and 13th, a new Plone sprint will be hosted in Barcelona, by "Universitat Politècnica de Catalunya": the Barcelona Mosaic sprint.

This is the natural outcome of one of the hot discussions that happened during last PLOG: how to improve the way we build pages in plone. The goal is to give to website editors a usable UX that let them take control over page composition and content presentation.

The sprint will focus on producing an addon to allow Plone editors to build pages using predefined blocks and predefined layouts.

Premise

A common requirement for many customers is to have the capabilities for creating and publishing beautiful composite pages (like landing pages and homepages).

The goal of the sprint is to have a solid product that will provide as much flexibility as possible for building those pages using a nice and comprehensible UI.

We already have some products that tried to address this requirement:

  • Collage
  • PortletPage
  • Cover

just to mention the most used ones.

All of them have their advantages, for instance: collage and portletpage allow to reuse the portlets of your portal to build the content, while Cover (the most modern one) use tiles and a grid composer to give the editors more flexibility.

But, all of them are far from the "Deco vision". Yes, because among the other addons, we also have Deco, or better, the "dream" of Deco. Deco is (or was?) an innovative way of building pages layout and sites layout that was presented at the Plone Conference in 2009 (!!). You can have a look at the slides of the conference and on the blogpost by Rob Gietema.

The technology that was prototyped at the time was a revolutionary tool that could push Plone ahead in terms of years compared to all the other CMSs out there. Nowadays, tools like this (like the one provided by Mailchimp) are something that customers claim to have by default.

Unfortunately, after getting a lot of interest and buzz and expectations, the project slowly became abandoned, because no one worked on it. Many are the reasons for this but we can assume that the main ones were: there was too much work to do and too few people to do that work in their spare time.

Vertical approaches

Inspired by this famous post from David Glick on how to use tiles without Deco, some developers started using tiles in their projects.

On this path, the guys from Simples Consultoria ended up creating Cover, based on their own use case.

We are using tiles for some customers, and during the PLOG I gave a short overview on what we have done for the Saucelabs project.

Our use case is plain simple: a lot of landing pages built with a well-defined set of blocks. We used tiles for creating those blocks and kept them as simple and light as possible. Beside editing the content in the blocks, since there's only one column the user can only arrange the order of the tiles. We built a specific JS UI for this, that allows users to add/edit tiles in place, without having to reload the page or to switch within a view for composing and a view for adding contents (like in c.cover).

The sprint

The main parts of the sprint, as stated on the official page can be summarized into:

  1. Provide a new page rendering engine that replaces main_template + multiple slots with a grid-based responsive layout.
  2. Provide a good and intuitive GUI for managing such layouts.
  3. Provide a mechanism for managing, storing and applying sets of layout rules.
  4. Provide a "good enough" backward compatibility for the core+addon ecosystem that expects certain outcomes.

The ways on how to get this done are still under investigation. The community is discussing them in an interesting thread on core dev mailing list.

Hopefully, a couple of things are already taken as assumptions to ease the work:

  • keep it simple, because we do not want to go off the rails and above all we don't want to end up again in a dead project;
  • reuse as much as possible, because we already have a lot of technology in there: portlets, tiles, viewlets, and above all the Deco rendering system.

We do not know yet how much of this technology we will reuse, but - as Asko said - we "like to learn from the history and avoid re-inventing too much".

Conclusions

The sprint is going to be awesome and we are sure it will get to an awesome result. The Plone editor experience has been left behind for too much time: let's fix this!

If you want to know more about the sprint and the discussions, follow the thread on plone developers mailing list and check the page of the sprint's project on coactivate.

Stay tuned! We'll keep you up to date!

 

 

Share this on

Share |

On same topics

Comments

comments powered by Disqus