When the Windows Phone Back Button Doesn't Work
Thursday, 24 October 2013
Going up an app's hierarchy on Windows Phone can be inconsistent and sometimes impossible because of a dependency on a hardware back button. I'm regularly reminded of this when I'm listening to music and want to change to another song. Let's begin at the start.
I've no apps running.
I go to the Start screen and tap on Xbox Music's tile.
I tap on the top left tile in Xbox Music to start playing a song.
I go back to the Start screen by tapping on the phone's Start button.
Imaginary time passes. Time to change song. I press my phone's volume rocker to get the playback controls to slide down, and tap on the song title.
This is when things start to get confusing. I tap on the back button to check the other songs on the album.
When I do, I'm not presented with the album's tracklist, but I'm instead taken back to Start.1
Confused, I tap on the back button again. I'm now taken to Xbox Music. More confused.
I tap on the back button again but this time more in hope than expectation. I'm returned to the Start screen once more.
Tapping on the back button now doesn't take me anywhere. At this point, I decide to change my strategy: try again but this time without the back button. I slide down the playback controls and tap on the song title.
Back here. I tap on the artist/album title this time.
I'm presented with Apparat's discography. I've jumped two levels up in the app's navigation hierarchy. I wasn't expecting that.
If I tap on the album title, I'll see the album's tracklist. But if I want to browse other artists, I can't. There isn't a way up Xbox Music's navigation hierarchy from here. I'll need to go back to Start and start Xbox Music anew.2 This wouldn't happen on an iPhone because its apps are not designed to have any external dependencies. That is, irrespective of where in an iPhone app I am, I could reliably move backwards because their navigation is solely internal.
When Windows Phone 7 launched, the hardware search button worked contextually. When tapped, it would present either an in-app search or Bing web search depending on the app you were on. In Windows Phone 7.5 to avoid any confusion, this was changed so that it consistently sent you to Bing.3 As a result, developers had to present search as an option accessible from within their apps. What motivated this change can also be used to justify dropping the back button Windows Phone hardware requirement. If the back button doesn't always work, then it doesn't work. Total reliability should never be compromised for occasional convenience. At least one Windows Phone 8 app ironically developed by Microsoft themselves already acknowledges this.
Hopefully the rest of the platform will soon follow.
1. According to Microsoft's Peter Torr, this is correct behaviour. That is, "back means back" and must always return you to the previous page. This can be practical when multitasking but hinders in-app navigation.
2. This was one example. There are many others that I encounter regularly. Ironically, they're usually experienced when I interact with of one my favourite Windows Phone differentiators: secondary tiles on my Start screen that are deep links to apps. An app when entered from this context usually has restricted navigation. For example, when I tap on my weather app's pinned London weather secondary tile, I will need to return to the Start screen and tap on my weather app's primary tile if I decide I want to check the weather of another city as well.
3. I know some people didn't like this decision. However, I don't think their problem was how Microsoft made the search button behave consistently, but rather how Microsoft chose to prioritise Bing search.