search

phetsims / molarity

"Molarity" is an educational simulation in HTML5, by PhET Interactive Simulations.
http://phet.colorado.edu/en/simulation/molarity
GNU General Public License v3.0
2 stars 6 forks source link

How should the code figure out why the precipitate amount changed? #125

Closed jbphet closed 5 years ago

jbphet commented 5 years ago

Issue https://github.com/phetsims/molarity/issues/110 is about adding sound to the molarity sim. In the process of doing this, I came across a case where I needed to know not only that a property value had changed, but also some information about why it was changing. This came up when implementing sound generation for the precipitate level. In general, sound should be produced when the precipitate level changes, but there are some exceptions and variations. Specifically,

In https://github.com/phetsims/axon/issues/251, I proposed an idea and made a change where the value of the notifying flag for soluteProperty was checked when the precipitate amount changed to try to identify one of the conditions listed above, but I have since reverted that change based on feedback from other developers. I have implemented an alternative solution that will be committed against this ticket shortly, but I'm not particularly happy with that approach either because it involves passing specific UI components into the sound generators, so I'd like help for other developers in coming up with a good, extensible solution for a problem that is likely to come up a lot as sims are sonified.

By the way, this is a very general issue, and may need to be moved to another repo (e.g. sun or tambo) at some point.

terracoda commented 5 years ago

@jbphet, said

If the precipitate amount changes due to a change in the selected solute, sound should not be generated.

@jbphet, was this a decision made in the sound design meetings? I agree that this is a viable design option, but was wondering how things sounded if the precipitate sound was left in when a solute change caused a saturation change, from an unsaturated solution to a saturated solution.

The tinkle is quite pleasant and may be a good cue about saturation on a solute change (edited).

We will not be describing - "not saturated, no solids" in the new solute change alerts. We will only be describing the saturated state.

jbphet commented 5 years ago

@jbphet, was this a decision made in the sound design meetings?

Yes, and it is the behavior of the sound design prototype that is the basis for this implementation. Having said that, it isn't set in stone by any means yet, so if you think it would be an improvement to have the sound play on precipitate changes, please create an issue and assign it to @Ashton-Morris and @emily-phet. Personally, I prefer for the sound not to play in this case, else we end up with overlapping sounds, which tends to confuse our listeners.

terracoda commented 5 years ago

@jbphet, @emily-phet and I discussed this issue and I agree with the approach that the precipitate sound should not play on a solute change that causes a saturation change.

terracoda commented 5 years ago

@jbphet, is there anything else needed from me?

terracoda commented 5 years ago

@jbphet, FYI, there is something in the sim code that watches for changes to the precipitate to update descriptions of how much "solids" are present. Would this be relevant for this issue? We have a scale for describing the amount of solids and we announce when solids appear and disappear, and when the amount changes (e.g., "more solids" or "less solids) when the sliders are increased or decreased.

twant commented 5 years ago

@jbphet, just checking in In preparation for a11y publication to see what came of this issue. Sound design/implementation seems to be complete, but wanted to check with you -- is this ready to close?