Audio device settings - Use OS devices, remember devices, disable automatically switching, custom profiles, priorities
As a user of multiple VoIP applications it still surprises me how little configuration Microsoft Teams offers with regards to audio devices, user sound control and communication platform hierarchy.
I know that a few of my suggestions match with, or overlap with other suggestions on this platform, but I feel like these suggestions interact with each other in a way that warrants them to considered all at once.
My suggestions basically boil down to these two things that are further explained below.
1. Give the user more control over what audio (or video) devices are used where and when and when/if Teams automatically changes them when disconnecting or (re)connecting devices.
2. Give call participants more control over how they themselves experience a meeting, but less control by default over meetings in general (role-based permissions).
First, I have some suggestions on audio device configuration and voice call volume configuration including short descriptions what should be added/changed to the UI to accommodate this.
At the end, there are some general notes illustrating why I think these features are needed and hinting how to further prevent missing, incomplete or incorrect features like those described here.
- Audio device configuration:
1.1. Enable users to select "default OS device" or "default OS communications device" from the dropdown menu of audio devices.
UI: Extra list options
1.2. Enable users to disable automatic switching to a newly connected communications device. Or at least ask the user before doing so.
1.3. Automatically switching devices if the chosen device gets disconnected is good, but remember which device the user last selected and if that device is reconnected, switch back to it.
UI: Checkbox "Use this device if available" (can only be checked on one device at a time)
1.4. Temporarily changing your chosen devices when joining or in a call without affecting your "global" settings should be an option.
UI: Checkbox on the in-call device selection screen. (remember it for next calls)
1.5. Save sets of (audio) device settings as custom profiles. Currently, you can only choose for audio device profiles that Teams automatically generates for communication devices (mostly headsets) or change something and automatically switch to a "custom profile" which gets reset every time you switch off of it. The suggestion here is that you can save this "custom profile" under a custom name and that Teams remembers these settings even if you switch to a different profile or restart Teams. If you switch to a saved profile, of course Teams should check if the saved devices are currently connected.
UI: Extra list options and buttons/options to add, remove and rename custom profiles.
1.6. As an advanced setting, a device priority queue would be nice. Similar to the ordered list of WiFi networks which enables the user to configure which WiFi network they prefer to be connected to if multiple known networks are in range, this would enable users to prefer microphone A over B over C for instance. So if microphone A, B and C are all connected, Teams will always pick A. If A is disconnected, it will pick B etc. And newly connected microphones are added to the bottom of the list, naturally. Of course this feature should be optional to use and perhaps hidden under "advanced settings."
UI: Checkbox "show advanced settings". Checkbox(es) to use devices based on priority. Extra ordered list(s) of devices. Option to remove currently disconnected devices from the list.
- Muting and volume in calls:
2.1. Muting and unmuting during presentations.
There are some controls for presentations that the organizer or presenter can mute participants and they are not allowed to unmute themselves. I am not 100% sure if this is already the case, but if a participant is muted by the presenter/organizer, the participant should not be allowed to unmute himself, but the presenter/organizer should not be allowed to unmute them either. If the participant wishes to be unmuted, the organizer/presenter should get a request to unmute them (don't allow this request to be spammed). If the organizer/presenter wishes to unmute the participant, the participant should get a notification saying "<The organizer/presenter> has allowed you to speak. You can now unmute yourself." The last action before they become audible, should always be the participant unmuting themselves.
UI: Participant: hover over text on mute button: "The organizer/presenter has muted you; Do you want to send a request to speak?"
UI: Organizer/presenter: Give participants that have been muted by organizer/presenter a different mute icon. Perhaps with a differently colored line through the microphone or color the microphone red as well as the line and only color the line red for users that have only muted themselves.
2.2. Client-sided volume controls. Enable the user to choose at what volume he hears other participants in the same call. This way the user can increase the volume of participants he can barely hear and decrease the volume of participants that are too loud (or even mute them). This should not impact the experience of the other participants at all though. These controls should be purely client-sided. Also, the volume adjustment should be remembered between meetings, probably on a per-contact basis. I am sure that each Teams contact has some (public) unique token. This could probably be used.
Perhaps the user whose volume has been adjusted should be able to see who (client-sided) adjusted his volume or muted him as well, just for transparency.
UI: A per-participant volume slider including a mute button. An extra button next to your own mute button for an information menu telling you which other participants adjusted your volume and if they increased or decreased it. (Grayed out if there are no adjustments, otherwise orange?)
2.3. Never allow "any user" to globally mute other participants. That was an incorrect interpretation of this suggestion:
Such "permissions" are generally reserved for admins or moderators of communication platforms and as such should only be available to participants that are explicitly given these permissions.
Look at similar software solutions and predecessors (like Skype) to see what basic functionality they have an provide at least that. (See 1.1.)
Don't automatically make decisions on behalf of the user without at least enabling the user to disable them. (See 1.2.)
Remember the choices that the user has explicitly configured, even if they are not applicable in the current situation, so that these can be used again once they become applicable. (See 1.3.)
Have separate layers of configuration. Your global/preferred settings need not necessarily match those that are used in a particular instance. (See 1.4.)
Users may disconnect used peripheral devices for any reason and reconnect them only when they wish to use them again. (See 1.5.)
Users may not always have access to the devices they prefer, and when they do not have access to these specific devices, they may have a distinct next-best preference. (See 1.6.)
Don't give admins full control of every user's system. (See 2.1.)
Users should be able to configure their own experience. (See 2.2.)
Don't give admin rights to every user. (See 2.3.)