Alarm setting?

[Reinhold Kainhofer]

On Wednesday,  22. September 2004 12:58, Bernhard Reiter wrote:
> Sometime "less is more" can be helpful for the usability of the package.
> You seem to consider a simple reminder being "poor".

No, I don't think a simple reminder is poor. In fact, it's the most common way 
of alarms that users might want and use. But in some cases you want multiple 
reminders for an event. E.g. there was the example of a birthday, where you 
have one reminder a week before to remind you to buy a present, and then one 
reminder on the birthday to call that person.

> The most important thing is, that I do get reminded as a users.

Yes, that's what alarms are all about, you know ;-) SCNR.

> 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.

Yeah, sure, we already plan to implement focus-follows-mind.... 
I think such context sensitive reminders would be impossible to implement, and 
further more quite confusing (some would say, it's bad usability if the same 
function does something different each time).

> 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?

Because such event-specific things can't be interpreted globally. Imagine that 
you have an exam supervision for a written exam. You're working on your 
computer while the students take the exam. 10 Minutes before the time is over 
you want to be notified so you can tell the students to read through their 
answers again and think of finishing.

Similarly, if you have a hard deadline for something, and you reserve some 
time in korganizer, you want to be reminded when you have only an hour left 
or so.

> I do not see the use case to specify some of those actions, like sound and
> actions for many alarms.

Email would be quite useful. E.g. at our department we have a weekly lunch 
meeting each wednesday noon. Every tuesday a reminder is sent out to the 
institute's mailing list. Currently that's done by a cron job, but if we 
shift the meeting (like we did already two times), the secretary needs to 
adjust the event in her calendar app, plus tell the sysadmin to adjust the 
reminder. If automatic email alarms are implemented, she could do this in the 
calendar.

Sound are a bit like toys, but you know how some people are: they like 
flashing and sounding things.

procedures are actually quite helpful. E.g. before an important meeting you 
can automatically run a script that extracts some statistics about the 
current status, etc. Or you can run a different reminder application. 
Another thing I can think of is time sheets: Each day, ten minutes before your 
shift is over, you can fire up you word processor/spread sheet/web browser, 
where you can enter the things you have done today, and how much time you 
spent on these.
And another use case is to send an sms: 
http://bugs.kde.org/show_bug.cgi?id=64095
That use case is actually similar to the email alarm type, only that it uses a 
different messaging protocol, for which you have to invoke an external 
application. In fact, email alarms could also be implemented as procedure 
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.

Nope, not reliably. But it's the same issue with attachments, too.

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

The scope of the RFC is not to make a specification that is absolutely 
fireproof, but rather it aims to give a specification for all possible things 
that one might like to do with a calendar. And for this, procedure alarms are 
an important thing. Of course, the RFC has to point out to the developers 
that they should think very thoroughly about how to implement procedure 
alarms without introducing security problems.

E.g. Evolution asks the user before executing the executable. 
And to quote the RFC: "While a very useful alarm capability, the PROCEDURE 
type of alarm SHOULD be treated by the "Calendar User Agent" as a potential 
security risk."

> > > 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.

Nope, KOrganizer will certainly save these things in the .ics file. I just 
wanted to let you know that korganizer will in the future support multiple 
alarms.

> 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.

These issues ARE demanded by the users:
Multiple alarms: bug #16493 (one of our oldest wishes)
email reminder: bug #50292
reminders relative to the end: bug #82105

And in case you didn't notice: Sounds and procedure alarm have already been 
supported by korganizer for some years...

Reinhold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20040922/468844dd/attachment.sig>