Alarm setting?

[Bernhard Reiter]

On Wednesday 22 September 2004 13:50, Reinhold Kainhofer wrote:
> 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. 

Then I might have missunderstood what you have meant eaarlier by:
    I just read the kolab spec once again, 
    and it seems that the alarm settings  are very poor 
    in the current version in cvs.

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

Our idea with the Kolab2 format is to first support
the most common way, because then the software (integrating 
Kontact) can do something that was not possible before:
Build a usable groupware solution.
Within this the current choice seems fine for now.
If that step is reached it makes sense to talk about the rare cases.

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

That is open to debate as some other issues in the posts are,
I suggest that we carry this to the kolab-devel or kde-pim lists,
because of the reach of those topics, which goes far beyond the
kolab-format itself.  What do you think?

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

Do not get me wrong at this: I am in favour of trying to add more
capabilites, but in terms of avaiable Free Software groupware solutions,
it seems to be the second step before the first.

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

Kolab would also offer the capability to try to model this situation with
	- an institute group account (marked alarm relevant)
	- an invitation to a distribution list (getting alarms in for all that accept
      and then use the personally adapted methods.)

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

Some of your examples are interesting, still they look like second step
to me and like not considering the possibilities when saving this in group
folders on a server and with access of different groups of people.

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

I do not see a problem making attachments like email attachements
to work reliably cross plattform. They are just binary blobs with a 
content-type.

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

This is one of the problems I do see with this RFC, it does not consider
the importance of the use cases. Because common and rare (and less important)
use cases are treated equally it is very hard to implement a fully compliant
software.

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

I still consider it a design flaw to allow this in the first place.

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

That is good to know.
We probably need to think about how to integrate this
the Kolab format in the future.

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

I read through the issues now.
My estimation still holds that this is not the most important thing
and other stuff is more important, especially in a real groupware setup.

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

I saw that, but I never used it.
How many different alarm sound do you have set?
-------------- 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/bb30fe71/attachment.p7s>