Re: Review Request: --hard_coded_colors in kalarm

[Celeste Lyn Paul]

> On 2009-08-11 23:16:35, David Jarvie wrote:
> > This seems a sensible idea. The colours are ok except for the archived alarm colour, which is quite similar in the default KDE colour scheme to the disabled alarm colour. They need to be clearly distinct by default since disabled and archived status are very different.
>
> Matthew Woehlke wrote:
>     It is? It should be purple (#644A9B) versus gray (#888786). Semantically speaking, VisitedText is best.
>    
>     If not Visited, what would you use?
>
> David Jarvie wrote:
>     I don't really care how the colour is classified, since there isn't one defined as "archived alarm". The important thing is that it's clearly different from the disabled alarm colour.
>
> Matthew Woehlke wrote:
>     I, however, care about correct semantic use of our color roles (and I also feel that the difference between #644A9B and #888786 is sufficient).
>    
>     As this deals with Usability, anyone else want to comment?

Screenshot please? David is concerned that purple and gray might not be visually distinct enough, and maybe there isn't enough of a difference in contrast.


- Celeste Lyn


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1288/#review1989
-----------------------------------------------------------


On 2009-08-12 00:48:33, Matthew Woehlke wrote:

>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1288/
> -----------------------------------------------------------
>
> (Updated 2009-08-12 00:48:33)
>
>
> Review request for usability and David Jarvie.
>
>
> Summary
> -------
>
> Hard-coded colors are Evil (bad Usability, bad Accessibility, and just plain bad... not to mention not very aesthetic in this case IMO). This removes the major hard-coded colors in KAlarm (default alarm colors, colors in the alarm list), the latter of which are especially bad as they can be illegible in some color schemes.
>
> ...but there are others in at least eventlistmodel.cpp, messagewin.cpp, dbushandler.cpp and resourcemodelview.cpp. Depending on how motivated I feel, more patches might follow in the future.
>
>
> Diffs
> -----
>
>   /trunk/KDE/kdepim/kalarm/kalarmconfig.kcfg 1010227
>
> Diff: http://reviewboard.kde.org/r/1288/diff
>
>
> Testing
> -------
>
> built and ran, colors were okay as checked by viewing in Settings, New Alarm, and a disabled alarm.
>
>
> Thanks,
>
> Matthew
>
>

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

Celeste Lyn Paul wrote:
> Screenshot please? David is concerned that purple and gray might not
> be visually distinct enough, and maybe there isn't enough of a
> difference in contrast.

Okay. I hope you find it here :-). I will update the request tomorrow, I
*really* have to go, I am going to be late for an appointment...

(This is of course generally a crapshoot, since the relative contrast
will differ per color scheme.)

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
And now back to your regularly scheduled e-mail.


_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[David Jarvie-4]

On Wednesday 12 August 2009 02:04:25 Matthew Woehlke wrote:

> Celeste Lyn Paul wrote:
> > Screenshot please? David is concerned that purple and gray might not
> > be visually distinct enough, and maybe there isn't enough of a
> > difference in contrast.
>
> Okay. I hope you find it here :-). I will update the request tomorrow, I
> *really* have to go, I am going to be late for an appointment...
>
> (This is of course generally a crapshoot, since the relative contrast
> will differ per color scheme.)

Here is a screenshot of the two colours in the alarm list in KAlarm (the first
and third entries). There is some difference in colour, but not enough to be
acceptable.

--
David Jarvie.
KDE developer.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm


_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[Peter Gostelow]

On Wednesday 12 August 2009 01:04, Matthew Woehlke wrote:
> Celeste Lyn Paul wrote:
> > Screenshot please? David is concerned that purple and gray might not
> > be visually distinct enough, and maybe there isn't enough of a
> > difference in contrast.

Yes, it is a marginal case. The difference is obvious when the two colours are
compared, but perhaps not when you see only one or the other. Unfortunately,
I suspect the display affects colours as much as personal preference as it
does depend on colour separation and contrast.

I'd accept this only because there is some colour-scheme involved, in the
arbitrary case, I'd prefer a more distinctive colour. However, it appears the
issue is with the scheme, so a review of that may be beneficial.

Regards,

Peter
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[Celeste Lyn Paul]

Ah hah. OK. I agree with David about the purple color in the sense
that it isn't a good once. The contrast between the purple and the
gray is very low, and I think that is probably why David doesn't like
the proposed color. If the purple were something more like #800080 (or
something with more red and hue and less blue and white) it will be
better.


2009/8/11 David Jarvie <djarvie@...>:

> On Wednesday 12 August 2009 02:04:25 Matthew Woehlke wrote:
>> Celeste Lyn Paul wrote:
>> > Screenshot please? David is concerned that purple and gray might not
>> > be visually distinct enough, and maybe there isn't enough of a
>> > difference in contrast.
>>
>> Okay. I hope you find it here :-). I will update the request tomorrow, I
>> *really* have to go, I am going to be late for an appointment...
>>
>> (This is of course generally a crapshoot, since the relative contrast
>> will differ per color scheme.)
>
> Here is a screenshot of the two colours in the alarm list in KAlarm (the first
> and third entries). There is some difference in colour, but not enough to be
> acceptable.
>
> --
> David Jarvie.
> KDE developer.
> KAlarm author and maintainer.
> http://www.astrojar.org.uk/kalarm
>
> _______________________________________________
> kde-usability mailing list
> kde-usability@...
> https://mail.kde.org/mailman/listinfo/kde-usability
>
>

--
Celeste Lyn Paul
KDE Usability Project
KDE e.V.
www.kde.org
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

Celeste Lyn Paul wrote:
> Ah hah. OK. I agree with David about the purple color in the sense
> that it isn't a good once. The contrast between the purple and the
> gray is very low, and I think that is probably why David doesn't like
> the proposed color. If the purple were something more like #800080 (or
> something with more red and hue and less blue and white) it will be
> better.

I still don't have a problem with that screenshot.

Anyway, it's entirely dependent on the color scheme (e.g. on Wonton
Soup, VisitedText is medium-bright blue). What would you use that is
different and isn't semantically wrong?

(An alternative option would be to use background color either instead
or in addition for archived alarms; not sure how much technical work
that is...)

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
ESIG: .sig file not available

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[David Jarvie-4]

On Wed, August 12, 2009 4:21 pm, Matthew Woehlke wrote:
> Celeste Lyn Paul wrote:
>> Ah hah. OK. I agree with David about the purple color in the sense
>> that it isn't a good once. The contrast between the purple and the
>> gray is very low, and I think that is probably why David doesn't like
>> the proposed color. If the purple were something more like #800080 (or
>> something with more red and hue and less blue and white) it will be
>> better.
>
> I still don't have a problem with that screenshot.

I have to disagree. If only one of the two statuses was visible in the
list (so that the two different colours weren't visible for comparison),
the user might well have to think about it to decide which type it was.
Given that KAlarm only displays 3 statuses in total - normal, disabled and
archived - it seems really unnecessary to make two of them look so similar
when there is such a wide range of colours to choose from.

> Anyway, it's entirely dependent on the color scheme (e.g. on Wonton
> Soup, VisitedText is medium-bright blue). What would you use that is
> different and isn't semantically wrong?

The fact that the *default* KDE colour scheme has this problem means that
some alternative has to be found. I'm not convinced by the argument that
it has to be semantically the right colour if that means that people can't
readily distinguish between the two statuses. I prefer usability in
KAlarm's very limited colour scheme over semantic correctness.

> (An alternative option would be to use background color either instead
> or in addition for archived alarms; not sure how much technical work
> that is...)

That wouldn't be any great problem, but it seems overkill. All that is
needed is to have two contrasting colours to use.

--
David Jarvie.
KDE developer.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[David Jarvie-4]

On Wed, August 12, 2009 5:48 pm, David Jarvie wrote:
> On Wed, August 12, 2009 4:21 pm, Matthew Woehlke wrote:
>> (An alternative option would be to use background color either instead
>> or in addition for archived alarms; not sure how much technical work
>> that is...)
>
> That wouldn't be any great problem, but it seems overkill. All that is
> needed is to have two contrasting colours to use.

On second thoughts, the background colour is already used for other
purposes - the user can set colours for different alarm calendars so that
alarms belonging to different calendars can be easily distinguished in the
alarm list. So it has to be the foreground colour which is allocated for
the different statuses.

--
David Jarvie.
KDE developer.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

David Jarvie wrote:
> The fact that the *default* KDE colour scheme has this problem means that
> some alternative has to be found. I'm not convinced by the argument that
> it has to be semantically the right colour if that means that people can't
> readily distinguish between the two statuses.

Is it really *that* important? Both are inactive alarms for one reason
or another.

There is also the matter (should have remembered this sooner, sorry)
that using only color to convey information is considered bad form. If
the status is that important, there should be a column that says the status.

> I prefer usability in KAlarm's very limited colour scheme over
> semantic correctness.

But if you use, say, NegativeText, then the first thing that says to the
user is "there is something wrong with this alarm". If you use
ActiveText, then you are saying that archived alarms are more important
than active alarms (an alternative could be to use ActiveText or
PositiveText for current alarms, but now that probably needs to be
configurable also, plus that seems... excessive).

That leaves PositiveText, LinkText and NeutralText, the last of which I
feel confident you will make the same complaint. LinkText semantically
implies "new" rather than "old". I suppose you could argue that an
archived alarm is one that went off == good == PositiveText, but IMO
that's a stretch.

Using NegativeText for disabled might work, but again a disabled alarm
isn't "broken", and that's what NegativeText indicates.

 From a semantic perspective, VisitedText is clearly the most
appropriate; NeutralText or InactiveText would also be okay, but
NeutralText isn't going to jump out substantially more (maybe even
less), and to use InactiveText you would have to use something else for
disabled, and InactiveText is a clear semantic match for disabled.
Anything else (except LinkText which would be merely strange)
immediately conveys a wrong message to the user.

Apparently the question is, do we want to confuse the user by telling
them something that is wrong, or by making it a little harder to be sure
what we are telling them?

Personally I vote for VisitedText plus adding a status column.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
ESIG: .sig file not available

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[David Jarvie-4]

On Wednesday 12 August 2009 18:49:19 Matthew Woehlke wrote:

> David Jarvie wrote:
> > The fact that the *default* KDE colour scheme has this problem means that
> > some alternative has to be found. I'm not convinced by the argument that
> > it has to be semantically the right colour if that means that people
> > can't readily distinguish between the two statuses.
>
> Is it really *that* important? Both are inactive alarms for one reason
> or another.
>
> There is also the matter (should have remembered this sooner, sorry)
> that using only color to convey information is considered bad form. If
> the status is that important, there should be a column that says the
> status.

I think the problem here arises from the fact that KAlarm only uses 3 status
colours in its alarm list, whereas the KDE colour scheme is designed for far
more statuses. It also seems quite likely that the disabled colour is usually
easily distinguished from the visited colour by context - in html text,
disabled text isn't exactly a common feature, so there's no particular need to
have contrasting colours for these two statuses.

In KAlarm, circumstances are different, and it doesn't make sense to have
similar colours for the two statuses - reasonably contrasting colours will
make things much easier for users.

> > I prefer usability in KAlarm's very limited colour scheme over
> > semantic correctness.
>
> But if you use, say, NegativeText, then the first thing that says to the
> user is "there is something wrong with this alarm". If you use
> ActiveText, then you are saying that archived alarms are more important
> than active alarms (an alternative could be to use ActiveText or
> PositiveText for current alarms, but now that probably needs to be
> configurable also, plus that seems... excessive).
>
> That leaves PositiveText, LinkText and NeutralText, the last of which I
> feel confident you will make the same complaint. LinkText semantically
> implies "new" rather than "old". I suppose you could argue that an
> archived alarm is one that went off == good == PositiveText, but IMO
> that's a stretch.
>
> Using NegativeText for disabled might work, but again a disabled alarm
> isn't "broken", and that's what NegativeText indicates.
>
>  From a semantic perspective, VisitedText is clearly the most
> appropriate; NeutralText or InactiveText would also be okay, but
> NeutralText isn't going to jump out substantially more (maybe even
> less), and to use InactiveText you would have to use something else for
> disabled, and InactiveText is a clear semantic match for disabled.
> Anything else (except LinkText which would be merely strange)
> immediately conveys a wrong message to the user.
>
> Apparently the question is, do we want to confuse the user by telling
> them something that is wrong, or by making it a little harder to be sure
> what we are telling them?
>
> Personally I vote for VisitedText plus adding a status column.

I would be very reluctant to clutter the interface by adding another column.
There are after all only 3 statuses, so it won't take a user long to learn
what the colours mean - alarms can only be disabled by specific user action
while the alarm list is displayed, so there is immediate feedback as to what
the disabled colour means. And the only way that archived alarms will ever be
displayed is when the user chooses to display them via the menu - again, it
should be evident at that moment what the significance of the archived colour
is.

So, if the general KDE colour scheme is not suitable for KAlarm because the
colour roles which matter lack contrast, then I'm afraid that some other means
of allocating colours is needed. I'm quite happy to adopt your proposal to
abolish hard coded colours as defaults, but I'm not prepared to have two of
the status colours being quite similar to each other when there are only 3
colours needed in total.

Note: I'm now subscribed to kde-usability.

--
David Jarvie.
KDE developer.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[Oswald Buddenhagen-4]

On Wed, Aug 12, 2009 at 05:55:33PM +0100, David Jarvie wrote:
> On second thoughts, the background colour is already used for other
> purposes - the user can set colours for different alarm calendars so that
> alarms belonging to different calendars can be easily distinguished in the
> alarm list. So it has to be the foreground colour which is allocated for
> the different statuses.
>
well, actually, you could also use a patterned background (try opening
multiple files with qt linguist, some of them read-only).

disclaimer: i do not endorse any particular option, i'm just adding to
the confusion. :D
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[David Jarvie-4]

On Thu, August 13, 2009 10:18 am, Oswald Buddenhagen wrote:

> On Wed, Aug 12, 2009 at 05:55:33PM +0100, David Jarvie wrote:
>> On second thoughts, the background colour is already used for other
>> purposes - the user can set colours for different alarm calendars so
>> that
>> alarms belonging to different calendars can be easily distinguished in
>> the
>> alarm list. So it has to be the foreground colour which is allocated for
>> the different statuses.
>>
> well, actually, you could also use a patterned background (try opening
> multiple files with qt linguist, some of them read-only).
>
> disclaimer: i do not endorse any particular option, i'm just adding to
> the confusion. :D

Yes, bring on the confusion! Alarms are old hat. Let's transform KAlarm
into a graphical demonstration platform. ;)

--
David Jarvie.
KDE developer.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

David Jarvie wrote:
> I would be very reluctant to clutter the interface by adding another column.
> There are after all only 3 statuses, so it won't take a user long to learn
> what the colours mean

You are assuming here that the user has color vision :-). As I
understand it, using only color is bed because some users may have total
color blindness. Rare, sure, but even limited color blindness may make
it difficult to differentiate based on color, and that's /common/ (IIRC
5% or more of the population).

> So, if the general KDE colour scheme is not suitable for KAlarm because the
> colour roles which matter lack contrast, then I'm afraid that some other means
> of allocating colours is needed.

If you have (or, if anyone has) a better idea that doesn't involve
misrepresenting something, I'm all ears.

(Part of the problem is that, as I know from kcalc, you're talking about
something that needs more code than a single expression, and that can be
hard to put in a kcfg.)

In a way I would prefer to fiddle with the default color scheme to make
Visited and Inactive 'more different', but I'm not sure that would
actually work for anything other than new distro installs.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
ELANG: input is in wrong language (please use English on English lists)

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

On Thursday 13 August 2009 18:43:50 Matthew Woehlke wrote:

> You are assuming here that the user has color vision :-).

not working in sunny environment, not old, etc etc. :-) Besides, poor
quality of anything that has to be read is causing also problems with
eyes.

> > So, if the general KDE colour scheme is not suitable for KAlarm
> > because the colour roles which matter lack contrast, then I'm
> > afraid that some other means of allocating colours is needed.
>
> If you have (or, if anyone has) a better idea that doesn't involve
> misrepresenting something, I'm all ears.

Icons?

Cheers,
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[David Jarvie-4]

On Thu, August 13, 2009 5:43 pm, Matthew Woehlke wrote:

> David Jarvie wrote:
>> I would be very reluctant to clutter the interface by adding another
>> column.
>> There are after all only 3 statuses, so it won't take a user long to
>> learn what the colours mean
>
> You are assuming here that the user has color vision :-). As I
> understand it, using only color is bed because some users may have total
> color blindness. Rare, sure, but even limited color blindness may make
> it difficult to differentiate based on color, and that's /common/ (IIRC
> 5% or more of the population).

When only 3 colours are needed, even a completely colour blind person
should be able to distinguish between suitably chosen ones - if they
appeared as black, mid grey and light grey.

--
David Jarvie.
KDE developer.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[Peter Gostelow]

On Friday 14 August 2009 08:23, David Jarvie wrote:

> On Thu, August 13, 2009 5:43 pm, Matthew Woehlke wrote:
> > David Jarvie wrote:
> >> I would be very reluctant to clutter the interface by adding another
> >> column.
> >> There are after all only 3 statuses, so it won't take a user long to
> >> learn what the colours mean
> >
> > You are assuming here that the user has color vision :-). As I
> > understand it, using only color is bed because some users may have total
> > color blindness. Rare, sure, but even limited color blindness may make
> > it difficult to differentiate based on color, and that's /common/ (IIRC
> > 5% or more of the population).
>
> When only 3 colours are needed, even a completely colour blind person
> should be able to distinguish between suitably chosen ones - if they
> appeared as black, mid grey and light grey.

The point is, kalarm is only providing one feedback channel, where
accessibility advocates multi-channel. The attention icon (!) could be more
informative, for example.

If kalarm is using unusual textual representation (such as archive), I suggest
a mapping of kalarm's textual representation to the standard. A disabled
alarm, for example, does not require a disabled text colour. Either/both
colour/s can be changed.

Or, take a base colour (from the current scheme) and generate two contrasting
colours from it. Since archive and disabled are not represented in the
standard scheme, there is a strong case for creating your own, but relative,
rather than absolute.

Regards,

Peter
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[David Jarvie-4]

On Fri, August 14, 2009 1:23 pm, Peter wrote:

> On Friday 14 August 2009 08:23, David Jarvie wrote:
>> On Thu, August 13, 2009 5:43 pm, Matthew Woehlke wrote:
>> > David Jarvie wrote:
>> >> I would be very reluctant to clutter the interface by adding another
>> >> column.
>> >> There are after all only 3 statuses, so it won't take a user long to
>> >> learn what the colours mean
>> >
>> > You are assuming here that the user has color vision :-). As I
>> > understand it, using only color is bed because some users may have
>> total
>> > color blindness. Rare, sure, but even limited color blindness may make
>> > it difficult to differentiate based on color, and that's /common/
>> (IIRC 5% or more of the population).
>>
>> When only 3 colours are needed, even a completely colour blind person
>> should be able to distinguish between suitably chosen ones - if they
>> appeared as black, mid grey and light grey.
>
> The point is, kalarm is only providing one feedback channel, where
> accessibility advocates multi-channel. The attention icon (!) could be
> more informative, for example.

The attention icon wouldn't be appropriate to indicate these statuses - it
is already used in any case for other purposes.

> If kalarm is using unusual textual representation (such as archive), I
> suggest
> a mapping of kalarm's textual representation to the standard. A disabled
> alarm, for example, does not require a disabled text colour. Either/both
> colour/s can be changed.
>
> Or, take a base colour (from the current scheme) and generate two
> contrasting
> colours from it. Since archive and disabled are not represented in the
> standard scheme, there is a strong case for creating your own, but
> relative, rather than absolute.

After the discussions on this topic, that is the solution I would favour.
For disabled alarms, I'd rather use the disabled colour from the standard
scheme, but generating a colour for archived alarms seems the only
satisfactory way to get a reasonable contrast.

--
David Jarvie.
KDE developer.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

Peter wrote:
> Since archive and disabled are not represented in the standard
> scheme, there is a strong case for creating your own,

Pardon?

Inactive Text: Second color; for example, comments, items which are old,
inactive *or disabled*.
(Emphasis added)

Visited Text: Fifth color; used for (visited) links. As with LinkText,
may be used for clickable *items that have been clicked, or otherwise
accessed, already*. May also be used *to indicate "historical" (i.e.
"old") items/information*, especially if InactiveText is being used in
the same context to express something different.
(Emphasis added)

We didn't go the route of every possible color being centrally
configurable, but it /is/ the intent that KDE applications should prefer
using a color from the KDE core scheme that is reasonably close to
semantically correct for the usage categories covered... and until
someone presents me with rational evidence to the contrary, I will argue
until I am blue in the face that the above *are* good semantic matches
for KAlarm's archived and disabled. (InactiveText especially, since
David has made it clear in private mail that the semantics he wants for
disabled are the same as the semantics InactiveText is meant to carry.)

I also fail to see how you can argue that an alarm that occurred in the
past does not count as an obvious generalization of 'an item that has
been accessed already'.

I'm really disappointed that I seem to be the only one that cares about
consistent desktop-wide semantics.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
  ,= ,-_-. =.    Freedom to Use
((_/)o o(\_))  Freedom to Examine
  `-'(. .)`-'  Freedom to Share
      \_/     Freedom to Improve

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[David Jarvie-4]

On Fri, August 14, 2009 5:17 pm, Matthew Woehlke wrote:
> I'm really disappointed that I seem to be the only one that cares about
> consistent desktop-wide semantics.

I would be quite happy to use the semantically correct colours if the ones
required were more easily distinguished from each other and therefore
practical from the user's point of view. But unfortunately they aren't.
(Perhaps, as I suggested before, because Disabled and Visited in html will
normally be readily distinguishable by context, so that having colours
which are somewhat similar isn't a disadvantage?)

--
David Jarvie.
KDE developer.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

On Friday 14 August 2009 18:46:33 David Jarvie wrote:

> On Fri, August 14, 2009 5:17 pm, Matthew Woehlke wrote:
> > I'm really disappointed that I seem to be the only one that cares
> > about consistent desktop-wide semantics.
>
> I would be quite happy to use the semantically correct colours if
> the ones required were more easily distinguished from each other
> and therefore practical from the user's point of view.

If I understand correctly colors can be changed by user, they are not
hardcoded. And relying solely on colors is wrong direction when you
talk about UI.

Cheers,
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability