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
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
