Hi Lisa,

It took me 3 times, but I think I finally got it now. ;o)

It seems like the real test for whether a recurrence rule should stay or go is: 
1. Are there examples of events that people schedule that require such a rule? (This criteria is implied throughout your document); and

2. Is there natural language way to express this rule and do people actually use it in day to day conversation?

So something like the 32nd Monday of the year would have a difficult time meeting either 1 or 2. If someone were Your head would have to jump through 2-3 hoops to figure out exactly where the 32nd Monday of the year falls. 

There are 52 weeks in the year. 32 is roughly 3/5ths into the year. That's 60% through the year. There are 12 months in a year. June 15 is 50% of the year. September 1st is 
66% of the year. So some time in August? Actually it's July. There's a reason why we keep track of time passing in month increments.

Criteria #2 makes an interesting argument for recurrence rules like 'every hour', every half hour etc.

Hourly is a common phrase and while it is rare in inter-personal scheduling, it is imaginable that it is useful for tasks (e.g. Take pill every hour.); and while tasks are not within the scope of this document, I have yet to bear witness to more than 3 people using electronic task lists religiously; instead, much more commonly, people use their calendar to track time-sensitive tasks, especially repetitive time-sensitive tasks (e.g. pay rent, take out the garbage, etc); which means that some sub-set of 'task use cases' should be considered when discussing personal calendaring.

Still, hourly is pretty rare, even for tasks like taking pills. Besides, who would want to clutter up their calendar with hourly tasks? And minutely seems completely outlandish in the personal calendaring domain.

So all in all, this is a long way of saying that this particular interpretation of 'simpler' is really better :o)

Mimi

On Jul 25, 2006, at 5:29 PM, Lisa Dusseault wrote:

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 <[EMAIL PROTECTED]>
Date: July 25, 2006 5:24:05 PM PDT
To: IETF-iCalendar <[EMAIL PROTECTED]>
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.

<recur-simplification.txt>

Feedback?

thanks!
Lisa_______________________________________________
Ietf-calsify mailing list

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to