Discussion with Mentors

[Lokeshsri11]

hey @Martchus
In {filter_form.js} we should use Cache jQuery selectors for improved performance and Combine if statement and continue statement into one line for improved readability and last we use modern array methods like map() instead of for loops for improved readability and conciseness If you want I can provide changeable code then you review it

[Martchus]

If you want I can provide changeable code then you review it

Sounds good. As mentioned before, you'll find room for improvement all over the place when browsing our JavaScript code. We have nothing against modernizing the code base in general; it just hasn't happened yet. The only exception are JavaScript features that would bump the minimum browser requirement unreasonably high (although we don't have any explicit policy on that).

I personally also try to avoid using jQuery at all in new code. We will likely not get rid of that library in the foreseeable future but maybe it makes still sense to move forward using native JavaScript APIs instead of improving jQuery code at this point. (Again, we don't really have a policy on that in the team. That's just my preference.)

[kalikiana]

Examples coming to mind are $.ajax versus XMLHttpRequest and DOM access. Those actually tend to be slower with jQuery.

[Lokeshsri11]

ok

[Lokeshsri11]

Well, @Martchus and @kalikiana , I will attempt to create a graphical UI for the OpenQA frontend and will share it with you for feedback


@okurz can you also check it

[Martchus]

I will attempt to create a graphical UI for the OpenQA frontend

Wait, a UI for the UI? I suppose you mean some high-level dashboards. I suppose the answer to that from our side is "why not" (but also "why?", see the last paragraph). However, please note that we put much effort into designing our current dashboard views. Maybe not from the perspective of having fancy graphs. However, we put though into what kind of views different groups of users within SUSE (and the community users on openqa.opensuse.org) need. We won't "revamp" that in a willy-nilly way.

---

About the designs you've been showing:

• I don't think using "capslock" is working well with the names "openQA" and "openSUSE". That's just not how those names are written anymore as the casing is used to separate different parts of those names. I'm also reluctant about introducing alternative spellings like "OPEN-QA" (even if they preserve the different parts). It is just inconsistent.
• It would be nice to be in-line with https://en.opensuse.org/openSUSE:Artwork_guidelines instead of re-inventing the wheel.
• We already have a defined color set for different job states/results. Unless it really breaks the design I'd recommend to stick to them. At least be in-line with them.

---

I'm also wondering how this is motivated. I mean, normally we don't just write code to increase the size of our code repository :-)
So what use cases do you have in mind (that are not covered by existing dashboards)?

[Lokeshsri11]

ok I'll understand, I just only think that how can we make openQA frontend more user/dev interactive

[Martchus]

I've just merged your PR. More changes are welcome of course. Please take note of #5068 (comment) before doing so. It is just about the commit messages :-)

[Lokeshsri11]

Hello mentors how are you, today I do some research and study that how can I make any web frontend (websites) more accessible. Also, how can we ensure that the color contrast of our website is suitable for visually impaired individuals?

1.Firstly, color and texture are crucial components, and it matters which colors are used for text against the background. For example, black text is appropriate for a yellow background, but white text may not be. On websites such as OpenQA, where the pass/fail stripes are essential, the text may not be as visually prominent. To address this, we can either assign a separate meaning to each color (e.g., red means fail, blue means pass), or we can use other techniques to make the colors distinguishable.

2.When coloring graphs or other elements, using texture and patterns in addition to color can make them more colorblind-friendly.

3.We can also provide manual font size adjustment on our website.

4.It's recommended to avoid using phrases like "click here" and instead provide links more effectively, as colorblind users often use keyboard shortcuts.

5.Lastly, I am currently studying about color combinations and other things to improve website accessibility.

[Martchus]

how are you, today

I'm fine, especially because the Easter break is approaching. However, that also means there's only limited availability from us in the next days.

I suppose the points make generally sense (except that blue should never mean "pass"; we should really not flip existing conventions).

[Lokeshsri11]

Oh ok, Happy Easter Martchus and have a lot of fun! <3

[Lokeshsri11]

One more thing here see what I got a calculator through which we can know which text is best on which background :)
so, I think in dark mode on green background white text is more visual

[Lokeshsri11]

Hello @Martchus @kalikiana , I hope you are enjoying Easter to the fullest! :)
I have conducted thorough research on the four problem points of the openQA project and have discovered various solutions to improve website accessibility and make it color-blindness friendly. I would like to share these points in a structured manner and would appreciate your feedback on them.

1.Firstly, regarding the issue with the color palette not providing adequate contrast, I would like to ask if you have the option to change the colors of the palette. If yes, that would be great. If not, the alternative would be to work on the given color contrast. I have already made some progress on this and found that the text color contrast should be 4.5:1 against the background. To check this, we can use a reliable tool such as https://colorpalettecombos.netlify.app/, which can test up to 12 colors at once.

2.Secondly, the problem with the dark mode can also be resolved by performing a color contrast test.

3.Thirdly, the issue with the website not being color-blindness friendly can be addressed by using different icons and text alongside colors to indicate what each element means.

4.Lastly, with regards to the fourth point, we can utilize the built-in screen reader called "Voiceover" for iOS and download a free tool called "NVDA" for Windows. Additionally, we need to ensure that our website can be navigated using keyboard shortcuts without a mouse? We should also ensure that we can identify whether the menu button is open or closed? whether a button has been pressed? and where a particular link will take us? ETC

[Lokeshsri11]

we can add code like this for ensure that interactive elements can be accessed and activated using a keyboard alone and Add focus styles for users who are using the keyboard to navigate

a:hover {
outline: 2px solid #0077cc;
}

[Martchus]

Supposedly it makes indeed sense to use some tooling to verify contrasts - also I assure you that you won't need it to identify the most problematic pages/issues (and we also have #4877 and #4875 and progress tickets linked from the GSoC issue). Those I would focus on first and then do tweaks later.

I'm also wondering whether we could add checks for contrast directly into our existing Selenium-based test suite. One can run/inject arbitrary JS code via Selenium so this should be possible. It could be part of t/ui/04-appearance.t.

I'm not sure whether advertising generic iOS/Windows-specific screen reading tools is going to help our users. I suppose users needing them are aware of the options available on their platforms anyways. Of course we could try out those options and tweak our pages to work better with them. Our users are mainly using GNU/Linux so I'd try a tool available for that platform. If there's no decent solution on GNU/Linux anyways I'd fallback to another desktop platform. Supposedly Windows is the next popular choice. Unfortunately it isn't used by any openQA developers themselves and running openQA locally on a Windows machine has never been tested yet. So it might not be easy to setup a development environment for testing (maybe WSL can help). I suppose the screen reading part is the last important one for now. So as mentioned before, I'd focus on the low-hanging fruit first which is fixing severe issues of the dark mode.

I guess an outline makes generally sense but likely not on :hover.

[Lokeshsri11]

Okay Martchus, now I will totally focus on solving issue numbers #4877 and #4875.

[Martchus]

I suppose keyboard shortcuts would also improve the accessibility/usability for some users. We've recently added a ticket about it. So I suppose this could be worked on as part of openSUSE/mentoring#202 as well.

[Lokeshsri11]

Yes @Martchus, keyboard shortcuts play a significant role in website accessibility, as I mentioned earlier and also included in my proposal. and I have started working on it, and I will provide you with the results soon with new PR

[Lokeshsri11]

hey @Martchus, I read a lot in the last few days to understand about keyboard accessibility. And as I checked openQA's website, it just has a keyevent and also It seems that there "Filter and Settings" button is not receiving keyboard focus. so we can add tabindex="0" attribute on it to make it keyboard focusable and we will also need to attach keydown event

[Lokeshsri11]

hey @Martchus Is there any way we can test our code before the deployment, all these 33 testcases like CodeCov, CI/CD, etc.

[Lokeshsri11]

Thank you @Martchus This is very helpful. 😊

[okurz]

IMHO nowadays within a WSL2 environment you should be able to execute most if not all tests locally.

[Martchus]

Right. Using WSL2 would basically be the container approach I've mentioned (although it means enabling Hyper-V under the hood so it is actually using VM technology after all). That's definitely the easy way :-)

[Lokeshsri11]

ok I have installed WSL Ubuntu by the way, I use this to check the code. By the way, thank you for replying and helping so quickly. <3

[Martchus]

I haven't used WSL myself yet but I believe openSUSE Tumbleweed is available there as well. So you make like your life even easier by sticking to that (or any openSUSE distribution) - simply because that's what our team mainly uses.

[Lokeshsri11]

Thanks to all finally my WSL linux command is set as my local cmd prompt

[Lokeshsri11]

Sir, now my entire local setup is completely done, now I am checking all the code locally by running 'npm run lint' etc. is also being checked, now squashing is also being done very easily.

[Martchus]

For something totally unrelated I've just came across the following test scenarios:

• https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=WSL&machine=uefi_win&test=wsl-main&version=Tumbleweed
• https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=WSL&machine=uefi_win&test=wsl-main&version=15.4

So openSUSE Tumbleweed and Leap 15.4 can definitely be installed via WSL and we test that in an automated way. These tests are kind of a step-by-step instruction for installing them (plus some additional fiddling to open a serial port which a normal user shouldn't need).

EDIT: Ok, this test uses an image provided as an openQA asset. So these exact steps are likely not that helpful for end users. Nevertheless I find it interesting :-)

[Lokeshsri11]

And sir, I was also thinking that I should write docs of how to set up WSL for Windows users.

[Lokeshsri11]

What is Manual daemon setup?

[Lokeshsri11]

Thank you for your support but I have rejected from GSoC 👍

[okurz]

@Lokeshsri11 I am very sorry to hear that. We would have appreciated if we could have mentored your project but it seems this year there are a record high number of project proposals that came to Google and we didn't get the grant. You already excelled in your contributions to this project as a newcomer even before the official start of GSOC contribution phase and we highly appreciate that. We welcome further contributions and will support in any upcoming pull requests if you are still interested. I wish you good luck and a lot of fun on your way forward wherever it may lead you :)

[Lokeshsri11]

Why is this project not selected?

[okurz]

We just state which projects we would like to mentor which included yours. But then Google decides how many projects they can sponsor and unfortunately that did not include our projects this year.

[Lokeshsri11]

hey @okurz Are you moving this project to LFX?

[okurz]

Do you mean https://lfx.dev/ ? Good idea. I will look into that

[Lokeshsri11]

yes

[Lokeshsri11]

https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2023/02-Jun-Aug/README.md
Today is the last date for the project proposal

[okurz]

It's a nice idea but I don't see "accessibility improvements for openQA" remotely related to to be proposed topics