ubuntu-phone team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Zanetti wrote on 30/09/15 10:42:
> 
> On 29.09.2015 20:54, Matthew Paul Thomas wrote:
>> 
>> Michael Zanetti wrote on 24/09/15 10:04:
>> 
>>> ...
>>> 
>>> Well, this is not really a bug in an implementation itself, but
>>> rather in the way we use the buttons. I press volume down a
>>> couple of times wanting to adjust the game value, but instead
>>> it acts on the ringtone volume because the game currently
>>> doesn't play a sound. The short sound effects are too short to
>>> make the buttons act on them in a useful way.
>> 
>> Okay, so that is the bug with the default role not being the one 
>> that sound effects use. <http://launchpad.net/bugs/1498466>
> 
> No. The issue is that the sound effect is playing too short and 
> thus the hardware buttons have not enough time to work on that 
> role.

Which is what I said in that bug report. I'm not assuming a particular
solution.

> Yes, you could workaround this by making the SoundEffect use the 
> same role as the ringtone, but that would introduce new issues:
> 
> a) I cannot have the sound effects in games muted but still hear my
> ringtone.

Good point.

> b) If a game has sound effects and background music, the issue 
> would be back. As the background music's role (multimedia) would
> be active most of the time and the SoundEffect/Ringtone role comes 
> active for fractions of seconds only, not allowing to adjust them 
> reasonably.
> 
> The only way to fix this issue by changing the sound effects role, 
> is to change/drop *all* of the roles, otherwise there will always 
> be combinations of roles which will bring this issue back. I agree 
> we don't want to drop all the roles, hence my proposal to keep the 
> current role (multimedia) active for the full time while an app 
> with audio permission is focused, not just while something is 
> actually playing. Also all sounds an app creates should end up in 
> the multimedia role.

If we did that, what -- if anything -- would use the "alert" role?

If the answer is "notifications", that would have the odd effect that
the same sound, for the same event, would be a different volume
depending on whether that app was in the background (so the sound was
from a notification) or in the foreground (so the sound was from the
app itself).

> ...
>>> Hmm, I think this is a good point where we have a different 
>>> understanding: You say in silent mode some things should be 
>>> silenced (ringtones, background music, sound effects) but some 
>>> things should still be playing (manually-played videos). I for 
>>> one would assume that when I put silent mode on my phone, it is
>>> silent. Even manually played videos shouldn't make a sound 
>>> unless I explicitly raise the multimedia volume which would 
>>> exit silent mode.
>> 
>> I don't think it's reasonable to prevent people from silencing 
>> their ringtone and notifications when watching a video with 
>> sound. On the contrary, watching a film is precisely one of the 
>> situations where I'd want to do that.
> 
> I never said that... I just said that if I activate silent mode, 
> everything should be silent.

"Everything" would include the audio of the film. Therefore, Silent
Mode would silence the audio of the film. Therefore, if you wanted to
silence the ringtone and notifications, you couldn't use Silent Mode
to do it.

> But I would still allow to move the ringtone slider to 0 and 
> keeping the multimedia slider at 100.

There would be two drawbacks to that. First, we'd need two volume
sliders. ;-) Second, if you wanted to stop the phone from ringing, you
would need to think about and choose one of two ways of doing it,
depending on why you wanted to do it. Is it because you want to
silence *everything*? Choose Silent Mode. Is it because you want to
listen to something uninterrupted? Find the ringtone slider.

Maybe I have the wrong mental model. Maybe "I want to stop the phone
from ringing" is not the way people think about these two situations.

Even if not, though, if we introduce some way of going into Silent
Mode with hardware buttons in future, presumably it would perform only
one of those variations. Which one?

> IMO the "silent" mode is the one that is activated when going into 
> a meeting, or in class in school/university. You activate the 
> silent mode and rely on the fact that the device doesn't make a 
> single beep so the teacher doesn't take it away or you don't 
> disturb the meeting/lecture, even if you are playing around with 
> the device because you're bored by the lecture/meeting. If our 
> silent mode still allows producing sounds it's basically useless
> as a silent mode as one never can rely on it. Each tap in the UI
> could potentially start playback of something...

If I had been the first to design a phone OS, I would not have called
this mode "Silent Mode" (just as I would not call offline mode "Flight
Mode"). I'd call it "Critical sounds only", or some svelte equivalent.

Maybe we could introduce a really-silent mode. But if we did, I don't
think we could call it Silent Mode. That name is now, however
perversely, too strongly associated with something else.

Google seems to have tried something similar in Android 5.0, with
three notification modes -- "None" ("Not even alarms"), "Priority",
and "All" -- and settings for what exactly "Priority" should mean.
<https://www.androidpit.com/android-5-1-lollipop-silent-mode>

This has caused ongoing rage, apparently because none of those options
meant "everything except alarms should use only vibration now,
thanks". <https://code.google.com/p/android/issues/detail?id=79445>

Samsung then promptly added a "Mute" button on top.
<http://www.androidcentral.com/samsung-galaxy-s5-receives-software-update-brings-back-silent-mode>
Not having a Samsung, I don't pretend to understand how that interacts
with the other settings.

> ...
>> I disagree. When I said "It requires care from app developers", I
>> meant "It *has to* require care from app developers" -- because
>> without app instruction, there's no way that an OS can tell how
>> important a particular sound is.
>> 
>> So it's the SDK's job to make it as easy as possible (and/or 
>> compulsory) for app developers to make that decision. That's 
>> where the SDK is failing.
> 
> No... IMO the app developer shouldn't have to do anything.. Every 
> sound an app makes should be part of the multimedia role and the OS
> controlling the volume. Otherwise we'll keep staying in the mess
> that every app behaves different and everything is totally 
> unpredictable.
> 
> The only exception is when apps produce ringtones for 
> messages/calls, but in those cases apps would not use Auido {} or 
> SoundEffect {}, but instead the push-helper plays the ringtone 
> sound. In other words, only trusted helpers for calls, messages
> and alarms should be allowed to produce ringtone/alarm sounds. 
> Everything else the app creates is multimedia.

Consider Sleep Cycle, the #1 paid Health & Fitness app on Google Play,
and #2 in the iPhone App Store. <http://www.sleepcycle.com/> This app
lets you set a half-hour period during which you want to be woken up.
It sounds its alarm at the moment during that period when it detects
that you're most awake. This moment can't be predicted in advance, so
the app can't set a system alarm for it. How would this work under
your proposal? If you'd put your phone into Silent Mode sometime in
the evening, how would the app override Silent Mode to wake you at the
appropriate time in the morning?

If your answer is something like, "it would set an alarm to go off 5
seconds from now", then that would be a way for any app to override
Silent Mode at any time; it would just be hard to code. (Maybe we
*want* it to be hard to code, on the grounds that you shouldn't
override Silent Mode on a whim; but we should be deliberate about this.)

The #1 paid Health & Fitness app in the iPhone App Store, meanwhile,
is "7 Minute Workout Challenge" <http://7minworkoutapp.net/>, which
has spoken prompts because you often aren't looking at your phone much
while you're doing a workout. These spoken prompts similarly play
regardless of Silent Mode. Should they not?

Or consider Duolingo, a popular app for learning languages.
<https://www.duolingo.com/mobile> It uses frequent sound effects, and
asks a mixture of questions, some of which are spoken. With Silent
Mode on, the sound effects no longer play, but the spoken questions
are still spoken. That's exactly what I expected to happen. Is it wrong?

> ...
>> 
>>> I think the main difference here is "if media is playing" vs 
>>> "if an app with audio permission is focused".
>> 
>> What do you mean by "audio permission"? As far as I know, apps 
>> don't need any permission to play audio. (Or if they do, they
>> all have that permission by default.)
> 
> They do require a permission, and they don't have it by default.

Then how do they get that permission? I've never seen an "{App X}
wants permission to play audio" prompt -- which is good, because I
would have objected before designing it. ;-)
<https://wiki.ubuntu.com/AccountPrivileges#Phone>

> ...
>>>> 
>>>> So should VoIP apps -- Skype, Google Hangouts, Facebook 
>>>> Messenger, etc -- use the same "actual calls" volume level 
>>>> for their calls? It would be odd if they didn't. But if they 
>>>> should, that's a third role.
> 
> ...
> 
> Oh, now I get it... the calls role is the volume of the actual call
> voice... Right, I didn't regard that before either... Fair enough,
> we do have an additional role there, although I'm not sure if that
> role should ever be exposed to 3rd party apps in any way. I would
> probably consider it an internal state of the dialer/telephony
> app.

Back to the question, then ... Should Skype, Google Hangouts, Facebook
Messenger etc be able to use that role as well? If not, we wouldn't be
reducing the number of roles as the user experiences them, we'd just
be making their use less consistent.

>> I actually think it's more plausible that we'd combine the roles 
>> for calls and multimedia, than for calls and ringtones. After 
>> all, most calls are through the earpiece, while most multimedia 
>> is through speakers or a headset. And, per spec, "sound volume 
>> should be remembered independently for each *combination* of 
>> primary output device and active output role". So you could set, 
>> once, different preferred volumes for (a) music through
>> speakers, (b) music/calls through headset, and (c) calls through
>> the earpiece, despite them all sharing the same role, and seldom
>> have to touch them again. Obviously (b) would be the main risk
>> of contention.
> 
> Hmm... that doesn't sound good to me. For instance, I want 
> multimedia sound to be silenced most of the time, but that doesn't 
> mean I don't want to hear the other person talking on phone calls. 
> I see your point about the audio output device separting them, but 
> still, would break as soon as you plug headphones.

Right. And the same for Skype calls etc.

> ...
>>> Not really, so far there's two, and the alarm, which I
>>> probably wouldn't treat like the other two roles. Meaning, an
>>> alarm doesn't need to be adjusted like the others, by pressing
>>> the hardware buttons or having a slider for them, the volume
>>> for them is defined when the alarm is set up. So yes, it could
>>> be a "role" in that sense, but more hidden than the other two.
>> 
>> That introduces a third drawback, besides the two I described 
>> already: if an alarm went off in your pocket, you might 
>> reasonably guess that reaching in and mashing the volume down 
>> button would quieten it until you could remove it from your 
>> pocket and take more decisive measures. But no such luck! The 
>> alarm would ignore the volume buttons completely, merrily 
>> disrupting your exam or audition or seance or whatever.
> 
> Well, I don't think you want to fiddle with volume in that case... 
> each alarm will paint a notification with stop/snooze buttons. You 
> really want to hit those instead of pressing the volume button
> like 20 times and then sleeping in the next morning because after
> the exam you certainly won't remember to increase the volume again.
> And even if you'd remember to restore the volume, you'd need to
> wait for the next alarm to silently ring, because otherwise you
> wouldn't have any way to adjust volume again if we keep the current
> model of the buttons/slider only working on a currently playing
> role.
> 
>> (We might make the power button snooze/stop alarms, but that 
>> wouldn't affect the volume buttons.)
> 
> I like the idea of snoozing/stopping alarms with the power button.

So I'm still really skeptical of dropping the axiom that "If a sound
is playing, the volume buttons adjust its volume".

But it might be feasible to say, "If a sound is playing, the volume
buttons adjust its volume OR the power button silences it".

> ...
>>>> That would have two drawbacks. First, it would make the UI 
>>>> more complex for every app that sets alarms -- even in just 
>>>> the default/impending-default apps, we'd need volume sliders 
>>>> in Clock, Calendar, Tasks, and Notes. Yikes.
>>> 
>>> IMO that would be quite nice tbh...
>> 
>> Well, this poses a quandary. Can you think of any evidence that 
>> would persuade you that this is a terrible idea? :-)
> 
> Not really... It's not that every app sets alarms. Its the clock 
> app and the calendar app. There might be some more examples but 
> it's gonna be a hand full at max.

I gave four existing examples in the text you quoted: Clock, Calendar,
Tasks, and Notes. Sleep Cycle would be another. Any map/transport app
(Citymapper, Google Maps, etc) that reminded you when to get off the
subway would be another. (It would use an optimistically-timed alarm
since, underground, it wouldn't have data/GPS access to use a
geofence. As you were entering the subway, you probably wouldn't even
notice that it was setting an alarm, let alone see any slider for it!)

>> (For me, screenshots of any existing first-party app with 
>> individual volume controls for individual alarms would suggest 
>> that maybe it's not as terrible as I think.)
> 
> http://i.imgur.com/RPh37qv.png
> 
> Doesn't this scream for a volume slider to have a predictable 
> volume for the alarm I'm just setting up? :)

Even in this case where I'm paying attention to the UI in general,
adding a slider wouldn't make it predictable. Even if I paid attention
to the slider in particular, by the time the alarm went off the next
day, probably I would have forgotten what I'd set anyway.

> Right now I just can't make any prediction of how loud the alarm 
> will ring... It might be full volume, but it might just be 
> silenced, I can't know.
> 
> ...

We could solve that without having a panoply of sliders *or* having
alarms be a volume-adjustable role.

One possibility is to say, "All alarms start out really quiet and get
steadily louder, and therefore they're independent of any volume
control".

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlYNYmIACgkQ6PUxNfU6ecoQXwCfcEtpeIHDPEtytdNP521U6tOh
AiUAoIu6re6H32Esr6ubuCzUuLFZoEii
=NDz3
-----END PGP SIGNATURE-----