[Design] Fwd: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs

[Lisa Dusseault]

I wonder if this proposal is of interest also from the Chandler  
design perspective... I've run this by Jeffrey already, happy to hear  
what others think.

Lisa

Begin forwarded message:

> From: Lisa Dusseault <lisa at osafoundation.org>
> Date: July 25, 2006 5:24:05 PM PDT
> To: IETF-iCalendar <ietf-calsify at osafoundation.org>
> Subject: [Ietf-calsify] RRule simplification for interpersonal  
> calendar GUIs
>
>
> I would like to consider whether RRules are too complicated for GUI  
> display in our most common calendar client applications.  If I send  
> a complex RRule event to you and your client can't display the  
> RRule in its GUI, you can only accept or reject the request, not  
> modify it, and possibly not even understand it well.   Worse, if  
> I'm using CalDAV and one client creates a complex RRule but then I  
> switch to another client, I risk having a recurring event that I  
> can't manage.   Shared calendars are particularly subject to this  
> problem.
>
> Although RRules may need to be powerful for certain situations  
> (timezones), I believe they're too complex for use in events in  
> GUIs designed for personal calendaring.  As an exercise, I took  
> Apple's iCal, the most powerful recurrence-rule generating GUI  
> available to me at this time on this computer, and tried to  
> discover the full range of RRules I could create.  I also searched  
> the Web for instances of certain kinds of RRules (e.g. looking at  
> IETF meeting ICS files and similar shared files and googling for  
> BYWEEKNO.) The kinds of RRules that I couldn't find "in the wild"  
> or create, we should consider discouraging for interpersonal  
> calendaring.
>
> I don't care if we repeat the exercise for some other GUI client or  
> make changes on what some other GUI client can do; this first  
> attempt illustrates the approach rather than limits it.
>
> My personal opinion is that some kind of simplification is required  
> for two big reasons:
> 	- To improve interoperability between clients that attempt to do a  
> decent job of RRules
> 	- To encourage clients that currently don't do RRules (many mobile  
> devices) to implement.  Let's meet them half-way with  recurrence  
> functionality that's simple enough for them to implement, and if  
> they implement anything they're more likely to implement the whole  
> set if it's that simple.
>
> Besides GUI display concerns, I had a couple more minor reasons  
> which you can find inside the proposal.
>

> Feedback?
>
> thanks!
> Lisa_______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-------------- next part --------------
Skipped content of type multipart/mixed