fix contrast in console ngql

[johnny-smitherson]

#770

What type of PR is this?

• bug
• feature
• enhancement

What problem(s) does this PR solve?

Issue(s) number:

#770

Description:

Very bad contrast on GQL query shown in studio console #770

How do you solve it?

color: #111;

Special notes for your reviewer, ex. impact of this fix, design document, etc:

[CLAassistant]

All committers have signed the CLA.

[johnny-smitherson]

before

after

[QingZ11]

@johnny-smitherson Thank you for your contribution 🤗

[yyh0808]

Great PR!
I suggest changing the color value to #0B8373 to align with our design standards so we can merge your PR. Additionally, I recommend using the Roboto Mono font to comply with our typography guidelines.

[johnny-smitherson]

changed font and colors

[huaxiabuluo]

designer's suggested style

font-family: Roboto-Mono, sans-serif;
font-weight: 500;
font-size: 16px;
color: #0B8373;

[huaxiabuluo]

adjusting the font-size to 16px might look better ?

[johnny-smitherson]

Thank you for your suggestions and insight into how this problem came to be.

I still am not convinced by your Green-on-Green, Red-on-Red and "smaller font" design guidelines.

I don't think developers that look at this exact field many hours a day for small bugs in the code prefer pretty-looking UI to easy-readable UI - maybe this one can be uglier than normal?

---

After reading the pixel color values from the images above:

contrast 3.5 = "Poor"

It's my personal opinion that what we're ending up with isn't that much different from where we left.

with black foreground: contrast 16 = "Super"

---

Maybe I'm looking too much at this page?

Maybe the solution would be to go further, e.g. Use same syntax highlighting from the code editor, on very slightly gray bg?.

I will probably continue to use my personal fork that uses black text foreground instead.

Please feel free to take over the PR or close it and hand it off to the product design.

[QingZ11]

@johnny-smitherson As an individual, I agree with your viewpoint, and I also do believe that readability is more important than aesthetic design. Your PR will be handed over to the UI designer @yyh0808 of NebulaGraph for handling.

Once again, thank you, Johnny, for your feedback. Both the PR and UI feedback are beneficial to us.

[huaxiabuluo]

Thank you for your suggestions and insight into how this problem came to be.

I still am not convinced by your Green-on-Green, Red-on-Red and "smaller font" design guidelines.

I don't think developers that look at this exact field many hours a day for small bugs in the code prefer pretty-looking UI to easy-readable UI - maybe this one can be uglier than normal?

After reading the pixel color values from the images above:

[contrast 3.5 = "Poor"](https://coolors.co/contrast-checker/0b8373-b2ece4) It's my personal opinion that what we're ending up with isn't that much different from where we left.

with black foreground: contrast 16 = "Super"

Maybe I'm looking too much at this page?

Maybe the solution would be to go further, e.g. Use same syntax highlighting from the code editor, on very slightly gray bg?.

I will probably continue to use my personal fork that uses black text foreground instead.

Please feel free to take over the PR or close it and hand it off to the product design.

hi @johnny-smitherson, thank you for your feedback.

In popular component libraries, there are several color combinations for successful message displays:

1. green background + black text (AntD <Alert type="success" >)

2. light green background + dark green text (MUI <Alert severity="success">)

3. light green background + dark green text (AntD <Tag color="success">)

4. light green background + white text (MUI <Alert variant="filled" severity="success">)

5. others

https://chakra-ui.com/docs/components/alert#status

https://element-plus.org/en-US/component/alert.html

https://react-bootstrap.netlify.app/docs/components/alerts#examples

https://tailwindui.com/components/application-ui/feedback/alerts#component-aa7cc38968c95d870db6ba62e76b8e0f

Each combination has its own use scenarios, but in general, there may not be such strict rules. Studio 3.x version does not provide the function of customizing themes, but in the new version, we provide the ability for users to match colors according to their own preferences, please stay tuned.

[johnny-smitherson]

Thank you for the examples above, I see where the problem comes from.

All examples you sent are illustrated as alerts - toasts, messages, responses, things like "Error 404" or "Operation Success" where the color of the message is 90% of the message information.

The field we're talking about is different - it's ngSQL code the programmer put in 30 mins ago, that needs to be easily readable.

I think the problem we're facing is caused by the design choice of combining the operation status (success or fail) with the query content.

Maybe the fix here is to show a green SUCCESS or red ERROR box, with whatever contrast looks pretty, but the source code of the query should be very high contrast.

Here is what i mean, courtesy of mspaint.exe

As you can see, it does not matter how pretty the "Success" box is, I will still be able to read the query. I can also quickly pattern match it to be code, not random text, because of the syntax highlighting and font being the same as the query box. The code also looks the same way regardless if it was in success or error.

Good luck!