One idea how to handle event blocking/nonblocking some more sophisticated

jaytraxx 2009-01-21 14:37:16 UTC #1

Hi guys,

me and my collegue just wondered how we could use calendar item’s states more sophisticated for our company as we wanted to use one calendar item to
invite people
and
inform the other people.
At the moment if you just want to inform people, you have to invite them as ususal and then the users have to “reject” the item if they don’t want to participate for the reason that the event shall not block their calendar. Now the event is gone in the users calendar. I know, we could say this user should set his prefs to “show rejected events” but that doesn’t make sense, because rejected events should stay “real” rejected.

We talked about the params “blocking / nonblocking” and “accepted / rejected” and came to one conclusion:
An already saved event with state “no response” should always be handled as “nonblocking” when eGW checks for overlapping events as long as the user does not give him a definite state like “accepted / tentative / rejected”.

Further more, these events could be displayed with 50% opacity to encourage the users to do something with new invitations. We often have the problem that users do not respond to invitations because of the missing difference between “no response” and “accepted”.

An invitation for a user who leaves the state to “no response” will then just be informative. The user sees it in its calendar with smooth opacity. That will also be a little eye-candy.

What do you think?
Greetings
Christian

David_Greaves 2009-01-22 09:52:37 UTC #2

jaytraxx wrote:

Hi guys,

me and my collegue just wondered how we could use calendar item’s states
more sophisticated for our company as we wanted to use one calendar item to
invite people
and
inform the other people.
At the moment if you just want to inform people, you have to invite them as
ususal and then the users have to “reject” the item if they don’t want to
participate for the reason that the event shall not block their calendar.
Now the event is gone in the users calendar. I know, we could say this user
should set his prefs to “show rejected events” but that doesn’t make sense,
because rejected events should stay “real” rejected.

We talked about the params “blocking / nonblocking” and “accepted /
rejected” and came to one conclusion:
An already saved event with state “no response” should always be handled as
"nonblocking" when eGW checks for overlapping events as long as the user
does not give him a definite state like “accepted / tentative / rejected”.

Further more, these events could be displayed with 50% opacity to encourage
the users to do something with new invitations. We often have the problem
that users do not respond to invitations because of the missing difference
between “no response” and “accepted”.

An invitation for a user who leaves the state to “no response” will then
just be informative. The user sees it in its calendar with smooth opacity.
That will also be a little eye-candy.

What do you think?
Greetings
Christian

I agree - I was thinking there should be visual indicators for calendar entry
states of:

no response (NEEDS-ACTION)
accepted (ACCEPTED)
maybe (TENTATIVE)
information only (?)
rejected

I checked the RFC http://www.ietf.org/rfc/rfc2445.txt and it says (in part)

4.2.12 Participation Status

Parameter Name: PARTSTAT

Purpose: To specify the participation status for the calendar user
specified by the property.

; These are the participation statuses for a “VEVENT”. Default is
; NEEDS-ACTION
partstatparam /= “PARTSTAT” “=”
(“NEEDS-ACTION” ; To-do needs action
/ “ACCEPTED” ; To-do accepted
/ “DECLINED” ; To-do declined
/ “TENTATIVE” ; To-do tentatively
; accepted
/ “DELEGATED” ; To-do delegated
/ “COMPLETED” ; To-do completed.
; COMPLETED property has
;date/time completed.
/ “IN-PROCESS” ; To-do in process of
; being completed
/ x-name ; Experimental status
/ iana-token) ; Other IANA registered
; status

So:

information only is not obviously supported
X-INFO-ONLY may be appropriate
where are the other IANA registered statuses and how can we discuss doing this
right?

–
“Don’t worry, you’ll be fine; I saw it work in a cartoon once…”

This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

jaytraxx 2009-01-22 15:55:39 UTC #3

Hi,

David Greaves:

jaytraxx wrote:

Hi guys,

me and my collegue just wondered how we could use calendar item’s states
more sophisticated for our company as we wanted to use one calendar item to
invite people
and
inform the other people.
At the moment if you just want to inform people, you have to invite them as
ususal and then the users have to “reject” the item if they don’t want to
participate for the reason that the event shall not block their calendar.
Now the event is gone in the users calendar. I know, we could say this user
should set his prefs to “show rejected events” but that doesn’t make sense,
because rejected events should stay “real” rejected.

We talked about the params “blocking / nonblocking” and “accepted /
rejected” and came to one conclusion:
An already saved event with state “no response” should always be handled as
"nonblocking" when eGW checks for overlapping events as long as the user
does not give him a definite state like “accepted / tentative / rejected”.

Further more, these events could be displayed with 50% opacity to encourage
the users to do something with new invitations. We often have the problem
that users do not respond to invitations because of the missing difference
between “no response” and “accepted”.

An invitation for a user who leaves the state to “no response” will then
just be informative. The user sees it in its calendar with smooth opacity.
That will also be a little eye-candy.

What do you think?
Greetings
Christian

I agree - I was thinking there should be visual indicators for calendar entry
states of:

no response (NEEDS-ACTION)

accepted (ACCEPTED)

maybe (TENTATIVE)

information only (?)

rejected

I checked the RFC http://www.ietf.org/rfc/rfc2445.txt and it says (in part)

4.2.12 Participation Status

Parameter Name: PARTSTAT

Purpose: To specify the participation status for the calendar user
specified by the property.

; These are the participation statuses for a “VEVENT”. Default is
; NEEDS-ACTION
partstatparam /= “PARTSTAT” “=”
(“NEEDS-ACTION” ; To-do needs action
/ “ACCEPTED” ; To-do accepted
/ “DECLINED” ; To-do declined
/ “TENTATIVE” ; To-do tentatively
; accepted
/ “DELEGATED” ; To-do delegated
/ “COMPLETED” ; To-do completed.
; COMPLETED property has
;date/time completed.
/ “IN-PROCESS” ; To-do in process of
; being completed
/ x-name ; Experimental status
/ iana-token) ; Other IANA registered
; status

So:

information only is not obviously supported

X-INFO-ONLY may be appropriate

where are the other IANA registered statuses and how can we discuss doing this
right?

I think we can leave the states as they are since we get into slight confusing things with creating another one. Implementing a new state ‘X-INFO-ONLY’ will mean that we have to change eGW that it spreads THIS state to specific users and THAT state to other users. That will be too much and confusing changes.

I think just slightly modify the handling of ‘No response (NEEDS-ACTION)’ to

display with opacity
let them behave as non-blocked
will make it more useable.

Greetings
Christian