Bug 12171 - List items should always "snap" to certain positions, regardless of length of copy on screen
: List items should always "snap" to certain positions, regardless of length of...
Status: RESOLVED FIXED
Product: SB Touch
Classification: Unclassified
Component: UI
: unspecified
: PC Other
: -- normal (vote)
: 8.0.0
Assigned To: Wadzinski Tom
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-26 15:57 UTC by Weldon Matt
Modified: 2009-09-08 09:24 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments
current implementation (134.41 KB, image/png)
2009-05-26 15:57 UTC, Weldon Matt
Details
correct implementation (134.81 KB, image/png)
2009-05-26 15:57 UTC, Weldon Matt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Weldon Matt 2009-05-26 15:57:07 UTC
Created attachment 5274 [details]
current implementation

Screenshots attached.

This might be a duplicate bug, but I looked and looked and can't find it.

On screens that have menu items AND supporting text, the menu items should always visually be aligned into a "slot" where the menu items would normally be located.  Right now they are offset based purely on the height of the supporting text.

This is bad aesthetically, and this was originally filed as an MP bug (which is why I searched for it) that never got fixed. 

But there are upcoming screen templates, and some existing ones (like 10-foot UI screens) where the positioning/alignment of these list items is critical and is NOT simply an aesthetic problem.  This needs go get fixed.

"Current" and "correct" screen comps are attached.

The solution: Don't know how this would be coded, but when supporting text pushes menu items down, those menu items need to "snap" into the next available normal menu-item position.  In other words, round to the nearest x pixels, where x is the height of a menu item.
Comment 1 Weldon Matt 2009-05-26 15:57:48 UTC
Created attachment 5275 [details]
correct implementation
Comment 2 Blackketter Dean 2009-05-27 12:19:17 UTC
Matt: We need to design this template to allow for more choices than fit on the screen.  In that case do you really want to snap the nearest item down?
Comment 3 Weldon Matt 2009-05-27 12:32:06 UTC
Dean: yes.  This has zero impact on the number of list items that can fit on a screen.  The currently available space on the bottom of the screen in the "current implementation" example is not large enough for a list item.

In the example shown, there is room for 2 list items in both cases.
Comment 4 Blackketter Dean 2009-05-27 15:01:32 UTC
Got it.  I was thinking that having some indication that there are
additional items below the bottom of the screen by showing a fractional item
would make sense.



On Wed, May 27, 2009 at 12:32 PM, <bugs@bugs.slimdevices.com> wrote:

> https://bugs-archive.lyrion.org/show_bug.cgi?id=12171
>
>
>
>
>
> --- Comment #3 from Weldon Matt <mweldon@slimdevices.com>  2009-05-27
> 12:32:06 ---
> Dean: yes.  This has zero impact on the number of list items that can fit
> on a
> screen.  The currently available space on the bottom of the screen in the
> "current implementation" example is not large enough for a list item.
>
> In the example shown, there is room for 2 list items in both cases.
>
> --
> Configure bugmail: https://bugs-archive.lyrion.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
Comment 5 Weldon Matt 2009-05-27 15:14:06 UTC
We don't have room for that luxury - also, that's what the scrollbar is for...
Comment 6 Blackketter Dean 2009-05-27 16:27:42 UTC
I'm not sure what "room for that luxury" means.  I understand the cosmetic implications in the wireframes you posted, but I suspect that you have a more serious problem that you are considering for other skins.  No?
Comment 7 Weldon Matt 2009-06-09 15:30:04 UTC
It looks (far, far) cleaner (both your designers are begging for this :-), plus there is an interaction issue with single-down remote presses and the baby boom scroll wheel (which "snaps" to certain positions - it's digital, not analog, if that makes sense).  We need the screen design to reflect this.
Comment 8 Richard Titmuss 2009-06-22 13:35:39 UTC
Tom, you've done this now?
Comment 9 Wadzinski Tom 2009-06-23 08:08:46 UTC
fixed with r6152, r6161, r6168