Let's be clear: the layout will persist. It's an unfortunate mistake on my part that it doesn't get persisted in the current beta. That doesn't need any more feedback.
In terms of the default layout, I feel we're trying to satisfy too many conflicting requirements.
We want the palette visible
We want an easier way to navigate lots of flows
We want debug to be visible, but still able to browse other sidebars, without having to hide debug. But then debug needs to be big enough to see properly. But we don't want to lose space in the workspace for the flows themselves.
There are so many conflicts and compromises trying to satisfy all of these.
At which point I wonder if we're making more problems than solving with some of the proposals.
Agree with both, this feels the most sensible compromise for the different audiences.
Kind of agree. They are mostly just confusing. However, a more useful approach with saved views is clearer and simpler and may be helpful as people progress through different stages of development and complexity.
Saved views Perspectives
Yes, completely agree. Any "current" view must be restored when returning with the same browser profile.
Of course, there is always that danger when asking for opinions. If in doubt, it generally seems to be best to go with common sense - which I think Dave has already expressed.
This is my first post, although I've been using Node-RED almost daily for over 5 years.
I feel the need to intervene with my opinion in those times, and maybe eliviate some of your stress.
I think once the UI persistance is fixed in the Beta 2, the Default View really will not feel like a problem. The default should consider a new user, not an experienced user. Node-RED is not only evolving for us already using it, but also for new generations of users. We should not lose potential new users, who one day might evolve to contribute for everybody. Here's what I think the default should be on a fresh set up:
My recommandation
Default = New Users, potential future contributors
An inject with the label hidden, and a debug with "node status" active on the first fresh page, to demonstrate what can be done. An input and an output;
Nodes visible in the left side, so the new user can drag & drop and experiment;
Help open in the top right side, so they can read about inserted nodes;
Smaller Debug in the bottom right side, so they can see an output of their experimentation.
Then, we the more experienced users, can move things around, and with UI Persistence they'll stay however we want, and it really doesn't matter for us how it looks for a fresh user. It takes less than a minute to move things around.
What's not for new users
Information - Very rarely used by me, except to navigate flows, would only feel "complicated" to a new user. When I teach someone Node-RED, I always say "don't worry about that one". Configuration nodes - That's a place for all your configurations in one place, but new users will just configurate from the inserted node, they don't need that tab, until they do.
(new) Explorer - They have tabs. It will take a while until they need the Explorer. Context Data - Extremely important, but not in the first day of Node-RED.
↑ I'm saying they should be there but not open by default.
New users don't want efficiency, they want clarity, and comprehensible potential. They need to feel like they can understand things, and do simple things already, even if they could do more in the future.
Because the "Enabled" button and it's grey background are drawn at the bottom of the screen regardless of the scrollbar position, there is nothing to suggest that there is more config further down.
Hi, I have a different question/request and would like to get your opinion.
I would like to have the option to start & stop selected flows from the UI. This would be very helpful after a "SAFE-Mode" start or for other debugging work.
Maybe this feature already exist and I just missed it ... but would you use/require such a feature ?
In the bottom 1cm or so of the workspace, the cursor changes to the standard pointer arrow.
If there is a node down there you cannot click on it, nor drag it further up the screen. And of course there are no scrollbars to get to it.
If you open a node's config and drag the LHS so it extends over the left hand sidebar, the cursor responds to the edge of the sidebar underneath the config, changing to the lift doors/drag sideways.
Clicking and dragging will resize the sidebar, all out of sight.
I can't remember it it has been mentioned but if you drag the editor pane until it touches the left pane it attaches to that pane and there is no way to un-attach it. If you continue to drag to the left the left pane disappears but you cannot then drag the editor pane back to the right. If the left pane is reinstated by clicking on an icon the editor pane is still attached
Problem when importing flow.
In Firefox when I import a "bad" flow" I get a pop up window that tells me it's a bad flow. The popup covers the cancel button so the only way to get out of this is to delete the entire bad code. Then the cancel button can be pressed.