Preferences Menu - Sound Design Section

[terracoda]

Related to #248, Cleaning up the Preferences Dialog, we need Voicing Design a for both the "Sound Design" section under Sounds in the Audio tab, and "Fine Input Spacing" under the Simulation tab.

I'll create 2 issues, this one is for the section "Sound Design" which currently has 2 radio buttons and a checkbox.
Iteration 1
I sketched out a voicing design for iteration 1 in the design document

I suggest we discuss Iteration 2.

Iteration 2
Section heading for radio buttons and checkbox:

• I suggest "Shape Sound Options" instead of "Sound Design".

Help text options for radio buttons:

• Choose how sound design represents different shapes as you interact.
• Choose the sound design you hear as you create different shapes.

Help text options for BOTH radio buttons AND checkbox:

• Choose how sound design plays and represents different shapes as you interact.
• Choose the sound design you hear as you create different shapes.

Names for radio buttons:

• Layer sounds that emphasize shape properties.
• Play sounds that emphasize different shapes.

Context responses for radio buttons:

• Shape sounds increase and decrease with shape properties.
• Shape sounds different for each shape.

The checkbox for "Tracks play forever" is trickier.

• Name for the checkbox:
  • Play Shape Sounds forever when checked in sim.
    • Context responses for checkbox:
      • When checked: Playing shape sounds forever.
      • When unchecked: Fading out shapes sounds.

I also considered a Shape Sound Duration (AB switch), but we do not have a design pattern for an A-B switch. It might be easy, but I have not thought about that aspect of an A-B switch. It might work as a toggle button with 2 names under the hood, not sure.

• Shape Sounds fade out. <--> Shape Sounds play forever.
  • Context responses for checkbox:
    • When toggled right: Playing shape sounds forever when checked in sim.
    • When toggled left: Fading out shapes sounds when checked in sim.

[brettfiedler]

Sounds great. Let's largely plan on implementing your Iteration 2, but let's chat about it briefly in Description meeting this week so I understand where each of those suggestions go and to refine our language around each sound design.

[brettfiedler]

@terracoda , what about something like this for the visuals?

[terracoda]

Yep that looks good and maybe the following Context Responses when things are toggled on and off:

Context responses for radio buttons (we might not need these responses):

• Shape sounds increase and decrease with shape changes.
• Shape sounds different for each shape.

Context responses for checkbox:

• When checked: Playing shape sounds forever.
• When unchecked: Playing shapes sounds during active transformations.

[terracoda]

@BLFiedler, is this issue ready for @jessegreenberg (or you) for implementation?

[jessegreenberg]

I feel like the placeholder text will be a distraction for the QA team so I am going to do this quickly now.

[jessegreenberg]

This was done. @BLFiedler @terracoda can you please review the new visual text and layout?

@terracoda can you please review the Voicing for this content? I wasn't sure how to do the radio buttons, have we done Voicing for radio buttons before? If so, can you point me to an example? If not, when would you like name/object/context/hint responses be triggered from various input?

[terracoda]

• (ignore this one) In first radio button, "(default)" doesn't sound right. I suggest changing "(default)" to "(recommended)", if that design is the preferred use case.
• Remove "the" in "Choose the sound design you hear as you create different shapes."

Name Responses and Context Responses for radio buttons...

• Would shorter names work better?
  • Name Response: Layered shape sounds (recommended)
    • Upon selection/activation name & context response: Layered shape sounds (recommended), Emphasizing shared shape qualities.
  • Name Response: Unique shape sounds.
    • Upon selection/activation name & context response: Unique shape sounds, Emphasizing each shape.

@BLFiedler. Maybe we may only need a Name Response for these radio buttons? The text on the screen can just identify the selected design. Radio buttons are activated on focus/click. Do you think of these names accurately communicate the selected sound design?:

• Layered sounds emphasize shared shape qualities (recommended).
• Unique sound combinations identify each shape.

The Play Forever check box...

• We need permanent context responses for checkboxes. This approach could evolve if there are general changes to how options are turned off and on in the Preferences menu.

Checkbox design:

• Name response: Play sounds forever when checked in sim.
• When checked: Playing sounds forever.
• When unchecked: Sounds fade with pauses in interaction.

Over to you @BLFiedler for some thoughts on polishing the visual text and the responses.

[terracoda]

@jessegreenberg, also to note, the radio buttons in RaP have context responses, but their actual name responses are very short. Let's see if these Preferences radio buttons will sound ok with only name responses.

[jessegreenberg]

These changes were made in the above commits. @terracoda can you please review? A couple of questions, which we started to discuss over slack.

1. Should "Shape Sound Options" be a reading block? Other headings in preferences are not, but they only have 1 item below them. In those cases, the reading block content for the heading is put in some text below it. The reasoning for this was to reduce the number of items in the traversal order. But that might not work as well for "Shape Sound Options" because there is more than one control below the heading.
2. The default Voicing pattern for checkbox is to speak the name response + context response upon selection. Is the default behavior what you intended in this case or does the name response need to be suppressed?

[terracoda]

Great Questions Jesse.

Re Q2 - default voicing pattern for checkboxes
The checkboxes in the Preferences Menu are atypical. They do not follow the common-code pattern. Where do I document this? This question has come up before. Mouse users cannot get the name response for the Preferences Menu's checkboxes (which tend to have long names) because they toggle the checkbox when they click on it. They will only get the context response that matches the checked state. Keyboard users get the name response on focus, and the context response upon toggling - the name response is suppressed on toggle (i.e., not repeated).

Re Q1 - I think we need a change that simplifies things

Using an on-off switch for "Play shape sounds forever" would make this entire UI way simpler.

Also, I am thinking people would more more likely to want to play sounds forever before potentially changing the sound design. I am going to propose something different and simpler.

With this design, "Shape Sound Options" can follow the Preferences Menu reading-block pattern.

And the context responses for the on-off switch would be:

• Play shape sounds forever on. (when toggled on)
• Play shape sounds forever off. (when toggled)

We can leave it to the leaner to figure out that Shape Sounds has to be checked in the sim for this to take effect.

[terracoda]

And the sound options should be indented for consistency.

[brettfiedler]

I'm good with the changes proposed by @terracoda!

[jessegreenberg]

They do not follow the common-code pattern. Where do I document this?

Sorry, I am not sure. I really like this proposed design though! It was done in the above commits. Can you please review?

[terracoda]

Seems like this is working nicely.

[jessegreenberg]

Great, thanks! @terracoda will continue to review but this is no longer blocking test.

[terracoda]

I found a navigation glitch with the Shape Sound Options radio buttons. The sim crashed.
I'll open a separate issue. This issue is just wrapping up the voicing design and visual design.

I have to re-load to check on those :-)

[terracoda]

The voicing is working great, and so is everything else. I needed to clear my cache.