ubuntu-phone team mailing list archive

[Nekhelesh Ramananthan <krnekhelesh@xxxxxxxxx>]

Hi Thomas,

In the night mode, I would not expect the screen to stay bright. I think
the design team's intention was to clearly differentiate between the
different clock modes. Besides in the Night Mode, the clock hands will
still use the proper colors, it will be just the background of the app that
turns dark. (90% opacity). However this is a detail that can be worked out
while testing the night mode.

  (1.) Would you expect the screen to stay bright when in night-mode?
> If not, I wonder if a darkened background makes sense at all, as the
> displays would autodim.
>
>
The visual design spec for the clock app is mostly done. However there are
some places which still need clarification like the one you raise. I like
your idea of using the proximity sensor to briefly turn on the screen. I
will bring this to the attention of the designers and update this email
thread when I get a reply about it.


>   (2.) Using the phone as a clock stand is certainly a good idea. Did
> you (as in you and design) explore the idea of leveraging the
> proximity sensor to briefly turn on the screen when the user "waves"
> in front of the phone?
>
>
Well this wouldn't too much of a issue since I could always add a timer
(for few minutes) or wait until the user taps the screen to end the Night
Mode. This is also the way the Android Clock App does it. But I will check
with the design team to be sure.


> One problem I see is: Today, the screen is kept on during periods of
> activity, where activity could be:
>
>   * user interaction
>   * video playback
>   * ongoing call
>
> All of these activities have in common that it simple to detect when
> they end. In the night-mode case, I have difficulties identifying
> criteria to be able to decide "night mode activity ended", except for
> a timeout (which then the users might want to adjust etc.).
>
>
+1 to the 3rd solution. However my only concern then would be if this is
viable within the RTM timeframe.  If you can give me a clear indication as
to if this is possible or not in the platform side, then I can accordingly
plan the implementation of the feature in the clock app. With the new
design we are essentially rebooting the entire clock app. And with that I
like to make a personal resolution of not exposing features in the UI until
their corresponding backend is complete. Otherwise it misleads the user and
warrants several bug reports against the clock app.


> While it is certainly possible to implement the exception as a viable
> short-term solution, it would also push the burden on the app to do
> the right thing (tm). While I'm certain that you will take care of the
> Clock app and its responsibilities, the assumption does not hold in
> the general case.
>
> That being said, I would prefer the 3rd option. We have been talking
> about making powerd policy-based, handling events and tracking
> activities to take power-related decisions. However, even if that
> happens, we still would have to come up with a good heuristic to
> determine the "end" of the clock app's "night mode".
>
> One alternative approach could be to allow the app to request an
> app-specific idle timeout within reasonable limits.
> That would also help in solving Oliver's ebook-reader use-case.
>
>
Cheers,
Nekhelesh