Write guidelines for screenshots

[Calinou]

The current editor and project (2D/3D) screenshots tend to be inconsistent, so we should write some guidelines for screenshots that are intended to be featured in the documentation.

Some suggestions:

• Always use the default editor theme and font settings.
• Window borders should not be visible unless mandatory, e.g. for a window management tutorial.
• For highlighting regions of the editor (such as buttons or a panel), use a 2 pixel-thick bright red (#ff4444) outline without rounded or beveled corners. For large regions where an outline would be hard to see, use a semi-transparent bright red rectangle with 40% opacity.
• For 3D screenshots: Use 4× MSAA.
• For 3D screenshots: Enable anisotropic filtering on the project's textures and set the anisotropic filter quality to 16× in the Project Settings.
• Take all screenshots in hiDPI?
  • This will make them larger and will require handling to scale them down (it should be fairly easy, it's just a CSS change) but will look much nicer on hiDPI displays such as Retina.
  • This would also make contributing harder for people with low-resolution displays (< 1920×1080), as they wouldn't be able to fit everything on screen at 2× scaling to take screenshots.

Feel free to discuss below. 😃

[pwab]

I totally agree with that. Just two comments:

For highlighting regions of the editor (such as buttons or a panel), use a 2 pixel-thick bright red (#ff4444) outline without rounded or beveled corners. For large regions where an outline would be hard to see, use a semi-transparent bright red rectangle with 40% opacity.

• What about multiple regions? Especially when it comes to "1. click here and 2. click there". (Or something extreme like this found here)
• How to handle text on images?

This would also make contributing harder for people with low-resolution displays

• A simple workaround would be to ask for help while submitting a PR. One can simply take a screenshot as a placeholder and ask other people with larger displays to redo it.

[pwab]

And I also want to add something regarding a11y:
If we choose to stick to this combination (red regions on default editor theme) people with Protanopia (specific kind of color blindness) could have a hard time looking at the pictures.

Example:
Normal view (taken from here)

Protanopia

Deuteranopia

There is also Protanomaly, Deuteranomaly (most common), Tritanopia, Tritanomaly and others but RGBlind is (not yet) able to render them.

[akien-mga]

Would there be a "safe" color that we can use instead of red?

[NathanLovato]

Good call! I hope we manage to have this work.

Take all screenshots in hiDPI?

We already lack contributors, so I'm not for an extra hardware-related entry barrier.

Also already saw a contributor with screenshots from a 4k screen and it was ugly. Dunno if there's a high-dpi/scaling option for the editor's interface but if there is it's off by default. Also at least until beta 2 Godot doesn't handle Windows's UI and text scale property too well. Got a 4k screen and had to revert to 1080p for that

How to handle text on images?

I'd recommend not to have any, write text around the images. If you need to show multiple steps, you may use multiple images instead. Text would add several issues:

1. placement
2. font
3. size

Etc. Good luck having people respect many guidelines.

Would there be a "safe" color that we can use instead of red?

Red is an aggressive color in any case, I'd recommend to forget it altogether.

Yes, there are several good options:

1. you can play with value contrast and use a light grey. The interface being dark it'll work in every case.
2. Otherwise a lighter Godot blue would work - again, playing with values.
3. If you need color and color contrast most often for the color blind you'll use green and purple as they tend to work well in most cases

[pwab]

Red is an aggressive color in any case, I'd recommend to forget it altogether.

Fully agree. 👍

Regarding color blindness I can totally recommend reading this post. These are the main points when being color blind friendly:

1. Avoid the situation where important information is conveyed only in the form of color.
2. Avoid the situation where texts and objects are obscured with the background.
   For example, there should be enough contrasts in brightness and saturation between texts/objects and backgrounds. Avoid the combination of colors that have the same brightness but different only in hue. [...]
3. Make texts and objects as thick or big as possible.
4. Caution when using red.
   For non-colorblind people, red is the bright and vivid color. But for colorblinds, it is as dull as blue or dark green. Especially for protanopes, who cannot detect long wavelength of red light, dark red appears almost as black. Thus, avoid using red characters on black backgrounds, including blackboards.Note that black text and red text look the same for protanopes. Colorblinds people, however, still feel certain ranges of reds as bright and vivid colors. [...]

They also provide a set of colors that is unambiguous both to colorblinds and non-colorblinds. Regarding the blueish default background possible choices would be yellow, orange or a light blue. As @NathanLovato already said brightness or saturation differences are very important so white and light grey are also possible because the background of the godot interface is often very dark (for further testing: here you can play with contrasts).

I created a little test matrix:

The chosen colors are only some examples. There might be nicer ones.

[pwab]

Another question which should be answered in a guideline: #946 (comment)

[mhilbrunner]

For all screenshots: use an PNG optimizer.
Also, yes, 1080p max. 720p is fine too.

[mhilbrunner]

Closed by #1031.