case study Mute Wars

	See page 704. Chapter 19 Groupware 19.7.2 Architectures for groupware We all spend so much time in video-conferencing software such as Zoom or Microsoft Teams, and yet still it happens ... You start to speak and the chair says "you're on mute" ... we have all been there! You try to click your unmute button, but it doesn't seem to work. You try again, and again, maybe sometimes you see it click momentarily to 'un-mute' state, but then back to muted. Eventually, apparently randomly, it works and you can speak The reason for this problem is that both you and the meeting chair are trying to unmute you at the same time. This could be a problem even if everything were working instantaneously, and arguably the visual and dynamic interaction design should take this into account. However, due to network latency and race conditions, the period for potential overlapping actions is increased: Mute Wars – timeline of events Sometimes as a designer you need to understand that underlying implementation mechanisms, in this case network delays, may have an impact on user experience. To reinforce this message, the inter-nal description of problem is used to suggest potential design solutions. This can happen even when there are no network delays, a user-level 'race conditions' when both you and the chair near simultaneously press the unmute button. The problem here is that the button will have changed between 'muted' and 'unmuted' visual states, but there is no time for the user to notice if they are in the process of clicking the button. Design Lesson: When it is possible that the target of a click or other user action is changing while they are in the process of acting, it is general good practice (but rarely observed) to temporarily freeze/lock the button or other action object for a few moments during the transition to prevent accidental actions: Temporary lock/freeze of button to reduce user-level race conditions This prevents nearly all user-level race conditions, but may not address network race conditions if the result of the chair's 'unmute' is still in transit when you reach to press the button yourself. This can be a particular problem if the network event is 'mute/unmute button pressed' or 'toggle mute state'. In such cases both ends may send 'toggle' messages that cancel each other out. Design Lesson: In general, race conditions can be reduced by sending a desired state message "become unmuted" rather than a 'toggle' change event: Send desired final state rather than toggle event to reduce network race conditions This case study is about race-condition and potential solutions, but also illustrates the more general importance of understanding the properties of networks at a non-technical level and being able to discuss both interface-level and underlying implementation-level interventions to improve user experience. Alan Dix © 2024