1068219 - (3.0 UX) Sound Design Updates

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Patryk Adamczyk [:patryk] UX]

Meta tracking bug for sound changes for 2.2

Comment 1

[David Scravaglieri [:scravag]]

Don't need to set blocker on meta, I am setting feature-b2g 2.2? for this.

Comment 2

[Jenny Lee]

Attachment: [Settings] Sound v1.4.pdf

See attached for Sound spec v1.4, thanks!

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Is this tracked under our team as feature-b2g: 2.2+?

Comment 4

[howie [:howie]]

No, this is not 2.2 committed feature.

Comment 5

[Evan Tseng [:evanxd]]

Attachment: [Settings] Sound v1.5.pdf

Comment 6

[Evan Tseng [:evanxd]]

Thank Jenny for the spec v1.5.

Comment 7

[Jenny Lee]

Attachment: [Settings] Sound v1.51.pdf

please see the latest spec, thanks!

Comment 8

[Jim Porter (:squib)]

I think the current audio channel competition specs on page 12 are far too complicated, and *still* don't handle all the cases we need. For instance, if you change the media volume in settings, it plays a sound on the content channel, which will *stop* any music playing in the background. I think it would make more sense to play both at the same time, or to reduce the volume of the background music to 20% like in some of the other cases.

I think the following rules would be simpler and more flexible:

1) higher-priority audio always "blocks" lower-priority audio; normal is the lowest priority, and public notification is the highest

2) audio in the foreground "blocks" audio in the background of the same priority

3) audio playback is divided into "short" and "long" modes

3a) when a short sound blocks another sound, the blocked sound is played at 20% volume until the blocking sound ends

3b) when a long sound blocks another sound, the blocked sound is paused until its app is brought to the foreground, or the user explicitly resumes it (e.g. by using the music controls in the lockscreen)

This would probably need a rule for vibrating when necessary, but I think the above rules would be a lot simpler to explain to users (and hopefully simpler to implement and test, as well!).

Comment 9

[Alastor Wu [:alwu]]

Hi, Mark,
Do we have any update about this UX spec?
As the audio competing policy didn't be defined very clearly, we have got some problems about the competing behavior.
I'll very appreciate if you can help update this spec.
Thanks!

Comment 10

[Mark Liang(:mark_liang)]

(In reply to Alastor Wu [PTO from 12/1-12/6] from comment #9)
> Hi, Mark,
> Do we have any update about this UX spec?
> As the audio competing policy didn't be defined very clearly, we have got
> some problems about the competing behavior.
> I'll very appreciate if you can help update this spec.
> Thanks!

I'll take a look into the spec, I'll let you know if you encounter any problem.

Thanks,
Mark

Comment 11

[Patryk Adamczyk [:patryk] UX]

Due to cancellation of Firefox OS, we won't implemented the V3 designs.