Closed Bug 988434 Opened 10 years ago Closed 6 years ago

Surprise! Settings>Sound>Alarm is for the Clock app!

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::Settings
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: dietrich, Unassigned)

References

Details

I had no idea, assumed it was about notifications or system level error popups or something.

So I put the slider all the way to the left.

And surprisingly, my Clock alarm made no noise in the morning!

There are probably two changes required to fix this bug:

1. Make the string in Settings>Sound to be clearly about the Clock app.

2. Allow the Clock app settings override the Settings>Sound>Alarm slider. If the user chooses a sound in the Sound field of an alarm, it means they want a sound!
Requesting UX review of this problem, and these proposed changes.
Flags: needinfo?(firefoxos-ux-bugzilla)
Ugh. This is less than ideal. Flagging Omega on Settings.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(ofeng)
IMO I think the current wording "Alarm" in Settings > Sound is quite good, since it implies that it will also affect 3rd party alarm apps.
For Clock app behaviors (overriding system Settings or not, or other solutions), Juwei, what do you think?
Flags: needinfo?(ofeng) → needinfo?(jhuang)
Alternately, we could have something that says "Click here to edit your alarms", which takes you to the clock app, implying that the alarm volume controls the Clock app.
Hi all, that's keep things simple :)

> 1. Make the string in Settings>Sound to be clearly about the Clock app.
As Omega said, the "alarm" may applied to 3rd party apps, we should keep the word generic.
> 
> 2. Allow the Clock app settings override the Settings>Sound>Alarm slider. If
> the user chooses a sound in the Sound field of an alarm, it means they want
> a sound!
Yes, indeed. We've already implemented a volume slider on creating/editing a alarm in Clock app (Bug 939197), so I'm sure people will found that the slider is all the way to the left when set up the alarm and adjust it back to normal sound.
Flags: needinfo?(jhuang)
(In reply to Marcus Cavanaugh [:mcav] <mcav@mozilla.com> from comment #4)
> Alternately, we could have something that says "Click here to edit your
> alarms", which takes you to the clock app, implying that the alarm volume
> controls the Clock app.

IIRC we've tried to keep away from this approach in Settings, so as to not pop users around. (While also trying to only put settings in Settings instead of apps - a tough thing to balance...)

Also, users will have clock apps that are not the built-in one, and alarms can be used for things not-clock.
(In reply to Omega Feng [:Omega] from comment #3)
> IMO I think the current wording "Alarm" in Settings > Sound is quite good,
> since it implies that it will also affect 3rd party alarm apps.

*You* understand that, but I don't think users make that leap of thought, which is the purpose of this bug :)
(In reply to Juwei Huang from comment #5)
> Hi all, that's keep things simple :)

I agree :D

The current wording is ambiguous, causing the user to be unsure of it's meaning, and unsure of the impact of changing it. If the user has to think about this, it causes anxiety and frustration, and is therefore no longer simple.

I think we can do better!

> Yes, indeed. We've already implemented a volume slider on creating/editing a
> alarm in Clock app (Bug 939197), so I'm sure people will found that the
> slider is all the way to the left when set up the alarm and adjust it back
> to normal sound.

I am not so sure that people will find that. I think people will not understand that when they change the slider in Settings, that *all* alarms of any kind across all apps that use the Alarms API will all suddenly be turned silent.
There is a lot of space in the current layout. Perhaps we could change the text to "Alarms (Clock alarms, timers, etc)".

It's not ideal, but it makes the setting unambiguous.
(In reply to Dietrich Ayala (:dietrich) from comment #0)
> 2. Allow the Clock app settings override the Settings>Sound>Alarm slider. If
> the user chooses a sound in the Sound field of an alarm, it means they want
> a sound!

Another idea would be to have the setting be bidirectional - if the user changes the volume using the slider on an alarm in a clock app, it changes the value in Settings.

This is not optimal because it also changes all alarms in all apps using Alarms API. However, it is preferable to ignoring the user entirely in a scenario where failing may cause the user to miss a flight or lose a job, etc.
Yes. This has to be fixed. It is not OK as is. People can miss important events.
(In reply to Dietrich Ayala (:dietrich) from comment #10)

> Another idea would be to have the setting be bidirectional - if the user
> changes the volume using the slider on an alarm in a clock app, it changes
> the value in Settings.

Bug 939197, which is close to landing, performs this bidirectional linking with Clock.
Thanks Marcus!
Depends on: 939197
See Bug 991026 for the Sound UX spec update.
In this update, volume bar icons are added in Settings to provide more information to help users understand more about each volume bar's meaning. Also, sound/volume preview when adjusting volume is added.
Since there is no longer a clear action on this bug (having landed alarm volume controls last week), I'm duping to bug 991026 for the Settings Sound spec. If there's any further Clock-specific changes, happy to reopen or discuss those changes; as it stands now, this appears to be a Settings papercut.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
There is still ambiguity in the string in Settings, where it's possible for a user to not realize they're turning their clock alarms all to silent.

Bug 939197 isn't quite closed yet, and bug 9910126 doesn't reduce the ambiguity of "Alarm", so let's leave this open until the dependencies and issues are addressed.

The effect of an action should be clear and unambiguous. This particular instance is dangerous: One incident and you'll never trust the phone ever again.

Separately, I'd like to dig a bit more into how 3rd party apps would be affected by this setting, because I don't fully understand it. I assumed it was via the Alarms API, but that's just timers-across-restarts, and has nothing to do with sound.

How would a 3rd party app's sounds be impacted by a user changing Alarms sound in Settings app?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Agreed that it is still ambiguous. Moving this bug to the Gaia::Settings component as that's where the actionable items on this bug remain.
Component: Gaia::Clock → Gaia::Settings
Thinking about this further, I'd actually suggest that we get rid of the Alarm slider from Settings entirely. On iOS, the volume for alarms is tied directly to the ringer volume and can't be changed separately.

The intent of the separate slider, as I understand it, is to apply to any app which uses the mozAudioChannel "alarm", though I don't think those two are explicitly linked anywhere.

Having several different volume sliders in the first place seems unnecessarily complex and confusing to me.
I like the idea of removing the setting entirely.

However, if 3rd party apps using mozAudioChannel "alarm" can then go off while the user has the phone in what they consider "silent" mode, then we lose trust yet again.

But that concern doesn't have much weight - I think it's extremely unlikely that a user would ever make the connection that Alarms slider in Settings actually applies to any 3rd party app.

(Unless the OS explicitly communicated it, by listing those apps in that Settings pane, or something like that.)
I also like the idea of removing this from Settings, but must respectfully defer to Omega. :)
Flags: needinfo?(ofeng)
I'd like to explain more about the Sound UX spec in Bug 991026. We added icons for the volume bars, and the icons for Alarm will look like Alarm Clock (They are placeholders [x] in the spec now, but our visual designer is working on the real icon design.) Since the volume bar and alarm clock have visual connection, we don't have to remove the volume bar from Settings.
Another downside of removing volume bar from Settings is: if a 3rd party alarm app has no in-app volume control and relies on only volume bar in Settings, removing the volume bar from Settings will be a disaster to that app.
Flags: needinfo?(ofeng)
Thanks Omega's explanation, and as bug 998911 is fixed, we have alarm icon for the volume sliders in Settings now, should we close this bug as the current ui fits the ux description? maybe WONTFIX for this bug.
Flags: needinfo?(ofeng)
Let's WONTFIX this.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Flags: needinfo?(ofeng)
Resolution: --- → WONTFIX
A couple of clarifying questions before closing this:

* When a user enables an alarm in the alarm clock that has a sound chosen, does the Alarms slider in Settings go back up?

* When a user selects a sound in the alarm clock, does the volume slider turn up?

* We still don't know how 3rd party apps are affected by the Alarms slider in Settings. Which exact API do 3rd party apps use that this would apply to?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Dietrich Ayala (:dietrich) from comment #24)
> A couple of clarifying questions before closing this:
> * When a user enables an alarm in the alarm clock that has a sound chosen,
> does the Alarms slider in Settings go back up?
> * When a user selects a sound in the alarm clock, does the volume slider
> turn up?
I don't think they should do it automatically, but we can add some dialog to advise user to adjust volume. ni? Alarm Clock UX owner Juwei since these questions in comment 24 are more like Alarm Clock parts.
Flags: needinfo?(jhuang)
Hi Deitrich, 
I know your concern is that the user may not notice that the sound is low when set up an alarm, but there are also some cases that user doesn't want the alarm sounds too loud...so I am not recommend to auto adjust the volume to a specific value when setting up an alarm.

I guess the better way is that if the volume sliders of the alarm is mute and the user is about to set up an new alarm/edit an alarm, we can pop out a window to remind the user that the alarm will be silent.
So the flow could be:
1. Add alarm
2. Alarm volume is mute, Set up time, and tap on done
3. A confirm window pops out "The alarm is mute. Set up anyway?" "OK" " Cancel"
4. Tap on OK will set up the alarm/ Tap cancel to back to alarm settings page.

Let me know your thought :)

And for your third question, I guess Omega can help you with it.
Flags: needinfo?(jhuang)
Juwei that sounds great, if we absolutely need the Alarms slider. Thanks!

> * We still don't know how 3rd party apps are affected by the Alarms slider
> in Settings. Which exact API do 3rd party apps use that this would apply to?

Omega, per Juwei's comment above - do you know this? Who are the consumers of the Alarm slider besides Clock?
Flags: needinfo?(ofeng)
(In reply to Dietrich Ayala (:dietrich) from comment #27)
> Juwei that sounds great, if we absolutely need the Alarms slider. Thanks!
> 
> > * We still don't know how 3rd party apps are affected by the Alarms slider
> > in Settings. Which exact API do 3rd party apps use that this would apply to?
> 
> Omega, per Juwei's comment above - do you know this? Who are the consumers
> of the Alarm slider besides Clock?

I don't know either. ni? Jenny who is the new UX owner of Settings/Sound.
Jenny, please follow up, thanks! :)
Flags: needinfo?(ofeng) → needinfo?(jelee)
All alarm 3rd app should be affected if the app chooses to use alarm channel.
ni Dominic for API detail, thanks Dominic!
Flags: needinfo?(jelee) → needinfo?(dkuo)
(In reply to Jenny Lee from comment #29)
> All alarm 3rd app should be affected if the app chooses to use alarm channel.
> ni Dominic for API detail, thanks Dominic!

If an 3rd app wants to have the sound behave like our Clock app, then it should set its audio channel type to |alarm|, once its channel is set to alarm, the volume will be associated as well. The alarm slider in settings is to adjust the alarm channel's volume, so any 3rd party alarm apps will be affected if they set their audio channel type to alarm.

And currently I think the Clock and Settings are able to change the alarm volume because only certified apps can use the mozSetting api, which we store the volume with the key "audio.volume.alarm". This means Settings and Clock will both modify the alarm channel's volume and affect each other, the 3rd party alarm apps could be also affected if it uses the alarm type channel.

To have the alarm slider in Settings make sense to me because, we could let the 3rd party apps to adjust the volume of the alarm channel which they don't have the capability to access the mozSettings api, but probably we need to clarify the ux between Settings and Clock and not to confuse the users.
Flags: needinfo?(dkuo)
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Closed: 10 years ago → 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.