Keynote: The User Experience - Editing Composite Pages in Plone 6 and Beyond
Panel discussion at Plone Conference 2020
It may be a surprise to non-technical people to learn that pages created in Volto are not currently interoperable with traditional Plone's page editing. If you think about it, the reason becomes obvious. Volto, like Mosaic, creates tiled layouts, and like Mosaic it stores page data in special fields for the individual blocks and their layout. Neither Volto nor Mosaic pages are editable in TinyMCE, which expects just one rich text field.
Is this divergence between sites created in Volto and sites created in traditional Plone a problem? It does make it harder to describe what Plone is, and it might mean that there is no way to mix both approaches - for instance when part of a larger site is available as a Volto-based sub-site. Would it be possible to have one tool and one representation for tiled layouts so that we can avoid this divergence? Is there some other solution? Is it even a problem? Will Plone 6 be backwards compatible with Plone 5 and include a smooth upgrade path?
We will tackle these questions in this strategic panel discussion, moderated by Sally Kleinfeldt. Panelists will include Paul Roeland, Philip Bauer, Timo Stollenwerk, Victor Fernandez de Alba, and Eric Steele.
First, Philip has a message from Max Jacob who is very ill with pancreatic cancer and may not survive this weekend. He wants to thank the Plone community for what they allowed him to do: like organize the German Plone Konferenz. Thanks for all the friendships. Such a pity that this is happening now, he wanted to jump into only doing Plone for the next few years, due to changes at his job, and looked forward to that.
We have Classic, Mosaic and Volto Pages. They have different internal representations and are not compatible. Is this a problem? Is there a solution? Is one tool, one representation possible? If we really need three, how to position?
Paul: for me as user this presents a problem. When do you switch over your site? We would like to not write 700 pages from scratch, again, like we did for previous composite pages.
Timo: We migrated quite a few large projects from classic Plone to Volto. One of those had collective.cover (other composite page system). Problem in general with such systems, is that they are pretty specific. They solve specific use cases and come from different eras. After any migration, it will not look the same any more. Whatever you do: the page will initially look ugly. So you put a lot of effort into migration, but then have to put manual effort into every page anyway. It can help: you at least have a start. We created a system where we migrated overview pages, and editors could click to migrate other pages one at a time.
Philip: We have code to migrate from non-folderish to folderish content types. There will be code to migrate to dexterity site root on Plone 6. We can make sure to migrate any standard content types. Mosaic is another story. So for pages you would at least have the text available. Maybe only visible for editors to pick and choose from. You may lose portlets, unless they get implemented in Volto.
Timo: When you go to Plone 6 and do a redesign at the same time, then you can jump on Volto. Otherwise you could stay at Classic Plone for now. There will be an overlap period.
Victor: For Mosaic you could dump all tiles into html and insert it in a block.
Victor: Definitely doable, though we have not done this ourselves.
Sally: But what happens when an editor in Classic goes to the Volto subsite? The Volto page would not be editable then, right?
Philip: You should not offer this. I see no upside, no use case. Split them into separate applications, with shared authentication maybe.
Paul: Use case: large site with several departments. The marketing department may want snazzy new Volto things.
Timo: Just create another site then.
So you just had a big migration to Plone5, and now what would you get for going to Plone 6.
Philip: We have this discussion every major upgrade. Communicate every upgrade as a relaunch. The relaunch is the reason for the upgrade. "There is a new version so you need to upgrade" does not fly for my clients.
Timo: We became a very developer oriented community, and every develop understands the need and benefits. We should really get back to giving more value at major releases, so clients really want to upgrade themselves. Plone releases should sell themselves.
Eric: It looks like we think Plone 6 + Volto is a costly upgrade with lots of benefits. For Classic 5 to Classic 6 the upgrade is not costly.
Was this fulfilled by Mosaic? Volto? Something still needed?
Paul: Not quite, but slowly getting there. For me it would be Volto, plus some power features that Eau de Web (EEA) adds.
Timo: I think we went beyond what Limi envisioned.
Eric and Victor: What we have seen from Volto, is pretty close to what Alex wanted.
Victor: We gave the users powerful tools, so beware of them.
Philip: Partly yes. Volto is close, and it is for normal users.
Now some questions from users.
Philip: This should be doable.
Philip: Plone 4 to 5.2 was three migrations in one. Plone 6 is less of a problem.
Eric: 5.2 had a lot of backend migrations. A split between backend and frontend with plone.restapi in between makes things easier.
[The question on multiple variations of Volto, especially editors, went a bit too fast for me to write intelligible notes down.]
With Volto the trend seems mixing/adding 40 different blocks for every page.
Timo: Blocks are definitely the way to work. But the underlying power of content types and behaviors still exists.
Philip: We need blocks that represent a field or a behavior. That is unavoidable.
Timo: We plan to have an open space on page compositions and Volto, and want to sprint on it.
Paul: Good if there is a longer term vision. I would rather have more power that a Site Admin can lock down, than having to choose between three different versions. I don't want choice stress.