@tkimnguyen does castleCMS change the display menu? It's still the single issue that causes me the most support problems so I can make a PLIP to change it to a popup instead of dropdown but if castle had a nicer solution with actual user feedback I'd like to use that. I would actually prefer it to be inside the edit dialog but that's a much harder change and even less chance to get any agreement on.
CastleCMS does not have that problem, it does not have a display menu. Folders and pages in CastleCMS use the Mosaic editor and don't need to select a page as the default.
In all content using mosaic you can have listings with seveal display options with preview, existing content that can display a page within a page and a lot more. (it's plone so you can still go to the url and change it if you want)
the Query listings in CastleCMS Mosaic actually has a preview similar to the one in the link you have
Edit (on folder): goes to folder edit with new layout tab that has options to change layout or select an item as default page.
has live preview embedded in iframe.
Edit (on page): won't allow setting as the default page. User would have to know to edit the folder.
maybe use info dialog with link to edit folder to select default page?
In that case of folderish items which can also be default pages. Then you get a warning to edit the folder like you currently do and they also have their own layout tab.
Edit (on default page): results in dropdown of "Edit Folder" "Edit Page" "Change displayed Layout/Default page".
Alternatively could just edit default page and have the same warning "you are editing the default page" but add "to change the default page edit the folder". Or have a layout tab but include the warning and link in there instead of allowing changing default page from inside the default page.
Edit (on a mosaic page): it would be: Edit -> properties -> layout.
could be a little confusing as there is already a Layout button on mosaic pages.
Here is the Volto part of the story: we kind of re-imagined the whole content creation story in Volto. There are no default pages any longer and Albert came up with a new way of creating content and blocks (which we implemented in Volto). Victor and I talked about this in Ferrara and I will try to write a blogpost about it.
Page templates/layouts are definitely on our todo list in the long run and I think Albert got mocks for that as well (you click on the "+" symbol and then instead of page types it shows you a list of page templates you can choose from), so rather similar to what is discussed here. I think Volto is already a lot closer to CastleCMS than classic Plone.
Though, our main focus is to finish the functionality that we already have and finish Volto 4 / Plone 6. We have to go step-by-step and got approval by the Framework Team for every change at the end.
Albert is the team lead of the Plone UX team, so he is the right person to talk to about UX issues and proposals (or Victor who is our connection to him).
Apart from that, we have to make a decision how to handle non-Volto PLIPs for Plone 6. For instance if PLIPs need to be implemented for the classic UI and Volto or not. This is something we have to discuss and decide in the Framework Team I guess.
Something meta here: Since CastleCMS is out I hear "when do we get this cool feature X into Plone core" (to some point valid vor PloneIntranet/Quaive).
In fact its first all about just doing it (I like the term DoOcracy here, even if its not very sharp and has many interpretations).
Write a PLIP, discuss it, get it approved, implement it yourself, find people (companies to send employees) to sprint on it (organize/support sprints), pay a designer/developer to implement, crowdsource money or development-time get it implemented, ...
Find like-minded to push the process together.
But whatever: you need to do it, like a seed in your garden needs lots of care to grow to a plant. Then the plant Plone can be harvested. And as it is software (=manifested/explicit knowledge) it gets more if its shared.
This is how Plone always worked. If we look at the current developments its still the main driver. Its how community driven FOSS works.
And even if a PLIP gets not approved: many features can be implemented just as add-ons.
Often its better to have just the generic hooks in core instead of an all-singing-all-dancing implementation - hey, we have the power of ZCA.
...and I appreciate the framework team's approving of this PLIP, despite there not being currently any heavy developer firepower behind it (this in itself is a big, and important, change in how the framework team sees PLIPs):
As Plone always developed out of the needs (mostly projects) and the resources/money behind, best is to collect those and manage them to get things done. If no one is willed to 100% fund the PLIP, but 10 do 10% (in coding resources or money) and i.e. you manage those (as one of the 10%) the probability that the feature gets in will increases a lot.