Agreed.  The artwork should be updated so that the off state for the shuffle and repeat is dimmed and not pure white.

I'd have to see the glowing concept, but I don' think this is consistent with the rest of our UI.

Defer to Noah on this one, but the dimmed version might be a bit tricky since we also need an easy-to-see state for "disabled" buttons (skip button on pandora after skip limit is reached...)

We need to be careful here.  Currently "dimmed" (RGB 104,104,104) means not available or disabled.  Example: Internet Radio template.

The glowing effect is not something that is in the current implementation in the UI.  It was in an original iteration, however, it was eventually removed.

Let me noodle on this...

Why not just hide unavailable buttons, why do we need a dimmed state?

(In reply to comment #4)
> Why not just hide unavailable buttons, why do we need a dimmed state?

For shuffle and repeat, I'd prefer a unique "off" icon.  Whether that is something with a red diagonal line through it or whatever, I don't know.

Anecdotally, I will admit the following:

As an SBC user, if I notice a blue icon from the corner of my eye, I associate "blue icon = bad".

We will play around with this, but until we get more than just anecdotal user data, this might end up as a "wontfix."  We have a round of CAT testing approaching, and I'll try to make sure this gets looked at...

FWIW, Removing inactive buttons won't really work - the primary case for this behavior is reaching your skip limit on pandora/lastfm/slacker etc.  Having the button simply disappear is a strong (and bad) break from design conventions.

Oh and technically it's teal, not blue ;-).

Looking at Ben's recent work with the thumbs up/down versions of NP, he's hidden the REW button instead of dimming it and I think it is successful as the way to indicate that this function is not available or not appropriate

This implies that the dimmed state would mean OFF and the hidden state means NOT AVAILABLE.  

We don't use (afaik) dimmed to mean unavailable anywhere else in the user interface, so there is no inconsistency added.

Adding an extra bright glow or color is visually distracting and does not sufficiently distinguish the meaning.

I do realize that some desktop system dim out buttons or words to indicate NOT AVAILABLE, but this seems unnecessary in our UI.

So, let's try it this way and see if it works any better.  Do you have all the assets you need?

I'm not a UI designer, so I'll resist the temptation to delve into the minutia - except to note that my 3 suggested solutions are not mutually exclusive.

My two cents is that Mark's suggestions are spot-on the correct approach, but like Mark, I am not a UI designer. I do know that white looks wrong as "off" to this user.

Dean, what do you mean by "let's try it this way"? Having dimmed instead of white icons for the off state in repeat and shuffle? If that's the case, then I do _not_ have assets for that. Please reassign to Noah if that's what you meant.

Dean, I think you misunderstand the problem space a bit.

It's correct to not have a button if it won't/can't be used at all on the screen.  So, for example, it's correct to not have a rewind button for Pandora.

The problem I was referring to is where INITIALLY the button is usable, but then later has a state where it needs to be disabled, and then might reappear again.  i.e. the fast forward button on Pandora.

Example: skip limit reached.  I hit the ff button x times, then suddenly it won't/can't work anymore.  Then an hour or so later it's enabled again.  Removing the button entirely, then having it show up again suddenly, just won't work well.  Therefore there needs to be a "disabled" state for the ff button on Pandora.  Currently Noah is (correctly I think) using a grayed-out version of the button for this.

The above case (and others like it) means that grayed-out = disabled (i.e. not clickable).  We can't / shouldn't use the same treatment for something that is "off" - "off" is different from "not clickable."  And therein lies the problem with trying to use a grayed-out button to show the "off" state.

I defer to Noah for proposing an exact solution to this, but I don't think grayed-out is the answer.

Separately from this, I will reiterate my opinion that I'm not convinced this a problem that is easy to solve (the solution might be worse than the problem).

"Removing the button entirely, then having it show up again suddenly, just won't
work well."

Why not?

The original intent of this bug is that it is not intuitive that for shuffle and repeat, "bright white=off" and "teal=on".  Having icons appear and/or disappear will not solve this.  Perhaps we need a different bug for those issues.

Ben: in this case you want to always let the user know that the function (ff) exists, but that it's not available at the moment.  Removing the button entirely doesn't communicate this nearly as well as a disabled button.  The sometimes enabled/sometimes disabled case is different from the case where the button is never available on the screen in question (i.e. rewind on pandora).

Also, the effect of removing the button is much more jarring and heavy-handed.

(NOTE: Part of this really gets to basic best practices in design.  I'd be happy to talk more about this in-person at the onsite but I don't want to write a novel here).

As for Fletch's specific suggestions:

These are (in practical terms) really two suggestions, not 3.  The first 2 recommend changing the look of the "white" ("off") state of the buttons.  The last suggestion recommends changing the look of the "highlighted" (teal) state of the buttons.  Notes below.

1) Replace the white icons with something else that clearly communicate "off";

Of the 3 suggestions, this is the only one that I consider a real option.  I leave it to Noah to see if we can come up with something that works well.

2) Make the white icons more gray so that they appear "off";

Grayed-out currently means "disabled" (which describes a state of the actual button) which is quite different from "off" (which describes a state of the option you're toggling - shuffle, repeat etc). So unless we change the "disabled" state, this option is off the table.  These two states can't have the same treatment, or else we introduce a new (and bigger) design problem.

3) Make the blue icons "glow" so that they appear "on"

They're teal, not blue ;-).  This would do nothing to improve any potential user confusion IMO.  The problem (if there is one) is when the icon is white and looks just like the other icons.  If you have a concern with the aesthetics of glowing vs. non-gloving icons, that's a different issue.  But the color change of white-to-teal is clear enough, I think, to show that the button state has changed.

(In reply to comment #15)
> 3) Make the blue icons "glow" so that they appear "on"
> 
> They're teal, not blue ;-).  This would do nothing to improve any potential
> user confusion IMO.  The problem (if there is one) is when the icon is white
> and looks just like the other icons.  If you have a concern with the aesthetics
> of glowing vs. non-gloving icons, that's a different issue.  But the color
> change of white-to-teal is clear enough, I think, to show that the button state
> has changed.

OK, but to my eye, the "glowing teal effect" is exactly what the SC webUI player pane does and I have always found it to be quite intuitive.  Whatever the final resolution is should probably be back ported to SC.

Yes, I mean having dimmed icons meaning off.

-dean

On May 26, 2009, at 11:40 AM, bugs@bugs.slimdevices.com wrote:

> https://bugs-archive.lyrion.org/show_bug.cgi?id=12132
>
>
>
>
>
> --- Comment #11 from Ben Klaas <bklaas@slimdevices.com>  2009-05-26  
> 11:40:37 ---
> My two cents is that Mark's suggestions are spot-on the correct  
> approach, but
> like Mark, I am not a UI designer. I do know that white looks wrong  
> as "off" to
> this user.
>
> Dean, what do you mean by "let's try it this way"? Having dimmed  
> instead of
> white icons for the off state in repeat and shuffle? If that's the  
> case, then I
> do _not_ have assets for that. Please reassign to Noah if that's  
> what you
> meant.
>
> -- 
> 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.

I disagree with the premise of this bug.  Once you've pressed either shuffle or repeat and you've seen it light up in Logitech's lovely patented teal color, shouldn't you have figured it out by then???  The interface is the same as in the web interface and there have been no issues there.

If you want to make it more obvious, just change the two teal icons now used for 'shuffle songs' and 'repeat all' so that they have some additional image overlayed on them.  This way, the difference is not only in color, but the actual image displayed.  The plain image with no overlay is 'Off'.  I would suggest a music note on 'shuffle songs', same as that used in the 'repeat songs' icon.  For the the 'repeat all' icon, overlay a small lined rectangle that mimics the Playlist button.

Can we test this both ways if necessary?  Using 'dimmed' to display off does not work for touch.  The button must appear ACTIVE and dynamic.  It should say, "it's ok to touch me."  If we dim the artwork it will appear inactive and broken.  

Intuition is based on past experience and history with various products both good and bad. This is something we should test.  Are debating over color preference(teal) here or something more fundamental?

Ben-
You should have all the assets you need to make a change...

I actually agree wholeheartedly with Jim on this, as mentioned earlier.  Given the constraints we have on the design treatment, I feel that the current implementation is pretty reasonable.  Other solutions have been suggested, but most of them won't work for reasons already mentioned.

The designers got to this point for a reason.  At a certain point you have to trust us.  The design isn't broken - everything is perfectly functional.  The only "bug" here, if there is one, is that the default state of "shuffle" and "repeat" is white, just like the default state of "play," "ff" etc.  If someone doesn't "like" the look of it, that isn't a bug.  If it's genuinely confusing, then sure, that's a bug, but I haven't heard anyone in this thread express any actual difficulty in figuring out how the buttons work. 

As Jim mentioned, the behavior of shuffle/repeat states is clear the first time the user presses one of those buttons.  And no testing has really been done on this, so all opinions here are pretty subjective.  

Given our timeline and workload, and the fact that arguments on both sides are pretty subjective, this needs to be a wontfix. At the very least we should hold off on messing with this until after the feature freeze.

Ok, so it boils down to this.  We need treatments for the icons that mean:

On
Off
Unavailable

And our choices (so far) are:

White
Teal
Grey
Missing

Matt's been clear that he doesn't want "missing" to be used to indicate "Unavailable" and he wants to use Grey to indicate that.  Got it.

So the remaining question is: given that white and teal are not working to distinguish off and on, what treatments do we use?

To further complicate things, Shuffle and Repeat have multiple "on" states.

So, it seems to me that we need another color (half-white?) to indicate off or a unique icon (an arrow that doesn't loop back?).

Noah: Can we see a mockup of each approach?

"given that white and teal are not working to distinguish off and on, what treatments do we use?."

This is the main issue with this bug.  I don't agree that it's a "problem."  I will repeat my earlier comment.  No one in this thread actually had a problem figuring out what the buttons meant.  There was a claim that it wasn't "intuitive."  

We have a mechanism to test this - CAT testing.  My understanding is that we have another round coming shortly, and if our process works, we should be able to communicate to Seth to keep an eye out for this.

I'm all for Noah trying to come up with other approaches for this.  But I fail to envision a solution that would be superior to the current one, given the constraints.  Any other treatment could also be argued to be "unintuitive."

Created attachment 5277 [details]
winamp-WMP-itunes-iphone repeat/shuffle examples

Discussed with Dean.  This is a "wontfix."

Attached are screenshots of this behavior in 2 different Winamp Skins, itunes, iphone, and windows media player.

With the possible exception of WMP (they don't treat repeat as a "button" per se - it's in a different spot in the UI - and they partially gray out the icon), we are doing the conventional thing here.

By default, all the buttons have the same treatment.  Things that can be toggled show a visual change, either through color, icon, or both, once they have been clicked.

Take a close look.

Created attachment 5278 [details]
sc web ui with glowing versions of icons

It should be noted that the sc web UI is technically a "legacy design" at this point.  Also, I should note that I'm not at all opposed to glowing icons (many of the screenshots I showed had them).  But that wouldn't have solved the original bug.

(In reply to comment #26)
> It should be noted that the sc web UI is technically a "legacy design" at this
> point.  Also, I should note that I'm not at all opposed to glowing icons (many
> of the screenshots I showed had them).  But that wouldn't have solved the
> original bug.

I really don't want to waste your time (or mine) much further on what is a minor issue, but...

IMO, the glowing effect used by SC would solve the original bug.  It was my "option 3".

Wow, that image you posted is really interesting, Matt!

Some observations:

- WMP actually changes the icon, greying out part of the icon in the middle.  I'm not sure what that icon means, actually, but I think that using a Microsoft product for guidance is a bad idea. :)

- Winamp Default puts a little indicator LED in the button.  This seems like a throwback to the 80's and is too literal for our UI.

- iTunes takes the off icon and changes color and adds a glow (grey to blue with a blue glow)

- iPhone does the same as iTunes, not surprisingly

- Winamp Bento takes the off icon and adds a glow to it (i.e. grey to grey with a blue glow), kind of like we're doing in the SC web skin (see the second attachment, off-white to off-white with a teal glow)

So, what this makes me think is that we definitely should add a glow to indicate the on state, I think this will resolve the issue that Mark and I saw where the blue/white colors didn't really indicate on or off specifically.  A glow definitely does.  

I think that it makes sense for the glow to be teal, but I'm not sure if we should take a Bento/SC approach and add a teal glow to a white icon or the Apple approach and add a teal glow to a teal icon.  

Matt/Noah: What do you think?

Dean, just curious.  What do you mean in comment 21 by "half white" and how is that different from gray?

Created attachment 5297 [details]
Ref artwork - repeat/shuffle on states

Well, Matt has already closed this as WONTFIX but, FWIW, this is exactly what I meant by "glowing effect" and I like it.  And it's consistent with SC.

checked in Noah's update in r5959

Noah, I'm reopening because I'd like you to test and confirm that the icons are how you want them. I believe the repeat song and shuffle by album icons don't align correctly with the other two states.

Thanks Noah-- r5965 has the fix on those two icons. Moving to closed.

This bug has been fixed in the latest release of MySqueezebox.com (formally
known as SqueezeNetwork)!

If you are still experiencing this problem, feel free to reopen the bug with
your new comments and we'll have another look.