-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Naming for sound features #143
Comments
+1 for using "Sounds" because it stands on its own. I think "Other Sounds" could be confusing in cases where Voicing is not available and "Other Sounds" is the only item in the "Audio" tab. Also, if we go with "Sounds" maybe we can keep "Enhanced Sounds", which accurately describes it without the drawbacks of "Extra" @jbphet mentioned. Assigning to @terracoda for next steps, but feel free to reassign to others if you want more feedback/discussion here. |
We need to think of all the pieces that make up the whole. It is really good that @jessegreenberg pointed out "Other Sounds" could be used on its own. I see how "Other Sounds" is problematic when "Voicing" is not present. From interviews, people did associate "Voicing" as a sound, and nobody understood "Sonification" in "Sound an Sonification". Also, in interviews people did not understand "Enhanced Sound". They thought it it meant higher quality sound. That said, nobody had access to the additional phrase descriptions that are now associated with the higher-level name of the feature/item. I think these descriptions add a lot of information. There has been a lot of iteration on the content for the Preferences Menu. I am linking in the Preferences Menu Design Doc. We might not come up with the perfect terms/words for Version 1 of the Preferences Menu. We might have to change them, and we are in fact already planning that there will be a Version 2. We need words we can use for John Travoltage, Gravity Force Lab: Basics, and Friction. These three sims will all have Voicing and Sonification. I agree we need to change "Other Sounds". But for "Extra Sounds" the description contains the word "additional", so I think that one, in context, is already fully defined. I also feel the sounds are kind of "extra sounds". A learner can use the sim with or without them and have a full sim experience. Each switch or checkbox in the Preferences Menu also has a response confirming the change. We can adjust those words, too, as needed. The full context is the feature/item name, its associated visible description, AND its associated responses upon toggling the feature/item on and off. I agree let's change "Other Sounds" to "Sounds" - this feature is controlled by an on/off switch. Sounds
To clarify that Sounds are not Voicing, we could use the response string to communicate that detail. For example, the responses could be changed to:
Personally, I think the the associated description for "Sounds" can remain the same:
I suggest we leave "Extra Sounds" which is a checkbox as-is, OR we just swap the usage of "extra" and "additional" in the label and in the description if people like that better. Here are the words laid out for each. Extra Sounds
Responses when toggled are:
OR Additional Sounds
Responses when toggled are:
Personally, I like "Extra Sounds" as the label for the checkbox. |
@terracoda - You've assigned this to me, but unfortunately I'm a little unclear as to what I need to do to move it along. Did you want me (and @Ashton-Morris) to opine on what you've written in the previous comment? |
@jbphet, yes please, opine! Specifically, in addition to the name change do you want to change the Sounds toggle responses to include "Non-speech"? I wanted you both to see the other content that supports the names to help you more with your opinion/decision. |
I also agree that Other Sounds can be changed to Sounds and I also prefer: |
I'd say that I prefer "Sounds" over "Other Sounds". I prefer "Additional Sounds" over "Extra Sounds". I also don't think that it's bad to use the label in the supporting text. So, for instance, I think it would be okay to label the checkbox with "Additional Sounds" and have the text say "Enable one or more additional sounds that may be useful for some learners". Having said these things, I should say that I'll support whatever is decided upon, because I know that the buck has to stop somewhere, and that person has to make the final call. On another note, in one of the comments above @terracoda said:
Please keep in mind that changing strings after publication means that translations of that string are no longer valid and will disappear from the sim. That doesn't mean we can't do it, but we need to consider this and not make such changes lightly. We currently have no mechanism in place to notify our translators that a sim that was previously fully translated has changed such that it now has some untranslated strings. |
@jbphet, you make a good point about translation. We are planning on doing a teacher survey to evaluate the Preferences Menu further. Is it possible to not allow translation on version 1? |
Hmm, given @jbphet's concern about translation, it might be beneficial for future translations to include both words, "Additional" and "extra" in our first release. If wording gets changed down the road, both words are already available in any translations that might have to be updated. Lets try the following: Additional Sounds
Responses when toggled:
If, "Additional" sounds funny due to strange screen readers pronunciation, let's leave the main title/label the same, but switch the responses to "Extra sounds on." and "Extra sounds off." Hopefully, "Additional" will sounds nice, but sometimes screen readers have trouble with getting the stress right on 3-syllable words. Assigning to @jessegreenberg for implementation. |
The Voicing Preferences Design doc has been updated, to include decisions above. |
Not really. The only things we prevent from being translated are a11y-specific strings. Everything else if fair game, and we'd have to add specific code to prevent this, which wouldn't be trivial. Can we do the teacher survey with dev or RC versions instead of fully published versions? |
Remind me the timeline for this? I could probably get the survey out next week with a Dev/RC version, collect a weeks worth of info, do a quick analysis/report out the week of the 17th? Does that delay too much? |
Voicing is still in its first dev test @BLFiedler, so I believe would have time for that before first publication and it wouldn't cause further delay. |
@jbphet, ok good to know, that "going live" means "getting translated"! This is all very exciting! @BLFiedler, I was assuming that the survey you are working on is about the Preferences Menu. In the Rocks spreadsheet, the survey is spanning end of May an June. And @jessegreenberg just commented above. |
Survey should go wherever it does the most good :) If that's pre-preferences publication, then it should be before that goes live. I'll chat with EM about it today, ping @jessegreenberg about a dev version that makes sense if necessary, and then chat with y'all about it Friday at the meetings. |
Two surveys have gone out. We'll have some data soon to see if we need to make any changes to the names of the sound features. |
The survey does not touch specifically on the wording of the preferences menu, but we can look at the comments to see how folks talk about the 'sounds' in comparison to the 'voicing' to see if anything sensible emerges. The comments from survey 1 & 2 are found here: https://docs.google.com/spreadsheets/d/117tjIISMwKLAwqPGqQhfuynXivbjnIlKiMeKlnYHezM/edit?usp=sharing Edit: I should mention that in both surveys, the ratings for the preferences menu were very positive (3 being a neutral score) for positive statements and expectedly negative for negative statements: |
Checking in on this issue - I am wrapping up updating the Teacher Tips with the latest A11y info for interactive description and updating Enhanced Sound to Extra Sound where appropriate. One issue we run into is that not every simulation that has an "Extra Sound" has a Preferences menu with the new vocab (Ratio and Proportion, Gravity Force Lab (regular), and Friction). I am not sure of the timeline for updates to these simulations. Should the Teacher Tips update hold off until they receive a Preferences menu update? If so, this issue may need to remain open and be updated when one of these simulations is updated so the PD materials can also be updated. This includes updates to the Sound Features videos. Tagging @jbphet and @zepumph as knowledgable folk and/or responsible for above sims. |
@BLFiedler said:
I am currently not aware of any efforts to go back through existing published sims and proactively add the preferences menu. @jessegreenberg may be in a better position to let us know whether there is such an effort. If not, then it doesn't seem to me like the Teacher Tips should be delayed. |
There is no plan currently to republish these sims for this. RaP and Friction may be republished sometime this year for other goals. |
Okay - well I'm not sure if we are set enough on this issue to close it, but I've updated the teacher tips and left the Enhanced Sound language for those sims without a preferences menu (listed in my last comment) |
What if you have
|
Just in the older ones, then that might buy you some time on updating them when and if they get updated. |
Moved this to phetsims/friction#309 The update to the sound features and teacher tips should be standard practice for republication. I am not sure this needs to be explicitly indicated for the remaining sims, but if there is some task assignment for "Create or Update Teacher Tips" on a publication checklist then that is probably sufficient for whoever is assigned to that. If we have that done, I think this issue can be closed. |
This came from a discussion on slack discussing how we want to name and describe the sound features that can be enabled/disabled from the Preferences dialog. Taking excerpts from the thread related to this issue:
@terracoda said
@Ashton-Morris said
@BLFiedler said
@terracoda said
@BLFiedler said
@terracoda said
@jessegreenberg said
@jbphet said
The text was updated successfully, but these errors were encountered: