unity-design team mailing list archive

[Ed Lin <edlin280@xxxxxxxxx>]

On Wed, May 4, 2011 at 1:19 AM, Niklas Rosenqvist
<niklas.s.rosenqvist@xxxxxxxxx> wrote:
> "What you suggested is a far reaching, non-default behavior "option"
>  and I still fail to see the point of it."
>
> That is because you still haven't read the discussion...

I've read every mail of it, I think even twice, just to make sure I'm
not jumping to conclusions or misreading something.

> "I'm not sure that would work very well: the default launcher would end
> up this ugly grey strip since no programs are run when you first log
> on. As an user-selected option it might be ok though."
>
> In the very beginning of this discussion we made it clear that what you just
> said isn't the suggested behaviour.
....
>Please say that you finally can picture this and we can
> go on without you ranting on something we haven't even said?

You are quoting me without the context. To rephrase Evan Huus:
"It's broken but it's OK if it's just an option."
There I was explicitly NOT referring to the particular content of the
discussion but to the attitude towards options "in general". I'm fully
aware of how your mockup is intended and what the reason behind it is.
The remaining question was why you'd favor this particular workaround
to a cleaner and simpler solution.

> "What's wrong with adding a new simple glow effect option
>  in CCSM?"
> Because the background's are already quite illuminated and glows. You have
> to put things into perspective when picturing a solution. With even more
> glow it will just be adding more glow to the glow. With all the color and
> indicators such as counters and progress bars the whole launcher gets
> cluttered and more color just adds to the clutter. This way we can still let
> applications use their counters and progress bars without it cluttering up
> our view together with super glow and colours when we want to easily select
> an application.

These are little implementation details. A GNOME 3 style glow effect
with counters and such *on top* would works as far as I can tell.

> "Your feature request goes beyond a simple option, it introduces a
> completely new launcher behavior (it now can change on mouse hover),
>  and as I outlined already, it doesn't work too well."
>
> Why would that be a major problem? It opens when we hover different areas
> such as the "Ubuntu"-button or the left side of the screen. Changing
> appearance of an UI-element when hovered is one of the most basic ways in
> UI-design to tell the user that the current element can be interacted with.
> If you look at it almost every element you can interact with in Ubuntu
> changes appearance on hovering with the cursor. So why exactly would this be
> a problem with the launcher?

I already stated the problems a few mails up:

>You can't see what's running at a glance without hovering the
>launcher. Why? Does it make sense for the user? Does it increase
>usability? I doubt so, it's just for aesthetic reasons.

>Icons are completely desaturated, this makes finding what you are
>looking for more difficult. Only shape, not color is different, now
>imagine working on a glossy screen outdoors.
and what about hidden applications?
and what about diverging from the idea of making switching and opening
programs transparent to the user?

Another problem I failed to mention: if you focus the launcher by
hovering a mouse over it you probably are also hovering over an
launcher item, possibly an app icon. Is it running or just hovered?
Now you need to take clues from the background and arrow anyway. So
what was the point in the first place if the goal is quick, at a
glance information?

Changing an interface element on hover is expected, but you are
changing non-hovered elements as well. This behavior is going to
appear arbitrary to the user and you can bet people demanding yet
another option to set grayed out to always visible.

> Let me just point out that everyone who has responded to this idea has been
> very positive except for you.

It may look nice on a static screenshot but I have my doubts this will
work out in practice. The feedback so far is in no way representative
for the "majority of Users". Anyway, 6 people commented so far and
only 3 of them explicitly "liked" your grayed out mock-up. Your bug
report is was a bit overzealous too, it sounds like a some kind of
consensus was reached.

They way I see it you correctly identified a problem (running apps
with square icons are less distinguishable from non running apps) and
set forth to come up with an solution. Of course people will be
grateful for you finding and solving an issue. The problem really is
the next step: Finding the best solution.

Your proposal very much reminds me of the menubar hover discussion. In
this spirit your design is very consistent. Well done!

But more seriously, your solution looks like a quickly drawn hack,
it's convoluted and inconsistent.
In your screenshot you now have 3 redundant indicators for running
applications. If you think the gray bar looks stupid or ugly and
that's why it shouldn't look that way "normally" this isn't going to
change by making it hover only. It will still look the same, ugly or
strange. If you agree grey on grey has poor visibility and makes
finding the right icon too hard you don't introduce yet another
option. The simple answer is to make your proposed idea suck less,
i.e. by default only slightly desaturated icons. But then, do we still
need to change the launcher on hover at all?

I'm not 100% against your idea and I don't know the answers. All I'm
saying is that your idea isn't finished yet and there are several yet
unanswered questions remaining.