Different nav apps solve this UX design question in different ways. Some resolutions seem obvious. Some are clever. Some are so bad, it's hard to believe they made it into production.
The stakes can be high. If two apps want to use the audio system at the same time, typically only one will succeed. If it's the nav app, you might miss an AMBER Alert on the radio while you're next to a car matching the description of one with a kidnapped child. If it's not the nav app, you might miss a freeway exit and have to drive many miles before the next one.
I compared the resolution of audio conflicts for Google Maps and Apple Maps under iOS 16.6 CarPlay on a 2019 Nissan Rogue. I don't know whether what I found is representative of other nav apps, other cars, or other phone-car interface systems (e.g., Android Auto).
The scenarios I checked were what happens when your nav app wants to speak and:
- A streaming app is playing.
- The car radio is playing.
- A phone call is in progress.
- You're talking to your phone.
- Your phone is talking to you, e.g., Siri is responding to a query or command.
This is what I found.
Nav App vs. Streaming App
The streaming apps I tested (Pandora and Simple Radio) can be paused, which is characteristic of every streaming app I'm familiar with. It seems obvious to me that the proper behavior when a nav app wants to talk is to pause the streaming app, have the nav app talk, then resume the streaming app. Google sort of agrees, because that's what Google Maps does when the streaming app is Pandora. However, when the streaming app is Simple Radio, Google mutes it instead of pausing it. I don't know the reason for this difference.
Apple would probably argue that I'm mischaracterizing what it does. Apple Maps employs audio ducking, whereby the volume of the streaming app is reduced when Apple Maps speaks. In concept, that's not unreasonable, but in my experiments, the ducking effect kicks in only when the volume of the streaming app crosses a loudness threshold. This threshold is far above my usual listening level. I had to go out of my way to elicit the ducking effect. When I did, I found that the volume of the ducked audio was still high enough to compete with Apple Maps' spoken directives.
To summarize:
- Google Maps: Pause stream, speak, resume stream.
- Apple Maps: Speak while stream plays. At high stream volumes, duck stream while speaking.
I think Apple's approach shows promise, but its implementation needs considerable refinement. For me, both the threshold and ducked volumes are too high. I wish I could configure them. With that said, comments on the Internet make clear that many people listening to spoken audio (e.g., podcasts) would prefer pausing over ducking, anyway.
Nav App vs. Car Radio
Radio is a different kind of streaming beast, because it's not pausable. That requires that Google change its approach to audio conflicts. Not so for Apple, which sticks to its guns and issues navigation instructions on top of whatever's playing on the radio. If you happen to be listening to a talk show or the play-by-play of a sporting event, you've again got dueling voices, and there's a good chance you'll understand neither. I'm generally a fan of UX consistency, but Apple's here is of Emerson's foolish variety.
Google's approach--to mute the radio while Google Maps speaks--is a lot more reasonable. There's a tiny chance you'll miss something important (e.g., an AMBER Alert), but it's more likely you'll just miss a snippet of a song, commercial, or host's blather.
We thus have:
- Google Maps: Mute radio, speak, un-mute radio.
- Apple Maps: Speak while radio plays. At high radio volumes, duck radio while speaking.
Nav App vs. Phone Call
While you're on the phone. Google is polite enough not to wrest control of your car's speakers from the person you're talking to, but it has no Plan B. If you don't notice the visual navigational directive on the CarPlay screen, you're out of luck: Google Maps remains silent if you're in a phone call.
Apple doesn't need a Plan B, because its Plan A is so good. When Apple Maps wants to speak, but you're on the phone, it issues a chime--a subtle indication that it'd like to tell you something, but it can't. It's your cue to look at the CarPlay screen to see what you need to do. I find it works well.
So:
- Google Maps: Don't speak or make any other sound.
- Apple Maps: Don't speak, but issue a chime.
What I admire about Apple's approach is that it takes advantage of the fact that you have a screen; CarPlay requires it. A chime is enough to tell you to look at it, but it's not so intrusive that it interrupts the flow of a conversation. Well done, Apple!
Nav App vs. Dictation
If a nav app wants to speak while you're talking to your phone (e.g., issuing a command to Siri or dictating a text message), the audio conflict is between you and your nav app. Google Maps bursts in like an excited child who, unable to restrain itself, says its piece without regard for the fact that you're already talking. It's rude, not to mention a sure-fire mechanism for derailing your train of thought.
Google Maps' interruption also aborts whatever you're dictating, e.g., the command you're issuing or the text you're dictating. This means you have to start over after the excited child has said its piece (and hope that it produces no further audio interruptions before you're finished).
Apple Maps' chime strategy would work well here, but Apple inexplicably adopts Google's speak-no-evil policy and remains silent. If you're dictating and Apple Maps wants to tell you something, the only way you'll know is by looking at the CarPlay screen. It's a bitter pill to swallow after the cleverness of Apple's phone call conflict resolution.
This is a case where both nav apps offer disappointing and frustrating behavior:
- Google Maps: Interrupt and abort dictation, speak.
- Apple Maps: Don't speak or make any other sound.
Nav App vs. Phone Voice Response
If your phone is talking to you when Apple Maps wants to speak, Apple employs the chime approach again. It works as well here as it did in the phone-call scenario, and it really raises the question of why Apple didn't apply it in the dictation case. You hear the chime, you know to look at your CarPlay screen, but you can continue to listen to your phone. It just works.
Google Maps treats your phone like a radio station. It mutes your phone's voice while it issues navigational instructions, then it turns your phone's voice on again. This is a curious decision. It means you could miss important information, such as a crucial part of an email message. I'd expect a nav app to treat a phone's voice like a streaming app and pause it while the nav app speaks. Perhaps there's no CarPlay API to pause Siri output...?
Recap:
- Google Maps: Mute phone voice, speak, un-mute phone voice.
- Apple Maps: Don't speak, but issue a chime.
If you have additional information on how nav apps handle audio conflicts, please let me know in the comments below.
