Hi Jeffrey,
What I was envisioning is the ability to tell if the current
occurrence differs from the
Master. For example, the rule is every Thursday at 1pm but the mailed
occurrence
is this Tuesday at 1pm.
In the case illustrated above we would include both the Master Event
info and
the individual Event info.
Geek speak in the mail body would look something like this:
Master Event: QA Staff meeting every Thursday from 1:00 PM PST to
2:00 PM PST
Individual Event: 'QA Staff meeting this Tuesday from 1:00 PM PST to
2:00 PM PST'
I would leave it to Mimi to come up with a better wording but
you get the idea.
If the individual occurrence *does not* differ from the Master Event
then
no additional Individual Event info would be included.
Does this sound doable?
-Brian
On Apr 11, 2007, at 11:54 AM, Jeffrey Harris wrote:
Moving this to the design list...
The context for the design list is the thread starting at:
http://lists.osafoundation.org/pipermail/chandler-users/2007-April/
000216.html
It would take a bit of gymnastics to get the mail code to see the
current occurrence and use it for the email's body and fetch the whole
series for ICS and EIM, but it's doable.
With that said, I want to reiterate that I see sending the selected
occurrence's details in the email body as problematic. Chandler users
will see something different from what email users will see, because
there won't be anything to distinguish the occurrence that was
selected
when it was sent in EIMML, which is what other Chandlers will read,
not
the email body.
We could get around this by marking the selected occurrence and
putting
that information in the EIMML when sending it, but then we have to
figure out how to display that.
Another approach would be to serialize text for every
modification. But
making the concatenated events readable seems a little daunting to me
(and there could be a lot of events).
I guess it wouldn't be the end of the world for Chandler users to see
something different from email recipients (they obviously see
different
things now), but... making this sort of change makes me nervous. For
instance, if we make this change, if I really want the email body of
what's sent to reflect the first occurrence of a series, I have to go
find the first occurrence.
My feeling is that what we have now is less than perfect, but there
isn't a lot of coherent middle ground between our
mail-sends-the-whole-series compromise and a full featured system for
choosing to send a subset of the series.
Sincerely,
Jeffrey
Mimi Yin wrote:
Oh, I was just suggesting that instead of putting both the Master and
the Individual Occurrence's info in the body, we *just* put the
Individual occurrence in the body, since that's what the user sees
when
they hit Send.
Mimi
===
Relevant KIND-COMBINATIONS
+ Recurring Event
+ Recurring All-day Event
--------------
<SENDER> sent you a <KIND-COMBINATION> from Chandler at <DATE SENT>:
From:
To:
CC:
** <*SELECTED OCCURRENCE* TITLE> at <*SELECTED OCCURRENCE* LOCATION>
from/on <*SELECTED OCCURRENCE *START DATE/TIME> to <*SELECTED
OCCURRENCE* END DATE/TIME> <OPTIONAL *SELECTED OCCURRENCE* TIME ZONE>
until <OPTIONAL *SELECTED OCCURRENCE *RECURRENCE END-DATE>
<*SELECTED OCCURRENCE *NOTES>
--------------
PHRASING FOR <DATE/TIME> FOR RECURRING EVENTS
Daily: Every day from xxx to yyy.
Weekly: Tuesdays from xxx to yyy.
Biweekly: Every other Tuesday from xxx to yyy.
Monthly: Every month on the 17th from xxx to yyy.
_______________________________________________
chandler-users mailing list
[EMAIL PROTECTED]
http://lists.osafoundation.org/mailman/listinfo/chandler-users
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
