[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:       "David Jarvie" <djarvie () kde ! org>
Date:       2009-08-18 8:56:30
Message-ID: 72efc37cd4b22394ed9b9a8eefdd8fad.squirrel () www ! sensical ! net
[Download RAW message or body]

On Tue, August 18, 2009 4:06 am, Peter wrote:
> On Monday 17 August 2009 16:37, Matthew Woehlke wrote:
>> Peter wrote:
>> > [A]n alarm does not refer to the user, but an event in time.
>> >
>> > Again, kalarm uses archived items to classify those items that have
>> > triggered, it does not suggest the user has done anything, or that the
>> > item is subject to time (i.e. new or old).
>>
>> Has been triggered, has been activated, has been visited...
>
> An alarm item refers to an event in time, not user activity. Combining the
> two concepts extends the WIMP colour scheme beyond its limits, imho.
>
>>
>> Wearing my user hat, I fail to see why there should be a distinction.
>
> While the current colour scheme provides time related colours, the
> semantics
> are not rich or subtle enough for time related apps, such as calendars,
> todos, and alarms. Although we can reconcile the semantic differences
> between
> alarms and coloured text, it seems more reasonable to provide a time
> related colour scheme independently of the WIMP semantics.

In KAlarm, the colours are used to indicate status at least as much as any
time quality. Active alarms, if they are recurring, may have first
triggered a long time ago, while archived alarms may have only triggered
once a short time ago. It is the fact that they won't trigger again which
makes them archived. So archived/active status does follow from their LAST
trigger time, but it bears little relationship to their FIRST trigger
time. Also, their last trigger time can be determined by user action, i.e.
deletion of a still active recurring alarm.

> My argument is that a generated time related colour palette will provide
> better semantics. It may or may not be based on a scheme colour. In this
> way,
> neither David nor anyone else can hard-code colours 'because there isn't
> one defined as "archived alarm"'.
>
> My other concern is that if you force the semantics, you create
> unrealistic
> expectations in the mind of users. The plasma is a case in point, users
> expect it to behave like a window because it looks like one. If an alarm
> looks like inactive text, some users will expect the alarm to behave like
> it.

A disabled alarm is inactive in the sense that it will not trigger. You
can still click on it to view or edit it. Certainly to my mind, the
disabled or inactive colour is the appropriate one.

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

_______________________________________________
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]