Jaime Chen <mailto:[email protected]>
January 9, 2014 11:35 AM
Hi Marco-
Let me have the team take a look and we'll follow up. Thanks for
calling this out.
Cheers!
Jaime
----
Jaime Chen
UX Manager & Design Strategist
Firefox OS, Mozilla
Marco Chen <mailto:[email protected]>
January 9, 2014 12:36 AM
Hi all,
It seems that this thread didn't attract much attention so I tried put
more issues which is waited to be fixed.
Bug 911238 - [AudioChannel] Consider to let normal channel play in the
background.
Or listen music from third party web site will not be allowed to
perform in the background.
Bug 871467 - [AudioChannel] To generate alert tone during in_call
state when alarm/notification is fired.
Or during phone call user doesn't have chance to notice any alart or
notification coming.
Bug 918626 - [Fugu][Buri][Camera][Music]When taking pictures,music
intermittent
Or user can't hear shutter sound because music volume is too big.
Bug 946556 - Music app in foreground can play the music now but
components underlying Gecko will block music stream during phone call.
The section of audio competing policy in [1] give the brief
introduction of what we have now.
And actually we didn't have any UX spec to show our audio competing
policy, we only collect each UX's reply in each bugs then implement it
in each patches.
So every time someone argue about this, we need to find out the
decision made by which bug then show to him/her.
[1] https://wiki.mozilla.org/WebAPI/AudioChannels
Thanks,
Sincerely yours.
----- ???? -----
???: "Dominic Kuo" <[email protected]>
???: [email protected], [email protected],
[email protected]
??: "Rob MacDonald" <[email protected]>, "Christopher Lam"
<[email protected]>, "Jacqueline Savory" <[email protected]>, "Casey
(Kok Ching) Yee" <[email protected]>, "Marco Chen" <[email protected]>,
"Andrea Marchesini" <[email protected]>, "Alive Kuo"
<[email protected]>, "Hema Koka" <[email protected]>
????: 2013 12 ? 20 ??? ?? 10:22:14
??: Improve audio competing policy and user experience
Hi folks,
Recently Gaia has encountered some audio issues that the current audio
channel API [1] did not
consider of, such as pick an audio file then preview it in mms while
music is playing in the
background(bug 894744), or talking in a call and listen to the music
at the same time via bluetooth
headset(bug 946556). These scenarios are not so common but let us know
there are spaces we can
improve for our audio channel policy/API, so I am sending this email
to start a thread.
From the perspective of audio channel API, the behaviours in the above
bugs are expected, but it
confuses our users and probably also mess up the ux that we are trying
to keep in the firefox os. I
have discussed with Marco and Casey about how we can solve this gap,
and we thought it might be
a good idea to start a discussion between devs and ux team to make
sure we are on the same page.
As an author of the music app, I believe the original audio c ompeting
policy was intended not to let
the apps involve the competing too much, and the apps can focus on the
features and don't have to
write some extra logic. But due to new features are making new issues,
we can probably provide
more api or information for the apps to handle the competing. This
depends on how our ui looks/feels
like and what ux we want to give to our users, so it might be better
that ux team can provide the policy
or rules from ux perspective, especially for the existing bugs [2][3]
to help the devs to design/implement
the new API if needed.
And since there are several audio competing bugs are first filed in
Gaia::Music, this inspired me to
do some investigations on the audio competing issues on the mainstream
mobile OSes. I just picked
two simple scenarios to test and the results are listed in the table
below.
Scenario 1 : The user answered a call and tried to bring the music app
to the foreground then play music.
Scenario 2 : The user is listening to the music, then go the settings
to change the ringtone.
OS
Scenario 1 Scenario 2
Android
1. The music will pause during the call.
2. The play controls in the music app will be disabled.
3. If the user try to resume the music, a prompt will come out and let
the user know it's disabled because of some reasons.
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music still plays in the background.
2. The previewing ringtone and music will be mixed together.
iOS
1. The music will pause during the call.
2. We can still play the music during a call.
3. Music will be mute.(playing without sound)
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music will pause.
2. When the user brings the music to the foreground, then music will
resume automatically.
Windows Phone
1. The music will pause during the call.
2. We can still play the music during a call.
3. Music will be mute.(playing without sound)
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music will pause.
2. When the user brings the music to the foreground, then music player
is in pause state.
Firefox OS
1. The music will pause during the call.
2. We can still play the music during a call.
3. The voice and music will be mixed together.
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music still plays in the background.
2. The previewing ringtone and music will be mixed together.
From the table I think every OS has it's own principle to handle the
audio competing, though I cannot
tell the exact idea, but basically we can see some OSes allow the
sounds to be mixed but some prefer
not to do so. I h ope this is a good start and can give ux team some
ideas to design the audio policy for
the bugs or the features in the future. And if ux team can drive this
and pilot the devs, that will be great!
Any thoughts?
[1] https://wiki.mozilla.org/WebAPI/AudioChannels
[2] Audio Channel: http://goo.gl/kLhP95
[3] [AUDIO_COMPETING]: http://goo.gl/rTvxag
Thanks,
- Dominic
Dominic Kuo <mailto:[email protected]>
December 19, 2013 6:22 PM
Hi folks,
Recently Gaia has encountered some audio issues that the current audio
channel API [1] did not
consider of, such as pick an audio file then preview it in mms while
music is playing in the
background(bug 894744), or talking in a call and listen to the music
at the same time via bluetooth
headset(bug 946556). These scenarios are not so common but let us know
there are spaces we can
improve for our audio channel policy/API, so I am sending this email
to start a thread.
From the perspective of audio channel API, the behaviours in the above
bugs are expected, but it
confuses our users and probably also mess up the ux that we are trying
to keep in the firefox os. I
have discussed with Marco and Casey about how we can solve this gap,
and we thought it might be
a good idea to start a discussion between devs and ux team to make
sure we are on the same page.
As an author of the music app, I believe the original audio competing
policy was intended not to let
the apps involve the competing too much, and the apps can focus on the
features and don't have to
write some extra logic. But due to new features are making new issues,
we can probably provide
more api or information for the apps to handle the competing. This
depends on how our ui looks/feels
like and what ux we want to give to our users, so it might be better
that ux team can provide the policy
or rules from ux perspective, especially for the existing bugs [2][3]
to help the devs to design/implement
the new API if needed.
And since there are several audio competing bugs are first filed in
Gaia::Music, this inspired me to
do some investigations on the audio competing issues on the mainstream
mobile OSes. I just picked
two simple scenarios to test and the results are listed in the table
below.
*Scenario 1*: The user answered a call and tried to bring the music
app to the foreground then play music.
*Scenario 2*: The user is listening to the music, then go the settings
to change the ringtone.
OS
Scenario 1 Scenario 2
Android
1. The music will pause during the call.
2. The play controls in the music app will be disabled.
3. If the user try to resume the music, a prompt will come out and let
the user know it's disabled because of some reasons.
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music still plays in the background.
2. The previewing ringtone and music will be mixed together.
iOS
1. The music will pause during the call.
2. We can still play the music during a call.
3. Music will be mute.(playing without sound)
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music will pause.
2. When the user brings the music to the foreground, then music will
resume automatically.
Windows Phone
1. The music will pause during the call.
2. We can still play the music during a call.
3. Music will be mute.(playing without sound)
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music will pause.
2. When the user brings the music to the foreground, then music player
is in pause state.
Firefox OS
1. The music will pause during the call.
2. We can still play the music during a call.
3. The voice and music will be mixed together.
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music still plays in the background.
2. The previewing ringtone and music will be mixed together.
From the table I think every OS has it's own principle to handle the
audio competing, though I cannot
tell the exact idea, but basically we can see some OSes allow the
sounds to be mixed but some prefer
not to do so. I hope this is a good start and can give ux team some
ideas to design the audio policy for
the bugs or the features in the future. And if ux team can drive this
and pilot the devs, that will be great!
Any thoughts?
[1] https://wiki.mozilla.org/WebAPI/AudioChannels
[2] Audio Channel: http://goo.gl/kLhP95
[3] [AUDIO_COMPETING]: http://goo.gl/rTvxag
Thanks,
- Dominic
