The buttons in/on the edit screen

(Sorry, this is the best fit group I can see)

I know it has been raised before, but as it is I keep getting caught with the buttons.

For example this: Two sets of buttons which keep catching me.

Another example:

Screenshot from 2020-04-28 19-31-32

Remember: These are *push buttons.

Yet, when you push them the button comes up. Which really can't happen in the real world. You push (or maybe press) a button: it moves down.

So when I want to select something I have to keep asking myself what I want, and why there are two of three buttons pressed?

When really the one pressed button is up.

Why is the selected button UP when you press it to select it?

But the currently selected button is down. (read it as: it sits in the shadow of) - you read it as: it is "on" instead.

To me, it looks raised.

Thus my question.

I understand your perspective.

To me it is darker, therefore pressed.
To others there is a line underneath, therefore up and not pressed.

It is not easy to serve everyone equally, there is probably a whole field of psychology behind it :smiley:

And to me, the buttons are all flat and the selected option is highlighted. Nothing to do with being 'higher' or 'lower'.

But yes, the perception is subjective to the individual.

(Was eating so now an explanation why I think they are raised.)

Let's look at the screen.

For me things are lite from the top. That is usually where light comes from. Above.

So looking at the button you can see the shadow (near the blue line):

Screenshot from 2020-04-28 19-26-59

That is below the button. Light coming from the top: It is raised.

Or did I miss something?

Yeah, ok, I can kind of accept that too.

But highlighted means (to me) brighter.

The button is darker.

It has to be said that I don't think they would pass WAI-AA would they - In fact a quick test shows that they wouldn't due to contrast issues as well as some other detailed issues. Particularly true on a very high-res monitor.

Personally, I'm used to it all so it doesn't especially bother me.

However, for anyone wanting to use Node-RED in a professional setting, this could become an issue. WAI-AA is generally accepted as the minimum standard now, some organisations might even require -AAA. Just to note that this is a legal requirement in many countries including the UK and EU.

@Trying_to_learn, you could maybe have a go a tweaking the standard theme to improve things and share with us?

2 Likes

I am flattered you asking, but I feel I am unable to do it because I have no idea how to edit the theme.

I could bash out some examples of what I think they should look.

Would that suffice?

What limits are there?
Resolution (screen)
Colours
Size of buttons

Just another observation to do with highlighting

As is, the greyed out button is highlighted - thus indicating it is the active one.

Screenshot from 2020-04-28 19-26-59

Screenshot from 2020-04-28 19-31-32

Screenshot from 2020-04-29 09-02-34

And I accept that these things are open to personal understanding.

And I don't want to argue for the sake of arguing. There just is/was something which was niggling at me that contradicted the claim that people see things differently. Which isn't my point of contention. Rather the whole scenario.

Today the kink has shown itself.

So, to re-cap:
In the above pictures, it is the greyed out one which is the active.

And I can't say it is right or wrong. But from a further out perspective, the tabs.......

Here is a picture. I goofed with the colours. Orange is the established scheme. Putting aside the underline (shadow) of the button.

The grey is the active selection.

Now the tabs. The active tab is Weather. Yet it is the opposite colour scheme to the buttons.

grey are the inactive tabs

The active tab has the same colour scheme as used in the other case for the inactive buttons.

Am I the first to notice this?
But that (I hope) is what is constantly getting me for selecting.

Tabs

the active tab is white. Inactive tabs are grey.

Buttons

the active button is grey. Other buttons are white.

I'll stop here, as I think that is what was/is my grief.

This is an example of how the buttons should look to better represent their state:

button_example

I don't think there is any ambiguity here.

I know the colour scheme is not exactly 2020, but that is the idea.

Using your browser's developer tools, it is actually quite easy to make dynamic changes to the visuals of the editor:

Use the selection icon image then click the element you want to change.

image

The Elements > Styles tab shows you all of the styles influencing the selected element & what file they are in. Play around with them to see changes. Sometimes, you may need to add !important after a style to boost its priority as in the example shown.

You will note the contrast is show when hovering over an element - the above element is showing sufficient contrast to meet WAI standards, but here is an example from the default settings that shows an element that has insufficient contrast:

image

This documentation shows you how to replace the CSS file for the editor:

https://nodered.org/docs/user-guide/runtime/configuration#editor-themes

Thanks, but I am already overwhelmed enough with CSS to start doing that.

It was merely a suggestion and finally - I hope - what was tripping me up all the time with the buttons, tabs and what is meaning what with respect to colours.

To throw a spanner in the works (because lets face it, that's always fun) have a look at a third party theme such as https://www.npmjs.com/package/@node-red-contrib-themes/midnight-red.

If you like it you could just run with it without making any further changes.

Although this doesn't affect the Dashboard I would recommend installing it onto a test instance of NR first, just in case.

It kind of looks nice, but I am not seeing details of what the buttons look like, compared to the active/inactive tab colours.

You will have to install it :wink:

But imo it does improve "visibility" in the areas you were referring to.

(I gotta ask)

If I don't like it.... I guess it is just the same command but remove rather than install - yes?

I sort of cringe when I do this because I get to see stuff like this:

found 34 vulnerabilities (22 low, 1 moderate, 9 high, 2 critical)
  run `npm audit fix` to fix them, or `npm audit` for details
me@me-desktop:~/.node-red$ 

Reading the instructions:

Add the following to the editorTheme section of your settings.js.

editorTheme: {
    page: {
        css: "<HOME>/.node-red/node_modules/@node-red-contrib-themes/midnight-red/theme.css"
    }
}

And I then get this:

If you read the link, initially you have to ADD a little text to the settings.js file for it to work. The same text would need to be DELETED if you don't like it. Not a big deal.

Or, you could make a backup copy of the settings.js file FIRST. Probably not a bad idea to do this anyway.

Of course, if you create a separate TEST instance of NR then it won't really matter, as you can blow the whole lot away afterward anyway.

What happens if you don't have a editorTheme section in the settings.js file though?
The operative word is ADD, not MAKE.

I just placed the text in at the bottom of the file.

But, please make a backup of the settings.js file first, if you are doing this on one of your prod systems. :thinking: