UI and API for selecting color profile is unnecessarily limiting.

[pixelzoom]

In the Preferences dialog, the UI for selecting a color profile looks like this:

And the API looks like this (example from gravity-and-orbits-main.ts):

  const simOptions: SimOptions = {
...
    preferencesConfiguration: new PreferencesConfiguration( {
      visualOptions: {
        supportsProjectorMode: true
      }
    } )
  };

This assumes that there are only 2 color profiles: 'default' and 'projector'. PhET specifically designed the color-profile API to support additional profiles, to meet future needs. While no sim currently has more than 2 profiles, this UI and API will be insufficient the first time we need a 3rd profile.

A more flexible API would pass the color profiles to the sim (along with their descriptions), and the UI would present those profiles as radio buttons.

[pixelzoom]

Also worth noting is that package.json (see phet.colorProfiles) and color-editor.html (see phetmarks) support profiles other than 'default' and 'projector'. Shouldn't the Preferences dialog do the same?

[arouinfar]

This assumes that there are only 2 color profiles: 'default' and 'projector'. PhET specifically designed the color-profile API to support additional profiles, to meet future needs. While no sim currently has more than 2 profiles, this UI and API will be insufficient the first time we need a 3rd profile.

This came up in design meeting while we considered UI options for Projector Mode, but decided to use a switch to match some of the other controls already in the Preference Dialog, like Interactive Highlights or the Voicing/Sound switches. The previous Projector Mode checkbox was also a binary control. Since there are no plans to add support for additional color profiles for the foreseeable future, this approach seemed reasonable.

Radio buttons would be more generalizable. If we want to consider it, here are some mockups including a fictitious 3rd color profile.

From an aesthetic perspective, I prefer the current implementation with the switch. It's clear and easier to understand, but I also recognize that it's not future-proof.

[pixelzoom]

I get it. And I'd prefer the cleanness of the on/off switch -- if it was really a binary choice.

But it's not binary. So there's a big mismatch between the UI and color-profile API here. Are we certain that there will be no need to add additional color profiles? Nothing related to a11y or research, like a high-contrast profile?

[zepumph]

Can we make the argument though that it is at least not more of a mismatch as what is already implementing ProjectorMode checkbox (which uses assumptions and assertions to map colorProfile into projector mode and "other")? We can always change the UI when it is time to add more color profiles.

For context, you are catching me after ~5 months of scope creep on the upcoming PhET-iO batch release, so anything we can do to move towards publication is a win to me!

[pixelzoom]

Agreed that it is no worse than using ProjectorModeCheckbox in an Options dialog.

[jessegreenberg]

The previous Projector Mode checkbox was also a binary control. Since there are no plans to add support for additional color profiles for the foreseeable future, this approach seemed reasonable.

Agreed and this is what we discussed in the meeting. But other sim code/tools do support multiple color profiles, it makes sense for this dialog to support that. If we need multiple profiles later will that require PhET-iO migration rules (I am not really sure what is involved for that)? Code side, it should be easy to change the UI/API for multiple profiles. ComboBox might also work and conserve space. Now could be a good time while work in Preferences is fresh.

@arouinfar @kathy-phet can you comment on what is best for design here and if the UI needs to be ready for multiple profiles now (I think mostly for PhET-iO compatibility in the future)?

[kathy-phet]

I would like to support a forward planning version, where we go with radio buttons, so the choices are all visible to the user.

I prefer "Display Mode" or "Display Options" or something with the word "Display", rather than "Color Profile".

[arouinfar]

Here's a mockup that I reviewed with @kathy-phet. It contains all of the options we can think of that would fall under "Visual", including the BAM-specific high contrast particles.

[zepumph]

Discussed during PhET-iO meeting today. @arouinfar and @kathy-phet would like a "Display Mode" radio button group.

• Please use the above mockup exactly except that "Default" doesn't need any extra description and . . .
• "Projector: light theme with higher contrast for visibility in classrooms"
• Keep colorProfileProperty as the name of the mode Property, and don't change the name of the linkedElement/references key in the PreferencesModel.visualModel.

[samreid]

In discussion with @arouinfar and @kathy-phet, we agreed this is non-blocking (since it won't affect the phet-io api) and can actually be deferred until we have a 3rd color profile. We don't know what sim that would be at the moment.

@arouinfar comments that for the binary choice, the toggle switch works nicely at the moment.

Note that this UI component will not be phet-io instrumented and hence will not appear in the studio tree.

[samreid]

When this issue undefers, it would also be a good time to work on https://github.com/phetsims/joist/issues/865