Request for feedback: Closing the Edit Dialog

A PR has been proposed to change a behaviour in the editor and I wanted to get wider feedback.

Currently, if you have a node's edit dialog open, clicking outside of the dialog will close the dialog as if you had confirmed the changes.

This is the behaviour we've had since the early days of Node-RED. Originally we treated a click outside the dialog as a 'cancel' - but we had complaints that it was then too easy to accidentally loose changes - so the current behaviour was set.

The PR proposes to change our behaviour to not close the dialog when clicking outside. The only way to close it will be via the Done/Cancel buttons (for the keyboard shortcuts Ctrl-Enter/Ctrl-Escape).

Whilst no-one else has flagged this as a problem, my experience tells me there are often bits of behaviour that people don't like, but not enough to actively feed it back until invited to. So here's your invitation.

There are three options - keep existing behaviour, adopt the PR, or something else. If you pick something else, please add a comment on what that might be.

  • Click outside confirms changes (existing behaviour)
  • Do not close dialog when clicking outside (PR proposal)
  • Something else
0 voters

I concur with the new approach. On one hand, we should never lose changes unless specifically clicking on 'Cancel' or typing 'Ctrl/Cancel' (like in any document editor). On the other hand, we should never auto-save changes (overwriting the previous content) unintentionally.

I propose to add a 'Discard changes?' OK/Cancel warning alert when the user clicks outside the dialog, where cancel leaves it open.

Alternatively, the editor can just ignore the key-click (as if the dialog is modal).

That was considered. The problem is, due to the dynamic nature of the edit forms, the editor doesn't know if there are changes or not - so it would always prompt even if the user hadn't changed anything. That would get very annoying in my opinion.

1 Like

I agree - we don't need more annoying prompts in our lives. :grinning_face_with_smiling_eyes:

2 Likes

My vote is both Do not close dialog when clicking outside (PR proposal) AND Something else

One thing that all dialogs should support is cancel via esc

So I vote something else:

  1. Do not close dialog when clicking outside
  2. Support esc as Cancel
6 Likes

We did, at one time, have this set as the default keyboard action for closing the dialog.

Again, it drew complaints around accidental cancelling of the dialog and losing changes - so we changed it to Ctrl/Esc.

I think this was primarily related to the Function node - and all of the pop-ups monaco generates - hitting escape is a natural way of getting rid of whatever monaco is obscuring the view of the code with... but if you hit it once too often, or at the wrong time, you lose all your work.

1 Like

Well for me on WIndows 11, CTRL/Esc pops up a totally useless jolly thoughtful offering from Microsoft. It seems to be a list of (deleted) bloatware apps that came with the PC.

I like the idea that Esc exits a dialog without saving. Now and then one gets a popup and the browser for some reason won't scroll to the Cancel button. The first thing one tries in this circumstance is Esc.

You can remap the exit to Esc - that's what I've done.

Ahha. I didnt realise we did that otherwise I would have pointed out (as Julian did) that ctrl+esc is an OS level shortcut on MS Windows to the Start menu (I think its the same on some linux desktops too)

TBF, I think esc is pretty much the universally accepted mechanism to cancel a modal dialog! Maybe we should be opinionated here?

I like that jbudd.

I also prefer the original behavior as it helps with my disability, i do not have to be so accurate with the mouse.

It is poor UX. Generally, people do not expect that type of interaction to save changes but rather to cancel them.

While I don't especially like the option to not be able to click outside the edit dialogue at all, it is the least objectionable option unless a pop-up warning is added which we've all agreed is not good either. :slight_smile:

Because one of the key features and capabilities of Node-RED is to provide powerful compute capabilities to people who are not expert developers or technologists.

1 Like

@gregorius The reason I opened this poll was to get feedback on the proposal. Nothing is being dumbed down here and please don't be insulting to our users.

There has been a number of occasions where someone has raised a simple question about some behaviour and there is a sudden rush of 'me too' type replies in support of a change - but nothing had been said until that one person took the time to ask.

My personal preference is not to change our behaviour for this item. But I didn't want to take that decision if this turned out to be one of those things users wanted to see changed but not enough to have asked.

We could add an option to toggle the behaviour on/off - but I'm trying to avoid the settings panel turning into VS Code where its 100 pages long of options.

Regarding the idea of a prompt - I've already said that was considered and dismissed as it would be annoying.

As for other features unrelated to this; the PRs are raised, you can see what is being proposed in detail. If you have feedback, please provide it. I do not want this to get derailed into a discussion on those other features - but rest assured I'm going to great lengths to introduce them in a sensible/pragmatic way.

@gregorius
As the person who pointed this counter intuitive UX issue, I felt offended by your words.

Sorry about that.

@knolleary it would be nice if you also ask the opinion of unbiased(people that never had contact with node-red editor) and biased UI/UX specialists in a separate pool. Their opinion will be more assertive for onboarding new Users.

I can see the arguments that this may not be a "standard" behaviour, but as I am so used to it now, I don't think I would ever get the hang of it, if it was changed.

I do tend to create some quite complex function nodes, so closing without saving would be very upsetting :anguished_face: and in my option would HAVE to have a dialog to confirm.

I would much prefer my work to be saved than not, the chances are that if you accidently saved a typo it would flag the node in error, and you always have undo option.

Retreats to minimum safe distance :person_running:

1 Like

The favoured change to not close the dialog. So you would not be losing changes.

Imo, it is better than applying changes "just because you had a look see* which if I'm honest dislike a lot. Consciously, I never want changes saved unless I press done. Partly because I understand what happens under the hood and partly because of how pretty much every other application behaves.

This change forces a conscious choice and it's closer to accepted ux norms.

1 Like

It used to be that, on a PC, no app would either save or abandon changes unless you confirmed that you really meant it.
These days though such things as settings and browser options are much more likely to be saved silently on exit.

So saving merely by exiting the dialog (clicking outside it) seems to me perfectly fine in Node-red. And there is the blue dot to visually confirm that a node has been modified.

I know I’m biased but I’m ok with the existing behaviour as indeed others have pointed out a) you get the blue dot to know something has changed b) it’s only saved editor side… and you still have to hit deploy to really save it and c) you can hit undo to undo.

Having said that I’d be ok if the answer was do nothing but in that case it should be part of v5 and any other UI changes

1 Like

I went with Something Else.

My 2c is to add an additional User attribute.
Where by default it is IS checked (allowing the currently expected behaviour to remain)

But addressing the concern also.

Personally, I open Dialogs to check things often - and as I'm reviewing, already moving my mouse to where I need to be next, having to cancel first - whilst not a massive issue, will be slightly annoying.

Hence my suggestion, to allow the user to alter behaviour.
My suggestion might need to be flipped, to address the current default that everyone has currently.

Sorry - if this has already been suggested

3 Likes