Alarm setting?

[Bernhard Reiter]

On Monday 20 September 2004 09:54, Reinhold Kainhofer wrote:
> On Monday 20 September 2004 08:32, Bo Thorsen wrote:
> > On Friday 17 September 2004 18:42, Reinhold Kainhofer wrote:
> > > I just read the kolab spec once again, and it seems that the alarm
> > > settings are very poor in the current version in cvs. All there is is
> > > one simple integer for specifying an alarm.
> > > Currently, korganizer already supports executing an application, and
> > > playing a sound in addition to a simple reminder dialog.

Sometime "less is more" can be helpful for the usability of the package.
You seem to consider a simple reminder being "poor".
Thinking about this, I am  usure if I agree.
The most important thing is, that I do get reminded as a users.
In reality I wand to be reminded differently depending on the context
not only of the appointment, but also about what I currently do
when the reminder reaches me. 
This cannot be decided within the event itself, but most consider
other circumstances.

I think that giving priorities (by categories) and the time of
the reminder and leave the rest for the surrounding application
is a sensible approach to the problem.

> > > However, I'm currently planning to extend korganizer to support
> > > multiple alarms, with possible settings for an alarm:
> > > -) type: reminder dialog (msg given by user), sound,
> > > application/script, maybe email (but that would require having a daemon
> > > running even when not logged in, so it's probably outside of
> > > korganizer's scop).
> > > -) repeating alarms
> > > -) Alarms also counted from the end of an incidence (or the start of a
> > > todo).

Those seem to be nice technical possibilities,
what about building them into KOrganizer interpreting the alarm
and the categories and not saving them in each event itself?
I do not see the use case to specify some of those actions, like sound and
actions for many alarms.

> > I also thought about this. But if you look at the "run an application"
> > alarm type, how would you expect that to work in a cross machine and
> > cross platform environment? Answer: Not reliably, at least.

The RFC even openly admits the security problem of an attached application,
which smells like bad design.

> > So the question is what to do about it. We might try and just save all
> > the things KOrganizer can do in the format. 

Saving this locally in KOrganizer seems a nice approach to me
which might improve the user experience of being reminded.
This is of course open to debate.
I feel that we should stop making a real interoperable
format as simple as possible because of the subcases.

> > However, Outlook usually
> > simply can not keep information like this between saving.

Outlook could perserve some tags, if that would make sense.

> Other calendaring applications like evolution also support multiple alarms,
> which are specified in rfc 2445. 

I see two things mentioned:
	- multiple alarms for one event
	- several types of alarms
the multuple alarms seem more important to me then the types,
but both seem to be too much if I look at rfc 2445 and will not help
users directly, but more confuse them.
If you ask me, leaving them out until we know if users really demand
them seems to be an improvement.

> I wouldn't like a message box "You can use
> multiple alarms, but please be aware that when using a Kolab server one
> other calendaring application (Outlook) does not support this. Do you
> really want this?" that much.

I assume that many coporate users  will just activiate the "Kolab compatible" setting
then then do not see any confusion advanced possibilities anymore
and get work done much faster with the interfaces.

> What's your current way to handle multiple email addresses and more then
> three phone numbers? We should probably do it in a similar way...

Outlook preserves them as far as I remember, this does not help the use case
much, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20040922/3a03f1ee/attachment.p7s>