OPENTOK-44484: replaced 'mute on entry' and 'disable mute on entry' buttons with a single toggle button

[cpettet]

What is this PR doing?

This PR is replacing the 'Mute on Entry' and 'Disable Mute on Entry' buttons with a single 'Toggle Mute on Entry' button that combines their functionality.

How should this be manually tested?

• run the app
• toggle mute on entry button
• toggle mute on self/publisher
• open new browser tab
• confirm functionality is correct
• toggle mute on entry button
• open another new browser tab
• confirm functionality is correct

What are the relevant tickets?

OPENTOK-44484

[austinwu13]

LGTM!

[maikthomas]

Just a small change in the error handling.
Also @v-kpheng isn't the wording on this kinda misleading?
Doesn't toggling 'mute on entry' mute everyone else already in the call here?

[v-kpheng]

Just a small change in the error handling. Also @v-kpheng isn't the wording on this kinda misleading? Doesn't toggling 'mute on entry' mute everyone else already in the call here?

@maikthomas, MuteOnEntry comes from the spec. The side effect of toggling depends on its state.

[maikthomas]

@v-kpheng Yea spec wise I see where this comes from, it's just UX wise we have a button that says 'Mute on Entry' that suddenly mutes everyone in the call 🤷

[v-kpheng]

@v-kpheng Yea spec wise I see where this comes from, it's just UX wise we have a button that says 'Mute on Entry' that suddenly mutes everyone in the call 🤷

Please feel free to suggest a different approach :-)
Would renaming the buttons to "Session-level mute" be sufficient? Or, is more needed? Also, meet has a host of UX issues already.

[maikthomas]

In terms of UI, given the way this works my personal preference would be

• 1st button state: "Force mute all"
• 2nd button state: "Disable mute on entry"
  Is this strange? yes, but so is the functionality underneath, we're basically doing two separate things with one method 🤷‍♂️

Another unrelated question:
What about the UI for other participants? We probably need to listen to the muteAll events and update UI for all participants.

[v-kpheng]

In terms of UI, given the way this works my personal preference would be

• 1st button state: "Force mute all"
• 2nd button state: "Disable force on entry"
  Is this strange? yes, but so is the functionality underneath, we're basically doing two separate things with one method 🤷‍♂️

Another unrelated question: What about the UI for other participants? We probably need to listen to the muteAll events and update UI for all participants.

Hmmm...looks like we need a holistic approach. @cpettet, @austinwu13, can you guys sync up w/ @maikthomas. Let's come up with a more complete DoD please. The one I suggested isn't sufficient. Sorry.

Once you guys have consensus on changes needed, then let's implement that please. Thanks!

[maikthomas]

Sounds good to me, I think my previous answer is incomplete, better to meet and discuss 👍