ubuntu-phone team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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

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>

> ...
>> 
>> In theory, you can go into Silent Mode before you start the 
>> game.
>> 
>> In practice, this doesn't work because of a separate problem: 
>> Silent Mode requires care from app developers, but our SDK makes 
>> it highly impractical. It requires care from app developers, 
>> because the OS alone can't tell which sounds should play even in 
>> Silent Mode (alarms, manually-played videos, language-training 
>> exercises) and which should not (ringtones, background music, 
>> game cutscenes, sound effects). And our SDK makes it highly 
>> impractical, firstly because we give no hint how to do it 
>> <https://developer.ubuntu.com/en/search/?q=silent+mode>, and 
>> secondly because even if we did, a developer would need to 
>> remember to wrap an 
>> if(getUserValue("com.ubuntu.touch.AccountsService.Sound", 
>> "SilentMode").toBool()){...} or equivalent around every sound 
>> that should not play in Silent Mode -- which, most of the time, 
>> they'll forget to do.

In the past week, nobody noticed that that code produced the exact
opposite result of what I intended ... which is not a good sign for
developer adoption either.

>> <http://irclogs.ubuntu.com/2015/06/01/%23ubuntu-touch.html#t15:26>
>
>
>> 
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.

(Maybe one day we'll have a Do Not Disturb or similar mode that will
fulfil that use case even better. But the existence of a Do Not
Disturb mode would not change the effect that I'd expect Silent Mode
to have.)

> Note that I'm not necessarily saying this would also raise ringtone
> volumes. Ringtone volumes might still be at 0, but it's not in
> "silent mode" any more. When the phone says it is in silent mode, I
> rely on the fact that I can do whatever I want with it and it won't
> make a sound.
> 
> I guess alarms would be a special case indeed here which might 
> escape the silent mode and still are allowed to make sounds there. 
> Not sure... I guess alarms from the clock application are
> different than calendar entries there. I would want my phone to
> wake me up in the morning even though I left it in silent mode
> yesterday, however, in silent mode I don't want my phone to ring a
> calendar entry every hour. Maybe calendar entries should use the
> multimedia or ringtone role too and only real alarms from the clock
> app have the special alarm casing...

Yes, whether calendar notifications should differ with Silent Mode is
a murkier question than whether clock alarms should. The current
designer has said that Silent Mode should mute calendar alarms.
<http://launchpad.net/bugs/1440111>

But that's a question that would be made harder, not easier, by moving
it from the app's control to that of the OS. The OS has much less
information to work with.

> I agree that relying on the app developer to take care about it is 
> not way to go here.

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.

> ...
>> 
>>> Probably the hardware buttons should then control ringtone 
>>> volume while no app is focused (or a call indication is on
>>> top) and control the multimedia volume whenever an app is
>>> focused or media-hub is playing in the background.
>> 
>> Similar to the current design: 
>> <https://wiki.ubuntu.com/Sound#role> | | * Otherwise, if media
>> is playing, the active output role should be | "multimedia". | * 
>> Otherwise, the active role should be "alert".
>> 
>> ("Alert" here includes ringtones. If you're playing music and 
>> your phone rings, you should still be able to adjust the
>> ringtone volume, because the music should have paused
>> automatically.)
> 
> 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.)

> An app (for example Dinosaur) might not be playing any background 
> music, just very short sound effects. Those sounds are too short 
> for the user to react on them and press the volume buttons. By the 
> time the buttons are pressed, we're back in the alert role and the 
> user controls the ringtone instead of those sound effects.

Right, that's the same role bug as above.

> ...
>> 
>>> * Apps should always use the multimedia role, regardless of 
>>> what they do (unless thy deal with actual calls or incoming 
>>> messages).
>> 
>> 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.
> 
> Why is that a third role? IMO just the same as the primary ringtone
> role.

So you'd have the same role for ringtones and calls? That could be
pretty annoying. For example, I used to work on a fruit grading line
where the office phone ringer was really loud. It had to be, because
otherwise no-one would hear it over the noise of the grading machine.
Did that mean the calls themselves should have been just as loud? No,
because whenever someone answered the phone, they did it after going
into the office and closing the door. If that had been a mobile phone,
having to turn down the volume every time we answered a call -- and
remember to turn it up again every time we finished -- would have
gotten boring fast.

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.

> ...
>> 
>> Well then, now we're up to four roles ... the same as the current
>> design!
> 
> 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.

(We might make the power button snooze/stop alarms, but that wouldn't
affect the volume buttons.)

> ...
> 
>>> But one never controls that role with either the buttons or a 
>>> slider. Instead, each alarm has his own volume value assigned 
>>> when the alarm is created, and an alarm is always played at
>>> the volume its config says (except maybe only vibrate when the 
>>> phone profile is set to vibrate only - but those are small 
>>> details we could work out on the road).
>> 
>>> ...
>> 
>> 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? :-)

(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.)

>> 
>> Second, it implies that "The volume I specified for the alarm, 
>> however long ago I did that" is more likely to be appropriate 
>> *now* than "the volume I adjusted, or was okay with, the last 
>> time an alarm went off". I think the reverse is true.
> 
> I think of it rather this way: The alarm that wakes me up in the 
> morning should always be the same volume, regardless of the volume 
> that reminds me of meetings during the day. I would want to have 
> alarms for calendar entries rather silent to not disturb the whole 
> office all day long, but the morning alarm needs to be full force 
> ahead, or I'll sleep in. And I can't manage to remind myself every 
> evening to check and adjust the alarm volume for the next morning.
> 
> ...

I understand the niceness of having different volumes for alarms in
different environments. But that way of achieving it wouldn't help as
many people as you seem to think. Some proportion of people wouldn't
notice the sliders in the first place. Of those who did, most wouldn't
understand why they were there. And of those who did, only a small
fraction would be like you and put enough thought into it to decide,
"hmmm, loud alarm in the morning, quiet alarms during the day".

Meanwhile, *everyone* would have the problem of "Argh, the last alarm
I set was too loud, and so is this one, and so will be the next one,
and the volume buttons don't even do anything" -- whether they knew
about the sliders or not. And even if they did know, fixing the
problem would require changing multiple sliders for however many
alarms they had. You have to take medication four times a day, and the
first alarm was too loud? Well then, taking the medication is not even
the most boring thing you'll be doing today. You'll also be twiddling
four sliders in four separate dialogs! Woohoo!

A much simpler solution would be to have alarm sounds that start out
quiet, and -- over a period of twenty seconds or so -- gradually get
louder. That would work no matter what environment you're in.

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

iEYEARECAAYFAlYK3lUACgkQ6PUxNfU6ecrE1wCbBdA5NRBDwwOlctbx2Yy1rpTe
g4sAoNIMEanun79ZDj2thsg/WhGkwhMP
=dFB3
-----END PGP SIGNATURE-----