@tkimnguyen I like the ideas in the open decision framework but it doesn't seem to be a framework but rather some ideas and tips the loomio thing doesn't seem to be structured enough.
I'm not sure if there is a tool that does what we need but I'd suggest some kind of online process where we first
list all the ideas of things we can do to plone. Every effort idea we have. Eg consistent icons. Upgrade to python 3
Then we categorise them into the problems they solve for our target customers. e.g. Editors don't get confused in X dialog? ... Python 3, who most benefits from that again?
This is not an easy process.
Then we try to tag each with similar sets of priorities. What helps plone become more popular sooner. What has to be done. What makes core developers job easier.
My preference is focus on grass roots popularity but we need to decided together on the priority.
Then try to keep all this reasoning in one place and talk about in different ways so everyone has a good idea where we are heading and why and why its good for everyone long term.
And we be disciplined and stick each task.
Then hopefully this can feed into GSOC, what makes for a good strategic sprint, what FWT should be approving and just generally inspires more PR?
Wix want to be a CMS ? why not, at the moment they have not a track record at it. If they succeed they will have to follow the track record of succeeding CMS: the one making the third-party developers the most welcome (easy to develop, stability, responsiveness to bug reports, not too painfull migrations). If they don't, they won't succeed as CMS,
I don't think the distinction is artificial. You can succeed at both market if you have the right resources.But it dont' change the fact that rules are different.
As others mentioned already, we will have the server side rendered UI still for quite a while.
There will be alternative UI's from the ClientSide world, but before this will replace everthing else, there will be a lot more watter going down the rivers.
Mosaic is a good and useful thing. We should put some effort in it to make it a bit more stable and add some more nice templates, especially for the listing tile (collections). At least for the content area I like to have Mosaic in all my projects. There is some room for improvements as in the management of the custom layouts, but that does not mean it isn't useful as it is. And the core elements the tiles are already in the core and are quite useful.
We should define a way, how one could use it as a default for all pages or for just some custom content types, which is what I usually do. The custom content type way is nice, because you can wire it with a Mosaic content layout template together and enable it by default.
Maybe plone.app.mosaic could add another content type which is a basic Item (Page) like content type with just the default behaviors enabled and Mosaic enabled be default. This way users could just add these Mosaic page and use Mosaic easier. You could still add normal pages, there is nothing wrong in this, if you don't need a more complex content layout.
This in place I don't see why we shouldn't ship Mosaic with Plone core. It will not replace anything and doesn't have to be enabled by default as the working copy support is not. But it's way easier to use then and also good for the marketing team.
Let's improve Mosaic now and use it. Even if not for any use case, but for content layout it's preatty useful. @datakurre you made some improvements for your university. Do you have a plan when you can move this into the package?
As said, I truly agree that as long as Python based server rendering is required Mosaic stack solves real issues. And I'm happy how we are able to use Mosaic stack for developing and deploying WYSIWYG editable layouts without limits or restarts...
But still, in my opinion, PLIP for Mosaic into Plone core would not help fixing the current issues in Mosaic, but might just create new ones.
About our customizations on top of Mosaic:
My public plone.app.mosaic branch do include a few new features, but I've been waiting for 2.0 to be released before merging most of them:
support for configuring tiles defined on fixed site layout panels without verbose Mosaic grid syntax
support for showing multiple tiles of same type but with different default configuration and "tile name" on Add-menu, e.g. to have separate menu entries for different theme fragment tiles
support for custom field tiles, e.g. for configuring a themefragment as replacement to image field tile just for some specific content type field
My pending plone.app.tiles branch includes support for fieldsets in tile forms, but is still waiting for me to write a test for it. (There's another branch related for better support of image field tile during drafting, but it's even less ready.)
All of our ESI -related fixes should already been included and released in plone.tiles and plone.app.blocks. Collective themefragments has support for configuring fragment specific caching rules.
We still have an unreleased private transform to enforce and optimize ESI for all reasonable tiles (without need for inheriting tiles from ESITile class). Together with a small patch to plone.app.caching and some Varnish configuration it also allows us to cache ESI tiles for logged-in users (cached per different set of roles) in safe manner.
Seems to be that the only blocker on Mosaic is Pastanaga. There doesn't seem to be any other mosaic rewrite on the horizon and It's still unclear to me if Pastanaga will or won't include a grid layout editor. Can anyone confirm if it does for sure? Assuming it does then the possible scenarios are
Pastanaga is mature enough this year, is part of Plone 6 and is done in such a way that it solves all the issues mosaic and other UX fixes are trying to solve. and doesn't create a massive learning curve for existing integrators such that get turned off and prefer to switch to something else like wagtail or drupal.
Pastanaga is more ambitious that first thought and to prevent the above pitfalls takes a few years. In this case then we ship Mosaic with Plone 6, probably switching it to use css grids.
No Pastanaga for a few years and Mosaic remains as plugin unfinished state. Slips further behind competition. I guess plone 6 would ship with no different UI and possibly just python 3 compatibility?
Anyway we can fill in the gaps on this? Comments on whats most likely?
They are working on an editor, which will probably be able to do that at some point. But there will be a lot of changes, because the data will be Jason and not html as now. So this will be a complete new stack. I'm curious what we will see in Berlin from Timo.
But I'm with @datakurre there is no advantage in putting it on the list for the core. We have to fix some issues and make it better. That's the way people will use it. If it is good enough, it can go core easily. If not just being a good add-on is not a bad thing.
I agree with @djay. We are waiting (and waiting) for 'perfect', and maybe users are moving (or not coming) in the meantime.
Also: I think some products could be included in buildout (or at least be added 'commented out'). Those that 'know Plone' dont 'just install a lot of add-ons', while the 'new ones' want to 'test what is possible', and since the 'products' section of Plone (5) is not working, they might not find any (and then decide to use another CMS)
Please: at least add it with a comment or warning.
… imagine if you were a new Plone user and wanted to make a 'complex' front page.… Would you know what to search for and add to buildout ?
The problem is that mosaic is not complete and work has stopped. In part due to Pastanaga and uncertainty about the JS story of Plone. Is that a fair assessment @datakurre?
In my opinion, Mosaic development has been slow because it seems to be ”good enough” for those current users who have any resources to develop it. And those resources aren’t much. Personally, I have not been able to touch Mosaic code for months (because our users have mostly learned to work around the current issues).
Castle forked Mosaic editor, so Mosaic doesn’t benefit from Castle bug fixes (beyond the initial development by Nathan).
Those who really have frontend development resources or skills don’t want to touch Mosaic either because they don’t need Python based server side rendering or know enough about JS to run away from the current editor codebase (it kinda works, but its coding style is prone to bugs and it is not fun work on - it is not react, vue, angular or elm).
Can someone please comment on the future or the current state of Mosaic regarding
usage and support of CSS3 grids
usage and support for webcomponents
auto-layout of items within a slot
?
We are currently investigating and we will invest into a mosaic-ish solution based on VueJS web compontents without client-side rendering (in contrast to the traditional Mosaic approach with server-side rendering).
We have a prototype (without Plone integration) here:
Fortunately we have two upcoming projects and therefore a reasonable amount of money for bringing our approach forward. Get in touch if you are interested.
What if castle merged those changes back in? @tkimnguyen?
The problem I see is that mosaic was the future. Now Pastanaga is the future. Later X will be the future... The future always seems to be half implemented before core developers find something new and shiny leaving something that puts too much work onto integrators to make work.
If we are going reimpliment mosaic in react then lets fund that and do it. Otherwise lets find a way to finish mosaic good enough for core.
Waiting for something like pastanaga that is too ambitious, too backwards incompatible and too likely to be lose functionality and be half implemented seems too risky to me.
I want CSS3 grids, but it would result in half-rewrite of the editor (to get rid of its HTML grid markup from 2009). Having a separate grid editing mode from in-line editing of tile contents might make sense to avoid accidental grid edits. Reusing your grid editor might be possible...
Why webcomponents? I don’t see big difference from Plone proprietary patterns (beyond a standardized way to configure and initialize). Will they be adopted beyond Chrome?
Could you explain ”auto layout” feature more. It sounds something we might have solved in some other way.
I can't see any solution that doesn't have a serverside rendering option being general useful to plone core. Unless its 5 years in the future, the JS wars are over and one single framework has won and no one needs plain html websites or progressive enhancement anymore. I can't see that happening in the next year or 2.
Why web-components? Everyone is jumping on the client-side rendering train. Web-components (or their implementations in frameworks like VueJS) follow this approach and give us various improvements - in particular isolation and incapsulation of state and data. And of course reusability.
"auto-layout": in our upcoming projects we have a lot to deal with tiles. If you drag a tile into a container then it must be placed based on the position where you dropped the tile...something in the sense of Isotope.JS if you the size of your tiles is not consistent or different.
Got your point because I was not precise enough. We are not focusing on a complete client-side rendering but for supplementary informations like stuff in side slots (known as portlets) or visual elements or walls with tiles we will be using client-side rendering with web components based on VueJS.
Well, my opinion, Plone has tried to do that already with KSS, then jQuery plug-ins, now patterns. The current Mosaic editor only supports patterns within tiles, but support for more “native” front end components is basically a missing feature in the editor.
That should be trivial to support if we could replace Mosaic grid markup with more flat markup and css grid.
We have used this within tiles (with collection like data), and it should work like that within a single Mosaic grid cell, but not really in any usable way.
have a drop in replacement for the editing side of mosaic only. (still using tinymce and inplace editing of tiles?)
keep server-side rendering of tiles the same as it is now except that it would use css3 grids so markup is a bit different (how to handle ie11?)
All existing tiles should still work?
Separately you would have of your own tiles that would use vuejs and web components to do somethings but that that won't have any impact on a theme that just wanted server-side rendering?
don't change anything about the toolbar, control panel or other parts of plone?
the loomio thing doesn't seem to be structured enough.