This is going to be a long one.
Recently some users have brought up an annoyance where videos are always muted in the app. This is annoying UX because sometimes you want sound and you don't want to have to manually unmute each and every video if you are watching a lot of them.
However this problem is more annoying to fix than it first seems.
To make this discussion easier I am going to group videos in the app into only two categories: inline (eg. in the post feed or in the post screen) and full screen.
Examples
Let's start with two examples of users and go from there (these are imaginary examples).
Let's start with Alice:
- Alice is browsing a post feed containing a lot of videos.
- The post feed shows all of the videos inline. They are all muted by default by the app.
- Alice sees a video they are interested in. They taps the video to expand it.
- Alice taps the unmute button to unmute the video.
- Once Alice is done with the video they go back to the post feed and see another video they are interested in.
- They tap the video to expand the video to full screen.
What should the volume of the video be in full screen?
I think in this example the best UX is that the video should play unmuted because Alice had previously chosen to play full screen videos unmuted. It is very likely that Alice intends to watch the 2nd video with sound on as well.
Let's now move on to another example with Bob:
- Bob is browsing a post feed with mostly non-videos but there is occasionally one.
- Bob stumbles upon a video inline.
- Bob unmutes the video in the inline player to listen to it.
- Bob then expands the video to full screen.
What should the volume of the video be in full screen?
I think in this example the best UX is that the video should be played unmuted. This is because Bob had decided to unmute the video inline so it's very likely they intent to listen to the video at the same volume full screen as well.
Learnings from the examples
These two examples show behavior that might be desirable:
- The full screen video player should probably manage it's own state separately from the inline player. In the example with Alice although all videos are muted inline, it's very likely Alice intends for the full screen player to remember their settings from another full screen playback.
- When a video goes from inline to full screen, some state should probably transfer from inline to full screen. This is illustrated in the Bob example.
The issue is these two things can be contradictory.
More examples
Here is a tricky example with Charlie:
- Charlie taps on a post to view it.
- Charlie sees a video in the post and plays it inline.
- Charlie unmutes the video.
- Charlie realizes the audio is annoying overlaid music.
- Charlie mutes the video.
- Charlie expands the video full screen.
What should the volume of the video be in full screen?
I think in this example the best UX is that the video should be played muted. Charlie has expressed the intent of playing the video muted explicitly so it's pretty obvious they would like the video muted regardless of inline or full screen.
Final learnings
There are simply way too many edge cases to consider but from these three examples there is a commonality. It is that the full screen video player should always operate using explicit intent from the user as a hint. In other words the app should offer sane defaults but if the user ever explicitly changes a setting with the video, that information should be used to figure out what to do when the video is played full screen.
In the example with Alice, Alice plays the videos inline without expressing any explicit intent. In this case, the full screen video player should not assume any intent and behave "like normal". That is the full screen video player should save and restore settings from a previous session. It results in the 2nd full screen video being played with sound.
In the example with Bob, Bob plays the video inline but then expressed an explicit intent to play it with sound. When Bob expands the video full screen, this intent should be passed to the full screen player. In this case the full screen player should override the default sound setting from a previous state and instead use the same volume as the inline player.
In the example with Charlie, Charlie plays the video first muted (but not by explicit intent) then with sound and then muted again (but with explicit intent). In this case when Charlie expands the video, the intent to play the video muted should be passed to the full screen player. The player should also override the volume and play the video muted.
One last example
Here is one last example as something to thing about with Dave:
- Dave watched some videos a few days ago full screen.
- Today Dave seens a video link in their post feed.
- Dave taps the link and the video opens full screen.
What should the volume of the video be in full screen?
This one is probably the most open ended one. There are two obvious answers here. (1) the video volume should be the same as from a few days ago. (2) the video volume should be some sane default that Dave could configure.
Conclusion
This was actually a pretty challenging problem to solve just because there are so many edge cases. I will implement the solution detailed in the Final learnings section. However I do realize my answers to each of the examples may not be "correct" or certain answers can be debated or controversial. If anyone has any thoughts please let me know in the comments.
I am sorry to do this to you but I think your suggestion is actually out of scope for the changes proposed here. This post is mainly about how to handle when users explicitly change things out of sane defaults. To change the defaults themselves is another topic, although a much easier to solve problem.
I'll add your request to the roadmap though.
No no. Don't be sorry at all.
You are an amazing developer and been super active here. We greatly appreciate it all.
And thanks for adding it to the roadmap. I wouldn't ask for anymore.
You have been very helpful.