Deprecating the old UI

Hey team! :slight_smile: I’d like to get a feeling of the current state and get to a consensus on the topic.

So the plan was to introduce the new UI gradually so people would start using it, which happened with the beta phase and as of 3.3 it has become the default UI with the old UI as a fallback.

The plan was to get rid of the old UI with new for 4.0, however I wanted to ask if you feel it’s ready to completely replace the old UI? The new UI is still at an early stage in terms of maturity and to me the state is similar to the old UI in version 1.1 where there’s still missing features, quite some bugs and lots of unpolished things (especially styling wise). I personally wouldn’t feel comfortable upgrading a site to 4.0 and only have the new UI for client projects. Don’t get me wrong, a tremendous amount of great work has gone into the new UI and it’s a great foundation that only gets better every week, but some older clients won’t be too accepting going back to a state where they’re have to deal with editors not being able to do their work due to bugs or missing features.

Now there’s certainly some arguments for getting rid of the old UI. An important one is integrating with the Event Sourcing, which doesn’t make sense to do with the old UI of course. Additionally eating your own dog food always helps, which we already do but there’s a fallback removing some pressure to finalize certain things. Lastly there’s the benefit of less code by getting rid of things, although having the two simultaneously already works and to my knowledge isn’t causing too many conflicts.

Thus keeping the old UI doesn’t take much work and we can still deprecate things things and remove them in 4.1 or 4.2 etc. This will allow more time for the new UI to mature and catch up feature wise with the old UI and get more tried and tested, however not leaving customers in a position where some things don’t work. And we’ll be able to feel more comfortable not having a fallback solution.

Btw. one thing that plays into this is definitely new development like the event sourcing, if that is planned for 4.0 and will conflict with the old UI, then that probably trumps. However I’m unsure if that’s even feasible to finish and stabilize with only a month and a half until the deadline of the next release.

An alternative is of course just to stick to 3.3 until I feel like the new UI has matured enough for those clients.

What are your thoughts on the matter? How comfortable are you with only having the new UI and do see other pros/cons to add to the picture?

Btw. opened this in relation to the work in progress PR to get rid of the old UI https://github.com/neos/neos-development-collection/pull/1937

Thank you!
Aske

I can generally live with having it around for some while longer (aka, another major cycle). I don’t think it’s getting in the way too much.

The old ui does a lot of stuff I would like to remove especially in the Neos.Neos:Page fusion object and in the shortcut-handling. Additionally there is still the inception-error that occurs from time to time where an old ui is rendered into the content iFrame of the new ui, at least this can be resolved by removing the old ui.

If we keep the old-ui we have to explain one more year in wich ui what is possible and package autors that provide custom editors will be asked to maintain both versions.

A possible reason for keeping the old ui is that removing the old stuff is not that easy. It would be great if some guys with more experience with the old ui could help with that. We should at least communicate clearly that the old ui is deprecated and will be removed.

Hey,
From my experience, the new UI is way more mature then the old UI in 1.1. We updated all our projects to the new UI and get good feedback from our customers. Yes there are some rough edges and bugs in edge cases. But these things are ironed out with every new bugfix release.
So I think if the complexity of removing the old UI in the short time till the major release is not a blocker for removing it, I see the state of the new UI not as a reason to keep the old one.

Couldn’t we provide the classic UI as optional installable package? Or would that mean a lot of work?

2 Likes

I feel like @aertmann regarding the unpolished state. We’ve rolled back the UI for a customer as he felt “lost” and “limited” because stuff didn’t work for him. So I’d appreciate it if the UI wouldn’t be dropped too soon.

I didn’t work with it a lot yet, and will have to investigate where this particular customer got his confusion from. But the stuff I did run into now does not give me the convidence that the new UI is polished enough yet.

Hey everybody,

I’d personally like to gradually phase out the old UI, though I feel it might be too early to completely get rid of it with 4.0.0 - as there are still edge cases which are better supported in the old UI. So my suggestion would be:

  • in 4.0.0, disable the old UI completely by default; and you need to switch on a setting in order to make it still reachable - something like: “enableDeprecatedOldUi” or s.th. like this.
  • this way, package authors should be fine to only support the new UI from now on.

From my experience, when running in well-maintained new Neos projects, running the new UI is usually without any problems.

I’ve seen some problems when running the new UI just as a drop-in replacement for the old UI in some projects; the main issue usually being that we load JS in the new UI on every page load; but in the old UI it is only loaded initially. Because of this, the behavior with the new UI might be more sluggish compared to the old one, if your JS delays loading the page for a longer time f.e…

Regarding the event sourced CR: There, we’ll only support the new UI - but at Neos Con we’ll release a Technology Preview; so that means the event sourced CR will definitely not land in 4.0.0.

All the best,
Sebastian

3 Likes