Progressively red-en and dim backlight according to sunset

[Siltaar]

Once in auto-turn-on mode, using sunrise and sunset times, what Twilight (or Redshift) still does better is to adapt their relaxing-parameters to the expected ambient luminosity, regarding sun light intensity (assumed to reach the user through its windows).

Sun is rising/setting fast or slow relatively to the user position on the globe, and the user's eyes are adapting this light quite slowly also.

Despite the matching-sunlight goal, I personally like the progressive start of other solutions because my sight adapts to the red and I feel that the image on the screen is less red-distorded if I'm slowly boiled to it (like a frog in a slowy heated water-filled pan).

[raatmarien]

Thanks for the feedback!

I agree that the automatic turn on (and turn off) is too immediate right now. However I feel Twilight's system is lacking in that it doesn't give the user the flexibility to turn the filter on earlier without changing the setting. For example when the user goes to bed early and uses their phone in the dark, while it is still light outside.

I will be looking into smoothing the turn on animation, when the filter is turned on automatically. For example turning it on gradually during 10 minutes. Do you think that is enough to let the user adapt to the changing colour?

[smichel17]

It would be possible to allow the user to specify the length, with 0 for instant transitions. That's good for flexibility but bad because it burdens the user with another decision (and one that we should not expect them to know the answer to), so I'm not sure if it's worth doing.

I'm not sure what the optimal transition period is, I believe f.lux, redshift, and twilight all take ~1 hour. Perhaps that is a reasonable default?

[bungabunga]

i agree longer transition (60-90min) is better bacause the sunset/dawn also takes some time.

[smichel17]

Original comment:

Say the transition period is 1 hour, and the user has configured the filter to pause at 7:00 and resume at 18:00. When should the filter transitions start?

My initial thought is that I (a as user) will probably set the filter for the time that it gets dark out, the time when I want the filter to be fully on, so the transition period should begin (in this case) 60 minutes before that time. Same for the morning time -- the filter should be fully disabled at whatever time I set.

edit 2017-03-03: I don't think it actually matters so much which behaviour we choose. As long as we communicate when the transition period starts and finishes, users will be able to put the transition period where they want it. It's more important that we get a good default for when we're setting the times automatically, since users can't adjust that.

[Siltaar]

Ok for user-set time.

What I experienced regarding (at least french) official sunset/dawn times is that sunset time is when the sun is entirely set, so transition could start 1h before. For dawn, I have less experience :p but I think the official time is the start of the process, so transition should start at this point and last for 1h after.

A one-size fits all suggestion would be to start transitions 30min before which time is considered for it, and last until 30 minutes after.

And slow transitions is what motivated Twilight to offer an "immediate try settings" button.

[bungabunga]

i think that Red Moon filter should be working 100% not when the sun is down but when it finally gets dark. that probably means the sunset should be the starting point of the process and sunrise an end of it.

[bungabunga]

CORRECTION: i think the "now it's totaly dark" point matters, sunset/sunrise not so much. a default or manualy set (evening-start/morning-end) transition periods should depend on this.

[smichel17]

When the "sun" setting is enabled, it is 100% clear what should be happening: the filter should line up with the sun -- the transition starts as it dims outside and finishes when it's fully dark (and same thing on the other end). We can modify whatever settings we need to in the background to force this to work, because the user doesn't see them.

I am more concerned with -- what should happen when the user has set custom times?

@bungabunga @Siltaar and others that I linked here: would you help with some informal research? Go to Red Moon and set custom times for the way you use the app right now, when it doesn't support transitions. Then get the answers to these questions:

• What times did you set (local time)?
• At each of those times, how bright was it actually out? (alternatively, "I was sleeping so I don't know")
• What time did it start to get dark?
• What time did it get fully dark?

After that, change the setting to 'sun', update the location, and write down what Red Moon automatically uses for sunset times. I don't think the latest f-droid version tells you this information so you'll have to download it and build yourself. Hopefully the next version will be out soon :) see #30

[Siltaar]

I did set automatic times at : 22h turn-on ; 08h turn-off. It was night outside at 22h, but I had lights turned on in my living place… At 8h it was already bright outside, but my eyes were expecting small lights to look at.

In sun time, I can't tell if it was really synced with the actual light outsides. I'm waiting for an update to get feedback from the app about this feature.

Now, I disabled the dim feature, as it's usefull only when no other lights are on around, and it's not my case, so when the phone reboots, I just urge to disable Red Moon to be able to use the phone.

On the contrary, I like RedShift on Linux because is is limitating with an upper value the screen color temp even at mid-day.

So I finally have 4 needs :

• exceptional times : normal image (to watch details in photos, install apk…)
• day time (with sun outside and no lights in) : need an already-reddish max-bright-screen value to get slightly red shifted screen all the time(so slightly relaxing eyes all the time)
• evening time (without sun, but few lights in) : need the full red but no dim
• night time (without sun, without lights) : need full red and dim (until I fully wake up…)

It could be possible to go in a continues process from a midday red value to full red at night, then full red and dim, and cycle everything back… Would allow to know which time is it, just by the color of the screen ^_^

Or, with current implementation, decide time bounds for intensity variation (or like RedShift, color variation from red to yellow), and separate time bounds for dim variation. It would do the trick for me I think.

(after that, if RedMoon could accept a setting like : secondary time bound to stop dim feature = time when next alarm will ring ; it would be perfect !)

[jo-elimu]

I also often have problems with the change from bright to dark screen being too sudden.

A gradual transition similar to what f.lux does would be nice:

[smichel17]

@Siltaar Your long comment is a great analysis. Some of those will be addressed with #75, others with #106. For this issue, let's just focus on the part about the gradual transition. I'm not sure exactly how it should interact with something like #106, but we can worry about the future if/when we get there.

---

Here's what I'm planning on doing. Feedback welcome.

• For now, I won't add a new setting for fading in; I'll just use whatever Times from location is set to.
  • It's much, much easier to add a setting later than to take one away. Relevant xkcd.
  • If I were to add a Fade in setting, there's two options:
  • The simple option: a toggle.
    • I am inclined not to add this, just because I'm having a hard time imagining any case where you would want Red Moon to be on a timer but not to fade in.
  • The flexible option: the length of the transition period (minutes)
    • This might be worth adding, because it also gives you some control over when Red Moon turns on. Don't usually go to bed until midnight? Set a long transition period!
    • This would be a nice solution to #100.

The transition period will start at the normal toggle time. For this early implementation, I'll hard code it to one hour, and we can figure out later whether that needs to change or be configurable. This will make Red Moon turn on and off a little bit later. I think this is fine; in my opinion, Times from location sets times too early anyway.

---

Red Moon will treat the transition period the same as if it were fully on. We need to do that, or else people who don't use Pause in secure apps will have issues. Tapping the switch or toggling via the notification/widget will turn Red Moon off.

There is one difference! You cannot manually enter a transition period. If you turn Red Moon off during the transition period you have canceled the transition. Turning it back on will not resume the transition, and Red Moon will not change state at what would have been the end of the transition.

Aside: If we still had a pause function, pausing would allow you to resume back into the transition. With recent backend changes, this is technically easy (just add a new state that subclasses suspendState) but I am not convinced it is worth the extra complexity for the user. If someone were to convince me that it's worth it, I would show that option only as an action that can be taken from the notification, and only during the transition period.

---

I am going to do #107 before this.

[smichel17]

I've added rudimentary fade-in for v3.0.0. Right now it's pretty brittle -- any change will cancel the transition (ie, switching filters, automatic pause in secure apps, manually toggling). It's hard-coded to an hour (starting at sunrise/sunset) and works only (and always) when Times from sun is enabled.

[smichel17]

Before I proceed with improving the UX for this feature, I'd like to get some feedback about how the current setup (v3.0.0) works for you all.

[bungabunga]

just installed RedMoon 3.0.0, will report tomorrow..

[bungabunga]

first impression: i forgot to turn on timer feature when i installed the app so there was no automatic fade in. when i realised this in the morning at 7.00 i swiched the timer on. nothing happened. i think the right response from the app in this situation would be to turn off the redlight immediately.

[smichel17]

https://github.com/raatmarien/red-moon/issues/137#issuecomment-296536441

[bungabunga]

i think that the fade-in doesn't really work on my phone (not sure though). sunset is at 20.10 here and redmoon notification appeared but until 20.35 i haven't spoted any difference on my screen. to check out i then pressed the turn-off button and also there was no difference. timer and times from are enabled.

[cao-]

@bungabunga I can confirm what you said: the red moon notification appears but the filter does not turn on.

[smichel17]

Does not turn on or does not turn on immediately?

It should fade in over an hour, so for the first 15-20 minutes it will be hard to notice (the fade is not linear).

[cao-]

@smichel17 It does not turn on at all. The notification appeared at sunset time, but then even after more than an hour the filter wasn't active.

[smichel17]

@cao- @bungabunga Workaround: set custom times to whatever your sunset/sunrise times are (right now the fade only applies when you are using times from sun).

In general this implementation of fading is very fragile (ie, I knew I'd have to rewrite it); seems I'll have to do that before I can get UX feedback though :)

[bungabunga]

hey, my sunset/sunrise times are set properly and i am using tmes from sun. i am sure that there is no fade-in, no fade-out either.

[smichel17]

Would you find it useful if the notification displayed a progress bar while it was fading in/out, so you could see how close to fully on it is? Assuming it works properly, so "yes, so I can see if it's working" wouldn't be a reason to add this ;)

[bungabunga]

yes, that would be great. it could also be a XX%, don't need to be a progress bar. twighlight, the app i used before redmoon also has it.

[smichel17]

Update for anyone following this issue: I and the other screen filter app devs are working on a library to do this over at https://github.com/LibreShift/TransitionScheduler, so this will be in one of the next two releases (edit: I'm not sure how much time it will take to get the release ready, though).