What we're missing in Volto, though, is alternative layouts for content types. And although we have some support for block variations, we need to improve that.
Yeah. That would be nice to have as an option for certain use cases. Though, there is also the risk of ending up with an overcomplicated system. We have so many layers of flexibility already (content types, content type layouts, blocks, behaviors) that we have to think carefully about what to expose to the editors. This is why I think the content types concept still makes lots of sense, as a concept to grasp for editors. In the underlying system, your content types can all use the page content type, custom content types can offer variants (if that makes sense). Though, pushing flexibility from the top layer (content types) to layers below (layouts, variants) is something we have to be careful with.
I think the way you sold Plone 6 in your keynote is good. The idea that Plone 6 you can give admins the control to either give editors control or you restrict them as you needed to fit the organisations "content governance" needs. Plone 6 is a perfect fit as a content governance CMS.
But full control vs just one layout seems like a bit too limited choice for Plone 6 to offer long long term?
Even something like mailchimp has multiple template options so it's a very common idea that wouldn't not be confusing to editors I believe.
Keep in mind the ability to give editors a limited selection of fixed layouts has been a basic element of Plone for a very long time so while volto is adding more with TTW custom layouts per type or per page, this would be the loss of an existing feature also.
`
I also think we need fixed schemas (real types with fields) with layouts as a use case. Without that I would not consider the new UI complete. It is a valid and common use case for Plone. Without it Plone Classic UI would be needed forever, and I would really like to avoid this scenario. To me Classic UI is a) for migrations of existing sites and b) for use cases Plone covers but are not available in the new UI.
Can you elaborate here a bit? Because I feel that there's things about Volto that get lost due to communication. As far as I can tell, Volto supports "real types with fields" just fine, see https://volto.kitconcept.com/add?type=News%20Item and separate "view layouts" are easily achievable: Volto has an option in the menu for the View (check the "View" option of the three dots menu in the toolbar, here: https://volto.kitconcept.com/news) and this can be extended with custom components for any "display view id", as seen here: volto/src/config/Views.jsx at bba0552826546a2607e3bc57d4f18830c5f09cf1 · plone/volto · GitHub
Ok, maybe its more about documentation than about features?
1 Like
Indeed, documentation is maybe lacking. More towards internals or development.
Plone 6 and Volto has it all:
- flexible and powerful page building capabilities with blocks-based layout (this is the way to go for the future and should be standard for Plone content types IMHO)
- creating new content types TTW and applying a standard layout for it (creating a "News Item" content type for instance is trivial, so we could even ship without it)
- creating and applying behaviors TTW: old story, well known, fully supported by Volto
- schema based content types, for content types that need more structure, like "Event". Though, clients usually prefer the flexibility of the blocks based system over the schema approach. If you can have blocks, using schemas feels like ancient. Though there is a use case for this and Plone 6 fully supports that use case
- variants for blocks: blocks often come with a "variant" option that can be extended. You can extend the listing block with whatever listing variants you might like
- variants for content types: nobody prevents you to add a select field to your schema and then use apply different layouts based on this setting. Given the flexibility that we already have in the system, I don't see this as a major use case we should support out-of-the-box. But still, it is trivial to implement if you want it
The challenge for Plone 6 will not be to implement missing options. We have far more options than ever before. Far more flexible and powerful capabilities. The challenge will be to turn Plone 6 into "a product" that comes with some sane defaults that not expose all the options that we have (which would overwhelm end-users and maybe integrators).
We have a concept that works well and that is well understood by our users: content types and behaviors. The TTW story is complete with Plone 6 for the first time in our history. We should embrace the content types concept and combine this with the power of blocks. That should be the default IMHO. The rest is the flexibility that integrators can use depending on their use case.
That's the core idea of "power and control". Provide editors with an easy-to-use system that does not overwhelm them. Though, under the hood integrators have all the power and flexibility you can imagine.
4 Likes
@tisto maybe we should enable blocks for Events and NewsItems in plone.volto? I have a website where I've done that (and built an "Event details" block to show the event details, as it's implemented in the default view). Best of both worlds, if you ask me.
2 Likes
@tiberiuichim yeah. we do the same on all our sites. I would love to see your "event details" block (we did not bother to implement this yet and lived with the edit and view to differ). I think enabling blocks on Page, Event, News Item is the way to go for Plone 6. For this, we would need the "event details" block in core I guess.
1 Like
Can you explain this a little more as I see I got the wrong impression
What I see is there is the old concept of "views" which can be selected by an editor. These are presumably developer coded templates like old plone.
and then there is this layout concept which @tisto showed the video of
which at first glance from the video seems to only allow a single template per type.
Why not get rid of views and replace it with multiple templates? Seems like you only need one of these concepts not two competing ones that work in different ways due to historical reasons?
BTW, technically creating a view that appears in the view menu TTW in plone is possible. I did this in GitHub - collective/collective.listingviews with a little local component registry magic.
But I wouldn't keep the name "views". It was always a not very explanatory name to the user. Templates is better.
And the UI to change the "view"/template should be inside the editor not in the toolbar because users expect to change the appearance by "editing".
Yes. Too too many vague terms. @djay, you're right. I've pointed to "multiple views per content type", but "multiple layouts" (= content type default block templates) are not there yet. I don't know if they make sense except for the view page (if they're the same content type, they should be the same entered information).
So if I want to have a structured content type with the rich text field this wouldn't be possible in Volto? The News Item on Volto for example does not have a rich text editor.
Also thinking about migrations, it would be much easier to migrate to schemas than to migrate to blocks.
They do, but it's not obvious that it's richtext. In the "Text" field of the news item, write some words, double-click one of them and you'll get the richtext toolbar.
Yes but I can't for example insert an image or put a class in a paragraph, like in Plone Classic.
Yes, indeed. These are not technical limitations of the underlying framework, it's just that they haven't been implemented as buttons and features of the draftjs based richtext editor implemented in Volto. That is to say, if someone really needs to have those, they could be implemented. The dropdown menu with configurable styles is an already implemented feature of volto-slate, which replaces the default draftjs implementation from Volto with something based on SlateJS.
1 Like