Thanks for the elaboration here! I agree with the points made. I would love to elaborate a bit on the design direction and the thoughts behind it. Also, laid out in the road to 5.0 blogpost.
First up, what we're trying to fix first is to align better with UI/UX standards and the goals of the user VS hierarchy of the UI sections. If the flow of the user going through the UI sections aligns with the goals of the user, we're in a good spot. Even better if we simplify it, though there is always a trade-off between configurability VS convention.
What has been achieved with this dev release, is the capability of moving things into a position in the Node-RED interface where they will be more meaningfully visually ordered.
It would be right to think about it as bringing it closer to an IDE like experience. IDE UI patterns generally but subtly follow better information hierarchy principles while leaving configurability to the end user. Especially allowing for L-to-R and R-to-L configurations depending on preference.
When we look at the classic Node-RED UI we can generally see a L-to-R mindset in the UI architecture: 1 influences 2, and 2 influences 3, etc.
The problem, however, is that a lot of content and ideas have ended up downstream in the UI and have been positioned in the place of least resistance meaning they ended up in number 4. Which, as Nick has stated, has become a collecting bucket for all kinds of content, including content that goes against the hierarchy order.
Generally speaking Node-RED has 4 areas. But if we look closer at the flow within these sections we can see that the order of things is not always aligned with the order of understanding the context. Hierarchy would state that you need number 1 to understand number 2, etc.
However, we can see that if we go from number 1 go to number 2 to see the deployment status, but of what? What is the context I need to understand the deployment status of? That is the next step, but number 2 doesn't lead me naturally to number 3. Why do I get to the deployment status first before being made to understand what it is about?
If we continue we can see that when we arrive at number 6, we are understanding what is defined in the sidebar we is down the ladder of hierachy. However, number 7 influences the canvas against the inferred direction of hierarchy. In the end this creates user confusion, especially for new users who are familiar with other tools but then find it hard to get started with Node-RED.
Here we can see that one of the main culprits, number 7 even hides (initially) a panel that we would naturally expect in that position: the debug panel:
With this in mind let's look at the example from the blogpost again. Here we can see we basically are trying to simplify to necessity of moving around the UI in order to ingest its meaning in a logical order. Where previously you had four areas, we now have three. A user does not need to move across the entire screen to find the next logical point to continue understanding. Plus at any point a user can take action without needing to understand the rest of the context: I don't need to understand the canvas view, if I am only interested in the outline, so I stay within area 1
This becomes more apparent when we swap the node palette with the info section in the UI concept:
Again to reiterate, what we gained is the ability to have modular sidebar panels and the ability to position sections out of the right sidebar to places where they are better aligned with user expectation and intentions.
PS: Love reading the feedback! Keep it coming
