Plone 6 - Future of "Classic" UI

Development
1

I talked with several different people at the conference and also with customers and other integrators about "Classic Plone" lifetime and there is a strong opinion that it should be continued for Plone 6. There are too many projects out. And Plone stands as enterprise CMS, so this means steadiness.

Also, and as you said, Volto will take some time to mature and get all features in.

My personal opinion and proposal (no framework team involved) would be to make Plone 6 a kind of LTS (long term support) version of Plone, kinda 4.3 was. And to continue making is better, but no breaking UI/UX, because all UI/UX energy should go into Volto.

The only task I can imagine for Plone 6 is to lever the current Bootstrap 3 based Barceloneta theme to latest Bootstrap (IIRC Bootstrap 3 is no longer supported/developed and Bootstrap 5 is on its way to final), but that would not be priority. If community members think its a good idea (I heard people talking about it) and just do it, and framework team approves it, fine.

3 Likes
2

Amen. But the message was already that the classic Plone stays at least for Plone 6.

Volto needs to mature and therefore it can not be replace the classic Plone UI now. It's good having it in Plone 6 as an optional (maintained) component that is then in sync with Plone 6. But experience shows that it takes a longer time for new components becoming mature, tested and accepted.

Lessons learned from the Plone conference in Ferrara: yes, it makes sense to go headless in the future but that also offers the opportunity to use different technologies other than React or Volto for whatever reason. I see Volto more in the space as frontend for replacing the current Plone classic UI. I have little personal interest for using Volto as a foundation for public facing UIs - but that's personal taste and highly opinonated about what the best framework for my projects would be.

2 Likes
3

Just to be clear: dropping the classic UI in Plone 6 was never considered and I am not aware of anybody who proposed this at any point.

Plone is and was always a good choice for large long-running projects. We supported Archetypes many years after it has been dropped. Volto and Plone REST API run on Plone 4.3 with Archetypes (still). You can run a Volto 4 on an ancient backend stack. It is almost ridiculous how much effort we put into backwards compatibility without talking about it.

Plone 6 will drop Python 2 support. By the time Plone 6 will be released, Python 2 will not receive any security updates. That's what we plan to cut, nothing else. Yes, we will add Volto but you are free to ignore it if you prefer.

If we want to drop the classic UI for Plone 7 or 8, someone has to write a PLIP for it and it has to pass the Framework Team. This is something I personally would like to see at some point.

Though, this step requires a wide adoption of Volto by the Plone community, the availability of add-on products, etc.

If you have an existing (large) Plone project there is nothing to worry about right now.

As Jens wrote on the CastleCMS topic, Plone is a do-ocracy. If people want/need the classic Plone UI, they should invest into it and continue to fix things there.

5 Likes
4

I also see Plone 6 as a kind of LTS and still will and have to do more complex site the way we're used to.

Therefore I'd like to start a LTS theme, stylewise based on Barceloneta (maybe simplify things a bit) but with freshed up markup to support Bootstrap 5 out of the box to make life easier.

Kick-off will be at the Alpine City Sprint https://alpinecity.tirol in February.
Everyone is welcome to join!

p.s. I also look forward to do sites the headless way :wink:
p.p.s. UI enhancements should go into Volto

3 Likes
5

I'm hearing very conflicting messages

Not really. If I have a UX enhancement (that I'm willing to implement) but I'm hearing

a) it has to go via UX Team (which unless I've missed an announcement was disbanded years ago and never really functioned anyway because the FWT was the decision making body)
b) volto is one and only place for UX enhancements.

I can implement this fix for a UX bug that has been plaguing plone for years but there is no point if has no chance of getting through FWT which has always been the problem with PLIPS for fixing plones UX. I don't know where this leaves us given we aren't going to be using volto anytime soon given how extreme the upgrade process will be and how most of the plugins we use will no longer work from what I can see.

I disagree with not enhancing Plones current UI.

6

Write a PLIP, bring it to the UX or the Framework Team, get it approved, start with the implementation. This is our process. Simple as that. There is no magic involved, just hard work and convincing people that your idea is a real enhancement. The process is the same for everybody and there are no short cuts, get used to it.

7

Says the person who sat on the FWT and rejected two previous proposals for folderish content types and now suddenly decides that folderish content is a good idea years later.

It's not the same for everyone. The idea that it is a myth that should have died a long time ago.

I've written PLIPS, done the work and had them rejected. It's not fun. The process is broken for UX enhancements as evidenced by the lack of progress in plone classic UI despite many known issues. The barrier to getting any non trivial UX change past the PLIP process is exceedingly high due to the fact the FWT members are chosen based on technical merit not UX ability.

8

I downvoted the folderish PLIP twice and I said that openly on a stage in Ferrara. Changing opinions is a sign of strength and not weakness. I do it all the time and I am proud of it. We listen to each other, we discuss, we fight and at the end we get a better product and some of us change their opinion. This is what makes us a community.

Though, in case of the folderish PLIP I never changed my opinion TBH. I downvoted the PLIP twice because of the UX side effects this change has, not because I don't like the idea. I stated that clearly to the people who submitted the PLIP and in the FWT meeting.

I am not the only person who had this opinion, it was a team vote. I have one vote like everybody else.

When we started Volto I saw the chance of trying out this long-discussed idea. It worked out and now things start to make sense IMHO (when folderish types meet blocks and Pastanaga UI).

The negative consequences of the folderish PLIP that made me downvote it (e.g. that the folder_contents view confuses the hell out of users with folderish types) are still present in Volto. It is still one of the hard UX problems that we somehow need to solve. This would have led to problems in classic Plone that we wouldn't have been able to solve easily.

In addition, there was always an add-on product for folderish types that people could easily use if they prefer that way (and we did so in some projects). Therefore the FWT saw no reason to take a huge risk to gain little.

Open Source communities are about mutual respect, understanding and working well together. We fight and argue all the time, within the framework team, within the Volto team and especially when it comes to UX issues. I disagree with Victor, I disagree with Rob, and sometimes I disagree with Albert. We have heated discussions and we usually come down afterward.

The reason for that is that we highly respect each other and never attack each other on a personal level. We discuss on a technical level and we live with the fact that we sometimes disagree. Eventually, someone changes their minds and we work towards a common goal.

I am open to having a drink at the next Plone conference to discuss this further on a technical or UI level. Though, I do not really enjoy spending my time with personal attacks via the community forum.

2 Likes
9

Given there is no active UX team outside Volto development (is this true?), the framework team is the official body for decisions here. As I know the framework team, in case of doubt they lever discussions up to the community asking for opinions. This happens regularly. Unfortunately there are often not many people with opinions around.

This "Very conflicting messages" are just opinions so far. So conflicting is fine. Lets get more of those here.

10

it is not a personal attack. you have completely missed my point. I am using the decisions against folderish types as just one example of joint FWT decisions done by a process that is weighted against fixing UX problems because of representation on the FWT. I'm sorry for singling you out but it was not personal as the rest of my post talked about, which you seemed to have skipped over. You are just one example of the tech heavy team chosen of technical rather representation merit.
The python PIP process works because the core team are the users of the product so they can appreciate the proposals against their own experience. Plone is for editors and themers, which have very little representation on the FWT. Albert is not on the FWT for example. There is no other process to get code into the core except via PLIP. When I was leader of the UX team I tried to work out ways to change this but it simply didn't make sense unless there are two different PLIP processes and two different ways to get code into Plone. What I should have proposed back then is the FWT should be representative. How many people on the current FWT regularly edit content of plone websites or talk/get complaints from people who do?
The other problem with the FWT is it's focused on rejecting proposals, not on improving proposals to important problems or increasing them. It assumes a survival of the fittest scenario where proposals are abundant which is not the case.

Can you give an example of this? I'm guessing if this happens it happens with people they know as I've never seen this on the community forums? I've also haven't seen any that representational outreach documented in the FWT minutes. I lead the UX team for a year and the FWT never asked it a single question that I remember.