You don’t have to prove your point, I believe you when you say people were requesting this feature.
Might it be that a few very vocal people succeeded in forcing this “feature” onto the majority?
And like I said, why don’t iPhones do this?
Of course this might be.
But you seem to be strangely sure of who the majority is in this case. How would we be counting to know?
We wouldn’t need to discuss majorities if this was switchable by the user.
Not every Android phone does this either.
But looking at iPhones in particular … as I said implementing this needs more work than not implementing it, and Apple is in a position to be always right by definition, remember “You’re holding it wrong”.
The phone keeps the time from the clock always right until the battery is out power, so I guess the phone is never really off. And it is good to save the battery at night in certain situations and still be able to benefit from the alarm.
Imo that that is an edge case. I get a feeling that many people suffer for the convenience that maybe, maybe you could, if the situation arises, save your battery AND have your phone wake you up.
At the very least it should be an opt-in feature and not opt-out. Now it’s neither. It’s always on.
I think it was better if that would have been a ‘hibernate’ option in the shutdown/restart menu. Then you have to consciously select it:
No, I said “might”, so I’m not sure. I am just posing the possibility.
1 Like
First time I see Hibernation on a phone but it might be working same.
There is probably a setting to control the alarm ?
By the way I had the same problem with my 7 alarms the other morning, since my meeting was canceled I struggled to find a way to shut this thing off for good.
For the user experience people that decide on this, I find it EXTREMELY hard to believe that the people requesting a phone to turn on for an alarm are in actual fact not working around some other really big issue that really is bothering them.
The fact is that turning off a phone puts it in deep sleep that may last weeks or months (on proper hardware). This is super relevant in a world where a lot of phones do not have a removable battery anymore.
Breaking this behavior is breaking the usability rule of least surprises. Ask 100 people on the street and you’ll see that the majority will say they do not expect an alarm on a device that has been manually turned off. Naturally phrasing of that question is relevant.
I want to repeat that the action of turning off a phone ever is similarly rare for a large number of users out there. This should not be a surprise, people prefer to put their phone on a charger on the nightstand at night if it has a bad battery life.
None of what I wrote here is a surprise to any UX dev.
So, absolutely I understand that some users ask for a feature like the phone turning on. Even though the vast majority of people
a) never hits that usecase (they don’t turn off their phone)
b) expects the action of turning off a device to, well, turn it off…
Or, in other words, what I’m saying is that a single user can certainly come to the solution of “the phone must turn itself on!” when put in that situation. But that doesn’t mean it is predictable behavior. It doesn’t mean that this same user will actually appreciate it were the situation very different in the future. Like being low on battery. Or leaving their phone in a locker at the front desk while at the movies.
The UX devs need to not just fulfil every user-request, as that will lead to a bad product. Instead features should fit the mental model of users. Let the information “in the world” be a guide to what it should do as opposed to the information “in the head” which may be learned behavior and hard to predict.
The simple fact is, 10 minutes before the alarm the phone is turned off. Ask yourself if that means the alarm should ring. I think anyone honest will say it should not. People that haven’t heard the idea before will not think it makes sense to make a device that is manually turned off do something that requires it to be on.
Therefore the phone should reflect this “mental picture”.
Afterall, consider the idea that a person on your starred list calls you. Does the phone turn on then? Can you explain to a techo-phobe why not but alarms CAN be?
1 Like
They could just request it because enough old feature phones already behaved this way and/or this somehow makes sense to them. It’s absolutely not hard to imagine this … It’s an alarm, it’s obviously important, as opposed to a simple alarm clock the phone can even remember to sound the alarm when it’s “off” … Woohoo! Progress! What a time to be alive 
!
Can the phone know that an alarm is due in a few minutes time?
Yes, of course it can, the alarm was set on the phone, so if it is capable to start itself, it could do this in time to sound the alarm.
Can the phone know any call is incoming in a few minutes time?
No, obviously not, so even with a possible capability to start itself it couldn’t and wouldn’t do it in time.
Therefore you should put in a feature request.
You talked the talk, now walk the walk .
You’re definitey more technical than the normal phone user as is clear by your thinking about “a few minutes earlier”
I’m not at all sure what it is you are trying to say here.
You said “techo-phobes”, not “logico-phobes” .
By using your line of arguing … Give this explanation to 100 people on the street and you’ll see that the majority will say it is sound. (See, I can do this, too, without actually proving it.)
I’m confused…
Are you trying to be funny?
Just in case you are not… First apologies for not getting the joke and responding seriously.
I stand by the point that a phone that is turned off can not be simply be explained to be able to sound an alarm but not be able to ring when a phone call is incoming.
I mean, I’m technical enough to know there is a vast difference between the two and the second is clearly 1000 times harder to do. But I stand by the point that this difference is not something you can expect to be known by users.
You can explain it, but that is a very different proposition at that point based on the fact that most users don’t actually read such kind of explanations. So you need to start at the point of people’s mental model of a normal device like a phone.
Which brings us back the entire point here: the basic logic of a phone being turned off (not reponsive to touch, doesn’t do its major functions) is univerally accepted to mean it doesn’t do anything until the user turns it on.
Deviating from that basic premise could happen only when you are facing a very techy audience that can ‘get’ it and are willing to learn.
But in modern phones for the normal (non techy) user that e.foundation is aiming at, the idea to wake up a phone automatically is just wrong. A UX bug. A breaking of the mental model that you can honestly go and check yourself in the street. Ask your family members. Do the research if you disagree…
I disagree that it can be solved with yet another checkbox. Any UX person knows that is not a solution, indeed it just moves the problem from the designer to the end-user and thus doesn’t actually solve it.
To AnotherElk, what is your opinion in this matter, straight without jokes. Just what do you personally want your phone to do?
1 Like
Not really, but I apologise for playing the devil’s advocate perhaps.
I don’t see this issue here as an issue of right or wrong at all, so I found this line of arguing rather curious.
Anyway …
I really don’t care either way, I don’t use this either way, I don’t need this to be either way, I’ll live with it either way.
I understand wanting the phone to stay off, I also understand wanting the alarm to sound even if it’s off, both lines of thinking are coming from somewhere, and I understand both. This really isn’t hard to do.
What I see is pretty simple:
There are devices behaving in a certain way.
There are devices not behaving in this certain way.
There are users wanting a device to behave the one way.
There are users wanting a device to behave the other way.
No arguing in whatever direction here in this context will make the devices go away which behave the respective other way.
No arguing in whatever direction here in this context will make the users go away who want a device to behave the respective other way.
Implementing or not implementing the behaviour one or the other way obviously is a choice for the powers doing it, because both ways are out there in practice.
So the obvious solution for users (if technically feasible) should be choice, too.
Which you want to deny users by being dogmatic about it, ok, so be it.
But what do you want to do now?
You or me or anybody asking anybody else about it will achieve nothing specific in this matter.
UX persons of anybody’s choice knowing anything will achieve nothing specific in this matter.
We will still have the device at hand in this topic (as well as other devices) behaving in a certain way one side of the argument including you find absolutely bizarre, with the other side finding it absolutely reasonable and desirable.
So, the constructive thing to do from my point of view would be … Put in a feature request to at least have a chance to make something specific happen in this matter … to get this changed to your liking, or to get a choice, or to get a specific explanation why this can not be done, or to get a specific explanation why this will not be done.
1 Like
That is your projection on how other people use their phone.
Why should an alarm always be important? I use my phone alarm for simple reminders.
If you’re going to a concert, whatever that alarm was supposed to remind you of, is almost by definition less important.
The only valid thing that would be allowed to disturb the music would be an extreme emergency call from a close relative or friend. But because it is not technically possible, the feature is not there.
This feature suffers very much from the mindset: “We can do it therefor we should do it.”
If you look at the quote I was referring to, I was simply showing how easy it is for me “to believe that the people requesting a phone to turn on for an alarm are in actual fact not working around some other really big issue that really is bothering them.” … while others might find this “EXTREMELY hard to believe”.
Thanks for the effort to move things forward.
Brilliant find (the Settings search doesn’t find it for me looking for “power off” or even “power”, whyever).
Settings - Advanced privacy - App Permission Request - Additional permissions - Power Off Alarm
The Clock App seems to be allowed by default there … that should be it, just don’t allow it there, and the phone should stay off.
Edit: It didn’t work for me on the first try, but now the phone seems to stay off:
I first disallowed the Clock App in the setting mentioned above, then set an alarm, then powered off the phone … and it powered on for the alarm nonetheless.
I went back to the Clock App, which now immediately asked me whether I wanted to Allow or Disallow the setting I just disallowed, I disallowed again in this prompt, set a new alarm, powered off the phone again … and now it stays off.
So, make sure you get this prompt in the Clock App to really disallow … I guess …
3 Likes
I see where you are coming from. And I’m coming from a different direction 
You seem to say that devices should do what people want them to do.
What I’m talking about is based on my decade in user experience design and knowing that what people ask one day may very well conflict with what the same person asks the next. People are like that.
So to me a handful of places on the Internet where people asked for a specific feature is really no reason to change software to do that. I refer back to my earlier statement about “yet another checkbox”. Weak leadership (unable to say NO) leads to lots of checkboxes and generally speaking dreadful software.
UX design should start from the core principles that are about consistency, simplicity and avoiding surprises.
So, yeah, from my stated first principles it is not just Ok to say NO to a feature, it is indeed wanted and preferred if that feature breaks one of the rules.
And this one does, it is inconsistent, it adds a lot of user-level complexity and it certainly can show some nasty surprises to actual end users.
I was waiting for that feature since i leave my regreated symbian Nokia with physical qwerty keyboard ten years ago, for a BlackBerry, then a FirefoxOS device, an iPhone and finaly an /e/OS device.
I am forced to let my device ON during the night and i know flying mode is not a real radio OFF.
BUT i agree this feature should NOT be enable by default.
I think it is to promote it.
I supose it will not be enable by default in future versions as it can cause desagrements as you testified.
This topic was automatically closed after 30 days. New replies are no longer allowed.