Future of Mosaic

I’m beginning to disagree.

Mosaic grid editor is already been obsoleted by CSS grid. Just CSS grid is enough to turn a folder “full content view” into a grid.

Pastanaga editor will offer better “inline” editing experience and could probably support tile-like arbitrary plugins.

Blocks composition in Mosaic solves issues for backend rendered UI, but once the UI is rendered by browser (or nodejs middleware) also that is obsolete.

So, resources for 5.2 and beyond might be better spent outside Mosaic.

(That said, I'm still using Mosaic as long as we use backend rendering: we need it for WYSIWYG editing of complex layouts and benefits of ESI composition [e.g. tiles with different cache timeouts]).

2 Likes

exactly; pushing Mosaic into the core now is a bad idea IMO.

we need to focus on putting Plone on track again; add-ons are a crucial part of the ecosystem.

we can sell upgrades to Plone 6 to our customers based on the fact that Python 2.7 is going EOL; we can not justify the same for Plone 5.

Here's how I see that delay: you want to wait even longer now for The Next Great Saviour to arrive. We've done that before, and it doesn't help sell Plone either. There's the bird in the hand, yada yada. And maybe you're unable or unwilling to sell Plone 5, but many others haven't had that issue.

I don't get your point: AFAIK it's now widely accepted the resource registries is broken and must be fixed; that's a blocker for many people, not only me. I've been consistent on my request for almost 18 months now and you keep saying there's nothing to fix (yes, your behavior is consistent also but no, the Earth is not flat).

the chief problem is we don't have a consistent roadmap.

we can divert and distract developers on many fronts and come here late December 2019 just to discover we're out of time... because Plone 5.2 and Plone 6.0 could take easily a year or more to deliver if we continue adding features to the list.

Widely is loose, but I do not disagree.

Most Plone houses seem to have rolled their own frontend stacks to keep up with the world as Plone did not.

So are we fine with Plone becoming a headless ZODB wrapper, going the way Guilliotina went?

Thinning resources usually imply a necessity for choices to be made (sans a massive success in rallying the community to take more workload).

IMO, is too early to cut the standard UI from Plone; that will make things worst; we don't know yet what kind of integration issues are we going to find with the client side UI.

if Pastanaga and the client side UI are ready by the time we get Python 3 compatibility and a new resource registry story is working, we can ship them also; but for me they are not blockers and must have a lower priority.

A carrot:

  • The way I see it there is
    • the UI which is icing.
    • the features which is the cake. Features determine what users can and can't do and how they will work with them.
    • Eating the cake is UX. Both together make a nice experience
  • If your features are a turd then a nice UI still means you are eating a turd.
  • Plone is not a turd but it has certain features that don't work together well or are clumsy or just aren't easy enough. If you are interested in what they are see my 2015 talk - https://www.slideshare.net/djay/5-things-still-too-hard-in-plone-5-54158231

What are carrots?

  • python 3 is a bit of a carrot but not a great one
  • fixing resource registries isn't a carrot. Anything that helps developers is hard to sell to end customers. It just doesn't work saying "please pay X to ugrade to plone 6, it will make my life easier".
  • New features is a carrot. Personalisation. Better search. Social media integration.
  • Optional headless is probably a carrot since some customers do want quicker pages and more custom apps. So not for everyone so not a great carrot
  • Better UX is a good carrot. Plone is a CMS. Better management of content is the goal.

Pastanga UI

Headless

  • Pastanga UI doesn't require headless. It is admin only UI. We can have admin being JS only and the frontend still server side rendering
    • However somehow pastanga is going to have to work with plugins, control panel, autoform etc etc. If the goal is to replace everything then I can't see it happening any time soon and the backwards compatibility hump for integrators to overcome will kill plone.
  • Serverside rendering will be with us for a long time. I think some companies have gone all in and that suits their market and their development teams. They see the future as headless only. Other companies don't work that way. Governments like UK require progressive enhancement. I think its far to early to go all in on headless so therefore we have to support both.

Conclusion

  • Without a carrot Plone is hard to sell. Thats bad for everyone.
  • Tackling the hard UX problems is the carrot. New icons is not. Plone 5 was mostly new icons. It didn't sell well. We don't want another plone 5.
  • We need to work out how to tackle the hard UX problems that our end users face (not us because we have stockholm syndrome). They are hard because everyone wants consensus yet everyone has an opinion and we don't personally experience the problems.
  • We have limited resources. Switching everything to react/vue/angular/nextjs framework seems like a LOT of work and risky. but if we have the resources...
  • On the other hand no one seems to want to work on mosaic code which is using jquery.
  • Mosaic only fixes one turd. There are others. folderless/Default pages, sharing/workflow, placeless content. Castle has solved some of these.

So we are at an impasse right? But we are smart people... we can work a way out... and I don't think it requires a resort holiday in italy to do it :slight_smile:

2 Likes

Awesome write up!

...except for the slag at the end about Sorrento... which I think you're wrong about, because it's in person that we can really work out a way forward. As you've seen, discussions via email and forum and github issues only get us so far with thorny questions.

Do I hear you proposing something in Bangkok? It's time. Talk to @jean and make it happen eh :slight_smile:

It's nothing personal about sorrento or the people who go there. But I don't think we can afford anymore exclude people who can't afford the time or the money. Having something in Bangkok would be easy. Prices are cheap, weather is good and the beer is ... ok, maybe drink cocktails... But the same problem exists. Not everyone would be in the room. Those that are here would get a good feeling but does it result in a roadmap that is representative? Maybe this year is the time to try something different? Tools like https://www.kialo.com/ or something else? Then when we have a good roadmap, I'l organise a bangkok sprint. How about that?

In person discussions, even if not attended by everyone, still allow us to work through the issues as understood by attendees, and we do try to get the major drivers of the work in attendance.

"Empowering reason"?!?! Balderdash, I say!

:wink:

OK let's take a look...

yeah it could be the wrong tool for the job. I haven't really looked at it much yet. But I do know that in-person doesn't get wide enough information, is expensive and suffers from "group think" (Groupthink - Wikipedia). Forums like this suffer the opposite problem. Polarisation, and loudest voices seeming to "win" arguments and no way to get a feel general opinion and silence being taken as agreement. Also differing opinions get too heated and turn off people who don't like conflict.
There has to be something better inbetween. Some way to first decide on the problems we want to solve from data not intuition, and then reason out the truthful pros and cons of each way to solve them.

As an example. One thing I said incorrectly above was that from the slides pastanga doesn't try solve UX problems other than too many items on the toolbar. One thing it seems to be aiming at is helping with workflow. There is this screenshot.

I'm guessing the problem is that this is trying to solve is confusion about names of transitions vs states or perhaps users feeling like they need to know the full end to end workflow, not just their part in it. The think is, I've actually never seen users experience these problems. Which is not to say they don't.
So first things is, is this an important problem? This is a really important question and one we need to go outside of our own experiences to answer because we aren't often users and we certainly aren't beginner users. The only way you get to see this is when you train someone, or offer a support contract and see what they get stuck on.
The next question is how important is it compared to competing UX problems?
For example problems I have seen are

  • Confusion about sharing roles users and groups roles
  • Confusion about groups vs roles. Wanting to create a new role when a group will do
  • Not connecting that sharing changes your workflow and not understanding the connection between roles at each step of the workflow
  • Not knowing the capabilities of each role.

We could instead solve any or all of these. And the solutions might overlap or conflict. Thats why knowing which is the most important problem that will have the most impact is so important.

Then finally there is another level of prioritisation. Sell-ability. When my company did a roadmap for a product we were building, we classified features into 5 groups.

  1. [wow] Impressive so customers be interested to buy it. USPs
  2. [doh]. Features that everyone has that they are unlikely to pick us if we don't have.
  3. [tick] Has features clients need so they sign off on it.
  4. [smooth] is easy to use and run well so we get less support requests. Will like us once they are already in (and recommend us)
  5. [power] is very productive so quick for us and clients to do advanced things more quickly
  6. [scale] Making our platform scalable and help us when we are popular

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. Why? because once you have sales you resources and more information to fix the others. That is why the iphone 1 launched without cut and paste. The same is true for community open source. We do want to be popular. We do want to sell. Because that will indirectly lead to more core developers and more resources to improve the other things.
However I would say our current process tends to favour more under the hood things. Like [scale] [power] where developers can create content types faster. One could argue that perhaps python 3 is now [doh] item, but if the customers are not developers, are they going to notice?
So if I was running a roadmap session, these are the questions I'd ask

  1. What do we already have that we can make into a [wow]? Our strengths. What features can we add to make it more so?
  2. What is everyone else doing that we aren't yet [doh] [tick]
  3. What are we currently trying to get done and how does it get classified according to its sell-ability? Can we reprioritise these to concentrate on [wow] stuff instead?

And finally once that is all done is explaining this to community and getting everyone onboard. Other really important process that seems to get lost with in-person group decisions. We should all know the where and why of our roadmap right?

2 Likes

I did some quick searching of "open source decision making software" to see what's out there... These two look interesting:

I think Pastanaga fits into the wow category

How? How is Pastanaga unique in field of CMS?

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