[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: [KDE Usability] Review Request: --hard_coded_colors in kalarm
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2009-08-12 17:49:19
Message-ID: h5uvb0$i7j$1 () ger ! gmane ! org
[Download RAW message or body]

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@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]