Music Player Hotkey Behavior Changed

TL;DR: The behavior of the music player hotkey changed in the 6.70 firmware release for the fr645m (and, I think, other button-based watches).

The old behavior always launched the music Player Main View.

The new behavior launches the Player Main View or the ConfigurePlayback view depending on state. While this is probably fine in the music-listening case, it notably worsens the podcast listening experience.

Terms

To communicate the details of what changed and why it impacts the UX, it's probably best to define terms up front. I don't know what the Garmin internal terminology is for these things, so here are the terms that I use:

Music Player Hotkey: This is the button that opens up the music player from any place in the watch. It's accessed by a long press on the DOWN button

Player Main View: This is the view that shows the episode metadata, cover art, and the PLAY button. It also shows the the '...' button which accesses the...

Player Secondary View: This holds additional controls, like volume, and importantly the cog button used to access the ConfigureSync view

Active Playback Mode: This represents an app lifecycle state where the user has used the player recently and the player remains resident in memory, ready to be resumed exactly where they left off. If a user has not used the player in a while, then after a while, a timeout occurs and the player is placed into ...

Inactive Playback Mode: This represents an app lifecycle state where the user has not used the player recently. When the player is subsequently re-opened, its state will need to be re-materialized from disk. One way to determine whether this state was reached is whether the headphones need to be reconnected upon playback.

Old Behavior

The pre-6.70 behavior was dead simple: when the music presses the Music Player Hotkey, the watch would open up the Player Main View, no matter what. From there, the user could press "Play" to resume an episode, or they could click on the app-icon to open up the ConfigurePlayback view.

They could also click the '...' icon to open up the Player Secondary View, and, from there click the cog icon, open up the ConfigureSync view.

What's important to note is that, from a UX perspective, this behaviors makes each of the crucial actions (initiating playback, re-configuring playback, syncing new content), easily accessible in a "forward direction". There is no need to click BACK, there is no need to initiate a 'dummy' playback to trick the app to being in a state to reach a menu (I'll explain later...), etc.

New Behavior

The new behavior makes the Music Player Hotkey action dependent on the Playback Mode of the player:

If the player is in Active Playback Mode (e.g. content was recently played and the player is still resident in memory), then the hotkey will open the Player Main View.

If content hasn't been played recently and the music player has been 'swapped to disk', so to speak and thus entered Inactive Playback Mode, then the hot key will open up the ConfigurePlayback view.

Consequences of the New Behavior

ConfigureSync view is no longer easily accessible.

The ConfigureSync view  is important as it's the main way a user manually syncs content to their watch. The UI flow on button-based watches is Player Main View > '...' ellipsis button > Player Secondary View > cog-icon > Configure Sync.

If a user hasn't played content recently, e.g. in Inactive Playback Mode,  the music player hotkey will open up the ConfigurePlayback view. Pressing the BACK button will not return to the Player Main View, but instead will return to the previous application, or watch face. This means the user cannot access ConfigureSync to sync new content to their watch.

A workaround, as mentioned above, is to perform a dummy playback, just pick a random piece of content, press play. This places the player into Active Playback Mode, which then allows the user to access the Player Main View, and then can access ConfigureSync.

But what happens when the user doesn't have any content to play yet (e.g. first use experience)? Even the 'dummy playback' workaround won't work here.

A user can no longer just press the 'Play' button to resume a previously played a piece of content, instead they get forced into the 'heavyweight' ConfigurePlayback View.

If a user has recently listened to something, then there is no issue here. But suppose a user listens to a piece of content, say a podcast episode and gets half way through, then goes to bed. When they resume the next morning and try to pick up where they left off, instead of the Music Player Hotkey pulling up the Player Main View where they can press PLAY and be off, instead, because the player has entered Inactive Playback Mode, they will be redirected into ConfigurePlayback view.

As the app wasn't designed for this UI flow, this 'heavyweight' view, will be extremely confusing. But more importantly, even optimizations to ConfigurePlayback view, will only be band-aids on the problem. What the user wants is the Player Main View so they can Just Press Play (tm) and be off.

Wild Speculation

I'm not sure why the behavior change was made, but I'm sure there was a good reason for it. My guess is, however, that the main design use-case for Garmin watches is music not podcasts. This is relevant, because unlike podcasts, music is often short (a few minutes), and upon entering Inactive Playback Mode, giving the user a menu to select another track could be considered a feature not a bug since they likely don't want to listen to the second-half of "Stairway" if they were listening to it the previous day (those people will be missing a kick-butt solo though!).

The podcast case, however, is quite different. Content is long, measured in hours, and resuming in the middle of paused playback, even after a long time away, is completely normal. In other words, even in Inactive Playback Mode, a user is going to want to be redirected to the Player Main View to pick up where they left off.

Suggestions

The easiest suggestion is to revert to the previous behavior :-) However, I'm sure there were good reasons for other apps, particularly music apps, to inherit this change.

An alternative, would be to allow player apps to declare what kind of behavior would be most appropriate for the Music Player Hotkey. This could occur at different levels of granularity.

The simplest would be an application-level configuration, perhaps part of the PlaybackProfile model, that declares that the content should be easily resumable and therefore the Music Player should always open up the Player Main View: Something like PlaybackProfile.isContentResumable().

If app-wide isn't fine-grained enough, perhaps, each piece of Content can declare itself resumable or not, and this state can be persisted to effect how the Music Player Hotkey decides which view to open.

For example, Content/ActiveContent could have isResumable() added as an overridable method. If it returns true, similar to above, that state is preserved somewhere so that the Music Player Hotkey handler code can decide to open up the Player Main View instead of the ConfigurePlayback view.

Conclusion

Hope this report made sense, if not, please let me know, happy to chat about this more.  I'm excited to give podcast listeners the best possible experience on Garmin devices and I think part of that resides in getting this key element right.