2019 Roadmap discussion: Plone 6

Development Roadmap and Future
21

I take the point you can teach how to make changes to volto quickly.
But my question is, if someone gave that person you just taught, an already created theme for example the first one that came up under most popular on themeforest

@tisto how long would it take them have a working plone site with volto and that theme?

From the way volto has been described the only theming story volto supports is starting with volto and customising it to make it like something else, exactly how we use to do plone theme. Overriding and twisting one thing into another was not fun. Having to include Plones CSS and understand and JS in my theme deal with its interactions was not fun. If I've misunderstood the way volto works then awesome but the words override and jbot are scary to me.

22

@tisto how long would it take them have a working plone site with volto and that theme?

This is exactly what we are trying out currently. I just gave one of our interns the task to build a Volto theme from an existing themeforest theme.

Our initial estimate was that it takes less time to create a Volto theme, than a classic Plone theme. We will report how this went.

In general our theming story relies heavily on Semantic UI theming:

Semantic UI allows you to easily switch between different themes and styles. As said, we do not have all the docs that we need. I just ask you to wait a bit longer, keep an open mind an give it a try.

Overriding and twisting one thing into another was not fun.

Volto theming is not simple overriding and twisting. Semantic UI theming is more sophisticated than that and overriding React components is also quite powerful.

Though, it is true that we came to the conclusion that it is more approachable to rely on standard web technology and a more simplistic override mechanism than on our own theming mechanism. Diazo is a great technology and I hate to see that go. This was btw what Laurence (inventor of XDV/Diazo) already said long time ago at the Plone conf in Boston about React and the modern web.

The truth is that I saw so many badly designed Diazo themes in the last year, where people shoot themselves in the foot and created horribly slow Plone sites. Even if you know what you are doing, if your theme requires complex (XSLT) transformation, you are doing Diazo wrong and overriding a viewlet or a template is the better way. There is no perfect way, it is always a tradeoff.

In addition to that, I think we have to accept the fact that we are a small community and that innovation in the web is driven by bigger players these days.

The times when the Plone community was able to drive and maintain major innovations are over. Web technology grew up and the requirements are much higher these days. If we accept that fact, we have to look for existing solutions that are used and maintained by others. Unfortunately, Diazo did not gain any traction outside of the Plone community. Semantic UI did. It is time to move on...

2 Likes
23

Because Diazo themes usually break Plone WYSIWYS experience, I consider GatsbyJS as a replacement for Diazo. Of course, the difference is that it is very hard to make a slow site with GatsbyJS :slight_smile:

1 Like
24

Chromebooks and such other initiatives to figure out which is the lowest client side power use people can tolerate will try their best.

1 Like
25

The comparison is not to classic plone theming but to diazo. Classic plone theming is very slow, very inflexible and requires lots of knowledge to know what to override and where.
You can train someone on diazo in a few hours and have them take a themeforest theme and have plone running it in a day or so realistically.

I am not saying diazo is the right technology
I am saying that

  • fitting the CMS into the theme is the right approach (full control over html)
  • fitting the theme into the CMS is the wrong approach (overriding/subthemes/basetheme)

Exactly my point. To theme with volto === must use our CSS == bad. It means I can't use html designs that don't use semantic UI without throwing the designs CSS away and reimplimenting it which is expensive in time.

You are right, diazo makes it easy to make it slow. But I'm not sure its true to say its a tradeoff of "time to theme" vs "page rendering time".
I can see for you and your business that time to theme is unimportant and page rendering is important. High paying clients that tradeoff is clear. Not everyone the tradeoff is so clear. but it should not have to be a tradeoff.
Can we, since we have the smartest people, create a technology that allows us to take any theme in html (already optimised for speed) and attach the CMS experience like volto, in a way thats simple to teach.

Strawman argument. I am not arguing for us to build something if it already exists. I am arguing for build-it-up theming not customise-it-down. Semantic UI doesn't do this.
The words to look for are "full control over html". Similar to wagtail. Similar to diazo. Similar to ExpressionEngine. Similar to CraftCMS (https://craftcms.com/)

ok. It's great its fast. But Introducing Gatsby Themes | Gatsby uses the words "Sub Themes and Overriding" so again its a customise-it-down experience so you have to do it gatsby's way so how is it a replacement for diazo?

So far with my themes I strike a decent compromise. Layout is there with mosaic but not the styles. And layout in the the theme is BS4 and mosaic is not. So the theme is still a built-it-up/lift-and-shift one.
But can we do better? Can we have volto editing on any html theme (including a gatsby theme).

57 am
57 am1238×704 250 KB

22 am
22 am1471×979 259 KB

26

Do you mean that GatsbyJS can create a static site which uses dinamic api query, so the site is dynamic but the resources (html, css, javascript) are static? This works also in managing the ui of logged users, adding content, control panel and so on?

27

For those interested, we will be hosting an Ask Me Anything session about Volto on Friday 15th at 2pm CET.

See you there!

1 Like
28

FYI: Diazo might still work on Volto. We are using server-side rendering. Diazo can take the HTML that is rendered by the node process on the server. The output can be transformed by Diazo. Just give it a try and let us know how it went. :slight_smile:

I agree that we disagree on the Plone target group. I don't see how Plone can be a good fit for low budget websites and intranets. If a client comes to us with a few hundred or 1-2k Euros budget, I point them to wordpress.com and tell them they should not hire an agency. This is the best service I can do for them as an honest person.

There are some exceptions where clients need to use Plone because they are already using Plone elsewhere. In that case, Plone still makes sense and we usually sell them a theme that we used elsewhere or just amend a few colors and the logo.

We could sell them any Diazo theme that we hack together in one day. Though they wouldn't be satisfied with the quality and we wouldn't be either. This is not my way of doing business.

I used to do Diazo themes on the fly within 3-5 minutes on trade fairs, presentations or conferences. Of course, you can do a Diazo theme in minutes and you can accomplish a lot within a day. Problem is that a real-world website always takes at least a week in our experience. No matter if you have to build a theme from the ground up from a PDF you get from an agency, if you start with existing HTML, or if you build something on your own.

With Victor we are lucky to have one of the most experienced Plone theme devs I know in our kitconcept team, he knows Barceloneta in and out because he wrote it. Still, he always needs at least a week to build a decent theme. You are faster at the beginning with Diazo but at the end, building a Plone theme takes the same amount of time, no matter if you build a classic theme, a Diazo theme or a Volto theme. This is our experience from the past 10 years.

Plone and Volto are open source. You are free to enhance it to make it fit your use case. We are more than happy to help if you want to jump in. Please just keep in mind that you can not expect other people to work on a use case they don't have.

29

Ok. I admit GatsbyJS approach is not 1:1 feature complete with Diazo.

The default use case for GatsbyJS is that the built site is completely separate from the origin backend. Yet, GatsbyJS built site is also a ReactJS app so, in theory, it could communicate with the site, but we don't have anything ready for this yet (of course, GatsbyJS users elsewhere have done almost everything possible for their systems).

@tisto would like to see GatsbyJS to work together with Volto somehow in the future.

1 Like
30

I see your confusion in what I'm saying. When I've talked about time spent theming I've divided up html and css construction from applying it to plone. I agree that if you have someone who knows the base theme of plone inside out they can build a site as quickly as first creating a html/css mockup and then building the diazo rules apply it to plone. You have to have that html/css person on staff and well trained on plone however.

My original point was about the "lift and shift" style theming where you can split the effort of theming between someone who knows html/css inside out without knowing plone, and the part of making it work with plone. The reality is that the old days of an agency being full service and not having to work other designers doesn't hold true anymore. We get given html/css themes from our clients and we aren't going to spend the money on rebuilding a perfectly good theme again just so it fits with plone.
I am not saying diazo is the only way to achieve this, or even that its the best way. In fact the biggest thing that made this possible was toolbar having minimal requirements and the ability to have a seperate frontend and backend theme.

So can volto be made in such a way as it can be "applied" to existing html/css?

The assumption you seem to make here is that
a) everyone creating a plone site is doing so via an agency
b) developer prices aren't going up and competition prices aren't coming down

I think anything open source has to support a DIY model otherwise it will fail to be recommended by those who find it and therefore will fail to grow.

You can't expect remove features from a product that people other than you have contributed to because you don't have their use-case. What makes you think you are the majority?

31

Am I missing something here? The inclusion of Volto in the Plone 6 roadmap would not remove any features from traditional Plone UI, which would also be in Plone 6.

1 Like
32

I'm assuming that would be only temporary and that the entire traditional plone UI would be removed in the future. We can't expect to support two whole different backend UIs and theming. That would be crazy. If not then why wouldn't volto remain as a plugin?

1 Like
33

We actually have a history of trying things out for a long time before making a choice :slight_smile: I can see Volto and “Plone classic” coexisting until that choice is made, and the choice would (rationally) be made only if and/or once Volto either became feature equivalent or we as a community decided that whichever features were missing in Volto were no longer as important as they are now. And the process of getting to that choice, and of getting Volto feature equivalent, would depend on interested parties implementing the missing features or continuing to drive the decision.

I would actually like to see a lot of CastleCMS features (and UI) get into Plone.

1 Like
34

@tkimnguyen Thats certainly not mentioned in the roadmap. In addition volto hasn't existed for very long yet the roadmap states it will become the default UI in the next Plone release. This is nothing like mosaic or CastleCMS "co-existing".
Keep in mind that when projects like this take big different directions that require relearning and retraining... if we get it wrong (I'm not saying we are yet) then it becomes a jump off point for a section of the community to switch to something else. Like what happened with plone 2.5 to 3. As you point out the old UI still exists so it doesn't require retraining yet but the writings on the wall. If plone is only designed for big rich agencies with designers on staff then it looks like we may have to be one of those moving on :frowning:

35

There is a PLIP open where this should be discussed. As with any PLIP, the community discusses the PLIP and its scope (so the PLIP is the place to better discuss this in detail, not here). The Framework Team will some day vote on the PLIP. After vote, the implementation needs to be done/finished. Then the review process starts where - again - problems to be solved can be placed. Here the community is always invited to be active part of it. The Framework Team then decides based on the reviews if the PLIP is finished and ready for merge.

From by personal POV - and opinions catched up around - I am pretty sure most people want Volto in the Core. Probably the installer will come with Volto UI as default. Or we have a choice in the Installer, what to install. I am also sure, that we have the old UI coexisting with Volto, because classical server side rendering (SSR) is and will be a use case for a large number of Plone users.

Probably at some point Volto front side rendering (FSR) will repress the classical SSR UI, because the majority of the community wants it that way. But as long some want the current SSR UI and as long it is developed, updated and a significant number of people are contributing to it, its not dead. If not it may die. Plone is a kind of DoOcracy, with some steering by Foundation teams.

But all this is just my view into my not-well-polished crystal ball... And so I am really bad in predicting the next 5-10 years, this is what we are talking about.

2 Likes
36

Thank you Jens. I couldn't have put it in a better way.

@djay lease keep in mind that our current classic Plone UI has a horribly outdated JS story. bower is dead. grunt is dead. requirejs is dead. Backbone and jQuery are ancient artifacts from a different time. Do I really have to go on?

I wish people would put lots of effort into the classic Plone UI. I wish people would remove at least the parts that were officially declared dead long time ago. I wish people would start back porting our Volto React components to the classic UI. I know @thet started some work on this but our resources are limited and I don't see this happening.

So if you think there is a bright future for Python-based server-side rendering and the classic Plone UI, please go ahead and help improving it! React is the way to go there as well IMHO. It is one of the few JS components in Plone core that are not horribly outdated.

3 Likes
37

That's because I'm waiting to see how much traction the idea gets and who would help make it (getting CastleCMS features/UI into Plone "somehow") a reality.

38

I'm not sure why you like making strawman arguments so much but it really is disingenuous.

  • I never argued for python server-side rendering/JS story or diazo
  • I never argued against a react based editing UI. I certainly see the benefit of a good grid layout editor and fast editing UI.
  • I believe plone dropping it's "full control of html" and toolbar approach would be bad.
  • I am saying that building flexibility into the volto theming story so an existing html/css theme does not have to be rewritten is a good thing. That requiring a theme to be built on top of semantic UI and the volto base will limits its appeal.

I am willing to help workout how to combine the approaches but certainly dismissing this usecase as unimportant is not going encourage my or other contributions.

I don't want to see the baby being thrown out with the bathwater. In the very least there should be acknowledgement in roadmap that this was a deliberate choice and why the pros outweigh the cons and why it's not possible to have both.

In addition the target group you mentioned should very much be in the roadmap. There was a deliberate reason I gave my lightning talk on how to write a roadmap at the ploneconf. https://www.youtube.com/watch?v=T-C15qInJ8A.
And also my talk on reducing the plone learning curve was very much directed at showing core-developers the importance of the low barrier to entry "lift and shift" theming creates https://www.youtube.com/watch?v=HXwvXf0SW1Q

I will put my comments there. However I will note that it's not possible to "watch" a github project so it's not possible to be notified of PLIP announcements. To get better community engagement of PLIP ideas perhaps all new PLIPs should be announced here?

@tkimnguyen The best way to do that is talk directly to @Albert. Volto is being developed against Pastanaga only and @Albert is only now starting to diverge it from Plones existing UI. I had some good conversations with him about ideas like the add dialog (like in CastleCMS), multiple grid layouts and workflow/sharing. I think it would be very useful to take input on all the training sessions you guys did with Castle and write a report on what parts of Castle UI worked and what didn't and discuss it directly with Albert. I think he needs this kind of input.

39

I don't think we ever collected metrics, so our assessment of CastleCMS's usability is anecdotal. Everyone who has seen and used CastleCMS found it much easier and comprehensive than Plone (not surprisingly, since it was designed that way based on feedback from Wildcard's biggest client and on our experience with websites managed by many content editors of varying levels of expertise).

CastleCMS has a lot of power under the covers that isn't something we show most people because most people don't need it and wouldn't be authorized to use it. Multiple layouts for content types is something people grasp easily but few will ever have need for them after they've launched their site. Same goes for what we call "site designs", which are essentially different page templates that can be applied on any content item and on any section of the site. Usually only people who deploy multiple sites will have need for this. If you look at all the tiles available, it's clear most people will never need them all.

Probably what I need to do is make a list of the features that I think should be "backported" to Plone and let others jump in. We can prioritize them, we can try to estimate difficulty/complexity, we can explicitly state the trade offs. A big trade off for example will be Mosaic. People argued on whether Mosaic should be in core or not, and there is not wide acceptance that it should be (at least not among core devs). CastleCMS uses Mosaic for almost all content types so without Mosaic in core, CastleCMS's UI could never be shipped with Plone (or could it? maybe if Mosaic came with Plone the way PloneFormGen does...)

40

I think you've missed a big unsaid part of volto PLIP to be shipped with Plone. It effectively means the death of mosaic. No one has really been working on mosaic to my knowledge because a) someone was building something else, ie volto and plone angular. b) no one wanted to write in Jquery anymore. So bad luck for Castle and anyone using mosaic heavily.

I'm not really sure what volto does for portlets vs site layouts vs something else. But it's grid system is very different from mosaic. At the moment it only supports a single column and so far the design decisions are not to allow very complex layouts to be made as a tradeoff to making easy for content editors. This was discussed during the open space last year.

So when it comes to features of Castle that could be backported I think the ones that are relevant are outside of site layouts and mosaic. For example it's add dialog?