Bugzilla – Bug 12403
change "sleep" menu into a 1-line toggle
Last modified: 2011-01-14 12:24:58 UTC
discussed with ben and dean on campfire. Proposal would be to have "Sleep" control be a single line in the "settings" menu (it's currently a sub-menu). Also recommending adding "current sleep time" to the remote behavior, as this was one of the listed advantages to the menu version. So the behavior would be the following. Touch UI (also controller menu etc): By default, present the current setting (include seconds) "Sleep: -63:45" (timer would be counting down). After first click, subsequent clicks toggle between settings, starting with highest number, then counting down (like a lot of alarm clocks and oven/microwave timers work etc). (xx:yy format is used to a) avoid localization problems, b) keep size small for controller UI, c) enable instant countdown in seconds so that user gets good feedback) "Sleep: 90:00" "Sleep: 60:00" "Sleep: 45:00" "Sleep: 30:00" "Sleep: 15:00" "Sleep: at end of song" "Sleep: Off" ("at end of song" might be tough to localize, might need to re-word) Alternate version (if it would work in localized form, and/or we didn't want the live second-by-second countdown): "Sleep: 90 min" "Sleep: 60 min" "Sleep: 45 min" "Sleep: 30 min" "Sleep: 15 min" "Sleep: at end of song" "Sleep: Off" Remote/controller UI: Basically same as above. first-time press of dedicated "sleep" button presents current setting (if turned on), otherwise start with "off." subsequent button presses start at 90 min and count down.
I _think_ that you are just asking for the same behavior on that menu item as is displayed on pushing the SLEEP button the remote on a classic device. In fact, we need to make the sleep button on the remote work for fab4 anyway. And it already does, we just need to make the menu do the same. i.e. Push once: "Sleep at end of song", twice: "Sleep in 15 min", thrice: "Sleep in 30 min", then 45, 60, 90, then off. This does mean that this menu item needs to be updated dynamically when that screen is shown, to show the current sleep time. What happens if you select this item (or press the SLEEP button on the remote) if the sleep timer is on? On the classic UI, the sleep time skips up to the next step (i.e. if the sleep timer has 27 minutes left, it goes to 30, then 45, etc...
(In reply to comment #1) > I _think_ that you are just asking for the same behavior on that menu item as > is displayed on pushing the SLEEP button the remote on a classic device. In > fact, we need to make the sleep button on the remote work for fab4 anyway. And > it already does, we just need to make the menu do the same. Basically, yes. And maybe that's all we do for this version. There is an issue of getting all of the text to fit in localized languages on controller (which is one argument for using xx:yy format - removes need for "min" or "minutes"). In addition, however, I'm suggesting some different functionality (see notes below): > What happens if you select this item (or press the SLEEP button on the remote) > if the sleep timer is on? TWEAK #1 The one really nice thing about the current menu is that is shows the current time remaining on sleep. It has the benefit of keeping you from accidentally resetting the sleep timer when you don't know whether it's on or not. So My proposal is that, when you first press the "sleep" button (on the remote), it would just show the actual time remaining (assuming sleep is on). On-device, the default display text would be "Sleep: x min" IF sleep timer is currently turned on, where x = time remaining. This is "new" behavior but only on the remote. The current menu UI on fab4 shows the time remaining when the timer is on, which is great. > i.e. Push once: "Sleep at end of song", twice: "Sleep in 15 min", thrice: > "Sleep in 30 min", then 45, 60, 90, then off. > > This does mean that this menu item needs to be updated dynamically when that > screen is shown, to show the current sleep time. > > On the classic UI, the sleep time skips up to the next step (i.e. if the sleep > timer has 27 minutes left, it goes to 30, then 45, etc... Er, right, I think we're saying the same thing basically. But I'm suggesting something (minor) here as well: TWEAK #2 almost all (good) alarm clocks or timers with sleep/countdown type settings start with the high number, then get lower (i.e. on old digital alarm clocks, when I hit "sleep" it starts at 1:00 and then counts down to zero as I hold the button down). Ours is backwards. Why does it matter? Why is counting down (instead of up) the "better" design? Because when I'm counting down, users will know that the "end" is zero - in the 1:00 sleep example above, the user knows that the number will stop counting down when it gets to zero. If you count "up," the user has no idea how big the number will get until it "stops." is the max setting 60 minutes? 90? 120? 180? the max setting is arbitrary in our case so someone who is toggling through a looped set of items is going to be a bit more anxious when using it for the first time. It's a minor, subtle thing, but these are the types of things that separate ok designs from really good ones - the attention to detail. So the proposal here is just to switch the order: [current time if applicable]/90/60/45/30/15/end of song/off. ("end of song" could easily be placed before 90, since it's not at all obvious we even have this feature until the user sees it - this is really more about the order of numbers from 0-90). ----------------------------------------------------- So, in descending order of importance/effectiveness IMO (for me anyway): - make this a toggle behavior that matches how the remote works - do "TWEAK#1" (show time remaining when i first visit the screen, OR when i first press sleep on the remote - but don't do either unless the sleep timer is turned on) - do "TWEAK#2," might not matter much to you guys but it's more intuitive
Great, so let's to the minimum for 7.4, then the tweaks post-launch.
cc:ing Richard Please note: My comment is only about targetting this for 7.4 release, not about UI design. I think this is a terrible use of resources for 7.4 release. Asking a choice item to be updated with arbitrary data that ticks down is an extension of the widget itself. The choice widget was designed to display categorical strings, not arbitrary data. The localization issue is also not trivial. It not only needs to fit in all languages, it needs to fit across all platforms, including controller. We've got a crazy pile of work to do for 7.4, and this can't be on that list. If we're going to start adding enhancements, lets fix the sync UI which is currently abysmal rather than player sleep which is fully functional.
So what is the minimum, as Ben says this already works. Does that mean it can be punted right away? Localization of choice items on the Controller was an issue, as if the strings get too long it does not render correctly. If I remember correctly it was actually Dean how suggested that we should limit choice items to simple things like "On" and "Off".
I am totally 100 percent fine with punting on this. I just wanted it written down. Feel free to reschedule for 8.1 or later...
resource constraints tell me this will never be fixed. closing.