Mocups of focus hints for panes

[Matthew Woehlke]

(Should we maybe start a new thread on -usability?)

Olaf Schmidt wrote:
> In the HCI working group, we already discussed adding additional colour roles 
> to kcontrol. We have worked out a suggestion that serves the needs of 
> artwork, usability and accessibility.
>  [snip]
> You can find an outdated version of the document here:
> http://amen-online.de/~olafschmidt/colors/colors.pdf

To comment on point 4, page 6 ("Most widget styles and window 
decorations use Qt functions for getting the colors for shadows or 
disabled elements."), did you see this thread I posted 
(http://lists.kde.org/?l=kde-devel&m=116499286902444&w=2) talking about 
the lack of standard ways to blend colors in KDE and the need for 
library functions to perform these operations?

Conversely, if a Qt function exists, it should be used. Part of the 
reason is that these methods should be as portable as possible to 
styles. How to achieve this is a pretty complex issue since you need to 
'play nice' with Qt.

(All following quotations are from the aforementioned PDF)
> Hard­coded colors values must never be used.

...and you would *THINK* people knew this! Alas, as we both know, this 
has been a problem for a loooong time. :-)

Have you considered that "150%" may be a better choice than "+2" for a 
font size? I almost want to say that a font size should be "the ____ of 
__ or ___%", where the blanks are 'larger'/'smaller', a point delta, and 
a percentage, but that's hard to implement. But having a way to specify 
a size as either a point size delta or a percentage seems like a good idea.

I think I would have to disagree with removing the title bar colors; 
users coming over from Windows expect to see these, and they provide a 
standard way of changing colors that many/most decorations will respect. 
I think ignoring a color is OK as long as the decoration does not 
implement its own custom color to fill a similar role. Removing these 
sounds to me like the opposite of the homogenization you are trying to 
achieve in other areas.

> It is recommended that the widget styles clearly mark the text focus
> using the focus colors and use the mouse­over color for hover effects.

Back on topic, the entire purpose of this discussion was to change "it 
is recommended that" to "it is required that the default behavior (which 
may be user-configurable) of". :-)

> It is important never to exchange foreground and background colors.

Just for the record, I personally find nothing wrong with exchanging 
color roles *as long as it is done consistently* (although since I am 
not color blind, I will accept that you may have a point there). For 
instance, variations of this are often used to indicate out-of-focus 
selections. If switching roles is being proscribed, then you should be 
sure this point is addressed.

> A small line or shadow must be drawn around the window in window
> frame text color (which defaults to black).

This is a ridiculous restriction that prohibits 'frameless' decorations. 
The default decoration should absolutely do it, but I rate nitpicking 
what decorations can and cannot do as starting to become excessive. At 
the very least, you need to /clearly/ state that the decoration may 
allow the user to turn this off.

> Either no window title gradient should be shown by default, or the
> color used for it must be a variation of the window title background
> color.

This is exactly why we have titlebar gradient colors. But decorations 
need to adhere to them.

> The option to override the website-­defined colors is very useful
> and should be extended to work with the current KDE system colors.

Please, oh PLEASE be the first browser to Do The Right Thing here! I 
*hate* websites that can't understand my colors are not 'black on white'.

(Say, where's that PDF "viewer" that lets me make annotations? ;-))

-- 
Matthew
"Braaaaaaaaiins!" -- Zombies