Closed Bug 332196 Opened 14 years ago Closed 12 years ago
recurrence dialog doesn't support complex recurrence patterns [extension fodder]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:184.108.40.206) Gecko/20060111 Firefox/220.127.116.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060329 Mozilla Sunbird/0.3a1+ The current improvements now show: '3rd day of month' or 'First Monday of the month', which is derived from the DSTART date. This allows certain details to be seen and edited, but does not show many of the optinos already fully supported by Sunbird (if loaded in an iCal file). This is intened to resolve these issues, in a least effort fashion. Reproducible: Sometimes Steps to Reproduce: 1. select an event 2. Edit Event, Edit Recurrence 3. select 'Occurs Monthly' If you wanted to add a second occurence (in a month), or the settings (as defined in iCal file) can be seen, then you either fail or bad things happen (if you edit).
This is based around a design philosophy that dialog boxes should be simple, small, and not change prompting / 'fixed' elements to match specific data settings.
This supports ALL possible iCal weekday elements.
This all other weekly iCal settings, in addition to weekday.
support ALL iCal settings relating to Monthly recurrence.
Support for all iCal settings, that relate to yearly / annually.
support for all iCal daily settings.
non-frequency (Yearly, Monthly, etc.) specific repeat settings.
For adding list of dates, for either Recurrence or Exclusion.
Includes good selection of examples from: RCF 2445, U.S./Canada, and New Zealand.
/me cries. This is really really complicated. I don't think many users could understand this at all. We've generally been closing bugs that ask for the entire range of recurrence options to be implemented for exactly that reason. In 95% of the use cases, they are not needed. Something like this seems like it would be much better implemented in an extension for people that need to set such odd recurrence rules. (Note that this dialog still doesn't seem to support multiple RRULES.) I participated in a discussion about this sort of thing at CalConnect in January. Every vendor there said that they do not support setting the full range of recurrence options. A recommendation was even made to say "Your program *must* be able to display any RRULE in a calendar. It does not need to offer UI for editing any RRULE." A simple "This rule is too complicated for Sunbird to understand" warning could be appropriate in that case. I'm voting for WONTFIX on this bug, although this looks like some really good work that you've done.
Now includes support for multiple RRULE instances.
Can you define: "Your program *must* be able to display any RRULE .." - Does this mean that you should see the results (correctly) in the calendar? - OR Should you be able to *view* any possible RRULE settings? Did you review the examples in the attached StarOffice document? Optimum target for requirements are: - Add rule, with period of primary recurrence. (1 or more) - (per period) specify interval: 1..999999 (ie. 'every 4 years') - (per period) additional sub-details: (1 or more) - YEARLY: at month 1..12, within year (ie. 'in August') - YEARLY: at day [-]1..366, within year - MONTHLY: at day [-]1..31, within month (ie. "day of month") - WEEKLY: at week [-]1..53, within year (ie. 'week number') - WEEKLY: define week-start (default: Monday) - WEEKLY: on weekday (Mon..Sun); [-]1..4 in month, or [-]1..53 in year (ie. 'third Monday') - (per period) specify repeat: - Repeat Forever (default) - Repeat for: 1..999999 (count) - Repeat Until: DATE/TIME - (per period) specify instance: (1 or more) - ANY match (default) - Match number: [-]1..999999 (ie. 'third occurrence') General requirements: (in preference order) - Support most common settings (from iCal file) to be loaded, and work safely. - Showin broken items in Event List: flag (column), or color OPTIONAL - Support settings, once loaded, to be viewed. - Show multiplier effect (every Year, in March or June == 2) OPTIONAL - with note of syntax error / unknown. OPTIONAL - Add ability to support: - multiple RRULE, EXRULE, etc. - Hours/Minutes/Seconds, etc. - Support settings, once loaded, to be edited (safely). - disallow if unable to be edit (too complex / not supported) - Allow interactive creation, by non-skilled user. - show resultant dates (what if), with tag as exception. LATER What should not be included, and should wait for Extensions: (some draft ideas) (a) Pattern (what if, instances), Holidays (construct), Easter (etc.), .. (b) Birthdays (ages, milestones, planning, ..) (c) Schedule: Pattern (what if, instances), Holidays (construct), entitlement, reporting, .. (c) Lunar, Tides, Astrology, etc.. (d) Calendar (printing): pretty, just the data (for others to print / layout), .. (e) Timesheet: based on Sunbird calendar, time logging (against project/category), reporting, .. Currently NOT supported in Sunbird 0.3a1+ (03-30) UI: - Add rule, with period of primary recurrence. (1 or more) [ NOT multiple ] - (per period) specify interval. [ ONLY supported for DAILY, YEARLY ] - (per period) additional sub-details: (1 or more) [ NOT multiple ] - YEARLY: at month, within year [ NOT supported ] - YEARLY: at day, within year [ NOT supported ] - MONTHLY: at day, within month [ONLY supported with 'magic' button ] - WEEKLY: at week, within year [ NOT supported ] - WEEKLY: define week-start [ NOT supported ] - WEEKLY: on weekday, in month or year [ONLY supported with 'magic' button ] - (per period) specify repeat: - Repeat Until: DATE/TIME [ NO support for time ] - (per period) specify instance: [ NOT supported ] Some of these are important, although I haven't tried to rank them.
(In reply to comment #12) > Can you define: "Your program *must* be able to display any RRULE .." > - Does this mean that you should see the results (correctly) in the calendar? > - OR Should you be able to *view* any possible RRULE settings? It means the first case. The second case was where the 'This rule is too complicated' warning comes in. Looking through the document, I see examples of holidays. I do not, however, see example of every-day use cases for most of these complex options. Case in point: Easter. No one knows the pattern for when Easter repeats. They simply buy a calendar that has Easter on it. Sunbird, in my opinion, should operate the same way. You can't set Easter in its options, but if you get a calendar with Easter in it, it will show up correctly. What I do see in the attached screenshots is something that, in my opinion, only someone who had read RFC2445 thoroughly would have a chance of understanding. I'd like to advocate the 'grandma test' here. If your grandmother can't sit down and figure it out on her own without explanation, it's too complicated.
(In reply to comment #12) > Currently NOT supported in Sunbird 0.3a1+ (03-30) UI: > Some of these are important, although I haven't tried to rank them. > Ranking would be important here. That way, we can see what options are not suppoted yet, but are important. Then we can work creating UI for those recurrance rules. I agree with jminta that the proposed screenshots looks complicated. Recurrance UI is a delicate balance between features and easy-to-use. We need to find our way to that balance. Forget the ical standard, think of what the user would want.
(In reply to comment #13) > > Looking through the document, I see examples of holidays. I do not, however, > see example of every-day use cases for most of these complex options. > > [...] > > I'd like to advocate the 'grandma test' here. If your > grandmother can't sit down and figure it out on her own without explanation, > it's too complicated. I completely agree. While our current recurrence editing UI does need to be slightly more powerful, I think UI with this level of complexity belongs in an extension.
I have taken on board your comments, and have re-designed the dialog boxes to reflect this need. Have attached example of new version.
Enhanced rule functionality, still easy to use: - Single Rule - Rule Period, for recurrence: yearly, month, weekly, or daily - specify interval: 1..999999 (ie. 4: 'every 4 years') - Quick Pick: this month/day yearly, this day monthly, this weekday monthly, etc. - specify repeat: - Repeat Forever (default) - Repeat for: 1..999999 (count) - Repeat Until: DATE/TIME - Additional dates, to Include - Additional dates, to Exclude Additional sub-details: - Period: YEARLY - which month, within year (ie. 'in August') - which week number, within year (ie. 'week number') (1 or more) - which day, within year (1 or more) - which day, within month (ie. "day of month") (1 or more) - which weekday (Mon..Sun) in month (1 or more, same occurrence) - Period: MONTHLY - which day, within month (ie. "day of month") (1 or more) - which weekday (Mon..Sun) in month (1 or more, which occurrence) - Period: WEEKLY - which weekday (Mon..Sun) (1 or more, ANY occurrence) - Period: DAILY ( no extra sub-details) Special conditions: - ANY match is assumed: NO first, second, etc. (using BYSETPOS) - which month, within year: single Month only supported - which weekday, in month: mixed occurrence NOT supported (ie.1st Sun, and 4rd Fri) - which weekday, in year: NOT supported (ie. 18th Monday, of year) - which week-start value: System Default is assumed - HOURS, MINUTES, and SECONDS not yet supported
Attachment #217243 - Attachment is obsolete: true
*** Bug 275157 has been marked as a duplicate of this bug. ***
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
This whole area (more complex rules / recurrence) will need to be reviewed in consideration of the latest suggested revision to iCalendar standard: draft-ietf-calsify-rfc2445bis-04 excerpt: -- Appendix A. Differences from RFC 2445 This appendix contains a list of changes that have been made in the Internet Calendaring and Scheduling Core Object Specification from RFC 2445. A.1. New restrictions 1. The "DTSTART" property SHOULD match the pattern of the recurrence rule, if specified. 2. The "RRULE" property SHOULD NOT occur more than once in a component. A.2. Deprecated features 1. The "EXRULE" property can no longer be specified in a component. 2. The "RANGE" parameter can no longer be specified on the "RECURRENCE-ID" property. -- The 2 conflicting needs are: (a) keep it simple, and only support what any typical user might need for meetings / events they create in their calendar. (b) allow sufficient complexity to support holiday and other recurrence logic likely to be used by multiple parties as: (i) iCalendar format, or (ii) shared calendar access. Item (b) has not been well supported in IETF-calsify discussions, to date.
QA Discussion --> Marked this as an enhancement which is what it truly is. It is unclear given the comments how much of this will be accepted into the core product and how much will be an extension, so leaving Unconfirmed.
Severity: normal → enhancement
Whiteboard: [qa discussion needed]
Marking WONTFIX based on the comments from Joey, mvl and dmose and in light of our past decisions on such complex proposals. The current proposal is still very complex and very hard to understand for normal users (e.g. your grandma). We recognizte however that some users want to be able to express such complex recurrence patterns through the UI. Therefore an extension based on this proposal would be very much appreciated.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Summary: recurrence dialog doesn't support sufficient settings for complex patterns → recurrence dialog doesn't support complex recurrence patterns [extension fodder]
Generally accept your comments. However, with this audience (extension users) I will adjust definition of must-have and like-to-have features. Peoples, if YOU COULD ASSIST (in development of extension), please comment ..
You need to log in before you can comment on or make changes to this bug.