Support arbitrary color schemes

[Lykos]

Is your feature request related to a problem? Please describe.
Not really a blocking problem.

Describe the solution you'd like
Some way of specifying the color scheme. Similar to the sch parameter for visualcube: http://cube.rider.biz/visualcube.php

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

[Vivaldo-Roque]

Is your feature request related to a problem? Please describe. Not really a blocking problem.

Describe the solution you'd like Some way of specifying the color scheme. Similar to the sch parameter for visualcube: http://cube.rider.biz/visualcube.php

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Any progress?

[lgarron]

Any progress?

Unfortunately not. There are several more urgent features, and I don't want to ship a half-baked color scheme until I know how to make it sufficiently accessible.

For now, you can use a picture cube for any custom appearance of the puzzle. See https://experiments.cubing.net/cubing.js/twisty/mkbhd.html for an example.

[bcube2]

If you are still looking for a solution and are willing to try a similar simulator, AnimCubeJS supports arbitrary color schemes. I would recommend to start with the facelets parameter and optionally go to the colors parameter (or the colorscheme parameter).

[DougCube]

I would really like to see this feature implemented in Twizzle Editor. In particular, puzzles like FTO and megaminx have lots of non-standard color scheme users in the community.

For the GUI, can take inspiration from other programs that support it, like Cube Explorer, Cubeast, and Hyperspeedcube.

[lgarron]

Yeah, color scheme customization is still important, but I expect it will be at least year before I can properly tackle it.

For the GUI, can take inspiration from other programs that support it, like Cube Explorer, Cubeast, and Hyperspeedcube.

These programs are less oriented around sharing and have significantly less scope than cubing.js and Twizzle, so they have simpler UX tradeoffs to handle. But I'm definitely glad to take more suggestions for prior art!

In particular, puzzles like FTO and megaminx have lots of non-standard color scheme users in the community.

By itself, this is not necessarily a good argument for custom color schemes.

For comparison, people also use a lot of incompatible variations on notation, and it is against the goals of cubing.js and Twizzle to support incompatible notations.

The community has also had success with normative specifications like Speffz. Even though it's very reasonable to have different preferences, there is value in specifically using Speffz for anything that is meant for sharing.

In a similar way, custom color schemes are at odds with features that enable sharing or communicating about puzzles. They can also increase significant developer UX confusion and edge cases for people using cubing.js. This is in contrast with benefits like:

• Color contrast can be an accessibility issue. I don't see problems with with a feature to increase contrast for common vision issue while roughly preserving colors, but that may not be enough for all users and all puzzles.
• People would probably take a lot of delight in being able to choose custom colors and shades. They may prefer this to other inconveniences.
• When comparing a reconstruction to a video, it is highly valuable for the color scheme to match.

I still expect it will take a lot of time to navigate the problem space and solution space, and I also think it's important not to ship something half-baked for this.