Same here, and I created a wish (linked in this thread) more than a year ago about it, so unfortunately, I would be surprised if it ever happens. Vote for it though to increase visibility.
Sorry. I’ll explain a little bit more. Under the yellow light of my studio it’s difficult to differentiate some grid layouts. Sometimes for me scenes only have two colours.
For me as a attentive reader the whislist system is flawed as a whole.
There are 3 essential categories:
Bugs. These are reported by users and this is great. Hundreds of people see more than a few devs. Nice to catch corner cases / race conditions. The devs should address reported bugs asap, servere ones even as a hotfix. In reality, only a few get fixed after a long amount of time and no other fixes are included alongside the logged ones on this forum. Is there no internal testing?
QoL improvements. These are no feature requests and dont belong to the wishlist! This one here is a QoL. Also, Polyend devs should also find some of them on their own, low effort
Wishlist. These are voted and are user based. But:
Where is the intrinsic effort of the devs? Why do they not come up with new ideas, bugfixes and QoL also? If no one reports something, nothing would be improved?
I think this whole system needs an overhaul.
And perhaps more dev crew members
Fun fact: It was green before they released it. I think they should have left it as green, yellow, blue. You can see the proto type at 0:18 in Emily’s video.
Same here. I find it extremely difficult to work like this because I also struggle with blue and purple. I can’t understand the reasoning behind choosing these two colors. There are two points related to this issue on the wishlist, but I would like to raise more awareness about it so that a solution can be found soon. How can we ensure that this problem gets more visibility?
Simple: People don’t know about colorblindness in particular, and about designing for accessibility in general, even though the web is full of resources about that. Especially they are unaware how simple it is to do checks for how things would look for the colorblind, you can upload photos or renderings to this website and set a type of color blindness
Here’s an example of the problems with the current design:
I don’t know if you mean to imply this, but this topic is not a QoL improvement, this is definitely a bug, because it breaks accessibility of the device to a significant group, and it can easily be avoided.
By QoL i mean things that need to be addressed for the usability of the device as soon as possible. Its a bad design decision but no code error per se.
But we agree it doesnt belong to a wishlist😊
You are completely right, and I agree with you 100% that awareness of what I referred to as the ‘colorblind accessibility topic’ is not as visible as many in the relevant group would like! However, the links you posted are very helpful for developers or UX/UI designers If they replace the current (blue/purple) design with the original one (green), it would definitely improve both the design and accessibility. So I also agree that this is a design bug. To raise more awareness on this topic, I think I will report it as a bug. Do you agree with this approach?
A bug is usually faulty execution of code, not a defective hardware.
I think this thread gets the attention by the devs.
If wanted you can always file a bug report, it gets logged when accepted.
From my perspective, I would still consider this issue a bug in UX/UI design, even though some might feel that the term “bug” applies strictly to software-related problems. Let me explain why I think it’s a fitting description in this context.
First, I want to say how much I enjoy using the Polyend synth—it’s a fantastic device that I’ve grown to really appreciate. I’m genuinely interested in its continued improvement because I see so much potential in making it even better. That’s why I feel it’s important to address this particular issue with the LED colors.
When I worked in software and app development a few years ago, particularly in testing, the term “bug” wasn’t limited to coding errors. It was also used for anything that hindered the usability or accessibility of a product, including UX/UI design flaws. In this case, the use of blue and purple LED Colors, which can be hard to distinguish for people with color vision deficiencies, makes it difficult for some users to fully interact with the hardware. While it’s not a coding issue, it’s still a design flaw that impacts how effectively users can operate the device.
To me, just like a software bug disrupts functionality, a UX/UI issue like this disrupts usability and accessibility. I believe addressing this would make the Polyend synth even more inclusive and user-friendly for everyone. I truly hope my feedback helps contribute to its continued success, as it’s already such a great product!
Well, you make it sound like this is a problem that has to do with people being colorblind, when it is in fact a problem of design that is unaware of colorblindness that makes the synth inaccessible to people with that natural and not uncommon variation in the way they see colors.
A problem that can easily avoided without sacrificing anything, I might add.
The more formal term for “bug” is defect, it might be easier to see that this would not only include problems with the code.
For apps and systems targeted at a wide user base it’s not uncommon these days to undergo regular accessibility audits, just like they would security audits, and in that process lots of accessibility issues are raised as defects that are then fixed. For software created by governments and institutions this is even mandated in the EU.
Definitely.
More developers and designers becoming aware of accessibility can only be a good thing. Accessibility is typically quire cheap when considered from the beginning, it’s only when it’s an afterthought that it can lead to additional costs.
That’s exactly why I posted the images, it leaves an impression that words cannot convey. When one reads about this, one might still think “how bad can it be?”, but with a picture you understand that other people obviously experience reality in a completely different way.
If you start adding aid for color blind-people, then deaf people might demand more focus on “sub frequencies” and epilepsy end-users with focus on how the pads flash or flicker to avoid a epilepsy seizure…list will just get started from there…
Following common design guidelines that make products more accessible to people is not the slippery slope you make it out to be.
On top of that your examples are entirely unrelated to the topic of accessibility, but about special applications and unintended effects.
That being said, deaf people are rarely using synthesizers anyway, and I doubt that there is anything in the current behaviour of the synth’s pads that could trigger photosensitive epilepsy.
But if such cases were to occur, and the firmware could easily be changed to accommodate them or prevent unintended side-effects, would you really argue against that?