ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On 01.10.2015 18:42, Matthew Paul Thomas wrote:
> 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?

Again, IMO inside an app nothing should use any other role than multimedia.

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

Not sure what you mean. If notifications (only ringing through the
push-client or unity8) would use the role, why would it depend on the
app focus state?

Obviously the app should not ring notifications itself using the
multimedia role or something. For ringing a notification it should
always go through libnotify or push and thus always end up having the
system ringing the notification for it.

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

+1 for 2 volume sliders. IMO the current magic single slider is the big
drawback.

And, no it's not too complicated to make the phone stop ringing. You
just enable silent mode :) Why would you still need video to make noises
if you want it to be silent?

Yes, I understand that there might be the rare occation where one would
want to disable ringtones but still watch a movie with sound. But for
that case I think it's really not asking too much to use the sliders to
set that up.

In 99.9% of the cases where you (well, at least me) want silent mode, is
because entering a place that cannot be disturbed via audio
reproduction, and it doesn't matter if ringtone or video playback.

Not making Silent mode behave like that has the drawback that one
silences the phone, believes everything is fine, accidentally taps
somewhere and the phone starts making noise even though the user thought
it would be silent.

> 
> 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?

My vote goes to "silent mode == silent device", regardless what
role/source/app.

Again, there's still the exception of alarm clock alarms which I think
should probably ring nevertheless. After all they've always been set up
by the user, and are there to remind the user of something, even if the
user might has forgotten to exit silent mode after the last meeting.

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

Even if called "Critical sounds only", I think that only applies to
alarm clock alarms. A Video doesn't qualify as critical sound to me.

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

That probably is my lack of experience of using an iPhone... But as
you've probably figured, I don't associate "Silent Mode" with
"Silent-except-maybe-video-and-some-music-still-make-noise Mode" :)

> 
> 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?

Now that is a good use case for the Background Service discussion. So
far, such an app wouldn't be possible. Anyhow, continuing with the
assumption it would be.

IMO if it's meant to wake you up, it still should use the alarm clock
style alarm. Note that an app can set up the alarm clock to ring within
a second from now. So yes, IMO, if it wants to escape the multimedia
role, going through a system helper and setting up a proper alarm is way
to go.

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

Note that the app requires the calendar permission in this case and is
subject to manual review in the store.

Hard to code is really relative... By the time one manages to integrate
with all the not yet existing system services in order to be able to
monitor the user while sleeping, using the Alarm {} item in QML will be
easy.

> 
> 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?

I like that you're coming up with all the impossible use cases we're
fighting for in another thread :)

No, I don't think those spoken prompts should play in silent mode. If I
can't even make them shut up in silent mode, how would I then? If I want
to hear my app talking, silent mode is really not the mode to be in.

> 
> 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 would not expect it like that... no... If the app is still usable even
when sound effects off, I would probably expect the app to offer a
configuration option to just disable sound effects. Other than that, I'd
expect everything the app produces to be on the same sound level.
Again, in silent mode I'd expect it to shut up completely.

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

Well, we don't have a trust prompt for it yet, but the app developer
needs to add the "audio" permission to the apparmor hook. The system,
could then show a trust prompt if we want. Basically the permission is
granted at installation time.

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

They should be able to ring ringtones, but not by playing sounds
themselves with the ringtone/alert role or something. They should use a
trusted helper which rings the device. For messages we have libnotify
and push-client to do so. For calls we'd need to come up with something
still.

> 
>>> 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".

I don't think we'd want to drop that. The only change I propose is to
change the behavior when no sound is playing. Right now it operates on
ringtone volume if nothing is playing. That has the issue of it jumping
back and forth if apps have short sound effects. My proposal is to keep
it on the multimedia role while an app that could play something is
focused, even if its not playing. If a phone call comes in, the call
notification shows up and takes the hardware buttons over.

There is, as I notice now, one issue with that. The Dash is also an app
that could play something. We probably don't want to keep hardware
buttons on multimedia all the time while the Dash is focused.... Still
need to think about this... Maybe the dash is an exception to that and
should only switch the volume keys to multimedia when it actually plays
music. After all it is an app that we control and it's not playing
sound-effects anyways, just proper music/video.

> 
> 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!)

If I don't notice it is setting an alarm, it probably shouldn't set an
alarm but instead play some multimedia. IMO it's again the same case as
the other examples you made... I don't think I want any app to set up
alarms except the clock app (or dedicated alarm apps). Note that alarms
can bypass silent mode. Something like a GPS navigation should not use
that in any case.

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

I disagree with this. It is definitely *much* more predictable than it
varying randomly, depending if you've been in a phone call or have been
playing a game at last... The current situation is exactly that, and as
I've said before, currently I cannot trust an alarm on Ubuntu Phone to
be ringing. It might just be silenced and I've no way to find out.

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

I'd go for the panoply of sliders, given that only 3 use cases come to
my mind that should set alarms with the alarm role... The alarm clock
app, the calendar app and reminders on notes. Everything else is
multimedia to me, really. I'm not even sure if calendar and reminders
should use the alarm role. IMO they should ring with multimedia volume
too... Only the alarms that should wake me up in the morning should be
able to bypass silent mode, and should have a static volume. Nothing else.

And please note, I'm not proposing to introduce multiple roles for
different alarm types. I'd really propose to move them over to use
multimedia volume. Especially the ones that are synced to my device and
might even have been set up by other people in my calendar. That's again
something that IMO should *not* bypass silent mode.

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

While nice on one hand, it's too limited on the other hand IMO.

Br,
Michael

Attachment: signature.asc
Description: OpenPGP digital signature