Saving flow after changing Layout Editor

[Paul-Reed]

Don't know if this is a bug or feature request...
When using the layout editor, and saving changes, it is not always clear that a deployment is necessary, because the normal editor 'deploy' button remains un-highlighted, and 'the flows on the server have been updated' popup appears to time-out.

Expected behaviour
When changes have been made, it's fair to expect that the 'deploy' button, would indicate so.

[joepavitt]

That's because there is no need to do a Deploy. These changes are deployed with the "Save" button in the Dashboard UI.

The popup you're seeing which mentions about the changes being made are as a result of you saving/deploying from the Dashboard UI

[Paul-Reed]

The warning triangle remains after the 'the flows on the server have been updated' popup has timed out.
So users need to refresh their browser to get rid of it?

[colinl]

I think this may well cause confusion. Consider this sequence of operation.

1. From the flow editor, select Layout Editor for a page. This opens a new browser tab for the layout editor.
2. Make changes to the layout and Save them, then select Leave Editor.The natural assumption here would be that this would return one to the flow editor, but it does not, it leaves the user in the new tab running the dashboard.
3. It is not immediately clear how to get back to the flow editor, however, once one does realise that the original flow editor tab is still there one selects that and there the changes made (such as group re-ordering) are not seen, the only indication is the yellow warning triangle warning that the have been changes. I guess the popup warning has already expired and gone away if one is not prompt about returning the the original tab.
4. When one does notice the warning and clicks it, the popup reappears, prompting one to review the changes, where in fact all one needs to do is to refresh the page.

I also notice that if one moves widgets about in the dashboard panel and then opens the layout editor without deploying, then further adjust the layout, save it, and return to the flow editor then confusion of the editor can easily ensue.

[joepavitt]

It is not immediately clear how to get back to the flow editor, however, once one does realise that the original flow editor tab is still there one selects that and there the changes made (such as group re-ordering) are not seen, the only indication is the yellow warning triangle warning that the have been changes. I guess the popup warning has already expired and gone away if one is not prompt about returning the the original tab.

This could be a better workflow. The Edit Layout button changes you're current tab to the Dashboard in edit mode. The "Leave Edit Mode" button then returns to the Editor. I could get on board with that. Also removes the browser session clash on reviewing/merging changes too.

Thoughts @Steve-Mcl

[Steve-Mcl]

When I took over the great foundation Joe kicked off, I hit an issue with API tokens (similar to the one Paul had recently and TBH, there are probably a bunch more edge cases out there) so I changed the workflow to emit the edits to Node-RED WITHOUT deploying them. The user had switch back to Node-RED and press "Deploy" to apply the changes. That eliminated the majority of the friction around merging but would have introduced different UX friction. To get past that poor UX, in my head, the workfow needed to be something like:

1. User choses to edit a page - a shading overlay dialog covers Node RED and displays "Dashboard Editing Page xxx"
2. The page to edit is popped out to a separate window (as it is now)
3. User goes about edits and eventually saves or exits, which returned the user to Node-RED where they would see the shaded dialog once more
4. The shading dialog would now display the edits that are held in memory (e.g. "Page xxx has undeployed edits") and at this point the user choses to Deploy or Discard the edits.

This meant there would be ZERO back door deploys via API & zero merge issues - everything is handled by the normal Node-RED deploy mechanism.

---

However, we have what we have & there are some improvements that would ease matters a little.

We could make both the "exit edit" AND the "save changes" buttons drop the user out of edit mode AND return them to the editor by closing the popped out tab. HOWEVER, Node-RED v4x seems to not always display the "Review Changes" and it is not always obvious you need to merge or refresh. That isnt going to change unless we dump the API calls or Node-RED improves how merges are handled.

[Paul-Reed]

FWIW, I favour only saving the changes from the editor, and not the layout dashboard.

Having a 'Return to editor' button which closes the layout dashboard, and returns to the editor, where the Deploy button would signify that a deploy is required, would feel more natural to me.

Not sure why 'Review changes' is necessary...
We've just seen what layout changes have been made. Are users really going to use this? It's just something extra to confuse new users IMO.

[joepavitt]

Having a 'Return to editor' button which closes the layout dashboard, and returns to the editor, where the Deploy button would signify that a deploy is required, would feel more natural to me.

You have also been using NR for years though. A lot of Dashboard users are new, and I didn't like the introduction of the steps:

Edit > Makes Changes > Save > Go to NR Editor > Deploy

So instead went for:

Edit > Make Changes > Save/Deploy

Which I think is more intuitive, especially for new users, and fewer clicks generally to achieve the same thing

[joepavitt]

Not sure why 'Review changes' is necessary...

Out of our control, that's a core Node-RED behaviour unfortunately

[joepavitt]

Are users really going to use this?

Are you referring to the Layout Editor entirely here, or the "Review Changes" bit?

[Paul-Reed]

Are you referring to the Layout Editor entirely here

No, the Layout Editor is a very welcome update, and should make it easier for users to design & build their layout.

It's the 'Review changes' feature that IMO is not likely to be used, and possibly adds confusion for new users.

We don't 'review changes' when we make changes to the editor flows.

[MaWa53]

I was "forced" to abandon Dashboard 1.0 because of display problems on WIN 10 & 11 systems.
So I thought it could be a good ocassion an I am now migrating my flows to 2.0 and am disapointed that handling layouts, especially of buttons and text fields, has become very awkward and IMHO clumsy.

I use a NR browser UI for my remote controlled CNC Mill, Laser Cutter and 3D printers running on raspberry Pi Zero W with PC, laptop and smartphone clients. On the laser cutter NR merges TCP serial commands from Lightburn and relays the control streams via raspi serial I/O to and from a marlin stepper controller.
The UI contains job button groups with x+, x-, y+, y-,z+,z-, home, park, pause, resume and so on buttons plus position display and edit fields for XYZ, Speed and Step sizes.
In 1.0 that was no big act. A new button appeared in the assigned groups matrix. I could resize the button after unlocking the size lock and freely move the button to its designated place. Other buttons already placed would move aside, the group automatically growing or shrinking if necessary and the result was done in a few minutes.
In 2.0 creating e.g. a XY Jog pad requires adding spacers to fill the open spaces and to get the buttons ordered as needed. I can reorder groups but can not change the layout of the widgets inside the group.
Am I doing something wrong or is the still a 'construction site'?

[joepavitt]

I can reorder groups but can not change the layout of the widgets inside the group.

You can, but it needs to be done (at the moment) from the Dashboard sidebar in the Node-RED Editor. We have a pull request open for it, but it requires my attention, and I've not had a chance to give it the time it deserves.

The reason for the layout shifts between D1.0 and D2.0 is heavily linked to responsiveness. We've had many customers complaining that D1.0 wouldn't work on mobile through to desktop, and so the changes we have introduced fix all of that. The disadvantage of this is that you can't now place and element in an empty space, it needs something either side (which we're doing with spacer)

Is the still a 'construction site'?

It always will be, as was Dashboard 1.0 for 8 years. We'll always be adding new features and improving the usability.