Future of Mosaic

[wow] Impressive so customers be interested to buy it. USPs
(...)
And we gave issues priority in that order. ie, deliberately spent more time upfront on things that look impressive in demos rather than things that only advanced users appreciate for example

Wow ! I never expected to see sales theory on this forum!
I'll bite, my idea is that there is no general sale approach across all people and all products.
There is at least according to the psychologists 2 forms of thought, fast thought used for quick decisions on the spur of the moment, and slow thought used for more long term decisions.
Fast thought is at its best when choosing about products aiming at bringing success, such as success with the opposite sex, or (for business people) with customers.

When you want to sell products aiming to bring sale success, you have to prioritize the wow factor. That's why so many market sites in my country are very cute at first sight, and between mildly annoying to use to nearly making it impossible to buy.

OTOH when people want to buy products that they want to use themselves and mostly not to impress other people, to get at well defined goals, such as a drill, a vacuum cleaner, or for business productivity tools, the wow factor is only getting you so far. People are not getting impressed as easily, they are asking more questions such as what it is bringing, really, can it be proved by examples, how much all this shiny stuff costs.
In fact prioritize the wow factor can even put off some potential buyers.
This is not only a matter of product, people are different; in western societies the wow factor works often a lot better for cars with men, but it's the opposite with shoes. For mobile phones the Apple market is clearly aimed at people having a very special approach to products, I remember when I was looking in a store at a cheapo phone, this guy saying loudly to his son to not look at these phones for cavemen, however Apple is not selling the majority of mobile phones by far, only the most profitable part. Apple is definitely not 'popular', but it sells well and make profits.

So it's not very coherent IMO to want to prioritize the wow factor and look with envy at Drupal for having so much more exposure, it's Apple vs cheapo phones really, 2 different ways to success, because in which category a CMS will fit will probably differ too in different circonstances.

@gp54321 Thanks for replying. I think its important to discuss sales approach. I know it seems weird for open source but its we function as a big organisation and we do have a sales process regardless if we have directly hired marketers and salespeople.

To be clear. Everything on the list/roadmap should be done and is important. But its about resources of which everyone is limited. The idea of the prioritisation I'm suggesting is not ditch power user features etc, but rather to acknowledge that people only have a short attention span, plone already has some really good "deep" functionality that looks good on paper, but it's still hard to answer the question "why plone?". A nice clean UI with nice looking icons is more a [doh] feature. It's what others have these days. We need something more unique. Forget the name Wow and replace it with unique and impressive.

Take for example the direction WIX is going - https://www.wix.com/code/home.
Now its a bit of FUD has from what I can see its not serverless but rather all the code is in clientside. Serverless means the code runs in the server but you only pay for when it runs not when it doesn't. And you only deploy the bits of code you need not everything else.
Plone is more serverless than WIX is. You can actually write both serverside and and clientside code in the cloud and just write the bits you need with themefragments or plomino. I guess we don't have a way to just pay for the code when it runs but the big advantage is that sometimes you do need code to run serverside for security and you have that option. Plone is like an open source serverless CMS server software. Is this impressive? I'm not sure, but I think its reasonably unique. There is a USP in there somewhere. However this is only an integrator USP, it doesn't really impress end users.
But we need to find others and what actually gets people to answer, "why plone?".

Take for example the direction WIX is going

Wix is not a CMS and it is baffling to look at this tool as a direction for a CMS. C of CMS is for 'content', Plone belongs in the data world, persistent data, a world where you can use Cobol in 2018.
Look at the mackinacorpus front page, Drupal is at the same level as Plone, Wix is nowhere to be seen.
I think it used to be a Python only shop, this Drupal presence should make you think more than Wix.
Look at Drupal for how it's done to sell better. Not Wix.

Not so fast. Perhaps you may remember when persons used to say Wordpress is not a CMS. My feeling is, there's a threshold* that a "thing" must cross before being called a CMS.
(*that threshold will vary, we probably have a higher bar in the Plone community, but that's not the point of this post.)

Wix Code looks to be moving Wix closer to that threshold as it is doing more "CMS-like" things. Wordpress added features to their blogging platform which made it more "CMS-like" so most persons would at least be willing to see Wordpress as "CMS-like". There's now a blurring of the lines between the traditional CMS approach (Drupal, Plone, Joomla) and the page builder.

I believe that the page builders are eroding the lower end of the CMS market, this has been the case since at least 2007. While Mosaic helps Plone to solve the page building gap, page builders like Webflow, Wix and Weebly are solving their content management gaps. Expect more and more convergence as gaps are filled.

If the Wix code approach adds value in a way that could be useful to Plone end users, we should at least try to understand the value it brings.

That is an entirely artificial distinction. In fact CMS doesn't have much category awareness anymore IMO, since there are other ways to build websites. At the end of the day someone either wants a public website, an intranet and these may or may not involve collaboration and workflow amongst many people. And it may or may not want to combine this with more bespoke apps as part of the site such as forms to collect data or ecommerce. That is the problem Plone is here to solve and that is what WIX solves, drupal solves, Hugo solves, github pages solves and wagtail solves. I sell CMS for a living and less and less use the word CMS or care about the distinctions.

@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 :frowning: 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

  1. list all the ideas of things we can do to plone. Every effort idea we have. Eg consistent icons. Upgrade to python 3
  2. 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.
  3. 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.
  4. 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.

WIX is a CMS. Your definition is wrong.

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... :slight_smile:

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:

    1. support for configuring tiles defined on fixed site layout panels without verbose Mosaic grid syntax

    2. 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

    3. 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.

1 Like

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

  1. 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.
  2. 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.
  3. 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:

https://public.zopyx.com/vuejs

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.

-aj

1 Like

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.

Do you mean to say without server-side rendering?

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.

Yes