Bugzilla – Bug 12361
Touch & Remote skins should use "..." for non selected menu items with long text strings
Last modified: 2009-12-22 09:46:12 UTC
"..." will do 2 things: 1. it let's the user know there is more text than what is currently viewable on screen. Currently the text is just cut off. 2. limits the necessity to scroll and does not appear to be a bug.
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code. Feel free to move it back if it's specific to the single original product.
Reset priority before triage.
Please also see bug 12935. My contention is that in the touch interface, there should be no concept of a 'selected' item, so you should never have a 'selected' item scroll in this interface. Once you've selected an item, some action occurs. You move right while navigating, or a track plays and you move into NP, or you pull up a context menu and do something in the CM or cancel. Coming back into that screen, the item that you touched should have no significance and therefore should not scroll. Only in the IR interface, with item highlighting, can you have a 'selected' item.
"..." should only apply to text strings that are NOT scrolling. For example on the touch UI, Jim is correct that menu items would never scroll. On touch "..." should appear more often and is more necessary as to not look like a bug in the software.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
With the recent discussion regarding the NP template revisions adding this in is even more necessary.
Adding keyword: Bug meeting With the notion of a "10ft" UI more text will inevitably get cut-off screen templates. For menu items and the Now Playing album/artist text this type of indication is a P0 and should of been in place for the original Controller release. Please keep this in mind for prioritization for release. Without this level of refinement the UI will appear buggy and unfinished.
We talked about this bug at length in the bug meeting today. If this is meant to copy the iPod functionality, there is an important difference that should be considered: iPod doesn't even bother to scroll. So, the problems resulting from this difference would seem to be: * If you want the '...' at the end when not scrolling, what do you want to happen at the transitions? When scrolling begins you want the '...' to just disappear and be replaced with characters? That's clearly ugly. When scrolling stops do you want a chunk of text to disappear and be replaced with '...'? * What about at the beginning of the text when scrolling begins? There will be text 'missing' at the left edge of the screen. Do you want a 'leading' ellipsis, too? Are we really sure we want to give what little space we have to ellipses?
Chris, Yes, the "..." and the remaining characters would be interchangeable. If you are nav. a list as you scroll over an option with "..." it would be replaced with char. as soon as the item was highlighted followed by a 1-2sec pause before scrolling left to right. The same effect would occur in reverse as you scroll off a truncated item. In terms of Now Playing. It is my intention (and has always been) that multiple lines would NOT scroll. In the hierarchy of track/album/artist, track info. is the single most important piece of info. For long albums and artist names "..." would be added. This is far better then simply being cut-off abruptly giving little or no info. that title extends beyond the page. What we have now is frankly crude and appears unfinished. ____________________________ "* What about at the beginning of the text when scrolling begins? There will be text 'missing' at the left edge of the screen. Do you want a 'leading' ellipsis, too?" Of course not. The motion of the scrolling text is enough to imply there is more information. The user will only see 1-2sec before the line is in motion. I am surprised this is such a contentious issue.
My switch to P2 got hit with a mid air collision. Trying again, a day later.. For followup, from the meeting, I/others think there are other P2's that are higher/similar priority than this and when we get around to reviewing what P2's to do this will be there.
The problem with this bug has never been that it's been contentious, but rather the amount of engineering effort involved in delivering this behavior. FYI, with the departure of Tom and Richard, this bug has zero chance of being fixed in the near term.