Prepare a shareable version with prototypes and other improvements

[jessegreenberg]

We have been making some improvements to the prototype content so that it is nicely shareable. That includes

1. Adding media pipe controls and making their content specific to this sim (Update MediaPipe support for latest version #258)
2. Improving controls for BLE connection (When to show tangible controls in Preferences #315)
3. Adding support for Voicing of the BLE controls (When to show tangible controls in Preferences #315)
4. Adding screen reader support for tangible and BLE controls (Make Preferences Menu screen reader accessible #441)
5. Following up from Make Preferences Menu screen reader accessible #441, maybe we want to make the localization tab screen reader accessible as well. (not done yet)

How should we share a version with these changes? Should all of these improvements be included in the version we share? Some options:

• We could publish a dev version with almost no effort but none of these improvements will be in the live 1.0 release. It might be nice to show off prototype features with a query param from the latest version on the website.
• We could patch these fixes into a maintenance release - A little more time consuming up front but less likely to introduce bugs and therefore would have lower QA and bug fixing cost. We could select which changes we want to include in the release.
• We could publish a 1.1 version, starting a new RC process from the beginning. Much more QA time required, but less time spent cherry-picking changes into the 1.0 branch.
• Other?

[terracoda]

I think the cleanest thing to do would publish the fixes in a 1.1 version, and since QA is free at the moment that seems like a good path. Here are some comments from my email exchange with @kathy-phet and @emily-phet which may be helpful for framing of the goals for the long term.

@kathy-phet:

If there are current issues with the preferences menu as it is implemented on Master, it seems like the first step would be to do an iteration where Master would be fixed, before sending it back into QA and redeploying (perhaps as a Maintenance Release) for sims where it isn't working.

@emily-phet:

It would be ideal if any sim that supports alternative input also has a functioning, described, screen reader accessible preferences menu. Considering most of the preferences menu contains boilerplate content, for any sim, only what is custom to the preferences menu would need some additional information added in the PDOM. In what I’m proposing, all sims with alternative input would have a screen reader accessible preferences menu, and screen reader accessibility would be part of the QA process for these sims. Since most is boilerplate, then likely the QA testing would be brief and the testers would gain familiarity quickly about what is expected.

So my question to you @jessegreenberg is, except for the Localization Tab phetsims/joist#930 , is everything on the Main branch (i.e. Master) already accessible for the Preferences menu?

Once we know that, we can see if we need to wait for the Localization Tab or publish Quad 1.1 without that, as that could part of a future maintenance release.

[jessegreenberg]

is everything on the Main branch (i.e. Master) already accessible for the Preferences menu

@terracoda for quadrilateral, yes.

[terracoda]

@brettfiedler, do you agree with going through QA for a 1.1 release? I figure we need to do screen reader testing on the changes to the Preferences menu, so that's why I think that is a good option.

It seems phetsims/joist#930 might get addressed soon, so we might not need to wait too long for that.

[brettfiedler]

We discussed and decided it might be cleanest to go 1.1. More QA time, but less dev time. QA queue seems light at the moment. Will vet out recent common code changes. We have a little bit of time before prime announcement time (which we need to finalize).

1. Need Add description to the Localization preferences tab. joist#930 complete - TS reviewing, one final dev task for JG, then review and close.
2. Dev-lite test (including screen reader on preferences menu only)
3. Respond to issues
4. RC testing
5. Publish 1.1

Timeline: Between 2-4 weeks

Other items:

• BF: Upload teacher tips when finished (minor task)

[jessegreenberg]

Quadrilateral 1.1 has been published to production with the features described in #443 (comment)! https://phet.colorado.edu/sims/html/quadrilateral/latest/quadrilateral_all.html