ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On 05.10.2015 12:02, Michael Zanetti wrote:
> 
> 
> 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.

This should've been "ringtone" volume... Sorry for that.

> 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