Is this a "this is what we're going to do", or are we still open to discussion? I really liked the font scaling, what's the issue?

It's a "let's look at it and see if it works."  (Some) folks are complaining that the text size is too small/unreadable at arm's length.  

I personally feel that there are hard limits to how much we can really do here - the one non-radical option was to increase the size of the non-selected text.  If it doesn't really help substantially, we can revert back to the present version.

Yeah, I read that... the other suggestion was to move from 4 items to 3 items in a menu. I'm very opposed to that.

I'll change the non-selected text size, but IMO it's really helpful to have _something_ scale on the selected item to give a visual clue beyond the selection box. We've already pulled back on icon scaling, so the text is the logical choice.

text scaling removed, r6393. After viewing it, I'm still not in favor of this change. Would like to hear feedback from others on this, but I think this is the wrong direction.

Hm, I think the larger selected text was a good solution, but I think all the text, especially the selected text, needed to be scaled up.

Why are we equalling out the size?

Why no reference screens here?

Created attachment 5413 [details]
textlist - all text 18px

What about making the selected item 20 or 21px?

Created attachment 5414 [details]
textlist - scaling effect selected 21px, non 18px

I think that looks pretty swell!  Reactions?

On Jul 6, 2009, at 7:31 PM, bugs@bugs.slimdevices.com wrote:

> https://bugs-archive.lyrion.org/show_bug.cgi?id=12704
>
>
>
>
>
> --- Comment #9 from ndijulio <noah@bould.com>  2009-07-06 19:31:20 ---
> Created an attachment (id=5414)
> --> (https://bugs-archive.lyrion.org/attachment.cgi?id=5414)
> textlist - scaling effect selected 21px, non 18px
>
> -- 
> 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.

It looks better than I thought, but I'm still tentative.  This is a 1-liner with no icon.

I'd like to see the "worst-case."  Album list.  Album art, 2 lines of text...

I'm one of the ones complaining :-)  I have pretty good acuity, and the text is very difficult for me to read at arms length -- the distance from my pillow to bed-stand).

I understand there's a tradeoff here, but I see a *ton* of wasted space on the old screen that can be used to increase readability.

I too have a hard time telling which item is selected due to the subtle highlight treatment.  The make-the-selected-text-larger really doesn't work for me.  It's a little like the mouse rollovers on some web pages.  It breaks my mental model of how selections should work.  ( I don't see it on any other products, except the OSX dock, and in that case it works a little better because it looks like a magnifying glass is rolling over the items -- something my brain can grok.)

The attachments in this bug look much better, but I need to work with it for an evening on the real product to know how I feel for sure.

-C

Created attachment 5415 [details]
Jive templates using 18/21px

Created attachment 5416 [details]
Baby templates using 18/21px

The largest negative trade-off will be on the Jive re-skin (assuming the font size, padding, etc. is the same for both devices).  FWIW: The Jive UI can withstand smaller font sizes as it is a handheld device...

Is there a minimum number of characters people are willing to have prior to  scrolling?

Ex. 15-20 characters (including ~4 spaces)

Jive doesn't need the scaling in this case, I think.

The main question is the font size for Jive vs. Baby and whether they need to be the same.  I would recommend that Jive remain non-15px and sel.-18px.  The original skin use 15px and an inverted color scheme.  I don't see any reason to go larger than 15-16px especially for non selected characters.

The scaling is another issue.  It seems if we are scaling text on 2 devices that the behavior would be carried over to Jive, no?

In response to Caleb:

In fairness to us designers, the scaling-when-selected design style is actually becoming much more conventional.  Look closely and you'll see it's starting to show up all over the place.  Hulu Desktop, the Nintendo Wii interface, a lot of Netflix's on-demand implementations, Google Android on HTC, and tons of other places.  And yes, it's been a part of Mac OS for many years now.  Increasing the size of the selected item makes it the center of attention - i.e. "selected."

I'm all for increasing readability, but I disagree that there is a *ton* of wasted space - look at the Jive examples with album art and the second line of text and you'll get a better sense of the true space constraints we have.

Increasing the font size too much cuts off the number of characters that display at any given time, making it less and less likely that you'll be able to read any full words when looking at a menu of items.  So by solving one readability problem you're just creating another readability problem.

Finally, This is a 1 1/2 x 2 - inch screen!!!!!!  The fab4's screen has 2.6 times the surface area, and we've been staring at it for months.  So yes, the transition to the baby boom's screen, by comparison, is going to feel a bit jarring to us, and maybe a bit underwhelming in terms of viewing area.  Them's the breaks...

One other thing to mention is that the Logi corp. website is now using a scaling effect for a majority of their mouse overs.  I have yet to see how corp. is dealing with large lists, however this is a nice alignment/consistency with the mothership...

>I'm all for increasing readability, but I disagree that there is a *ton* of
>wasted space - look at the Jive examples with album art and the second line of
>text and you'll get a better sense of the true space constraints we have.

Ah, fair enough.  I wasn't considering the 2nd line of text.  

>Increasing the font size too much cuts off the number of characters that
>display at any given time, making it less and less likely that you'll be able
>to read any full words when looking at a menu of items.  

Yeah, I know.  That's the tradeoff.  Readability vs. readability :-)    I didn't mean to be too critical.  Baby has a little farther nominal distance than Jive, so I think we need to increase font size.   That's all I really needed to say -- it's up to y'all to figure out what's feasible/reasonable/possible/good-looking.

-C

Ah, the one other comment I do have about the text scaling is that when you actually mouse over an item, perhaps it was all readable in the small font, but then some of it disappears (gets truncated) as soon as you select it.  I think that's really what boggles my brain. 

-C

We should design the UI appropriate to the physical screen size, position and controls. Reuse when apprpriate and build on what we have as needed. 

Baby's screen is generally further away (sometimes much) from the user's eyes, so it needs a boost of text size and more visible selection highlight.

This bug has been identified as one that may not be required for MPQ since it now seems clear that MPQ and MP firmwares will be different.  Please comment if you disagree with this assessment.  Thanks!

What's my final instruction on what to do here? I've removed the scaling from baby and made everything 18px, but I don't think that should be the final solution.

Weldon, yours for a decision.

per discussion and full consensus from Weldon, Noah, and myself, r6442 makes this an 18/21px scaling

I think this looks great, but I miss having the icon get larger.  Can  
we get that back in?

Sorry Dean, we're not doing icon scaling. There are numerous engineering constraints on this

1. we don't have on-device rescaling
so given that constraint,
2. We'd have to request two sets of thumbs for album lists from SC, one for selected and one for not. That would double the size of our artwork cache, which is a no-go, esp. on controller 
3. creating two sizes of icons for home menu items doubles the impact on firmware size

the skin is another problem...the icons are delivered as individual icon styles, and changing the icon for the selected item ends up being very convoluted and specific for a given window style (e.g., s.text_list.selected.hm_settingsAdvanced when s.hm_settingsAdvanced defined the original icon). That's not an insurmountable problem, but I wouldn't say it scales _well_. To do this right I think we'd need to evaluate a new way of styling custom icons in menu items.

Richard, Noah and I all discussed this at length and decided that we would not pursue icon scaling on the left.

fyi, we are scaling icons on the right when selected (right arrow, wifi strength, radio/checkboxes)

We do have on-device rescaling, I used it in the screen test applet with the zoom method:

		srf = Surface:loadImage("applets/TestDisplay/Face.jpg")
		local wi,hi = srf:getSize()
		srf = srf:zoom( w / wi, h / hi, 1)

My expectation would be that we only request the single size and then when the item is selected, it's zoomed.  At that size it should be very fast and have no visible performance impact.

sorry, I misspoke. We have no current method of doing rescaling an icon dynamically _in the skin_.

retarget for 7.4, assign to Richard for comment on doing scaling within the skin, then it can go back to me.

also note that the implementation of SC-based album thumb lists will likely be different than home menu items.

Noah has weighed in that it's all or nothing on icon scaling, which I would agree with...

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.

This is not a P1. It will require some redesign of the skin to allow dynamically resized images, and we should plan this in for a later release.

Noah, please comment on how important you think this is visually.

Given engineering constraints and schedule I am moving to wont'fix.  The idea of scaling the thumbnail icons on the left (apps, albums, etc.) is not a requirement for the UI to function.  Weldon, Ben, and myself have all weighed the options.  Long story short, no action nec. at this time.