Mobile app audio player state design

August 30, 2015/ Wes Byers / Uncategorized / 0 comments

The challenge with a paper-based design is that, although the player control is shown correctly, we have taken a snapshot of that player’s state at one particular time. Let’s look at that again:

Audio player showing the track title and description as well as the pause button, equalizer icon, and player control

If you haven’t yet seen the Design choices to consider for a mobile app audio player that have influenced these player state designs, consider taking a look there first.

Player states

The player is currently playing a track and is somewhere in the middle of playback. In the app, there will be many different states that the player will go through as the user interacts with it and the player feeds back information about the track as it is playing.

Interacting with the player control has two possible categories of outcomes:

1. Display-based outcomes: The user’s action changes the audio control’s display (such as expanding or collapsing the view, or that the play button changes to a pause button)
2. Audio-based outcomes: The user’s action results in a change in the playback of the audio (start, pause, fast-forward)

Interacting with the audio control could generate outcomes that fall into one or both of the above categories. Now, have a look at all of the possible display-based outcomes collected into the various states that the player would then be in at any one time:

The five player states that were possible, showing the visual treatment of each element in each state.

In addition to the display states, let’s review the state diagram for the interaction. (Click the image below to view full size.)

Audio Player State Diagram

Silent (Collapsed):

• Tapping anywhere on the control transitions the control to Expanded.

Expanded:

• Tapping the text of the control would move the control to the Silent (Collapsed) state.
• Tapping the Play button moves the control to the BeginPlay state.
  • Note, no audio-based outcomes at this point – except that the control will programmatically queue this audio stream to start playing

BeginPlay:

• Tapping the text of the control would move the control to the Silent (Collapsed) state.
  • Audio-based outcome: cancels the audio playback of this track
• Tapping the Pause button moves the control to the Expanded state.
  • Audio-based outcome: cancels the audio playback of this track

ExpandedPlay:

• This state is entered programmatically, when the audio stream that is trying to be played, is ready to play (as opposed to some user interaction).
  • Audio-based outcome: The track’s audio begins playing.
• Tapping the Pause button moves the control to the Expanded state.
  • Audio-based outcome: pauses the audio playback of this track and retains the user’s current position in the track.
• Tapping the text moves the control to the CollapsedPlay state.

CollapsedPlay:

• Tapping the control anywhere would transition the player to the ExpandedPlay state.

The transition from Expanded to BeginPlay to ExpandedPlay could take a long time (in the case of a bad connection). In some cases, over a high-speed connection, the ExpandedPlay state may not even be visible to the user because it happens so fast.

This is the second article in a multi-part series. Previous: Design choices to consider for a mobile app audio player. Next: Implementing the audio player for Android.